CONTRATO DE REGISTRO

CONTRATO DE REGISTRO

Este CONTRATO DE REGISTRO (este “Contrato”) é celebrado a partir de ___ (a “Data de Vigência”) entre a Internet Corporation for Assigned Names and Numbers, empresa sem fins lucrativos com sede Califórnia (“ICANN”), e ___ , um _

(“Operador de registro”).

ARTIGO 1.

DELEGAÇÃO E OPERAÇÃO

DE DOMÍNIO DE PRIMEIRO NÍVEL; REPRESENTAÇÕ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 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 Operador de registro como o operador de registro para o TLD, sujeito aos requisitos e aprovações necessárias para delegaçã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, determinadas cadeias de caracteres de domínios de primeiro nível podem encontrar dificuldade na aceitação pelos ISPs e Web hosters e/ou validação pelos 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 de TLD antes de assinar este Contrato.

1.3 Representações e garantias.

(a) O Operador de registro declara e garante à ICANN o seguinte:

(i) toda informação relevante fornecida e as declarações feitas no aplicativo de registro TLD e 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 na Data de vigência, exceto quando divulgado de outra forma anteriormente por escrito pelo Operador de registro da ICANN;

(ii) o Operador de registro se encontra 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 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 para TLD no caso de rescisão ou expiração deste Contrato

(o "Instrumento de operações contínuas"), e tal instrumento é uma obrigação vinculativa das partes a ele relacionadas, exequível contra as partes a ele relacionadas em conformidade com seus termos.

(b) A ICANN declara e garante ao Operador de registro que a ICANN é uma empresa 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 poder e autoridade necessários e obteve todas as aprovações corporativas necessárias para celebrar e executar devidamente este Contrato.

ARTIGO 2.

DECLARAÇÃO DO OPERADOR DE REGISTRO

