Skip to main content
Resources

Processo para Lidar com Solicitações de Remoção de Restrições de Propriedade Cruzada de Operadores de gTLDs Existentes

Esta página também está disponível em:

Por favor, observe que a versão em inglês de todo o conteúdo e dos documentos traduzidos são versões oficiais e que as traduções em outras línguas são apenas para fins de informar.

(Adotado em 18 de outubro de 2012)

Para remover restrições de propriedade cruzada, os operadores de registro de gTLDs podem solicitar um aditamento ao Contrato de Registro existente para remover as restrições de propriedade cruzada ou solicitar uma transição para a nova forma de Contrato de Registro para novos gTLDs. Qualquer aditamento significativo em contratos de registro de gTLDs está sujeito a um período para comentários públicos antes da aprovação pela ICANN. O processo é realizado da seguinte maneira:

  1. O operador de registro do gTLD envia uma solicitação por escrito para a ICANN a fim de fazer a transição para a nova forma de Contrato de Registro ou uma solicitação para aditar seu Contrato de Registro atual e inclui o aditamento proposto. Se o operador de registro solicitar um aditamento, ele incluirá:

    1. A. Declarações semelhantes às que são dispostas nas Seções 2.9(b) e (c) do contrato de novos gTLDs http://newgtlds.icann.org/en/applicants/agb da seguinte maneira:

      "(b) Se o Operador de Registro (i) se tornar um Afiliado ou revendedor de um registrador acreditado da ICANN , ou (ii) subcontratar a prestação de quaisquer Serviços de registro para um registrador acreditado da ICANN, revendedor registrador ou qualquer um de seus respectivos afiliados, em qualquer um dos casos (i) ou (ii) acima, o Operador de Registro avisará prontamente a ICANN sobre o contrato, transação ou outra disposição que tenha resultado de tal afiliação, relacionamento de revenda ou subcontrato, conforme seja aplicável, inclusive se for solicitado pela ICANN, cópias de qualquer contrato relacionado, desde que a ICANN não divulgue tal contrato para terceiros, além das autoridades de concorrência relevantes. A ICANN se reserva o direito, mas não a obrigação, de encaminhar todo contrato, transação ou outras disposições a autoridades de concorrência relevantes no caso de a ICANN determinar que tal contrato, transação ou outras disposições possam suscitar problemas de concorrência.

      (c) Para os fins do presente Contrato: (i) "Afiliado" significa uma pessoa ou entidade que, direta ou indiretamente, por meio de um ou mais intermediários, controla, é controlada pela pessoa ou entidade especificada ou se encontra sob controle comum dela, e (ii) "controle" (inclusive os termos "controlado por" e "sob controle comum de") significa deter, direta ou indiretamente, o poder de dirigir ou fazer dirigir a administração ou políticas de uma pessoa ou entidade, seja por meio de propriedade de títulos, como fiduciário ou executor, atuando como funcionário ou membro de uma diretoria ou órgão diretor equivalente, por contrato, por disposição de crédito ou de outra forma."

    2. Uma declaração de modo a atender ao novo Código de Conduta de Operador de Registro. Isso é disposto na Seção 2.14 do contrato de novos gTLDs da seguinte maneira:

      "Juntamente com a operação do registro para o TLD, o Operador de Registro atenderá ao Código de Conduta de Registro conforme estabelecido na especificação em [consulte a Especificação 9]."

      Nesse caso, é necessário acrescentar o Código de Conduta de Operador de Registro como um novo Anexo.

    3. Aditamento da Seção 7.1(b), por exemplo, dos contratos de biz/info/org (ou termos semelhantes em outros contratos), de modo que o texto seja:

      (b) o Operador de Registro não atuará como seu próprio registrador. O Operador de Registro não atuará como um registrador relacionado ao TLD. Isso não impedirá que o Operador de Registro faça o registro de nomes com o TLD para si mesmo por meio de uma solicitação feita a um registrador credenciado pela ICANN nem que ele se torne um afiliado ou um revendedor para um registrador credenciado pela ICANN.

    4. Remoção da Seção 7.1(c), por exemplo, dos contratos de biz/info/org (ou termos semelhantes em outros contratos).
  2. Cada solicitação para remover restrições de propriedade cruzada estará sujeita a uma revisão de concorrência, semelhante à que é realizada na fase de determinação preliminar de uma solicitação do Processo de Avaliação de Serviços de Registros http://www.icann.org/en/registries/rsep/prelim-competition-issues-en.htm). Se a ICANN (após consulta com seus próprios especialistas) determinar em até 15 dias que a remoção das restrições de propriedade cruzada poderá resultar em problemas significativos de concorrência, a ICANN deverá notificar o operador de registro que a ICANN pretende encaminhar a solicitação à(s) autoridade(s) de concorrência governamental(ais) apropriada(s) com jurisdição sobre a questão. Depois disso, o operador de registro poderá, a seu próprio critério, retirar sua solicitação de aditamento. Se o operador de registro optar por prosseguir com o processo, a solicitação de aditamento permanecerá com o status de pendente até a(s) autoridade(s) de concorrência fornecerem uma resposta concreta à ICANN. Após o recebimento dessa resposta, a ICANN concluirá sua revisão e consideração da solicitação de aditamento. Se a ICANN não receber uma resposta da(s) autoridade(s) de concorrência em até 90 dias, a ICANN, a seu próprio critério, poderá, considerando todos os fatores relevantes, prosseguir com o processo de análise da solicitação ou, se for viável diante das circunstâncias, postergar a consideração do aditamento proposto até que a ICANN tenha recebido uma resposta concreta da(s) autoridade(s) de concorrência. Observação: não há nada nesse processo que indique que uma autoridade de concorrência seja obrigada a tomar alguma ação em qualquer momento.
  3. Todo aditamento solicitado de acordo com esse processo será publicado para comentários públicos.
Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."