CONTRATO DE REGISTRO

Este CONTRATO DE REGISTRO (este “Contrato”) é celebrado em (a “Data de início de vigência”) entre a Corporação da Internet para atribuição de nomes e números, uma corporação de utilidade pública sem fins lucrativos com sede na Califórnia (“ICANN”), e , um

(“Operador de Registro”).

ARTIGO 1.

AUTORIZAÇÃO E OPERAÇÃO DE DOMÍNIO DE PRIMEIRO NÍVEL; DECLARAÇÕES E GARANTIAS

1.1 Domínio e designação. O domínio de primeiro nível ao qual este Contrato se aplica é (o “TLD”). Na Data de início de vigência e até a data de término do Prazo (conforme definido na Seção 4.1) ou da rescisão deste Contrato nos termos do Artigo 4, a ICANN designa o Operador de Registro como operador de registro do TLD, sujeito aos requisitos e aprovações necessárias para a autorização do TLD e entrada na zona raiz.

1.2 Viabilidade técnica da cadeia de caracteres. Embora a ICANN tenha incentivado e continuará incentivando a aceitação universal de todas as cadeias de caracteres de domínios de primeiro nível na Internet, algumas cadeias de caracteres de domínios de primeiro nível podem encontrar dificuldades para ser aceitas por ISPs e webhosters e/ou validadas por aplicativos da web. O Operador de Registro será responsável por garantir, no cumprimento de sua obrigação, a viabilidade técnica da cadeia de caracteres do TLD antes de assinar este Contrato.

1.3 Declarações e garantias.

(a) O Operador de Registro declara e garante à ICANN que:

(i) todas as informações importantes fornecidas e as declarações feitas na solicitação do TLD do registro, assim como as declarações feitas por escrito durante a negociação deste Contrato, são verdadeiras e corretas em todos os aspectos relevantes no momento em que foram feitas, e tais informações ou declarações continuam a ser verdadeiras e corretas em todos os aspectos relevantes a partir da Data de início de vigência, salvo divulgação prévia de outra forma e por escrito pelo Operador de Registro à ICANN;

(ii) o Operador de Registro encontra-se devidamente organizado, validamente existente e em boas condições nos termos das leis do foro previsto no preâmbulo do presente documento, e o Operador de Registro detém todo o poder e a autoridade necessários e obteve todas as aprovações necessárias para celebrar e executar devidamente este Contrato; e

(iii) o Operador de Registro entregou à ICANN um instrumento devidamente assinado que assegura os recursos necessários para executar as funções de registro do TLD em caso de rescisão ou expiração deste Contrato

(o “Instrumento de Operações Contínuas”), e tal instrumento é uma obrigação vinculativa entre as respectivas partes e exequível contra as respectivas partes, em conformidade com os respectivos termos.

(b) A ICANN declara e garante ao Operador de Registro que a ICANN é uma corporação de utilidade pública sem fins lucrativos, devidamente organizada, validamente existente e em boas condições conforme as leis do estado da Califórnia, nos Estados Unidos da América. A ICANN detém todo o poder e a autoridade necessários e obteve todas as aprovações corporativas necessárias para celebrar e executar devidamente este Contrato.

ARTIGO 2.

COMPROMISSOS DO OPERADOR DE REGISTRO

O Operador de Registro assume e concorda com a ICANN da seguinte forma:

2.1 Serviços aprovados; Serviços adicionais. O Operador de Registro terá o direito de prestar os Serviços de registro descritos nas cláusulas (a) e (b) do primeiro parágrafo da Seção 2.1 da Especificação 6 anexa a este documento (“Especificação 6”) e os demais Serviços de registro previstos no Documento A (coletivamente, os “Serviços aprovados”). Se o Operador de Registro desejar prestar qualquer Serviço de registro que não seja um Serviço aprovado ou que constitua uma modificação significativa de um Serviço aprovado (sendo cada um deles um “Serviço adicional”), o Operador de Registro deverá apresentar uma solicitação de aprovação para tal Serviço adicional de acordo com a Política de Avaliação de Serviços de Registro, disponível em xxxxx://xxx.xxxxx.xxx/xxxx, já que tal política poderá ser alterada esporadicamente de acordo com o Estatuto da ICANN (conforme alterado ocasionalmente, o “Estatuto da ICANN”) aplicável às Políticas Consensuais (a “RSEP”). O Operador de Registro só poderá oferecer Serviços adicionais com a aprovação por escrito da ICANN e, após tal aprovação, esses Serviços adicionais serão considerados Serviços de registro, nos termos deste Contrato. Segundo seu próprio critério, a ICANN poderá requerer um aditamento a este Contrato que reflita a prestação de qualquer Serviço adicional que seja aprovado de acordo com a RSEP, sendo que tal aditamento deverá ser feito em uma forma razoavelmente aceitável para as partes.

2.2 Conformidade com Políticas Consensuais e Políticas Temporárias. O Operador de Registro cumprirá e implementará todas as Políticas Consensuais e as Políticas Temporárias disponíveis em xxxxx://xxx.xxxxx.xxx/xxxxxxxxx-xxxxxxxx, a partir da Data de início de vigência e conforme possam ser desenvolvidas e adotadas no futuro, de acordo com o Estatuto da ICANN, contanto que essas Políticas Consensuais e Políticas Temporárias sejam adotadas de acordo com o procedimento e estejam relacionadas aos tópicos e sujeitas às limitações dispostas na Especificação 1 anexa a este documento (“Especificação 1”).

2.3 Depósito de dados. O Operador de Registro deverá cumprir os procedimentos de depósito de dados estabelecidos na Especificação 2 anexa a este

documento (“Especificação 2”) em um prazo de catorze (14) dias consecutivos após a

autorização.

2.4 Relatório mensal. Em um prazo de vinte (20) dias consecutivos após o final de cada mês, começando com o primeiro mês no qual o TLD for autorizado na zona raiz, o Operador de Registro deverá apresentar à ICANN relatórios no formato indicado na Especificação 3 anexa a este documento (“Especificação 3”).; no entanto, se o TLD for autorizado na zona raiz após o décimo quinto (15º) dia do mês, o Operador de Registro poderá adiar a entrega dos relatórios referentes a esse primeiro mês e entregá-los à ICANN no máximo até o momento em que deverão ser entregues os relatórios do mês imediatamente seguinte. O Operador de Registro deverá incluir no relatório de transações por registrador todos os nomes de domínio criados durante os testes de pré-autorização que não foram excluídos até o momento da autorização (de modo especial, mas não se limitando aos domínios registrados pelos IDs de registrador 9995 e/ou 9996).

2.5 Publicação dos dados de registro. O Operador de Registro deverá proporcionar acesso público aos dados de registro de acordo com a Especificação 4 anexa a este documento (“Especificação 4”).

2.6 Nomes reservados. A menos que a ICANN autorize expressamente por escrito de outra forma, o Operador de Registro deverá cumprir os requisitos estabelecidos na Especificação 5 anexa a este documento (“Especificação 5”). O Operador de Registro poderá, a qualquer momento, estabelecer ou modificar as políticas referentes à capacidade do Operador de Registro de reservar (ou seja, recusar o registro ou alocar ao Operador de Registro, mas não registrar para terceiros, autorizar, usar, ativar no DNS ou disponibilizar de outra forma) ou bloquear cadeias de caracteres adicionais dentro do TLD a seu critério. Exceto conforme especificado na Especificação 5, se o Operador de Registro for o registrante de qualquer nome de domínio no TLD do registro, o respectivo registro deverá ser feito por meio de um registrador credenciado pela ICANN e será considerado como uma Transação (conforme definido na Seção 6.1) para fins de cálculo da taxa de transação do nível do registro a ser paga à ICANN pelo Operador de Registro, de acordo com a Seção 6.1.

2.7 Interoperabilidade e continuidade do registro. O Operador de Registro deverá cumprir as Especificações de interoperabilidade e continuidade do registro estabelecidas na Especificação 6 anexa a este documento (“Especificação 6”).

2.8 Proteção dos direitos legais de terceiros. O Operador de Registro deverá especificar e cumprir os processos e procedimentos para lançamento do TLD e a proteção inicial e contínua relacionada ao registro dos direitos legais de terceiros, conforme estabelecido na Especificação 7 anexa a este documento (“Especificação 7”). O Operador de Registro poderá, a seu critério, implementar proteções adicionais dos direitos legais de terceiros. Quaisquer alterações ou modificações no processo e procedimentos, exigidas pela Especificação 7 após a Data de início de vigência, deverão ser aprovadas previamente pela ICANN por escrito. O Operador de Registro deverá estar em conformidade com todas as reparações impostas pela ICANN conforme a Seção 2 da Especificação 7, sujeito ao direito do Operador de Registro de contestar tais reparações conforme estabelecido no

procedimento aplicável, descrito na mesma especificação. O Operador de Registro tomará medidas razoáveis para investigar e responder a todas as denúncias de conduta ilegal relacionada ao uso do TLD, provenientes de órgãos semigovernamentais, governamentais e de agências legais fiscalizadoras. Em resposta a essas denúncias, o Operador de Registro não será obrigado a tomar nenhuma medida que contrarie a legislação aplicável.

2.9 Registradores.

(b) Se o Operador de Registro (i) se tornar um Afiliado ou revendedor de um registrador credenciado pela ICANN, ou (ii) subcontratar a prestação de qualquer Serviço de registro para um registrador credenciado pela ICANN, revendedor registrador

ou qualquer um de seus respectivos Afiliados, então, em qualquer um dos casos (i) ou (ii) acima, o Operador de Registro avisará imediatamente a ICANN sobre o contrato, transação ou outra disposição que tenha resultado em tal afiliação, relacionamento de revenda ou subcontrato, conforme aplicável, e incluirá, caso solicitado pela ICANN, cópias de qualquer contrato relacionado; a ICANN tratará tal contrato ou documentos relacionados que estiverem adequadamente marcados como confidenciais (conforme exigido na Seção 7.15) como Informações confidenciais do Operador de Registro, de acordo com a Seção 7.15 (com a exceção de que a ICANN poderá divulgar tal contrato e documentos relacionados a autoridades de concorrência relevantes). A ICANN reserva-se o direito, mas não a obrigação, de encaminhar tais contratos, documentos relacionados, transações ou outras disposições a autoridades de concorrência relevantes, caso a ICANN determine que tais contratos, documentos relacionados, transações ou outras disposições possam suscitar problemas de concorrência significativos nos termos da legislação aplicável. Caso seja viável e apropriado nas circunstâncias, a ICANN fornecerá ao Operador de Registro um aviso prévio antes de fazer qualquer encaminhamento a uma autoridade de concorrência.

(c) Para os fins do presente Contrato: (i) “Afiliado” refere-se a uma pessoa ou entidade que, direta ou indiretamente, por meio de um ou mais intermediários, ou em combinação com uma ou mais pessoas ou entidades, controla, é controlada ou se encontra sob controle comum com a pessoa ou entidade especificada, e (ii) “controle” (inclusive os termos “controlado por” e “sob controle comum com”) refere-se a deter, direta ou indireta, o poder de dirigir ou fazer dirigir a administração ou as 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.10 Definição de preços dos Serviços de registro.

(a) Com relação aos registros iniciais de nomes de domínio, o Operador de Registro deverá fornecer a cada registrador credenciado pela ICANN que tenha firmado o Contrato entre registro e registrador do TLD um aviso prévio por escrito sobre qualquer aumento de preço (inclusive como resultado da eliminação de eventuais reembolsos, abatimentos, descontos, vinculação de produto ou outros programas que, de alguma forma, reduziram o preço cobrado dos registradores, a menos que tais reembolsos, abatimentos, descontos, vinculação de produto ou outros programas tenham uma duração limitada e que essa condição tenha sido clara e ostensivamente divulgada ao registrador quando oferecida), com um prazo mínimo de trinta (30) dias consecutivos. O Operador de Registro deverá oferecer aos registradores a opção de obter registros iniciais de nomes de domínio por períodos de um (1) a dez (10) anos, a critério do registrador, mas sem ultrapassar dez

(10) anos.

(b) Com relação à renovação de registros de nome de domínio, o Operador de Registro deverá fornecer a cada registrador credenciado pela ICANN que tenha firmado o Contrato entre registro e registrador do TLD um aviso prévio por escrito sobre qualquer aumento de preço (inclusive como resultado da eliminação de eventuais reembolsos, abatimentos, descontos, vinculação de produto, programas de marketing

qualificados ou outros programas que, de alguma forma, reduziram o preço cobrado dos registradores), com um prazo mínimo de cento e oitenta (180) dias consecutivos. Não obstante a frase anterior, com relação à renovação de registros de nome de domínio: (i) o Operador de Registro deverá fornecer um aviso prévio com um prazo de apenas trinta (30) dias consecutivos sobre qualquer aumento de preço, se o preço resultante for menor ou equivalente a: (A) para o período iniciado na Data de início de vigência e com encerramento doze (12) meses após a Data de início de vigência, o preço inicial cobrado pelos registros no TLD, ou (B) para períodos subsequentes, um preço para o qual o Operador de Registro tiver fornecido um aviso de acordo com a primeira frase desta

Seção 2.10(b) dentro do período de doze (12) meses anteriores à data de início de vigência do aumento de preço proposto; e (ii) o Operador de Registro não precisará fornecer aviso sobre aumentos de preço para a imposição da Taxa variável do nível do registro, estabelecida na Seção 6.3. O Operador de Registro deverá oferecer aos registradores a opção de obter renovações de registros de nomes de domínio ao preço atual (ou seja, o preço praticado antes de qualquer aumento notificado) por períodos de um (1) a dez (10) anos, a critério do registrador, mas sem ultrapassar dez (10) anos.

(c) Além disso, o Operador de Registro deverá ter uma definição de preços uniforme para renovações de registros de nomes de domínios (“Preço de renovação”). Para os fins de determinação do Preço de renovação, o preço de cada renovação de registro de domínio deverá ser idêntico ao preço de todas as outras renovações de registros de nomes de domínios em prática no momento de tal renovação, e esse preço deverá considerar a aplicação universal de eventuais reembolsos, abatimentos, descontos, vinculação de produtos ou outros programas vigentes no momento da renovação. Os requisitos anteriores desta Seção 2.10(c) não se aplicarão (i) à determinação do Preço de renovação se o registrador tiver fornecido ao Operador de Registro uma documentação que demonstre que o respectivo registrante ajustou expressamente, em seu Contrato de registro com o registrador, um Preço de renovação mais alto no momento do registro inicial do nome de domínio após tal Preço de renovação ter sido clara e ostensivamente divulgado a tal registrante, e (ii) ao Preço de renovação descontado de acordo com um Programa de marketing qualificado (conforme definido abaixo). As partes reconhecem que a finalidade desta Seção 2.10(c) é proibir práticas de definição do Preço de renovação abusivas e/ou discriminatórias impostas pelo Operador de Registro sem o consentimento por escrito do registrante aplicável no momento do registro inicial do domínio, e esta Seção 2.10(c) será interpretada de modo amplo para proibir tais práticas. Para os fins desta Seção 2.10(c), um “Programa de marketing qualificado” é um programa de marketing no qual o Operador de Registro oferece um Preço de renovação com desconto, desde que todos os critérios a seguir sejam atendidos: (i) o programa e os descontos relacionados são oferecidos por um período não superior a cento e oitenta (180) dias consecutivos (com programas consecutivos consideravelmente similares agregados a fim de determinar o número de dias consecutivos do programa), (ii) todos os registradores credenciados pela ICANN têm a mesma oportunidade de obter tal Preço de renovação com desconto; e (iii) a intenção ou efeito do programa não é excluir nenhuma classe especial de registros (por exemplo, registros mantidos por grandes corporações) nem aumentar o preço de renovação de nenhuma classe especial de registros. Nenhuma cláusula desta

Seção 2.10(c) deverá limitar as obrigações do Operador de Registro nos termos da Seção 2.10(b).

(d) O Operador de Registro deverá fornecer um serviço público de pesquisa no DNS com base em consultas do TLD (ou seja, operar os servidores de zona do TLD do registro) às suas expensas.

2.11 Auditorias de conformidade contratual e operacional.

(a) A ICANN poderá ocasionalmente (no máximo duas vezes por ano- calendário) realizar ou contratar terceiros para realizar auditorias de conformidade contratual a fim de avaliar a conformidade do Operador de Registro com suas declarações e garantias contidas no Artigo 1 deste Contrato e seus compromissos contidos no Artigo 2 deste Contrato. Essas auditorias deverão ser adaptadas para atingir o objetivo de avaliar a conformidade e a ICANN (a) enviará um aviso com antecedência razoável sobre essa auditoria especificando em detalhes as categorias de documentos, dados e outras informações solicitadas pela ICANN, e (b) usará meios comerciais razoáveis para realizar essa auditoria de modo a não interromper desnecessariamente as operações do Operador de Registro. Como parte dessa auditoria e por solicitação da ICANN, o Operador de Registro deverá fornecer em tempo hábil todos os documentos, dados e quaisquer outras informações necessárias para demonstrar a conformidade do Operador de Registro com este Contrato. Com um aviso prévio de no mínimo dez (10) dias (a menos que o Operador de Registro concorde com outro prazo), a ICANN poderá, como parte de qualquer auditoria de conformidade contratual, fazer visitas ao local durante o horário comercial a fim de avaliar a conformidade do Operador de Registro com suas declarações e garantias contidas no Artigo 1 deste Contrato e seus compromissos contidos no Artigo 2 deste Contrato. Quaisquer informações obtidas em conexão com essas auditorias e apropriadamente marcadas como confidenciais (conforme exigido pela Seção 7.15) serão tratadas pela ICANN como Informações confidenciais do Operador de Registro, de acordo com a

Seção 7.15.

(b) Qualquer auditoria realizada nos termos da Seção 2.11(a) será feita às expensas da ICANN, a menos que (i) o Operador de Registro (A) controle, seja controlado, esteja sob controle comum ou de outra forma Afiliado a qualquer registrador credenciado pela ICANN ou revendedor de registrador ou qualquer um de seus respectivos Afiliados, ou

(B) tenha subcontratado um registrador credenciado pela ICANN ou revendedor de registrador ou qualquer um de seus respectivos Afiliados para prestar Serviços de registro e, em qualquer um dos casos (A) ou (B) acima, a auditoria se refira à conformidade do Operador de Registro com a Seção 2.14, em cujo caso o Operador de Registro deverá reembolsar à ICANN todos os custos e despesas razoáveis, associados à parte da auditoria relacionada à conformidade do Operador de Registro com a Seção 2.14, ou (ii) a auditoria esteja relacionada a uma discrepância nas taxas pagas pelo Operador de Registro nos termos deste instrumento superior a 5% em determinado trimestre, em detrimento da ICANN, em cujo caso o Operador de Registro deverá reembolsar à ICANN todos os custos e despesas razoáveis associados à totalidade de tal auditoria. Em qualquer um dos casos (i) ou (ii) acima, tal reembolso será pago juntamente com o pagamento da próxima Taxa do

nível do registro devida após a data de transmissão da declaração de custos para tal auditoria.

(c) Não obstante a Seção 2.11(a), se for determinado que o Operador de Registro não está em conformidade com suas declarações e garantias contidas no Artigo 1 deste Contrato ou com seus compromissos contidos no Artigo 2 deste Contrato, em duas auditorias consecutivas realizadas nos termos desta Seção 2.11, a ICANN poderá aumentar o número dessas auditorias para uma a cada trimestre.

(d) O Operador de Registro avisará imediatamente a ICANN sobre o conhecimento do Operador de Registro do início de qualquer um dos procedimentos referidos na Seção 4.3(d) ou da ocorrência de qualquer uma das matérias especificadas na Seção 4.3(f).

2.12 Instrumento de Operações Contínuas. O Operador de Registro deverá estar em conformidade com os termos e condições relacionados ao Instrumento de Operações Contínuas e estabelecidos na Especificação 8 anexa a este documento (“Especificação 8”).