O Operador de registro declara 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 na 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 deseja fornecer qualquer Serviço de registro que não seja um serviço aprovado ou que seja 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 para aprovação de tal serviço adicional de acordo com a Política de avaliação de serviços de registro em xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxxx/xxxx/xxxx.xxxx, já que tal política pode ser aditada esporadicamente de acordo com os estatutos da ICANN (conforme aditado ocasionalmente, os "Estatutos da ICANN") aplicáveis às Políticas de consenso ("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, tais 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 refletindo a prestação de qualquer Serviço adicional que seja aprovado de acordo com a RSEP, cujo aditamento deverá ser em uma forma razoavelmente aceitável para as partes.

2.2 Conformidade com políticas de consenso e políticas temporárias. O Operador de registro cumprirá e implementará todas as Políticas de consenso e políticas temporárias localizadas em <xxxx://xxx.xxxxx.xxx/xxxxxxx/xxxxxxxxx-xxxxxxxx.xxx>, a partir da data de início da vigência e que poderão ser desenvolvidas e adotadas no futuro de acordo com os Estatutos da ICANN, contanto que essas Políticas de consenso e políticas temporárias sejam adotadas de acordo com os procedimentos e estejam relacionadas aos tópicos e sujeitas às limitações dispostas na Especificação 1 anexa ao presente ("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 aqui anexa ("Especificação 2").

2.4 Relatórios mensais. Dentro de vinte (20) dias consecutivos após o final de cada mês civil, o Operador de registro deverá submeter à ICANN relatórios no formato estabelecido na Especificação 3 anexa ao presente ("Especificação 3").

2.5 Publicação dos dados de registro. O Operador de registro providenciará acesso público para dados de registro em conformidade com a Especificação 4 aqui anexa ("Especificação 4").

2.6 Nomes reservados. A menos que a ICANN expressamente autorize por escrito de outra forma, o Operador de registro deverá cumprir os requisitos estabelecidos na Especificação 5 anexa ao presente ("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 registro ou alocação de Operador de registro, mas não registrar a terceiros, delegar, usar, ativar no DNS ou disponibilizar de outra forma) ou bloquear cadeias de caracteres adicionais dentro do TLD a seu critério. Exceto como especificado na Especificação 5, se o Operador de registro for o registrante de quaisquer nomes de domínio no TLD de registro, tais registros devem ser através de um registrador acreditado da ICANN e deverão ser considerados Transações (conforme definido na Seção 6.1) para fins de cálculo da taxa de transação de nível de registro a ser paga à ICANN pelo Operador de registro de acordo com a Seção 6.1.

2.7 Interoperabilidade e continuidade de registro. O Operador de registro deverá cumprir as Especificações de interoperabilidade e continuidade de registro conforme estabelecido na Especificação 6 aqui anexa ("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 proteção inicial existentes e relacionados a registro dos direitos legais de terceiros conforme estabelecido na Especificação 7 aqui anexa ("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 vigência deverão ser aprovadas previamente pela ICANN por escrito. O Operador de registro deverá estar em conformidade com todas as correções impostas pela ICANN conforme a Seção 2 da Especificação 7 sujeitas ao direito do Operador de registro de contestar tais correções conforme estabelecido no procedimento aplicável, descrito neste documento. O Operador de registro tomará as medidas razoáveis para investigar e responder a todos os relatórios, provenientes de agências paragovernamentais, governamentais e de imposição da lei, de conduta ilegal relacionada ao uso do TLD. Em resposta a esses relatórios, o Operador de registro não será obrigado a tomar nenhuma ação que contrarie a legislação pertinente.

2.9 Registradores.

(a) Todos os registros de nomes de domínio no TLD deverão ser realizados por meio de um registrador acreditado da ICANN, desde que o Operador de registro não precise utilizar um registrador, se registrar nomes em seu próprio nome para

retirar tais nomes da delegação, ou utilizar de acordo com a Seção 2.6. Sujeito aos requisitos da Especificação 11, o Operador de registro deverá fornecer acesso não discriminatório aos Serviços de registro a todos os registradores acreditados da ICANN que celebram e estão em conformidade com o Contrato entre registro e registrador para o TLD, desde que o Operador de registro possa estabelecer critérios não discriminatórios de qualificação para registrar nomes no TLD que estejam razoavelmente relacionados ao funcionamento apropriado do TLD. O Operador de registro deverá usar um contrato não discriminatório uniforme com todos os registradores autorizados para registrar nomes no TLD (o "Contrato entre registro e registrador"). O Operador de registro poderá aditar o Contrato entre registro e registrador esporadicamente, contanto que, entretanto, todas as revisões relevantes relacionadas a ele devam ser aprovadas pela ICANN antes de quaisquer revisões se tornarem efetivas e vinculadas para qualquer registrador. O Operador de registro fornecerá à ICANN e a todos os registradores autorizados a registrar nomes no TLD aviso por escrito de pelo menos quinze (15) dias consecutivos de quaisquer revisões para o Contrato entre Registro e registrador antes que tais revisões se tornem efetivas e vinculadas para qualquer registrador. Durante esse período, a ICANN determinará se as revisões propostas são irrelevantes, possivelmente relevantes ou de natureza relevante. Se a ICANN não tiver fornecido ao Operador de registro o aviso de sua determinação dentro do período de quinze (15) dias consecutivos, será considerado que a ICANN determinou que tais revisões propostas são de natureza irrelevante. Se a ICANN determinar, ou considerar-se que determinou, nos termos da Seção 2.9(a), que tais revisões são irrelevantes, o Operador de registro poderá adotar e implementar as revisões. Se a ICANN determinar que tais revisões são relevantes ou possivelmente relevantes, a ICANN posteriormente seguirá seu procedimento com relação à revisão e à aprovação de alterações nos Contratos entre registro e registrador em

<xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/xxx-xxxxxxxxx-xxxxxxxxx>, e tais revisões não poderão ser adotadas e implementadas até que sejam aprovadas pela ICANN.

(b) Se o Operador de registro (i) se tornar um Afiliado ou revendedor de um registrador acreditado da ICANN, ou (ii) subcontratar a prestação de quaisquer Serviços de registro para um registrador acreditado da ICANN, revendedor registrador ou qualquer um de seus respectivos afiliados, em qualquer um dos casos (i) ou (ii) acima, o Operador de registro avisará prontamente a ICANN sobre o contrato, transação ou outra disposição que tenha resultado de tal afiliação, relacionamento de revenda ou subcontrato, conforme seja aplicável, inclusive se for solicitado pela ICANN, cópias de qualquer contrato relacionado, desde que a ICANN trate tal contrato ou documentos relacionados que estejam adequadamente marcados como confidenciais (como disposto pela Seção 7.15) como Informação confidencial de operador de registro em conformidade com a Seção 7.15 (exceto que a ICANN poderá divulgar tal contrato e documentos relacionados a autoridades de concorrência relevante). A ICANN se reserva o direito, mas não a obrigação, de encaminhar todo contrato, documentos relacionados, transação ou outras disposições a autoridades de concorrência relevantes no caso de a ICANN determinar que tal contrato, documentos relacionados, transação ou outras disposições possam suscitar problemas de concorrência significativos nos termos da legislação aplicável. Se viável e apropriado sob as circunstâncias, a ICANN fornecerá ao Operador de registro aviso prévio antes de fazer qualquer referência a uma autoridade de concorrência.

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

2.10 Preço para serviços de registro.

(a) Com relação aos registros de nome de domínio iniciais, o Operador de registro deve fornecer à ICANN e a cada registrador acreditado da ICANN que tenha celebrado o contrato entre registro e registrador para o TLD aviso prévio por escrito de qualquer aumento de preço (inclusive como resultado da eliminação de quaisquer reembolsos, abatimentos, descontos, subordinação de produto ou outros programas que tiveram o efeito de reduzir o preço cobrado dos registradores, a menos que tais reembolsos, abatimentos, descontos, subordinação de produto ou outros programas sejam de duração limitada, que seja clara e ostensivamente divulgada ao registrador quando oferecida), não inferior a trinta (30) dias consecutivos. O Operador de registro deverá oferecer aos registradores a opção de obter registros de nome de domínio inicial para 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 à ICANN e a cada registrador acreditado da ICANN que tenha celebrado o Contrato entre registro e registrador para o TLD, aviso prévio por escrito de qualquer aumento de preço (inclusive como resultado da eliminação de quaisquer reembolsos, abatimentos, descontos, subordinação de produtos, programas de qualificação de marketing ou outros programas que tiveram o efeito de reduzir o preço cobrado dos registradores) não inferior a cento e oitenta (180) dias consecutivos. Não obstante a sentença anterior, com relação à renovação de registros de nome de domínio:

(i) o Operador de registro somente precisa fornecer aviso de trinta (30) dias consecutivos de qualquer aumento de preço se o preço resultante for menor ou igual a (A) para o período iniciado na Data de vigência e com encerramento em doze (12) meses após a Data de vigência, o preço inicial cobrado por registros no TLD, ou (B) para períodos subsequentes, um preço para o qual o Operador de registro forneceu um aviso de acordo com a primeira frase desta Seção 2.10(b) dentro do período de doze (12) meses antecedentes à data de vigência do aumento de preço proposto; e (ii) o Operador de registro não precisa fornecer aviso de nenhum aumento de preço para a imposição da Taxa de nível de registro variável estabelecida na Seção 6.3. O Operador de registro deverá oferecer aos registradores a opção de obter renovações de registros de nome de domínio ao preço atual (ou seja, o preço em prática 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 deve ter preços unificados para renovações de registros de nomes de domínios ("Preço de renovação"). Para os fins de determinação de Preço de renovação, o preço para cada renovação de registro de domínio deve 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 deve considerar a aplicação universal de quaisquer reembolsos, abatimentos, descontos, subordinação de produtos ou outros programas em prática no momento da renovação. Os requisitos anteriores desta Seção 2.10(c) não se aplicarão para (i) fins de determinar Preço de renovação se o registrador tiver fornecido ao Operador de registro a documentação que demonstra que o registrante aplicável concordou expressamente, em seu Contrato de registro, com o registrador para Preço de renovação mais alto no momento do registro inicial do nome de domínio após divulgação clara e visível de tal Preço de renovação para tal registrante, e (ii) 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 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 nos termos do qual o Operador de registro oferece Preço de renovação com desconto desde que cada um dos seguintes critérios 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 similares substancialmente consecutivos agregados a fim de determinar o número de dias consecutivos do programa), (ii) todos os registradores acreditados da ICANN recebem a mesma oportunidade para se qualificar para tal Preço de renovação com desconto; e (iii) a intenção ou efeito do programa não é excluir nenhuma classe em especial de registros (por exemplo, registros mantidos por grandes corporações) nem aumentar o preço de renovação de nenhuma classe em especial de registros. Nada nesta 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 fornecerá serviço de pesquisa de DNS com base em consulta para o TLD (ou seja, operar os servidores de zona de TLD de registro) às suas expensas.

2.11 Auditorias de conformidade contratual e operacional.

(a) A ICANN poderá ocasionalmente (no máximo duas vezes por ano civil) realizar ou contratar terceiros para realizar auditorias de conformidade contratual a fim de avaliar a conformidade por Operador de registro com as suas representações e garantias contidas no Artigo 1 deste Contrato e suas declarações contidas no Artigo 2 deste Contrato. Essas auditorias deverão ser adaptadas para atingir o objetivo de avaliar a conformidade e a ICANN (a) enviará aviso com antecedência razoável dessa auditoria especificando satisfatoriamente os detalhes das 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 mediante solicitação da ICANN, o Operador de registro

fornecerá em tempo hábil todos os documentos, dados e quaisquer outras informações necessárias para demonstrar a conformidade do Registrador com este Contrato. Em não menos que dez (10) dias de aviso (a menos que acordado de modo diverso pelo Operador de registro), a ICANN poderá, como parte de qualquer auditoria de conformidade contratual, fazer visitas no local durante o horário comercial a fim de avaliar a conformidade do Operador de registro com suas representações e garantias contidas no Artigo 1 deste Contrato e suas declarações contidas no Artigo 2 deste Contrato. A ICANN tratará qualquer informação obtida em conexão com essas auditorias que seja apropriadamente marcada como confidencial (conforme exigido pela Seção 7.15) como Informação confidencial de 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 por conta 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 acreditado ou revendedor de registrador da ICANN ou qualquer um de seus respectivos afiliados, ou (B) tenha subcontratado a prestação de serviços de registro para um registrador acreditado ou revendedor de registrador da ICANN ou qualquer um de seus respectivos Afiliados e, em qualquer um dos casos (A) ou (B) acima, a auditoria se refere à conformidade do Operador de registro com a Seção 2.14, em cujo caso o Operador de registro deverá reembolsar a ICANN com relação a todos os custos e despesas razoáveis, associados à parte da auditoria relacionada com a conformidade do Operador de registro com a Seção 2.14 ou (ii) a auditoria está relacionada a uma discrepância nas taxas pagas pelo Operador de registro nos termos deste instrumento acima de 5% em determinado trimestre, em detrimento da ICANN, em cujo caso o Operador de registro deverá reembolsar a ICANN com relação a 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 de nível de 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 o Operador de registro não estiver em conformidade com suas declarações e garantias contidas no Artigo 1 deste Contrato ou suas declarações, contidas 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 do conhecimento do Operador de registro do começo de qualquer um dos procedimentos referidos na Seção 4.3(d) ou a 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 estabelecido na Especificação 8 aqui anexa ("Especificação 8").

2.13 Transição de emergência. O Operador de registro concorda que, no caso de serem atingidos quaisquer limites de emergência para funções de registro estabelecidas na

Seção 6 da Especificação 10, a ICANN poderá designar um operador de registro interino de emergência do registro para o TLD (um "Operador de emergência") de acordo com o processo de transição de registro da ICANN (disponível em

<xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/xxxxxxxxxx-xxxxxxxxx>) (como o mesmo pode ser aditado esporadicamente, o "Processo de transição de registro") até o momento em que o Operador de registro tenha demonstrado, a critério razoável da ICANN, que pode retomar a operação do registro para o TLD sem a recorrência de tal falha. Após tal demonstração, o Operador de registro pode retornar à operação do registro para o 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 conjunto com a operação do registro para o TLD, cujos custos deverão ser documentados em detalhamento razoável nos registros que deverão ser 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 providenciará para a ICANN ou qualquer 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 para o TLD necessárias para manter operações e funções de registro que possam ser razoavelmente solicitadas pela ICANN ou por tal Operador de emergência. O Operador de registro concorda que a ICANN pode fazer qualquer alteração que considere necessária no banco de dados IANA para DNS e registros de WHOIS com relação ao TLD no caso de um Operador de emergência ser designado nos termos desta Seção 2.13. Além disso, no caso de tal falha, a ICANN deverá reter e poderá aplicar seus direitos sob o Instrumento de operações contínuas.

2.14 Código de conduta do registro. Juntamente com a operação do registro para o TLD, o Operador de registro atenderá ao Código de conduta de registro conforme estabelecido na Especificação 9 aqui anexa ("Especificação 9").

2.15 Cooperação com estudos econômicos. Se a ICANN iniciar ou preparar um estudo econômico sobre o impacto ou funcionamento de novos domínios genéricos de primeiro nível na Internet, o DNS ou matéria relacionada, o Operador de registro cooperará de modo razoável com a ICANN ou seu designado, realizando tal estudo com todos os dados relacionados à operação do TLD razoavelmente necessários para os fins de tal estudo requisitado pela ICANN ou seu designado, desde que o Operador de registro possa reter (a) qualquer análise interna ou as 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 violar a legislação pertinente. Todos os dados entregues à ICANN ou seu designado nos termos desta Seção 2.15 que estiverem apropriadamente marcados como confidenciais (conforme exigido pela Seção 7.15) deverão ser tratados como Informação confidencial de operador de registro de acordo com a Seção 7.15, desde que, se a ICANN agregar e tornar anônimos tais dados, a ICANN ou seu designado possa divulgar tais 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 de registro. As especificações de desempenho de registro para operação do TLD serão conforme o estabelecido na Especificação 10 aqui anexa ("Especificação 10"). O Operador de registro atenderá a tais Especificações de desempenho por um período de no mínimo um (1) ano, manterá registros técnicos e operacionais suficientes para evidenciar conformidade com tais especificações para cada ano civil consecutivo 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 aqui anexa ("Especificação 11").

2.18 Dados pessoais. O Operador de registro avisará (i) cada registrador acreditado da ICANN, qualificado como uma das partes do Contrato entre registro e registrador para o TLD, dos fins para cujos dados sobre qualquer pessoa natural identificada ou identificável ("Dados pessoais") entregues ao Operador de registro por tal registrador é coletado e utilizado nos termos deste Contrato ou de outra forma e os 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 cobrança e uso de Dados pessoais. O Operador de registro tomará medidas razoáveis para proteger os Dados pessoais coletados de tal registrador de 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 com a comunidade TLD. O Operador de registro estabelecerá políticas de registro em conformidade com o pedido entregue em relação ao TLD para: (i) convenções de nomenclatura dentro do TLD, (ii) requisitos de registro por membros da comunidade TLD, e (iii) uso de nomes de domínios registrados em conformidade com a finalidade declarada do TLD baseado na comunidade. O Operador de registro operará o TLD de modo que permita à comunidade TLD discutir e participar no desenvolvimento e modificação de políticas e práticas para o TLD. O Operador de registro estabelecerá procedimentos para a aplicação de políticas de registro para o TLD e resolução de disputas com relação à 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 vincular-se ao Procedimento de resolução de disputas de restrições de registro conforme estabelecido em xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/xxxxx com relação a disputas que surjam nos termos desta Seção 2.19. O Operador de registro implementará e cumprirá as políticas de registro da comunidade, estabelecidas na Especificação 12 aqui anexa.

ARTIGO 3.

DECLARAÇÃO DA ICANN

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

3.1 Aberta e transparente. Consistentemente com a missão e os valores fundamentais expressos da ICANN, esta operará de forma aberta e transparente.

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

3.3 Servidores de nomes TLD. A ICANN envidará esforços comercialmente razoáveis para garantir que quaisquer alterações às designações de servidores de nomes do TLD entregues à ICANN pelo Operador de registro (em formato e com elementos técnicos necessários especificados pela ICANN em xxxx://xxx.xxxx.xxx/xxxxxxx/xxxx/) serão implementadas pela ICANN em sete (7) dias consecutivos ou o mais rápido possível após verificações técnicas.

3.4 Publicação de informação de zona raiz. A publicação da ICANN de informações de contato de zona raiz para o TLD 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 deve ser feita no formato especificado de tempos em tempos pela ICANN em xxxx://xxx.xxxx.xxx/xxxxxxx/xxxx/.

3.5 Banco de dados raiz oficial. Na medida em que a ICANN é autorizada a definir a política com 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 de autoridade aponte para os servidores de nomes de domínio de primeiro nível designados pelo Operador de registro para o TLD, (b) manter uma base de dados publicamente disponível estável, segura e oficial, com 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 de modo que seja operado e mantido de modo estável e seguro; desde que a ICANN não esteja violando este Contrato e a ICANN não terá nenhuma responsabilidade no caso de terceiros (inclusive qualquer entidade governamental ou provedor de serviço de Internet) bloquearem ou restringirem o acesso ao TLD em algum foro.

ARTIGO 4.

VIGÊNCIA E RESCISÃO

4.1 Prazo. O prazo deste Contrato será de dez (10) anos a partir da Data de Vigência (já que tal prazo poderá ser estendido nos termos da 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 por parte da ICANN ao Operador de registro de uma violação fundamental e significativa das declarações do Operador de registro estabelecidas no Artigo 2 ou violação de suas obrigações de pagamento sob o Artigo 6 deste Contrato, cujo aviso deverá incluir com especificidade os detalhes da suposta violação, e tal violação não tenha sido reparada no prazo de trinta (30) dias consecutivos de tal aviso, (A) um árbitro ou tribunal de foro competente tenha finalmente determinado que o Operador de registro incorreu em violação fundamental e significativa de tais declarações ou em violação de suas obrigações de pagamento, e (B) o Operador de registro não esteja em conformidade com tal determinação e tal violação seja reparada dentro 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, o Operador de registro deverá ter sido encontrado por um árbitro (nos termos da Seção 5.2 deste Contrato) ou um tribunal de foro competente em pelo menos três (3) ocasiões separadas por ter estado em (A) violação fundamental e relevante (reparada ou não) das declarações do Operador de registro estabelecidas no Artigo 2 ou

(B) violação de suas obrigações de pagamento nos termos do Artigo 6 deste Contrato.

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

4.3 Rescisão pela ICANN.

(a) A ICANN poderá, mediante aviso ao Operador de registro, rescindir este Contrato se: (i) o Operador de registro não conseguir reparar (A) nenhuma violação fundamental e relevante das representações e garantias do Operador de registro estabelecidas no Artigo 1 ou das declarações estabelecidas no Artigo 2, ou (B) qualquer violaçã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 o aviso da ICANN para o Operador de registro sobre tal violação, aviso esse que incluirá com especificidade os detalhes da suposta violação, (ii) um árbitro ou tribunal de foro competente tiver finalmente determinado que o Operador de registro está em violação fundamental e relevante de tais declarações ou em violação de suas obrigações de pagamento, e (iii) o Operador de registro não puder cumprir tal determinação e reparar tal violação no 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 delegação do TLD na zona raiz dentro de doze (12) meses desde a Data de vigência. O Operador de registro poderá solicitar uma extensão de até doze (12) meses adicionais para delegação, se puder demonstrar, a critério razoável da ICANN, que o Operador de registro está trabalhando diligentemente e em boa fé para concluir de modo bem-sucedido as etapas necessárias para delegação do TLD. Quaisquer taxas pagas pelo Operador de registro à ICANN antes dessa data de rescisão poderão ser totalmente 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 violação relevante das obrigações do Operador de registro, estabelecidas na Seção 2.12 deste Contrato dentro de trinta (30) dias a partir da entrega do aviso de tal violaçã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 da Data de vigência, (ii) um árbitro ou tribunal de foro competente tenha finalmente determinado que o Operador de registro esteja em violação relevante de tal declaração, e (iii) o Operador de registro não tenha reparado tal violação em dez (10) dias consecutivos ou outro período conforme seja 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, procedimentos estes que sejam uma ameaça relevante à capacidade do Operador de registro de operar o registro para o 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 manter controle sobre quaisquer propriedades do Operador de registro, (iv) os bens do Operador de registro forem penhorados, (v) forem instituídos procedimentos pelo Operador ou contra ele, de registro por motivo de falência, insolvência, reorganização ou outras leis relacionadas à dispensa de devedores e tais procedimentos não forem extintos em até sessenta (60) dias consecutivos após terem sido iniciados, ou (vi) o Operador de registro fizer pedido de proteção de acordo com a 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 interromper suas operações ou a operação do TLD.

(e) A ICANN poderá, após aviso de trinta (30) dias consecutivos ao Operador de registro, rescindir este Contrato nos termos da Seção 2 da Especificação 7 ou Seções 2 e 3 da Especificação 11, sujeito ao direito do Operador de registro de contestar tal rescisão conforme estabelecido no procedimento aplicável descrito neste documento.

(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 de qualquer crime, ou for julgado por um juiz da foro competente de ter cometido fraude ou violação de

dever de lealdade, ou for objeto de uma determinação judicial que a ICANN considera fundamentalmente equivalente a uma das infrações anteriores e tal executivo não for dispensado em até trinta (30) dias após o Operador de registro tomar conhecimento da(s) infração(ões); ou (ii) qualquer membro da diretoria do Operador de registro ou órgão governante semelhante for condenado por contravenção penal relacionada a atividades financeiras ou de qualquer crime, ou for julgado por um juiz de foro competente de ter cometido fraude ou violação de dever de lealdade, ou for objeto de uma determinação judicial que a ICANN considerar fundamentalmente equivalente a uma das infrações anteriores e tal membro não for removido da diretoria do Operador de registro ou órgão governante semelhante em até trinta (30) dias 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 pelo Operador de registro.

(a) O Operador de registro poderá rescindir este Contrato mediante aviso à ICANN se (i) a ICANN não reparar nenhuma violação fundamental e relevante de declarações da ICANN estabelecidas no Artigo 3 dentro de trinta (30) dias consecutivos após o Operador de registro avisar à ICANN sobre tal violação, cujo aviso incluirá com especificidade os detalhes da suposta violação, (ii) um árbitro ou tribunal de foro competente tiver finalmente determinado que a ICANN está em violação fundamental e relevante de tais declarações, e (iii) a ICANN não cumprir tal determinação e não puder reparar a violação em dez (10) dias consecutivos ou outro prazo conforme seja determinado pelo árbitro ou tribunal de foro competente.

(b) O Operador de registro pode rescindir este Contrato por qualquer motivo após aviso prévio de cento e oitenta (180) dias consecutivos à ICANN.

4.5 Transição de registro mediante rescisão de Contrato. Após 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 qualquer operador de registro sucessor que possa ser designado pela ICANN para o TLD em conformidade com esta Seção 4.5 com todos os dados (inclusive os dados depositados em conformidade com a Seção 2.3) com relação a operações do registro para o TLD necessário para manter operações e funções de registro que possam ser razoavelmente requisitadas pela ICANN ou por esse operador de registro sucessor. Após consulta com o Operador de registro, a ICANN determinará 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, desde que, no entanto a ICANN (i) leve em consideração quaisquer direitos de propriedade intelectual do Operador de registro (como comunicado para a ICANN pelo Operador de registro) em determinar se passará a operação de transição do TLD a um operador de

registro sucessor e (ii) se o Operador de registro demonstrar, a critério razoável da ICANN, que (A) todos os registros de nome de domínio no TLD são registrados para o Operado 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 (o qual não deverá ser indevidamente recusado, limitado ou postergado). Para evitar dúvidas, a sentença precedente não deverá proibir a ICANN de delegar o TLD de acordo com um processo de aplicação futuro para a delegação de domínios de primeiro nível, sujeito a quaisquer processos e procedimentos de objeção instituídos pela ICANN em conexão com tal processo de aplicação com o objetivo de proteger os direitos de terceiros. O Operador de registro concorda que a ICANN pode fazer qualquer alteração que considere necessária no banco de dados IANA para DNS e registros de WHOIS com relação ao TLD no caso de uma transição do TLD de acordo com esta Seção 4.5. Além disso, a ICANN ou seu representante deverão reter e poderão impor 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 de registro mediante rescisão de Contrato para organizações intergovernamentais ou entidades governamentais ou outras circunstâncias especiais:

“Transição de registro mediante rescisão de Contrato. Após expiração do Prazo, de acordo com a Seção 4.1 ou Seção 4.2, ou qualquer rescisão deste Contrato, conforme a Seção 4.3 ou Seção 4.4, em conjunto com a designação da ICANN, de um operador de registro sucessor para o 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 consulta com o Operador de registro, a ICANN deverá determinar 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 caso de a ICANN determinar fazer a operação de transição do TLD para um operador de registro sucessor, após consentimento do Operador de registro (que não deve ser indevidamente recusado, limitado ou postergado), o Operador de registro deverá providenciar para a ICANN ou o Operador de registro sucessor para o TLD quaisquer dados com relação a operações do TLD necessárias para manter as operações e funções de registro que possam ser razoavelmente solicitadas pela ICANN ou por tal operador de registro sucessor adicionalmente aos dados depositados de acordo com a Seção 2.3 deste. No caso de o Operador de registro não consentir em fornecer tais dados, qualquer dado de registro relacionado ao TLD deverá ser retornado ao Operador de registro, a menos que acordado diferentemente entre as partes. O Operador de registro concorda que a ICANN pode fazer qualquer alteração que considere necessária no banco de dados IANA para DNS e registros de WHOIS com relação ao TLD no caso de uma transição do TLD de acordo com esta Seção 4.5. Além disso, a ICANN ou seu representante deverão manter e poderão impor

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 deverão cessar, desde que tal expiração ou rescisão deste Contrato não exonerem as partes de nenhuma obrigação ou violação deste Contrato, vencidas antes de tal expiração ou rescisão, incluindo, sem limitação, 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 devem sobreviver à 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 devem tentar resolver a disputa por meio de mediação em conformidade com os seguintes termos e condições:

(a) Uma parte enviará uma disputa para mediação por aviso por escrito à outra parte. A mediação será realizada por um só mediador selecionado pelas partes. Se as partes não puderem concordar com um mediador em até quinze (15) dias consecutivos após a entrega de 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 após a seleção dessa entidade, nomeará um mediador, que será um advogado licenciado com conhecimento geral sobre a legislação de contratos 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 ele ou ela não é, e não se tornará, durante o período da mediação, funcionário, parceiro, diretor executivo, executivo ou responsável por segurança da ICANN nem de um 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 ele ou ela determinará após consulta com as partes. As partes discutirão a disputa em 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 deverá portanto ser confidencial e não poderá ser utilizada contra nenhuma das partes em qualquer procedimento posterior relacionado à disputa, inclusive qualquer arbitragem segundo a Seção 5.2. O mediador não poderá testemunhar para nenhuma das partes em qualquer procedimento posterior relacionado com a disputa.

(c) Cada parte arcará com suas próprias custas da mediação. As partes repartirão igualmente as taxas e as despesas do mediador. Cada uma das partes deverá tratar as informações recebidas da outra parte segundo a mediação 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.

(d) Se as parte tiverem se envolvido em participação de boa fé na mediação mas não tiverem resolvido a disputa por qualquer motivo, a parte ou o mediador poderão encerrar a mediação a qualquer momento e a disputa poderá então prosseguir para arbitragem segundo a Seção 5.2 abaixo. Se as partes não tiverem resolvido a disputa por qualquer motivo até a data que for noventa (90) dias consecutivos após a data do aviso entregue segundo a Seção 5.1(a), a mediação será automaticamente encerrada (a menos que estendida por acordo das partes) e a disputa poderá então prosseguir para arbitragem segundo 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 sejam resolvidas segundo a Seção 5.1, inclusive solicitações de execução específica, serão resolvidas por meio de arbitragem vinculante conduzida segundo as regras do Tribunal Internacional de Arbitragem da Câmara Internacional de Comércio. A arbitragem será em inglês e realizada 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) as partes concordem por escrito com um número maior de árbitros, ou (iii) 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á perante três árbitros com cada parte apontando um árbitro e os dois árbitros selecionados apontando o terceiro árbitro. 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 os árbitros determinarem 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 pelos árbitros com base na determinação independente dos árbitros 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 árbitro(s) incluirá no julgamento. No caso da 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á requerer 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 envolvendo a ICANN, relacionado a este Contrato, o local e o foro exclusivo para tal litígio serão em uma vara localizada no condado de Los

Angeles, Califórnia, EUA; entretanto, as partes também terão o direito de impor um parecer dessa vara 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 sejam resolvidas segundo a Seção 5.1, inclusive solicitações de execução específica, serão resolvidas por meio de arbitragem vinculante conduzida segundo as regras do Tribunal Internacional de Arbitragem da Câmara Internacional de Comércio. 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) as partes concordem por escrito com um número maior de árbitros, ou (iii) 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á perante três árbitros com cada parte apontando um árbitro e os dois árbitros selecionados apontando o terceiro árbitro. 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 os árbitros determinarem 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 pelos árbitros com base na determinação independente dos árbitros 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 árbitro(s) incluirá no julgamento. No caso da 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á requerer 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 envolvendo a ICANN e relacionado a este Contrato, o local e foro exclusivo para tal litígio será uma vara localizada em Genebra, Suíça, exceto se outra localidade for mutuamente acordada pelo Operador de registro e a ICANN; entretanto, as partes também terão o direito de impor um parecer dessa vara em qualquer tribunal de foro competente."]

5.3 Limitação de responsabilidade. A responsabilidade monetária agregada da ICANN por violações deste Contrato não deverá exceder um valor igual às Taxas de nível de registro pagas pelo Operador de registro à ICANN dentro do período anterior de doze meses segundo o presente Contrato (excluindo a Taxa de Nível de registro variável estabelecida na Seção 6.3, se houver). A responsabilidade monetária agregada do Operador de registro com a ICANN por violações deste Contrato será limitada a um montante igual às

taxas pagas para a ICANN durante o período anterior de doze meses (excluindo a Taxa de nível de registro variável 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 Seção 7.2. Em nenhum caso qualquer uma das partes será responsável 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 como previsto na 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, incluindo sem limitação, qualquer garantia implícita de comercialização, não violação ou adequação para uma finalidade em especial.

5.4 Execução específica. O Operador de registro e a ICANN concordam que podem ocorrer danos irreparáveis se qualquer uma das disposições 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 buscar de um árbitro ou tribunal de foro competente uma execução específica dos termos desse Contrato (adicionalmente a qualquer outra reparação a que cada parte tenha direito).

ARTIGO 6.

TAXAS

6.1 Taxas de nível de registro.

(a) O Operador de registro pagará à ICANN uma taxa de nível de registro igual (i) à taxa de registro fixa de US$ 6.250 por trimestre e (ii) à taxa de transação de nível de registro (coletivamente, as "Taxas de nível de registro"). A taxa de transação de nível de registro será igual ao número de incrementos anuais de um registro de nome de domínio inicial ou renovado (em um ou mais níveis e incluindo renovações associadas com transferências de um registrador acreditado da ICANN para outro, sendo cada um uma "Transação"), durante o trimestre aplicável multiplicado por US$ 0,25; desde que a taxa de transação de nível de registro não se aplique até e a não ser que tenham ocorrido 50.000 transações no TLD em qualquer trimestre ou quaisquer quatro trimestres consecutivos no agregado (o "Limite de transação") e se aplicarão a cada Transação que ocorra em qualquer trimestre em que o Limite de transação tenha sido atingido, mas não se aplicará a cada trimestre em que o Limite de transação não tenha sido atingido. A obrigação do Operador de registro de pagar a taxa trimestral fixa de nível de registro iniciará na data em que o TLD é delegado no DNS ao Operador de registro. O primeiro pagamento trimestral da taxa fixa de nível de registro será rateado com base no número de dias consecutivos entre a data de delegação e o fim do trimestre em que recai a data de delegação.

(b) Sujeito à Seção 6.1(a), o Operador de registro pagará as Taxas de nível de registro em uma base trimestral em uma conta designada pela ICANN no prazo de trinta

(30) dias consecutivos após a data da fatura fornecida pela ICANN.

6.2 Recuperação de custos para RSTEP. Solicitações feitas pelo Operador de registro para aprovação de Serviços adicionais segundo a Seção 2.1 podem ser encaminhadas pela ICANN ao RSTEP (Registry Services Technical Evaluation Panel, Painel de avaliação de serviços técnicos de registros) nos termos do processo em xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxxx/xxxx/. No caso de tais solicitações serem encaminhadas ao RSTEP, o Operador de registro remeterá à ICANN o custo faturado da revisão do RSTEP no prazo de quatorze (14) dias consecutivos do recebimento de uma cópia da fatura do RSTEP, da ICANN, a menos que a ICANN determine, a seu exclusivo e absoluto critério, pagar todo ou parte do custo faturado da revisão do RSTEP.

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

(a) Se os registradores acreditados da ICANN (levando em conta, no agregado, o pagamento de dois terços de todas as taxas de nível de registro, ou a parte dos registradores acreditados da ICANN, necessária para aprovar taxas de credenciamento nos termos do então vigente contrato de credenciamento de registrador) não aprovarem, segundo os termos de seus Contratos de credenciamento de registradores com a ICANN, as taxas de credenciamento variáveis estabelecidas pela Diretoria da ICANN para qualquer exercício fiscal da ICANN, após entrega de aviso da ICANN, o Operador de registro pagará à ICANN uma taxa de nível de registro variável, que poderá ser paga em uma base fiscal trimestral, e entra em vigor a partir do início do primeiro trimestre fiscal do exercício fiscal da ICANN (a "Taxa de nível de registro variável"). A taxa será calculada e faturada pela ICANN trimestralmente e será paga pelo Operador de registro no prazo de sessenta (60) dias consecutivos em relação ao primeiro trimestre do exercício fiscal da ICANN e dentro de vinte (20) dias consecutivos com relação a cada trimestre remanescente do exercício fiscal da ICANN, ou do recebimento do montante faturado pela ICANN. O Operador de registro poderá faturar e cobrar as Taxas de nível de registro variáveis dos registradores que façam parte de um Contrato entre registro e registrador com o Operador de registro (cujo contrato poderá especificamente prever o reembolso de Taxas de nível de registro variável pagas pelo Operador de registro segundo a Seção 6.3); desde que as taxas sejam faturadas para todos os registradores acreditados da ICANN se forem faturadas para algum. A Taxa de nível de registro variável, se cobrável pela ICANN, deverá ser uma obrigação do Operador de registro e será considerada exigível conforme previsto nesta Seção 6.3 independentemente da capacidade do Operador de registro de buscar e obter reembolso de tal taxa pelos registradores. No caso da ICANN cobrar mais tarde taxas de credenciamento variável pelas quais o Operador de registro tenha pago à ICANN uma taxa de nível de registro variável, a ICANN deverá reembolsar ao Operador de registro um montante apropriado da Taxa de nível de registro variável, conforme razoavelmente determinado pela ICANN. Se os registradores credenciados da ICANN (como um grupo) aprovarem, segundo os termos de seus Contratos de credenciamento de registrador com a ICANN, as taxas de credenciamento variáveis estabelecidas pela Diretoria da ICANN para um exercício fiscal, a ICANN não será responsável por uma taxa de nível variável deste Contrato para tal exercício fiscal, independentemente de os registradores credenciados da ICANN cumprirem ou não suas obrigações de pagamento com a ICANN durante o exercício fiscal.

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

6.4 Taxas de repasse. O Operador de registro pagará à ICANN (i) uma taxa única igual a US$ 5.000 por acesso e uso do Trademark Clearinghouse (Centro de Informações de Marcas) conforme descrito na Especificação 7 (a “Taxa de acesso de RPM”) e (ii) US$ 0,251 por Registro de período experimental e Registro de reivindicações (como tais termos são usados nos RPMs do Centro de Informações de Marcas aqui incorporados segundo a

Especificação 7) (a “Taxa de registro de RPM”). A taxa de acesso de RPM será faturada a partir da Data de vigência deste Contrato e o Operador de registro pagará a taxa em uma conta especificada pela ICANN no 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 RPM, 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 na expiração do primeiro ano deste Contrato e após a expiração de cada ano posteriormente 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 igual à variação percentual, caso exista, no (i) Índice de preço ao consumidor para todos os consumidores urbanos, média de cidade norte-americana (1982-1984 = 100) publicada pelo Departamento do Trabalho dos Estados Unidos, Agência de Estatísticas Trabalhistas, ou qualquer índice sucessor (o "CPI") para o mês que for um (1) mês antes do início do ano aplicável, sobre (ii) o 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 providenciará aviso ao Operador de registro especificando o montante de tal ajuste. Qualquer ajuste de taxa nos termos desta Seção 6.5 estará em vigor a partir do primeiro dia do primeiro trimestre do ano após pelo menos trinta (30) dias depois da entrega pela ICANN do aviso do ajuste da taxa ao Operador de registro.

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

1 Sujeito a aprovações adicionais.

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, dirigentes, funcionários e agentes (coletivamente, "Indenizados") de e contra quaisquer alegações, danos, responsabilidades, custos e despesas, inclusive taxas e despesas jurídicas razoáveis de terceiros, que resultem de direitos de propriedade de propriedade intelectual com respeito ao TLD, a delegação do TLD para o Operador de registro, a operação do Operador de registro do registro para o TLD ou a prestação de Serviços de registro do Operador de registro ou estejam relacionadas com estes, desde que o Operador de registro não seja obrigado a indenizar ou defender nenhum Indenizado na medida em que surjam alegações, danos, responsabilidade, custos ou despesas: (i) devido a ações ou omissões da ICANN, seus subcontratados, membros de equipe ou avaliadores especificamente relacionados com o processo de aplicação do TLD de registro e que ocorreram durante ele (outras ações ou omissões solicitadas pelo Operador de registro ou em benefício deste), ou (ii) devido a uma violação por parte da ICANN de qualquer obrigação contida neste Contrato ou qualquer má conduta intencional pela ICANN. Esta Seção não deverá ser considerada como obrigação do Operador de registro de reembolsar ou de alguma forma indenizar a ICANN por custos associados à negociação ou execução deste Contrato, ou com monitoração ou administração das obrigações respectivas das partes aqui qualificadas. 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, que possam ser regidos pelo Artigo 5 ou de outra forma julgados 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 para cooperar com a ICANN para assegurar que a ICANN não incorra em quaisquer custos associados com alegações, danos, responsabilidades, custos e despesas, inclusive taxas e despesas jurídicas razoáveis que resultem de direitos de propriedade de propriedade intelectual com respeito ao TLD, à delegação do TLD para o Operador de registro, à operação do Operador de registro do registro para o TLD ou à previsão de Serviços de registro do Operador de registro ou estejam relacionadas com estes, desde que o Operador de registro não seja obrigado a prestar tal cooperação na medida em que surjam alegações, danos, responsabilidade, custos ou despesas devido a uma violação pela ICANN de qualquer uma de suas obrigações contidas neste Contrato ou qualquer má conduta intencional pela ICANN. Esta Seção não deverá ser considerada como obrigação do Operador de registro de reembolsar ou de alguma forma indenizar a ICANN por custos associados à negociação ou execução deste Contrato, ou com monitoração ou administração das obrigações respectivas das partes aqui qualificadas. 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,

que possam ser regidos pelo Artigo 5 ou de outra forma concedidos por um tribunal ou árbitro de foro competente."]

(b) Para quaisquer alegações da ICANN por indenização onde diversos operadores de registro (inclusive o Operador de registro) estejam envolvidos nas mesmas ações ou omissões que tenham feito surgir a alegação, a responsabilidade agregada do Operador de registro para indenizar a ICANN com relação a tal alegação deverá ser limitada a um percentual do total de alegações da ICANN, calculado dividindo-se o número de nomes de domínio total sob registro com o Operador de registro dentro do TLD (cujos nomes sob registro deverão ser calculados consistentemente com o Artigo 6 para qualquer trimestre aplicável) pelo número total de nomes de domínio sob registro dentro de todos os domínios de primeiro nível pelos quais os operadores de registro estejam envolvidos nos mesmos atos e omissões que deram origem a tal alegação. A fim de reduzir a responsabilidade do Operador de registro sob a Seção 7.1(a) segundo esta Seção 7.1(b), o Operador de registro terá o ônus de identificar os outros operadores de registro que estejam envolvidos nas mesmas ações ou omissões que deram origem à alegação e de demonstrar, a critério razoável da ICANN, a culpabilidade desses outros operadores de registro por tais ações ou omissões. A fim de evitar dúvidas, no caso de um operador de registro estar envolvido nos mesmos atos ou omissões que deram origem às alegações, mas tal operador de registro não ter as mesmas nem semelhantes obrigações de indenização para com a ICANN como estabelecido na Seção 7.1(a) acima, o número de domínios sob gerenciamento por tais operadores de registro não será incluído no cálculo do parágrafo 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 indenizada nos termos da Seção 7.1 acima, a ICANN deverá fornecer aviso ao Operador de registro tão logo quanto possível. O Operador de registro terá o direito, se assim o decidir, em um aviso imediatamente entregue à ICANN, de tomar controle imediatamente da defesa e investigação de tal alegação e de empregar e usar advogados que sejam aceitáveis para a ICANN para assumir o caso e defendê-la, por conta e risco unicamente do Operador de registro, desde que em todos os casos a ICANN tenha o direito de controlar por sua conta e risco o litígio de problemas com relação à validade ou interpretação das políticas, estatutos ou conduta da ICANN. A ICANN cooperará, às custas 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 que possa daí surgir, e poderá, por sua conta e risco, participar, através de seus advogados ou de outra forma, em tal investigação, julgamento e defesa de tal alegação e qualquer apelação que possa daí surgir. 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 controle total sobre a defesa de uma alegação sujeita à 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 custas 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 fins deste Contrato, salvo tais definições sejam alteradas segundo uma Política de consenso em data futura, em cujo caso as seguintes definições deverão ser consideradas alteradas e consolidadas em sua totalidade, conforme estabelecido em tal Política de consenso, segurança e estabilidade, serão definidas da seguinte maneira:

(a) Para 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 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 normalização da Internet bem estabelecido e reconhecido, como o relevante Standards-Track ou Best Current Practice Requests for Comments (“RFCs”) patrocinado pela Internet Engineering Task Force; ou (2) a criação de uma condição que afete adversamente 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 relevante

Standards-Track 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 outro) entre o Operador de registro e a ICANN.

7.5 Alteração de controle, cessão e subcontratação. Exceto como estabelecido nesta Seção 7.5, nenhuma das partes poderá ceder nenhum dos seus direitos e obrigações constantes deste Contrato sem aprovação prévia por escrito da outra parte, aprovação essa que não será retida de maneira infundada. Para os fins desta Seção 7.5, uma alteração direta ou indireta de controle de Operador de registro ou qualquer disposição de subcontratação que se relacione a qualquer Função crítica (como identificado na Seção 6 da Especificação 10) para o TLD ("Disposição de subcontratação relevante") será considerada uma cessão.

(a) O Operador de registro deve fornecer à ICANN um aviso prévio de pelo menos trinta (30) dias consecutivos de qualquer cessão ou Disposição de subcontratação relevante, e qualquer acordo para ceder ou subcontratar qualquer parte das operações do TLD (seja ou não uma Disposição de subcontratação relevante) deverá exigir conformidade com todas as declarações, obrigações e Contratos pelo Operador de registro aqui qualificado, e o Operador de registro continuará vinculado por tais declarações, obrigações e Contratos. O Operador de registro precisa também 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) No prazo de trinta (30) dias consecutivos a partir de qualquer um desses avisos, segundo a Seção 7.5(a), a ICANN poderá solicitar informação adicional do 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 relevante (em todo caso, 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 dentro 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 Contrato material de subcontratação também estará sujeito a verificações de histórico sobre qualquer Parte contratante proposta (e Afiliados dessa Parte contratante).

(d) Se a ICANN não conseguir fornecer expressamente ou recusar o consentimento para qualquer cessão, mudança direta ou indireta de controle de Operador de registro ou qualquer Contrato material de subcontratação dentro de trinta (30) dias consecutivos do recebimento do aviso da ICANN de tal transação (ou se a ICANN tiver solicitado informação adicional do Operador de registro conforme estabelecido acima, trinta (30) dias consecutivos a partir do recebimento de todas as informações por escrito solicitadas com referência à tal transação) do Operador de registro, será considerado que a ICANN consentiu tal transação.

(e) Em relação a essa cessão, alteração de controle ou Contrato material de subcontratação, o Operador de registro deverá estar em conformidade com o Processo de transição de registro.

(f) Não obstante o acima exposto, (i) nenhuma alteração consumada de controle poderá ser anulada pela ICANN; desde que, entretanto, se a ICANN determinar razoavelmente retirar seu consentimento de 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 aprovação da Diretoria da ICANN em conjunto com a reorganização, reconstituição ou reincorporação da ICANN mediante 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 para uma subsidiária integral do Operador de registro, ou, se o Operador de registro for uma subsidiária integral em relação à sua empresa controladora ou a outra subsidiária integral de sua controladora direta, mediante aceitação expressa de tal subsidiária ou controladora, conforme aplicável, dos termos e condições deste Contrato, Contrato material de subcontratação ou alteração de transação de controle no qual a Parte contratante seja um operador existente de domínio de primeiro nível genérico de Contrato 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 relevantes), a menos que a ICANN forneça ao Operador de registro uma objeção por escrito para tal transação no prazo de dez (10) dias consecutivos

a partir do recebimento pela ICANN do 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 ser feita 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 o aviso imediato após tal cessão de direitos.

7.6 Aditamentos e renúncias.

(a) Se a Diretoria da ICANN determinar que é desejável um aditamento a este Contrato (incluindo as Especificações referidas neste contrato) e a todos os outros

contratos de registro entre a ICANN e os Operadores de registros aplicáveis (os “Contratos de registros aplicáveis”) (sendo, cada um, um “Aditamento especial”), a ICANN poderá adotar um Aditamento especial de acordo com as disposições e o processo estabelecidos nesta Seção 7.6; considerando que o Aditamento especial não será um Aditamento restrito.

(b) Antes de enviar um Aditamento especial para a Aprovação do Operador de registro, a ICANN deverá primeiro consultar em boa-fé o Grupo de trabalho quanto à forma e o conteúdo desse 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 em seu site por não menos que trinta (30) dias consecutivos (o “Período de publicação”) e fornecendo aviso desse aditamento proposto aos Registradores aplicáveis de acordo com a Seção 7.9. A ICANN considerará os comentários públicos enviados sobre um Aditamento especial durante o Período de publicação (incluindo comentários enviados pelos Operadores de registros aplicáveis).

(c) Se, em até 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 abordará o objeto do Aditamento especial disponibilizado para comentários públicos, modificado de maneira a refletir e/ou abordar as informações fornecidas pelo Grupo de trabalho e comentários públicos), a ICANN fornecerá aviso e enviará esse Aditamento especial para aprovação ou rejeição dos Operadores de registros aplicáveis. Se, durante o período de sessenta (60) dias consecutivos após o fornecimento desse aviso pela ICANN aos Operadores de registros aplicáveis, esse Aditamento especial receber aprovação dos Registradores, esse Aditamento especial será considerado aprovado (“Aditamento aprovado”) pelos Operadores de registros aplicáveis, e entrará em vigor e será considerado um aditamento a este Contrato na data correspondente a sessenta (60) dias consecutivos após a data de fornecimento pela ICANN do aviso de aprovação desse

Aditamento aprovado ao Operador de registro (“Data de início da vigência do aditamento”).

Caso o Aditamento especial não receba aprovação dos Operadores de registros, ele será considerado não aprovado pelos Operadores de registros 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 objeto estabelecidas na Seção 1.2 da

Especificação 1, a Diretoria da ICANN poderá adotar uma resolução (a data em que essa resolução é adotada é referida neste instrumento como a “Data de adoção da resolução”) solicitando um Relatório de problemas (conforme definido nos Estatutos 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 o Relatório de problemas solicitado é referido no presente instrumento como “PDP”. Se esse PDP resultar em um Relatório final apoiado pela maioria extraordinária da GNSO (conforme definido nos Estatutos da ICANN) que (i) recomenda a adoção do Aditamento rejeitado como Política de consenso ou (ii) não recomenda a adoção do Aditamento rejeitado como Política de consenso, e, no caso de (i) acima, a Diretoria adotar essa Política de consenso, 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 ele 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 de Operadores de registros conforme a Seção 7.6(c), o objeto desse Aditamento rejeitado era o objeto de um PDP concluído ou, de outra maneira, abandonado ou rescindido, que não resultou em uma recomendação da GNSO com maioria extraordinária.

(e) Se (a) um Aditamento rejeitado não se enquadrar nas categorias de objeto dispostas na Seção 1.2 da Especificação 1 (b) o objeto de um Aditamento rejeitado foi, a qualquer momento durante o período de doze (12) meses anterior ao envio desse Aditamento rejeitado para a aprovação de Operadores de registros conforme a Seção 7.6(c), o objeto de um PDP concluído ou, de outra maneira, abandonado ou rescindido, que não resultou em uma recomendação da GNSO com maioria extraordinária, ou (c) um PDP não resultar em um Relatório final apoiado por uma maioria extraordinária da GNSO que

(A) recomende a adoção do Aditamento rejeitado como Política de consenso ou (B) não recomende a adoção do Aditamento rejeitado como Política de consenso (ou esse PDP tenha sido abandonado ou cancelado por qualquer motivo), então, em qualquer um desses casos, esse Aditamento rejeitado ainda poderá ser adotado e entrar em vigor na maneira descrita abaixo. Para que o Aditamento Rejeitado seja adotado, os seguintes requisitos deverão ser atendidos:

(i) o objeto do Aditamento Rejeitado deverá fazer parte do escopo da missão da ICANN e ser consistente com uma aplicação equilibrada dos seus valores centrais (conforme descrito nos Estatutos da ICANN);

(ii) o Aditamento rejeitado deverá ser justificado por um Motivo substancial e convincente de interesse público, provavelmente promoverá esse interesse, considerando os interesses públicos e privados concorrentes que possivelmente serão afetados pelo Aditamento rejeitado, e deverá ser elaborado de maneira sucinta e não se estender mais que o necessário a fim de abordar esse Motivo substancial e convincente de interesse público;

(iii) no que diz respeito ao Aditamento rejeitado proibir ou exigir conduta ou atividades, impor custos significativos aos Operadores de registros aplicáveis e/ou reduzir significativamente o acesso público a serviços de nome 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) com o Grupo de trabalho, os especialistas no objeto, os membros da GNSO, os 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 aprovação de Operadores de Registros, mas abordará o objeto 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 pelos menos dois terços dos membros da Diretoria da ICANN aptos a votar sobre esse objeto, levando em consideração qualquer política da ICANN que afete essa qualificação,

incluindo a Política de conflito de interesses da ICANN (“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 de envio pela ICANN do aviso sobre a aprovação desse Aditamento da diretoria ao Operador de registro (essa data de início de vigência será considerada a Data de início de 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 as disposições da 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 aprovação pela Diretoria da ICANN do Aditamento da diretoria, o Grupo de trabalho, em nome dos Operadores de registros aplicáveis, enviar à

Diretoria da ICANN uma alternativa ao Aditamento da diretoria (“Aditamento alternativo”) que atenda aos seguintes requisitos:

(i) dispõe 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) comparado ao Aditamento da diretoria é: (a) elaborado de maneira mais sucinta a fim de abordar esse Motivo substancial e convincente de interesse público, e (b) no que diz respeito ao Aditamento alternativo proibir ou exigir conduta ou atividades, impor custos significativos aos Operadores de registro afetados, ou reduzir significativamente o acesso a serviços de nome de domínio, deverá ser um meio menos restritivo de abordar o Motivo substancial e convincente de interesse público.

Qualquer aditamento proposto que não atenda aos requisitos das subcláusulas (i) a (iii) no parágrafo imediatamente anterior não será considerado um Aditamento alternativo nos termos deste instrumento e, sendo assim, não substituirá nem postergará a vigência do Aditamento da diretoria. Se, após o envio do Aditamento alternativo à diretoria da ICANN, o Aditamento alternativo receber aprovação dos Operadores de registro, o Aditamento alternativo substituirá o Aditamento da diretoria e será considerado um Aditamento aprovado nos termos deste Contrato (e entrará em vigor e será considerado um aditamento a este Contrato na data correspondente a sessenta (60) dias consecutivos após a data de envio pela ICANN do aviso da aprovação desse Aditamento alternativo ao Operador de registro; essa data de início de vigência será considerada a Data de início de vigência do aditamento nos termos deste Contrato), a menos que, em um período de sessenta (60) dias consecutivos após a data de aviso do Grupo de trabalho à Diretoria da ICANN sobre a aprovação dos Operadores de registro de tal Aditamento alternativo (durante esse tempo a ICANN entrará em contato com o Grupo de trabalho com relação ao Aditamento alternativo), a Diretoria da ICANN com o voto positivo de pelos menos dois terços dos membros da Diretoria da ICANN aptos a votar sobre esse objeto, levando em consideração qualquer política da ICANN que afete essa qualificação, incluindo a Política de conflito de interesses da ICANN, rejeitar o Aditamento alternativo. Se (A) o Aditamento alternativo não receber aprovação dos Operadores de registro em até 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 dois terços dos votos, o Aditamento da diretoria (e não o Aditamento alternativo) entrará em vigor e será considerado um aditamento a este Contrato na data correspondente a sessenta (60) dias consecutivos após a data de fornecimento pela ICANN de aviso ao Operador de registro (cuja data de início de vigência será considerada a Data de início de vigência do aditamento nos termos deste contrato). Se a Diretoria da ICANN rejeitar um Aditamento alternativo, a diretoria publicará por escrito um fundamento lógico dispondo sua análise dos critérios previstos 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 dispostos nas Seções 7.6(e)(i) a 7.6(e)(v).

(g) Caso o Operador de registro acreditar que um Aditamento aprovado não atenda aos requisitos relevantes previstos nesta Seção 7.6 ou que foi adotado em violação a qualquer uma das disposições processuais desta Seção 7.6, o Operador de registro poderá contestar a adoção desse Aditamento especial de contrato com as disposições para a resolução de disputas previstas no Artigo 5, exceto se essa arbitragem for realizada por um tribunal arbitral composto por três pessoas. Qualquer contestação dessa natureza deverá ser indicada em até sessenta (60) dias consecutivos após a data de fornecimento pela ICANN de aviso ao Operador de registro sobre o Aditamento aprovado, e a ICANN poderá unir todas as contestações levantadas pelos operadores de registro (incluindo o Operador de registro) em um só processo judicial. O Aditamento aprovado será desconsiderado como um 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 (cada solicitação enviada pelo Operador de registro nos termos deste contrato será uma “Solicitação de isenção”) durante o período de trinta (30) dias consecutivos após a data de fornecimento pela ICANN de aviso ao Operador de registro sobre esse Aditamento aprovado. Cada Solicitação de isenção estabelecerá a base para essa solicitação e fornecerá um apoio detalhada 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, ao Aditamento aprovado proposta por esse Operador de registro. Uma Solicitação de isenção poderá ser concedida apenas 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 adverso relevante na condição financeira a longo prazo ou nos 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 aos registrantes ou resultaria na negação de um benefício direto aos registrantes. Em até noventa (90) dias consecutivos após o recebimento pela ICANN de uma Solicitação de Isenção, a ICANN aprovará (essa aprovação poderá estar condicionada ou consistir em alternativas ou uma variação do Aditamento Aprovado) ou negará a Solicitação de Isenção por escrito; durante esse tempo, o Aditamento Aprovado não aditará este Contrato. Se a Solicitação de Isenção for aprovada pela ICANN, o Aditamento Aprovado não aditará este Contrato; considerando que quaisquer condições, alternativas ou variações do Aditamento Aprovado exigidas pela ICANN entrarão em vigor e, dentro do possível, aditarão este Contrato a partir da Data de Início da Vigência do Aditamento. Se essa Solicitação de isenção for negada 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á passou, tal Aditamento aprovado será considerado em vigor imediatamente na data da negação), considerando que o Operador de registro poderá, em até trinta (30) dias consecutivos após o recebimento da determinação da ICANN, recorrer da decisão da ICANN de negar 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 um aditamento a este Contrato durante a pendência do processo de resolução de disputas. Para evitar dúvidas, somente as Solicitações de isenção submetidas pelo Operador de registro que são aprovadas pela ICANN nos termos desta Seção 7.6(j),

acordada pela ICANN seguindo mediação nos termos da Seção 5.1 ou por meio de 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) deverá ter qualquer efeito nos termos deste Contrato ou isentar o Operador de registro de qualquer Aditamento aprovado.

(i) Exceto conforme o disposto nesta Seção 7.6, Seção 7.7 e de outra maneira disposto neste Contrato e nas Especificações deste instrumento, nenhum aditamento, suplemento ou modificação deste Contrato ou nenhuma disposição deste será vinculante a menos que executado 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 assinar modificações ou aditamentos bilaterais neste Contrato, negociados exclusivamente entre as duas partes. Nenhuma renúncia de nenhuma disposição deste Contrato será vinculante a menos que evidenciada por meio de documento assinado pela parte renunciando a conformidade a essa disposição. Nenhuma renúncia de nenhuma das disposições deste Contrato ou a não aplicação das disposições deste será considerada ou constituirá uma renúncia a nenhuma outra disposição deste instrumento, bem como nenhuma renúncia dessa natureza constituirá uma renúncia contínua 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 como 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 seguintes termos deverão ter os significados a seguir:

(i) "Operadores de registro aplicáveis" significa, coletivamente, os operadores de registro da parte de domínios de primeiro nível para um Contrato de registro que contém uma disposição similar para esta Seção 7.6, inclusive o Operador de registro.

(ii) “Aprovação de operador de registro” significa o 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 de taxas (convertido em dólar norte-americano, 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) para a ICANN por todos os Operadores de registro aplicáveis durante o ano civil imediatamente anterior nos termos dos Contratos de registros aplicáveis, e (B) a aprovação favorável de uma maioria dos Operadores de registro aplicáveis no momento em que tal aprovação é 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" significa o seguinte: (A) um aditamento de especificação 1, (B) exceto no que trata a Seção 2.10 do presente documento, um aditamento que especifica o preço cobrado pelo Operador de registro para registradores de registros de nome de domínio, (C) um aditamento para a definição de Serviços de registro conforme previsto 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 no interesse público” significa um motivo que é justificado por um objetivo de interesse público importante, específico e articulado que esteja dentro da missão da ICANN e seja consistente com uma aplicação equilibrada dos valores fundamentais da ICANN conforme definido no Estatuto social da ICANN.

(v) “Grupo de trabalho” significa os representantes dos Operadores de registro aplicáveis e outros membros da comunidade indicados periodicamente pelo Grupo de partes interessadas de registro a fim de servir como um grupo de trabalho para consultoria sobre aditamentos nos 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 que satisfaçam razoavelmente à ICANN de que o Aditamento aprovado aumentaria significativamente o custo do fornecimento 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-presidente da ICANN (“CEO”) ou o Presidente do Grupo de partes interessadas de registradores (“Presidente”) desejarem discutir qualquer revisão deste Contrato, o CEO ou o Presidente, conforme aplicável, fornecerá à outra parte um aviso por escrito dispondo em detalhes razoáveis as revisões propostas deste Contrato

(“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 de consenso 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 em um 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) farão consulta em boa-fé sobre negociações relacionadas à forma e ao conteúdo das revisões propostas para este Contrato, que poderá ser 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á uma notificação 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 considerarã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 aprovação do Operador 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 um aditamento a este Contrato entrará em vigor e será considerado 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ão fornecer à 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 mediação imparcial, facilitadora (não avaliativa) de acordo com os termos e as condições dispostas abaixo. Caso seja fornecido o Aviso de mediação, a ICANN e o Grupo de trabalho deverão, em até quinze (15) dias consecutivos, publicar simultaneamente o texto da 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 só mediador selecionado pelas partes. Se as partes não puderem concordar com um mediador em até quinze (15) dias consecutivos após o recebimento pelo CEO ou Presidente, conforme aplicável, do Aviso de mediação, as partes selecionarão imediatamente uma entidade mediadora mutuamente aceitável, que, assim que possível após a seleção dessa entidade, nomeará um mediador, que será um advogado licenciado com conhecimento geral sobre a lei 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. Todo mediador deverá confirmar por escrito que ele ou ela não é, e não se tornará, durante o período da mediação, funcionário, parceiro, diretor executivo, executivo ou responsável pela segurança da ICANN nem de um Operador de registro aplicável. Se esta 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 ele ou ela determinará após consulta com as partes. As partes discutirão a disputa em 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 repartirão igualmente as taxas e as despesas do mediador.

(iv) Se um acordo for alcançado 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 considerarão os comentários públicos enviados sobre as Revisões propostas acordadas 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 enviados para aprovação do Operador 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 um aditamento a este Contrato entrará em vigor e será considerado em sessenta (60) dias consecutivos após o envio de aviso da ICANN ao Operador de registro.

(v) Se as partes não resolveram a disputa par algum motivo até a data correspondente a noventa (90) dias consecutivos após o recebimento pelo CEO ou o Presidente, conforme aplicável, da Notificação de mediação, a mediação será encerrada imediatamente (a menos que estendida por acordo das partes). O mediador entregará às partes uma definição das questões que poderá ser considerada em arbitragem futura, se solicitada. Estas questões estão sujeitas às prescrições dispostas na Seção 7.7(e)(ii) abaixo.

(e) Se, após a mediação, a ICANN e o Grupo de trabalho não alcançarem um acordo sobre as Revisões propostas, o CEO ou o Presidente poderão fornecer à 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 vinculante de acordo com as disposições de arbitragem da Seção 5.2, sujeita aos requisitos e às prescrições desta Seção 7.7(e).

(i) Se for enviado um Aviso de arbitragem, a definição do mediador sobre as questões, junto 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 pelo menos trinta (30) dias consecutivos. A ICANN e o Grupo de trabalho considerarã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), e as informações relacionadas a esses comentários e será

considerado um tribunal arbitral 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 para comentários públicos, e a ICANN não poderá unir todas as contestações levantadas pelos operadores de registro (incluindo o Operador de registro) em um só 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, no que diz respeito ao objeto das Revisões propostas, se ela (i) for relacionada à Política de consenso, (ii) enquadrar-se nas categorias de objeto dispostas na Seção 1.2 da Especificação 1, ou (iii) tiver como objetivo aditar qualquer uma das seguintes disposições ou Especificações deste Contrato: Artigos 1, 3 e 6; Secçõ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 as especificações de 1, 4, 6, 10 e 11.

(iii) O mediador apresentará um resumo ao tribunal arbitral com relação às propostas respectivas 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 aprovação do Operador de registro e, no caso da ICANN, o aditamento proposto tenha sido aprovado pela Diretoria da ICANN.

(v) Para que o tribunal arbitral aprove o aditamento proposto da ICANN ou do Grupo de trabalho relacionado às Revisões propostas, o tribunal arbitral deverá concluir que esse aditamento proposto é consistente com uma aplicação equilibrada dos valores centrais da ICANN (conforme descrito nos Estatutos da ICANN) e ser razoável considerando a relação

custo-benefício para os interesses comerciais dos Operadores de registro aplicáveis e da ICANN (conforme aplicável), e o benefício público almejado com as Revisões propostas conforme disposto nesse aditamento. Se o tribunal arbitral 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 um aditamento para este Contrato sessenta (60) dias consecutivos após o envio de notificação pela ICANN 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 disposições 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 que satisfaçam razoavelmente à ICANN de que o Aditamento aprovado aumentaria significativamente o custo do fornecimento 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 de acordo com a Seção 4.4(b).