2.13 Transição de emergência. O Operador de Registro concorda que, caso seja atingido algum dos limites de emergência para as funções de registro estabelecidos na Seção 6 da Especificação 10, a ICANN poderá designar um operador de registro interino de emergência do registro do TLD (um “Operador de emergência”) de acordo com o processo de transição de registro da ICANN (disponível em xxxxx://xxx.xxxxx.xxx/xxxxxxxx-xxxxxxxxxx-xxxxxxxxx) (conforme possa ser alterado esporadicamente, o “Processo de Transição de Registro”), até o momento em que o Operador de Registro demonstrar, de modo razoavelmente satisfatório para a ICANN, que está apto a retomar a operação do registro do TLD sem a nova ocorrência dessa falha. Após tal demonstração, o Operador de Registro poderá retornar à operação do registro do TLD nos termos dos procedimentos estabelecidos no Processo de Transição de Registro, desde que o Operador de Registro pague todos os custos razoáveis incorridos (i) pela ICANN como resultado da designação do Operador de emergência e (ii) pelo Operador de emergência em conexão à operação do registro do TLD, cujos custos deverão ser documentados de maneira razoavelmente detalhada nos registros que serão disponibilizados ao Operador de Registro. Caso a ICANN designe um Operador de emergência nos termos desta Seção 2.13 e do Processo de Transição de Registro, o Operador de Registro deverá enviar à ICANN ou a tal Operador de emergência todos os dados (inclusive os dados depositados de acordo com a Seção 2.3) com relação a operações do registro do TLD necessárias para manter operações e funções de registro que poderão ser razoavelmente solicitadas pela ICANN ou por esse Operador de emergência. O Operador de Registro concorda que a ICANN pode fazer qualquer alteração que considerar necessária no banco de dados da IANA de registros do DNS e do WHOIS com relação ao TLD, caso um Operador de emergência seja designado nos termos desta Seção 2.13. Além disso, em caso de tal falha, a ICANN deverá reter e poderá exigir seus direitos de acordo com o Instrumento de Operações Contínuas.

2.14 Código de Conduta do Registro. Em conexão com a operação do registro do TLD, o Operador de Registro deverá cumprir o Código de Conduta do Registro, conforme estabelecido na Especificação 9 anexa a este documento (“Especificação 9”).

2.15 Cooperação com estudos econômicos. Se a ICANN iniciar ou encomendar um estudo econômico sobre o impacto ou o funcionamento de novos domínios genéricos de primeiro nível na Internet, sobre o DNS ou outros assuntos relacionados, o Operador de Registro deverá cooperar de modo razoável com esse estudo, inclusive fornecendo à ICANN ou seu representante que estiver realizando tal estudo todos os dados relacionados à operação do TLD razoavelmente necessários para os fins de tal estudo e solicitados pela ICANN ou seu representante; o Operador de Registro poderá reter (a) eventuais análises internas ou avaliações preparadas pelo Operador de Registro com respeito a tais dados e

(b) todos os dados na medida em que a entrega de tais dados possa infringir a legislação aplicável. Todos os dados entregues à ICANN ou seu representante nos termos desta Seção 2.15 que estiverem devidamente marcados como confidenciais (conforme exigido pela Seção 7.15) deverão ser tratados como Informações confidenciais do Operador de Registro, de acordo com a Seção 7.15; se a ICANN agregar e tornar anônimos tais dados, a ICANN ou seu representante poderá divulgar esses dados a terceiros. Após a conclusão de um estudo econômico para o qual o Operador de Registro tenha fornecido dados, a ICANN destruirá todos os dados fornecidos pelo Operador de Registro que não tenham sido agregados e tornados anônimos.

2.16 Especificações de desempenho do registro. As especificações de desempenho do registro da operação do TLD serão as estabelecidas na Especificação 10 anexa a este documento (“Especificação 10”). O Operador de Registro deverá cumprir tais Especificações de desempenho e, por um período de no mínimo um (1) ano, deverá manter registros técnicos e operacionais suficientes para demonstrar conformidade com tais especificações para cada ano-calendário durante o Prazo.

2.17 Outros compromissos de interesse público. O Operador de Registro deverá atender aos compromissos de interesse público estabelecidos na Especificação 11 anexa a este documento (“Especificação 11”).

2.18 Dados pessoais. O Operador de Registro deverá (i) avisar a cada registrador credenciado pela ICANN que constituir uma das partes do Contrato entre Registro e Registrador do TLD sobre os fins para os quais os dados sobre qualquer pessoa natural identificada ou identificável (“Dados pessoais”) entregues ao Operador de Registro por tal registrador serão coletados e utilizados nos termos deste Contrato ou de outra forma, além dos destinatários pretendidos (ou categorias de destinatários) de tais Dados pessoais, e (ii) solicitar que tal registrador obtenha o consentimento de cada registrante no TLD para tal coleta e uso de dados pessoais. O Operador de Registro deverá tomar medidas razoáveis para proteger os dados pessoais coletados desse registrador contra perda, mau uso, divulgação não autorizada, alteração ou destruição. O Operador de Registro não deverá usar nem autorizar o uso de Dados pessoais em um modo que seja incompatível com o aviso fornecido aos registradores.

2.19 [Observação: apenas para TLDs baseados na comunidade] Obrigações do Operador de Registro para com a comunidade do TLD. O Operador de Registro estabelecerá políticas de registro em conformidade com a solicitação apresentada em relação ao TLD para: (i) convenções de nomenclatura dentro do TLD, (ii) requisitos de

registro para membros da comunidade de TLDs e (iii) uso de nomes de domínios registrados em conformidade com a finalidade declarada do TLD de comunidade. O Operador de Registro deverá operar o TLD de modo a permitir que a comunidade do TLD discuta e participe do desenvolvimento e da modificação de políticas e práticas do TLD. O Operador de Registro deverá estabelecer procedimentos para a aplicação de políticas de registro do TLD e a resolução de disputas referentes à conformidade com as políticas de registro do TLD, e deverá impor tais políticas de registro. O Operador de Registro concorda em implementar e submeter-se ao Procedimento de Resolução de Disputas de Restrições de Registro, conforme estabelecido em xxxxx://xxx.xxxxx.xxx/xxxxx com relação a disputas decorrentes dos termos desta Seção 2.19. O Operador de Registro deverá implementar e cumprir as políticas de registro da comunidade estabelecidas na Especificação 12 anexa a este documento.]

ARTIGO 3.

COMPROMISSOS DA ICANN

A ICANN declara e concorda com o Operador de Registro da seguinte forma:

3.1 Aberta e transparente. Em coerência com a missão e os valores essenciais expressos da ICANN, esta deverá operar de modo aberto e transparente.

3.2 Tratamento equitativo. A ICANN não aplicará normas, políticas, procedimentos ou práticas de maneira arbitrária, infundada ou injusta e não dará um tratamento diferenciado ao Operador de Registro, a menos que justificado por uma causa substancial e razoável.

3.3 Servidores de nomes do TLD. A ICANN deverá envidar esforços comercialmente razoáveis para garantir que eventuais alterações nas designações de servidores de nomes do TLD apresentadas à ICANN pelo Operador de Registro (no formato e com os elementos técnicos necessários especificados pela ICANN em xxxxx://xxx.xxxx.xxx/xxxxxxx/xxxx/) serão implementadas pela ICANN dentro de sete

(7) dias consecutivos ou o mais rápido possível após verificações técnicas.

3.4 Publicação de informações da zona raiz. A publicação de informações de contato da zona raiz do TLD por parte da ICANN incluirá o Operador de Registro e seus contatos administrativos e técnicos. Qualquer solicitação para modificar as informações de contato do Operador de Registro deverá ser feita no formato especificado esporadicamente pela ICANN em xxxxx://xxx.xxxx.xxx/xxxxxxx/xxxx/.

3.5 Banco de dados raiz oficial. Na medida em que a ICANN for autorizada a definir a política em relação a um sistema de servidor raiz oficial (o “Sistema de servidor raiz oficial”), a ICANN envidará esforços comercialmente razoáveis para (a) garantir que a raiz oficial aponte para os servidores de nomes de domínio de primeiro nível designados pelo Operador de Registro do TLD, (b) manter um banco de dados publicamente disponível estável, seguro e oficial das informações relevantes sobre o TLD, de acordo com as políticas e procedimentos publicamente disponíveis da ICANN, e (c) coordenar o Sistema de

servidor raiz oficial para que seja operado e mantido de modo estável e seguro; a ICANN não deverá descumprir este Contrato e a ICANN não terá nenhuma responsabilidade caso terceiros (inclusive qualquer entidade governamental ou provedor de serviço de Internet) bloqueiem ou restrinjam o acesso ao TLD em algum foro.

ARTIGO 4.

PRAZO E RESCISÃO

4.1 Prazo. O prazo deste Contrato será de dez (10) anos a partir da Data de início de vigência (conforme tal prazo possa ser ampliado de acordo com a Seção 4.2, o “Prazo”).

4.2 Renovação.

(a) Este Contrato será renovado por períodos sucessivos de dez (10) anos após o término do Prazo inicial estabelecido na Seção 4.1 e cada Prazo sucessivo, a menos que:

(i) Após aviso da ICANN ao Operador de Registro, de um descumprimento fundamental e importante dos compromissos do Operador de Registro, estabelecidos no Artigo 2 ou de uma infração de suas obrigações de pagamento, nos termos do Artigo 6 deste Contrato, sendo que tal aviso deverá especificar os detalhes da suposta infração, e se tal infração não for reparada em um prazo de trinta (30) dias consecutivos após tal aviso, (A) um árbitro ou tribunal de foro competente tenha finalmente determinado que o Operador de Registro incorreu em infração fundamental e importante de tais compromissos ou em infração de suas obrigações de pagamento, e (B) o Operador de Registro não estiver em conformidade com tal determinação e repare tal infração em um prazo de dez (10) dias consecutivos ou outro período, conforme venha a ser determinado pelo árbitro ou tribunal de foro competente; ou

(ii) Durante o Prazo então vigente, tenha sido determinado por um árbitro (nos termos da Seção 5.2 deste Contrato) ou um tribunal de foro competente que o Operador de Registro incorreu, em pelo menos três (3) ocasiões diferentes, em (A) infração fundamental e importante (reparada ou não) dos compromissos do Operador de Registro estabelecidos no Artigo 2 ou (B) infração de suas obrigações de pagamento nos termos do Artigo 6 deste Contrato.

(b) Em caso de ocorrência dos eventos estabelecidos na Seção 4.2(a) (i) ou (ii), o Contrato será rescindido no término do Prazo então vigente.

4.3 Rescisão por parte da ICANN.

(a) A ICANN poderá, mediante aviso ao Operador de Registro, rescindir este Contrato se: (i) o Operador de Registro não reparar (A) nenhuma infração

fundamental e importante das declarações e garantias do Operador de Registro estabelecidas no Artigo 1 ou dos compromissos estabelecidos no Artigo 2, ou (B) qualquer infração das obrigações de pagamento do Operador de Registro sob o Artigo 6 deste Contrato, cada um no prazo de trinta (30) dias consecutivos após a ICANN enviar um aviso ao Operador de Registro sobre tal infração, sendo que tal aviso deverá especificar os detalhes da suposta infração, (ii) um árbitro ou tribunal de foro competente finalmente decidir que o Operador de Registro incorreu em infração fundamental e importante de tal(is) compromisso(s) ou em descumprimento de suas obrigações de pagamento, e (iii) o Operador de Registro não cumprir tal decisão e não reparar tal infração em um prazo de dez (10) dias consecutivos ou outro período que possa ser determinado pelo árbitro ou tribunal de foro competente.

(b) A ICANN poderá, mediante aviso ao Operador de Registro, rescindir este Contrato se o Operador de Registro não concluir todos os testes e procedimentos (identificados pela ICANN por escrito ao Operador de Registro antes da data deste) para a autorização do TLD na zona raiz em um prazo de doze (12) meses a partir da Data de início de vigência. O Operador de Registro poderá solicitar uma extensão de até doze (12) meses adicionais para a autorização, se puder demonstrar, de modo razoavelmente satisfatório para a ICANN, que o Operador de Registro está trabalhando diligentemente e de boa-fé para concluir com sucesso as etapas necessárias para a autorização do TLD. Eventuais taxas pagas pelo Operador de Registro à ICANN antes dessa data de rescisão poderão ser integralmente retidas pela ICANN.

(c) A ICANN poderá, mediante aviso ao Operador de Registro, rescindir este Contrato se (i) o Operador de Registro não reparar uma infração importante das obrigações do Operador de Registro estabelecidas na Seção 2.12 deste Contrato em um prazo de trinta (30) dias a partir da entrega do aviso de tal infração pela ICANN, ou se o Instrumento de Operações Contínuas não estiver em vigor por mais de sessenta (60) dias consecutivos a qualquer momento após a Data de início de vigência, (ii) um árbitro ou tribunal de foro competente finalmente decidir que o Operador de Registro incorreu em descumprimento fundamental e importante de tal compromisso, e (iii) o Operador de Registro não reparar tal infração em um prazo de dez (10) dias consecutivos ou outro período que possa ser determinado pelo árbitro ou tribunal de foro competente.

(d) A ICANN poderá, mediante aviso ao Operador de Registro, rescindir este Contrato se (i) o Operador de Registro fizer uma cessão em benefício de credores ou ato similar; (ii) apreensão, penhora ou procedimentos similares sejam iniciados contra o Operador de Registro, decisões estas que sejam uma ameaça relevante à capacidade do Operador de Registro de operar o registro do TLD, e não forem extintos em até sessenta

(60) dias consecutivos após terem sido iniciados; (iii) um administrador, depositário, liquidante ou equivalente for indicado no lugar do Operador de Registro ou mantiver controle sobre quaisquer propriedades do Operador de Registro; (iv) a execução for cobrada de qualquer propriedade material do Operador de Registro que, se cobrada, possivelmente afetaria a capacidade do Operador de Registro de operar o registro do TLD;

(v) forem iniciadas decisões por parte do Operador de Registro ou contra ele, por motivo de falência, insolvência, reorganização ou outras leis relacionadas à dispensa de devedores

e tais decisões não forem extintas em até sessenta (60) dias consecutivos após terem sido iniciadas (se essas decisões forem iniciadas pelo Operador de Registro ou seus afiliados) ou cento e oitenta (180) dias consecutivos a contar do início (se essas decisões forem iniciadas por um terceiro contra o Operador de Registro); ou (vi) o Operador de Registro registrar um pedido de proteção nos termos da Lei de falências dos Estados Unidos, U.S.C. 11

Seção 101 em diante ou uma proteção equivalente de outro país ou liquidar, dissolver ou de alguma forma encerrar as operações ou a operação do TLD.

(e) A ICANN poderá, mediante aviso de trinta (30) dias consecutivos ao Operador de Registro, rescindir este Contrato de acordo com uma decisão de qualquer painel de PDDRP ou painel de RRDRP nos termos da Seção 2 da Especificação 7 ou uma decisão de qualquer painel de PICDRP nos termos da Seção 2, Seção 3 ou qualquer outra Seção aplicável da Especificação 11, sujeito ao direito do Operador de Registro de contestar tal rescisão, conforme estabelecido no procedimento aplicável descrito nas referidas Seções.

(f) A ICANN poderá, mediante aviso ao Operador de Registro, rescindir este Contrato se (i) o Operador de Registro conscientemente empregar um executivo condenado por contravenção penal relacionada a atividades financeiras ou por qualquer crime, ou for julgado por um tribunal do foro competente por ter cometido fraude ou infração de dever de lealdade, ou for objeto de uma decisão judicial que a ICANN considerar fundamentalmente equivalente a uma das infrações anteriores e tal executivo não for dispensado em um prazo de trinta (30) dias consecutivos após o Operador de Registro tomar conhecimento da(s) infração(ões); ou (ii) qualquer membro da diretoria ou órgão governante semelhante do Operador de Registro for condenado por contravenção penal relacionada a atividades financeiras ou por qualquer crime, ou for julgado por um tribunal de foro competente por ter cometido fraude ou infração de dever de lealdade, ou for objeto de uma decisão judicial que a ICANN considerar fundamentalmente equivalente a uma das infrações anteriores e tal membro não for removido da diretoria ou órgão governante semelhante do Operador de Registro em um prazo de trinta (30) dias consecutivos após o Operador de Registro tomar conhecimento da(s) infração(ões).

(g) A ICANN poderá, mediante aviso de trinta (30) dias consecutivos ao Operador de Registro, rescindir este Contrato como especificado na Seção 7.5.

(h) [Aplicável apenas a organizações intergovernamentais ou entidades governamentais.] A ICANN poderá rescindir este Contrato nos termos da Seção 7.16.

4.4 Rescisão por parte do Operador de Registro.

(a) O Operador de Registro poderá rescindir este Contrato mediante aviso à ICANN se (i) a ICANN não reparar nenhuma infração fundamental e importante dos compromissos da ICANN estabelecidos no Artigo 3 em um prazo de trinta (30) dias consecutivos após o Operador de Registro avisar à ICANN sobre tal infração, sendo que tal aviso deverá especificar os detalhes da suposta infração, (ii) um árbitro ou tribunal de foro competente finalmente decidir que a ICANN incorreu em infração fundamental e

importante de tais compromissos, e (iii) a ICANN não cumprir tal decisão e não reparar a infração em um prazo de dez (10) dias consecutivos ou outro período que possa ser determinado pelo árbitro ou tribunal de foro competente.

(b) O Operador de Registro poderá rescindir este Contrato por qualquer motivo mediante aviso prévio de cento e oitenta (180) dias consecutivos à ICANN.

4.5 Transição do registro após a rescisão do Contrato. Após a expiração do Prazo nos termos da Seção 4.1 ou Seção 4.2 ou qualquer rescisão deste Contrato nos termos da Seção 4.3 ou Seção 4.4, o Operador de Registro fornecerá à ICANN ou a qualquer operador de registro sucessor que possa ser designado pela ICANN para o TLD, em conformidade com esta Seção 4.5, todos os dados (inclusive os dados depositados em conformidade com a Seção 2.3) relacionados a operações do registro do TLD e necessários para manter as operações e funções do registro que possam ser razoavelmente solicitadas pela ICANN ou por esse operador de registro sucessor. Após consultar o Operador de Registro, a ICANN deverá decidir se passará ou não a operação do TLD a um operador de registro sucessor a seu próprio critério e em conformidade com o Processo de Transição de Registro; no entanto, a ICANN (i) levará em consideração quaisquer direitos de propriedade intelectual do Operador de Registro (conforme comunicado à ICANN pelo Operador de Registro) ao decidir se passará a operação do TLD a um operador de registro sucessor e (ii) se o Operador de Registro demonstrar, de maneira razoavelmente satisfatória para a ICANN, que (A) todos os registros de nomes de domínio no TLD são registrados para o Operador de Registro ou seus Afiliados e mantidos por eles, para seu uso exclusivo, (B) o Operador de Registro não vender, distribuir nem transferir o controle ou uso de nenhum registro no TLD para terceiros que não sejam um Afiliado do Operador de Registro e (C) a operação de transição do TLD não for necessária para proteger o interesse público, então, a ICANN não poderá passar a operação a um operador de registro sucessor após a expiração ou rescisão deste Contrato sem o consentimento do Operador de Registro (que não deverá ser indevidamente recusado, limitado ou postergado). Para evitar dúvidas, a frase anterior não proibirá a ICANN de autorizar o TLD de acordo com um processo de solicitação futuro para a autorização de domínios de primeiro nível, sujeito a quaisquer processos e procedimentos de contestação instituídos pela ICANN em conexão com tal processo de solicitação com o objetivo de proteger os direitos de terceiros. O Operador de Registro concorda que a ICANN poderá fazer qualquer alteração que considerar necessária no banco de dados da IANA com relação ao TLD em caso de transição do TLD de acordo com esta Seção 4.5. Além disso, a ICANN ou seu representante reterá e poderá fazer valer seus direitos nos termos do Instrumento de Operações Contínuas para a manutenção e operação do TLD, independentemente do motivo de rescisão ou expiração deste Contrato.

[Texto alternativo da Seção 4.5 Transição do registro após a rescisão do Contrato para organizações intergovernamentais ou entidades governamentais, ou outras circunstâncias especiais:

“Transição do registro após a rescisão do Contrato. Após a expiração do Prazo nos termos da Seção 4.1 ou Seção 4.2 ou qualquer rescisão deste Contrato nos termos da Seção 4.3 ou Seção 4.4, em conexão com a designação por parte da ICANN de um operador

de registro sucessor do TLD, o Operador de Registro e a ICANN concordam em consultar um ao outro e trabalhar cooperativamente para facilitar e implementar a transição do TLD em conformidade com esta Seção 4.5. Após consultar o Operador de Registro, a ICANN decidirá se passará ou não a operação do TLD a um operador de registro sucessor, a seu próprio critério, e em conformidade com o Processo de Transição de Registro. Caso a ICANN decida passar a operação do TLD a um operador de registro sucessor, com o consentimento do Operador de Registro (que não deverá ser indevidamente recusado, limitado ou postergado), o Operador de Registro fornecerá à ICANN ou a qualquer operador de registro sucessor do TLD todos os dados relacionados a operações do TLD e necessários para manter as operações e funções do registro que possam ser razoavelmente solicitados pela ICANN ou por esse operador de registro sucessor, além dos dados depositados de acordo com a Seção 2.3 deste documento. Caso o Operador de Registro não aceite fornecer tais dados, os dados de registro relacionados ao TLD deverão ser devolvidos ao Operador de Registro, a menos que acordado de outra forma entre as partes. O Operador de Registro concorda que a ICANN poderá fazer qualquer alteração que considerar necessária no banco de dados da IANA com relação ao TLD em caso de transição do TLD de acordo com esta Seção 4.5. Além disso, a ICANN ou seu representante reterão e poderão fazer valer seus direitos nos termos do Instrumento de Operações Contínuas, independentemente do motivo de rescisão ou expiração deste Contrato.”]

4.6 Efeito da rescisão. Após a expiração do Prazo ou rescisão deste Contrato, as obrigações e direitos das partes deste instrumento cessarão, desde que tal expiração ou rescisão deste Contrato não exonerem as partes de nenhuma obrigação ou infração deste Contrato acumuladas antes de tal expiração ou rescisão, inclusive, entre outras, todas as obrigações de pagamento acumuladas decorrentes do Artigo 6. Além disso, o Artigo 5, Artigo 7, Seção 2.12, Seção 4.5 e esta Seção 4.6 sobreviverão à expiração ou rescisão deste Contrato. Para evitar dúvidas, os direitos do Operador de Registro de operar o registro para o TLD cessarão imediatamente após a expiração do Prazo ou rescisão deste Contrato.

ARTIGO 5.

RESOLUÇÃO DE DISPUTAS

5.1 Mediação. No caso de surgir qualquer disputa nos termos deste Contrato ou em conexão com ele, antes que qualquer parte possa iniciar arbitragem segundo a

Seção 5.2 abaixo, a ICANN e o Operador de Registro deverão tentar resolver a disputa por meio de mediação em conformidade com os seguintes termos e condições:

(a) Uma parte submeterá uma disputa a mediação mediante aviso por escrito à outra parte. A mediação será realizada por um único mediador selecionado pelas partes. Se as partes não chegarem a um acordo sobre o mediador em um prazo de quinze

(15) dias consecutivos após a entrega do aviso por escrito, de acordo com esta Seção 5.1, as partes selecionarão imediatamente uma entidade mediadora mutuamente aceitável, que, assim que possível e após a seleção dessa entidade, nomeará um mediador, que será um advogado licenciado com conhecimento geral sobre direito contratual e, na medida do necessário para mediar a disputa em particular, conhecimento geral do sistema de nomes

de domínio. Qualquer mediador deverá confirmar por escrito que não é e não se tornará, durante o período da mediação, funcionário, sócio, diretor executivo, executivo ou detentor de valores mobiliários da ICANN nem do Operador de Registro. Se essa confirmação não for fornecida pelo mediador nomeado, um mediador substituto será nomeado de acordo com esta Seção 5.1(a).

(b) O mediador realizará a mediação de acordo com as regras e os procedimentos que determinar após consultar as partes. As partes discutirão a disputa de boa-fé e tentarão, com a ajuda do mediador, alcançar uma resolução amigável para a disputa. A mediação deverá ser tratada como uma discussão de liquidação e, portanto, deverá ser confidencial e não poderá ser utilizada contra nenhuma das partes em procedimentos posteriores relacionados à disputa, inclusive qualquer arbitragem segundo a Seção 5.2. O mediador não poderá testemunhar a favor de nenhuma das partes em procedimentos posteriores relacionados com a disputa.

(c) Cada parte arcará com suas próprias custas da mediação. As partes dividirão igualmente as taxas e as despesas do mediador. Cada uma das partes deverá tratar as informações recebidas da outra parte de acordo com a mediação e que estiverem marcadas adequadamente como confidenciais (conforme estabelecido na Seção 7.15) como Informações confidenciais da outra parte, em conformidade com a Seção 7.15.

(d) Se as partes participarem de boa-fé da mediação, mas não resolverem a disputa por qualquer motivo, qualquer uma das partes ou o mediador poderão encerrar a mediação a qualquer momento e a disputa será encaminhada para arbitragem de acordo com a Seção 5.2 abaixo. Se as partes não resolverem a disputa por qualquer motivo em um prazo de noventa (90) dias consecutivos após a data do aviso entregue conforme a

Seção 5.1(a), a mediação será automaticamente encerrada (a menos que seja prorrogada por acordo entre as partes) e a disputa será encaminhada para arbitragem de acordo com a Seção 5.2 abaixo.

5.2 Arbitragem. As disputas que surgirem nos termos deste contrato ou em conexão com ele que não forem resolvidas de acordo com a Seção 5.1, inclusive as solicitações de desempenho específico, serão resolvidas por meio de arbitragem vinculativa, realizada conforme as regras da Corte Internacional de Arbitragem da Câmara de Comércio Internacional (a “ICC”). A arbitragem será realizada em inglês e ocorrerá no condado de Los Angeles, Califórnia, EUA. Qualquer arbitragem será perante um único árbitro, a menos (i) que a ICANN esteja buscando danos punitivos ou exemplares, ou sanções operacionais, (ii) que as partes concordem por escrito com um número maior de árbitros, ou (iii) que a disputa ocorra nos termos da Seção 7.6 ou 7.7. No caso das cláusulas (i), (ii) ou (iii) do parágrafo anterior, a arbitragem será realizada por três árbitros, sendo que cada parte indicará um árbitro a ser confirmado pela ICC e os dois árbitros selecionados indicarão o terceiro árbitro a ser confirmado pela ICC. Para uma arbitragem realizada por um único árbitro, o Operador de Registro e a ICANN poderão, por acordo mútuo, indicar o árbitro, a ser confirmado pela ICC. Se as partes não indicarem um único árbitro ou, no caso de arbitragem de três árbitros, se cada parte não indicar um árbitro, em cada caso dentro de trinta (30) dias consecutivos a contar da data em que a parte solicitou

a arbitragem e a solicitação foi recebida pela outra parte, ou dentro de uma prorrogação de tempo que poderá ser permitida pela Secretaria da Corte da ICC, o(s) árbitro(s) deverá(ão) ser indicado(s) pela ICC. Se qualquer um dos árbitros indicados não for confirmado pela ICC, a parte ou as pessoas que indicaram esse árbitro deverão indicar imediatamente um árbitro substituto para ser confirmado pela ICC. A fim de agilizar a arbitragem e limitar os custos, o(s) árbitro(s) deverá(ão) estabelecer limites de páginas para a apresentação de documentos das partes em conjunto com a arbitragem e, se o(s) árbitro(s) determinar(em) que é necessária uma audiência, esta será limitada a um (1) dia consecutivo, desde que em qualquer arbitragem em que a ICANN esteja buscando danos punitivos ou exemplares, ou sanções operacionais, a audiência possa ser estendida para um (1) dia adicional consecutivo se acordado pelas partes ou ordenado pelo(s) árbitro(s) com base na determinação independente do(s) árbitro(s) ou na solicitação razoável de uma das partes deste instrumento. A parte favorecida na arbitragem terá o direito de recuperar os custos e taxas advocatícias razoáveis, que o(s) árbitro(s) incluirá(ão) no julgamento. Se a arbitragem determinar que o Operador de Registro esteve repetida e deliberadamente em violação fundamental e relevante de suas obrigações estabelecidas no Artigo 2, Artigo 6 ou Seção 5.4 deste Contrato, a ICANN poderá solicitar dos árbitros o julgamento de danos punitivos ou exemplares ou sanções operacionais (inclusive sem limitação uma ordem restringindo temporariamente os direitos do Operador de Registro de vender novos registros). Cada uma das partes deverá tratar as informações recebidas da outra parte segundo a arbitragem que esteja marcada adequadamente como confidencial (conforme estabelecido na Seção 7.15) como Informação confidencial da outra parte em conformidade com a Seção 7.15. Para qualquer litígio que envolva a ICANN em relação a este Contrato, o local e o foro exclusivo para tal litígio serão um tribunal localizado no condado de Los Angeles, Califórnia, EUA; entretanto, as partes também terão o direito de fazer valer um parecer desse tribunal em qualquer tribunal de foro competente.

[Texto alternativo da Seção 5.2 Arbitragem para organizações intergovernamentais ou entidades governamentais, ou outras circunstâncias especiais:

“Arbitragem. As disputas que surgirem nos termos deste contrato ou em conexão com ele que não forem resolvidas de acordo com a Seção 5.1, inclusive as solicitações de desempenho específico, serão resolvidas por meio de arbitragem vinculativa, realizada conforme as regras da Corte Internacional de Arbitragem da Câmara de Comércio Internacional (a “ICC”). A arbitragem será realizada em inglês e ocorrerá em Genebra, Suíça, exceto se outra localidade for mutuamente acordada entre o Operador de Registro e a ICANN. Qualquer arbitragem será perante um único árbitro, a menos (i) que a ICANN esteja buscando danos punitivos ou exemplares, ou sanções operacionais, (ii) que as partes concordem por escrito com um número maior de árbitros, ou (iii) que a disputa ocorra nos termos da Seção 7.6 ou 7.7. No caso das cláusulas (i), (ii) ou (iii) do parágrafo anterior, a arbitragem será realizada por três árbitros, sendo que cada parte indicará um árbitro a ser confirmado pela ICC e os dois árbitros selecionados indicarão o terceiro árbitro a ser confirmado pela ICC. Para uma arbitragem realizada por um único árbitro, o Operador de Registro e a ICANN poderão, por acordo mútuo, indicar o árbitro, a ser confirmado pela ICC. Se as partes não indicarem um único árbitro ou, no caso de arbitragem de três árbitros, se cada parte não indicar um árbitro, em cada caso dentro de trinta (30) dias consecutivos a

contar da data em que a parte solicitou a arbitragem e a solicitação foi recebida pela outra parte, ou dentro de uma prorrogação de tempo que poderá ser permitida pela Secretaria da Corte da ICC, o(s) árbitro(s) deverá(ão) ser indicado(s) pela ICC. Se qualquer um dos árbitros indicados não for confirmado pela ICC, a parte ou as pessoas que indicaram esse árbitro deverão indicar imediatamente um árbitro substituto para ser confirmado pela ICC. A fim de agilizar a arbitragem e limitar os custos, o(s) árbitro(s) deverá(ão) estabelecer limites de páginas para a apresentação de documentos das partes em conjunto com a arbitragem e, se o(s) árbitro(s) determinar(em) que é necessária uma audiência, esta será limitada a um (1) dia consecutivo, desde que em qualquer arbitragem em que a ICANN esteja buscando danos punitivos ou exemplares, ou sanções operacionais, a audiência possa ser estendida para um (1) dia adicional consecutivo se acordado pelas partes ou ordenado pelo(s) árbitro(s) com base na determinação independente do(s) árbitro(s) ou na solicitação razoável de uma das partes deste instrumento. A parte favorecida na arbitragem terá o direito de recuperar os custos e taxas advocatícias razoáveis, que o(s) árbitro(s) incluirá(ão) no julgamento. Se a arbitragem determinar que o Operador de Registro esteve repetida e deliberadamente em violação fundamental e relevante de suas obrigações estabelecidas no Artigo 2, Artigo 6 ou Seção 5.4 deste Contrato, a ICANN poderá solicitar dos árbitros o julgamento de danos punitivos ou exemplares ou sanções operacionais (inclusive sem limitação uma ordem restringindo temporariamente os direitos do Operador de Registro de vender novos registros). Cada uma das partes deverá tratar as informações recebidas da outra parte segundo a arbitragem que esteja marcada adequadamente como confidencial (conforme estabelecido na Seção 7.15) como Informação confidencial da outra parte em conformidade com a Seção 7.15. Para qualquer litígio que envolva a ICANN em relação a este Contrato, o local e o foro exclusivo para tal litígio serão um tribunal localizado em Genebra, Suíça, exceto se outro local for mutuamente acordado pelo Operador de Registro e a ICANN; entretanto, as partes também terão o direito de fazer valer um parecer desse tribunal em qualquer tribunal de foro competente.”]

5.3 Limitação de responsabilidade. A responsabilidade monetária agregada da ICANN por infrações deste Contrato não deverá exceder um valor igual às Taxas do nível do registro pagas pelo Operador de Registro à ICANN no período anterior de doze meses de acordo com este Contrato (exceto a Taxa variável do nível do registro estabelecida na Seção 6.3, se houver). A responsabilidade monetária agregada do Operador de Registro perante a ICANN por infrações deste Contrato será limitada a um montante igual às taxas pagas para a ICANN durante o período anterior de doze meses (exceto a Taxa variável do nível do registro estabelecida na Seção 6.3, se houver), e danos punitivos e exemplares, se houver, concedidos de acordo com a Seção 5.2, exceto com relação às obrigações

indenizatórias do Operador de Registro segundo a Seção 7.1 e a Seção 7.2. Em nenhum caso as partes serão responsáveis por danos especiais, punitivos, exemplares ou consequentes, decorrentes ou em conexão com este Contrato, ou pela execução ou falta de execução de obrigações assumidas neste Contrato, exceto o que estabelece a Seção 5.2. Salvo disposição em contrário neste Contrato, nenhuma das partes assume qualquer garantia, expressa ou implícita, com relação aos serviços prestados por si mesma, seus funcionários ou agentes, ou aos resultados obtidos de seus trabalhos, inclusive, entre outras, qualquer garantia implícita de comercialização, não infração ou adequação para uma finalidade em especial.

5.4 Execução específica. O Operador de Registro e a ICANN concordam que poderão ocorrer danos irreparáveis se qualquer uma das cláusulas deste Contrato não for executada em conformidade com seus termos específicos. Da mesma forma, as partes concordam que cada uma terá o direito de requerer a um árbitro ou tribunal de foro competente uma execução específica dos termos deste Contrato (adicionalmente a qualquer outra reparação a que cada parte tenha direito).

ARTIGO 6.

TAXAS

6.1 Taxas do nível do registro.

(a) O Operador de Registro pagará à ICANN uma taxa do nível do registro igual (i) à taxa de registro fixa de US$ 6.250 por trimestre e (ii) à taxa de transação do nível do registro (coletivamente, as “Taxas do nível do registro”). A taxa de transação do nível do registro será igual ao número de incrementos anuais de um registro inicial ou renovado de nome de domínio (em um ou mais níveis e inclusive renovações associadas com transferências de um registrador credenciado pela ICANN para outro, sendo cada um uma “Transação”) durante o trimestre aplicável multiplicado por US$ 0,25; no entanto, a taxa de transação do nível do registro não será aplicada até que e a menos que tenham ocorrido

50.000 transações no TLD em qualquer trimestre ou quaisquer quatro trimestres consecutivos no agregado (o “Limite de transações”) e será aplicada a cada Transação que ocorrer em cada trimestre em que o Limite de transações seja atingido, mas não será aplicada a cada trimestre em que o Limite de transações não tenha sido atingido. A obrigação do Operador de Registro de pagar a taxa trimestral fixa do nível do registro iniciará na data em que o TLD for autorizado no DNS ao Operador de Registro. O primeiro pagamento trimestral da taxa fixa do nível do registro será proporcional ao número de dias consecutivos entre a data de autorização e o fim do trimestre em que recai a data de autorização.

(b) Sujeito à Seção 6.1(a), o Operador de Registro pagará as Taxas do nível do registro trimestralmente em uma conta designada pela ICANN em um prazo de trinta (30) dias consecutivos após a data da fatura fornecida pela ICANN.

6.2 Recuperação de custos para RSTEP. As solicitações do Operador de Registro de aprovação de Serviços adicionais de acordo com a Seção 2.1 poderão ser encaminhadas pela ICANN ao RSTEP (Registry Services Technical Evaluation Panel, Painel de Avaliação Técnica de Serviços de Registros) nos termos do respectivo processo, disponível em xxxxx://xxx.xxxxx.xxx/xxxx. Caso tais solicitações sejam encaminhadas ao RSTEP, o Operador de Registro remeterá à ICANN o custo faturado da revisão do RSTEP em um prazo de catorze (14) dias consecutivos após o RSTEP receber uma cópia da fatura da ICANN, a menos que a ICANN decida, a seu exclusivo e absoluto critério, arcar com o custo faturado de tal revisão do RSTEP, no todo ou em parte.

6.3 Taxa variável do nível do registro.

(a) Se os registradores credenciados pela ICANN (levando em conta, no agregado, o pagamento de dois terços de todas as taxas do nível do registro, ou a parte dos registradores credenciados pela ICANN necessária para aprovar taxas variáveis de credenciamento nos termos do contrato de credenciamento de registrador vigente no momento) não aprovarem, de acordo com os termos de seus contratos de credenciamento de registrador com a ICANN, as taxas variáveis de credenciamento estabelecidas pela Diretoria da ICANN referente a qualquer exercício financeiro da ICANN, após a entrega de um aviso da ICANN, o Operador de Registro pagará à ICANN uma taxa variável do nível do registro, que poderá ser paga trimestralmente e aumentará no início do primeiro trimestre fiscal de tal exercício financeiro da ICANN (a “Taxa variável do nível do registro”). A taxa será calculada e faturada pela ICANN trimestralmente e será paga pelo Operador de Registro em um prazo de sessenta (60) dias consecutivos em relação ao primeiro trimestre do exercício financeiro da ICANN e em um prazo de vinte (20) dias consecutivos em relação a cada trimestre remanescente do exercício financeiro da ICANN, após o recebimento do montante faturado pela ICANN. O Operador de Registro poderá faturar e cobrar as Taxas variáveis do nível do registro dos registradores que constituam uma das partes em um Contrato entre Registro e Registrador com o Operador de Registro (sendo que tal contrato pode especificamente prever o reembolso de Taxas variáveis do nível do registro pagas pelo Operador de Registro de acordo com a Seção 6.3); as taxas deverão ser cobradas a todos os registradores credenciados pela ICANN caso sejam cobradas de algum deles. A Taxa variável do nível do registro, caso possa ser cobrada pela ICANN, será uma obrigação do Operador de Registro e deverá ser paga conforme previsto nesta Seção 6.3, independentemente da capacidade do Operador de Registro de solicitar e obter reembolso de tal taxa dos registradores. No caso de a ICANN cobrar mais tarde taxas variáveis de credenciamento pelas quais o Operador de Registro tenha pago à ICANN uma taxa variável do nível do registro, a ICANN deverá reembolsar ao Operador de Registro um montante apropriado da Taxa variável do nível do registro, conforme razoavelmente determinado pela ICANN. Se os registradores credenciados pela ICANN (como um grupo) aprovarem, de acordo com os termos de seus contratos de credenciamento de registrador com a ICANN, as taxas variáveis de credenciamento estabelecidas pela Diretoria da ICANN para um exercício financeiro, a ICANN não terá direito a uma taxa variável do nível do registro nos termos deste Contrato para tal exercício financeiro, independentemente de os registradores credenciados pela ICANN cumprirem ou não suas obrigações de pagamento à ICANN durante tal exercício financeiro.

(b) O montante da Taxa variável do nível do registro será especificado para cada registrador e poderá incluir um componente por registrador e um componente transacional. O componente por registrador da Taxa variável do nível do registro será especificado pela ICANN de acordo com o orçamento adotado pela Diretoria da ICANN para cada exercício financeiro da ICANN. O componente transacional da Taxa variável do nível do registro será especificado pela ICANN de acordo com o orçamento adotado pela Diretoria da ICANN para cada exercício financeiro da ICANN, mas não deverá ultrapassar US$ 0,25 por registro de nome de domínio (inclusive renovações associadas a transferências de um registrador credenciado pela ICANN para outro) por ano.

6.4 Taxas de repasse. O Operador de Registro pagará à ICANN (i) uma taxa única no valor de US$ 5.000 pelo acesso e uso do Centro de Informações de Marcas, conforme descrito na Especificação 7 (a “Taxa de acesso a RPMs”) e (ii) US$ 0,25 por Registro de Período Experimental e Registro de Reivindicações (conforme tais termos são usados nos RPMs do Centro de Informações de Marcas, aqui incorporados de acordo com a Especificação 7) (a “Taxa de registro de RPMs”). A taxa de acesso a RPMs será faturada na Data de início de vigência deste Contrato, e o Operador de Registro pagará a taxa em uma conta especificada pela ICANN em um prazo de trinta (30) dias consecutivos após a data da fatura. A ICANN cobrará do Operador de Registro trimestralmente a taxa de registro de RPMs, que deverá ser paga de acordo com o procedimento de pagamento e faturamento especificado na Seção 6.1.

6.5 Ajustes de taxas. Apesar das limitações de taxas estabelecidas neste Artigo 6, com início após o término do primeiro ano deste Contrato e após o término de

cada ano desde então durante o Prazo, as taxas então correntes, estabelecidas na Seção 6.1 e Seção 6.3, poderão ser ajustadas, a critério da ICANN, em um percentual equivalente à variação percentual, se houver, (i) do Índice de preços ao consumidor para todos os consumidores urbanos, média das cidades norte-americanas (1982-1984 = 100), publicado pelo Departamento do Trabalho dos Estados Unidos, Agência de Estatísticas Trabalhistas, ou de qualquer índice sucessor (o “CPI”) para o mês que for um (1) mês antes do início do ano aplicável, ou (ii) do CPI publicado para o mês que for um (1) mês antes do início do ano imediatamente anterior. Em caso de tal aumento, a ICANN enviará um aviso ao Operador de Registro especificando o montante de tal ajuste. Qualquer ajuste de taxa nos termos desta Seção 6.5 entrará em vigor no primeiro dia do primeiro trimestre do ano após transcorridos pelo menos trinta (30) dias desde a entrega do aviso da ICANN sobre o ajuste da taxa ao Operador de Registro.

6.6 Taxa adicional para pagamentos atrasados. Para pagamentos atrasados trinta (30) dias consecutivos ou mais, nos termos deste Contrato, o Operador de Registro deverá pagar uma taxa adicional sobre pagamentos atrasados de 1,5% ao mês ou, se menos, a taxa máxima permitida pela legislação aplicável.

6.7 Isenção de redução de taxas. A critério exclusivo da ICANN, esta poderá reduzir o valor das taxas de registro a pagar, constantes deste documento, pelo Operador de Registro, referentes a qualquer período (“Isenção de redução de taxas”). Tal Isenção de redução de taxas poderá, conforme determinado pela ICANN a seu critério exclusivo, ser

(a) de duração limitada e (b) condicionada à aceitação por parte do Operador de Registro dos termos e condições estabelecidos em tal isenção. Uma Isenção de redução de taxas não entrará em vigor a menos que seja executada por escrito pela ICANN conforme estabelecido na Seção 7.6(i). A ICANN enviará ao Operador de Registro um aviso sobre a Isenção de redução de taxas de acordo com a Seção 7.9.

ARTIGO 7.

DISPOSIÇÕES GERAIS

7.1 Indenização da ICANN.

(a) O Operador de Registro deverá indenizar e defender a ICANN e seus diretores, executivos, funcionários e agentes (coletivamente, “Indenizados”) de toda e qualquer alegação, danos, responsabilidades, custos e despesas, inclusive taxas e despesas jurídicas razoáveis, decorrentes ou relacionadas a direitos de propriedade intelectual com respeito ao TLD, a autorização do TLD ao Operador de Registro, à operação de registro do Operador de Registro do TLD ou à prestação de Serviços de registro do Operador de Registro; o Operador de Registro não será obrigado a reembolsar nem defender nenhum Indenizado na medida em que tais alegações, danos, responsabilidade, custos ou despesas sejam decorrentes: (i) de ações ou omissões da ICANN, seus subcontratados, painelistas ou avaliadores especificamente relacionadas com o processo de solicitação do TLD do registro e que ocorram durante tal processo (exceto ações ou omissões solicitadas pelo Operador de Registro ou em benefício deste), ou (ii) de uma infração por parte da ICANN de qualquer obrigação contida neste Contrato ou qualquer má conduta intencional da ICANN. Esta Seção não deverá ser considerada como obrigação do Operador de Registro de reembolsar ou indenizar de outra forma a ICANN por custos associados à negociação ou execução deste Contrato, ou à monitoração ou administração das respectivas obrigações das partes constituintes deste Contrato. Além disso, esta Seção não se aplicará a nenhuma solicitação de honorários advocatícios em conexão com qualquer litígio ou arbitragem entre as partes, os quais serão regidos pelo Artigo 5 ou concedidos de outra forma por um tribunal ou árbitro de foro competente.

[Texto alternativo da Seção 7.1(a) para organizações intergovernamentais ou entidades governamentais:

“O Operador de Registro deverá envidar seus melhores esforços e cooperar com a ICANN para assegurar que a ICANN não incorra em quaisquer custos associados a alegações, danos, responsabilidades, custos e despesas, inclusive taxas e despesas jurídicas razoáveis, decorrentes ou relacionadas a direitos de propriedade intelectual com respeito ao TLD, a autorização do TLD para o Operador de Registro, a operação de registro do Operador de Registro para o TLD ou a prestação de Serviços de registro do Operador de Registro; o Operador de Registro não será obrigado a prestar tal cooperação na medida em que tais alegações, danos, responsabilidade, custos ou despesas sejam decorrentes de uma infração por parte da ICANN de qualquer uma de suas obrigações contidas neste Contrato ou de qualquer má conduta intencional da ICANN. Esta Seção não deverá ser considerada como obrigação do Operador de Registro de reembolsar ou indenizar de outra forma a ICANN por custos associados à negociação ou execução deste Contrato, ou à monitoração ou administração das respectivas obrigações das partes constituintes deste Contrato. Além disso, esta Seção não se aplicará a nenhuma solicitação de honorários advocatícios em conexão com qualquer litígio ou arbitragem entre as partes, os quais serão regidos pelo Artigo 5 ou concedidos de outra forma por um tribunal ou árbitro de foro competente.”]

(b) Em quaisquer reivindicações de indenização da ICANN nas quais diversos operadores de registro (inclusive o Operador de Registro) estiverem envolvidos nas mesmas ações ou omissões que tenham suscitado a reivindicação, a responsabilidade agregada do Operador de Registro de indenizar a ICANN com relação a tal reivindicação será limitada a um percentual do total de reivindicações da ICANN, calculado dividindo-se o número total de nomes de domínio registrados junto ao Operador de Registro no TLD (cujos nomes registrados serão calculados de acordo com o Artigo 6 deste Contrato para qualquer trimestre aplicável) pelo número total de nomes de domínio registrados em todos os domínios de primeiro nível nos quais os operadores de registro estiverem envolvidos nas mesmas ações ou omissões que suscitaram tal reivindicação. A fim de reduzir a responsabilidade do Operador de Registro nos termos da Seção 7.1(a) e de acordo com esta Seção 7.1(b), o Operador de Registro terá o ônus de identificar os outros operadores de registro envolvidos nas mesmas ações ou omissões que suscitaram a reivindicação e de demonstrar, de maneira razoavelmente satisfatória para a ICANN, a culpabilidade desses outros operadores de registro por tais ações ou omissões. A fim de evitar dúvidas, caso um operador de registro esteja envolvido nas mesmas ações ou omissões que suscitaram as reivindicações, mas tal operador de registro não tenha as mesmas obrigações de indenização para com a ICANN ou semelhantes, conforme estabelecido na Seção 7.1(a) acima, o número de domínios gerenciados por tal operador de registro não será incluído no cálculo referido na frase anterior. [Observação: esta Seção 7.1(b) não se aplica a organizações intergovernamentais ou entidades governamentais.]

7.2 Procedimentos de indenização. Se for iniciada alguma alegação de terceiro que seja indenizado nos termos da Seção 7.1 acima, a ICANN enviará um aviso ao Operador de Registro tão logo quanto possível. O Operador de Registro terá direito, se assim o decidir e comunicar mediante um aviso prontamente entregue à ICANN, de assumir imediatamente o controle da defesa e investigação de tal alegação e de empregar e envolver advogados que sejam razoavelmente aceitáveis para a ICANN para assumir o caso e defendê-la, às expensas do Operador de Registro; em todos os casos, a ICANN terá o direito de controlar às suas próprias expensas o litígio de questões relacionadas à validade ou interpretação das políticas, Estatuto ou conduta da ICANN. A ICANN cooperará, às expensas do Operador de Registro, em todos os aspectos razoáveis com o Operador de Registro e seus advogados na investigação, julgamento e defesa de tal alegação e qualquer apelação dela decorrente, e poderá participar, às suas próprias expensas, por meio de seus advogados ou de outra forma, de tal investigação, julgamento e defesa de tal alegação e qualquer apelação dela decorrente. Nenhuma quitação de uma alegação que envolva uma reparação que afete a ICANN e que não seja o pagamento de quantias em um montante que seja totalmente indenizável pelo Operador de Registro será firmada sem o consentimento da ICANN. Se o Operador de Registro não assumir o controle total sobre a defesa de uma alegação sujeito a tal defesa de acordo com esta Seção 7.2, a ICANN terá o direito de defender a reivindicação na forma que considerar apropriada, às expensas do Operador de Registro, e o Operador de Registro cooperará com a defesa. [Observação: esta Seção 7.2 não se aplica a organizações intergovernamentais ou entidades governamentais.]

7.3 Termos definidos. Para os fins deste Contrato, exceto se tais definições forem alteradas nos termos de uma Política Consensual no futuro, em cujo caso as

seguintes definições deverão ser consideradas alteradas e consolidadas em sua totalidade, conforme estabelecido em tal Política Consensual, os termos Segurança e Estabilidade serão definidos da seguinte maneira:

(a) Para os fins deste Contrato, afetar a “Segurança” significará (1) a divulgação, alteração, inserção ou destruição não autorizadas de dados de registro, ou (2) o acesso ou divulgação não autorizados de informações ou recursos na Internet por sistemas que estejam em operação de acordo com todas as normas aplicáveis.

(b) Para os fins deste Contrato, afetar a “Estabilidade” se referirá a (1) falta de conformidade com normas relevantes aplicáveis que sejam oficiais e publicadas por um órgão de normatização da Internet bem estabelecido e reconhecido, como o

Standards-Track correspondente ou Best Current Practice Requests for Comments (“RFCs”) patrocinado pela Força-tarefa de Engenharia da Internet; ou (2) a criação de uma condição que afete negativamente a taxa de transferência, tempo de resposta, consistência ou coerência de respostas para os servidores da Internet ou sistemas finais que operam em conformidade com as normas relevantes aplicáveis que sejam oficiais e publicadas por um órgão de normalização da Internet bem estabelecido e reconhecido, como o Standards- Track correspondente ou Best Current Practice RFCs, e contando com as informações delegadas do Operador de Registro ou provisionamento de serviços.

7.4 Sem compensação. Todos os pagamentos efetuados nos termos deste Contrato serão feitos pontualmente durante todo o Prazo e não obstante a pendência de qualquer disputa (monetária ou de outro tipo) entre o Operador de Registro e a ICANN.

7.5 Alteração de controle, cessão e subcontratação. Salvo o disposto nesta Seção 7.5, nenhuma das partes poderá ceder algum de seus direitos e obrigações constantes deste Contrato sem aprovação prévia por escrito da outra parte, a qual não deverá ser indevidamente recusada. Para os fins desta Seção 7.5, uma alteração direta ou indireta de controle do Operador de Registro ou qualquer disposição de subcontratação relacionada a qualquer Função crítica (conforme definido na Seção 6 da Especificação 10) para o TLD (uma “Disposição de subcontratação importante”) será considerada como sendo uma cessão.

(a) O Operador de Registro deverá fornecer à ICANN um aviso prévio de pelo menos trinta (30) dias consecutivos sobre qualquer cessão ou Disposição de subcontratação importante, e qualquer acordo para ceder ou subcontratar qualquer parte das operações do TLD (seja ou não uma Disposição de subcontratação importante) deverá exigir conformidade com todos os compromissos, obrigações e disposições do Operador de Registro nos termos deste Contrato, e o Operador de Registro continuará vinculado a tais compromissos, obrigações e disposições. O Operador de Registro também deverá fornecer um aviso prévio de pelo menos trinta (30) dias consecutivos à ICANN antes de consumar qualquer transação prevista para ter como resultado uma alteração direta ou indireta de controle de Operador de Registro.

(b) Em um prazo de trinta (30) dias consecutivos a partir de qualquer um desses avisos, de acordo com a Seção 7.5(a), a ICANN poderá solicitar outras informações ao Operador de Registro, estabelecendo (i) conformidade com este Contrato e (ii) que a parte que adquire tal controle ou celebra tal cessão ou Disposição de subcontratação importante (em qualquer um dos casos, a “Parte contratante”) e a entidade controladora final da Parte contratante cumprem a especificação ou política adotada pela ICANN sobre critérios de operador de registro então em vigor (inclusive com relação a recursos financeiros e operacionais e capacidades técnicas), em cujo caso o Operador de Registro deverá fornecer as informações solicitadas em um prazo de quinze (15) dias consecutivos.

(c) O Operador de Registro concorda que o consentimento da ICANN para qualquer cessão, mudança de controle ou Disposição de subcontratação importante também estará sujeito a verificações de antecedentes sobre qualquer Parte contratante proposta (e Afiliados dessa Parte contratante).

(d) Se a ICANN não fornecer expressamente ou recusar o consentimento para qualquer cessão, mudança direta ou indireta de controle de Operador de Registro ou qualquer Disposição de subcontratação importante em um prazo de trinta (30) dias consecutivos a partir da data em que a ICANN receber o aviso de tal transação (ou, se a ICANN tiver solicitado outras informações ao Operador de Registro, conforme estabelecido acima, trinta (30) dias consecutivos a partir do recebimento por escrito de todas as informações solicitadas com referência à tal transação) do Operador de Registro, será considerado que a ICANN consentiu tal transação.

(e) Em conexão com essa cessão, alteração de controle ou Disposição de subcontratação importante, o Operador de Registro deverá estar em conformidade com o Processo de Transição de Registro.

(f) Não obstante o acima exposto, (i) as alterações de controle consumadas não poderão ser anuladas pela ICANN; entretanto, se a ICANN razoavelmente decidir recusar seu consentimento a tal transação, a ICANN poderá rescindir este Contrato nos termos da Seção 4.3(g), (ii) a ICANN poderá ceder os direitos deste Contrato sem o consentimento do Operador de Registro após a aprovação da Diretoria da ICANN em conjunto com uma reorganização, reconstituição ou mudança na personalidade jurídica da ICANN após a aceitação expressa de tal cessionário dos termos e condições deste Contrato, (iii) o Operador de Registro poderá ceder os direitos deste Contrato sem o consentimento da ICANN diretamente a um Cessionário afiliado, conforme este termo se encontra definido abaixo, após a aceitação expressa de tal subsidiária Cessionário afiliado ou empresa controladora, conforme o caso, por escrito dos termos e condições deste Contrato, e (iv) será considerado que a ICANN consentiu qualquer transação de cessão, Disposição de subcontratação importante ou alteração de controle na qual a Parte contratante seja um operador existente de um domínio genérico de primeiro nível de acordo com um contrato de registro entre tal Parte contratante e a ICANN (desde que tal Parte Contratante esteja então em conformidade com os termos e condições de tal contrato de registro em todos os aspectos importantes), a menos que a ICANN forneça ao Operador de Registro uma objeção por escrito a tal transação em um prazo de dez (10) dias consecutivos a partir da data em que a ICANN receber o aviso sobre tal transação de acordo com esta Seção 7.5. Não obstante a Seção 7.5(a), no caso de uma cessão de direitos nos termos das cláusulas (ii) ou (iii) desta Seção 7.5(f), a parte cedente fornecerá à outra parte um aviso imediato após tal cessão de direitos. Para os fins desta Seção 7.5(f), (A) “Cessionário afiliado” refere-se a uma pessoa ou entidade que, direta ou indiretamente, por

meio de um ou mais intermediários, controla, é controlada ou está sob controle comum com a pessoa ou entidade especificada, e (B) “controle” (inclusive os termos “controlado” e “sob controle comum”) terão o mesmo significado especificado na Seção 2.9(c) deste Contrato.

7.6 Aditamentos e renúncias.

(a) Se a Diretoria da ICANN determinar que é desejável um aditamento a este Contrato (inclusive as Especificações referidas neste instrumento) e a todos os outros contratos de registro entre a ICANN e os Operadores de Registro aplicáveis (os “Contratos de Registro Aplicáveis”) (sendo, cada um, um “Aditamento especial”), a ICANN poderá adotar um Aditamento especial de acordo com as exigências e o processo estabelecidos nesta Seção 7.6; o Aditamento especial não será um Aditamento restrito.

(b) Antes de apresentar um Aditamento especial para aprovação do Operador de Registro, a ICANN deverá primeiro consultar de boa-fé o Grupo de Trabalho quanto à forma e ao conteúdo de tal Aditamento especial. A duração dessa consulta será razoavelmente determinada pela ICANN com base no conteúdo do Aditamento especial. Após essa consulta, a ICANN poderá propor a adoção de um Aditamento especial disponibilizando publicamente esse aditamento no próprio site por no mínimo trinta (30) dias consecutivos (o “Período de publicação”) e fornecendo aviso sobre esse aditamento proposto aos Operadores de Registro Aplicáveis de acordo com a Seção 7.9. A ICANN analisará os comentários públicos enviados sobre um Aditamento especial durante o Período de publicação (inclusive comentários enviados pelos Operadores de Registro Aplicáveis).

(c) Se, em um prazo de cento e oitenta (180) dias consecutivos após o término do Período de publicação (o “Período de aprovação”), a Diretoria da ICANN aprovar um Aditamento especial (que poderá estar em uma forma diferente da enviada para comentários públicos, mas deverá abordar o objeto do Aditamento especial disponibilizado para comentários públicos, modificado de maneira a refletir e/ou abordar as contribuições do Grupo de Trabalho e comentários públicos), a ICANN fornecerá um aviso e enviará esse Aditamento especial para aprovação ou rejeição dos Operadores de Registro Aplicáveis. Se, durante o período de sessenta (60) dias consecutivos após a ICANN fornecer esse aviso aos Operadores de Registro Aplicáveis, esse Aditamento especial receber a Aprovação dos Operadores de Registro, esse Aditamento especial será considerado aprovado (“Aditamento aprovado”) pelos Operadores de Registro Aplicáveis, e entrará em vigor e será considerado como um aditamento a este Contrato na data correspondente a sessenta (60) dias consecutivos após a ICANN fornecer ao Operador de Registro o aviso de aprovação desse Aditamento aprovado (“Data de início da vigência do aditamento”). Caso o Aditamento especial não receba a Aprovação dos Operadores de Registro, ele será considerado não aprovado pelos Operadores de Registro Aplicáveis (“Aditamento rejeitado”). Um Aditamento rejeitado não afetará os termos e as condições deste Contrato, exceto conforme disposto abaixo.

(d) Se a Diretoria da ICANN determinar razoavelmente que um Aditamento rejeitado se enquadra nas categorias de matéria estabelecidas na Seção 1.2 da Especificação 1, a Diretoria da ICANN poderá adotar uma resolução (a data em que tal resolução é adotada é referida neste instrumento como a “Data de adoção da resolução”) solicitando um Relatório de Assunto (conforme definido no Estatuto da ICANN) da Organização de Apoio a Nomes Genéricos (“GNSO”) com relação ao conteúdo de tal Aditamento rejeitado. O processo de desenvolvimento de políticas realizado pela GNSO de acordo com tal Relatório de Assunto solicitado é referido no presente instrumento como “PDP”. Se esse PDP resultar em um Relatório Final apoiado pela maioria qualificada da GNSO (conforme definido no Estatuto da ICANN) que (i) recomende a adoção do Aditamento rejeitado como Política Consensual ou (ii) não recomende a adoção do Aditamento rejeitado como Política Consensual, e, no caso de (i) acima, a Diretoria adotar essa Política Consensual, o Operador de Registro cumprirá suas obrigações de acordo com a Seção 2.2 deste Contrato. Em ambos os casos, a ICANN abandonará o Aditamento rejeitado e isso não afetará os termos e as condições deste Contrato. Não obstante as disposições precedentes desta Seção 7.6(d), a Diretoria da ICANN não será obrigada a iniciar um PDP com relação ao Aditamento rejeitado se, a qualquer momento durante o período de doze (12) meses anterior ao envio desse Aditamento rejeitado para a Aprovação dos Operadores de Registro de acordo com a Seção 7.6(c), a matéria desse Aditamento rejeitado for a mesma de um PDP já concluído, ou de outra forma abandonado ou encerrado, que não tenha resultado em uma recomendação da GNSO por maioria qualificada.

(e) Se (a) um Aditamento rejeitado não se enquadrar nas categorias de matéria estabelecidas na Seção 1.2 da Especificação 1, (b) a matéria de um Aditamento rejeitado for, a qualquer momento durante o período de doze (12) meses anterior ao envio desse Aditamento rejeitado para a Aprovação dos Operadores de Registro de acordo com a Seção 7.6(c), a mesma de um PDP já concluído, ou de outra forma abandonado ou encerrado, que não tenha resultado em uma recomendação da GNSO por maioria qualificada, ou (c) um PDP não resultar em um Relatório Final apoiado pela maioria qualificada da GNSO que (A) recomende a adoção do Aditamento rejeitado como Política Consensual ou (B) não recomende a adoção do Aditamento rejeitado como Política Consensual (ou caso esse PDP tenha sido abandonado ou encerrado por qualquer motivo), então, em qualquer um desses casos, esse Aditamento rejeitado ainda poderá ser adotado e entrar em vigor da maneira descrita abaixo. Para que o Aditamento rejeitado seja adotado, deverão ser atendidos os seguintes requisitos:

(i) a matéria do Aditamento rejeitado deverá estar no escopo da missão da ICANN e ser coerente com uma aplicação equilibrada de seus valores essenciais (conforme descrito no Estatuto da ICANN);

(ii) o Aditamento rejeitado deverá ser justificado por um Motivo substancial e convincente de interesse público, ter probabilidade de promover esse interesse, considerando os interesses públicos e privados concorrentes que provavelmente serão afetados pelo Aditamento rejeitado, e ser elaborado de maneira limitada, sem ser mais amplo que o razoavelmente

necessário para abordar esse Motivo substancial e convincente de interesse público;

(iii) na medida que o Aditamento rejeitado proibir ou exigir conduta ou atividades, impuser custos significativos aos Operadores de Registro Aplicáveis e/ou reduzir consideravelmente o acesso público a serviços de nomes de domínio, o Aditamento rejeitado deverá ser o menos restritivo possível a fim de abordar o Motivo substancial e convincente de interesse público;

(iv) a Diretoria da ICANN deverá enviar o Aditamento rejeitado, junto com uma explicação por escrito do motivo relacionado à sua determinação de que o Aditamento rejeitado atende aos requisitos estabelecidos nas subcláusulas (i) a (iii) acima, para comentários públicos por um período de pelo menos trinta (30) dias consecutivos; e

(v) após esse período de comentários públicos, a Diretoria da ICANN deverá (a) fazer uma consulta (ou solicitar à gerência da ICANN que faça uma consulta) ao Grupo de Trabalho, aos especialistas na matéria, aos membros da GNSO, aos comitês consultivos relevantes e outras partes interessadas com relação ao Aditamento rejeitado por um período de pelo menos sessenta (60) dias consecutivos; e (b) após essa consulta, aprovar novamente o Aditamento rejeitado (que poderá estar em uma forma diferente da enviada para a Aprovação dos Operadores de Registro, mas deverá abordar a matéria do Aditamento rejeitado, modificado de maneira a refletir e/ou abordar as informações fornecidas pelo Grupo de Trabalho e comentários públicos) com o voto positivo de pelo menos dois terços dos membros da Diretoria da ICANN qualificados para votar sobre essa matéria, levando em consideração qualquer política da ICANN que afete essa qualificação, inclusive a Política de Conflito de Interesses da ICANN (um “Aditamento da Diretoria”).

Esse Aditamento da Diretoria será considerado, sujeito à Seção 7.6(f), um Aditamento aprovado, e entrará em vigor e será considerado um aditamento a este Contrato na data correspondente a sessenta (60) dias consecutivos após a data em que a ICANN enviar o aviso sobre a aprovação desse Aditamento da Diretoria ao Operador de Registro (essa data de início da vigência será considerada a Data de início da vigência do aditamento nos termos deste Contrato). Não obstante o precedente, o Aditamento da Diretoria não poderá aditar as taxas de registro cobradas pela ICANN de acordo com este instrumento nem aditar esta Seção 7.6.

(f) Não obstante o disposto na Seção 7.6(e), o Aditamento da Diretoria não será considerado um Aditamento aprovado se, durante o período de trinta (30) dias consecutivos após a Diretoria da ICANN aprovar o Aditamento da Diretoria, o Grupo de Trabalho, em nome dos Operadores de Registro Aplicáveis, enviar à Diretoria da ICANN

uma alternativa ao Aditamento da Diretoria (“Aditamento alternativo”) que atenda aos

seguintes requisitos:

(i) estabelece o texto preciso proposto pelo Grupo de Trabalho para aditar este Contrato em substituição ao Aditamento da Diretoria;

(ii) aborda o Motivo substancial e convincente de interesse público identificado pela Diretoria da ICANN como a justificativa para o Aditamento da Diretoria; e

(iii) em comparação com o Aditamento da Diretoria: (a) é elaborado de maneira mais limitada a fim de abordar esse Motivo substancial e convincente de interesse público, e (b) na medida em que o Aditamento alternativo proibir ou exigir conduta ou atividades, impuser custos significativos aos Operadores de Registro Afetados ou reduzir significativamente o acesso a serviços de nomes de domínio, constitui um meio menos restritivo de abordar o Motivo substancial e convincente de interesse público.

(A) o Aditamento alternativo não receber a Aprovação dos Operadores de Registro em um prazo de trinta (30) dias consecutivos após o envio desse Aditamento alternativo aos Operadores de Registro Aplicáveis (e o Grupo de Trabalho avisará a ICANN sobre a data desse envio), ou (B) a Diretoria da ICANN rejeitar o Aditamento alternativo por uma votação de dois terços de seus membros, o Aditamento da Diretoria (e não o Aditamento alternativo) entrará em vigor e será considerado como um aditamento a este Contrato na data correspondente a sessenta (60) dias consecutivos após a data em que a ICANN fornecer o aviso ao Operador de Registro (cuja data de início da vigência será considerada a Data de início da vigência do aditamento nos termos deste Contrato). Se a Diretoria da

ICANN rejeitar um Aditamento alternativo, a diretoria publicará por escrito uma justificativa indicando sua análise dos critérios estabelecidos nas Seções 7.6(f)(i) a 7.6(f)(iii). A capacidade da Diretoria da ICANN de rejeitar um Aditamento alternativo nos termos deste Contrato não anula a obrigação da Diretoria de garantir que qualquer Aditamento da Diretoria atenda aos critérios estabelecidos nas Seções 7.6(e)(i) a 7.6(e)(v).

(g) Caso o Operador de Registro acredite que um Aditamento aprovado não atende aos requisitos relevantes previstos nesta Seção 7.6 ou que foi adotado em infração a qualquer uma das cláusulas processuais desta Seção 7.6, o Operador de Registro poderá contestar a adoção desse Aditamento especial de acordo com as cláusulas para a resolução de disputas estabelecidas no Artigo 5, exceto pelo fato de que essa arbitragem deverá ser realizada por um tribunal de arbitragem composto por três pessoas. Qualquer contestação dessa natureza deverá ser indicada em até sessenta (60) dias consecutivos após a data em que a ICANN fornecer o aviso ao Operador de Registro sobre o Aditamento aprovado, e a ICANN poderá unir todas as contestações levantadas pelos operadores de registro (inclusive o Operador de Registro) em um único processo judicial. O Aditamento aprovado será desconsiderado como aditamento a este Contrato durante a pendência do processo de resolução de disputas.

(h) O Operador de Registro poderá solicitar por escrito à ICANN uma isenção do Aditamento aprovado (sendo cada solicitação enviada pelo Operador de Registro nos termos deste Contrato uma “Solicitação de isenção”) durante o período de trinta (30) dias consecutivos após a data em que a ICANN fornecer o aviso ao Operador de Registro sobre esse Aditamento aprovado. Cada Solicitação de isenção estabelecerá a base para essa solicitação e fornecerá apoio detalhado para uma isenção ao Aditamento aprovado. A Solicitação de isenção também poderá incluir uma descrição detalhada e apoio a qualquer alternativa ou variação do Aditamento aprovado proposta por esse Operador de Registro. Uma Solicitação de isenção só poderá ser concedida mediante uma demonstração clara e convincente por parte do Operador de Registro de que a conformidade com o Aditamento aprovado representa um conflito com a legislação pertinente ou causaria um efeito negativo considerável sobre a condição financeira em longo prazo ou sobre os resultados das operações do Operador de Registro. Nenhuma Solicitação de isenção será concedida se a ICANN determinar que, a seu critério razoável, a aceitação dessa Solicitação de isenção seria significativamente prejudicial para os registrantes ou resultaria na negação de um benefício direto para os registrantes. Em um prazo de noventa (90) dias consecutivos após a ICANN receber uma Solicitação de isenção, a ICANN aprovará (sendo que tal aprovação poderá estar condicionada ou consistir em alternativas ou uma variação do Aditamento aprovado) ou rejeitará a Solicitação de isenção por escrito; durante esse período, o Aditamento aprovado não será considerado um aditamento a este Contrato. Se a Solicitação de isenção for aprovada pela ICANN, o Aditamento aprovado não alterará este Contrato; quaisquer condições, alternativas ou variações do Aditamento aprovado exigidas pela ICANN entrarão em vigor e, na medida em que forem aplicáveis, aditarão este Contrato a partir da Data de início da vigência do aditamento. Se essa Solicitação de isenção for rejeitada pela ICANN, o Aditamento aprovado aditará este Contrato a partir da Data de início da vigência do aditamento (ou, se essa data já tiver transcorrido, tal Aditamento aprovado será considerado em vigor imediatamente na data da rejeição); o Operador de

Registro poderá, em um prazo de trinta (30) dias consecutivos após o recebimento da decisão da ICANN, recorrer da decisão da ICANN de rejeitar a Solicitação de isenção de acordo com os procedimentos para resolução de disputas dispostos no Artigo 5. O Aditamento aprovado será desconsiderado como aditamento a este Contrato durante a pendência do processo de resolução de disputas. Para evitar dúvidas, apenas as Solicitações de isenção submetidas pelo Operador de Registro que forem aprovadas pela ICANN nos termos desta Seção 7.6(j), acordadas pela ICANN após mediação nos termos da Seção 5.1 ou por uma decisão de arbitragem nos termos da Seção 5.2 isentarão o Operador de Registro de qualquer Aditamento aprovado, e nenhuma Solicitação de isenção concedida a qualquer outro Operador de Registro Aplicável (seja pela ICANN ou por meio de arbitragem) terá qualquer efeito nos termos deste Contrato nem isentará o Operador de Registro de qualquer Aditamento aprovado.

(i) Exceto conforme estabelecido nesta Seção 7.6 e na Seção 7.7, e de outra maneira disposto neste Contrato e respectivas Especificações, nenhum aditamento, suplemento ou modificação deste Contrato nem nenhuma cláusula deste será vinculativa, a menos que executada por escrito por ambas as partes, e nada nesta Seção 7.6 ou na

Seção 7.7 impedirá a ICANN e o Operador de Registro de firmar modificações ou aditamentos bilaterais a este Contrato, negociados exclusivamente entre as duas partes. Nenhuma renúncia a nenhuma cláusula deste Contrato será vinculativa, a menos que evidenciada por meio de documento escrito e assinado pela parte que renuncia à conformidade com tal cláusula. Nenhuma renúncia a nenhuma das cláusulas deste Contrato ou a não aplicação das cláusulas deste será considerada ou constituirá uma renúncia a nenhuma outra cláusula deste instrumento, assim como nenhuma renúncia dessa natureza constituirá uma renúncia continuada, a menos que seja disposto expressamente o contrário. Para evitar dúvidas, nada nesta Seção 7.6 ou na Seção 7.7 será considerado um limite à obrigação do Operador de Registro de agir de acordo com a Seção 2.2.

(j) Para os fins desta Seção 7.6, os termos a seguir terão os seguintes

significados:

(i) “Operadores de Registro Aplicáveis” refere-se, coletivamente, aos operadores de registro da parte de domínios de primeiro nível em um contrato de registro que contenha uma cláusula similar a esta Seção 7.6, inclusive o Operador de Registro.

(ii) “Aprovação dos Operadores de Registro” refere-se ao recebimento de uma das seguintes aprovações: (A) a aprovação favorável dos Operadores de Registro Aplicáveis cujos pagamentos à ICANN sejam responsáveis por dois terços do valor total das taxas (convertido em dólares norte-americanos, se aplicável, à taxa de câmbio vigente publicada no dia anterior na edição norte-americana do Wall Street Journal para a data em que tal cálculo é feito pela ICANN) pagas à ICANN por todos os Operadores de Registro Aplicáveis durante o ano-calendário imediatamente anterior nos termos dos Contratos de Registro Aplicáveis, e (B) a aprovação favorável da maioria dos Operadores de Registro Aplicáveis no momento em que tal

aprovação for obtida. Para evitar dúvidas, com relação à cláusula (B), cada Operador de Registro Aplicável deverá ter um voto para cada domínio de primeiro nível operado por tal Operador de Registro de acordo com um Contrato de Registro Aplicável.

(iii) “Aditamento restrito” refere-se ao seguinte: (A) um aditamento da Especificação 1, (B) exceto no que trata a Seção 2.10 deste Contrato, um aditamento que especifica o preço cobrado pelo Operador de Registro aos registradores para registros de nomes de domínio, (C) um aditamento à definição de Serviços de registro, conforme estabelecido no primeiro parágrafo da Seção 2.1 da Especificação 6, ou (D) um aditamento à duração do Prazo.

(iv) “Motivo substancial e convincente de interesse público” refere- se a um motivo justificado por um objetivo de interesse público importante, específico e articulado que esteja no escopo da missão da ICANN e seja coerente com uma aplicação equilibrada dos valores essenciais da ICANN, conforme definido no Estatuto da ICANN.

(v) “Grupo de Trabalho” refere-se aos representantes dos Operadores de Registro Aplicáveis e outros membros da comunidade indicados periodicamente pelo Grupo de Partes Interessadas de Registros a fim de servir como um grupo de trabalho para consultoria sobre aditamentos aos Contratos de Registro Aplicáveis (exceto aditamentos bilaterais nos termos da Seção 7.6(i)).

(k) Não obstante qualquer disposição em contrário nesta Seção 7.6, (i) se o Operador de Registro fornecer provas razoavelmente satisfatórias à ICANN de que o Aditamento aprovado aumentaria significativamente o custo da prestação de Serviços de registro, a ICANN concederá até cento e oitenta (180) dias consecutivos para o Aditamento aprovado entrar em vigor para o Operador de Registro, e (ii) nenhum Aditamento aprovado adotado conforme a Seção 7.6 entrará em vigor para o Operador de Registro se o Operador de Registro fornecer à ICANN um aviso irrevogável de rescisão nos termos da Seção 4.4(b).

7.7 Processo de negociação.

(a) Se o diretor geral da ICANN (“CEO”) ou o presidente do Grupo de Partes Interessadas de Registros (“Presidente”) desejarem discutir qualquer revisão deste Contrato, o CEO ou o Presidente, conforme o caso, fornecerá à outra parte um aviso por escrito dispondo em detalhes razoáveis as revisões propostas para este Contrato (um “Aviso de negociação”). Não obstante o precedente, nem o CEO nem o Presidente poderão

(i) propor revisões deste Contrato que modifiquem qualquer Política Consensual existente no momento, (ii) propor revisões deste Contrato de acordo com esta Seção 7.7 até o dia 30 de junho de 2014, ou (iii) propor revisões ou enviar um Aviso de negociação mais de uma vez durante qualquer período de doze (12) meses a partir de 1º de julho de 2014.

(b) Após o recebimento do Aviso de negociação pelo CEO ou pelo Presidente, a ICANN e o Grupo de Trabalho (conforme definido na Seção 7.6) iniciarão negociações de boa-fé relacionadas à forma e ao conteúdo das revisões propostas para este Contrato, as quais poderão ser feitas na forma de um aditamento proposto para este Contrato (“Revisões propostas”), por um período de pelo menos noventa (90) dias consecutivos (a menos que seja obtida uma resolução antes disso) e tentarão obter um acordo mutuamente aceitável com relação às Revisões propostas (“Período de discussão”).

(c) Se, após a conclusão do Período de discussão, for obtido um acordo para as Revisões propostas, a ICANN publicará as Revisões propostas mutuamente acordadas em seu site para comentários públicos por pelo menos trinta (30) dias consecutivos (“Período de publicação”) e fornecerá um aviso sobre essas revisões a todos os Operadores de Registro Aplicáveis de acordo com a Seção 7.9. A ICANN e o Grupo de Trabalho analisarão os comentários públicos enviados sobre as Revisões propostas durante o Período de publicação (incluindo comentários enviados pelos Operadores de Registro Aplicáveis). Após a conclusão do Período de publicação, as Revisões propostas serão enviadas para a Aprovação dos Operadores de Registro (conforme definido na Seção 7.6) e da Diretoria da ICANN. Se forem obtidas essas aprovações, as Revisões propostas serão consideradas um Aditamento aprovado (conforme definido na Seção 7.6) pelos Operadores de Registro Aplicáveis e a ICANN, e entrará em vigor e será considerado

um aditamento a este Contrato em sessenta (60) dias consecutivos após o envio de aviso da ICANN ao Operador de Registro.

(d) Se, após a conclusão do Período de discussão, um acordo não for alcançado entre a ICANN e o Grupo de Trabalho sobre as Revisões propostas, o CEO ou o Presidente poderá enviar à outra parte um aviso por escrito (“Aviso de mediação”) solicitando que cada parte tente resolver os desacordos relacionados às Revisões propostas por meio de uma mediação imparcial e facilitadora (não avaliativa), de acordo com os termos e as condições dispostas abaixo. Caso seja enviado o Aviso de mediação, a ICANN e o Grupo de Trabalho deverão, em um prazo de quinze (15) dias consecutivos, publicar simultaneamente o texto de sua versão desejada das Revisões propostas e um documento explicando sua posição com relação a elas no site da ICANN.

(i) A mediação será realizada por um único mediador selecionado pelas partes. Se as partes não chegarem a um acordo sobre um mediador em um prazo de quinze (15) dias consecutivos após o CEO ou o Presidente, conforme o caso, receber o Aviso de mediação, as partes selecionarão imediatamente uma entidade mediadora mutuamente aceitável, que, assim que possível e após a seleção dessa entidade, nomeará um mediador, que será um advogado licenciado com conhecimento geral sobre direito contratual e sem nenhuma relação comercial em andamento com qualquer uma das partes e, na medida do necessário para mediar a disputa em particular, conhecimento geral do sistema de nomes de domínio. Qualquer mediador deverá confirmar por escrito que não é e não se tornará, durante o período da mediação, funcionário, sócio, diretor executivo, executivo ou detentor de valores mobiliários da ICANN nem de um Operador de Registro

Aplicável. Se essa confirmação não for fornecida pelo mediador nomeado, um mediador substituto será nomeado de acordo com esta Seção 7.7(d)(i).

(ii) O mediador realizará a mediação de acordo com as regras e os procedimentos da mediação facilitadora que determinar após consultar as partes. As partes discutirão a disputa de boa-fé e tentarão, com a ajuda do mediador, alcançar uma resolução amigável para a disputa.

(iii) Cada parte arcará com suas próprias custas da mediação. As partes dividirão igualmente as taxas e as despesas do mediador.

(iv) Se for alcançado um acordo durante a mediação, a ICANN publicará as Revisões propostas mutuamente acordadas em seu site para o Período de publicação e fornecerá aviso a todos os Operadores de Registro Aplicáveis de acordo com a Seção 7.9. A ICANN e o Grupo de Trabalho analisarão os comentários públicos enviados sobre as Revisões propostas acordadas durante o Período de publicação (inclusive comentários enviados pelos Operadores de Registro Aplicáveis). Após a conclusão do Período de publicação, as Revisões propostas serão enviados para a Aprovação dos Operadores de Registro e da Diretoria da ICANN. Se forem obtidas essas aprovações, as Revisões propostas serão consideradas um Aditamento aprovado (conforme definido na Seção 7.6) pelos Operadores de Registro Aplicáveis e a ICANN, e entrará em vigor e será considerado um aditamento a este Contrato em sessenta (60) dias consecutivos após o envio de aviso da ICANN ao Operador de Registro.

(v) Se as partes não resolverem a disputa por algum motivo até a data correspondente a noventa (90) dias consecutivos após o CEO ou o Presidente, conforme o caso, receber o Aviso de mediação, a mediação será encerrada imediatamente (a menos que seja prorrogada por acordo das partes). O mediador entregará às partes uma definição das questões que poderiam ser analisadas em uma arbitragem futura, se solicitada. Essas questões estão sujeitas às limitações estabelecidas na Seção 7.7(e)(ii) abaixo.

(e) Se, após a mediação, a ICANN e o Grupo de Trabalho não chegarem a um acordo sobre as Revisões propostas, o CEO ou o Presidente poderá enviar à outra parte um aviso por escrito (“Aviso de arbitragem”) solicitando que a ICANN e os Operadores de Registro Aplicáveis resolvam a disputa por meio de arbitragem vinculativa de acordo com as cláusulas de arbitragem da Seção 5.2, sujeito aos requisitos e às limitações desta

Seção 7.7(e).

(i) Se for enviado um Aviso de arbitragem, a definição das questões do mediador, juntamente com as Revisões propostas (sejam elas da ICANN, do Grupo de Trabalho ou de ambos), será publicada para comentários públicos no site da ICANN por um período de o mínimo trinta (30) dias consecutivos. A ICANN e o Grupo de Trabalho analisarão os comentários

públicos enviados sobre as Revisões propostas durante o Período de publicação (inclusive comentários enviados pelos Operadores de Registro Aplicáveis), e as informações relacionadas a esses comentários e análise serão fornecidas a um painel de arbitragem composto por três (3) pessoas. Cada parte poderá modificar suas Revisões propostas antes e depois do Período de publicação. O procedimento de arbitragem não poderá começar antes do fechamento desse período de comentários públicos, e a ICANN poderá unir todas as contestações levantadas pelos operadores de registro (inclusive o Operador de Registro) em um único procedimento. Exceto conforme disposto nesta Seção 7.7, a arbitragem será realizada de acordo com a Seção 5.2.

(ii) Nenhuma disputa referente às Revisões propostas poderá ser enviada para arbitragem na medida em que a matéria das Revisões propostas

(i) esteja relacionada à Política Consensual, (ii) se enquadre nas categorias de matéria estabelecidas na Seção 1.2 da Especificação 1, ou (iii) tenha como objetivo aditar qualquer uma das seguintes cláusulas ou Especificações deste Contrato: Artigos 1, 3 e 6; Seções 2.1, 2.2, 2.5, 2.7, 2.9, 2.10, 2.16, 2.17, 2.19, 4.1, 4.2, 7.3, 7.6, 7.7, 7.8, 7.10, 7.11, 7.12, 7.13, 7.14, 7.16; Seção 2.8 e Especificação 7 (mas apenas na medida em que tais Revisões propostas busquem implementar um RPM não contemplado nas Seções 2.8 e Especificação 7); Documento A; e Especificações 1, 4, 6, 10 e 11.

(iii) O mediador apresentará um resumo ao painel de arbitragem com relação às respectivas propostas da ICANN e do Grupo de Trabalho referentes às Revisões propostas.

(iv) Nenhum aditamento a este Contrato relacionado às Revisões propostas poderá ser enviado para arbitragem pelo Grupo de Trabalho nem pela ICANN, a menos que, no caso do Grupo de Trabalho, o aditamento proposto tenha recebido a Aprovação dos Operadores de Registro e, no caso da ICANN, o aditamento proposto tenha sido aprovado pela Diretoria da ICANN.

(v) Para que o painel de arbitragem aprove o aditamento proposto da ICANN ou do Grupo de Trabalho relacionado às Revisões propostas, o painel de arbitragem deverá concluir que esse aditamento proposto é coerente com uma aplicação equilibrada dos valores essenciais da ICANN (conforme descrito no Estatuto da ICANN) e razoável considerando a relação custo-benefício para os interesses comerciais dos Operadores de Registro Aplicáveis e da ICANN (conforme o caso), e o benefício público almejado com as Revisões propostas conforme disposto nesse aditamento. Se o painel de arbitragem concluir que o aditamento proposto pela ICANN ou pelo Grupo de Trabalho referente às Revisões propostas atende ao padrão mencionado acima, esse aditamento entrará em vigor e será considerado como tal para este Contrato sessenta (60) dias consecutivos após a ICANN enviar um aviso

ao Operador de Registro e será considerado um Aditamento aprovado nos termos deste instrumento.

(f) Com relação a um Aditamento aprovado referente a um aditamento proposto pela ICANN, o Registro poderá solicitar por escrito à ICANN uma isenção desse aditamento conforme as cláusulas da Seção 7.6.

(g) Não obstante qualquer disposição em contrário nesta Seção 7.7, (a) se o Operador de Registro fornecer provas razoavelmente satisfatórias para a ICANN de que o Aditamento aprovado aumentaria significativamente o custo da prestação de Serviços de registro, a ICANN concederá até cento e oitenta (180) dias consecutivos para o Aditamento aprovado entrar em vigor para o Operador de Registro, e (b) nenhum Aditamento aprovado adotado conforme a Seção 7.7 entrará em vigor para o Operador de Registro se este fornecer à ICANN um aviso irrevogável de rescisão nos termos da Seção 4.4(b).

7.8 Sem terceiros beneficiários. Este Contrato não será interpretado de modo a criar nenhuma obrigação da ICANN nem do Operador de Registro para com qualquer outra parte não constituinte deste Contrato, inclusive qualquer registrador ou titular de nome registrado.

7.9 Avisos gerais. Com exceção dos avisos de acordo com as Seções 7.6 e 7.7, todos os avisos que forem fornecidos nos termos deste Contrato ou em relação a ele serão enviados (i) por escrito no endereço da parte apropriada, conforme estabelecido abaixo, ou

(ii) por fax ou correio eletrônico, conforme disposto abaixo, a menos que a parte tenha enviado uma notificação de mudança de endereço postal, e-mail ou número de fax, conforme definido neste Contrato. Todos os avisos de acordo com as Seções 7.6 e 7.7 deverão ser fornecidos através da publicação das informações aplicáveis no site da ICANN e da transmissão dessas informações ao Operador de Registro por correio eletrônico. Qualquer alteração nas informações de contato para aviso indicadas abaixo será fornecida pela parte em um prazo de trinta (30) dias consecutivos após tal alteração. Exceto os avisos nos termos da Seção 7.6 ou 7.7, qualquer aviso exigido pelo presente Contrato será considerado como tendo sido adequadamente fornecido (i) se em papel, quando entregue pessoalmente ou por serviço de mensageiro com confirmação de recebimento ou (ii) se por correio eletrônico, após a confirmação de recebimento pelo servidor de e-mail do destinatário, desde que tal aviso seja acompanhado por uma cópia enviada por correio em um prazo de 3 (três) dias consecutivos. Qualquer aviso exigido pelas Seções 7.6 ou 7.7 será considerado como tendo sido fornecido quando publicado eletronicamente no site da ICANN e após a confirmação de recebimento pelo servidor de e-mail. Caso outros meios de comunicação se tornem viáveis, como avisos por meio de um site seguro, as partes trabalharão juntas para implementar tal meio de comunicação nos termos deste Contrato.

Se for para a ICANN, o endereço de destino é:

Internet Corporation for Assigned Names and Numbers 00000 Xxxxxxxxxx Xxxxx, Xxxxx 000

Xxx Xxxxxxx, XX 00000-0000 EUA

Telefone: x0-000-000-0000

Aos cuidados de: Presidente e CEO Com cópia para: Diretor jurídico

E-mail: (Conforme especificado periodicamente.)

Se for destinado ao Operador de Registro, endereçado a: [ ]

[ ]

Telefone:

Com cópia para:

E-mail: (Conforme especificado periodicamente.)

7.10 Contrato completo. Este Contrato (inclusive as especificações e documentos incorporados por referência a URLs que fazem parte dele) constitui a totalidade do contrato entre as partes do presente relativas à operação do TLD e substitui todos os acordos, entendimentos, negociações e discussões anteriores, tanto verbais como por escrito, entre as partes sobre o assunto.

7.11 Prevalência do idioma inglês. Independentemente de qualquer versão traduzida deste Contrato e/ou especificações que possam ser fornecidas ao Operador de Registro, a versão original em inglês deste Contrato e de todas as especificações referidas é a versão oficial que vincula as partes. Caso haja qualquer conflito ou discrepância entre qualquer versão traduzida deste Contrato e a versão original em inglês, prevalecerá a versão em inglês. Os avisos, designações, decisões e especificações feitos nos termos deste Contrato estarão no idioma inglês.

7.12 Direitos de propriedade. Nada do que consta neste Contrato deverá ser interpretado como (a) o estabelecimento ou a concessão ao Operador de Registro de quaisquer direitos de propriedade ou interesses do Operador de Registro sobre o TLD ou sobre as letras, palavras, símbolos ou outros caracteres que compõem a cadeia de caracteres de TLD, ou (b) um impacto negativo sobre quaisquer direitos de propriedade intelectual ou de propriedade existentes do Operador de Registro.

7.13 Autonomia; conflitos com a legislação. O presente Contrato será considerado independente; a invalidade ou inaplicabilidade de qualquer termo ou cláusula do presente Contrato não afetará a validade nem a aplicabilidade do conjunto do presente Contrato ou de qualquer outro termo deste, que permanecerá em pleno vigor e efeito. Se qualquer uma das cláusulas deste Contrato for considerada inválida ou inaplicável, as partes deverão negociar, de boa-fé, as modificações a este Contrato no intuito de efetivar a intenção original das partes, tanto quanto possível. A ICANN e o Grupo de Trabalho cooperarão mutuamente para desenvolver um procedimento de revisão e análise da ICANN de supostos conflitos de leis aplicáveis e cláusulas não relacionadas ao RDDS deste Contrato (conforme definido na Especificação 4). Até que esse

procedimento seja desenvolvido e implementado, a ICANN revisará e analisará supostos conflitos de leis aplicáveis e cláusulas não relacionadas ao RDDS deste Contrato de maneira semelhante ao procedimento da ICANN para tratar os conflitos do WHOIS com leis de privacidade.

7.14 Ordens judiciais. A ICANN respeitará qualquer decisão de um tribunal de foro competente, inclusive qualquer ordem de qualquer foro no qual o consentimento ou a não objeção do governo seja um requisito para a delegação do TLD. Não obstante qualquer outra cláusula deste Contrato, a implementação por parte da ICANN de tal ordem não constituirá uma infração do presente Contrato.

7.15 Confidencialidade

(a) Nos termos da Seção 7.15(c), durante o Prazo e por um período de 3 (três) anos após o respectivo término, cada uma das partes fará com que seus administradores, diretores, funcionários e agentes, assim como os de seus Afiliados, mantenham sigilo e não publiquem nem divulguem a terceiros, direta ou indiretamente, qualquer informação que a parte divulgadora tenha marcado ou de outra forma designado por escrito à parte destinatária como “segredo comercial confidencial”, “informações comerciais confidenciais” ou “informações financeiras confidenciais” (coletivamente, “Informações confidenciais”), salvo na medida em que tal divulgação seja permitida nos termos deste Contrato.

(b) As obrigações de confidencialidade impostas pela Seção 7.15(a) não se aplicam a nenhuma Informação confidencial que (i) seja ou que doravante se torne parte do domínio público por uso público, publicação, conhecimentos gerais ou similar, sem culpa da parte destinatária de incorrer em infração a este Contrato, (ii) possa ser demonstrada por documentação ou outra prova competente que se encontrava na posse da parte destinatária antes da divulgação pela parte divulgadora sem qualquer obrigação de confidencialidade em relação a tal informação, (iii) seja posteriormente recebida pela parte destinatária de um terceiro sem vínculo com qualquer obrigação de confidencialidade com relação a tal informação, (iv) tenha sido publicada por um terceiro ou tenha passado de outra forma ao domínio público sem culpa da parte destinatária, ou (v) possa ser demonstrada por documentação ou outra prova competente que foi desenvolvida de modo independente por ou para a parte destinatária, sem referência às Informações confidenciais da parte divulgadora.

(c) Cada parte terá o direito de divulgar informações confidenciais, na medida em que essa divulgação seja (i) feita em resposta a uma ordem válida de um tribunal de foro competente ou, se na opinião razoável da assessoria jurídica da parte destinatária, tal divulgação for de outra forma exigida pela legislação aplicável; no entanto, a parte destinatária avisará primeiro a parte divulgadora e dará à parte divulgadora uma oportunidade razoável para anular essa ordem ou obter uma ordem de proteção ou ordem de tratamento confidencial exigindo que as Informações confidenciais objeto de tal ordem ou outra legislação aplicável sejam mantidas em sigilo por tal tribunal ou outro terceiro destinatário, a menos que a parte destinatária não seja autorizada a fornecer tal aviso de

acordo com tal ordem ou legislação aplicável, ou (ii) feita pela parte destinatária ou qualquer de seus Afiliados aos próprios procuradores, auditores, assessores, consultores, contratados ou outros terceiros para uso por tal pessoa ou entidade conforme possa ser necessária ou útil em conexão com o desempenho das atividades nos termos deste Contrato, desde que o terceiro esteja vinculado a obrigações de confidencialidade no mínimo tão rigorosas como as aqui estabelecidas, seja por acordo escrito ou por meio de normas de responsabilidade profissional.

[Observação: a seção a seguir aplica-se apenas a organizações intergovernamentais ou entidades governamentais.]

7.16 Cláusula especial referente a organizações intergovernamentais ou entidades governamentais.

(a) A ICANN reconhece que o Operador de Registro é uma entidade sujeita ao direito internacional público, incluindo os tratados internacionais aplicáveis ao Operador de Registro (como o direito e os tratados públicos internacionais, doravante coletivamente denominados “legislação aplicável”). Nada do que consta no presente Contrato e em suas especificações relacionadas deverá ser interpretado de modo a exigir que o Operador de Registro infrinja a legislação aplicável ou impeça seu cumprimento. As partes concordam que a conformidade do Operador de Registro com a legislação aplicável não constitui uma infração do presente Contrato.

(b) Caso o Operador de Registro decida razoavelmente que qualquer cláusula do presente Contrato e as respectivas especificações relacionadas, ou qualquer decisão ou política da ICANN referida no presente Contrato, inclusive, entre outras, as Políticas Temporárias e as Políticas Consensuais (como cláusulas, especificações e políticas, doravante coletivamente denominadas “Requisitos da ICANN”), possam entrar em conflito ou infringir a legislação aplicável (doravante, um “possível conflito”), o Operador de Registro fornecerá à ICANN um aviso detalhado (um “Aviso”) sobre tal possível conflito o mais breve possível e, no caso de um possível conflito com uma Política Consensual proposta, no mais tardar ao final de qualquer período de comentários públicos sobre tal Política Consensual proposta. Caso o Operador de Registro determine que há um possível conflito entre uma legislação aplicável proposta e qualquer Requisito da ICANN, o Operador de Registro deverá fornecer à ICANN um aviso detalhado de tal possível conflito tão logo quanto possível e, no caso de um possível conflito com uma Política Consensual proposta, no mais tardar ao final de qualquer período de comentários públicos sobre tal Política Consensual proposta.

(c) Tão logo quanto possível após essa revisão, as partes tentarão resolver o possível conflito por meio de mediação, de acordo com os procedimentos estabelecidos na Seção 5.1. Além disso, o Operador de Registro envidará seus melhores esforços para eliminar ou minimizar qualquer impacto decorrente de tal possível conflito entre a legislação aplicável e qualquer Requisito da ICANN. Se, após a mediação, o Operador de Registro decidir que o possível conflito constitui um conflito real entre qualquer Requisito da ICANN e a legislação aplicável, a ICANN renunciará à conformidade com tal

Requisito da ICANN (desde que as partes negociem de boa-fé continuamente, logo após o ocorrido, para atenuar ou eliminar os efeitos de tal falta de conformidade da ICANN), a menos que a ICANN, de maneira razoável e objetiva, decida que a falha do Operador de Registro em atender tal Requisito da ICANN constituiria uma ameaça à Segurança e Estabilidade dos Serviços de Registro, da Internet ou do DNS (doravante, “Decisão da ICANN”). Após o Operador de Registro receber o aviso sobre tal Decisão da ICANN, será concedido um prazo de 90 (noventa) dias consecutivos para o Operador de Registro resolver tal conflito com a legislação aplicável. Se o conflito com a legislação aplicável não for resolvido de maneira completamente satisfatória para a ICANN durante esse período, o Operador de Registro terá a opção de apresentar, em um prazo de 10 (dez) dias consecutivos a partir de então, a questão para arbitragem vinculativa, tal como definido na subseção (d) abaixo. Se, durante esse período, o Operador de Registro não enviar a questão para arbitragem nos termos da subseção (d) abaixo, a ICANN poderá, após fornecer aviso ao Operador de Registro, rescindir este Contrato imediatamente.

(d) Se o Operador de Registro discordar de uma Decisão da ICANN, ele poderá enviar a questão para arbitragem vinculativa nos termos das cláusulas da Seção 5.2, exceto que a única questão apresentada para decisão do árbitro será o fato de a ICANN ter chegado à Decisão da ICANN de maneira razoável e objetiva ou não. Para os fins de tal arbitragem, a ICANN apresentará provas ao árbitro para sustentar a Decisão da ICANN. Se o árbitro decidir que a ICANN não agiu de maneira razoável e objetiva para chegar à Decisão da ICANN, a ICANN renunciará à conformidade do Operador de Registro com o Requisito da ICANN. Se os árbitros ou o juiz de pré-arbitragem, conforme o caso, decidirem que a ICANN chegou à Decisão da ICANN de maneira razoável e objetiva, então, após fornecer um aviso ao Operador de Registro, a ICANN poderá rescindir este Contrato imediatamente.

(e) O Operador de Registro declara e garante que, até onde sabe, na data da execução deste Contrato, nenhum Requisito da ICANN entra em conflito ou infringe alguma legislação aplicável.

(f) Não obstante qualquer outra cláusula desta Seção 7.16, seguindo uma Decisão da ICANN e antes da decisão de um árbitro nos termos da Seção 7.16(d) acima, a ICANN poderá, sujeito a consultas prévias ao Operador de Registro, tomar as medidas técnicas razoáveis que considerar necessárias para garantir a Segurança e a Estabilidade dos Serviços de Registro, da Internet e do DNS. Essas medidas técnicas razoáveis serão tomadas pela ICANN em caráter provisório até o início da data da conclusão do procedimento de arbitragem referido na Seção 7.16(d) acima ou da data da resolução completa do conflito com a legislação aplicável. Caso o Operador de Registro não concorde com as medidas técnicas tomadas pela ICANN, ele poderá enviar a questão à arbitragem vinculativa nos termos das cláusulas da Seção 5.2 acima, processo durante o qual a ICANN poderá continuar a tomar tais medidas técnicas. Caso a ICANN tome tais medidas, o Operador de Registro arcará com todos os custos incorridos pela ICANN como resultado de tomar tais medidas. Além disso, caso a ICANN tome tais medidas, ela manterá e poderá fazer valer seus direitos nos termos do Instrumento de Operações Contínuas e do Instrumento alternativo, conforme o caso.

* * * * *

ESTANDO JUSTAS E CONTRATADAS, as partes firmam este Contrato por meio de seus representantes devidamente autorizados.

CORPORAÇÃO DA INTERNET PARA ATRIBUIÇÃO DE NOMES E NÚMEROS

Por: [ ]

Presidente e CEO Data:

[Operador de Registro]

Por: [ ]

[ ] Data:

DOCUMENTO A

Serviços aprovados

O Manual do Solicitante de gTLDs da ICANN (disponível em xxxxx://xxxxxxxx.xxxxx.xxx/xx/xxxxxxxxxx/xxx) e a RSEP especificam os processos para a análise de serviços de registro propostos. O Operador de Registro poderá prestar qualquer serviço que seja necessário nos termos deste Contrato. Além disso, os serviços a seguir (se houver) são especificamente identificados como tendo sido aprovados pela ICANN antes da data de início de vigência do Contrato, e o Operador de Registro poderá prestar tais serviços:

1. Serviço do DNS – Conteúdo de zona do TLD

Sem prejuízo de qualquer disposição em contrário neste Contrato, conforme indicado na seção 2.2.3.3 do Manual do Solicitante de gTLDs, o conteúdo permitido para o serviço de DNS de TLD é:

1.1.	Para a	classe “Internet” (IN):
	1.1.1.	Registro de SOA no ápice
	1.1.2.	Registros de NS no ápice e no campo de atividade agregado de servidores de
		DNS no TLD
	1.1.3.	Registros de NS e no campo de atividade agregado de servidores de DNS de nomes registrados no TLD
	1.1.4.	Registros de DS de nomes registrados no TLD
	1.1.5.	Registros associados à assinatura da zona de TLD (por exemplo, XXXXX, XXXXXX, XXXX, XXXX0XXXXX e NSEC3)
	1.1.6.	Registro de TXT no ápice para fins de versão de zona
	1.1.7.	Registro TYPE65534 no ápice para sinalização de assinatura de DNSSEC
1.2.	Para a	classe “Chaos” (CH):
	1.2.1.	Registros TXT de versão/identificação do servidor (por exemplo, registros TXT de

“version.bind.”, “id.server.”, “authors.bind” e/ou “hostname.bind.”)

(Observação: a redação acima não permite eficientemente, entre outras coisas, a inclusão dos registros do recurso de DNS que possibilitariam um nome de domínio sem ponto (por exemplo, registros ápice A, AAAA, MX) na zona de TLD.)

Se o Operador de Registro desejar colocar qualquer tipo de registro de recurso de DNS em seu serviço de DNS do TLD (que não sejam os relacionados nas Seções 1.1 ou 1.2 acima), ele deverá descrever em detalhes sua proposta e enviar uma solicitação de Processo de Avaliação de Serviços de Registros (RSEP). Essas informações serão avaliadas de acordo com o RSEP a fim de determinar se o serviço geraria um risco de um impacto significativamente adverso sobre a segurança ou a estabilidade do DNS. O Operador de Registro reconhece e confirma que um serviço baseado no uso de registros de recursos de DNS e/ou classes menos comuns na zona de TLD, mesmo que aprovados, talvez não funcione conforme o previsto para todos os usuários, devido à falta de suporte de software.

ESPECIFICAÇÃO 1

ESPECIFICAÇÃO DE POLÍTICAS CONSENSUAIS E POLÍTICAS TEMPORÁRIAS

1. Políticas Consensuais.

1.1. “Políticas Consensuais” são políticas estabelecidas (1) de acordo com o procedimento disposto no Estatuto da ICANN e no devido processo e (2) que abrangem os tópicos relacionados na Seção 1.2 desta Especificação. O procedimento e o processo de desenvolvimento de Políticas Consensuais estabelecidos no Estatuto da ICANN poderão ser revisados ocasionalmente de acordo com o processo estabelecido em tal Estatuto.

1.2. As Políticas Consensuais e os procedimentos pelos quais são desenvolvidas serão elaborados de modo a gerar, na medida do possível, um consenso entre as partes interessadas da Internet, inclusive os operadores de gTLDs. As Políticas Consensuais estarão relacionadas a um ou mais dos seguintes itens:

1.2.1 questões para as quais seja razoavelmente necessária uma resolução uniforme ou coordenada para promover a interoperabilidade, a segurança e/ou a estabilidade da Internet ou do Sistema de Nomes de Domínio (“DNS”);

1.2.2 especificações funcionais e de desempenho para a prestação de Serviços de registro;

1.2.3 segurança e estabilidade do banco de dados do registro para o TLD;

1.2.4 políticas de registro razoavelmente necessárias para implementar Políticas Consensuais relacionadas a operações de registro ou registradores;

1.2.5 resolução de disputas referentes ao registro de nomes de domínio (em contraposição ao uso desses nomes de domínio); ou

1.2.6 restrições para propriedade cruzada de operadores de registro e registradores ou revendedores de registradores, assim como normas e restrições com relação às operações de registro e o uso de dados do registro e do registrador, caso um operador de registro e um registrador ou revendedor de registrador sejam afiliados.

1.3. As categorias de questões referidas na Seção 1.2 desta Especificação incluirão, entre outros:

1.3.1 princípios para alocação de nomes registrados no TLD (por exemplo, atendimento por ordem de chegada, renovação oportuna, período de retenção após vencimento);

1.3.2 proibições de armazenamento ou especulação em nomes de domínio por registros ou registradores;

1.3.3 reserva de nomes registrados no TLD que talvez não sejam inicialmente registrados, ou que talvez não sejam renovados por motivos razoavelmente relacionados a (i) evitar confusão ou engano entre os usuários, (ii) propriedade intelectual, ou (iii) o gerenciamento técnico do DNS ou da Internet (por exemplo, estabelecimento de reservas de nomes do registro); e

1.3.4 manutenção e acesso a informações precisas e atualizadas referentes a registros de nomes de domínio; e os procedimentos para evitar interrupções de registros de nomes de domínio devido à suspensão ou ao encerramento das operações de um operador de registro ou de um registrador, inclusive procedimentos para a alocação da responsabilidade de atender a nomes de domínio registrados em um TLD afetado por tal suspensão ou encerramento.

1.4. Além das demais limitações das Políticas Consensuais, elas não deverão:

1.4.1 prescrever ou limitar o preço dos Serviços de registro;

1.4.2 modificar os termos ou condições para a renovação ou rescisão do Contrato de Registro;

1.4.3 modificar as limitações das Políticas Temporárias (definidas abaixo) ou das Políticas Consensuais;

1.4.4 modificar as cláusulas do contrato de registro em relação às taxas pagas pelo Operador de Registro à ICANN; ou

1.4.5 modificar as obrigações da ICANN de garantir o tratamento equitativo dos operadores de registro e agir de modo aberto e transparente.

2. Políticas Temporárias. O Operador de Registro implementará e cumprirá todas as especificações ou políticas estabelecidas pela Diretoria temporariamente, se adotadas pela Diretoria por meio dos votos de pelo menos dois terços de seus membros, contanto que a Diretoria determine razoavelmente que essas modificações ou aditamentos são justificados e que é necessário o estabelecimento temporário imediato de uma especificação ou política sobre o assunto para manter a estabilidade ou a segurança dos Serviços de registro ou do DNS (“Políticas Temporárias”).

2.1. Essa especificação ou política proposta será elaborada da maneira mais limitada possível a fim de alcançar esses objetivos. Ao estabelecer qualquer Política Temporária, a Diretoria declarará o período para o qual a Política Temporária será adotada e implementará imediatamente o processo de desenvolvimento da Política Consensual estabelecido no Estatuto da ICANN.

2.1.1 A ICANN também emitirá uma declaração consultiva contendo uma explicação detalhada de seus motivos para adotar a Política Temporária e pelos quais a Diretoria acredita que essa Política Temporária deveria receber o apoio consensual das partes interessadas da Internet.

2.1.2 Se o período para o qual a Política Temporária é adotada for superior a noventa (90) dias consecutivos, a Diretoria reafirmará sua adoção temporária a cada noventa (90) dias consecutivos, sendo que o período total não será superior a um (1) ano, a fim de manter essa Política Temporária em vigor até o momento em que se tornar uma Política Consensual. Se o período de um (1) ano expirar ou se, durante esse período de um (1) ano, a Política Temporária não se tornar uma Política Consensual e não for reafirmada pela Diretoria, o Operador de Registro não será mais obrigado a implementar nem a cumprir essa Política Temporária.

3. Aviso e conflitos. O Operador de Registro terá um tempo razoável após o envio do aviso de estabelecimento de uma Política Consensual ou Política Temporária para entrar em conformidade com essa política ou especificação, levando em consideração qualquer nível de urgência envolvido. Caso exista um conflito entre os Serviços de registro e as Políticas Consensuais ou qualquer Política Temporária, as Políticas Consensuais ou a Política Temporária serão aplicadas, mas apenas com relação à matéria em conflito.

ESPECIFICAÇÃO 2 REQUISITOS DE DEPÓSITO DE DADOS

O Operador de Registro envolverá uma entidade independente para atuar como agente

depositário de dados (“Agente depositário”) para a prestação de serviços de depósito de dados relacionados com o Contrato de Registro. As Especificações técnicas a seguir, estabelecidas na parte A, e os Requisitos legais, apresentados na parte B, serão incluídos em qualquer contrato de depósito de dados entre o Operador de Registro e o Agente depositário, em cujos termos a ICANN deverá ser indicada como um terceiro beneficiário. Além dos requisitos a seguir, o contrato de depósito de dados poderá conter outras cláusulas que não sejam contraditórias ou que não tenham a intenção de subverter os termos obrigatórios estabelecidos abaixo.

PARTE A – ESPECIFICAÇÕES TÉCNICAS

1. Depósitos. Haverá dois tipos de Depósitos: integral e diferencial. Para ambos os tipos, o universo de objetos de Registro a serem considerados para depósito de dados são os objetos necessários para oferecer todos os Serviços de registro aprovados.

1.1. “Depósito integral” são os dados que refletem o estado do registro às 00:00:00 UTC (Tempo Universal Coordenado) do dia em que tal Depósito integral for enviado ao Agente depositário.

1.2. “Depósito diferencial” são os dados que refletem todas as transações que não foram refletidas nos Depósitos integral e diferencial anteriores, conforme o caso. Cada Depósito diferencial conterá todas as transações de banco de dados desde a conclusão do Depósito anterior, às 00:00:00 UTC de cada dia, exceto domingo. Os Depósitos diferenciais deverão incluir Registros depositados completos, conforme especificado abaixo, que não tenham sido incluídos ou alterados desde o Depósito diferencial ou integral mais recente (ou seja, todos os acréscimos, modificações ou remoções de dados).

2. Programação dos depósitos. O Operador de Registro enviará um conjunto de arquivos depositados diariamente da seguinte maneira:

2.1. Todo domingo, deverá ser enviado um Depósito integral ao Agente depositário até às 23:59 UTC.

2.2. Nos outros seis (6) dias da semana, deverá ser enviado um Depósito integral ou o Depósito diferencial correspondente ao Agente depositário até às 23:59 UTC.

3. Especificação do formato do depósito.

3.1. Formato do depósito. Objetos de Registro, como domínios, contatos, servidores de nomes, registradores etc., serão compilados em um arquivo construído como descrito na RFC 8909, consulte a Parte A, Seção 9, referência 1 desta Especificação e a RFC 9022, consulte a Parte A, Seção 9, referência 2 desta Especificação (coletivamente, “Especificação DNDE”). A Especificação DNDE descreve alguns elementos como opcionais; o Operador de Registro incluirá esses elementos nos Depósitos se eles estiverem disponíveis. Será utilizada a codificação de caracteres UTF-8.

3.2. Extensões. Se um Operador de Registro oferecer outros Serviços de registro que exijam a apresentação de dados adicionais, não incluídos acima, serão definidos outros “esquemas de extensão” para representar tais dados caso a caso. Esses “esquemas de extensão” serão especificados conforme descrito na Parte A, Seção 9, referência 2 desta Especificação. Os dados relativos aos “esquemas de extensão” serão incluídos no arquivo de depósito descrito na Parte A, Seção 3.1 desta Especificação. A ICANN e o respectivo Operador de Registro deverão trabalhar em conjunto para chegar a um acordo sobre as especificações de depósito de dados desses novos objetos.

4. Processamento de arquivos de Depósito. É recomendado o uso de compactação para reduzir o tempo de transferência eletrônica dos dados e os requisitos de capacidade de armazenamento. A criptografia de dados será utilizada para garantir a privacidade dos dados de depósito do registro. Os arquivos processados para compactação e criptografia estarão no formato OpenPGP binário conforme a

RFC 4880 – Formato de mensagem OpenPGP, consulte a Parte A, Seção 9,

referência 3 desta Especificação. Os algoritmos aceitáveis para criptografia de chave pública, criptografia de chave simétrica, hash e compactação são os enumerados na RFC 4880, não marcados como obsoletos no registro OpenPGP da IANA, consulte a Parte A, Seção 9, referência 4 desta Especificação, que também são livres de direitos autorais. O processo a ser seguido para o arquivo de dados em formato de texto original é:

(1) O arquivo XML do depósito, conforme descrito na Parte A, Seção 9, referência 1 desta Especificação, deve ser nomeado como o arquivo que contém o texto, conforme especificado na Seção 5, mas com a extensão xml.

(2) O(s) arquivo(s) de dados é(são) agregado(s) em um arquivo tarball nomeado da mesma forma descrita em (1), mas com a extensão tar.

(3) Uma mensagem OpenPGP compactada e criptografada é criada usando o arquivo tarball como entrada única. O algoritmo sugerido para a compactação é ZIP, de acordo com a RFC 4880. Os dados compactados serão criptografados utilizando a chave pública do agente depositário. Os algoritmos sugeridos para a criptografia de chave pública são Elgamal e RSA, de acordo com a RFC 4880. Os algoritmos sugeridos para a criptografia de chave simétrica são TripleDES, AES128 e CAST5, de acordo com a RFC 4880.

(4) O arquivo pode ser dividido conforme necessário se, uma vez compactado e criptografado, for maior que o limite de tamanho de arquivo acordado com o agente depositário. Cada parte de um arquivo dividido ou o arquivo inteiro, caso não seja dividido, será chamado de arquivo processado nesta seção.

(5) Um arquivo de assinatura digital será gerado para cada arquivo processado utilizando a chave privada do Operador de Registro. O arquivo de assinatura digital estará em formato OpenPGP binário de acordo com a RFC 4880 Seção 9, referência 3, e não será compactado nem criptografado. Os algoritmos sugeridos para as assinaturas digitais são DSA e RSA, de acordo com a RFC 4880. O algoritmo sugerido para hashes nas assinaturas digitais é SHA256.

(6) Os arquivos processados e os arquivos de assinatura digital serão então transferidos para o Agente depositário por meio de mecanismos eletrônicos de segurança, como upload de arquivos via SFTP, SCP, HTTPS etc., conforme acordado entre o Agente depositário e o Operador de Registro. Poderão ser usadas entregas não eletrônicas em meios físicos, como CD-ROM, DVD-ROM ou dispositivos de armazenamento USB, desde que autorizado pela ICANN.

(7) O Agente depositário então validará cada arquivo de dados transferido (processado) usando o procedimento descrito na Parte A, Seção 8 desta Especificação.

5. Convenções de nomenclatura de arquivos. Os arquivos serão nomeados de acordo com a seguinte convenção: {gTLD}_{YYYY-MM-DD}_{type}_S{#}_R{rev}.{ext} onde:

5.1. {gTLD} é substituído pelo nome gTLD; no caso de um TLD de IDN, deve ser utilizado o formato compatível com ASCII (rótulo A);

5.2. {YYYY-MM-DD} é substituído pela data correspondente ao horário utilizado como marca d’água do cronograma das transações; ou seja, para o Depósito integral correspondente a 2009-08-02T00:00Z, a cadeia de caracteres utilizada seria “2009-08-02”;

5.3. {tipo} é substituído por:

(1) “full”, se os dados representarem um Depósito integral;

(2) “diff”, se os dados representarem um Depósito diferencial;

(3) “thin”, se os dados representarem um arquivo de Acesso a dados de registro em lote, conforme especificado na Seção 3 da Especificação 4;

(4) “thick-{gurid}”, se os dados representarem Dados de registro thick de

um registrador específico, conforme definido na Seção 3.2 da

Especificação 4. O elemento {gurid} deve ser substituído pelo ID do registrador da IANA associado aos dados.

5.4. {#} é substituído pela posição do arquivo em uma série de arquivos, começando em “1”; no caso de um arquivo único, este deve ser substituído por “1”.

5.5. {rev} é substituído pelo número de revisão (ou reenvio) do arquivo, começa

em “0”:

5.6. {ext} é substituído por “sig” se for um arquivo de assinatura digital do arquivo quase homônimo. Caso contrário, é substituído por “ryde”.

6. Distribuição de chaves públicas. Cada Operador de Registro e Agente depositário distribuirá sua chave pública à outra parte (Operador de Registro ou Agente depositário, conforme o caso) por e-mail para um endereço de e-mail a ser especificado. Cada parte confirmará o recebimento da chave pública da outra parte com um e-mail de resposta, e a parte distribuidora confirmará posteriormente a autenticidade da chave transmitida por métodos off-line, como reunião presencial, por telefone etc. Dessa forma, a transmissão da chave pública é autenticada para um usuário capaz de enviar e receber e-mails por meio de um servidor de correio eletrônico operado pela parte distribuidora. O Agente depositário, o Operador de Registro e a ICANN trocarão chaves públicas pelo mesmo procedimento.

7. Aviso de depósitos. Junto com a entrega de cada Depósito, o Operador de Registro entregará ao Agente depositário e à ICANN (usando a API descrita no draft-lozano- icann-registry-interfaces, consulte a Parte A, Seção 9, referência 5 desta Especificação (a “Especificação da interface”)) uma declaração por escrito do Operador de Registro (que poderá ser por e-mail autenticado) incluindo uma cópia do relatório gerado após a criação do Depósito e afirmando que o Xxxxxxxx foi inspecionado pelo Operador de Registro e está completo e preciso. A preparação e o envio dessa declaração deverão ser realizados pelo Operador de Registro ou seu designado, mas tal designado não poderá ser nem o Agente depositário, nem nenhum de seus Afiliados. O Operador de Registro incluirá os atributos “id” e “resend” do Depósito em sua declaração. Os atributos são explicados na Parte A, Seção 9, referência 1 desta Especificação.

Se ainda não tiver uma RFC, o Operador de Registro usará a versão preliminar mais recente da Especificação da interface na Data de início de vigência. O Operador de Registro poderá, a seu critério, usar versões mais recentes da Especificação da interface após a Data de início de vigência. Depois que a Especificação da interface for publicada como uma RFC, o Operador de Registro implementará essa versão da Especificação da interface, em até cento e oitenta (180) dias consecutivos após a publicação.

8. Procedimento de verificação.

(1) O arquivo de assinatura de cada arquivo processado é validado.

(2) Se os arquivos processados fizerem parte de um arquivo maior, este será montado.

(3) Cada arquivo obtido na etapa anterior é então descriptografado e descompactado.

(4) Cada arquivo de dados contido na etapa anterior é validado em relação ao formato definido na Parte A, Seção 9, referência 1 desta Especificação.

(5) O processo de verificação ampliado do agente de depósito de dados, que será aplicado nesta etapa conforme definido abaixo na referência 2 da Parte A desta Especificação 2, assim como qualquer outro processo de verificação de depósito de dados contido em tal referência.

Caso seja encontrada alguma discrepância em qualquer uma das etapas, o Depósito será considerado incompleto.

9. Referências.

(1) Especificação de Depósito de Dados de Registro, xxxxx://xxx.xxx- xxxxxx.xxx/xxx/xxx0000.xxx

(2) Mapeamento de objetos de Dados de Registro de Nomes de Domínio (DNRD), xxxxx://xxx.xxx-xxxxxx.xxx/xxx/xxx0000.xxx

(3) Formato de mensagem OpenPGP, xxxxx://xxx.xxx- xxxxxx.xxx/xxx/xxx0000.xxx

(4) Parâmetros do OpenPGP,

xxxxx://xxx.xxxx.xxx/xxxxxxxxxxx/xxx-xxxxxxxxxx/xxx-xxxxxxxxxx.xxxxx

(5) Interfaces de Registros da ICANN, xxxxx://xxxxxxxxxxx.xxxx.xxx/xxx/xxxxx- lozano-icann-registry-interfaces

PARTE B – REQUISITOS LEGAIS

1. Agente depositário. Antes de celebrar um contrato de depósito, o Operador de Registro deverá enviar um aviso à ICANN em relação à identidade do Agente depositário e fornecer à ICANN as informações de contato e uma cópia do contrato de depósito correspondente, assim como de todos os aditamentos a este. Além disso, antes de celebrar um contrato de depósito, o Operador de Registro deverá obter o consentimento da ICANN para (a) usar o Agente depositário especificado e (b) celebrar o tipo de contrato de depósito fornecido. A ICANN deverá ser expressamente designada como um terceiro beneficiário do contrato de depósito. A ICANN reserva-se o direito de negar seu consentimento a qualquer Agente depositário, contrato de depósito ou respectivos aditamentos, a seu exclusivo critério.

2. Taxas. O Operador de Registro deverá pagar as taxas ou ordenar o pagamento em seu nome diretamente ao Agente depositário. Se o Operador de Registro deixar de pagar alguma taxa na respectiva data de vencimento, o Agente depositário enviará à ICANN um aviso de inadimplência por escrito e a ICANN poderá pagar a(s) taxa(s) vencida(s) no prazo de quinze (15) dias consecutivos após receber o aviso por escrito do Agente depositário. Após pagar as taxas em atraso, a ICANN poderá reivindicar tal valor ao Operador de Registro, e este deverá pagá-lo à ICANN no vencimento do próximo pagamento da taxa nos termos do Contrato de Registro.

3. Propriedade. A propriedade dos Depósitos durante o prazo de vigência do Contrato de Registro permanecerá sempre com o Operador de Registro. Após o final desse prazo, o Operador de Registro atribuirá qualquer direito de propriedade (inclusive direitos de propriedade intelectual, conforme o caso) sobre tais depósitos à ICANN. Se, durante a vigência do Contrato de Registro, qualquer Depósito for liberado da custódia para a ICANN, qualquer direito de propriedade intelectual detido pelo Operador de Registro sobre os Depósitos será automaticamente licenciado para a ICANN ou para uma parte designada por escrito pela ICANN de modo não exclusivo, perpétuo, irrevogável, livre de direitos autorais e integralizado para qualquer uso relacionado com a operação, manutenção ou transição do TLD.

4. Integridade e confidencialidade. O Agente depositário será obrigado a (i) guardar e manter os Depósitos em uma instalação ambientalmente segura e bloqueada, acessível apenas aos representantes autorizados do Agente depositário, (ii) proteger a integridade e a confidencialidade dos Depósitos usando medidas comercialmente razoáveis e (iii) manter e proteger cada Depósito por um (1) ano. A ICANN e o Operador de Registro terão o direito de inspecionar os registros aplicáveis do Agente depositário mediante aviso prévio e durante o horário de expediente. O Operador de Registro e a ICANN terão o direito de designar um auditor terceirizado para auditar ocasionalmente a conformidade do Agente depositário com as especificações técnicas e requisitos de manutenção desta Especificação 2.

Se um Agente depositário receber uma intimação ou qualquer outra citação de um tribunal ou outro órgão judicial referente à divulgação ou liberação dos Depósitos, o Agente depositário deverá avisar imediatamente o Operador de Registro e a ICANN, a menos que proibido por lei. Após avisar o Operador de Registro e a ICANN, o Agente depositário deverá fornecer tempo suficiente para que o Operador de Registro ou a ICANN contestem qualquer citação, que será de responsabilidade do Operador de Registro ou da ICANN; desde que, no entanto, o Agente depositário não renuncie a seus direitos de apresentar uma posição em relação a qualquer citação. O Agente depositário cooperará com o Operador de Registro ou a ICANN para apoiar os esforços de minimizar ou limitar qualquer intimação às expensas dessa parte.

Qualquer parte que solicitar assistência adicional deverá arcar com os encargos padrão do Agente depositário ou, como citado, mediante a apresentação de uma solicitação detalhada.

5. Cópias. O Agente depositário poderá ter permissão para duplicar qualquer Depósito no intuito de cumprir os termos e cláusulas do contrato de depósito.

6. Liberação de depósitos. O Agente depositário disponibilizará para download eletrônico (salvo pedido em contrário) para a ICANN ou seu representante, no prazo de vinte e quatro (24) horas, às custas do Operador de Registro, todos os Depósitos em posse do Agente depositário, caso o Agente depositário receba uma solicitação do Operador de Registro para efetuar essa entrega à ICANN, ou receba da ICANN um dos avisos por escrito a seguir, afirmando que:

6.1. o Contrato de Registro expirou sem renovação ou foi rescindido; ou

6.2. a ICANN não recebeu uma notificação do Agente depositário, conforme descrito na Parte B, Seções 7.1 e 7.2 desta Especificação, em um prazo de 5 (cinco) dias consecutivos após a data de entrega agendada do Depósito; (a) a ICANN avisou o Agente depositário e o Operador de Registro sobre tal inadimplência; e (b) a ICANN não recebeu, em um prazo de sete (7) dias consecutivos após tal aviso, a notificação do Agente depositário; ou

6.3. a ICANN recebeu uma notificação do Agente depositário, conforme descrito na Parte B, Seções 7.1 e 7.2 desta Especificação, sobre a falta de verificação do último depósito de dados em uma data específica ou uma notificação sobre um depósito ausente, e a notificação for para um depósito que deveria ter sido feito em um domingo (ou seja, um Depósito integral); (a) a ICANN notificou o Operador de Registro sobre tal recebimento; e (b) a ICANN não recebeu, em um prazo de 7 (sete) dias consecutivos após o aviso, conforme descrito na Parte B, Seções 7.1 e 7.2 desta Especificação, tal notificação do Agente depositário sobre a verificação de uma versão corrigida de tal Depósito integral; ou

6.4. a ICANN recebeu cinco notificações do Agente depositário nos últimos trinta

(30) dias consecutivos, notificando a ICANN sobre depósitos de dados

ausentes ou com falha que deveriam ter sido feitos de segunda a sábado (ou seja, um Depósito diferencial), e (x) a ICANN enviou aviso ao Operador de Registro sobre o recebimento dessas notificações; e (y) a ICANN não recebeu, em um prazo de sete (7) dias consecutivos após a entrega de tal aviso ao Operador de Registro, a notificação do Agente depositário sobre a verificação de uma versão corrigida de tal Depósito diferencial; ou

6.5. o Operador de Registro: (I) deixou de realizar seus negócios no curso normal; ou (ii) pediu falência, tornou-se insolvente ou houve alguma situação análoga a qualquer um dos itens anteriores de acordo com as leis de qualquer foro em qualquer lugar do mundo; ou

6.6. o Operador de Registro teve uma falha nas funções essenciais de registro e a ICANN fez valer seus direitos nos termos da Seção 2.13 do Contrato; ou

6.7. um tribunal competente, arbitral, legislativo ou órgão governamental determinou a liberação dos Depósitos para a ICANN; ou

6.8. de acordo com Auditorias de conformidade contratual e operacional, conforme especificado na Seção 2.11 do Contrato.

A menos que o Agente depositário tenha liberado anteriormente os Depósitos do Operador de Registro para a ICANN ou seu designado, o Agente depositário entregará todos os Depósitos à ICANN após a expiração ou rescisão do Contrato de Registro ou do Contrato de depósito.

7. Verificação de Depósitos.

7.1. Em um prazo de vinte e quatro (24) horas após o recebimento de cada Depósito ou Depósito corrigido, o Agente depositário deverá verificar o formato e a integridade de cada Depósito e entregar à ICANN uma notificação gerada para cada Depósito. Os relatórios serão entregues eletronicamente usando a API descrita em draft-lozano-icann-registry-interfaces, consulte a Parte A, Seção 9, referência 5 desta Especificação.

7.2. Se o Agente depositário constatar que qualquer Xxxxxxxx foi reprovado nos procedimentos de verificação ou se o Agente depositário não receber nenhum Depósito programado, o Agente depositário deverá notificar o Operador de Registro por e-mail, fax ou telefone e a ICANN (usando a API descrita em draft-lozano-icann-registry-interfaces, consulte a Parte A,

Seção 9, referência 5 desta Especificação) sobre tal falta de conformidade ou não recebimento em um prazo de vinte e quatro (24) horas após receber o Depósito fora de conformidade ou no prazo para tal Depósito, conforme o caso. Após a notificação desta falha de verificação ou entrega, o Operador de Registro deverá começar a desenvolver alterações, atualizações, correções e outros ajustes do Depósito necessários para que ele seja entregue e aprovado

nos devidos procedimentos de verificação, e entregar tais correções ao Agente depositário o mais breve possível.

8. Aditamentos. O Agente depositário e o Operador de Registro deverão aditar os termos do Contrato de depósito de acordo com a presente Especificação 2 em um prazo de dez (10) dias consecutivos após qualquer aditamento ou modificação a esta Especificação 2. No caso de um conflito entre esta Especificação 2 e o Contrato de depósito, esta Especificação 2 prevalecerá.

9. Indenização. O Agente depositário indenizará e isentará o Operador de Registro, a ICANN e cada um de seus respectivos diretores, executivos, agentes, funcionários, membros e acionistas (“Indenizados”) em absoluto e indefinidamente, de toda e qualquer alegação, ações, danos, processos, responsabilidades, obrigações, custos, taxas, cobranças e quaisquer outras despesas de qualquer natureza, inclusive honorários advocatícios e custas que possam ser reivindicados por terceiros contra qualquer Indenizado em conexão com a falsa declaração, negligência ou má conduta do Agente depositário, seus diretores, executivos, agentes, funcionários e contratados.

ESPECIFICAÇÃO 3

FORMATO E CONTEÚDO DO RELATÓRIO MENSAL DO OPERADOR DE REGISTRO

O Operador de Registro deverá fornecer um conjunto de relatórios mensais por gTLD, usando a API descrita em draft-lozano-icann-registry-interfaces, consulte a Especificação 2, Parte A, Seção 9, referência 5, com o conteúdo a seguir.

A ICANN poderá solicitar futuramente que os relatórios sejam entregues por outros meios e em outros formatos. A ICANN envidará todos os esforços comerciais para preservar a confidencialidade das informações relatadas por até 3 (três) meses após o final do mês ao qual se referem os relatórios. Salvo o disposto nesta Especificação 3, qualquer referência a um horário específico refere-se ao Tempo Universal Coordenado (UTC). Os relatórios mensais serão compostos por dados que reflitam o estado do registro no final do mês (UTC).

1. Relatório de transações por registrador. Este relatório deverá ser compilado em um arquivo formatado com valores separados por vírgulas, conforme especificado na RFC 4180. O arquivo deverá ser nomeado “gTLD-transactions-yyyymm.csv", onde “gTLD” é o nome do gTLD; no caso de um TLD de IDN, deverá ser utilizado o

rótulo A; “yyyymm” é o ano e o mês do relatório. O arquivo deverá conter os

seguintes campos por registrador:

Nº do camp o	Nome do campo	Descrição
01	registrar-name	Razão social completa do registrador conforme registrado na IANA
02	iana-id	Nos casos em que o operador de registro atue como registrador (ou seja, sem o uso de um registrador credenciado pela ICANN), deverá ser usado 9998 ou 9999, dependendo do tipo de registro (conforme descrito na Especificação 5), caso contrário deverá ser usado o ID da IANA do registrador responsável, conforme especificado em xxxxx://xxx.xxxx.xxx/xxxxxxxxxxx/xxxxxxxxx- ids
03	total-domains	total de nomes de domínio sob responsabilidade em qualquer status do EPP, exceto pendingCreate, que não tenham sido descartados
04	total-nameservers	total de servidores de nomes (objetos de host ou hosts do servidor de nomes como atributos de nome de domínio) associados a nomes de domínio registrados para o TLD em qualquer status do

		EPP, exceto pendingCreate, que não tenham sido descartados
05	net-adds-1-yr	número de domínios registrados com sucesso (ou seja, não estão com status pendingCreate do EPP) em um período inicial de um (1) ano (e não excluídos dentro do período de tolerância). A transação deverá ser relatada no mês em que terminar o período de tolerância.
06	net-adds-2-yr	número de domínios registrados com sucesso (ou seja, não estão com status pendingCreate do EPP) em um período inicial de dois (2) anos (e não excluídos dentro do período de tolerância). A transação deverá ser relatada no mês em que terminar o período de tolerância.
07	net-adds-3-yr	número de domínios registrados com sucesso (ou seja, não estão com status pendingCreate do EPP) em um período inicial de três (3) anos (e não excluídos dentro do período de tolerância). A transação deverá ser relatada no mês em que terminar o período de tolerância.
08	net-adds-4-yr	número de domínios registrados com sucesso (ou seja, não estão com status pendingCreate do EPP) em um período inicial de quatro (4) anos (e não excluídos dentro do período de tolerância). A transação deverá ser relatada no mês em que terminar o período de tolerância.
09	net-adds-5-yr	número de domínios registrados com sucesso (ou seja, não estão com status pendingCreate do EPP) em um período inicial de cinco (5) anos (e não excluídos dentro do período de tolerância). A transação deverá ser relatada no mês em que terminar o período de tolerância.
10	net-adds-6-yr	número de domínios registrados com sucesso (ou seja, não estão com status pendingCreate do EPP) em um período inicial de seis (6) anos (e não excluídos dentro do período de tolerância). A transação deverá ser relatada no mês em que terminar o período de tolerância.
11	net-adds-7-yr	número de domínios registrados com sucesso (ou seja, não estão com status pendingCreate do EPP) em um período inicial de sete (7) anos (e não excluídos dentro do período de tolerância). A

		transação deverá ser relatada no mês em que terminar o período de tolerância.
12	net-adds-8-yr	número de domínios registrados com sucesso (ou seja, não estão com status pendingCreate do EPP) em um período inicial de oito (8) anos (e não excluídos dentro do período de tolerância). A transação deverá ser relatada no mês em que terminar o período de tolerância.
13	net-adds-9-yr	número de domínios registrados com sucesso (ou seja, não estão com status pendingCreate do EPP) em um período inicial de nove (9) anos (e não excluídos dentro do período de tolerância). A transação deverá ser relatada no mês em que terminar o período de tolerância.
14	net-adds-10-yr	número de domínios registrados com sucesso (ou seja, não estão com status pendingCreate do EPP) em um período inicial de dez (10) anos (e não excluídos dentro do período de tolerância). A transação deverá ser relatada no mês em que terminar o período de tolerância.
15	net-renews-1-yr	número de domínios renovados com sucesso (ou seja, não estão com status pendingRenew do EPP) automaticamente ou por comando com um novo período de renovação de um (1) ano (e não excluídos dentro do período de renovação ou de tolerância de renovação automática). A transação deverá ser relatada no mês em que terminar o período de renovação ou de tolerância de renovação automática.
16	net-renews-2-yr	número de domínios renovados com sucesso (ou seja, não estão com status pendingRenew do EPP) automaticamente ou por comando com um novo período de renovação de dois (2) anos (e não excluídos dentro do período de renovação ou de tolerância de renovação automática). A transação deverá ser relatada no mês em que terminar o período de renovação ou de tolerância de renovação automática.
17	net-renews-3-yr	número de domínios renovados com sucesso (ou seja, não estão com status pendingRenew do EPP) automaticamente ou por comando com um novo período de renovação de três (3) anos (e não excluídos dentro do período de renovação ou de tolerância de renovação automática). A transação

		deverá ser relatada no mês em que terminar o período de renovação ou de tolerância de renovação automática.
18	net-renews-4-yr	número de domínios renovados com sucesso (ou seja, não estão com status pendingRenew do EPP) automaticamente ou por comando com um novo período de renovação de quatro (4) anos (e não excluídos dentro do período de renovação ou de tolerância de renovação automática). A transação deverá ser relatada no mês em que terminar o período de renovação ou de tolerância de renovação automática.
19	net-renews-5-yr	número de domínios renovados com sucesso (ou seja, não estão com status pendingRenew do EPP) automaticamente ou por comando com um novo período de renovação de cinco (5) anos (e não excluídos dentro do período de renovação ou de tolerância de renovação automática). A transação deverá ser relatada no mês em que terminar o período de renovação ou de tolerância de renovação automática.
20	net-renews-6-yr	número de domínios renovados com sucesso (ou seja, não estão com status pendingRenew do EPP) automaticamente ou por comando com um novo período de renovação de seis (6) anos (e não excluídos dentro do período de renovação ou de tolerância de renovação automática). A transação deverá ser relatada no mês em que terminar o período de renovação ou de tolerância de renovação automática.
21	net-renews-7-yr	número de domínios renovados com sucesso (ou seja, não estão com status pendingRenew do EPP) automaticamente ou por comando com um novo período de renovação de sete (7) anos (e não excluídos dentro do período de renovação ou de tolerância de renovação automática). A transação deverá ser relatada no mês em que terminar o período de renovação ou de tolerância de renovação automática.
22	net-renews-8-yr	número de domínios renovados com sucesso (ou seja, não estão com status pendingRenew do EPP) automaticamente ou por comando com um novo período de renovação de oito (8) anos (e não excluídos dentro do período de renovação ou de

		tolerância de renovação automática). A transação deverá ser relatada no mês em que terminar o período de renovação ou de tolerância de renovação automática.
23	net-renews-9-yr	número de domínios renovados com sucesso (ou seja, não estão com status pendingRenew do EPP) automaticamente ou por comando com um novo período de renovação de nove (9) anos (e não excluídos dentro do período de renovação ou de tolerância de renovação automática). A transação deverá ser relatada no mês em que terminar o período de renovação ou de tolerância de renovação automática.
24	net-renews-10-yr	número de domínios renovados com sucesso (ou seja, não estão com status pendingRenew do EPP) automaticamente ou por comando com um novo período de renovação de dez (10) anos (e não excluídos dentro do período de renovação ou de tolerância de renovação automática). A transação deverá ser relatada no mês em que terminar o período de renovação ou de tolerância de renovação automática.
25	transfer-gaining-successful	número de transferências de domínio iniciadas por este registrador que foram concluídas com sucesso (aprovadas explícita ou automaticamente) e não excluídas dentro do período de tolerância de transferência. A transação deverá ser relatada no mês em que terminar o período de tolerância de transferência.
26	transfer-gaining-nacked	número de transferências de domínio iniciadas por este registrador que foram rejeitadas (por exemplo, EPP transfer op="reject") por outro registrador
27	transfer-losing-nacked	número de transferências de domínio iniciadas por outro registrador que foram concluídas com sucesso (aprovadas explícita ou automaticamente)
28	transfer-losing-nacked	número de transferências de domínio iniciadas por outro registrador que este registrador rejeitou (por exemplo, EPP transfer op="reject")
29	transfer-disputed-won	número de disputas de transferência em que este registrador prevaleceu (relatado no mês em que ocorrer a decisão)

30	transfer-disputed-lost	número de disputas de transferência que este registrador perdeu (relatado no mês em que ocorrer a decisão)
31	transfer-disputed-nodecision	número de disputas de transferência envolvendo este registrador com uma decisão dividida ou sem decisão (relatado no mês em que ocorrer a decisão)
32	deleted-domains-grace	domínios excluídos no período de tolerância (não inclui nomes excluídos enquanto apresentavam status pendingCreate do EPP). A exclusão deverá ser relatada no mês em que o nome for descartado.
33	deleted-domains-nograce	domínios excluídos fora do período de tolerância (não inclui nomes excluídos enquanto apresentavam status pendingCreate do EPP). A exclusão deverá ser relatada no mês em que o nome for descartado.
34	restored-domains	nomes de domínio restaurados durante o período do relatório
35	restored-noreport	número total de nomes restaurados para os quais o registro exige um relatório de restauração, mas o registrador não o apresentou
36	agp-exemption-requests	número total de solicitações de isenção do AGP (período de tolerância)
37	agp-exemptions-granted	número total de isenções do AGP (período de tolerância) concedidas
38	agp-exempted-domains	número total de nomes afetados pelas solicitações de isenção do AGP (período de tolerância) concedidas
39	attempted-adds	número de tentativas de comandos de criar nomes de domínio (bem-sucedidas e com falha)

A primeira linha deverá incluir os nomes dos campos exatamente conforme descritos na tabela acima como uma “linha de cabeçalho”, conforme descrito na Seção 2 da RFC 4180. A última linha de cada relatório deverá incluir os totais de cada coluna em todos os registradores; o primeiro campo dessa linha deverá ser “Totals”, enquanto o segundo campo dessa linha deverá ser deixado em branco. Não deverão ser incluídas outras linhas além das descritas acima. As quebras de linha serão <U+000D, U+000A>, conforme descrito na RFC 4180.

2. Relatório de atividades das funções de registro. Este relatório deverá ser compilado em um arquivo formatado com valores separados por vírgulas, conforme especificado na RFC 4180. O arquivo deverá ser nomeado “gTLD-atividade-

yyyymm.csv”, onde “gTLD” é o nome do gTLD; no caso de um TLD de IDN, deverá ser utilizado o rótulo A; “yyyymm” é o ano e o mês do relatório. O arquivo deverá conter os seguintes campos:

Nº do campo	Nome do campo	Descrição
01	operational-registrars	número de registradores operacionais no sistema de produção ao final do período do relatório
02	zfa-passwords	número de senhas ativas de acesso ao arquivo de zona no final do período do relatório; poderá ser usado "CZDS" em vez do número de senhas ativas de acesso ao arquivo de zona, caso o Serviço de Dados de Zona Centralizado (CZDS) seja usado para fornecer o arquivo de zona ao usuário final
03	whois-43-queries	número de consultas do WHOIS (porta 43) respondidas durante o período relatado; um valor vazio será usado após a Data de Descontinuação dos Serviços de WHOIS (conforme definido na Especificação 4), caso o serviço de WHOIS (porta 43) não esteja disponível após essa data
04	web-whois-queries	número de consultas do WHOIS baseadas na web respondidas durante o período relatado, sem incluir o WHOIS pesquisável; um valor vazio será usado após a Data de Descontinuação dos Serviços de WHOIS, caso o serviço de WHOIS baseado na web não esteja disponível após essa data
05	searchable-whois-queries	número de consultas do WHOIS pesquisável respondidas durante o período relatado; um valor vazio será usado, caso o serviço de WHOIS pesquisável não esteja disponível durante o período relatado
06	dns-udp-queries-received	número de consultas do DNS recebidas por transporte UDP durante o período do relatório
07	dns-udp-queries-responded	número de consultas do DNS recebidas por transporte UDP respondidas durante o período do relatório
08	dns-tcp-queries-received	número de consultas do DNS recebidas por transporte TCP durante o período do relatório

Nº do campo	Nome do campo	Descrição
09	dns-tcp-queries-responded	número de consultas do DNS recebidas por transporte TCP respondidas durante o período do relatório
10	srs-dom-check	número de solicitações de “verificar” nomes de domínio do SRS (EPP e qualquer outra interface) respondidas durante o período do relatório
11	srs-dom-create	número de solicitações de “criar” nomes de domínio do SRS (EPP e qualquer outra interface) respondidas durante o período do relatório
12	srs-dom-delete	número de solicitações de “excluir” nomes de domínio do SRS (EPP e qualquer outra interface) respondidas durante o período do relatório
13	srs-dom-info	número de solicitações de “informações” de nomes de domínio do SRS (EPP e qualquer outra interface) respondidas durante o período do relatório
14	srs-dom-renew	número de solicitações de “renovar” nomes de domínio do SRS (EPP e qualquer outra interface) respondidas durante o período do relatório
15	srs-dom-rgp-restore-report	número de solicitações de “restaurar” o RGP de nomes de domínio do SRS (EPP e qualquer outra interface) que forneceram um relatório de restauração e foram respondidas durante o período do relatório
16	srs-dom-rgp-restore-request	número de solicitações de “restaurar” o RGP de nomes de domínio do SRS (EPP e qualquer outra interface) respondidas durante o período do relatório
17	srs-dom-transfer-approve	número de solicitações de “transferir” nomes de domínio do SRS (EPP e qualquer outra interface) para aprovar transferências respondidas durante o período do relatório
18	srs-dom-transfer-cancel	número de solicitações de “transferir” nomes de domínio do SRS (EPP e qualquer outra interface) para cancelar transferências respondidas durante o período do relatório

Nº do campo	Nome do campo	Descrição
19	srs-dom-transfer-query	número de solicitações de “transferência” de nome de domínio do SRS (EPP e qualquer outra interface) para consulta sobre uma transferência respondida durante o período relatado
20	srs-dom-transfer-reject	número de solicitações de “transferir” nomes de domínio do SRS (EPP e qualquer outra interface) para rejeitar transferências respondidas durante o período do relatório
21	srs-dom-transfer-request	número de solicitações de “transferir” nomes de domínio do SRS (EPP e qualquer outra interface) para solicitar transferências respondidas durante o período do relatório
22	srs-dom-update	número de solicitações de “atualizar” nomes de domínio do SRS (sem incluir solicitações de restauração do RGP) respondidas durante o período do relatório
23	srs-host-check	número de solicitações de “verificar” hosts do SRS (EPP e qualquer outra interface) respondidas durante o período do relatório
24	srs-host-create	número de solicitações de “criar” hosts do SRS (EPP e qualquer outra interface) respondidas durante o período do relatório
25	srs-host-delete	número de solicitações de “excluir” hosts do SRS (EPP e qualquer outra interface) respondidas durante o período do relatório
26	srs-host-info	número de solicitações de “informações” de hosts do SRS (EPP e qualquer outra interface) respondidas durante o período do relatório
27	srs-host-update	número de solicitações de “atualizar” hosts do SRS (EPP e qualquer outra interface) respondidas durante o período do relatório
28	srs-cont-check	número de solicitações de “verificar” contatos do SRS (EPP e qualquer outra interface) respondidas durante o período do relatório
29	srs-cont-create	número de solicitações de “criar” contatos do SRS (EPP e qualquer outra interface) respondidas durante o período do relatório

Nº do campo	Nome do campo	Descrição
30	srs-cont-delete	número de solicitações de “excluir” contatos do SRS (EPP e qualquer outra interface) respondidas durante o período do relatório
31	srs-cont-info	número de solicitações de “informações” de contatos do SRS (EPP e qualquer outra interface) respondidas durante o período do relatório
32	srs-cont-transfer-approve	número de solicitações de “transferir” contatos do SRS (EPP e qualquer outra interface) para aprovar transferências respondidas durante o período do relatório
33	srs-cont-transfer-cancel	número de solicitações de “transferir” contatos do SRS (EPP e qualquer outra interface) para cancelar transferências respondidas durante o período do relatório
34	srs-cont-transfer-query	número de solicitações de “transferir” contatos do SRS (EPP e qualquer outra interface) para consultar sobre uma transferência respondida durante o período do relatório
35	srs-cont-transfer-reject	número de solicitações de “transferir” contatos do SRS (EPP e qualquer outra interface) para rejeitar transferências respondidas durante o período do relatório
36	srs-cont-transfer-request	número de solicitações de “transferir” contatos do SRS (EPP e qualquer outra interface) para solicitar transferências respondidas durante o período do relatório
37	srs-cont-update	número de solicitações de “atualizar” contatos do SRS (EPP e qualquer outra interface) respondidas durante o período do relatório
38	rdap-queries	número de consultas do RDAP respondidas durante o período do relatório

A primeira linha deverá incluir os nomes dos campos exatamente conforme descritos na tabela acima como uma “linha de cabeçalho”, conforme descrito na Seção 2 da RFC 4180. Não deverão ser incluídas outras linhas além das descritas acima. As quebras de linha serão

<U+000D, U+000A>, conforme descrito na RFC 4180.

No caso de gTLDs que fazem parte do Sistema de Registro Compartilhado de instância única: (1) os campos whois-43-queries, web-whois-queries, searchable-whois-queries e rdap-queries no Relatório de Atividade de Funções de Registro deverão corresponder à soma de consultas relatadas para

os gTLDs no Sistema de Registro Compartilhado de instância única, (2) no caso de consultas relacionadas aos campos mencionados em (1) acima para os quais o Operador de Registro é incapaz de determinar o TLD para contabilizar as consultas (por exemplo, uma consulta de pesquisa de registrador para um registrador que opera em mais de um TLD que compartilha a mesma URL de base de RDAP ), os registros terão a possibilidade de escolher como alocar essas consultas aos gTLDs utilizando o Sistema de Registro Compartilhado de instância única, e (3) o Relatório de Atividade de Funções de Registro poderá incluir o total de transações de contato ou host para todos os gTLDs no sistema.

ESPECIFICAÇÃO 4

SERVIÇOS DE PUBLICAÇÃO DE DADOS DE REGISTRO

1. Serviços de Diretório de Dados de Registro

1.1. Definições.

1.1.1 “Protocolo de Acesso a Dados de Registro”, ou “RDAP”, é um protocolo de Internet que oferece serviços de web “RESTful” (transferência de estado representativo) para recuperar metadados de registro de Registros de Nomes de Domínio e de Registros Regionais da Internet.

1.1.2 “Serviços de Diretório de RDAP” refere-se a um Serviço de Diretório de Dados de Registro que utiliza o RDAP descrito no STD 95 (xxxxx://xxx.xxx-xxxxxx.xxx/xxxx/xxx-xxx00.xxx), e seus padrões sucessores

1.1.3 “Serviços de Diretório de Dados de Registro”, ou “RDDS”, refere-se coletivamente aos Serviços de Diretório de Dados de Registro do WHOIS (conforme definido nesta Especificação 4) e aos Serviços de Diretório do RDAP (Registration Data Access Protocol, Protocolo de Acesso a Dados de Registro) (conforme definido nesta Especificação 4).

1.1.4 “Serviços de Diretório de Dados do WHOIS” refere-se coletivamente aos serviços de WHOIS disponibilizados pela porta 43, em conformidade com a RFC 3912, e a um serviço do WHOIS baseado na web que ofereça acesso público e gratuito com base em consultas a dados de registro.

1.1.5 “Período de Preparação do RDAP” refere-se ao período que termina em 3 de fevereiro de 2024.

1.1.6 “Data de Descontinuação dos Serviços de WHOIS” refere-se à data que corresponde a 360 dias após a expiração do Período de Preparação do RDAP, não obstante o fato de que a ICANN e o Grupo de Partes Interessadas de Registros poderão, mediante acordo mútuo, adiar a Data de Descontinuação dos Serviços de WHOIS. Se o diretor geral da ICANN (“CEO”) ou o presidente do Grupo de Partes Interessadas de Registros (“presidente”) desejarem discutir o adiamento da Data de Descontinuação dos Serviços de WHOIS, o CEO ou o Presidente, conforme o caso, fornecerá à outra parte um aviso por escrito dispondo em detalhes razoáveis o adiamento proposto.

1.2. Serviços de Diretório do RDAP

1.2.1 O Operador de Registro deverá implementar a versão mais recente do Guia de Implementação Técnica do RDAP e o Perfil de Resposta do RDAP, disponível em xxxxx://xxxxx.xxx/xxxx-xxxx-xxxxxxx. O Operador de Registro implementará novas versões do Guia de Implementação Técnica do RDAP e do Perfil de Resposta do RDAP em até, no máximo, cento e oitenta (180) dias consecutivos após a notificação da ICANN.

1.2.2 O Operador de Registro deverá fornecer suporte a consultas de pesquisa para:

(1) informações de domínios, conforme descrito na seção “Domain Path Segment Specification” (“Especificação de Segmento de Caminho de Domínio”) da RFC 9082.

(2) informações de servidores de nomes, conforme descrito na seção “Nameserver Path Segment Specification” (“Especificação do Segmento de Caminho de Servidor de Nomes”) da RFC 9082; contanto que o Operador de Registro não seja obrigado a (mas poderá optar por) oferecer suporte a pesquisa de servidores de nomes, se o Operador de Registro especificar servidores de nomes como atributos de domínio no EPP.

(3) informações de registradores, conforme descrito na seção “Entity Path Segment Specification” (“Especificação de Segmento de Caminho de Entidade”) da RFC 9082.

(4) informações de ajuda, conforme descrito na seção “Help Path Segment Specification” (“Especificação de Segmento de Caminho de Ajuda”) da RFC 9082.

1.2.3 A ICANN se reserva o direito de especificar formatos e protocolos alternativos aprovados como “Padrões da Internet” (em vez de padrões informativos ou experimentais) por meio dos processos relevantes da IETF relacionados a Dados de Registro. Mediante essa especificação, a ICANN deverá: (a) trabalhar de maneira colaborativa com registros de gTLDs e registradores credenciados pela ICANN para definir todos os requisitos operacionais necessários para implementar a norma aplicável; e (b) se for o caso, iniciar as negociações para definir todos os requisitos para relatórios (se houver) e as exigências razoáveis para níveis de serviço, de maneira proporcional a outros serviços situados de maneira semelhante.

1.3. Capacidade de pesquisa. A disponibilização de recursos de pesquisa para Dados de Registro é opcional, mas, se oferecida pelo Operador de Registro, deverá estar em conformidade com a especificação descrita nesta seção.

1.3.1 O Operador de Registro oferecerá recursos de pesquisa como um serviço baseado na web.

1.3.2 O Operador de Registro oferecerá recursos de correspondência parcial para cada um dos seguintes campos: nome de domínio, nome do registrante e de contatos e endereço postal do registrante e de contato, inclusive todos os subcampos descritos no EPP (por exemplo, rua, cidade, estado ou província etc.), e poderá oferecer recursos de correspondência parcial para outros campos, em cada caso sujeito à legislação relevante.

1.3.3 O Operador de Registro oferecerá recursos de correspondência exata, pelo menos, nos campos a seguir: ID do registrador, nome do servidor de nomes e endereço IP do servidor de nomes (aplica-se somente a endereços IP armazenados pelo registro, ou seja, registros agregados).

1.3.4 O Operador de Registro oferecerá recursos de pesquisa booleana para, pelo menos, dar suporte aos operadores lógicos a seguir para reunir um conjunto de critérios de pesquisa: AND, OR, NOT.

1.3.5 Os resultados de pesquisa conterão os nomes de domínio correspondente aos critérios de pesquisa.

1.3.6 O Operador de Registro: 1) implementará as medidas adequadas para evitar o abuso desse recurso (por exemplo, permitindo o acesso apenas a usuários autorizados legítimos) e 2) garantirá que o recurso esteja em conformidade com todas as leis de privacidade aplicáveis e com as Políticas Consensuais e as Políticas Temporárias da ICANN.

1.3.7 O Operador de Registro só poderá oferecer os recursos de pesquisa exigidos pelo Guia de Implementação Técnica do RDAP e pelo Perfil de Resposta do RDAP nos Serviços de Diretório do RDAP.

1.4. Serviços de Diretório de Dados do WHOIS.

1.4.1 Até a Data de Descontinuação dos Serviços de WHOIS, o Operador de Registro fornecerá um serviço de WHOIS disponível pela porta 43, de acordo com a RFC 3912, e um Serviço de WHOIS baseado na web em

<whois.nic.TLD> que ofereça acesso público e gratuito com base em consultas a pelo menos os elementos a seguir, no formato definido.

1.4.2 O formato das respostas seguirá a descrição de formato de texto semilivre abaixo, seguida de uma linha em branco e uma ressalva jurídica especificando os direitos do Operador de Registro e do usuário que faz a consulta ao banco de dados.

1.4.3 Cada objeto de dados será representado como um conjunto de pares de chave/valor, com linhas iniciadas por chaves, seguidas de dois- pontos e espaço como delimitadores, seguidas pelo valor.

1.4.4 Para campos em que exista mais de um valor, serão permitidos vários pares de chave/valor com a mesma chave (por exemplo, para relacionar vários servidores de nome). O primeiro par de chave/valor após uma linha em branco será considerado o início de um novo registro, e será considerado o identificador desse registro, e usado para agrupar dados, como nomes de host e endereços IP, ou um nome de domínio e as informações do registrante.

1.4.5 Os campos especificados abaixo apresentam os requisitos mínimos de saída.

1.4.6 Dados do nome de domínio

(1) Formato da consulta: whois EXEMPLO.TLD

(2) Formato da resposta:

Nome de domínio: EXEMPLO.TLD

ID de domínio do Registro: D1234567-TLD

Servidor de WHOIS do Registrador: whois.exemplo.tld URL do Registrador: xxxx://xxx.xxxxxxx.xxx

Data de atualização: 2009-05-29T20:13:00Z Data de criação: 2000-10-08T00:45:00Z

Data de vencimento do registro: 2010-10-08T00:44:59Z

Data de término da vigência do registro do registrador: 2010-10-08T00:44:59Z1 Registrador: EXEMPLO REGISTRADOR LLC

ID IANA do Registrador: 5555555

E-mail de contato do registrador para abuso: xxxxx@xxxxxxxxxxx.xxx Telefone de contato do registrador para abusos: +1.123551234 Revendedor: EXEMPLO REVENDEDOR12

Status do domínio: clientDeleteProhibited Status do domínio: clientRenewProhibited Status do domínio: clientTransferProhibited Status do domínio: serverUpdateProhibited ID de registrante do registro: 5372808-ERL

Nome do registrante: EXEMPLO REGISTRANTE Organização do registrante: EXEMPLO ORGANIZAÇÃO Endereço do registrante: RUA EXEMPLO 123

Cidade do registrante: QUALQUER CIDADE Estado/província do registrante: AP Código postal do registrante: A1A1A1

País do registrante: EX

Telefone do registrante: +1.5555551212 Ramal do telefone do registrante: 1234 Fax do registrante: +1.5555551213 Ramal do fax do registrante: 4321

E-mail do registrante: XXXXX@XXXXXXX.XXX ID do administrador do Registro: 5372809-ERL

Nome do administrador: EXEMPLO ADMINISTRATIVO REGISTRANTE Organização do administrador: EXEMPLO ORGANIZAÇÃO REGISTRANTE Endereço do administrador: RUA EXEMPLO 123

1 Campo opcional.

2 Campo opcional.

Cidade do administrador: QUALQUER CIDADE Estado/província do administrador: AP Código postal do administrador: A1A1A1

País do administrador: EX

Telefone do administrador: +1.5555551212 Ramal do telefone do administrador: 1234 Fax do administrador: +1.5555551213 Ramal do fax do administrador:

E-mail do Administrador: XXXXX@XXXXXXX.XXX ID de técnico do Registro: 5372811-ERL

Nome do técnico: EXEMPLO TÉCNICO REGISTRADOR Organização do técnico: EXEMPLO REGISTRADOR LLC Endereço do técnico: RUA EXEMPLO 123

Cidade do técnico: QUALQUER CIDADE Estado/província do técnico: AP Código postal do técnico: A1A1A1

País do técnico: EX

Telefone do técnico: +1.1235551234 Ramal do telefone do técnico: 1234 Fax do técnico: +1.5555551213 Ramal do fax do técnico: 93

E-mail do técnico: XXXXX@XXXXXXX.XXX

Servidor de nomes: NS01.EXAMPLEREGISTRAR.TLD Servidor de nomes: NS02.EXAMPLEREGISTRAR.TLD DNSSEC: signedDelegation

DNSSEC: unsigned

URL do formulário da ICANN para reclamações de erros no WHOIS: xxxxx://xxx.xxxxx.xxx/xxxx/

>>> Última atualização do banco de dados de WHOIS: 2009-05-29T20:15:00Z <<<

1.4.7	Dados	do registrador
Inc.”	(1)	Formato da consulta: whois “registrador Exemplo Registrar,
	(2)	Formato da resposta:
		Registrador: Exemplo Registrar, Inc. Endereço: 0000 Xxxxxxxxx Xxx Cidade: Marina del Rey Estado/província: CA Código postal: 90292 País: EUA Número de telefone: +1.3105551212 Número de fax: +1.3105551213 E-mail: registrador@exemplo.tld Servidor WHOIS do Registrador: whois.exemplo-registrador.tld URL do Registrador: xxxx://xxx.xxxxxxx-xxxxxxxxxxx.xxx Contato do administrador: Xxxx Xxxxxxxxxxx Número de telefone: +1.3105551213 Número de fax: +1.3105551213 E-mail: xxxxxxxxxxxxxxx@xxxxxxx-xxxxxxxxxxx.xxx Contato do administrador: Xxxx Xxxxxxxxxxxx Número de telefone: +1.3105551214 Número de fax: +1.3105551213 E-mail: xxxxxxxxxxxxxxxx@xxxxxxx-xxxxxxxxxxx.xxx Contato técnico: Xxxx Xxxx Número de telefone: +1.3105551215 Número de fax: +1.3105551216

E-mail: xxxxxxxx@xxxxxxx-xxxxxxxxxxx.xxx

>>> Última atualização do banco de dados de WHOIS: 2009-05-29T20:15:00Z <<<

1.4.8 Dados do servidor de nomes:

(1) Formato da consulta: whois “nameserver (nome do servidor de nomes)” ou whois “nameserver (endereço IP)”. Por exemplo, whois “nameserver NS1.EXEMPLO.TLD”.

(2) Formato da resposta:

Nome do servidor: NS1.EXAMPLE.TLD Endereço IP: 192.0.2.123

Endereço IP: 2001:0DB8::1 Registrador: Exemplo Registrar, Inc.

Servidor WHOIS do Registrador: whois.exemplo-registrador.tld URL do Registrador: xxxx://xxx.xxxxxxx-xxxxxxxxxxx.xxx

>>> Última atualização do banco de dados de WHOIS: 2009-05-29T20:15:00Z <<<

1.4.9 O formato dos campos de dados a seguir: status do domínio, nomes da organização e pessoal, endereço, rua, cidade, estado/província, código postal, país, números de telefone e fax (o ramal será fornecido como um campo separado, conforme mostrado acima), endereços de e-mail, data e hora deverão corresponder aos mapeamentos especificados nas RFCs 5730-5734 do EPP de modo que a exibição dessas informações (ou os valores retornados em resultados de WHOIS) seja processada e compreendida de maneira uniforme.

1.5. Serviços do Diretório de Dados do WHOIS após a Data de Descontinuação dos Serviços de WHOIS. Se o Operador de Registro continuar oferecendo Serviços de Diretório de Dados do WHOIS após a Data de Descontinuação dos Serviços de WHOIS, os requisitos a seguir serão aplicáveis:

1.5.1 Se o Operador de Registro continuar oferecendo um serviço de WHOIS pela porta 43, o Operador de Registro deverá fazê-lo de acordo com a RFC 3912.

1.5.2 O Operador de Registro deverá enviar uma solicitação de alteração ao operador de funções da IANA para atualizar todos os registros desatualizados ou incorretos do WHOIS relacionados ao TLD, conforme descrito na Especificação 6, Seção 1.6.

1.5.3 Dados pessoais incluídos nos dados de registro deverão ser omitidos, de acordo com as Políticas Consensuais e Políticas Temporárias da ICANN;

1.5.4 O Operador de Registro deverá atender aos requisitos relacionados a campos adicionais da Política Consensual de Exibição e Rotulagem Consistentes, caso decida adicionar outros campos de dados.

1.5.5 Se o Operador de Registro fornecer menos dados de registro nos Serviços de Diretório de Dados do WHOIS do que os disponíveis nos Serviços de Diretório do RDAP, o Operador de Registro deverá adicionar o seguinte aviso no rodapé do resultado do WHOIS: “Os dados de registro disponíveis neste serviço são limitados. Outros dados poderão estar disponíveis em xxxxx://xxxxxx.xxxxx.xxx”.

1.5.6 Após a Data de Descontinuação dos Serviços de WHOIS, caso exista um conflito entre os requisitos do Serviço de Diretório de Dados do WHOIS e de Políticas Consensuais ou qualquer Política Temporária em vigor após a Data de Descontinuação dos Serviços de WHOIS, as Políticas Consensuais ou a Política Temporária será dominante, mas apenas no que diz respeito à questão em conflito.

1.5.7 Até que atualizações sejam feitas e colocadas em vigor para as Políticas Consensuais e os procedimentos relacionados às recomendações da Fase 1 da Política Consensual da GNSO do Processo de Desenvolvimento de Políticas Rápido sobre a Especificação Temporária para Dados de Registro de gTLDs, adotadas pela Diretoria da ICANN em maio de 2019, a partir da Data de Descontinuação dos Serviços de WHOIS, os termos a seguir constantes nessas políticas serão interpretados da seguinte maneira:

(1) Com a exceção de “Whois pesquisável” e o “serviço de pesquisa de contato de Whois”, os seguintes termos: “WHOIS”, “Whois”, “serviço de Whois”, “Whois de acesso público” e demais variações serão interpretados de maneira associada ao RDDS, conforme definido nesta Especificação.

(2) “dados de Whois”, “informações de WHOIS”, “informações de contato de Whois”, “dados de consulta do WHOIS”, “detalhes do WHOIS”, “resultado do Whois”, “registro do Whois”, “entrada do Whois” e demais variações serão interpretados de maneira associada aos dados de registro, conforme mencionado nesta Especificação.

1.6. Após a Data de Descontinuação dos Serviços de WHOIS, os termos em 1.5.7(1) e 1.5.7(2) acima, incluídos no Documento A e nas Especificações 11 e 12, serão interpretados conforme definido em 1.5.7(1) e 1.5.7(2).

1.7. Cooperação com estudos de transição. Se a ICANN iniciar ou encomendar um estudo sobre a transição dos Serviços do Diretório de Dados do WHOIS para os Serviços de Diretório do RDAP, o Operador de Registro deverá

cooperar de modo razoável com esse estudo, inclusive enviando à ICANN ou seu representante responsável por tal estudo dados quantitativos e qualitativos relacionados à sua experiência durante a transição dos Serviços de Diretório de Dados do WHOIS para os Serviços de Diretório de Dados do RDAP. Se a solicitação de dados ultrapassar o escopo de dados coletados pelo Operador de Registro durante suas operações normais e ultrapassar o escopo dos dados que o Operador de Registro é obrigado a coletar e a fornecer à Organização ICANN, de acordo com este Contrato, o Operador de Registro deverá cooperar de maneira voluntária para enviar as informações solicitadas ou explicar à ICANN o motivo pelo qual o Operador do Registro não poderá fornecer as informações solicitadas. Os termos desta seção não exigem que o Operador de Registro envie dados a ICANN que ultrapassem o escopo para o qual o Operador de Registro está obrigado a fornecer dados à ICANN, de acordo com outras seções do presente Contrato. Todos os dados entregues à ICANN ou seu representante nos termos desta seção que estiverem devidamente marcados como confidenciais, de acordo com as cláusulas de confidencialidade do Contrato, deverão ser tratados como Informações Confidenciais do Operador de Registro, de acordo com as cláusulas de confidencialidade do Contrato; considerando que, não obstante as disposições do Contrato, se a ICANN ou seu representante agregar e tornar anônimos tais dados, a ICANN ou seu representante poderá divulgar esses dados a terceiros. Após a conclusão de um estudo econômico para o qual o Operador de Registro tenha fornecido dados, a ICANN destruirá todos os dados fornecidos pelo Operador de Registro que não tiverem sido agregados e tornados anônimos de acordo com esta seção.

1.8. Materiais educativos e sobre políticas. O Operador de Registro deverá fornecer um link no site principal do TLD (ou seja, o site fornecido à ICANN, para a publicação no site da ICANN) para uma página designada pela ICANN que contenha a política RDDS e materiais educativos.

2. Acesso ao arquivo de zona

2.1. Acesso de terceiros

2.1.1 Contrato de acesso ao arquivo de zona. O Operador de Registro celebrará um acordo com qualquer usuário de Internet, o que permitirá que tal usuário acesse um servidor host da Internet ou servidores designados pelo Operador de Registro e baixe dados do arquivo de zona. O acordo será padronizado, simplificado e administrado por um Provedor de Acesso de Dados de Zona Centralizado, que pode ser da ICANN ou designado por esta (o “Provedor de CZDA”). O Operador de Registro (opcionalmente por meio do Provedor de CZDA) fornecerá acesso aos dados do arquivo de zona de acordo com a Seção 2.1.3 desta Especificação e o fará utilizando o formato de arquivo descrito na Seção 2.1.4 desta

Especificação. Não obstante o acima exposto, (a) o Provedor de CZDA poderá rejeitar a solicitação de acesso de qualquer usuário que não atenda aos requisitos de credenciamento na Seção 2.1.2 desta Especificação; (b) o Operador de Registro poderá rejeitar a solicitação de acesso de qualquer usuário que não tenha fornecido as credenciais corretas ou legítimas nos termos da Seção 2.1.2 desta Especificação ou quando o Operador de Registro acreditar que violará os termos da Seção 2.1.5 desta Especificação; e (c) o Operador de Registro poderá revogar o acesso de qualquer usuário se o Operador de Registro tiver evidências para sustentar que o usuário tenha violado os termos da Seção 2.1.5 desta Especificação.

2.1.2 Requisitos de credenciamento. O Operador de Registro, por meio do Provedor CZDA, solicitará que cada usuário forneça a ele as informações suficientes para identificar e localizar o usuário corretamente. Tais informações do usuário conterão, por exemplo, nome da empresa, nome de contato, endereço, número de telefone, número de fax, endereço de e-mail e endereço IP.

2.1.3 Concessão de acesso. Cada Operador de Registro (opcionalmente por meio do Provedor CZDA) fornecerá o serviço de SFTP de Arquivo de zona SFTP (ou outro Registro aceito) de uma URL especificada e gerenciada pela ICANN (especificamente, <TLD>.xxx.xxxxx.xxx onde

<TLD> é o TLD pelo qual o registro é responsável) para o usuário acessar arquivos de dados de zona do Registro. O Operador de Registro concederá ao usuário um direito de acesso intransferível e limitado para acessar o servidor de hospedagem do Arquivo de zona do Operador de Registro (opcionalmente do Provedor CZDA) e para transferir uma cópia dos arquivos de zona de domínio de nível superior, e de qualquer arquivo de soma de verificação associada não mais do que uma vez por período de 24 horas utilizando SFTP, ou outros protocolos de transporte de dados e de acesso que possam ser indicados pela ICANN. Para cada servidor de acesso de arquivo de zona, os arquivos de zona estarão no diretório de nível superior chamado <zone>.zone.gz, com <zone>.zone.gz.md5 e

<zone>.zone.gz.sig para verificação de downloads. Se o Operador de Registro (ou o Provedor CZDA) também fornecer dados históricos, ele usará o padrão de nomenclatura <zone>-yyyymmdd.zone.gz etc.

2.1.4 Padrão de formato de arquivo. O Operador de Registro (opcionalmente por meio do Provedor CZDA) fornecerá os arquivos de zona usando um subformato do formato de Arquivo mestre padrão, como originalmente definido na RFC 1035, Seção 5, inclusive todos os registros presentes na zona real usada no DNS público. O subformato ocorre da seguinte forma:

1. Cada registro deverá incluir todos os campos em uma única linha como: <domain-name> <TTL> <class> <type> <RDATA>.

2. Classe e tipo deverão utilizar o mnemônico padrão e em letras minúsculas.

3. TTL deverá estar presente como um inteiro decimal.

4. É permitido o uso de \X e \DDD dentro de nomes de domínio.

5. Todos os nomes de domínio deverão estar em letras minúsculas.

6. Deve-se usar exatamente uma marca de tabulação como separador de campos dentro de um registro.

7. Todos os nomes de domínio deverão ser totalmente qualificados.

8. Sem diretivas $ORIGIN.

9. Não utilize “@” para marcar a origem atual.

10. Não utilize “nomes de domínio em branco” no início de um registro para continuar o uso do nome de domínio no registro anterior.

11. Sem diretivas $INCLUDE.

12. Sem diretivas $TTL.

13. Não utilize parênteses, por exemplo, para continuar a lista de campos em um registro em um limite de linha.

14. Não utilize comentários.

15. Sem linhas em branco.

16. O registro SOA deverá estar presente na parte superior e (duplicado) no fim do arquivo de zona.

17. Com exceção do registro SOA, todos os registros em um arquivo deverão estar em ordem alfabética.

18. Uma zona por arquivo. Se um TLD dividir seus dados de DNS em diversas zonas, cada zona vai para um arquivo separado, nomeado conforme mostrado acima com todos os arquivos

combinados usando tar em um arquivo chamado

<tld>.zone.tar.

2.1.5 Uso de dados por usuário. O Operador de Registro permitirá que o usuário utilize o arquivo de zona para fins legais; desde que (a) o usuário tome todas as medidas razoáveis para a proteção contra o acesso não autorizado, utilização e divulgação dos dados e (b) sob nenhuma circunstância o Operador de Registro será obrigado ou terá permissão para autorizar o usuário a utilizar os dados para, (i) permitir, ativar, ou de outra forma apoiar qualquer atividade de marketing a entidades que não sejam os clientes atuais do usuário, independentemente da mídia usada (essa mídia pode conter, mas não se limita à transmissão por e-mail, telefone, ou fax, correio postal, SMS e alertas sem fio de publicidade comercial massiva não solicitada ou pedidos a entidades) ou (ii) possibilitar processos eletrônicos automáticos e de grande volume que enviem consultas ou dados aos sistemas do Operador de Registro ou de qualquer registrador credenciado pela ICANN ou (iii) interromper, encerrar ou interferir nas operações normais de negócios de qualquer registrante.

2.1.6 Prazo de uso. O Operador de Registro, por meio do Provedor CZDA, fornecerá a cada usuário o acesso ao arquivo de zona por um período de até 3 (três) meses. O Operador de Registro permitirá que os usuários renovem sua Concessão de acesso.

2.1.7 Sem taxa de acesso. O Operador de Registro fornecerá, e o Provedor CZDA promoverá, o acesso ao arquivo de zona para o usuário sem nenhum custo.

2.2. Cooperação

2.2.1 Assistência. O Operador de Registro cooperará e fornecerá assistência à ICANN e o Provedor CZDA facilitará e manterá o acesso eficiente aos dados do arquivo de zona por usuários autorizados conforme previsto neste Cronograma.

2.3. Acesso à ICANN. O Operador de Registro deverá fornecer o acesso em massa aos arquivos de zona para o TLD à ICANN ou seu representante continuamente, da maneira que a ICANN especificar ocasionalmente. O acesso será fornecido pelo menos diariamente. Os arquivos de zona conterão dados do SRS confirmados o mais próximo possível de 00:00:00 UTC.

2.4. Acesso de emergência do operador. O Operador de Registro deverá fornecer o acesso em massa aos arquivos de zona para o TLD aos Operadores de emergência designados pela ICANN continuamente, da maneira que a ICANN especificar ocasionalmente.

3. Acesso a dados de registro em lote para a ICANN

3.1. Acesso periódico aos dados de registro thin. No intuito de verificar e assegurar a estabilidade operacional dos Serviços de registro, analisar a estabilidade operacional do DNS, bem como facilitar a verificação de conformidade dos registradores credenciados, o Operador de Registro fornecerá à ICANN semanalmente (em um dia a ser designado pela ICANN) dados de registro atualizados conforme especificado abaixo. Os dados incluem os dados confirmados a partir de 00:00:00 UTC do dia anterior ao designado para recuperação pela ICANN.

A ICANN publicará anualmente um resumo dos projetos de pesquisa que utilizaram esses dados no ano anterior, juntamente com uma relação de todas as organizações cujos dados brutos foram compartilhados para fins de realização da pesquisa.

3.1.1 Conteúdo. O Operador de Registro enviará os dados a seguir para todos os nomes de domínio registrados: nome de domínio, id do objeto de repositório de nome de domínio (roid), ID do registrador (ID IANA), status, data da última atualização, data de criação, data de vencimento e nomes do servidor de nomes. No caso de registradores responsáveis, o Operador de Registro fornecerá o seguinte: nome do registrador, ID do registrador (ID IANA), nome de host do servidor WHOIS do registrador (esse elemento de dados poderá ser omitido após a Data de Descontinuação dos Serviços de WHOIS) e a URL do registrador. O Operador de Registro não deverá fornecer quaisquer elementos de dados adicionais.

3.1.2 Formato. Os dados serão fornecidos no formato especificado na Especificação 2 para Depósito de dados (inclusive criptografia, assinatura etc.), mas contendo somente os campos mencionados no item anterior, ou seja, o arquivo conterá apenas os objetos Domínio e Registradores com os campos mencionados acima. O Operador de Registro tem a opção de fornecer um arquivo de depósito integral ao invés do indicado na Especificação 2.

3.1.3 Acesso. O Operador de Registro terá o(s) arquivo(s) pronto(s) para baixar a partir de 00:00:00 UTC do dia designado para recuperação pela ICANN. O(s) arquivo(s) será(ão) disponibilizados para baixar por SFTP, embora a ICANN possa solicitar outros meios no futuro.

3.2. Acesso excepcional aos dados de registro thick. Em caso de uma falha do registrador, descredenciamento, ordem judicial etc., que implique na transferência temporária ou definitiva de seus nomes de domínio para outro registrador, a pedido da ICANN, o Operador de Registro fornecerá à ICANN os dados atualizados dos nomes de domínio do registrador perdido. Os dados

serão fornecidos no formato especificado na Especificação 2 para Depósito de dados. O arquivo conterá apenas os dados relacionados aos nomes de domínio do registrador perdido. O Operador de Registro fornecerá os dados assim que comercialmente viáveis, mas em nenhum caso o mais tardar em até cinco (5) dias consecutivos após a solicitação da ICANN. A menos que previamente acordado entre o Operador de Registro e a ICANN, o arquivo será disponibilizado para download pela ICANN da mesma maneira que os dados especificados na Seção 3.1 desta Especificação.

ESPECIFICAÇÃO 5 CRONOGRAMA DE NOMES RESERVADOS

Exceto na medida em que a ICANN autorizar expressamente de outra forma, por escrito, e

sujeito aos termos e condições desta Especificação, o Operador de Registro deverá reservar os rótulos a seguir do registro inicial (isto é, que não sejam renovação) no TLD. Se estiver usando a própria alocação, o Operador de Registro deverá mostrar o registro no RDDS. No caso de nomes IDN (conforme indicado abaixo), as variações de IDN serão identificadas de acordo com a política de registro de IDN do operador de registro, quando aplicável.

1. Exemplo. O rótulo ASCII “EXEMPLO” será retido no registro ou será alocado ao Operador de Registro no segundo nível e em todos os outros níveis dentro do TLD nos quais o Operador de Registro oferece registros (como segundo nível e todos os outros níveis serão coletivamente referidos aqui como “Todos os níveis”). Esse rótulo não poderá ser ativado no DNS e não poderá ser disponibilizado para o registro a nenhuma pessoa ou entidade que não seja o Operador de Registro. Após a conclusão da designação do Operador de Registro como operador de registro para o TLD, tal rótulo retido ou atribuído deverá ser transferido conforme especificado pela ICANN. O Operador de Registro poderá atribuir para si e renovar esse nome sem o uso de um registrador credenciado pela ICANN, fato que não será considerado Transações para fins da Seção 6.1 do Contrato.

2. Rótulos de dois caracteres. Todos os rótulos de dois caracteres ASCII serão retidos no registro ou serão alocados ao Operador de Registro no segundo nível dentro do TLD. Esses rótulos não poderão ser ativados no DNS e não poderão ser liberados para o registro a nenhuma pessoa ou entidade que não seja o Operador de Registro, desde que tais cadeias de caracteres de rótulos de dois caracteres possam ser liberadas na medida em que o Operador de Registro chegar a um acordo com o respectivo governo e o gerenciador de código de país da cadeia de caracteres, conforme especificado no padrão ISO 3166-1 alpha-2. O Operador de Registro também poderá propor a liberação dessas reservas com base na implementação de medidas para evitar confusão com os códigos de países correspondentes, sujeito à aprovação pela ICANN. Após a conclusão da designação do Operador de Registro como operador de registro para o TLD, todos esses rótulos que permanecerem retidos no registro ou alocados ao Operador de Registro serão transferidos, conforme especificado pela ICANN. O Operador de Registro poderá atribuir para si e renovar tais nomes sem o uso de um registrador credenciado pela ICANN, fato que não será considerado Transações para fins da Seção 6.1 do Contrato.

3. Reservas para operações de registro.

3.1. Os rótulos ASCII a seguir deverão ser retidos no registro ou alocados ao Operador de Registro em Todos os níveis para uso em conjunto com a operação do registro para o TLD: WWW, RDDS e WHOIS. O rótulo ASCII a seguir deverá ser alocado ao Operador de Registro mediante a autorização na

zona raiz em Todos os níveis para o uso em conjunto com a operação do registro do TLD: NIC. O Operador de Registro poderá ativar os rótulos WWW, RDDS e WHOIS no DNS, mas deverá ativar NIC no DNS, conforme necessário, para a operação do TLD (de acordo com o disposto no Documento A, o rótulo ASCII NIC deverá ser fornecido no DNS como um corte de zona que utiliza registros de recursos de NS). Nenhum rótulo WWW, RDDS, WHOIS ou NIC poderá ser disponibilizado ou registrado para nenhuma pessoa (a não ser o Operador de Registro) ou terceiros. Após a conclusão da indicação do Operador de Registro como operador do registro do TLD, todos esses nomes retidos ou atribuídos serão transferidos conforme especificado pela ICANN. O Operador de Registro poderá atribuir para si e renovar tais nomes sem o uso de um registrador credenciado pela ICANN, fato que não será considerado Transações para fins da Seção 6.1 do Contrato. Esses domínios serão identificados pelo ID de registrador 9999.

3.1.1 Se o Documento A do Contrato estabelecer especificamente que o Operador de Registro poderá oferecer registro de IDNs, ele também poderá ativar uma tradução ou transliteração específica no idioma do termo "NIC" ou uma abreviação para a tradução do termo "Centro de Informações de Rede" no DNS de acordo com as tabelas de IDNs do Operador de Registro e as regras de registro de IDNs. A tradução, transliteração ou abreviação poderão ser reservadas pelo Operador de Registro e usadas além do rótulo NIC para fornecer qualquer função de registro necessária. Para evitar dúvidas, o Operador de Registro é obrigado a ativar o rótulo ASCII NIC de acordo com a

Seção 3.1 desta Especificação 5.

3.2. O Operador de Registro poderá ativar no DNS em Todos os níveis, até 100 (cem) nomes (além de suas variações de IDN, quando aplicável) necessários para a operação ou a promoção do TLD. O Operador de Registro deverá agir como o Titular de Nome Registrado de tais nomes, como o termo é definido no atual Contrato de Credenciamento de Registradores (RAA) da ICANN. Essas ativações serão consideradas Transações para fins da Seção 6.1 do Contrato. O Operador de Registro deverá (i) registrar tais nomes por meio de um registrador credenciado pela ICANN; ou (ii) atribuir para si tais nomes e com respeito a eles enviar à ICANN e responsabilizar-se perante a ICANN pela conformidade com as Políticas Consensuais da ICANN e as obrigações previstas nas Subseções 3.7.7.1 a 3.7.7.12 do RAA vigente no momento (ou qualquer outra cláusula de substituição que estabelece os termos do contrato de registro entre um registrador e um titular de nome registrado). Se o Operador de Registro escolher a opção (ii) acima, deverá identificar essas transações com o uso do ID de registrador 9998. A critério do Operador de Registro e em conformidade com todos os outros termos deste Contrato, inclusive os RPMs estabelecidos na Especificação 7, esses nomes poderão ser disponibilizados para registro para outra pessoa ou entidade.

3.4. Mediante a conclusão do Período de não ativação especificado na Seção 6.1 da Especificação 6, o Operador de Registro deverá alocar o nome de domínio "icann-sla-monitoring.<tld>" ao registrador de testes da ICANN (esse registrador é descrito na Seção 8.2 da Especificação 10). Se esse nome de domínio não estiver disponível para registro no TLD ou estiver de outra forma inconsistente com as políticas de registro do TLD, o Operador de Registro poderá alocar um nome de domínio diferente para o registrador de testes da ICANN mediante consulta com a ICANN. A alocação de qualquer um desses nomes de domínio alternativos será comunicada à ICANN após consulta. A alocação do nome de domínio "icann-sla-monitoring.<tld>" ao registrador de testes da ICANN (i) não será considerada uma Transação para fins da Seção 6.1 do Contrato, (ii) não será contada dentro dos cem nomes de domínio disponíveis para o Operador de Registro nos termos da Seção 3.2 desta Especificação 5 (iii) nem afetará desfavoravelmente a qualificação do Operador de Registro como um TLD .BRAND de acordo com a

Especificação 13 (cláusulas do TLD .BRAND) deste documento (conforme o caso).

4. Nomes de países e territórios. Os nomes de países e territórios (inclusive suas variações de IDN, quando aplicável) contidos nas seguintes listas reconhecidas internacionalmente, deverão ser retidos no registro ou alocados para o Operador de Registro em Todos os níveis:

4.1. a forma abreviada (em inglês) de todos os nomes de países e territórios que constam na lista ISO 3166-1, atualizada esporadicamente, inclusive a União Europeia, que é excepcionalmente reservada na lista ISO 3166-1, e seu escopo ampliado em agosto de 1999 para qualquer solicitação que deva representar o nome União Europeia xxxxx://xxx.xxx.xxx/xxx-0000-xxxxxxx- codes.html;

4.2. o Grupo das Nações Unidas de especialistas em nomes geográficos, Manual de referência técnica para a padronização de nomes geográficos, Parte III Os nomes dos países do mundo; e

4.3. a relação dos Estados membros das Nações Unidas em 6 idiomas oficiais das Nações Unidas preparados pelo Grupo de Trabalho sobre os nomes dos países da Conferência das Nações Unidas sobre a padronização de nomes geográficos;

contanto que a reserva de nomes de países e territórios específicos (inclusive suas variações de IDN, de acordo com a política de registro de IDN do operador de registro, se for o caso) possa ser disponibilizada na medida em que o Operador de Registro chegar a um acordo com o(s) governo(s) relevante(s). O Operador de Registro não deverá ativar tais nomes no DNS; no entanto, o Operador de Registro poderá propor a liberação dessas reservas, sujeito à revisão pelo Comitê Consultivo para Assuntos Governamentais (GAC) da ICANN e aprovação pela ICANN. Após a conclusão da designação do Operador de Registro como operador de registro para o TLD, todos esses nomes que permanecerem retidos no registro ou alocados para o Operador de Registro deverão ser transferidos, conforme especificado pela ICANN. O Operador de Registro poderá atribuir para si e renovar tais nomes sem o uso de um registrador credenciado pela ICANN, fato que não será considerado Transações para fins da Seção 6.1 do Contrato.

5. Comitê Olímpico Internacional; Movimento Internacional da Cruz Vermelha e do Crescente Vermelho. Conforme instruções fornecidas pela ICANN periodicamente, os nomes (inclusive suas variações de IDNs, quando aplicável) relacionados ao Comitê Olímpico Internacional, ao Movimento Internacional da Cruz Vermelha e do Crescente Vermelho relacionados em xxxxx://xxx.xxxxx.xxx/xxxxxxxx-xxxxx deverão ter o registro bloqueado ou serem alocados ao Operador de Registro no segundo nível dentro do TLD. Outros nomes do Comitê Olímpico Internacional, do Movimento Internacional da Cruz Vermelha e do Crescente Vermelho (inclusive suas variações de IDNs) poderão ser incluídos na lista, dez (10) dias consecutivos após a notificação da ICANN ao Operador de Registro. Esses nomes não poderão ser ativados no DNS e não poderão ser disponibilizados para registro a nenhuma pessoa ou entidade que não seja o Operador de Registro. Após a conclusão da designação do Operador de Registro como operador de registro para o TLD, todos esses nomes com registro bloqueado ou alocados para o Operador de Registro deverão ser transferidos, conforme especificado pela ICANN. O Operador de Registro poderá atribuir para si e renovar tais nomes sem o uso de um registrador credenciado pela ICANN, fato que não será considerado uma Transação para fins da Seção 6.1 do Contrato.

6. Organizações intergovernamentais. Conforme instruções fornecidas pela ICANN periodicamente, o Operador de Registro implementará os mecanismos de proteção determinados pela Diretoria da ICANN em relação à proteção de identificadores para Organizações Intergovernamentais. Uma lista de nomes reservados para esta

Seção 6 está disponível em xxxxx://xxx.xxxxx.xxx/xxxxxxxx-xxxxx. Nomes adicionais (inclusive suas variações de IDNs) poderão ser incluídos na lista, dez (10) dias consecutivos após a notificação da ICANN ao Operador de Registro. Nenhum desses identificadores protegidos por Organizações Intergovernamentais poderá ser ativado no DNS nem disponibilizado para registro a nenhuma pessoa ou entidade que não seja o Operador de Registro. Após a conclusão da designação do Operador de Registro como operador de registro para o TLD, todos esses identificadores protegidos deverão ser transferidos, conforme especificado pela ICANN. O Operador de Registro poderá atribuir para si e renovar tais nomes sem o uso de um registrador credenciado pela ICANN, fato que não será considerado uma Transação para fins da Seção 6.1 do Contrato.

ESPECIFICAÇÃO 6

ESPECIFICAÇÕES DE INTEROPERABILIDADE E CONTINUIDADE DO REGISTRO

1. Conformidade com as normas

1.1. DNS. O Operador de Registro deverá cumprir as RFCs relevantes já existentes e as que serão publicadas futuramente pela Força-tarefa de Engenharia da Internet (IETF), inclusive todas as normas, modificações ou aditamentos posteriores referentes ao DNS e operações do servidor de nomes, inclusive, entre outras, as RFCs 1034, 1035, 1123, 1982, 2181, 2182, 3226, 3596, 3597, 4343, 5966 e 6891. Os rótulos de DNS contêm somente hifens na terceira e quarta posições, caso representem IDNs válidos (conforme especificado acima) em sua codificação ASCII (por exemplo, “xn--ndk061n”).

1.2. EPP. O Operador de Registro deverá cumprir as RFCs relevantes já existentes e as que serão publicadas futuramente pela Força-tarefa de Engenharia da Internet (IETF), inclusive todas as normas, modificações ou aditamentos posteriores relativos ao fornecimento e gestão de nomes de domínio usando o Protocolo de Provisionamento Extensível (EPP) em conformidade com as RFCs 5910, 5730, 5731, 5732 (se estiver usando objetos de host), 5733 e 5734. Se o Operador de Registro implementar o Período de Tolerância do Registro (RGP), ele atenderá à RFC 3915 e posteriores. Se o Operador de Registro exigir o uso da funcionalidade fora das RFCs do EPP de base, o Operador de Registro deverá documentar as extensões de EPP no formato preliminar da Internet, seguindo as orientações descritas na RFC 3735. O Operador de Registro fornecerá e atualizará a documentação pertinente de todos os objetos e extensões de EPP aceitos pela ICANN antes da implantação.

1.3. DNSSEC. O Operador de Registro deverá assinar seus arquivos de zona TLD da implementação das Extensões de segurança do sistema de nomes de domínio (“DNSSEC”). Para evitar dúvidas, o Operador de Registro deverá assinar o arquivo de zona de <TLD> e os arquivos de zona usados para o campo de atividade agregado dos servidores de DNS do TLD. Durante o Prazo, o Operador de Registro deverá cumprir as RFCs 4033, 4034, 4035, 4509 e posteriores e seguir as práticas recomendadas descritas na RFC 6781 e posteriores. Se o Operador de Registro implementar Negação autenticada em hash da existência das extensões de segurança do DNS, ele deverá atender à RFC 5155 e posteriores. O Operador de Registro deverá aceitar o material de chave pública dos nomes de domínio secundários de modo seguro, de acordo com as práticas recomendadas do setor. O Registro também deverá publicar em seu site as Declarações de Práticas de DNSSEC (DPS), que descrevem os controles e procedimentos de segurança fundamentais para o armazenamento, acesso e uso do material de suas próprias chaves e a aceitação segura do material de chave pública dos

registrantes. O Operador de Registro deverá publicar sua DPS seguindo o formato descrito na RFC 6841. A validação de DNSSEC deverá estar ativada e usar o conjunto de chaves de assinatura de chave raiz do DNS da IANA (disponível em xxxxx://xxx.xxxx.xxx/xxxxxx/xxxxx) como uma âncora de confiança dos Serviços de registro do Operador de Registro que fizer uso dos dados obtidos por meio de respostas de DNS.

1.4. IDNs. Se o Operador de Registro oferecer Nomes de Domínio Internacionalizados (“IDNs”), ele deverá manter conformidade com as RFCs 5890, 5891, 5892, 5893 e posteriores. O Operador de Registro deverá cumprir as Diretrizes de IDN da ICANN em xxxxx://xxx.xxxxx.xxx/xx/xxxxxx/xxx/xxxxxxxxxxxxxx-xxxxxxxxxx.xxx, sendo que elas poderão ser alteradas, modificadas ou substituídas ao longo

do tempo. O Operador de Registro deverá publicar e manter atualizadas suas tabelas de IDNs e Regras de Registro de IDNs no Repositório de práticas de IDNs da IANA.

1.5. IPv6. O Operador de Registro deverá ser capaz de aceitar endereços IPv6 como registros agregados em seu Sistema de Registro e publicá-los no DNS. O Operador de Registro deverá oferecer transporte IPv6 público a, pelo menos, dois dos servidores de nomes do Registro relacionados na zona raiz com os endereços IPv6 correspondentes registrados na IANA. O Operador de Registro deverá seguir as “Diretrizes operacionais de transporte de IPv6 do DNS”, conforme descrito na BCP 91 e as recomendações e considerações descritas na RFC 4472. O Operador de Registro deverá oferecer, além de transporte IPv4, transporte IPv6 público para seus Serviços de Diretório de Dados de Registro, conforme definido na Especificação 4 deste Contrato; por exemplo, WHOIS (RFC 3912), WHOIS baseado na web e RDAP. O Operador de Registro deverá oferecer transporte IPv6 público a seu Sistema de Registro Compartilhado (SRS) a qualquer Registrador, o mais tardar seis (6) meses após o recebimento da primeira solicitação por escrito de um registrador credenciado do gTLD disposto a operar com o SRS no IPv6.

1.6. Banco de dados da zona raiz da IANA. A fim de garantir que as informações confiáveis sobre o TLD permaneçam publicamente disponíveis, o Operador de Registro deverá enviar uma solicitação de alteração ao operador de funções da IANA atualizando todos os registros desatualizados ou incorretos de DNS, do WHOIS ou da URL base do RDAP do serviço de RDAP do TLD. O Operador de Registro deverá empregar iniciativas comercialmente razoáveis para enviar qualquer uma dessas solicitações de alteração em até sete (7) dias consecutivos após a data em que qualquer registro do DNS, do WHOIS ou da URL base do RDAP do serviço de RDAP se tornar desatualizado ou incorreto. O Operador de Registro deverá enviar todas as solicitações de alteração de acordo com os procedimentos estabelecidos em xxxxx://xxx.xxxx.xxx/xxxxxxx/xxxx .

1.7. Filtragem de entrada de rede. O Operador de Registro deverá implementar as verificações de filtragem de entrada de rede de seus Serviços de registro conforme descrito na BCP 38 e BCP 84, que a ICANN também implementará.

2. Serviços de registro

2.1. Serviços de registro. Os "Serviços de registro" são, para efeitos do Contrato, definidos conforme segue: (a) os serviços que são operações do registro essenciais para as seguintes tarefas: o recebimento de dados de registradores relativos aos registros de nomes de domínio e servidores de nomes; o fornecimento, aos registradores, das informações de status referentes aos servidores de zona do TLD; a divulgação dos arquivos da zona de TLD; a operação dos servidores de DNS do registro; e a divulgação do contato e outras informações sobre os registros do servidor de nomes de domínio no TLD, conforme exigido pelo presente Contrato; (b) outros produtos ou serviços que o Operador de Registro é obrigado a fornecer devido ao estabelecimento de uma Política Consensual, conforme definido na Especificação 1; (c) quaisquer outros produtos ou serviços que apenas um operador de registro é capaz de fornecer em razão de sua designação como operador de registro; e (d) alterações significativas em qualquer Serviço de registro no âmbito de (a), (b) ou (c) acima.

2.2. Proibição de caracteres-curinga. Para nomes de domínio que não estejam registrados, ou para os quais o registrante não tenha fornecido registros válidos, como registros NS para a inclusão no arquivo da zona de DNS, ou cujo status não permita que sejam publicados no DNS, é proibido o uso dos Registros de recursos de caracteres-curinga do DNS, conforme descrito nas RFCs 1034 e 4592, ou de qualquer outro método ou tecnologia para a síntese de Registros de recursos do DNS ou que use o redirecionamento dentro do DNS pelo Registro. Quando consultados por esses nomes de domínio, os servidores de nomes autorizados deverão retornar uma resposta “Erro de nome" (também conhecida como NXDOMAIN), RCODE 3, conforme descrito na RFC 1035 e RFCs relacionadas. Esta disposição se aplica a todos os arquivos da zona de DNS em todos os níveis na árvore do DNS para os quais o Operador de Registro (ou um afiliado envolvido no fornecimento de Serviços de registro) mantém dados, organiza tal manutenção ou obtém receita com base nessa manutenção.

3. Continuidade do registro

3.1. Alta disponibilidade. O Operador de Registro realizará suas operações usando servidores de rede redundantes e variados geograficamente (inclusive a redundância em nível de rede, a redundância em nível de extremidade do nó e a implementação de um esquema de balanceamento de cargas, quando aplicável) para garantir o funcionamento contínuo em caso de falha técnica (generalizada ou local), ou de uma circunstância

extraordinária ou fora do controle do Operador de Registro. O departamento de operações de emergência do Operador de Registro deverá estar disponível em todos os momentos para responder a circunstâncias extraordinárias.

3.2. Evento extraordinário. O Operador de Registro envidará esforços comercialmente razoáveis para restaurar as funções críticas do registro no prazo de vinte e quatro (24) horas após o término de um evento extraordinário, que esteja fora do controle do Operador de Registro, e restaurará a funcionalidade completa do sistema no prazo máximo de quarenta e oito (48) horas após o evento, dependendo do tipo de função crítica envolvida. Interrupções causadas por um evento dessa natureza não serão consideradas como falta de disponibilidade do serviço.

3.3. Continuidade dos negócios. O Operador de Registro deverá manter um plano de continuidade dos negócios, que contemplará a manutenção dos Serviços de registro, no caso de um evento extraordinário, fora do controle do Operador de Registro, ou de uma falha nos negócios do Operador de Registro, e poderá incluir a designação de um provedor de continuidade dos Serviços de registro. Caso esse plano inclua a designação de um provedor de continuidade dos Serviços de registro, o Operador de Registro deverá fornecer o nome e as informações de contato desse provedor de continuidade dos Serviços de registro para a ICANN. No caso de um evento extraordinário, fora do controle do Operador de Registro, em que seja impossível fazer contato com o Operador de Registro, o Operador de Registro concorda que a ICANN poderá entrar em contato com o provedor de continuidade de Serviços de registro designado, se houver. O Operador de Registro deverá realizar testes de continuidade dos Serviços de registro pelo menos uma vez por ano.

4. Mitigação de abusos

4.1. Contato de abuso. O Operador de Registro deverá fornecer à ICANN e publicar em seu site os detalhes de contato precisos, contendo um endereço de e-mail válido ou formulário eletrônico e um endereço para correspondência, bem como um contato principal para tratar de denúncias relacionadas a conduta maliciosa no TLD, inclusive Abusos no DNS, e enviará um aviso à ICANN imediatamente sobre qualquer alteração nesses detalhes de contato. Ao receber denúncias dessa natureza, o Operador de Registro deverá enviar ao denunciante uma confirmação de recebimento.

Para os fins do presente Contrato, “Abusos no DNS” se referem a malware, botnets, phishing, pharming e spam (quando spam for usado como um mecanismo de entrega para as outras formas de Abusos no DNS relacionadas nesta Seção), conforme a definição desses termos na Seção 2.1 do SAC115 (<xxxxx://xxx.xxxxx.xxx/xx/xxxxxx/xxxxx/xxxxx/xxx-000-xx.xxx>).

4.2. Mitigação de abusos do DNS. Quando um Operador de Registro determinar de maneira razoável, com base em evidências acionáveis, que um nome de domínio registrado no TLD está sendo usado para Abusos no DNS, o Operador de Registro deverá imediatamente tomar a(s) ação(ões) de mitigação apropriada(s) razoavelmente necessária(s) para ajudar a impedir ou de alguma forma impossibilitar que o nome de domínio seja usado para Abusos no DNS. Essa(s) ação(ões) deverá(ão), no mínimo, incluir: (i) a indicação dos domínios sendo usados para o Abuso no DNS, juntamente com as evidências relevantes, ao registrador patrocinador; ou (ii) uma ação direta do Operador de Registro, quando o Operador de Registro considerar apropriado. A(s) ação(ões) poderá(ão) variar, dependendo das circunstâncias de cada caso, considerando-se a gravidade do prejuízo causado pelo Abuso no DNS e a possibilidade de danos colaterais associados.

4.3. Uso malicioso de registros órfãos agregados. O Operador de Registro deverá tomar medidas para remover registros órfãos agregados (conforme definido em xxxxx://xxx.xxxxx.xxx/xx/xxxxxxxxxx/xxxxxxxx/xxx000.xxx) quando apresentado com provas por escrito de que tais registros tenham conexão com uma conduta maliciosa.

5. Períodos de registro inicial e de renovação aceitos

5.1. Períodos de registro inicial. Os registros iniciais de nomes registrados poderão ser feitos no registro em incrementos de um (1) ano, até no máximo dez (10) anos. Para evitar dúvidas, os registros iniciais dos nomes registrados não poderão ultrapassar 10 (dez) anos.

5.2. Períodos de renovação. A renovação dos nomes registrados poderá ser feita em incrementos de um (1) ano, até no máximo dez (10) anos. Para evitar dúvidas, a renovação de nomes registrados não poderá estender seu período de registro por mais de dez (10) anos a partir da data da renovação.

6. Gerenciamento de ocorrências de colisões de nomes

6.1. Período de não ativação. O Operador de Registro não deverá ativar nenhum nome na zona de DNS do TLD de Registro (exceto para “NIC”) até 120 dias consecutivos, no mínimo, a partir da data de início de vigência deste contrato. O Operador de Registro poderá alocar nomes (sujeito à subseção 6.2) durante esse período, apenas se o Operador de Registro informar claramente aos registrantes sobre a impossibilidade de ativar os nomes até o término do Período de não ativação.

6.2. Avaliação de ocorrência de colisões de nomes

6.2.1 O Operador de Registro não deverá ativar nenhum nome na zona de DNS do TLD de Registro, exceto de acordo com uma Avaliação de ocorrência de colisões de nomes fornecida pela ICANN em relação ao

TLD de Registro. O Operador de Registro (A) implementará as medidas de mitigação descritas em sua Avaliação de ocorrência de colisões de nomes antes de ativar qualquer nome de domínio de segundo nível, ou (B) bloqueará os nomes de domínio de segundo nível para os quais as medidas de mitigação, conforme descrito na Avaliação de ocorrência de colisões de nomes, não foram implementadas, e prosseguirá com a ativação de nomes que não estiverem relacionados na Avaliação.

6.2.2 Não obstante a subseção 6.2.1, o Operador de Registro poderá prosseguir com a ativação de nomes na zona de DNS sem a implementação das medidas estabelecidas na Seção 6.2.1, somente se

(A) a ICANN determinar que o TLD de Registro está qualificado para esse caminho alternativo de ativação de nomes; e (B) o Operador de Registro bloquear todos os nomes de domínio de segundo nível identificados pela ICANN e estabelecidos em xxxxx://xxxxxxxx.xxxxx.xxx/xx/xxxxxxxxxxxxx-xxx- media/announcement-2-17nov13-en, sendo que essa lista poderá ser modificada pela ICANN esporadicamente. O Operador de Registro poderá ativar nomes nos termos da presente subseção e, posteriormente, ativar os nomes nos termos da subseção 6.2.1.

6.2.3 Os conjuntos de nomes sujeitos a mitigação ou bloqueio em conformidade com as Seções 6.2.1 e 6.2.2 serão baseados na análise de informações do DNS pela ICANN, inclusive os dados do “Day in the Life of the Internet” (“Dia na Vida da Internet”, em tradução livre) mantidos pelo Centro de Investigação e Análise de Operações do Sistema de Nomes de Domínio (DNS-OARC) xxxxx://xxx.xxx- xxxx.xxx/xxxx/xxxx/xxxx .

6.2.4 O Operador de Registro poderá participar, pela comunidade da ICANN, do desenvolvimento de um processo para determinar se e como esses nomes bloqueados poderão ser disponibilizados.

6.2.5 Se a ICANN determinar que o TLD não está qualificado para o caminho alternativo de ativação de nomes, a ICANN poderá optar por não delegar o TLD até a conclusão da Avaliação final de ocorrência de colisões de nomes para o TLD e a conclusão de todas as medidas de mitigação necessárias pelo Operador de Registro. O Operador de Registro entende que as medidas de mitigação exigidas pela ICANN como uma condição para a ativação de nomes na zona do DNS para o TLD poderão incluir, entre outras, medidas de mitigação, como as descritas na Seção 3.2 do Plano de Gerenciamento de Ocorrências de Colisões de Nomes de Novos gTLDs, aprovado pelo Comitê do Programa de Novos gTLDs (NGPC) da Diretoria da ICANN em 7 de outubro de 2013, conforme encontrado em

xxxxx://xxx.xxxxx.xxx/xx/xxxxxx/xxxxx/xxxxxxxxx/xxxxxxxxxxx- new-gtld-annex-1-07oct13-en.pdf.

6.3. Administração do relatório de colisões de nomes

6.3.1 Durante os primeiros dois anos após a delegação do TLD, o departamento de operações de emergência do Operador de Registro deverá estar disponível para receber relatórios, retransmitidos pela ICANN, alegando danos comprovadamente prejudiciais das colisões com sobreposição de uso dos nomes fora do DNS autorizado.

6.3.2 O Operador de Registro deverá desenvolver um processo interno para administrar os relatórios recebidos de modo rápido nos termos da subseção 6.3.1, sendo que o Operador de Registro poderá, na medida em que for necessário e adequado, remover um nome recentemente ativado da zona de TLD por um período de até dois anos, a fim de permitir que a parte afetada faça alterações em seus sistemas.

ESPECIFICAÇÃO 7

REQUISITOS MÍNIMOS PARA OS MECANISMOS DE PROTEÇÃO DE DIREITOS

1. Mecanismos de proteção de direitos. O Operador de Registro deverá implementar e respeitar os Mecanismos de Proteção de Direitos (“RPMs”) detalhados nesta Especificação. Além desses RPMs, o Operador de Registro poderá desenvolver e implementar outros RPMs que desestimulem ou impeçam o registro de nomes de domínio que infrinjam ou violem os direitos legais de outra parte. O Operador de Registro incluirá todos os RPMs exigidos por esta Especificação 7 e quaisquer outros RPMs desenvolvidos e implementados pelo Operador de Registro no Contrato entre Registros e Registradores celebrado entre registradores credenciados pela ICANN, autorizados a registrar nomes no TLD. O Operador de Registro deverá implementar, de acordo com os requisitos lá estabelecidos, cada um dos RPMs obrigatórios definidos no Centro de Informações de Marcas a partir da data deste documento, conforme publicado em xxxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/xxxx- requirements (os “Requisitos do Centro de Informações de Marcas”), que poderão ser revistos em aspectos irrelevantes pela ICANN esporadicamente. O Operador de Registro não poderá exigir que nenhum proprietário dos direitos de propriedade intelectual aplicáveis use nenhuma outra agregação de informações de marca registrada, notificação ou serviço de validação, além do Centro de Informações de Marcas designado pela ICANN ou no lugar desse. No caso de conflito entre os termos e as condições deste Contrato e os Requisitos do Centro de Informações de Marcas, os termos e as condições do presente Contrato deverão prevalecer. O Operador de Registro deverá celebrar um Contrato entre Registros e Registradores com pelo menos um registrador credenciado pela ICANN autorizando esse(s) registrador(es) a registrar nomes de domínio no TLD da seguinte forma:

a. se o Operador de Registro realizar um programa de lançamento qualificado ou for autorizado pela ICANN a realizar um programa de lançamento aprovado (cujos termos estão definidos nos requisitos do Centro de Informações de Marcas), o Operador de Registro deverá celebrar um Contrato entre Registros e Registradores vinculativo e aplicável com pelo menos um registrador credenciado pela ICANN antes de alocar qualquer nome de domínio, de acordo com esse programa de lançamento qualificado ou programa de lançamento aprovado, conforme o caso;

b. se o Operador de Registro não realizar um programa de lançamento qualificado ou não for autorizado pela ICANN a realizar um programa de lançamento aprovado, o Operador de Registro deverá celebrar um Contrato entre Registros e Registradores vinculativo e aplicável com pelo menos um registrador credenciado pela ICANN no mínimo trinta (30) dias consecutivos antes da data de expiração do Período Experimental (conforme definido nos requisitos do Centro de Informações de Marcas) do TLD; ou

c. se este Contrato contiver uma Especificação 13, o Operador de Registro deverá celebrar um Contrato entre Registros e Registradores vinculativo e aplicável com pelo menos um registrador credenciado pela ICANN antes da Data de início das reivindicações (conforme definido na Especificação 13).

Nenhuma cláusula da Especificação 7 limitará ou isentará qualquer outra obrigação ou requisito deste Contrato aplicável ao Operador de Registro, inclusive a

Seção 2.9(a) e a Especificação 9.

2. Mecanismos de resolução de disputas. O Operador de Registro cumprirá os seguintes mecanismos de resolução de disputas, que poderão ser revisados esporadicamente:

a. o Procedimento de Resolução de Disputas Pós-delegação de Marcas (PDDRP) e o Procedimento de Resolução de Disputas de Restrição de Registro (RRDRP), adotados pela ICANN (publicados em xxxxx://xxx.xxxxx.xxx/xxxxx e xxxxx://xxx.xxxxx.xxx/xxxxx, respectivamente). O Operador de Registro concorda em implementar e respeitar qualquer solução imposta pela ICANN (que poderá abranger qualquer solução razoável, inclusive, para que não restem dúvidas, a rescisão do Contrato de Registro nos termos da Seção 4.3(e) do Contrato), seguindo uma determinação de qualquer painel de PDDRP ou RRDRP e em se comprometer com tal determinação; e

b. o sistema de Suspensão Rápida Uniforme (“URS”), adotado pela ICANN (publicado em xxxxx://xxx.xxxxx.xxx/xxx), inclusive a implementação das determinações emitidas pelos examinadores de URS.

ESPECIFICAÇÃO 8 INSTRUMENTO DE OPERAÇÕES CONTÍNUAS.

1. O Instrumento de Operações Contínuas deverá (a) fornecer recursos financeiros

suficientes para garantir a continuidade da operação das funções críticas de registro relacionadas ao TLD, estabelecidas na Seção 6 da Especificação 10 do presente Contrato, por um período de 3 (três) anos a partir da rescisão do presente Contrato ou antes do quinto ano a contar da Data de início de vigência, ou por um período de um (1) ano após a rescisão deste Contrato, após o quinto ano da Data de início de vigência, mas antes de seis (6) anos da Data de início de vigência ou nessa data, e (b) estar na forma de (i) uma carta de crédito de garantia irrevogável, ou (ii) depósito judicial em dinheiro irrevogável, cada um de acordo com os requisitos estabelecidos no item 50(b) do Anexo ao Módulo 2 – Perguntas e critérios de avaliação – do Manual do Solicitante de gTLDs, conforme publicado e complementado pela ICANN antes da data determinada (incorporada para referência a esta Especificação 8). O Operador de Registro envidará seus melhores esforços para tomar todas as medidas necessárias ou aconselháveis para manter em vigor o Instrumento de Operações Contínuas por um período de 6 (seis) anos a partir da Data de início de vigência e manter a ICANN como um terceiro beneficiário deste. Se o Operador de Registro optar por obter uma carta de crédito de garantia irrevogável, mas o prazo exigido acima não for viável, o Operador de Registro poderá obter uma carta de crédito com o prazo de um ano e uma “condição permanente", que prevê extensões anuais, sem alterações, para um número indefinido de períodos adicionais até que o banco emissor informe à ICANN sobre seu vencimento final ou até que a ICANN libere a carta de crédito, conforme evidenciado por escrito, se a carta de crédito de outra forma atender aos requisitos previstos no item 50(b) do Anexo ao Módulo 2 – Perguntas e critérios de avaliação – do Manual do Solicitante de gTLDs, conforme publicado e complementado pela ICANN antes desta data, desde que, no entanto, o banco emissor informe à ICANN sobre o vencimento desta carta de crédito antes do sexto (6º) ano da Data de início de vigência, esta carta de crédito deverá prever que a ICANN tenha o direito de sacar os fundos garantidos pela carta de crédito antes desse vencimento. A carta de crédito deverá exigir que o banco emissor conceda à ICANN um aviso com pelo menos 30 (trinta) dias consecutivos de antecedência de qualquer expiração ou não renovação. Se a carta de crédito expirar ou for rescindida a qualquer momento antes de seis anos da Data de início de vigência, o Operador de Registro será obrigado a obter uma substituição para o Instrumento de Operações Contínuas. A ICANN poderá sacar os fundos da carta de crédito original, se a substituição do Instrumento de Operações Contínuas não estiver em vigor antes do vencimento da carta de crédito original. O Operador de Registro deverá fornecer à ICANN cópias de todos os documentos finais relativos ao Instrumento de Operações Contínuas e manter a ICANN razoavelmente informada dos fatos relevantes relativos ao Instrumento de Operações Contínuas. O Operador de Registro não deverá concordar com nenhuma alteração ou isenção, nem autorizá-las, nos termos do Instrumento de Operações Contínuas ou de outro documento relativo a este, sem

o consentimento prévio por escrito da ICANN (tal consentimento não deverá ser negado sem razão).

2. Se, no entanto, o uso dos melhores esforços por parte do Operador de Registro em atender às suas obrigações nos termos do parágrafo anterior, o Instrumento de Operações Contínuas vencer ou for rescindido por outra parte, no todo ou em parte, por qualquer motivo, antes do sexto ano a contar da Data de início de vigência, o Operador de Registro deverá imediatamente (i) notificar a ICANN sobre tal vencimento ou rescisão e os motivos deste e (ii) providenciar um instrumento alternativo que forneça os recursos financeiros suficientes para garantir a continuidade da operação das funções críticas de registro relacionadas ao TLD, estabelecidas na Seção 6 da Especificação 10 do presente Contrato, por um período de 3 (três) anos a partir da rescisão do presente Contrato ou antes do quinto ano a contar da Data de início de vigência ou por um período de um (1) ano após a rescisão deste Contrato, após cinco anos da Data de início de vigência, mas antes ou no sexto (6º) ano da Data de início de vigência (um “Instrumento alternativo”). Qualquer Instrumento alternativo deverá estar nos termos não menos favoráveis à ICANN do que o Instrumento de Operações Contínuas e, além disso, em forma e substância razoavelmente aceitável pela ICANN.

3. Não obstante qualquer disposição em contrário contida nesta Especificação 8, a qualquer momento, o Operador de Registro poderá substituir o Instrumento de Operações Contínuas por um Instrumento alternativo que (i) forneça os recursos financeiros suficientes para garantir a operação contínua das funções críticas de registro relacionadas ao TLD, estabelecidas na Seção 6 da Especificação 10 do presente Contrato, por um período de 3 (três) anos após a rescisão deste Contrato no quinto ano da Data de início de vigência ou antes deste, ou por um (1) período de um ano após a rescisão do presente Contrato após cinco anos da Data de início de vigência, mas antes ou no sexto (6º) ano da Data de início de vigência, e (ii) conter os termos não menos favoráveis à ICANN do que o Instrumento de Operações Contínuas e estar em forma e substância razoavelmente aceitável pela ICANN. No caso do Operador de Registro substituir o Instrumento de Operações Contínuas nos termos do parágrafo 2 ou deste parágrafo 3, os termos desta Especificação 8 deixam de ser aplicados no que diz respeito ao Instrumento de Operações Contínuas original, mas deverão ser aplicados, posteriormente, em relação ao(s) Instrumento(s) alternativo(s), e tal instrumento será posteriormente considerado o Instrumento de Operações Contínuas para os efeitos deste Contrato.

ESPECIFICAÇÃO 9

CÓDIGO DE CONDUTA DO OPERADOR DE REGISTRO

1. Em conexão com a operação do registro para o TLD, o Operador de Registro não permitirá que nenhum subcontratado principal, subsidiário, afiliado ou outra entidade relacionada, na medida em que essa parte esteja envolvida na prestação de Serviços de registro com relação ao TLD (cada um, “Parte relacionada ao registro”), a:

a. direta ou indiretamente, demonstrar preferência ou fornecer qualquer consideração especial a qualquer registrador em relação ao acesso operacional aos sistemas de registro e serviços de registro relacionados, a menos que sejam disponibilizadas a todos os registradores oportunidades comparáveis para se qualificar a tais preferências ou considerações em termos e sujeito substancialmente semelhantes a condições substancialmente semelhantes;

b. registrar nomes de domínio em seu próprio direito, com exceção de nomes registrados por meio de um registrador credenciado pela ICANN, desde que, no entanto, o Operador de Registro possa (a) reservar nomes de registro nos termos da Seção 2.6 do Contrato e (b) reter o registro ou alocar para o Operador de Registro até cem (100) nomes de acordo com a Seção 3.2 da Especificação 5;

c. registrar nomes no TLD ou em subdomínios do TLD com base em acesso exclusivo a informações sobre pesquisas ou solicitações de resolução de nomes de domínio por parte de clientes ainda não registrados (conhecidos como “front-running”); ou

d. permitir que qualquer registrador Afiliado divulgue dados pessoais sobre os registrantes ao Operador de Registro ou a qualquer Parte relacionada ao registro, exceto conforme razoavelmente necessário para a gestão e as operações do TLD, a menos que todos os terceiros não relacionados (inclusive outros operadores de registro) tenham acesso equivalente a esses dados de usuário em termos substancialmente semelhantes e sujeito a condições substancialmente semelhantes.

2. Se o Operador de Registro ou uma Parte relacionada ao registro também atuar como prestador de serviços de registrador ou registrador-revendedor, o Operador de Registro fará com que essa Parte relacionada ao registro garanta que esses serviços sejam oferecidos por meio de uma entidade jurídica separada do Operador de Registro e mantenha livros de contas separados no que diz respeito às operações de seu registrador ou registrador-revendedor.

3. Se o Operador de Registro ou uma Parte relacionada ao registro também atuar como prestador de serviços de registrador ou registrador-revendedor, o Operador de

Registro fará revisões internas pelo menos uma vez por ano-calendário para assegurar a conformidade com este Código de Conduta. Dentro de vinte (20) dias consecutivos após o final de cada ano-calendário, o Operador de Registro fornecerá os resultados da revisão interna, juntamente com uma certificação executada por um diretor executivo do Operador de Registro atestando a conformidade do Operador de Registro com este Código de Conduta, via e-mail para um endereço a ser fornecido pela ICANN. (a ICANN poderá especificar no futuro a forma e o conteúdo desses relatórios ou que os relatórios sejam entregues por outros meios razoáveis.) O Operador de Registro concorda que a ICANN poderá divulgar publicamente esses resultados e certificação, desde que, no entanto, a ICANN não divulgue informações confidenciais contidas nesses resultados, exceto em conformidade com a Seção 7.15 do Contrato.

4. Nada do que consta no presente documento deverá: (i) limitar a ICANN de realizar investigações de alegações de não conformidade do Operador de Registro com este Código de Conduta, ou (ii) fornecer motivos para o Operador de Registro se recusar a cooperar com as investigações da ICANN sobre alegações de não conformidade do Operador de Registro com este Código de Conduta.

5. Nada do que consta no presente documento deverá limitar a capacidade do Operador de Registro, ou de qualquer Parte relacionada ao registro, de participar de transações independentes no curso normal dos negócios com um registrador ou revendedor em relação aos produtos e serviços não relacionados em todos os aspectos ao TLD.

6. O Operador de Registro poderá solicitar uma isenção a este Código de Conduta, e tal isenção poderá ser concedida pela ICANN, a critério razoável da ICANN, se o Operador de Registro demonstrar, de maneira razoavelmente satisfatória para a ICANN, que (i) todos os registros de nomes de domínio no TLD estão registrados para o Operador de Registro, e mantidos por ele, para o uso exclusivo do Operador de Registro ou seus Afiliados, (ii) o Operador de Registro não vende, distribui nem transfere o controle ou uso de quaisquer registros no TLD a qualquer terceiro que não seja um Afiliado do Operador de Registro e (iii) a aplicação deste Código de Conduta para o TLD não for necessária para proteger o interesse público.

ESPECIFICAÇÃO 10

ESPECIFICAÇÕES DE DESEMPENHO DO REGISTRO

1. Definições

1.1. DNS. Refere-se ao Sistema de Nomes de Domínio, conforme especificado nas RFCs 1034, 1035 e RFCs relacionadas.

1.2. Resolução adequada de DNSSEC. Há uma cadeia de confiança de DNSSEC válida que começa na âncora de confiança de raiz para um nome de domínio específico, por exemplo, um TLD, um nome de domínio registrado sob um TLD etc.

1.3. EPP. Refere-se ao Protocolo de Provisionamento Extensível, conforme especificado na RFC 5730 e RFCs relacionadas.

1.4. Endereço IP. Refere-se aos endereços IPv4 ou IPv6 sem haver nenhuma distinção entre os dois. Quando for necessário haver uma distinção, serão usados IPv4 ou IPv6.

1.5. Sondas. Hosts de rede usados para realizar testes (DNS, EPP etc.) (veja abaixo) e que estão localizados em todo o mundo.

1.6. [Omissão intencional]

1.7. RTT. Round-Trip Time, ou RTT, refere-se ao tempo medido desde o envio do primeiro bit do primeiro pacote da sequência de pacotes necessária para fazer uma solicitação até o recebimento do último bit do último pacote da sequência necessária para receber a resposta. Se o cliente não receber toda a sequência de pacotes necessária para considerar a resposta como recebida, a solicitação será considerada como sem resposta.

1.8. SLR. O Requisito de Nível de Serviço (SLR, Service Level Requirement) é o nível de serviço esperado para um certo parâmetro sendo medido em um Contrato de Nível de Serviço (SLA, Service Level Agreement).

1.9. RDAP-RDDS. Refere-se aos Serviços de Diretório do Protocolo de Acesso a Dados de Registro (RDAP), conforme definido na Especificação 4 deste Contrato.

1.10. WHOIS-RDDS e Serviços de Diretório de Xxxxx do WHOIS. Refere-se coletivamente ao WHOIS e aos serviços do WHOIS baseados na web, conforme definido na Especificação 4 deste Contrato.

2. Matriz do Contrato de Nível de Serviço

2.1. No que diz respeito ao TLD, o Operador de Registro deverá atender ou exceder cada um dos seguintes Contratos de Nível de Serviço (SLRs) relacionados ao DNS, EPP e serviços de RDAP-RDDS*:

	Parâmetro	SLR (mensal)
DNS	Disponibilidade do serviço de DNS	tempo de inatividade de 0 min = 100% de disponibilidade
	Disponibilidade do servidor de nomes do DNS	≤ tempo de inatividade de 432 min (≈ 99%)
	RTT de resolução de DNS TCP	≤ 1500 ms de pelo menos 95% das consultas
	RTT de resolução de DNS UDP	≤ 500 ms de pelo menos 95% das consultas
	Tempo de atualização do DNS	≤ 60 min de pelo menos 95% das sondas
EPP	Disponibilidade do serviço de EPP	≤ tempo de inatividade de 864 min (≈ 98%)
	RTT de comando da sessão de EPP	≤ 4000 ms de pelo menos 90% dos comandos
	RTT do comando de consulta de EPP	≤ 2000 ms de pelo menos 90% dos comandos
	RTT do comando de transformação de EPP	≤ 4000 ms de pelo menos 90% dos comandos
RDAP-RDDS*	Disponibilidade do RDAP	≤ tempo de inatividade de 864 min (≈ 98%)
	RTT de consulta do RDAP	≤ 4000 ms de pelo menos 95% das consultas
	Tempo de atualização do RDAP	≤ 60 min de pelo menos 95% das sondas

*Esses SLRs para RDAP-RDDS não são obrigatórios até a expiração do Período de Preparação do RDAP.

2.2. O Operador de Registro é incentivado a fazer a manutenção de diversos serviços em horas e datas que estatisticamente apresentem o menor tráfego de cada serviço. No entanto, observe que não há previsão para interrupções planejadas ou períodos semelhantes de serviço indisponível ou lento; qualquer tempo de inatividade, seja para manutenção ou devido a falhas do sistema, será observado apenas como tempo de inatividade e contabilizado para fins de medição do SLR.

2.3. No que diz respeito ao TLD, até a Data de Descontinuação dos Serviços de WHOIS, o Operador de Registro deverá atender ou exceder cada um dos seguintes SLRs relacionados Serviços de Diretório de Dados do WHOIS:

	Parâmetro	SLR (mensal)
WHOIS-RDDS	Disponibilidade do WHOIS-RDDS	≤ tempo de inatividade de 864 min (≈ 98%)
	RTT de consulta do WHOIS- RDDS	≤ 2000 ms de pelo menos 95% das consultas
	Tempo de atualização do WHOIS-RDDS	≤ 60 min de pelo menos 95% das sondas

Document Metadata

Table of Contents

CONTRATO DE REGISTRO

Document Metadata