7.8 Sem terceiros beneficiários. Este Contrato não será interpretado para criar nenhuma obrigação da ICANN nem do Operador de registro com qualquer outra parte não constante neste Contrato, incluindo qualquer registrador ou titular de nome registrado.

7.9 Avisos gerais. Com exceção dos avisos nos termos das Cláusulas 7.6 e 7.7, todos os avisos que serão fornecidos sob ou em relação a este Contrato, serão dados (i) por escrito no endereço da parte apropriada conforme descrito abaixo ou (ii) por fax ou correio eletrônico conforme previsto 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 fornecido no presente Contrato. Todos os avisos, nos termos das Seções 7.6 e 7.7, devem 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 do aviso a seguir será fornecida pela parte no prazo de trinta (30) dias consecutivos após a alteração. Além dos avisos nas Seções 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 fax ou por correio eletrônico, após a confirmação de recebimento pelo servidor de e-mail ou da máquina de fax do destinatário, desde que tal aviso seja acompanhado por uma cópia enviada por correio no prazo de 3 (três) dias consecutivos. Qualquer notificação exigida pelas Seções 7.6 ou 7.7 será considerada como tendo sido fornecida quando publicada 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, tais como avisos por meio de um site seguro, as partes trabalharão juntas para implementar tal meio de avisos nos termos deste Contrato.

Se for destinada à ICANN, endereçada para:

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

Xxx Xxxxxxx, XX 00000-0000 XUA

Telefone: x0-000-000-0000

Fax: x0-000-000-0000

Aos cuidados de: Presidente e CEO

Com cópia para: Conselheiro geral

E-mail:(Conforme especificado periodicamente.)

Se for destinada ao Operador de registro, endereçada a: [_ _]

[_ _]

[_ _]

Telefone:

Com cópia para:

E-mail:(Conforme especificado periodicamente.)

7.10 Contrato completo. Este Contrato (incluindo as especificações e documentos incorporados por referência a URLs que formam uma 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, verbais ou por escrito, entre as partes sobre o assunto.

7.11 Prevalência do idioma inglês. Independente 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 todas as especificações mencionadas são as versões oficiais que vinculam as partes. No caso de qualquer conflito ou discrepância entre qualquer versão traduzida deste Contrato e a versão original em Inglês, prevalece a versão em Inglês. As notificações, designações, determinações e especificações feitas sob este Contrato serão no idioma Inglês.

7.12 Direitos de propriedade. Nada do que consta neste Contrato deverá ser interpretado como (a) a determinação ou concessão ao Operador de registro de quaisquer direitos de propriedade imóvel ou interesses de Operador de registro no TLD ou as letras, palavras, símbolos ou outros caracteres que compõem a cadeia de caracteres de TLD, ou

(b) o impacto 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 divisível; a invalidade ou ineficácia de qualquer termo ou disposição do presente Contrato não afetará a validade ou a aplicabilidade do equilíbrio do presente Contrato ou de qualquer outro termo do presente documento, que permanecerá em pleno vigor e efeito. Se qualquer uma das disposições deste for considerada inválida ou inexequí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 processo de revisão e consideração da ICANN de supostos conflitos entre a legislação pertinente e cláusulas não relacionadas ao WHOIS deste Contrato. Até que este procedimento seja desenvolvido e implementado, a ICANN analisará e considerará supostos conflitos entre a legislação

pertinente e cláusulas não relacionadas ao WHOIS deste Contrato de maneira semelhante ao procedimento para tratar os conflitos de WHOIS com a Lei de privacidade da ICANN.

7.14 Decisões judiciais. A ICANN respeitará qualquer decisão de um tribunal de foro competente, incluindo qualquer ordem de qualquer foro onde o consentimento ou a objeção do governo seja um requisito para a delegação do TLD. Não obstante qualquer outra disposição deste Contrato, a implementação por parte da ICANN de tal decisão não será uma violaçã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 encerramento, cada uma das partes fará com que os seus afiliados administradores, diretores, funcionários e agentes mantenham sigilo e não publiquem nem divulguem a terceiros, direta ou indiretamente, qualquer informação que a parte divulgadora marcou como "segredo comercial confidencial", ou de outra forma designou por escrito à parte destinatária como "informações comerciais confidenciais" ou

"informações financeiras confidenciais” (coletivamente, "Informações confidenciais"), salvo na medida em que tal divulgação é permitida pelos termos deste Contrato.

(b) Os compromissos de confidencialidade impostos 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, de uso público, publicação de conhecimentos gerais ou similar, sem culpa da parte divulgadora na violação deste Contrato, (ii) possa ser demonstrada pela documentação ou outra prova competente que se encontrava na posse da parte destinatária antes da divulgação pela parte divulgadora sem qualquer compromisso de confidencialidade em relação a tais informações, (iii) seja posteriormente recebida pela parte destinatária de um terceiro sem vínculo com qualquer compromisso de confidencialidade com relação a tais informações, (iv) foi publicada por um terceiro ou de outro modo entrou no domínio público não por culpa da parte destinatária, ou (v) possa ser demonstrada pela documentação ou outras provas competentes ter sido desenvolvida de modo independente pela parte destinatária ou para esta, 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 seja de outra forma exigida pela legislação pertinente, desde que, no entanto, a parte destinatária avise primeiro a parte divulgadora e seja dada à 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 pertinente sejam mantidas em sigilo por tal tribunal ou outro terceiro destinatário, a menos que o destinatário não seja autorizado a fornecer tal aviso sob tal ordem ou legislação pertinente, ou (ii) feita pela parte destinatária ou qualquer de suas afiliadas aos próprios procuradores, auditores, assessores, consultores, contratados ou outros terceiros para uso por tal pessoa ou entidade que possa ser

necessário ou útil em conexão com o desempenho das atividades no âmbito deste Contrato, desde que o terceiro seja vinculado por compromisso de confidencialidade, pelo menos, tão rigoroso como o aqui estabelecido, seja por acordo escrito ou por meio de padrões 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 a lei e os tratados públicos internacionais, coletivamente doravante denominada "Legislação pertinente"). Nada do que consta no presente Contrato e em suas especificações relacionadas deverá ser construído ou interpretado para exigir que o Operador de registro viole a legislação pertinente ou impeça seu cumprimento. As Partes acordam que o cumprimento da legislação pertinente por parte do Operador de registro não constitui uma violação do presente Contrato.

(b) Caso o Operador de registro determine com bom senso que qualquer cláusula do presente Contrato e as respectivas especificações relacionadas, ou qualquer decisão ou política da ICANN referente ao presente Contrato, incluindo por exemplo as Políticas temporárias e as Políticas de consenso (como cláusulas, especificações e políticas, coletivamente doravante, "Requisitos da ICANN"), possam entrar em conflito ou violar a legislação pertinente (doravante, “Conflito potencial"), o Operador de registro deverá avisar detalhadamente (o "Aviso") tal Conflito potencial a ICANN o mais breve possível e, no caso de um Conflito potencial com uma proposta de Política de consenso, o mais tardar ao final de qualquer período de comentário público sobre tal Política de consenso proposta. Caso o Operador de registro determine que não há Conflito potencial entre uma legislação pertinente proposta e qualquer Requisito da ICANN, o Operador de registro deverá fornecer um aviso detalhado de tal Conflito potencial à ICANN, o mais breve possível e, no caso de um Conflito potencial com uma Política de consenso proposta, o mais tardar ao final de qualquer período de comentário público sobre essa Política de consenso proposta.

(c) Logo que possível após essa revisão, as partes devem tentar resolver o Conflito potencial 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 conflito entre a legislação pertinente e qualquer Requisito da ICANN. Se, após a mediação, o Operador de registro determinar que o Conflito potencial constitui um conflito real entre qualquer Requisito da ICANN e a legislação pertinente, a ICANN deve renunciar ao cumprimento deste requisito (desde que as partes negociem em boa fé continuamente, logo após o ocorrido, para atenuar ou eliminar os efeitos de tal descumprimento da ICANN), a menos que a ICANN, razoável e objetivamente, determine 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, a Internet ou o DNS (doravante, "Determinação da ICANN"). Após o recebimento da notificação desta Determinação da ICANN pelo Operador de registro, deverá ser concedido um período de 90 (noventa) dias consecutivos para a resolução desse tipo de conflito com a legislação pertinente. Se o conflito com a legislação pertinente não for resolvido para a satisfação completa da ICANN durante esse período, o Operador de registro terá a opção de apresentar, no prazo de 10 (dez) dias consecutivos a contar desta data, a questão para arbitragem obrigatória, tal como definido no parágrafo (d) abaixo. Se, durante esse período, o Operador de registro não enviar a questão para arbitragem nos termos do parágrafo (d) abaixo, a ICANN poderá, mediante notificação ao Operador de registro, rescindir este Contrato imediatamente.

(d) Se o Operador de registro discordar de uma Determinação da ICANN, ele poderá enviar a questão para arbitragem nos termos das cláusulas na Seção 5.2, exceto se a única questão apresentada para determinação do árbitro seja o fato ou não de a ICANN, de modo razoável e objetivo, ter adotado a Determinação da ICANN. Para fins de tal arbitragem, a ICANN deve apresentar provas ao árbitro para sustentar a Determinação da ICANN. Se o árbitro determinar que a ICANN não agiu de forma razoável e objetiva para chegar à Determinação da ICANN, a ICANN deve dispensar o cumprimento do Operador de registro referente à Determinação da ICANN. Se os árbitros ou juiz pré-arbitral, conforme o caso, determinarem que a ICANN, de modo razoável e objetivo, adotou a Determinação da ICANN, então, mediante aviso ao Operador de registro, a ICANN poderá rescindir este Contrato imediatamente.

(e) O Operador de registro declara e garante que, com o melhor de seu conhecimento a partir da data da assinatura deste Contrato, nenhum requisito da ICANN entra em conflito ou viola alguma legislação pertinente.

(f) Não obstante qualquer cláusula desta Seção 7.16, seguindo uma Determinação da ICANN e antes de uma conclusão por um intermediador nos termos da Seção 7.16 (d) acima, a ICANN poderá, sujeito a consultas prévias com o Operador de registro, tomar as medidas técnicas razoáveis que considere necessárias para garantir a Segurança e a Estabilidade dos Serviços de Registro, Internet e DNS. Estas 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 mencionado na Seção 7.16(d) acima ou da data da resolução completa do conflito com alguma legislação pertinente. Caso o Operador de registro não concorde com as medidas técnicas tomadas pela ICANN, ele poderá enviar a questão à arbitragem vinculante nos termos das cláusulas na Seção 5.2 acima, processo durante o qual a ICANN poderá continuar a tomar as 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 deverá reter e poderá exercer seus direitos sob o Instrumento de operações contínuas e o Instrumento alternativo, conforme o caso.

* * * * *

ESTANDO JUSTAS E CONTRATADAS, as partes celebram este Contrato por 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 Guia do solicitante de gTLD da ICANN (localizado em xxxx://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á fornecer qualquer serviço que seja exigido pelos 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 vigência do Contrato e o Operador de registro poderá prestar tais serviços:

ESPECIFICAÇÃO 1

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

1. Políticas de consenso.

1.1. “Políticas de consenso” são políticas estabelecidas (1) de acordo com o procedimento disposto no Estatuto da ICANN e o devido processo e (2) que abrangem os tópicos relacionados na Seção 1.2 desta Especificação. O conjunto de procedimentos e o processo de desenvolvimento da Política de consenso dispostos nos Estatutos da ICANN poderão ser revisados esporadicamente de acordo com o processo previsto neste instrumento.

1.2. As Políticas de consenso 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, incluindo os operadores de gTLDs. As Políticas de consenso estarão relacionadas a um ou mais dos seguintes itens:

1.2.1 questões para as quais é razoavelmente necessária uma resolução coordenada ou uniforme a fim de 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 de registro para o TLD;

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

1.2.5 resolução de contestações referentes ao registro de nomes de domínio (em oposição ao uso desses nomes de domínio); ou

1.2.6 restrições para propriedade cruzada dos operadores de registro e registradores ou revendedores de registros e regulamentações e restrições com relação às operações de registro e o uso de dados de registro e de registrador caso um Operador de registro e um registrador ou revendedor sejam afiliados.

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

1.3.1 princípios para a alocação de nomes registrados no TLD (por exemplo, FCFS (first-come/first-served, primeiro a chegar/primeiro atendido), renovação em tempo hábil, período de espera após vencimento);

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

1.3.3 reserva de nomes registrados em um TLD que podem não estar registrados inicialmente ou que não podem ser renovados devido a motivos razoavelmente relacionados a (i) modos de evitar a confusão ou o engano entre os usuários, (ii) propriedade intelectual ou (iii) o gerenciamento técnico do DNS ou da Internet (por exemplo, o estabelecimento de reservas de nomes na inscrição 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 do registro de nomes de domínio devido à suspensão ou ao rescisão das operações de um Operador de registro ou de um registrador, incluindo procedimentos para a alocação de responsabilidade para exercer nomes de domínio registrados em um TLD afetado por tal suspensão ou rescisão.

1.4. Além de outras prescrições das Políticas de Consenso, elas:

1.4.1 não determinarão nem limitarão o preço dos Serviços de registro;

1.4.2 não modificarão os termos ou condições para a renovação ou encerramento do Contrato de registro;

1.4.3 não modificarão as prescrições das Políticas Temporárias (definidas abaixo) nem das Políticas de Consenso;

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

1.4.5 nem modificarão as obrigações da ICANN para garantir o tratamento equitativo dos operadores de registro e agirão 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 sejam justificados e que seja necessário o estabelecimento temporário imediato de uma especificação ou política para o objeto, a fim de 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 sucinta 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 de consenso, disposto nos Estatutos 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 por que a Diretoria acredita que essa Política Temporária deverá 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 de consenso. 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 de consenso e não for reafirmada pela Diretoria, o Operador de registro não será mais obrigado a implementar nem cumprir com essa Política temporária.

3. Notificação e conflitos. O Operador de registro terá um tempo razoável após o envio da notificação de estabelecimento de uma Política de consenso 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 de consenso ou qualquer Política temporária, as Políticas de consenso ou a Política temporária serão aplicadas, mas apenas com relação ao objeto em conflito.

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

O Operador de registro envolverá uma entidade independente para atuar como agente de depósito 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 acordo de depósito de dados entre o Operador de registro e o Agente depositário, nos termos do qual a ICANN deve ser nomeada como um terceiro beneficiário. Além dos requisitos a seguir, o acordo de depósito de dados pode conter outras cláusulas que não sejam contraditórias ou que tenham a intenção de subverter os termos obrigatórios fornecidos 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” será composto de dados que refletem o estado do registro a partir da 00:00:00 UTC (Tempo Universal Coordenado) no dia em que tal Depósito integral é 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 operações de banco de dados desde que o Depósito anterior tenha sido concluído a partir da 00:00:00 UTC de cada dia, exceto domingo. Os Depósitos diferenciais devem incluir Registros depositados completos, conforme especificado abaixo, que não foram incluídos ou alterados desde o Depósito diferencial ou integral mais recente (ou seja, nomes de domínio adicionados ou modificados recentemente).

2. Cronograma para depósitos. O Operador de registro enviará um conjunto de arquivos depositados diariamente da seguinte maneira:

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

2.2. Nos outros seis (6) dias da semana, deve 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, nomes de servidores, registradores etc., serão compilados em um arquivo construído como descrito em draft-arias-noguchi-registry-data-escrow, consulte a Parte A, Seção 9, referência 1 desta Especificação e

draft-arias-noguchi-dnrd-objects-mapping, 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á estes elementos nos Depósitos se eles estiverem disponíveis. Se ainda não tiver uma RFC, o Operador de registro usará o versão preliminar mais recente da Especificação DNDE disponível na Data de vigência. O Operador de registro poderá, a seu critério, usar versões mais recentes das Especificação DNDE após a Data de vigência. Uma vez que a Especificação DNDE é publicada como uma RFC, o Operador de registro implementará esta versão da Especificação DNDE, em até cento e oitenta

(180) dias consecutivos. Será utilizada a codificação de caracteres UTF-8.

3.2. Extensões. Se um Operador de registro oferecer Serviços de registro adicionais que exigem a apresentação de dados adicionais, não incluídos acima, os "esquemas de extensão" adicionais para representar estes dados serão definidos caso a caso. Estes "esquemas de extensão" serão especificados como descrito na parte A, Seção 9, referência 2 desta

Especificação. Os dados relativos aos “esquemas de extensões” 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 destes novos objetos.

4. Processamento de arquivos de depósitos. É recomendado o uso de compressão no intuito de reduzir o tempo de transferência eletrônica de dados e os requisitos de capacidade de armazenamento. A criptografia de dados será utilizada para garantir a privacidade dos dados de depósito de registro. Os arquivos processados para compressão e criptografia serão no formato OpenPGP binário, como por formato de mensagem OpenPGP - RFC 4880, 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 compressão são as enumeradas no RFC 4880, não marcados como obsoletos no registro OpenPGP IANA, consulte a Parte A, Seção 9, Referência 4 desta Especificação, que também são gratuitos. O processo a seguir 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 (1), mas com a extensão tar.

(3) A mensagem OpenPGP compactada e criptografada é criada usando o arquivo tarball como entrada única. O algoritmo sugerido para compressão é ZIP, de acordo com o RFC 4880. Os dados comprimidos 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 o RFC 4880. Os algoritmos sugeridos para a criptografia de chave simétrica são TripleDES, AES128 e CAST5, de acordo com o RFC 4880.

(4) Se necessário, o arquivo pode ser dividido caso, uma vez compactado e criptografado, seja maior do que o limite de tamanho de arquivo acordado com o agente depositário. Cada parte de um arquivo dividido, ou do arquivo inteiro, será chamada 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 será em formato OpenPGP binário de acordo com RFC 4880 Seção 9, referência 3 e não será compactado nem criptografado. Os algoritmos sugeridos para as assinaturas digitais são o DSA e o RSA, de acordo com o RFC 4880. O algoritmo sugerido para hashes nas assinaturas digitais é o 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. Podem ser feitas entregas por meios não eletrônicos por mídia física, como CD-ROM, DVD-ROM ou dispositivos de armazenamento USB, desde que autorizado pela ICANN.

(7) O Agente depositário, em seguida, validará cada arquivo de dados transferidos (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 convenção a seguir: {gTLD}_{YYYY-MM-DD}_{type}_S{#}_R{rev}.{ext}, onde:

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

5.2. {AAAA-MM-DD} é substituída pela data correspondente ao horário utilizado como uma marca d'água do cronograma das transações; ou seja, para 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 representam um Depósito integral;

(2) "diff", se os dados representam um Depósito diferencial;

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

5.4. {#} é substituído pela posição do arquivo em uma série de arquivos, começando com "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 que começa com "0":

5.6. {ext} é substituído por "sig" se for um arquivo de assinatura digital do arquivo quase homônimo. Caso contrário, ele é 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 em reunião presencial, telefone etc. Desta forma, a transmissão de chave pública é autenticada para um usuário capaz de enviar e receber e-mails através 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 (que pode ser por e-mail autenticado), que contém uma cópia do relatório gerado após a criação do Depósito e afirma que o Depósito foi inspecionado pelo Operador de

registro e está completo e preciso. O Operador de registro incluirá a “id” do

Depósito e “reenviará" os atributos 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 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 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 forem peças de um arquivo maior, o último é colocado junto.

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

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

(5) Se Parte A, Seção 9, referência 1 desta Especificação contiver um processo de verificação, este será aplicado nesta etapa.

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

9. Referências.

(1) Especificação do Depósito de dados do nome de domínio (em andamento), xxxx://xxxxx.xxxx.xxx/xxxx/xxxxx-xxxxx-xxxxxxx-xxxxxxxx-xxxx-xxxxxx

(2) Mapeamento de objetos de dados de registro de nome de domínio (DNRD), xxxx://xxxxx.xxxx.xxx/xxxx/xxxxx-xxxxx-xxxxxxx-xxxx-xxxxxxx-xxxxxxx

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

(4) Parâmetros OpenPGP, http://xxx.xxxx.xxx/assignments/pgp&#x1E;parameters/pgp&#x1E;para meters.xhtml

(5) Interfaces da ICANN para registros e agentes de depósito de dados, xxxx://xxxxx.xxxx.xxx/xxxx/xxxxx-xxxxxx-xxxxx-xxxxxxxx-xxxxxxxxxx

PARTE B - REQUISITOS LEGAIS

1. Agente depositário. Antes de celebrar um contrato de depósito, o Operador de registro deve fornecer 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 relevante e todas as alterações contratuais anexas. 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) assinar o formulário de contrato de depósito fornecido. A ICANN deve 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 qualquer alteração contratual a seu exclusivo critério.

2. Taxas. O Operador de registro deve pagar, ou ter pago em seu nome, as taxas diretamente ao Agente depositário. Se o Operador de registro deixar de pagar qualquer taxa na devida data de vencimento, o Agente depositário fornecerá à ICANN um aviso por escrito de inadimplência e a ICANN poderá pagar a(s) taxa(s) vencida(s) no prazo de quinze (15) dias consecutivos após o recebimento do aviso por escrito do Agente depositário. Após o pagamento das taxas em atraso por parte da ICANN, a ICANN poderá solicitar tal valor do Operador de registro, que o Operador de registro é obrigado a pagar à ICANN juntamente com o próximo pagamento da taxa devida 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. Dali em diante, o Operador de registro deve atribuir qualquer direito de propriedade (inclusive direitos de propriedade intelectual, conforme o caso) de 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 mantido pelo Operador de registro nos Depósitos será automaticamente licenciado para a ICANN ou uma parte designada por escrito pela ICANN de modo não exclusivo, perpétuo, irrevogável, gratuito e integralizado para qualquer uso relacionado com a operação, manutenção ou transição de TLD.

4. Integridade e confidencialidade. O Agente depositário será obrigado a (i) realizar 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 a conformidade do Agente depositário com as especificações técnicas e requisitos de manutenção desta Especificação 2 esporadicamente.

Se um Agente depositário receber uma intimação ou qualquer outra citação de um tribunal ou outro tribunal judicial referente à divulgação ou liberação dos Depósitos, o Agente depositário deverá notificar imediatamente o Operador de registro e a ICANN, a menos que proibido por lei. Após notificar 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 sua posição com 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 tenha solicitado assistência adicional deverá arcar com os encargos padrão do Agente depositário ou como citado, mediante a apresentação de um pedido detalhado.

5. Cópias. O Agente depositário pode ter permissão para duplicar qualquer Depósito no intuito de atender aos termos e às cláusulas do contrato de depósito.

6. Lançamento 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 um dos avisos por escrito a seguir por parte da ICANN, afirmando que:

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

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

6.3. A ICANN recebeu a notificação do Agente depositário, conforme descrito na Parte B, Seções 7.1 e 7.2 desta Especificação ou não verificou o último depósito de dados em uma data específica ou uma notificação da falta de depósito e a notificação for para um depósito que deve ter sido feito no domingo (ou seja, um Depósito integral); (a) a ICANN notificou o Operador de registro de tal recebimento, e (b) a ICANN não recebeu tal notificação do Agente depositário, no prazo de 7 (sete) dias após o aviso, conforme descrito na Parte B, Seções 7.1 e 7.2 desta Especificação, da 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 de que os depósitos de dados em inadimplência ou com falha que deveriam ter sido feitos de segunda a sábado

(ou seja, um Depósito diferencial), e (x) a ICANN forneceu aviso ao Operador de registro do recebimento dessas notificações, e (y) a ICANN não recebeu, no prazo de sete (7) dias consecutivos após a entrega de tal aviso ao Operador de registro, a notificação do Agente depositário da verificação de uma versão corrigida desse 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 qualquer situação análoga a qualquer um dos anteriores sob as leis de qualquer foro em qualquer lugar do mundo; ou

6.6. O Operador de registro teve uma falha nas funções críticas de registro e a ICANN insistiu em 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 lançado anteriormente os depósitos do Operador de registro para a ICANN ou seu representante, o Agente depositário entregará todos os Depósitos à ICANN na expiração ou rescisão do Contrato de registro ou do Contrato de depósito.

7. Verificação de depósitos.

7.1. No 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 Depósito 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 ao 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 essa não conformidade ou não recebimento no prazo de vinte e quatro (24) horas após ter recebido o Depósito em não conformidade ou fora do prazo para tal depósito, conforme o caso. Após a notificação desta falha de verificação ou entrega, o Operador de registro deve começar a desenvolver alterações, atualizações, correções e outros ajustes do Depósito necessários para que ele seja entregue e passe pelos 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 alterar os termos do Contrato de depósito de acordo com a presente Especificação 2 dentro de dez (10) dias consecutivos de 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 deverá 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 e contra 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 e custos advocatícios que possam ser reivindicados por terceiros contra qualquer Indenizado referente à 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 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 até 3 (três) meses após o final do mês ao qual se refere o relatório. A menos que estabelecido 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 refletem o estado do registro no final do mês (UTC).

1. Relatório de transações por registrador. Esse relatório deve ser compilado em um arquivo formatado em valores separados por vírgulas, conforme especificado no RFC 4180. O arquivo deve ser nomeado “gTLD-transações-aaaamm.csv", onde "gTLD" é o nome do gTLD; no caso um IDN-TLD, deve ser utilizada a etiqueta A; “aaaamm" é o ano e o mês que está sendo informado. O arquivo deverá conter os campos por registrador a seguir:

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 do registro atue como registrador (ou seja, sem o uso de um registrador acreditado pela ICANN) deve ser usado 9999, caso contrário deve ser usado o ID de registrador responsável da IANA, conforme especificado em xxxx://xxx.xxxx.xxx/xxxxxxxxxxx/xxxxxxxxx-xxx
03	total-domains	o total de nomes de domínio sob responsabilidade em qualquer status de EPP, mas pendingCreate que não tenham sido eliminados
04	total-nameservers	o 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 de EPP, mas pendingCreate que não tenham sido descartados
05	net-adds-1-yr	o número de domínios registrados com sucesso (ou seja, não estão com status EPP pendingCreate) em um período inicial de um (1) ano (e não excluídos dentro do período de tolerância). A transação deve

		ser relatada no mês em que termina o período de tolerância.
06	net-adds-2-yr	o número de domínios registrados com sucesso (ou seja, não estão com status EPP pendingCreate) em um período inicial de dois (2) anos (e não excluídos dentro do período de tolerância). A transação deve ser relatada no mês em que termina o período de tolerância.
07	net-adds-3-yr	o número de domínios registrados com sucesso (ou seja, não estão com status EPP pendingCreate) 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 deve ser relatada no mês em que termina o período de tolerância.
08	net-adds-4-yr	o número de domínios registrados com sucesso (ou seja, não estão com status EPP pendingCreate) em um período inicial de quatro (4) anos (e não excluídos dentro do período de tolerância). A transação deve ser relatada no mês em que termina o período de tolerância.
09	net-adds-5-yr	o número de domínios registrados com sucesso (ou seja, não estão com status EPP pendingCreate) em um período inicial de cinco (5) anos (e não excluídos dentro do período de tolerância). A transação deve ser relatada no mês em que termina o período de tolerância.
10	net-adds-6-yr	o número de domínios registrados com sucesso (ou seja, não estão com status EPP pendingCreate) em um período inicial de seis (6) anos (e não excluídos dentro do período de tolerância). A transação deve ser relatada no mês em que termina o período de tolerância.
11	net-adds-7-yr	o número de domínios registrados com sucesso (ou seja, não estão com status EPP pendingCreate) em um período inicial de sete (7) anos (e não excluídos dentro do período de tolerância). A transação deve ser relatada no mês em que termina o período de tolerância.
12	net-adds-8-yr	o número de domínios registrados com sucesso (ou seja, não estão com status EPP pendingCreate) em um período inicial de oito (8) anos (e não excluídos dentro do período de tolerância). A transação deve ser relatada no mês em que termina o período de

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

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

		período de renovação de dez (10) anos (e não excluídos no período de renovação ou de tolerância de renovação automática). A transação deve ser relatada no mês em que o período de renovação ou de tolerância de renovação automática termina.
25	transfer-gaining-successfu l	o número de transferências de domínio iniciadas por este registrador que foram concluídas com sucesso (explícitas ou automaticamente aprovadas) e não excluídas dentro do período de tolerância de transferência. A transação deve ser relatada no mês em que o período de tolerância de transferência termina.
26	transfer-gaining-nacked	o número de transferências de domínio iniciadas por este registrador que foram rejeitadas (por exemplo, transferência EPP op="reject") por outro registrador
27	transfer-losing-successfull y	o número de transferências de domínio iniciadas por outro registrador que foram concluídas com êxito (explícitas ou automaticamente aprovadas)
28	transfer-losing-nacked	o número de transferências de domínio iniciadas por outro registrador que esse registrador rejeitou (por exemplo, transferência EPP op="reject")
29	transfer-disputed-won	o número de disputas de transferência em que esse registrador prevaleceu (relatada no mês em que ocorreu a determinação)
30	transfer-disputed-lost	o número de disputas de transferência que esse registrador perdeu (relatada no mês em que ocorreu a determinação)
31	transfer-disputed-nodecisi on	o número de disputas de transferência envolvendo esse registrador com uma decisão dividida ou nenhuma decisão (relatada no mês em que ocorreu a determinação)
32	deleted-domains-grace	os domínios excluídos no período de tolerância (não inclui nomes excluídos enquanto o status for EPP pendingCreate). A exclusão deve ser relatada no mês em que o nome foi descartado.
33	deleted-domains-nograce	os domínios excluídos fora do período de tolerância (não inclui nomes excluídos enquanto o status for EPP pendingCreate). A exclusão deve ser relatada no mês em que o nome foi descartado.
34	restored-domains	os nomes de domínio restaurados do período de resgate
35	restored-noreport	o número total de nomes restaurados para o qual o

		registrador não conseguiu apresentar um relatório de restauração
36	agp-exemption-requests	o número total de solicitações de isenção AGP (incluir período de tolerância)
37	agp-exemptions-granted	o número total de isenções AGP concedidas (incluir período de tolerância)
38	agp-exempted-domains	o número total de nomes afetados pelas solicitações de isenção de agp concedidas (incluir período de tolerância)
39	attempted-adds	o número de tentativa de comandos de criar nomes de domínio (bem-sucedidas e falhas)

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

2. Relatório de atividade de funções de registro. Esse relatório deve ser compilado em um arquivo formatado em valores separados por vírgulas, conforme especificado no RFC 4180. O arquivo deve ser nomeado

“gTLD-activity-yyyymm.csv", onde "gTLD" é o nome de gTLD, em caso de um IDN TLD, deve ser utilizada a etiqueta A; “yyyymm" é o ano e o mês que está sendo informado. O arquivo deverá conter os campos a seguir:

Campo #	Nome do campo	Descrição
01	operational-registrars	o número de registradores operacionais no final do período relatado
02	ramp-up-registrars	o número de registradores que receberam uma senha de acesso para Avaliação e teste operacional (OT&E) no final do período relatado
03	pre-ramp-up-registrars	o número de registradores que solicitaram o acesso, mas ainda não entraram no período de reforço no final do período relatado
04	zfa-passwords	o número de senhas de acesso ao arquivo de zona ativa no final do período relatado
05	whois-43-queries	o número de consultas WHOIS (porta 43) respondidas durante o período relatado
06	web-whois-queries	o número de consultas Whois baseadas na Web respondidas durante o período relatado, não incluindo Whois pesquisável

Campo #	Nome do campo	Descrição
07	searchable-whois-querie s	o número de consultas Whois pesquisáveis respondidas durante o período relatado, se esta opção for oferecida
08	dns-udp-queries-receive d	o número de consultas de DNS recebidas através de transporte UDP durante o período relatado
09	dns-udp-queries-respon ded	o número de consultas de DNS recebidas através de transporte UDP que foram respondidas durante o período relatado
10	dns-tcp-queries-received	o número de consultas de DNS recebidas através de transporte TCP durante o período relatado
11	dns-tcp-queries-respond ed	o número de consultas de DNS recebidas através do transporte de TCP que foram respondidas durante o período relatado
12	srs-dom-check	o número de solicitações de “verificação” do nome de domínio do SRS (EPP e qualquer outra interface) respondida durante o período relatado
13	srs-dom-create	o número de solicitações de “criar” nome de domínio do SRS (EPP e qualquer outra interface) respondida durante o período relatado
14	srs-dom-delete	o número de solicitações de “excluir” nome de domínio do SRS (EPP e qualquer outra interface) respondida durante o período relatado
15	srs-dom-info	o número de solicitações de “informações” de nome de domínio do SRS (EPP e qualquer outra interface) respondida durante o período relatado
16	srs-dom-renew	o número de solicitações de “renovar” de nome de domínio do SRS (EPP e qualquer outra interface) respondida durante o período relatado
17	srs-dom-rgp-restore-rep ort	o número de solicitações de “restauração” RGP de nome de domínio SRS (EPP e qualquer outra interface) fornecendo um relatório de restauração respondido durante o período relatado
18	srs-dom-rgp-restore-req uest	o número de solicitações de “restauração” do RGP de nome de domínio do SRS (EPP e qualquer outra interface) respondidas durante o período relatado
19	srs-dom-transfer-approv e	o número de solicitações de “transferência” de nome de domínio do SRS (EPP e qualquer outra interface) para aprovar transferências respondidas durante o período relatado

Campo #	Nome do campo	Descrição
20	srs-dom-transfer-cancel	o número de solicitações de “transferência” de nome de domínio do SRS (EPP e qualquer outra interface) para cancelar transferências respondidas durante o período relatado
21	srs-dom-transfer-query	o 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
22	srs-dom-transfer-reject	o número de solicitações de “transferência” de nome de domínio do SRS (EPP e qualquer outra interface) para rejeitar transferências respondidas durante o período relatado
23	srs-dom-transfer-reques t	o número de solicitações de “transferência” de nome de domínio do SRS (EPP e qualquer outra interface) para solicitação de transferências respondidas durante o período relatado
24	srs-dom-update	o número de solicitações de “atualização” de nome de domínio do SRS (não inclui solicitações de restauração de RGP) respondidas durante o período relatado
25	srs-host-check	o número de solicitações de “verificação” de host do SRS (EPP e qualquer outra interface) respondidas durante o período relatado
26	srs-host-create	o número de solicitações de “criar” host do SRS (EPP e qualquer outra interface) respondidas durante o período relatado
27	srs-host-delete	o número de solicitações de “excluir” host do SRS (EPP e qualquer outra interface) respondidas durante o período relatado
28	srs-host-info	o número de solicitações de “informações” de host do SRS (EPP e qualquer outra interface) respondidas durante o período relatado
29	srs-host-update	o número de solicitações de “atualização” de host do SRS (EPP e qualquer outra interface) respondidas durante o período relatado
30	srs-cont-check	o número de solicitações de “verificação” de contato do SRS (EPP e qualquer outra interface) respondidas durante o período relatado
31	srs-cont-create	o número de solicitações de “criar” contato do SRS (EPP e qualquer outra interface) respondidas

Campo #	Nome do campo	Descrição
		durante o período relatado
32	srs-cont-delete	o número de solicitações de “excluir” contato do SRS (EPP e qualquer outra interface) respondidas durante o período relatado
33	srs-cont-info	o número de solicitações de “informações” de contato do SRS (EPP e qualquer outra interface) respondidas durante o período relatado
34	srs-cont-transfer-approv e	o número de solicitações de “transferência” de contato do SRS (EPP e qualquer outra interface) para aprovar transferências respondidas durante o período relatado
35	srs-cont-transfer-cancel	o número de solicitações de “transferência” de contato do SRS (EPP e qualquer outra interface) para cancelar transferências respondidas durante o período relatado
36	srs-cont-transfer-query	o número de solicitações de “transferência” de contato do SRS (EPP e qualquer outra interface) para solicitação sobre uma transferência respondidas durante o período relatado
37	srs-cont-transfer-reject	o número de solicitações de “transferência” de contato do SRS (EPP e qualquer outra interface) para rejeitar transferências respondidas durante o período relatado
38	srs-cont-transfer-reques t	o número de solicitações de “transferência” de contato do SRS (EPP e qualquer outra interface) para solicitar transferências respondidas durante o período relatado
39	srs-cont-update	o número de solicitações de “atualização” de contato do SRS (EPP e qualquer outra interface) respondidas durante o período relatado

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

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

Para gTLDs que fazem parte de uma única instância do Sistema de registro compartilhado, o Relatório de atividades de funções de registro pode incluir o total de contatos ou operações de 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. Até a ICANN exigir um protocolo diferente, o Operador de registro fornecerá um serviço de WHOIS disponível pela porta 43 de acordo com o RFC 3912 e um Serviço de diretório baseado na Web em

<whois.nic.TLD> fornecendo acesso público gratuito com base em consulta pelo menos aos elementos e no formato a seguir. A ICANN se reserva o direito de especificar formatos e protocolos alternativos, e mediante essa especificação, o Operador de registro implementará essa especificação alternativa o quanto antes possível.

O Operador de registro deverá implementar um novo padrão de acesso ao suporte para dados de registro de nome de domínio (SAC 051) em até cento e trinta e cinco

(135) dias após solicitado pela ICANN, se: 1) a IETF produzir um padrão (ou seja, ele for publicado, pelo menos, como um Padrão proposto de RFC conforme especificado no RFC 2026); e 2) sua implementação for comercialmente razoável no âmbito de toda a operação do registro.

1.1. O formato das respostas seguirá a descrição de formato de texto semilivre abaixo, seguida por 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.2. Cada objeto de dados será representado como um conjunto de pares de chave/valor, com linhas iniciadas por chaves, seguidas por dois-pontos e espaço como delimitadores, seguidas pelo valor.

1.3. 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. Os campos especificados abaixo apresentam os requisitos mínimos de saída. O Operador de registro poderá incluir campos de dados de saída além dos especificados abaixo, sujeitos à aprovação pela ICANN, cuja aprovação não deve ser indevidamente recusada.

1.5. Dados do Nome de Domínio:

1.5.1 Formato da consulta: whois EXEMPLO.TLD

1.5.2 Formato da resposta:

Nome de domínio: EXEMPLO.TLD ID do domínio: D1234567-TLD Servidor WHOIS: whois.exemplo.tld

URL de referência: xxxx://xxx.xxxxxxx.xxx Data atualizada: 2009-05-29T20:13:00Z Data de criação: 2000-10-08T00:45:00Z

Data de vencimento do registro: 2010-10-08T00:44:59Z Registrador responsável: EXEMPLO DE REGISTRADOR LLC ID IANA DO Registrador responsável: 5555555

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

Nome do registrante: EXEMPLO DE REGISTRANTE EMPRESA DO REGISTRANTE: EXEMPLO DE EMPRESA

Endereço do registrante: RUA DO 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.0000000000 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: 5372809-ERL

Nome do administrador: EXEMPLO DE REGISTRANTE ADMINISTRATIVO Empresa do administrador: EXEMPLO DE REGISTRANTE DA ORGANIZAÇÃO Endereço do administrador: RUA EXEMPLO 123

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.0000000000 Ramal do telefone do administrador: 1234 Fax do administrador: +1.5555551213 Ramal do fax do administrador:

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

Nome do técnico: EXEMPLO TÉCNICO DO REGISTRADOR

Empresa 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 nome: NS01.EXAMPLEREGISTRAR.TLD Servidor de nome: NS02.EXAMPLEREGISTRAR.TLD DNSSEC: signedDelegation

DNSSEC: não assinado

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

<<<

1.6. Dados do registrador:

1.6.1 Formato da consulta: whois “registrar Example Registrar, Inc.”

1.6.2 Formato da resposta:

Nome do registrador: Example 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.0000000000 Número de fax: +1.3105551213

E-mail: xxxxxxxxxxx@xxxxxxx.xxx

Servidor WHOIS: whois.exemplo-registrador.tld

URL de referência: xxxx://xxx.xxxxxxx-xxxxxxxxxxx.xxx Contato do administrador: José Registrador

Número de telefone: +1.3105551213 Número de fax: +1.3105551213

E-mail: xxxxxxxxxxxxxxx@xxxxxxx-xxxxxxxxxxx.xxx Contato do administrador: Jane registradora Número de telefone: +1.3105551214

Número de fax: +1.3105551213

E-mail: xxxxxxxxxxxxxxx@xxxxxxx-xxxxxxxxxxx.xxx Contato técnico: João Silva

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.7. Dados do servidor de nomes:

1.7.1 Formato da consulta: whois “NS1.EXEMPLO.TLD”, whois “nameserver (nome do servidor de nome)” ou whois “nameserver (Endereço IP)”

1.7.2 Formato da resposta:

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

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

Servidor WHOIS: whois.exemplo-registrador.tld

URL de referência: xxxx://xxx.xxxxxxx-xxxxxxxxxxx.xxx

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

1.8. 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, como mostrado acima), endereços de e-mail, data e hora devem corresponder aos mapeamentos especificados no EPP RFCs 5730-5734 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.9. Para ser compatível com a interface comum da ICANN para WHOIS (InterNIC), o WHOIS será no formato mostrado acima.

1.10. Capacidade de pesquisa. Oferecer recursos para capacidade de pesquisa nos Serviços de diretório é opcional, mas se for oferecido pelo Operador de registro, ele deve respeitar as especificações descritas nesta seção.

1.10.1 O Operador de registro oferecerá a capacidade de pesquisa no Serviço de diretório baseado na Web.

1.10.2 O Operador de registro oferecerá recursos de correspondência parcial, pelo menos, nos campos a seguir: nome de domínio, contatos e nome do registrante, contato e endereço postal do registrante, inclusive todos os subcampos descritos no EPP (por exemplo, endereço, cidade, estado ou província etc.).

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

1.10.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.10.5 Os resultados de pesquisa incluem os nomes de domínio correspondente aos critérios de pesquisa.

1.10.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 ou políticas de privacidade pertinentes.

1.11. 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 WHOIS 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 CZDA”). O Operador de registro (opcionalmente através do Provedor CZDA) fornecerá acesso aos dados do arquivo de zona pela 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 CZDA pode rejeitar a solicitação de acesso de qualquer usuário que não atenda aos requisitos de credenciamento na Seção 2.1.2 abaixo; (b) o Operador de registro pode rejeitar a solicitação de acesso de qualquer usuário que não forneceu as credenciais corretas ou legítimas nos termos da Seção

2.1.2 abaixo ou quando o Operador de registro acredita que violará os termos da Seção 2.1.5 abaixo; 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 abaixo.

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 FTP de Arquivo de zona (ou outro Registro aceito) para 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 FTP, ou outros protocolos de transporte de dados e de acesso que podem ser indicados pela ICANN. Para cada servidor de acesso de arquivo de zona, os arquivos de zona estão no diretório de nível superior chamado <zona>.zone.gz, com <zona>.zona.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 <zona>-aaaammdd.zona.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 no 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 deve incluir todos os campos em uma única linha como:

<nome de domínio> <TTL> <classe> <tipo> <RDATA>.

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

3. TTL deve 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 devem estar em letras minúsculas.

6. Deve-se usar exatamente parágrafo como separador de campos dentro de um registro.

7. Todos os nomes de domínio devem 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 deve 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 devem estar em ordem alfabética.

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

<tld>.zona.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 acesso não autorizado e a utilização e divulgação dos dados e (b) em nenhuma circunstância será exigido ou concedido ao Operador de registro permitir que o usuário use os dados para: (i) permitir, possibilitar ou de alguma forma apoiar a transmissão por e-mail, telefone, fax ou outros meios de divulgação comercial em massa ou pedidos a entidades diferentes dos clientes existentes; ou (ii) possibilitar processos eletrônicos automatizados em grande volume que enviam consultas ou dados aos sistemas de qualquer Operador de registro ou registrador credenciado pela ICANN.

2.1.6 Termos 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, 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.

3.1.1 Conteúdo. O Operador de registro proporcionará, pelo menos, 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 validade e os nomes do servidor de nome. Para registradores responsáveis, pelo menos, fornecerá: nome de registro, id do objeto de repositório de nome de domínio (roid), hostname do servidor Whois e URL do registrador.

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 especificado 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 solicite a 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 como 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 as etiquetas a seguir do registro inicial (isto é, que não sejam renovação) no TLD. Se estiver usando a autoalocação, o Operador de registro deve 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. A etiqueta ASCII “EXEMPLO” será retida no registro ou será alocada 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 são coletivamente referidos aqui como "Todos os níveis"). Esta etiqueta não pode ser ativada no DNS e não pode ser disponibilizada 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 etiqueta retida ou atribuída deverá ser transferida conforme especificado pela ICANN. O Operador de registro poderá atribuir por si e renovar este 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. Etiquetas de dois caracteres. Todas as etiquetas de dois caracteres ASCII serão retidas no registro ou serão alocadas ao Operador de registro no segundo nível dentro do TLD. Estas etiquetas não podem ser ativadas no DNS e não podem ser liberadas para o registro a nenhuma pessoa ou entidade que não seja o Operador de registro, desde que tais cadeias de caracteres de etiquetas de dois caracteres possam ser liberadas na medida em que o Operador de registro chegar a um acordo com o governo relacionado 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 pode propor a liberação dessas reservas com base em sua 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, todas estas etiquetas que permanecem retidas no registro ou alocadas ao Operador de registro serão transferidas, conforme especificado pela ICANN. O Operador de registro poderá atribuir por 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. As etiquetas ASCII a seguir deverão ser retidas no registro ou alocadas 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. A etiqueta ASCII a

seguir deve ser alocada ao Operador de registro em Todos os níveis para o uso em conjunto com a operação do registro para o TLD: NIC. O Operador de registro poderá ativar o WWW, RDDS e o WHOIS no DNS, mas deve ativar o NIC no DNS, conforme necessário para a operação do TLD. Nenhum WWW, RDDS, WHOIS ou NIC pode ser disponibilizado ou registrado para nenhuma pessoa (que não seja o Operador de registro) ou terceiros. Após a conclusão da designação do Operador de registro como operador de registro para o TLD, todos estes nomes retidos ou atribuídos serão transferidos conforme especificado pela ICANN. O Operador de registro poderá atribuir por 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.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 deve agir como o Detentor do nome registrado de tais nomes, como o termo é definido no atual Contrato de credenciamento de registradores (RAA) da ICANN. Estas ativações serão consideradas transações para fins da Seção 6.1 do Contrato. O Operador de registro deve (i) registrar tais nomes por meio de um registrador credenciado pela ICANN; ou (ii) atribuir por si tais nomes e com respeito a eles enviar à ICANN e responsabilizar-se perante a ICANN pela conformidade com as Políticas de consenso da ICANN e as obrigações previstas nas Subseções 3.7.7.1 a 3.7.7.12 do RAA atual (ou qualquer outra cláusula de substituição que estabelece os termos do contrato de registro entre um registrador e um detentor de nome registrado). A critério do Operador de registro e em conformidade com todos os outros termos deste Contrato, tais nomes podem ser disponibilizados para registro para outra pessoa ou entidade.

3.3. O Operador de registro poderá negar o registro ou alocar para nomes do Operador de registro (inclusive suas variações de IDN, se for o caso) em Todos os níveis de acordo com a Seção 2.6 do Contrato. Estes nomes não podem ser ativados no DNS, mas podem ser disponibilizados para registro a outra pessoa ou entidade, a critério do Operador de registro. Após a conclusão da designação do Operador de registro como Operador de registro para o TLD, todos estes nomes que permanecerem retidos no registro ou alocados para o Operador de registro deverão ser transferidos, conforme especificado pela ICANN. Mediante solicitação da ICANN, o Operador de registro deve fornecer uma lista de todos os nomes retidos ou alocados ao Operador de registro em conformidade com a Seção 2.6 do Contrato. O Operador de registro poderá atribuir por 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.

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, devem 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 aplicação que necessite representar o nome União Europeia

<xxxx://xxx.xxx.xxx/xxx/xxxxxxx/xxxxxxx_xxxxx/xxx_0000_xxxx_xxxxx/xxx-0 166-1_decoding_table.htm>;

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) aplicável. O Operador de registro não deve ativar tais nomes no DNS, desde que o Operador de registro possa propor a liberação destas reservas, sujeitas à revisão pelo Comitê Consultivo Governamental da ICANN e aprovadas pela ICANN. Após a conclusão da designação do Operador de registro como Operador de registro para o TLD, todos estes 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 por 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 Meia-Lua Vermelha. Conforme as instruções que a ICANN fornece periodicamente, os nomes (inclusive suas variações de IDN, quando aplicável) relacionados ao Comitê Olímpico Internacional, Movimento Internacional da Cruz Vermelha e

Meia-Lua Vermelha relacionados em xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/xxxxxxxx devem ser retidos no registro ou 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 Meia-lua Vermelha (inclusive suas variações de IDN) podem ser incluídos na lista, dez (10) dias consecutivos após a notificação da ICANN ao Operador de registro. Esses nomes não podem ser ativado no DNS e não podem ser disponibilizados 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, todos esses nomes retidos no registro ou alocados para o Operador de registro deverão ser transferidos, conforme especificado pela ICANN. O Operador de registro poderá atribuir por 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.

6. Organizações intergovernamentais. Conforme as instruções que a ICANN fornece 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 relação de nomes reservados para esta Seção 6 está disponível em xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/xxxxxxxx. Nomes adicionais (incluindo suas variações de IDN) podem ser incluídos na lista, dez (10) dias consecutivos após o aviso da ICANN ao Operador de registro. Nenhum destes identificadores protegidos por Organizações intergovernamentais pode ser ativado no DNS nem 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, todos estes identificadores protegidos deverão ser transferidos, conforme especificado pela ICANN. O Operador de registro poderá atribuir por 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.

ESPECIFICAÇÃO 6

ESPECIFICAÇÕES DE INTEROPERABILIDADE E CONTINUIDADE DO REGISTRO

1. Conformidade com as normas

1.1. DNS. O Operador de registro deve cumprir os RFCs relevantes já existentes e os que serão publicados futuramente pela Força-tarefa para Engenharia da Internet (IETF), inclusive todas as normas, modificações ou aditamentos posteriores relativos ao DNS e operações do servidor de nomes, incluindo, entre outros, os RFCs 1034, 1035, 1123, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 4343 e 5966. As etiquetas de DNS contêm somente hífens 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 deve cumprir os RFCs relevantes já existentes e os que serão publicados futuramente pela Força-tarefa para Engenharia da Internet (IETF), inclusive todos os padrões, 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 os 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á ao RFC 3915 e posteriores. Se o Operador de registro exigir o uso da funcionalidade fora dos RFCs do EPP de base, o Operador de registro deve documentar as extensões de EPP no formato Preliminar da Internet, seguindo as orientações descritas no 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 da zona TLD da implementação das Extensões de Segurança do Sistema de Nomes de Domínio ("DNSSEC"). Durante o Prazo, o Operador de registro deve cumprir os RFCs 4033, 4034, 4035, 4509 e posteriores e seguir as práticas recomendadas descritas no RFC 4641 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 deve atender ao RFC 5155 e posteriores. O Operador de registro deverá aceitar o material de chave pública dos nomes de domínio secundário de modo seguro, de acordo com as práticas recomendadas do setor. O Registro também deverá publicar em seu site, a Declaração sobre as práticas de DNSSEC (DPS), que descreve 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 deve publicar sua DPS seguindo o formato descrito no RFC 6841.

1.4. IDN. Se o Operador de registro oferecer Nomes de domínio internacionalizados ("IDNs"), ele deve cumprir com os RFCs 5890, 5891, 5892, 5893 e posteriores. O Operador de registro deve cumprir as Diretrizes de IDN da ICANN em

<xxxx://xxx.xxxxx.xxx/xx/xxxxxx/xxx/xxxxxxxxxxxxxx-xxxxxxxxxx.xxx>, sendo que eles podem ser alterados, modificados ou substituídos ao longo do tempo. O Operador de registro deve publicar e manter atualizadas suas tabelas de IDN e Normas de registro de IDN no Repositório IANA de práticas de IDN, conforme especificado nas Diretrizes de IDN da ICANN.

1.5. IPv6. O Operador de registro deve ser capaz de aceitar endereços IPv6 como registros agregados em seu Sistema de registro e publicá-los no DNS. O Operador de registro deve oferecer transporte de IPv6 público para, pelo menos, dois dos servidores de nomes do registro relacionados na zona raiz com os endereços IPv6 correspondentes registrados pelo IANA. O Operador de registro deve seguir as “Diretrizes operacionais de transporte de IPv6 do DNS”, conforme descrito no BCP 91 e as recomendações e considerações descritas no RFC 4472. O Operador de registro deve oferecer transporte de IPv6 público para seus Serviços de publicação de dados de registro, conforme definido na Especificação 4 do presente Contrato; por exemplo, Whois (RFC 3912), Whois baseado na Web. O Operador de registro deve oferecer transporte de IPv6 público para 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 pelo gTLD disposto a operar com o SRS no IPv6.

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; fornecimento, aos registradores, das informações de status referentes aos servidores de zona para o TLD; divulgação dos arquivos da zona de TLD; operação dos servidores de DNS do registro e 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 de consenso, 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 materiais para 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 que o registrante não tenha fornecido registros válidos, como

registros NS para a inclusão no arquivo da zona de DNS, ou cujo estatuto não permita que sejam publicados no DNS, é proibido o uso dos Registros de recursos de caracteres-curinga do DNS, como descrito nos 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 estes nomes de domínio, os servidores de nomes autorizados devem retornar uma resposta “Erro de nome" (também conhecida como NXDOMAIN), RCODE 3, conforme descrito no RFC 1035 e RFCs relacionados. Esta disposição se aplica a todos os arquivos da zona de DNS em todos os níveis na árvore do DNS, para que o Operador de registro (ou um afiliado envolvido no fornecimento de Serviços de registro) mantenha os dados, organize tal manutenção ou obtenha a receita a partir de tal manutenção.

3. Registro de continuidade

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 carga, quando aplicável) para garantir o funcionamento contínuo em caso de falha técnica (generalizada ou local), ou de um acontecimento extraordinário 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 acontecimentos extraordinários.

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 caso, dependendo do tipo de função crítica envolvida. Interrupções causadas por um evento como este 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 apresentará para 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 deste 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. Reparação de abuso

4.1. Contato de abuso. O Operador de registro deve fornecer à ICANN e publicar em seu site os detalhes de contato precisos, contendo um e-mail válido e endereço para correspondência, bem como um contato principal para tratar das consultas relacionadas à conduta maliciosa no TLD, e fornecerá um aviso à ICANN imediatamente sobre qualquer alteração desses detalhes de contato.

4.2. Uso malicioso dos registros órfãos agregados. O Operador de registro deverá tomar medidas para remover os registros órfãos agregados (como definido em xxxx://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 dos nomes registrados podem 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 pode ultrapassar 10 (dez) anos.

5.2. Períodos de renovação. A renovação dos nomes registrados pode 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 pode estender seu período de registro por mais de dez (10) anos a partir da data da renovação.

6. Gestão de ocorrência de colisões de nomes

6.1. Período de não ativação. O Operador de registro não deve ativar nenhum nome da zona de DNS para o TLD de Registro (exceto para "NIC") até pelo menos 120 dias consecutivos a partir da data de vigência deste contrato. Operador de registro poderá atribuir nomes (sujeito à subseção 6.2) durante este período, apenas se o Operador de registro fizer com que os registrantes sejam claramente informados da 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 deve ativar nenhum nome na zona de DNS para o 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 reparaçã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 reparação, como 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 estejam 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 aplicação das medidas estabelecidas na Seção 6.2.1, somente se (A) a ICANN determinar que o TLD de Registro está qualificado para este caminho alternativo para a 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

<xxxx://xxxxxxxx.xxxxx.xxx/xx/xxxxxxxxxxxxx-xxx-xxxxx/xxxxxxx ement-2-17nov13-en>, sendo que esta lista pode ser modificada pela ICANN esporadicamente.. O Operador de registro poderá ativar nomes nos termos da presente subseção e depois ativar os nomes nos termos da subseção 6.2.1.

6.2.3 Os conjuntos de nomes sujeitos a atenuaçã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 de DNS da ICANN, inclusive os dados do “Dia na Vida da Internet" mantidos pelas Operações de DNS, análise e Centro de pesquisas (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 estes nomes bloqueados poderão ser disponibilizados.

6.2.5 Se a ICANN determinar que o TLD não está qualificado para o caminho alternativo para a ativação de nomes, a ICANN pode optar por não delegar o TLD mediante 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 atenuação necessárias pelo Operador de registro. O Operador de registro entende que as medidas de atenuação exigidas pela ICANN como uma condição para a ativação de nomes na zona de DNS para o TLD podem incluir, sem limitação, medidas de atenuação, tais como as descritas na Seção 3.2 do Novo plano de gestão de ocorrência de colisões de nomes de gTLDs, aprovado pelo Comitê do novo programa de gTLD (NGPC) da Diretoria da ICANN em 7 de outubro de 2013, conforme encontrado em

<xxxx://xxx.xxxxx.xxx/xx/xxxxxx/xxxxx/xxxxxxxxx/xxxxxxxxxxx-xxx-xxx d-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 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 sob os quais o Operador de registro poderá, na medida em que for necessário e adequado, remover um nome recentemente ativado a partir 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 deve implementar e respeitar os mecanismos de proteção de direitos ("RPMs") especificados nesta Especificação. Além destes RPMs, o Operador de registro pode desenvolver e implementar RPMs adicionais 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 RPMs adicionais desenvolvidos e implementados pelo Operador de registro no contrato entre registro e registrador, 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 estabelecidos no Centro de informação e proteção de marcas comerciais a partir da data deste documento, conforme publicado em xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/xxxx-xxxxxxxxxxxx (os "Requisitos do centro de informação e proteção de marcas comerciais"), que podem ser revistos em aspectos imateriais pela ICANN esporadicamente.O Operador de registro não deve exigir que nenhum proprietário dos direitos de propriedade intelectual aplicáveis use nenhuma outra agregação de informação de marca registrada, notificação ou serviço de validação, além do Centro de informação e proteção de

marcas comerciais designado pela ICANN ou no lugar xxxxx.Xx caso de conflito entre os termos e condições deste Contrato e os Requisitos do Centro de informação e proteção de marcas comerciais, os termos e condições do presente Contrato devem prevalecer.

2. Mecanismos de resolução de disputas. O Operador de registro cumprirá os seguintes mecanismos de solução de disputas, pois podem 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 xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/xxxxx e em xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/xxxxx, respectivamente). O Operador de registro concorda em implementar e respeitar qualquer solução imposta pela ICANN (que pode 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 xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/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 deve (a) fornecer os recursos financeiros suficientes para garantir a continuidade da operação das funções críticas de registro relacionadas com o 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 de cinco anos da data 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 vigência, mas antes ou em seis anos da data de vigência, 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 Guia do solicitante de gTLD, como publicado e complementado pela ICANN antes da data determinada (incorporada para referência a esta Especificação 8). O Operador de registro deverá usar 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 vigência e para 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 um 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 a ICANN sobre seu vencimento final ou até que a ICANN libere a carta de crédito, como 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 Guia do solicitante de gTLD, 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 de seis anos da Data de vigência, esta carta de crédito deve 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 deve exigir que o banco emissor conceda à ICANN um aviso com pelo menos 30 (trinta) dias consecutivos 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 vigência, o Operador de registro será obrigado a obter uma substituição do Instrumento de operações contínuas. A ICANN pode 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 deve concordar com nenhuma alteração ou isenção nem autorizá-las, nos termos do Instrumento de operações contínuas ou 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 satisfazer à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 de seis anos da Data de vigência, o Operador de registro deverá imediatamente (i) notificar a ICANN sobre tal vencimento ou rescisão e os motivos para o mesmo 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 com o TLD estabelecidas na Seção 6 da Especificação 10 do presente Contrato por um período de 3 (três) anos partir da rescisão do presente Contrato ou antes de cinco anos da Data 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

vigência, mas antes ou no sexto ano da Data de vigência (um “Instrumento alternativo”). Qualquer Instrumento alternativo deve estar nos termos não menos favoráveis à ICANN do que o Instrumento de operações contínuas e, além disso, estar 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 relacionados com o 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 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 vigência, mas antes ou em seis anos da Data 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 do 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 as oportunidades comparáveis para se qualificar para tais preferências ou considerações sejam disponibilizados a todos os registradores 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 de 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 estes 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 esta Parte relacionada ao registro garanta que esses serviços sejam oferecidos por meio de uma entidade jurídica separada do Operador de registro e mantenham 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 realizará revisões internas pelo menos uma vez por ano civil para assegurar a conformidade com este Código de conduta. Dentro de 20 (vinte) dias consecutivos após o final de cada ano civil, 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 pode especificar no futuro a forma e o conteúdo destes relatórios ou que os relatórios sejam entregues por outros meios razoáveis.) O Operador de registro concorda que a ICANN pode publicar publicamente estes resultados e certificação, desde que, no entanto, a ICANN não divulgue informações confidenciais contidas neste resultados, exceto em conformidade com a Seção 7.15 do Contrato.

4. Nada do que consta no presente documento deve: (I) limitar a ICANN de realizar investigações de declarações de não conformidade do Operador de registro com este Código de conduta, ou (ii) fornecer os motivos para o Operador de registro se recusar a cooperar com as investigações de declarações da ICANN de não conformidade do Operador de registro com este Código de conduta.

5. Nada do que consta no presente documento deve limitar a capacidade do Operador de registro ou 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 pode ser concedida pela ICANN em critério razoável da ICANN, se o Operador de registro demonstrar à satisfação razoável da 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 vender, distribuir nem transferir 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.

1. Definições

ESPECIFICAÇÃO 10 ESPECIFICAÇÕES DE REGISTRO DE DESEMPENHO

1.1. DNS. Refere-se ao sistema de nomes de domínio, conforme especificado nos RFCs 1034, 1035 e RFCs relacionados.

1.2. Resolução adequada do DNSSEC. Há uma cadeia de confiança de DNSSEC válida a partir da â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 no RFC 5730 e RFCs relacionados.

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, IPv4 ou IPv6 será usado.

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

1.6. RDDS. Os Serviços de Diretório de Dados de Registro (RDDS) referem-se ao conjunto de WHOIS e serviços de WHOIS baseados na Web, tal como definido na Especificação 4 deste Contrato.

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) é o nível de serviço esperado para um certo parâmetro sendo medido em um Contrato de Nível de Serviço (SLA).

2. Matriz do contrato de nível de serviço

	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, para pelo menos 95% das consultas

	RTT de resolução de DNS UDP	 500 ms, para pelo menos 95% das consultas
	Tempo de atualização do DNS	 60 min., para pelo menos 95% das sondas
RDDS	Disponibilidade de RDDS	 tempo de inatividade de 864 min. ( 98%)
	RTT de consulta de RDDS	 2000 ms, para pelo menos 95% das consultas
	Tempo de atualização de RDDS	 60 min., para 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, para pelo menos 90% dos comandos
	RTT do comando de consulta de EPP	 2000 ms, para pelo menos 90% dos comandos
	RTT do comando de transformação de EPP	 4000 ms, para pelo menos 90% dos comandos

O Operador de registro é incentivado a fazer a manutenção de diferentes serviços em horas e datas que estatisticamente apresentam 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 devida a falhas do sistema, será observado apenas como tempo de inatividade e contabilizado para fins de SLA.

3. DNS

3.1. Disponibilidade do serviço de DNS. Refere-se à capacidade do grupo de servidores de nome relacionado como autorizado de determinado nome de domínio (por exemplo, um TLD), para responder a consultas de DNS a partir de sondas de DNS. Para o serviço ser considerado disponível em determinado momento, pelo menos dois dos servidores de nomes delegados registrados no DNS devem apresentar resultados bem-sucedidos de “testes de DNS” para cada um de seus “endereços IP” registrados no DNS público para os quais o servidor de nomes encontra uma solução. Se 51% ou mais sondas de teste de DNS observarem o serviço como indisponível durante determinado momento, o serviço de DNS será considerado como indisponível.

3.2. Disponibilidade do servidor de nomes do DNS. Refere-se à capacidade de um “endereço IP” registrado no DNS público de um servidor de nome específico relacionado como autorizado para um nome de domínio, em responder a consultas de DNS de um usuário da Internet. Todo “endereço IP” registrado no DNS público de todos os servidores de nome do nome de domínio que está sendo monitorado deve ser testado individualmente. Se 51% ou mais das sondas de teste de DNS obtiverem resultados sem resposta ou indefinidos dos “testes de DNS” para um “endereço IP” do servidor de nome durante determinado momento, o “endereço IP” do servidor de nome será considerado indisponível.

3.3. RTT de resolução de DNS UDP. Refere-se ao RTT da sequência de dois pacotes, a consulta de DNS UDP e a resposta de DNS UDP correspondente. Se o RTT é 5 vezes maior do que o tempo especificado no SLR relevante, o RTT será considerado indefinido.

3.4. RTT de resolução de DNS TCP. Refere-se ao RTT da sequência de pacotes desde o início da conexão de TCP até sua conclusão, inclusive a recepção da resposta de DNS para somente uma consulta de DNS. Se o RTT é 5 vezes maior do que o tempo especificado no SLR relevante, o RTT será considerado indefinido.

3.5. RTT de resolução de DNS. Refere-se a um “RTT de resolução de DNS UDP” ou “RTT de resolução de DNS TCP”.

3.6. Tempo de atualização do DNS. Refere-se ao tempo medido a partir da recepção de uma confirmação de EPP para um comando de transformação em um nome de domínio, até que os servidores de nome do nome de domínio principal respondam “consultas de DNS”, com dados consistentes com a alteração feita. Isso só se aplica a alterações nas informações do DNS.

3.7. Teste de DNS. Significa uma consulta de DNS não recursiva, enviada a determinado “endereço IP” (via UDP ou TCP). Se o DNSSEC é oferecido na zona de DNS consultada, para que uma consulta seja considerada como respondida, as assinaturas devem ser verificadas de modo positivo com um registro de DS correspondente, publicado na zona principal, ou, se a principal não estiver assinada, com uma Âncora de confiança configurado estaticamente. A resposta à consulta deve conter as informações correspondentes do Sistema de registro, caso contrário, a consulta será considerada sem resposta. Uma consulta com um “RTT de resolução de DNS” 5 vezes maior do que o SLR correspondente, será considerada sem resposta. Os resultados possíveis para um teste de DNS são: um número em milissegundos correspondendo à “RTT de Resolução de DNS” ou indefinido/sem resposta.

3.8. Medição dos parâmetros de DNS. A cada minuto, cada sonda de DNS fará um “teste de DNS” de UDP ou TCP para cada um dos “endereços IP” registrados no DNS público dos servidores de nomes do nome do domínio que está sendo monitorado. Se um resultado de “teste de DNS” for indefinido/sem resposta, o IP testado será considerado indisponível a partir desta sonda, até o momento de fazer um novo teste.

3.9. Comparação dos resultados das sondas de DNS. O número mínimo de sondas de teste ativas para considerar uma medição válida é 20 com qualquer período determinado de medição, caso contrário as medições serão descartadas e consideradas inconclusivas; nessa situação, nenhuma falha será sinalizada contra os SLRs.

3.10. Distribuição de consultas de UDP e TCP. As sondas de DNS enviarão o “teste de DNS” de UDP ou TCP aproximando a distribuição destas consultas.

3.11. Posicionamento das sondas de DNS. As sondas para medição dos parâmetros de DNS devem ser posicionadas o mais próximo possível dos resolvedores de DNS nas redes com a maioria dos usuários entre as diferentes regiões geográficas; deve ser tomado o devido cuidado para que as sondas não sejam implementadas por trás de links com atraso de propagação, como os links de satélites.

4. RDDS

4.1. Disponibilidade de RDDS. Refere-se à capacidade de todos os serviços de RDDS para o TLD, de responderem às consultas de um usuário da Internet com os dados apropriados do sistema de registro relevante. Se 51% ou mais sondas de teste de RDDS observarem algum dos serviços de RDDS indisponível durante determinado momento, o RDDS será considerado como indisponível.

4.2. RTT de consulta de WHOIS. Refere-se ao RTT da sequência de pacotes desde o início da conexão de TCP até sua conclusão, inclusive a recepção da resposta de WHOIS. Se o RTT for equivalente a 5 vezes ou mais ao SLR correspondente, o RTT será considerado como indefinido.

4.3. RTT de consulta de WHOIS com base na Web. Refere-se ao RTT da sequência de pacotes desde o início da conexão de TCP até sua conclusão, incluindo a recepção da resposta de HTTP para somente uma solicitação de HTTP. Se o Operador de registro implementar um processo de múltiplas etapas para obter a informação, apenas a última etapa será medida. Se o RTT for equivalente a 5 vezes ou mais ao SLR correspondente, o RTT será considerado como indefinido.

4.4. RTT de consulta de RDDS. Refere-se ao conjunto de “RTT de consulta de WHOIS” e “RTT de consulta de WHOIS com base na Web”.

4.5. Tempo de atualização de RDDS. Refere-se ao tempo medido desde o recebimento de uma confirmação de EPP para um comando de transformação em um nome de domínio, host ou contato, até os servidores dos serviços de RDDS refletirem as alterações realizadas.

4.6. Teste de RDDS. Significa uma consulta enviada a determinado “endereço IP” de um dos servidores de um dos serviços de RDDS. As consultas serão sobre objetos existentes no Sistema de registro e as respostas deverão conter as informações correspondentes, caso contrário a consulta será considerada como sem resposta. Consultas com um RTT 5 vezes superior ao SLR correspondente serão consideradas como sem respostas. Os resultados

possíveis para um teste de RDDS são: um número em milissegundos correspondendo ao RTT ou indefinido/sem resposta.

4.7. Medição dos parâmetros de RDDS. A cada 5 minutos, as sondas de RDDS selecionarão um endereço IP de todos os “endereços IP” registrados no DNS público dos servidores de cada serviço de RDDS do TLD que está sendo monitorados e fará um “teste de RDDS” em cada um. Se um resultado de “teste de RDDS” for indefinido/sem resposta, o serviço de RDDS correspondente será considerado com indisponível por essa sonda até o momento de um novo teste.

4.8. Comparação de resultados das sondas de RDDS. O número mínimo de sondas de teste ativas para considerar uma medição válida é 10 com qualquer período determinado de medição, caso contrário as medições serão descartadas e consideradas inconclusivas; nessa situação, nenhuma falha será sinalizada contra os SLRs.

4.9. Posicionamento das sondas de RDDS. As sondas para medição dos parâmetros de RDDS serão posicionadas dentro das redes com a maioria de usuários entre as diferentes regiões geográficas; será tomado o devido cuidado para que as sondas não sejam implementadas por trás de links com atraso de propagação, como os links de satélites.

5. EPP

5.1. Disponibilidade do serviço de EPP. Refere-se à capacidade dos servidores EPP de TLD como um grupo, de responder aos comandos dos Registradores credenciados no Registro, que já têm credenciais para os servidores. A resposta deve conter os dados apropriados do Sistema de registro. Um

comando EPP com o “RTT de comando do EPP” 5 vezes superior ao SLR correspondente será considerado como sem resposta. Se 51% ou mais sondas de teste de EPP observarem o serviço de EPP como indisponível durante determinado momento, o serviço de EPP será considerado como indisponível.

5.2. RTT de comando da sessão de EPP. Refere-se ao RTT da sequência de pacotes que inclui o envio de um comando da sessão mais a recepção da resposta de EPP apenas para um comando da sessão de EPP. Para o comando de login, incluirá os pacotes necessários para iniciar a sessão de TCP. Para o comando de logout, incluirá os pacotes necessários para encerrar a sessão de TCP. Os comandos da sessão de EPP são aqueles descritos na seção 2.9.1 do EPP RFC 5730. Se o RTT for equivalente a 5 vezes ou mais ao SLR correspondente, o RTT será considerado como indefinido.

5.3. RTT do comando de consulta de EPP. Refere-se ao RTT da sequência de pacotes que inclui o envio de um comando da consulta mais a recepção da resposta de EPP apenas para um comando da consulta de EPP. Não inclui os

pacotes necessários para o início ou término da sessão de EPP ou TCP. Os comandos da consulta de EPP são aqueles descritos na seção 2.9.2 do EPP RFC 5730. Se o RTT for equivalente a 5 vezes ou mais ao SLR correspondente, o RTT será considerado como indefinido.

5.4. RTT do comando de transformação de EPP. Refere-se ao RTT da sequência de pacotes que inclui o envio de um comando de transformação mais a recepção da resposta de EPP apenas para um comando de transformação de EPP. Não inclui os pacotes necessários para o início ou término da sessão de EPP ou TCP. Os comandos de transformação de EPP são aqueles descritos na seção 2.9.3 do EPP RFC 5730. Se o RTT for equivalente a 5 vezes ou mais ao SLR correspondente, o RTT será considerado como indefinido.

5.5. RTT de comando de EPP. Refere-se ao “RTT de comando da sessão de EPP”, “RTT do comando de consulta de EPP” ou “RTT do comando de transformação de EPP”.

5.6. Teste de EPP. Significa um comando de EPP enviado a determinado “endereço IP” para um dos servidores EPP. Os comandos de consulta e transformação, com exceção de "criar", referem-se a objetos existentes no sistema de registro. A resposta deve conter os dados apropriados do Sistema de registro. Os resultados possíveis para um teste de EPP são: um número em milissegundos correspondendo ao “RTT de comando de EPP” ou indefinido/sem resposta.

5.7. Medição dos parâmetros de EPP. A cada 5 minutos, as sondas de EPP selecionarão um “endereço IP” dos servidores EPP do TLD que estão sendo monitorados e realizarão um “teste de EPP”; elas sempre devem alternar entre os 3 tipos diferentes de comandos e entre os comandos dentro de cada categoria. Se um resultado de “teste de EPP” for indefinido/sem resposta, o serviço de EPP será considerado com indisponível por essa sonda até o momento de um novo teste.

5.8. Comparação dos resultados das sondas de EPP. O número mínimo de sondas de teste ativas para considerar uma medição válida é 5 com qualquer período determinado de medição, caso contrário as medições serão descartadas e consideradas inconclusivas; nessa situação, nenhuma falha será sinalizada contra os SLRs.

5.9. Posicionamento das sondas de EPP. As sondas para medição dos parâmetros de EPP serão posicionadas dentro ou próximo aos pontos de acesso dos registradores com a Internet; deve ser tomado o devido cuidado para que as sondas não sejam implementadas por trás de links com atraso de propagação, como os links de satélites.

6. Limites de emergência

A matriz a seguir apresenta os limites de emergência que, se alcançados por qualquer um dos serviços acima mencionados para um TLD, causariam a transição de emergência do registro para o TLD, conforme especificado na Seção 2.13 deste Contrato.

Função crítica	Limites de emergência
Serviço de DNS (todos os servidores)	tempo de inatividade total de 4 horas/semana
Resolução adequada do DNSSEC	tempo de inatividade total de 4 horas/semana
EPP	tempo de inatividade total de 24 horas / semana
RDDS (WHOIS/WHOIS com base na Web)	tempo de inatividade total de 24 horas / semana
Depósito de dados	Violação do Contrato de registro conforme descrito na Especificação 2, Parte B, Seção 6.

7. Escalonamento de emergência

O escalonamento é estritamente para fins de notificação e investigação de possíveis ou potenciais problemas em relação aos serviços monitorados. O início de um escalonamento e as investigações cooperativas posteriores não implicam que um serviço monitorado falhou em seus requisitos de desempenho.

Os escalonamentos devem ser realizados entre a ICANN e os operadores de registro, registradores e Operador de registro, e registradores e a ICANN. Os operadores de registro e a ICANN devem fornecer os mencionados departamentos de operações de emergência.

Os contatos atuais devem ser mantidos entre a ICANN e os operadores de registro e publicados aos registradores, quando relevantes à sua função nos escalonamentos, antes de qualquer processamento de um escalonamento de emergência por todas as partes relacionadas, e mantidos atualizados em todos os momentos.

7.1. Escalonamento de emergência iniciado pela ICANN

Ao atingir 10% dos limites de emergência, conforme descrito na Seção 6 desta Especificação, as operações de emergência da ICANN iniciarão um escalonamento de emergência com o respectivo Operador de registro. Um escalonamento de emergência é composto pelos seguintes elementos mínimos: eletrônico (ou seja, e-mail ou SMS) e/ou notificação por contato de voz para o departamento de operações de emergência do Operador de registro com informações detalhadas sobre o assunto que está sendo escalonado, incluindo a evidência de falhas de monitoramento, resolução de problemas cooperativo da falta de monitoramento entre a equipe da ICANN e o Operador de registro, além do compromisso de iniciar o processo de resolução de problemas com o serviço de monitoramento ou com o serviço que está sendo monitorado.

7.2. Escalonamento de emergência iniciado pelos registradores

O Operador de registro manterá um departamento de operações de emergência preparado para lidar com solicitações de emergência dos registradores. Se um registrador não for capaz de realizar transações EPP com o registro para o TLD devido a uma falha no serviço de registro e não for capaz de entrar em contato (pelos métodos de comunicação exigidos pela ICANN) com o Operador de registro, ou o Operador de registro não for capaz ou não desejar resolver o problema, o registrador poderá iniciar um escalonamento de emergência para o departamento de operações de emergência da ICANN. A ICANN pode, a partir daí, iniciar um escalonamento de emergência com o Operador de registro, conforme explicado acima.

7.3. Notificações de interrupções e manutenção

No caso de um Operador de registro planejar a manutenção, ele fornecerá um aviso ao departamento de operações de emergência da ICANN, pelo menos vinte e quatro (24) horas antes da manutenção. O departamento de operações de emergência da ICANN determinará horários de manutenção planejada e suspenderá os serviços de escalonamento de emergência para os serviços monitorados durante o período de interrupção de manutenção esperado.

Se o Operador de registro declarar uma interrupção, conforme suas obrigações contratuais com a ICANN, em serviços sob um acordo de nível de serviço e requisitos de desempenho, ele notificará o departamento de operações de emergência da ICANN. Durante essa interrupção declarada, o departamento de operações de emergência da ICANN observará e suspenderá os serviços de escalonamento de emergência para os serviços monitorados envolvidos.

8. Contratos de medição de desempenho

8.1. Sem interferência. O Operador de registro não interferirá com as Sondas de medição, incluindo qualquer forma de tratamento preferencial das solicitações para os serviços monitorados. O Operador de registro responderá aos testes de medição descritos nesta Especificação como faria para qualquer outra solicitação feita por um usuário da Internet (para DNS e RDDS) ou registrador (para EPP).

8.2. Registrador de teste da ICANN. O Operador de registro concorda que a ICANN terá um registrador de teste utilizado para fins de medição dos SLRs descritos acima. O Operador de registro concorda em não fornecer nenhum tipo de tratamento diferenciado ao registrador de teste a não ser a não cobrança das transações. A ICANN não deverá usar o registrador para registrar nomes de domínio (ou outros objetos de registro) para si ou para outros, exceto para fins de verificação da conformidade contratual com as condições descritas no presente Contrato.

ESPECIFICAÇÃO 11

COMPROMISSOS DE INTERESSE PÚBLICO

1. O Operador de registro usará apenas registradores credenciados pela ICANN que façam parte do Contrato de credenciamento de Registradores, aprovado pela Diretoria da ICANN em 27 de junho de 2013, ao registrar nomes de domínio. A lista desses registradores deverá ser mantida pela ICANN no site da ICANN.

2. O Operador de registro operará o registro para o TLD em conformidade com todos os compromissos, declarações de intenção e planos de negócios apresentados nas seguintes seções da aplicação do Operador de registro à ICANN para o TLD, cujos compromissos, declarações de intenção e planos de negócios estão incorporados por referência no presente Contrato. As obrigações do Operador de registro em conformidade com o presente parágrafo devem ser cumpridas pela ICANN e por meio do Processo de resolução de disputas do compromisso de interesse público estabelecido pela ICANN (publicado em xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/xxxxxx), que poderá ser revisto em aspectos secundários pela ICANN esporadicamente (o "PICDRP").O Operador de registro deve cumprir o PICDRP.O Operador de registro concorda em implementar e respeitar qualquer solução imposta pela ICANN (que pode incluir 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 por qualquer painel de PICDRP e em se comprometer com tal determinação

[O Operador de registro deve inserir aqui seções específicas de aplicação, conforme o caso]

3. O Operador de registro concorda em executar os seguintes compromissos específicos de interesse público, os quais devem ser cumpridos pela ICANN e pelo PICDRP. O Operador de registro deve cumprir o PICDRP. O Operador de registro concorda em implementar e respeitar qualquer solução imposta pela ICANN (que pode incluir 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 por qualquer painel de PICDRP e em se comprometer com tal determinação.

a. O Operador de registro incluirá uma cláusula em seu contrato entre registro e registrador que exige que os registradores incluam em seus contratos de registro uma cláusula que proíba os titulares de nome registrado de distribuir malware, botnets que operam de forma abusiva, phishing, pirataria, violação de marca registrada ou de direitos autorais, práticas fraudulentas ou enganosas, falsificação ou, de outra forma, se envolver em atividade contrária à legislação pertinente e gerar (de acordo com a legislação pertinente e qualquer procedimento relacionado) consequências para tais atividades, inclusive a suspensão do nome de domínio.

b. O Operador de registro realizará periodicamente uma análise técnica para avaliar se os domínios no TLD estão sendo usados para cometer ameaças de segurança, como pharming, phishing, malware e botnets. O Operador de registro manterá relatórios estatísticos sobre o número de ameaças de segurança identificadas e as ações tomadas como resultado das verificações de segurança periódicas. O Operador de registro manterá esses relatórios pelo período do Contrato, a menos que um período mais curto seja exigido por lei ou aprovado pela ICANN, e os fornecerá à ICANN mediante solicitação.

c. O Operador de registro operará o TLD de modo transparente e conforme os princípios gerais de franqueza e não discriminação, através da criação, publicação e adesão a políticas de registro seguras.

d. O Operador de registro de um TLD com "Cadeia de caracteres genéricos" não pode impor critérios de qualificação para registrar nomes no TLD que limitem os registros exclusivamente a uma única pessoa ou entidade e/ou “afiliados" dessa pessoa ou entidade (conforme definido na Seção 2.9(c) do Contrato de registro). A “cadeia de caracteres genéricos" refere-se a uma cadeia de caracteres que consiste em uma palavra ou termo que denomina ou descreve uma classe geral de bens, serviços, grupos, organizações ou coisas, ao invés de distinguir uma marca específica de bens, serviços, grupos, organizações ou coisas de outros.

ESPECIFICAÇÃO 12

POLÍTICAS DE REGISTRO DA COMUNIDADE

O Operador de registro deverá implementar e cumprir todas as políticas de registro da comunidade descritas abaixo e/ou anexas a esta Especificação 12.

[Inserir políticas de registro]