CONTRATO DE REGISTRO

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

, e (“Operador de registro”).

ARTICLE 1.

AUTORIZAÇÃO E OPERAÇÃO

DE DOMÍNIO DE PRIMEIRO NÍVEL; DECLARAÇÕES E GARANTIAS

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

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

1.3 Declarações e garantias.

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

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

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

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

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

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

ARTICLE 2.

COMPROMISSOS DO OPERADOR DE REGISTRO

O Operador de registro assume e concorda com a ICANN que:

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

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

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

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

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

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

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

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

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

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

2.9 Registradores.

(a) Todos os registros de nomes de domínio no TLD deverão ser realizados por meio de um registrador credenciado 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 deve fornecer acesso não discriminatório aos Serviços de registro a todos os registradores credenciados da ICANN que firmarem e estiverem em conformidade com o Contrato entre registro e registrador do TLD; o Operador de registro pode 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 um aviso por escrito com pelo menos quinze (15) dias consecutivos de antecedência em caso de eventuais revisões do Contrato entre registro e registrador para que tais revisões se tornem efetivas e vinculativas para qualquer registrador. Durante esse período, a ICANN determinará se as revisões propostas são irrelevantes, possivelmente importantes ou importantes por natureza. Se a ICANN não fornecer ao Operador de registro o aviso de sua decisão no mencionado período de quinze (15) dias consecutivos, será considerado que a ICANN decidiu que tais revisões propostas são de natureza irrelevante. Se a ICANN decidir, ou for considerado que decidiu, nos termos desta 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. Não obstante as cláusulas precedentes desta Seção 2.9(a), qualquer alteração no Contrato entre registrador e registro que esteja exclusivamente relacionada à taxa cobrada pelo Operador de registro para registrar nomes de domínio no TLD não estará sujeita ao processo de aviso e aprovação especificado nesta Seção 2.9(a), mas sujeita aos requisitos estabelecidos na Seção 2.10 abaixo.

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

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

(c) Para os fins do presente Contrato: (i) “Afiliado” 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 ou se encontra sob controle comum com a pessoa ou entidade especificada, e (ii) “controle” (inclusive os termos “controlado por” e “sob controle comum com”) significa deter, direta ou indireta, o poder de dirigir ou fazer dirigir a administração ou as políticas de uma pessoa ou entidade, seja por meio de propriedade de títulos, como fiduciário ou executor, atuando como funcionário ou membro de uma diretoria ou órgão diretor equivalente, por contrato, por disposição de crédito ou de outra forma.

2.10 Definição de preços dos Serviços de registro.

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

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

reembolsos, abatimentos, descontos, vinculação de produto, programas de marketing qualificados ou outros programas que tenham tido o efeito de reduzir o preço cobrado dos registradores), com um prazo mínimo de 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 deve fornecer um aviso prévio com um prazo de apenas trinta

(30) dias consecutivos sobre qualquer aumento de preço se o preço resultante for menor ou igual a: (A) para o período iniciado na Data de vigência e com encerramento doze (12) meses após a Data de vigência, o preço inicial cobrado pelos registros no TLD, ou (B) para períodos subsequentes, um preço para o qual o Operador de registro tiver fornecido um aviso de acordo com a primeira frase desta Seção 2.10(b) dentro do período de doze (12) meses anteriores à data de entrada em vigor do aumento de preço proposto; e (ii) o Operador de registro não precisa fornecer aviso sobre aumentos de preço para a imposição da Taxa variável do nível do registro estabelecida na Seção 6.3. O Operador de registro deverá oferecer aos registradores a opção de obter renovações de registros de nomes de domínio ao preço atual (ou seja, o preço 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.

uniforme para renovações de registros de nomes de domínios (“Preço de renovação”).

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

nenhuma classe especial de registros. Nenhuma cláusula desta Seção 2.10(c) deve limitar as obrigações do Operador de registro nos termos da Seção 2.10(b).

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

2.11 Auditorias de conformidade contratual e operacional.

(a) A ICANN poderá ocasionalmente (no máximo duas vezes por ano civil) realizar ou contratar terceiros para realizar auditorias de conformidade contratual a fim de avaliar a conformidade do Operador de registro com suas declarações e garantias contidas no Artigo 1 deste Contrato e seus compromissos contidos no Artigo 2 deste Contrato. Essas auditorias devem ser adaptadas para atingir o objetivo de avaliar a conformidade e a ICANN (a) enviará um aviso com antecedência razoável sobre essa auditoria especificando em detalhes as categorias de documentos, dados e outras informações solicitadas pela ICANN, e (b) usará meios comerciais razoáveis para realizar essa auditoria de modo a não interromper desnecessariamente as operações do Operador de registro. Como parte dessa auditoria e por solicitação da ICANN, o Operador de registro deve 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. Com um aviso prévio de no mínimo dez

(10) dias (a menos que o Operador de registro concorde com outro prazo), a ICANN poderá, como parte de qualquer auditoria de conformidade contratual, fazer visitas ao local durante o horário comercial a fim de avaliar a conformidade do Operador de registro com suas declarações e garantias contidas no Artigo 1 deste Contrato e seus compromissos contidos no Artigo 2 deste Contrato. Quaisquer informações obtidas em conexão com essas auditorias e apropriadamente marcadas como confidenciais (conforme exigido pela Seção 7.15) serão tratadas pela ICANN como Informações confidenciais do Operador de registro, de acordo com a Seção 7.15.

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

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

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

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

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

2.12 Instrumento de operações contínuas. O Operador de registro deve estar em conformidade com os termos e condições relacionados ao Instrumento de operações contínuas e estabelecidos na Especificação 8 anexa a este documento (“Especificação 8”).

2.13 Transição de emergência. O Operador de registro concorda que, caso seja atingido algum dos limites de emergência para as funções de registro estabelecidos na Seção 6 da Especificação 10, a ICANN poderá designar um operador de registro interino de emergência do registro do TLD (um “Operador de emergência”) de acordo com o processo de transição de registro da ICANN (disponível em

<xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/xxxxxxxxxx-xxxxxxxxx>) (conforme possa ser alterado esporadicamente, o “Processo de transição de registro”), até o momento em que o Operador de registro demonstrar, de modo razoavelmente satisfatório para a ICANN, que pode retomar a operação do registro do TLD sem a nova ocorrência dessa falha. Após tal demonstração, o Operador de registro poderá retornar à operação do registro do TLD nos termos dos procedimentos estabelecidos no Processo de transição de registro, desde que o Operador de registro pague todos os custos razoáveis incorridos (i) pela ICANN como resultado da designação do Operador de emergência e (ii) pelo Operador de emergência em conexão com a operação do registro do TLD, cujos custos devem ser documentados de maneira razoavelmente detalhada nos registros que devem 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 deve proporcionar à ICANN ou a tal Operador de emergência todos os dados (inclusive os dados depositados de acordo com a Seção 2.3) com relação a operações do registro do TLD necessárias para manter operações e funções de registro que possam ser razoavelmente solicitadas pela ICANN ou por esse Operador de emergência. O Operador de registro concorda que a ICANN pode fazer qualquer alteração que considerar necessária no banco de dados da IANA de registros do DNS e do WHOIS com relação ao TLD, caso um Operador de emergência seja designado nos termos desta Seção 2.13. Além disso, em caso de tal falha, a ICANN deve reter e poderá exigir seus direitos de acordo com o Instrumento de operações contínuas.

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

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

(b) todos os dados na medida em que a entrega de tais dados possa infringir a legislação aplicável. Todos os dados entregues à ICANN ou seu representante nos termos desta Seção

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

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

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

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

2.19 [Observação: apenas para TLDs baseados na comunidade] Obrigações do Operador de registro para com a comunidade do TLD. O Operador de registro estabelecerá políticas de registro em conformidade com a solicitação apresentada em relação ao TLD para: (i) convenções de nomenclatura dentro do TLD, (ii) requisitos de registro para membros da comunidade do 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 deve operar o TLD de modo a permitir que a comunidade do TLD discuta e participe do desenvolvimento e da modificação de políticas e práticas do TLD. O Operador de registro deve estabelecer procedimentos para a aplicação de políticas de registro do TLD e resolução de disputas referentes à conformidade com as políticas de registro do TLD, e deverá impor tais políticas de registro. O Operador de registro concorda em implementar e submeter-se ao Procedimento de resolução de disputas de restrições de registro, conforme estabelecido em xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/xxxxx com relação a disputas decorrentes dos termos desta Seção 2.19. O Operador de registro deve implementar e cumprir as políticas de registro da comunidade estabelecidas na Especificação 12 anexa a este documento.]

ARTICLE 3.

COMPROMISSOS DA ICANN

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

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

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

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

3.4 Publicação de informações da zona raiz. A publicação de informações de contato da zona raiz do TLD por parte da ICANN conterá 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 esporadicamente pela ICANN em xxxx://xxx.xxxx.xxx/xxxxxxx/xxxx/.

3.5 Banco de dados raiz oficial. Na medida em que a ICANN for autorizada a definir a política em relação a um sistema de servidor raiz oficial (o “Sistema de servidor raiz oficial”), a ICANN envidará esforços comercialmente razoáveis para (a) garantir que a

raiz oficial aponte para os servidores de nomes de domínio de primeiro nível designados pelo Operador de registro do TLD, (b) manter um banco de dados publicamente disponível estável, seguro e oficial das informações relevantes sobre o TLD, de acordo com as políticas e procedimentos publicamente disponíveis da ICANN, e (c) coordenar o Sistema de servidor raiz oficial para que seja operado e mantido de modo estável e seguro; a ICANN não deve descumprir este Contrato e a ICANN não deve ter nenhuma responsabilidade caso terceiros (inclusive qualquer entidade governamental ou provedor de serviço de Internet) bloqueiem ou restrinjam o acesso ao TLD em algum foro.

ARTICLE 4.

PRAZO E RESCISÃO

4.1 Prazo. O prazo deste Contrato será de dez (10) anos a partir da Data de

vigência (conforme tal prazo possa ser ampliado de acordo com a Seção 4.2, o “Prazo”).

4.2 Renovação.

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

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

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

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

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

4.3 Rescisão por parte da ICANN.

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

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

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

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

(60) dias consecutivos após terem sido iniciados, (iii) um administrador, depositário, liquidante ou equivalente for indicado no lugar do Operador de registro ou mantiver controle sobre quaisquer propriedades do Operador de registro, (iv) a execução for

cobrada de qualquer propriedade material do Operador de registro que, se cobrada, possivelmente afetaria a capacidade do Operador de registro de operar o registro do TLD,;

(v) forem iniciadas decisões por parte do Operador de registro ou contra ele, por motivo de falência, insolvência, reorganização ou outras leis relacionadas à dispensa de devedores e tais decisões não forem extintas em até sessenta (60) dias consecutivos após terem sido iniciadas (se essas decisões forem iniciadas pelo Operador de registro ou seus afiliados) ou cento e oitenta (180) dias consecutivos a contar do início (se essas decisões forem iniciadas por um terceiro contra o Operador de registro); ou (vi) o Operador de registro registrar um pedido de proteção nos termos da Lei de falências dos Estados Unidos, U.S.C. 11 Seção 101 em diante ou uma proteção equivalente de outro país ou liquidar, dissolver ou de alguma forma encerrar as operações ou a operação do TLD.

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

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

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

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

4.4 Rescisão por parte do Operador de registro.

(a) O Operador de registro poderá rescindir este Contrato mediante aviso à ICANN se (i) a ICANN não reparar nenhuma infração fundamental e importante dos

compromissos da ICANN estabelecidos no Artigo 3 em um prazo de trinta (30) dias consecutivos após o Operador de registro avisar à ICANN sobre tal infração, sendo que tal aviso deverá especificar os detalhes da suposta infração, (ii) um árbitro ou tribunal de foro competente finalmente decidir que a ICANN incorreu em infração fundamental e importante de tais compromissos, e (iii) a ICANN não cumprir tal decisão e não reparar a infração em um prazo de dez (10) dias consecutivos ou outro período que possa ser determinado pelo árbitro ou tribunal de foro competente.

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

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

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

“Transição do registro após a rescisão do Contrato. Após a expiração do Prazo 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 conexão com a designação por parte da ICANN de um operador de registro sucessor do TLD, o Operador de registro e a ICANN concordam em consultar um ao outro e trabalhar cooperativamente para facilitar e implementar a transição do TLD em conformidade com esta Seção 4.5. Após consultar o Operador de registro, a ICANN decidirá se passará ou não a operação do TLD a um operador de registro sucessor, a seu próprio critério, e em conformidade com o Processo de transição de registro. Caso a ICANN decida passar a operação do TLD a um operador de registro sucessor, com o consentimento do Operador de registro (que não deve ser indevidamente recusado, limitado ou postergado), o Operador de registro fornecerá à ICANN ou a qualquer operador de registro sucessor do TLD todos os dados relacionados a operações do TLD e necessários para manter as operações e funções do registro que possam ser razoavelmente solicitados pela ICANN ou por esse operador de registro sucessor, além dos dados depositados de acordo com a Seção

2.3 deste documento. Caso o Operador de registro não consinta em fornecer tais dados, os dados de registro relacionados ao TLD deverão ser devolvidos ao Operador de registro, a menos que acordado de outra forma entre as partes. O Operador de registro concorda que a ICANN pode fazer qualquer alteração que considerar necessária no banco de dados da IANA de registros do DNS e do WHOIS com relação ao TLD em caso de transição do TLD de acordo com esta Seção 4.5. Além disso, a ICANN ou seu representante reterão e poderão fazer valer seus direitos nos termos do Instrumento de operações contínuas, independentemente do motivo de rescisão ou expiração deste Contrato.”]

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

ARTICLE 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 submeterá uma disputa a mediação mediante aviso por escrito à outra parte. A mediação será realizada por um único mediador selecionado pelas partes. Se as partes não chegarem a um acordo sobre o mediador em um prazo de quinze

(15) dias consecutivos após a entrega do aviso por escrito, de acordo com esta Seção 5.1, as partes selecionarão imediatamente uma entidade mediadora mutuamente aceitável, que, assim que possível e após a seleção dessa entidade, nomeará um mediador, que será um advogado licenciado com conhecimento geral sobre direito contratual e, na medida do necessário para mediar a disputa em particular, conhecimento geral do sistema de nomes de domínio. Qualquer mediador deverá confirmar por escrito que não é e não se tornará, durante o período da mediação, funcionário, sócio, diretor executivo, executivo ou detentor de valores mobiliários da ICANN nem do Operador de registro. Se essa confirmação não for fornecida pelo mediador nomeado, um mediador substituto será nomeado de acordo com esta Seção 5.1(a).

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

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

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

5.2 Arbitragem. As disputas que surgirem nos termos deste contrato ou em conexão com ele que não forem resolvidas de acordo com a Seção 5.1, inclusive as solicitações de desempenho específico, serão resolvidas por meio de arbitragem vinculativa, realizada conforme as regras da Corte Internacional de Arbitragem da Câmara de Comércio Internacional (a “ICC”). A arbitragem será realizada em inglês e ocorrerá no condado de Los Angeles, Califórnia, EUA. Qualquer arbitragem será perante um único árbitro, a menos (i) que a ICANN esteja buscando danos punitivos ou exemplares, ou sanções operacionais, (ii) que as partes concordem por escrito com um número maior de

árbitros, ou (iii) a disputa ocorra nos termos da Seção 7.6 ou 7.7. No caso das cláusulas (i),

(ii) ou (iii) do parágrafo anterior, a arbitragem será realizada por três árbitros, sendo que cada parte indicará um árbitro a ser confirmado pela ICC e os dois árbitros selecionados indicarão o terceiro árbitro a ser confirmado pela ICC. Para uma arbitragem realizada por um único árbitro, o Operador de registro e a ICANN poderão, por acordo mútuo, indicar o árbitro, a ser confirmado pela ICC. Se as partes não indicarem um único árbitro ou, no caso de arbitragem de três árbitros, se cada parte não indicar um árbitro, em cada caso dentro de trinta (30) dias consecutivos a contar da data em que a parte solicitou a arbitragem e a solicitação foi recebida pela outra parte, ou dentro de uma prorrogação de tempo que poderá ser permitida pela Secretaria da Corte da ICC, o(s) árbitro(s) deverá(ão) ser indicado(s) pela ICC. Se qualquer um dos árbitros indicados não for confirmado pela ICC, a parte ou as pessoas que indicaram esse árbitro deverão indicar imediatamente um árbitro substituto para ser confirmado pela ICC. A fim de agilizar a arbitragem e limitar os custos, o(s) árbitro(s) deverá(ão) estabelecer limites de páginas para a apresentação de documentos das partes em conjunto com a arbitragem e, se o(s) árbitro(s) determinar(em) que é necessária uma audiência, esta será limitada a um (1) dia consecutivo, desde que em qualquer arbitragem em que a ICANN esteja buscando danos punitivos ou exemplares, ou sanções operacionais, a audiência possa ser estendida para um (1) dia adicional consecutivo se acordado pelas partes ou ordenado pelo(s) árbitro(s) com base na determinação independente do(s) árbitro(s) ou na solicitação razoável de uma das partes deste instrumento. A parte favorecida na arbitragem terá o direito de recuperar os custos e taxas advocatícias razoáveis, que o(s) árbitro(s) incluirá(ão) no julgamento. 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á solicitar dos árbitros o julgamento de danos punitivos ou exemplares ou sanções operacionais (inclusive sem limitação uma ordem restringindo temporariamente os direitos do Operador de registro de vender novos registros). Cada uma das partes deverá tratar as informações recebidas da outra parte segundo a arbitragem que esteja marcada adequadamente como confidencial (conforme estabelecido na Seção 7.15) como Informação confidencial da outra parte em conformidade com a Seção 7.15. Para qualquer litígio que envolva a ICANN em relação a este Contrato, o local e o foro exclusivo para tal litígio serão um tribunal localizado no condado de Los Angeles, Califórnia, EUA; entretanto, as partes também terão o direito de fazer valer um parecer desse tribunal em qualquer tribunal de foro competente.

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

“Arbitragem. As disputas que surgirem nos termos deste contrato ou em conexão com ele que não forem resolvidas de acordo com a Seção 5.1, inclusive as solicitações de desempenho específico, serão resolvidas por meio de arbitragem vinculativa, realizada conforme as regras da Corte Internacional de Arbitragem da Câmara de Comércio Internacional (a “ICC”). A arbitragem será realizada em inglês e ocorrerá em Genebra, Suíça, exceto se outra localidade for mutuamente acordada entre o Operador de registro e a ICANN. Qualquer arbitragem será perante um único árbitro, a menos (i) que a ICANN esteja buscando danos punitivos ou exemplares, ou sanções operacionais, (ii) que as partes

concordem por escrito com um número maior de árbitros, ou (iii) a disputa ocorra nos termos da Seção 7.6 ou 7.7. No caso das cláusulas (i), (ii) ou (iii) do parágrafo anterior, a arbitragem será realizada por três árbitros, sendo que cada parte indicará um árbitro a ser confirmado pela ICC e os dois árbitros selecionados indicarão o terceiro árbitro a ser confirmado pela ICC. Para uma arbitragem realizada por um único árbitro, o Operador de registro e a ICANN poderão, por acordo mútuo, indicar o árbitro, a ser confirmado pela ICC. Se as partes não indicarem um único árbitro ou, no caso de arbitragem de três árbitros, se cada parte não indicar um árbitro, em cada caso dentro de trinta (30) dias consecutivos a contar da data em que a parte solicitou a arbitragem e a solicitação foi recebida pela outra parte, ou dentro de uma prorrogação de tempo que poderá ser permitida pela Secretaria da Corte da ICC, o(s) árbitro(s) deverá(ão) ser indicado(s) pela ICC. Se qualquer um dos árbitros indicados não for confirmado pela ICC, a parte ou as pessoas que indicaram esse árbitro deverão indicar imediatamente um árbitro substituto para ser confirmado pela ICC. A fim de agilizar a arbitragem e limitar os custos, o(s) árbitro(s) deverá(ão) estabelecer limites de páginas para a apresentação de documentos das partes em conjunto com a arbitragem e, se o(s) árbitro(s) determinar(em) que é necessária uma audiência, esta será limitada a um (1) dia consecutivo, desde que em qualquer arbitragem em que a ICANN esteja buscando danos punitivos ou exemplares, ou sanções operacionais, a audiência possa ser estendida para um (1) dia adicional consecutivo se acordado pelas partes ou ordenado pelo(s) árbitro(s) com base na determinação independente do(s) árbitro(s) ou na solicitação razoável de uma das partes deste instrumento. A parte favorecida na arbitragem terá o direito de recuperar os custos e taxas advocatícias razoáveis, que o(s) árbitro(s) incluirá(ão) no julgamento. 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á solicitar dos árbitros o julgamento de danos punitivos ou exemplares ou sanções operacionais (inclusive sem limitação uma ordem restringindo temporariamente os direitos do Operador de registro de vender novos registros). Cada uma das partes deverá tratar as informações recebidas da outra parte segundo a arbitragem que esteja marcada adequadamente como confidencial (conforme estabelecido na Seção 7.15) como Informação confidencial da outra parte em conformidade com a Seção 7.15. Para qualquer litígio que envolva a ICANN em relação a este Contrato, o local e o foro exclusivo para tal litígio serão um tribunal localizado em Genebra, Suíça, exceto se outro local for mutuamente acordado pelo Operador de registro e a ICANN; entretanto, as partes também terão o direito de fazer valer um parecer desse tribunal em qualquer tribunal de foro competente.”]

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

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

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

ARTICLE 6.

TAXAS

6.1 Taxas do nível do registro.

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

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

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

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

6.2 Recuperação de custos para RSTEP. As solicitações do Operador de registro de aprovação de Serviços adicionais de acordo com a Seção 2.1 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 respectivo processo, disponível em xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxxx/xxxx/. Caso tais solicitações sejam encaminhadas ao RSTEP, o Operador de registro remeterá à ICANN o custo faturado da revisão do RSTEP em um prazo de catorze (14) dias consecutivos após o RSTEP receber uma cópia da fatura da ICANN, a menos que a ICANN decida, a seu exclusivo e absoluto critério, arcar com o custo faturado de tal revisão do RSTEP, no todo ou em parte.

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

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

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

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

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

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

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

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

ARTICLE 7.

DISPOSIÇÕES GERAIS

7.1 Indenização da ICANN.

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

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

“O Operador de registro deverá envidar seus melhores esforços e cooperar com a ICANN para assegurar que a ICANN não incorra em quaisquer custos associados a alegações, danos, responsabilidades, custos e despesas, inclusive taxas e despesas jurídicas razoáveis, decorrentes ou relacionadas a direitos de propriedade intelectual com respeito ao TLD, a autorização do TLD para o Operador de registro, a operação de registro do Operador de registro para o TLD ou a prestação de Serviços de registro do Operador de registro; o Operador de registro não será obrigado a prestar tal cooperação na medida em que tais alegações, danos, responsabilidade, custos ou despesas sejam decorrentes de uma infração por parte da ICANN de qualquer uma de suas obrigações contidas neste Contrato ou de qualquer má conduta intencional da ICANN. Esta Seção não deverá ser considerada

como obrigação do Operador de registro de reembolsar ou indenizar de outra forma a ICANN por custos associados à negociação ou execução deste Contrato, ou à monitoração ou administração das respectivas obrigações das partes constituintes deste Contrato. Além disso, esta Seção não se aplicará a nenhuma solicitação de honorários advocatícios em conexão com qualquer litígio ou arbitragem entre as partes, os quais serão regidos pelo Artigo 5 ou concedidos de outra forma por um tribunal de foro competente ou árbitro.”]

(b) Em quaisquer reivindicações de indenização da ICANN nas quais diversos operadores de registro (inclusive o Operador de registro) estiverem envolvidos nas mesmas ações ou omissões que tenham suscitado a reivindicação, a responsabilidade agregada do Operador de registro de indenizar a ICANN com relação a tal reivindicação será limitada a um percentual do total de reivindicações da ICANN, calculado dividindo-se o número total de nomes de domínio registrados junto ao Operador de registro no TLD

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

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

alegação sujeito a tal defesa de acordo com esta Seção 7.2, a ICANN terá o direito de defender a reivindicação na forma que considerar apropriada, às expensas do Operador de registro, e o Operador de registro cooperará com a defesa. [Observação: esta Seção 7.2 não se aplica a organizações intergovernamentais ou entidades governamentais.]

7.3 Termos definidos. Para fins deste Contrato, exceto se tais definições forem alteradas nos termos de uma Política consensual no futuro, em cujo caso as seguintes definições deverão ser consideradas alteradas e consolidadas em sua totalidade, conforme estabelecido em tal Política consensual, os termos Segurança e Estabilidade serão definidos da seguinte maneira:

(a) Para 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 normatização da Internet bem estabelecido e reconhecido, como o

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

Standards-Track correspondente ou Best Current Practice RFCs, e contando com as informações delegadas do Operador de registro ou provisionamento de serviços.

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

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

(a) O Operador de registro deve fornecer à ICANN um aviso prévio de pelo menos trinta (30) dias consecutivos sobre qualquer cessão ou Disposição de subcontratação importante, e qualquer acordo para ceder ou subcontratar qualquer parte das operações do TLD (seja ou não uma Disposição de subcontratação importante) deverá exigir conformidade com todos os compromissos, obrigações e disposições do Operador de

registro nos termos deste Contrato, e o Operador de registro continuará vinculado a tais compromissos, obrigações e disposições. O Operador de registro também deve fornecer um aviso prévio de pelo menos trinta (30) dias consecutivos à ICANN antes de consumar qualquer transação prevista para ter como resultado uma alteração direta ou indireta de controle de Operador de registro.

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

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

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

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

(f) Não obstante o acima exposto, (i) as alterações de controle consumadas não poderão ser anuladas pela ICANN; entretanto, se a ICANN razoavelmente decidir recusar seu consentimento a tal transação, a ICANN poderá rescindir este Contrato nos termos da Seção 4.3(g), (ii) a ICANN poderá ceder os direitos deste Contrato sem o consentimento do Operador de registro após a aprovação da diretoria da ICANN em conjunto com uma reorganização, reconstituição ou mudança na personalidade jurídica da ICANN após a aceitação expressa de tal cessionário dos termos e condições deste Contrato,

(iii) o Operador de registro poderá ceder os direitos deste Contrato sem o consentimento da ICANN diretamente a um Cessionário afiliado, conforme este termo se encontra definido abaixo, após a aceitação expressa de tal subsidiária Cessionário afiliado ou empresa controladora, conforme o caso, por escrito dos termos e condições deste Contrato, e (iv) será considerado que a ICANN consentiu qualquer transação de cessão, Disposição de subcontratação

importante ou alteração de controle na qual a Parte contratante seja um operador existente de um domínio genérico de primeiro nível de acordo com um contrato de registro entre tal Parte contratante e a ICANN (desde que tal Parte Contratante esteja então em conformidade com os termos e condições de tal contrato de registro em todos os aspectos importantes), a menos que a ICANN forneça ao Operador de registro uma objeção por escrito a tal transação em um prazo de dez (10) dias consecutivos a partir da data em que a ICANN receber o aviso sobre tal transação de acordo com esta Seção 7.5. Não obstante a Seção 7.5(a), no caso de uma cessão de direitos nos termos das cláusulas (ii) ou (iii) desta Seção 7.5(f), a parte cedente fornecerá à outra parte um aviso imediato após tal cessão de direitos. Para os fins desta Seção 7.5(f), (A) “Cessionário afiliado” significa uma pessoa ou entidade que, direta ou indiretamente, por meio de um ou mais intermediários, controla, é controlada ou está sob controle comum com a pessoa ou entidade especificada, e (B) “controle” (inclusive os termos “controlado” e “sob controle comum”) terão o mesmo significado especificado na Seção 2.9(c) deste Contrato.

7.6 Aditamentos e renúncias.

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

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

(c) Se, em um prazo de cento e oitenta (180) dias consecutivos após o término do Período de publicação (o “Período de aprovação”), a diretoria da ICANN aprovar um Aditamento especial (que poderá estar em uma forma diferente da enviada para comentários públicos, mas deverá abordar o objeto do Aditamento especial disponibilizado para comentários públicos, modificado de maneira a refletir e/ou abordar as contribuições do grupo de trabalho e comentários públicos), a ICANN fornecerá um aviso e enviará esse Aditamento especial para aprovação ou rejeição dos Operadores de registro aplicáveis. Se, durante o período de sessenta (60) dias consecutivos após a ICANN fornecer esse aviso aos Operadores de registro aplicáveis, esse Aditamento especial receber a Aprovação dos operadores de registro, esse Aditamento especial será

considerado aprovado (“Aditamento aprovado”) pelos Operadores de registro aplicáveis, e entrará em vigor e será considerado como um aditamento a este Contrato na data correspondente a sessenta (60) dias consecutivos após a ICANN fornecer ao Operador de registro o aviso de aprovação desse Aditamento aprovado (“Data de início da vigência do aditamento”). Caso o Aditamento especial não receba a Aprovação dos operadores de registro, ele será considerado não aprovado pelos Operadores de registro aplicáveis (“Aditamento rejeitado”). Um Aditamento rejeitado não afetará os termos e as condições deste Contrato, exceto conforme disposto abaixo.

(d) Se a diretoria da ICANN determinar razoavelmente que um Aditamento rejeitado se enquadra nas categorias de matéria estabelecidas na Seção 1.2 da Especificação 1, a diretoria da ICANN poderá adotar uma resolução (a data em que tal resolução é adotada é referida neste instrumento como a “Data de adoção da resolução”) solicitando um Relatório de assunto (conforme definido no Estatuto da ICANN) da Organização de apoio a nomes genéricos (“GNSO”) com relação ao conteúdo de tal Aditamento rejeitado. O processo de desenvolvimento de políticas realizado pela GNSO de acordo com tal Relatório de problemas solicitado é referido no presente instrumento como “PDP”. Se esse PDP resultar em um Relatório final apoiado pela maioria qualificada da GNSO (conforme definido no Estatuto da ICANN) que (i) recomende a adoção do Aditamento rejeitado como Política consensual ou (ii) não recomende a adoção do Aditamento rejeitado como Política consensual, e, no caso de (i) acima, a diretoria adotar essa Política consensual, o Operador de registro cumprirá suas obrigações de acordo com a Seção 2.2 deste Contrato. Em ambos os casos, a ICANN abandonará o Aditamento rejeitado e isso não afetará os termos e as condições deste Contrato. Não obstante as disposições precedentes desta Seção 7.6(d), a diretoria da ICANN não será obrigada a iniciar um PDP com relação ao Aditamento rejeitado se, a qualquer momento durante o período de doze

(12) meses anterior ao envio desse Aditamento rejeitado para a Aprovação dos operadores de registro de acordo com a Seção 7.6(c), a matéria desse Aditamento rejeitado for a mesma de um PDP já concluído, ou de outra forma abandonado ou encerrado, que não tenha resultado em uma recomendação da GNSO por maioria qualificada.

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

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

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

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

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

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

Esse Aditamento da diretoria será considerado, sujeito à Seção 7.6(f), um Aditamento aprovado, e entrará em vigor e será considerado um aditamento a este Contrato na data correspondente a sessenta (60) dias consecutivos após a data em que a ICANN enviar o aviso sobre a aprovação desse Aditamento da diretoria ao Operador de registro (essa data de início da vigência será considerada a Data de início da vigência do aditamento nos

termos deste Contrato). Não obstante o precedente, o Aditamento da diretoria não poderá aditar as taxas de registro cobradas pela ICANN de acordo com este instrumento nem aditar esta Seção 7.6.

(f) Não obstante o disposto na Seção 7.6(e), o Aditamento da diretoria não será considerado um Aditamento aprovado se, durante o período de trinta (30) dias consecutivos após a diretoria da ICANN aprovar o Aditamento da diretoria, o grupo de trabalho, em nome dos Operadores de registro aplicáveis, enviar à diretoria da ICANN uma alternativa ao Aditamento da diretoria (“Aditamento alternativo”) que atenda aos seguintes requisitos:

(i) estabelece o texto preciso proposto pelo grupo de trabalho para aditar este Contrato em substituição ao Aditamento da diretoria;

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

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

Qualquer aditamento proposto que não atender aos requisitos das subcláusulas (i) a (iii) do parágrafo imediatamente anterior não será considerado como um Aditamento alternativo nos termos deste instrumento e, portanto, 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 a 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 em que a ICANN enviar o aviso sobre a aprovação desse Aditamento alternativo ao Operador de registro; essa data de início da vigência será considerada como a Data de início da vigência do aditamento nos termos deste Contrato), a menos que, em um período de sessenta (60) dias consecutivos após a data em que o grupo de trabalho enviar o aviso à diretoria da ICANN sobre a Aprovação dos operadores de registro de tal Aditamento alternativo (sendo que durante esse período a ICANN entrará em contato com o grupo de trabalho com relação ao Aditamento alternativo), a diretoria da ICANN, com uma votação positiva de pelos menos dois terços de seus membros qualificados para votar sobre essa matéria e levando em consideração qualquer política da ICANN que afete essa qualificação, inclusive a Política de conflito de interesses da ICANN, rejeitar o Aditamento alternativo. Se

(A) o Aditamento alternativo não receber a Aprovação dos operadores de registro em um

prazo de trinta (30) dias consecutivos após o envio desse Aditamento alternativo aos Operadores de registro aplicáveis (e o grupo de trabalho avisará a ICANN sobre a data desse envio), ou (B) a diretoria da ICANN rejeitar o Aditamento alternativo por uma votação de dois terços de seus membros, o Aditamento da diretoria (e não o Aditamento alternativo) entrará em vigor e será considerado como um aditamento a este Contrato na data correspondente a sessenta (60) dias consecutivos após a data em que a ICANN fornecer o aviso ao Operador de registro (cuja data de início da vigência será considerada a Data de início da vigência do aditamento nos termos deste Contrato). Se a diretoria da ICANN rejeitar um Aditamento alternativo, a diretoria publicará por escrito uma justificativa indicando sua análise dos critérios estabelecidos nas Seções 7.6(f)(i) a 7.6(f)(iii). A capacidade da diretoria da ICANN de rejeitar um Aditamento alternativo nos termos deste Contrato não anula a obrigação da diretoria de garantir que qualquer Aditamento da diretoria atenda aos critérios estabelecidos nas Seções 7.6(e)(i) a 7.6(e)(v).

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

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

Aditamento aprovado não será considerado um aditamento a este Contrato. Se a Solicitação de isenção for aprovada pela ICANN, o Aditamento aprovado não alterará este Contrato; quaisquer condições, alternativas ou variações do Aditamento aprovado exigidas pela ICANN entrarão em vigor e, na medida em que forem aplicáveis, aditarão este Contrato a partir da Data de início da vigência do aditamento. Se essa Solicitação de isenção for rejeitada pela ICANN, o Aditamento aprovado aditará este Contrato a partir da Data de início da vigência do aditamento (ou, se essa data já tiver transcorrido, tal Aditamento aprovado será considerado em vigor imediatamente na data da rejeição); o Operador de registro poderá, em um prazo de trinta (30) dias consecutivos após o recebimento da decisão da ICANN, recorrer da decisão da ICANN de rejeitar a Solicitação de isenção de acordo com os procedimentos para resolução de disputas dispostos no Artigo 5. O Aditamento aprovado será desconsiderado como aditamento a este Contrato durante a pendência do processo de resolução de disputas. Para evitar dúvidas, apenas as Solicitações de isenção submetidas pelo Operador de registro que forem aprovadas pela ICANN nos termos desta Seção 7.6(j), acordadas pela ICANN após mediação nos termos da Seção 5.1 ou por uma decisão de arbitragem nos termos da Seção 5.2 isentarão o Operador de registro de qualquer Aditamento aprovado, e nenhuma Solicitação de isenção concedida a qualquer outro Operador de registro aplicável (seja pela ICANN ou por meio de arbitragem) terá qualquer efeito nos termos deste Contrato nem isentará o Operador de registro de qualquer Aditamento aprovado.

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

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

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

significados:

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

(ii) “Aprovação dos operadores de registro” 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 das taxas (convertido em dólares norte-americanos, se aplicável, à taxa de câmbio vigente publicada no dia anterior na edição norte-americana do Wall Street Journal para a data em que tal cálculo é feito pela ICANN) pagas à ICANN por todos os Operadores de registro aplicáveis durante o ano civil imediatamente anterior nos termos dos Contratos de registro aplicáveis, e (B) a aprovação favorável da maioria dos Operadores de registro aplicáveis no momento em que tal aprovação for obtida. Para evitar dúvidas, com relação à cláusula (B), cada Operador de registro aplicável deverá ter um voto para cada domínio de primeiro nível operado por tal Operador de registro de acordo com um Contrato de registro aplicável.

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

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

(v) “Grupo de trabalho” 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 aos Contratos de registro aplicáveis (exceto aditamentos bilaterais nos termos da Seção 7.6(i)).

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

7.7 Processo de negociação.

(a) Se o diretor geral da ICANN (“CEO”) ou o presidente do Grupo de partes interessadas de registradores (“Presidente”) desejarem discutir qualquer revisão

deste Contrato, o CEO ou o Presidente, conforme o caso, fornecerá à outra parte um aviso por escrito dispondo em detalhes razoáveis as revisões propostas para este Contrato (um “Aviso de negociação”). Não obstante o precedente, nem o CEO nem o Presidente poderão

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

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

(c) Se, após a conclusão do Período de discussão, for obtido um acordo para as Revisões propostas, a ICANN publicará as Revisões propostas mutuamente acordadas em seu site para comentários públicos por pelo menos trinta (30) dias consecutivos (“Período de publicação”) e fornecerá uma aviso sobre essas revisões a todos os Operadores de registro aplicáveis de acordo com a Seção 7.9. A ICANN e o grupo de trabalho analisarão os comentários públicos enviados sobre as Revisões propostas durante o Período de publicação (incluindo comentários enviados pelos Operadores de registro aplicáveis). Após a conclusão do Período de publicação, as Revisões propostas serão enviadas para a Aprovação dos operadores de registro (conforme definido na Seção 7.6) e da diretoria da ICANN. Se forem obtidas essas aprovações, as Revisões propostas serão consideradas um Aditamento aprovado (conforme definido na Seção 7.6) pelos Operadores de registro aplicáveis e a ICANN, e 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 uma mediação imparcial e 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 um prazo de quinze (15) dias consecutivos, publicar simultaneamente o texto de sua versão desejada das Revisões propostas e um documento explicando sua posição com relação a elas no site da ICANN.

(i) A mediação será realizada por um único mediador selecionado pelas partes. Se as partes não chegarem a um acordo sobre um mediador em um prazo de quinze (15) dias consecutivos após o CEO ou o Presidente, conforme o caso, receber o Aviso de mediação, as partes selecionarão imediatamente uma entidade mediadora mutuamente aceitável, que, assim

que possível e após a seleção dessa entidade, nomeará um mediador, que será um advogado licenciado com conhecimento geral sobre direito contratual e sem nenhuma relação comercial em andamento com qualquer uma das partes e, na medida do necessário para mediar a disputa em particular, conhecimento geral do sistema de nomes de domínio. Qualquer mediador deverá confirmar por escrito que não é e não se tornará, durante o período da mediação, funcionário, sócio, diretor executivo, executivo ou detentor de valores mobiliários da ICANN nem de um Operador de registro aplicável. Se essa confirmação não for fornecida pelo mediador nomeado, um mediador substituto será nomeado de acordo com esta Seção 7.7(d)(i).

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

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

(iv) Se for alcançado um acordo durante a mediação, a ICANN publicará as Revisões propostas mutuamente acordadas em seu site para o Período de publicação e fornecerá aviso a todos os Operadores de registro aplicáveis de acordo com a Seção 7.9. A ICANN e o grupo de trabalho analisarão os comentários públicos enviados sobre as Revisões propostas acordadas durante o Período de publicação (inclusive comentários enviados pelos Operadores de registro aplicáveis). Após a conclusão do Período de publicação, as Revisões propostas serão enviados para a Aprovação dos operadores de registro e da diretoria da ICANN. Se forem obtidas essas aprovações, as Revisões propostas serão consideradas um Aditamento aprovado (conforme definido na Seção 7.6) pelos Operadores de registro aplicáveis e a ICANN, e 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 resolverem a disputa por algum motivo até a data correspondente a noventa (90) dias consecutivos após o CEO ou o Presidente, conforme o caso, receber o Aviso de mediação, a mediação será encerrada imediatamente (a menos que seja prorrogada por acordo das partes). O mediador entregará às partes uma definição das questões que poderiam ser analisadas em uma arbitragem futura, se solicitada. Essas questões estão sujeitas às limitações estabelecidas na Seção 7.7(e)(ii) abaixo.

(e) Se, após a mediação, a ICANN e o grupo de trabalho não chegarem a um acordo sobre as Revisões propostas, o CEO ou o Presidente poderã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 vinculativa

de acordo com as cláusulas de arbitragem da Seção 5.2, sujeito aos requisitos e às limitações desta Seção 7.7(e).

(i) Se for enviado um Aviso de arbitragem, a definição das questões do mediador, juntamente com as Revisões propostas (sejam elas da ICANN, do grupo de trabalho ou de ambos), será publicada para comentários públicos no site da ICANN por um período de o mínimo trinta (30) dias consecutivos. A ICANN e o grupo de trabalho analisarão os comentários públicos enviados sobre as Revisões propostas durante o Período de publicação (inclusive comentários enviados pelos Operadores de registro aplicáveis), e as informações relacionadas a esses comentários e análise serão fornecidas a um painel de arbitragem composto por três (3) pessoas. Cada parte poderá modificar suas Revisões propostas antes e depois do Período de publicação. O procedimento de arbitragem não poderá começar antes do fechamento desse período de comentários públicos, e a ICANN não poderá unir todas as contestações levantadas pelos operadores de registro (inclusive o Operador de registro) em um único procedimento. Exceto conforme disposto nesta Seção 7.7, a arbitragem será realizada de acordo com a Seção 5.2.

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

(i) esteja relacionada à Política consensual, (ii) se enquadre nas categorias de matéria estabelecidas na Seção 1.2 da Especificação 1, ou (iii) tenha como objetivo aditar qualquer uma das seguintes cláusulas ou Especificações deste Contrato: Artigos 1, 3 e 6; 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 Especificações 1, 4, 6, 10 e 11.

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

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

(v) Para que o painel de arbitragem aprove o aditamento proposto da ICANN ou do grupo de trabalho relacionado às Revisões propostas, o painel de arbitragem deverá concluir que esse aditamento proposto é coerente com uma aplicação equilibrada dos valores essenciais da ICANN

(conforme descrito no Estatuto da ICANN) e razoável considerando a relação custo-benefício para os interesses comerciais dos Operadores de registro aplicáveis e da ICANN (conforme o caso), e o benefício público almejado com as Revisões propostas conforme disposto nesse aditamento. Se o painel de arbitragem concluir que o aditamento proposto pela ICANN ou pelo grupo de trabalho referente às Revisões propostas atende ao padrão mencionado acima, esse aditamento entrará em vigor e será considerado como tal para este Contrato sessenta (60) dias consecutivos após a ICANN enviar um aviso ao Operador de registro e será considerado um Aditamento aprovado nos termos deste instrumento.

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

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

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

7.9 Avisos gerais. Com exceção dos avisos de acordo com as Seções 7.6 e 7.7, todos os avisos que forem fornecidos nos termos deste Contrato ou em relação a ele, serão dados (i) por escrito no endereço da parte apropriada conforme estabelecido abaixo ou (ii) por fax ou correio eletrônico conforme disposto abaixo, a menos que a parte tenha enviado uma notificação de mudança de endereço postal, e-mail ou número de fax, conforme estabelecido neste Contrato. Todos os avisos de acordo com as 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 para aviso indicadas abaixo será fornecida pela parte em um prazo de trinta (30) dias consecutivos após tal alteração. Exceto os avisos nos termos da Seção 7.6 ou 7.7, qualquer aviso exigido pelo presente Contrato será considerado como tendo sido adequadamente fornecido (i) se em papel, quando entregue pessoalmente ou por serviço de mensageiro com confirmação de recebimento ou (ii) se por 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 em um prazo de 3 (três) dias consecutivos. Qualquer aviso exigido pelas Seções 7.6 ou 7.7 será considerado como tendo sido fornecido quando publicado eletronicamente no site da ICANN e após a confirmação de recebimento pelo servidor de

e-mail. Caso outros meios de comunicação se tornem viáveis, como avisos por meio de um site seguro, as partes trabalharão juntas para implementar tal meio de comunicação nos termos deste Contrato.

Se for destinado à ICANN, endereçado para:

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

Xxx Xxxxxxx, XX 00000-0000 EUA

Telefone: x0-000-000-0000

Fax: x0-000-000-0000

Aos cuidados de: Presidente e CEO

Com cópia para: Consultor jurídico geral

E-mail: (Conforme especificado periodicamente.)

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

[ ]

Telefone:

Com cópia para:

E-mail: (Conforme especificado periodicamente.)

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

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

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

7.13 Autonomia; conflitos com a legislação. O presente Contrato será considerado como sendo divisível; a invalidade ou inaplicabilidade de qualquer termo ou cláusula do presente Contrato não afetará a validade ou a aplicabilidade do conjunto do presente Contrato ou de qualquer outro termo deste, que permanecerá em pleno vigor e efeito. Se qualquer uma das cláusulas deste Contrato for considerada inválida ou inaplicável, as partes deverão negociar, de boa-fé, as modificações a este Contrato no intuito de efetivar a intenção original das partes, tanto quanto possível. A ICANN e o grupo de trabalho cooperarão mutuamente para desenvolver um processo de revisão e análise da ICANN de supostos conflitos entre a legislação aplicável e cláusulas não relacionadas ao WHOIS deste Contrato. Até que este procedimento seja desenvolvido e implementado, a ICANN revisará e analisará supostos conflitos entre a legislação aplicável e cláusulas não relacionadas ao WHOIS deste Contrato de maneira semelhante ao procedimento para tratar os conflitos do WHOIS com a Lei de privacidade da ICANN.

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

7.15 Confidencialidade

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

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

(c) Cada parte terá o direito de divulgar informações confidenciais, na medida em que essa divulgação seja (i) feita em resposta a uma ordem válida de um tribunal de foro competente ou, se na opinião razoável da assessoria jurídica da parte destinatária, tal divulgação for de outra forma exigida pela legislação aplicável; no entanto, a parte destinatária avisará primeiro a parte divulgadora e dará à parte divulgadora uma oportunidade razoável para anular essa ordem ou obter uma ordem de proteção ou ordem de tratamento confidencial exigindo que as Informações confidenciais objeto de tal ordem ou outra legislação aplicável sejam mantidas em sigilo por tal tribunal ou outro terceiro destinatário, a menos que a parte destinatária não seja autorizada a fornecer tal aviso de acordo com tal ordem ou legislação aplicável, ou (ii) feita pela parte destinatária ou qualquer de seus Afiliados aos próprios procuradores, auditores, assessores, consultores, contratados ou outros terceiros para uso por tal pessoa ou entidade conforme possa ser necessária ou útil em conexão com o desempenho das atividades nos termos deste Contrato, desde que o terceiro esteja vinculado a obrigações de confidencialidade no mínimo tão rigorosas como as aqui estabelecidas, seja por acordo escrito ou por meio de normas de responsabilidade profissional.

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

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

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

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

proposta, o mais tardar ao final de qualquer período de comentários públicos sobre tal Política consensual proposta.

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

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

(f) Não obstante qualquer outra cláusula desta Seção 7.16, seguindo uma Decisão da ICANN e antes da decisão de um árbitro nos termos da Seção 7.16(d) acima, a ICANN poderá, sujeito a consultas prévias ao Operador de registro, tomar as medidas técnicas razoáveis que considerar necessárias para garantir a Segurança e a estabilidade dos serviços de registro, da Internet e do DNS. Essas medidas técnicas razoáveis serão

tomadas pela ICANN em caráter provisório até o início da data da conclusão do procedimento de arbitragem referido na Seção 7.16(d) acima ou da data da resolução completa do conflito com a legislação aplicável. Caso o Operador de registro não concorde com as medidas técnicas tomadas pela ICANN, ele poderá enviar a questão à arbitragem vinculativa nos termos das cláusulas da Seção 5.2 acima, processo durante o qual a ICANN poderá continuar a tomar tais medidas técnicas. Caso a ICANN tome tais medidas, o Operador de registro arcará com todos os custos incorridos pela ICANN como resultado de tomar tais medidas. Além disso, caso a ICANN tome tais medidas, ela manterá e poderá fazer valer seus direitos nos termos do Instrumento de operações contínuas e do Instrumento alternativo, conforme o caso.

* * * * *

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

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

Por: [ ]

Presidente e CEO Data:

[Operador de registro]

Por: [ ]

[ ] Data:

DOCUMENTO A

Serviços aprovados

O Manual do solicitante de gTLDs da ICANN (disponível em 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á prestar qualquer serviço que seja necessário nos termos deste Contrato. Além disso, os serviços a seguir (se houver) são especificamente identificados como tendo sido aprovados pela ICANN antes da data de vigência do Contrato, e o Operador de registro poderá prestar tais serviços:

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

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

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

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

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

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

SPECIFICATION 1

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

1. Políticas consensuais.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.1. Essa especificação ou política proposta será elaborada da maneira mais limitada possível a fim de alcançar esses objetivos. Ao estabelecer qualquer Política temporária, a diretoria declarará o período para o qual a Política

temporária será adotada e implementará imediatamente o processo de desenvolvimento da Política consensual estabelecido no Estatuto da ICANN.

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

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

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

SPECIFICATION 2 REQUISITOS DE DEPÓSITO DE DADOS

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

depositário de dados (“Agente depositário”) para a prestação de serviços de depósito de dados relacionados com o Contrato de registro. As Especificações técnicas a seguir, estabelecidas na parte A, e os Requisitos legais, apresentados na parte B, serão incluídos em qualquer contrato de depósito de dados entre o Operador de registro e o Agente depositário, em cujos termos a ICANN deve ser indicada como um terceiro beneficiário.

Além dos requisitos a seguir, o contrato de depósito de dados pode conter outras cláusulas que não sejam contraditórias ou que não tenham a intenção de subverter os termos obrigatórios estabelecidos abaixo.

PARTE A – ESPECIFICAÇÕES TÉCNICAS

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

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

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

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

2.1. Todo domingo, deve ser enviado um Depósito integral ao Agente depositário até 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é 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-xxxxx-xxxxxxx-registry-data-escrow, consulte a Parte A, Seção 9, referência 1 desta Especificação e

draft-xxxxx-xxxxxxx-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á esses elementos nos Depósitos se eles estiverem disponíveis. Se já não houver 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 da Especificação DNDE após a Data de vigência. Quando a Especificação DNDE for publicada como RFC, o Operador de registro implementará essa versão da Especificação DNDE em um prazo máximo de 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 outros Serviços de registro que exijam a apresentação de dados adicionais, não incluídos acima, serão definidos outros “esquemas de extensão” para representar tais dados caso a caso. Esses “esquemas de extensão” serão especificados conforme descrito na Parte A, Seção 9, referência 2 desta Especificação. Os dados relativos aos “esquemas de extensão” serão incluídos no arquivo de depósito descrito na Parte A, Seção 3.1 desta Especificação. A ICANN e o respectivo Operador de registro deverão trabalhar em conjunto para chegar a um acordo sobre as especificações de depósito de dados desses novos objetos.

4. Processamento de arquivos de Depósito. É recomendado o uso de compactação para reduzir o tempo de transferência eletrônica dos dados e os requisitos de capacidade de armazenamento. A criptografia de dados será utilizada para garantir a privacidade dos dados de depósito do registro. Os arquivos processados para compactação e criptografia estarão no formato OpenPGP binário conforme a RFC 4880 – Formato de mensagem OpenPGP, consulte a Parte A, Seção 9, referência 3 desta Especificação. Os algoritmos aceitáveis para criptografia de chave pública, criptografia de chave simétrica, hash e compactação são os enumerados na RFC 4880, não marcados como obsoletos no registro OpenPGP da IANA, consulte a Parte A, Seção 9, referência 4 desta Especificação, que também são livres de direitos autorais. O processo a ser seguido para o arquivo de dados em formato de texto original é:

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

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

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

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

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

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

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

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

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

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

5.3. {tipo} é substituído por:

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

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

(3) “thin”, se os dados representarem um arquivo de Acesso a dados de

registro em lote, conforme especificado na Seção 3 da Especificação 4;

(4) “thick-{gurid}”, se os dados representarem Dados de registro thick de um registrador específico, conforme definido na Seção 3.2 da Especificação 4. O elemento {gurid} deve ser substituído pelo ID do registrador da IANA associado aos dados.

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

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

em “0”:

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

6. Distribuição de chaves públicas. Cada Operador de registro e Agente depositário distribuirá sua chave pública à outra parte (Operador de registro ou Agente depositário, conforme o caso) por e-mail para um endereço de e-mail a ser especificado. Cada parte confirmará o recebimento da chave pública da outra parte com um e-mail de resposta, e a parte distribuidora confirmará posteriormente a autenticidade da chave transmitida por métodos off-line, como reunião presencial, telefone etc. Dessa forma, a transmissão da 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 do Operador de registro (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 Xxxxxxxx foi inspecionado pelo Operador de registro e está completo e preciso.. A preparação e o envio dessa declaração deverão ser realizados pelo Operador de registro ou seu designado, mas tal designado não poderá ser nem o Agente depositário, nem nenhum de seus Afiliados. O Operador de registro incluirá os atributos “id” e “resend” do Depósito em sua declaração. Os atributos são explicados na Parte A, Seção 9, referência 1 desta Especificação.

Se ainda não tiver uma RFC, o Operador de registro usará a versão preliminar mais recente da Especificação da interface na Data de 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 fizerem parte de um arquivo maior, este será montado.

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

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

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

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

9. Referências.

(1) Especificação 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 do 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 do OpenPGP,

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

(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 correspondente, assim como de todos os aditamentos a este. Além disso, antes de celebrar um contrato de depósito, o Operador de registro deverá obter o consentimento da ICANN para (a) usar o Agente depositário especificado e

(b) celebrar o tipo de contrato de depósito fornecido. A ICANN 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 respectivos aditamentos, a seu exclusivo critério.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7. Verificação de Depósitos.

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

7.2. Se o Agente depositário constatar que qualquer 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 o Operador de registro por e-mail, fax ou telefone e a ICANN (usando a API descrita em draft-lozano-icann-registry-interfaces, consulte a Parte A, Seção 9, referência 5 desta Especificação) sobre tal falta de conformidade ou não recebimento em um prazo de vinte e quatro (24) horas após receber o Depósito fora de conformidade ou no prazo para tal Depósito, conforme o caso. Após a notificação desta falha de verificação ou entrega, o Operador de registro 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 aprovado

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

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

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

SPECIFICATION 3

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

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

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

1. Relatório de transações por registrador. Este relatório deve ser compilado em um arquivo formatado com valores separados por vírgulas, conforme especificado na RFC 4180. O arquivo deve ser nomeado “gTLD-transactions-yyyymm.csv", onde “gTLD” é o nome do gTLD; no caso de um TLD de IDN, deve ser utilizado o rótulo A; “yyyyfmm” é o ano e o mês do relatório. O arquivo deverá conter os seguintes campos por registrador:

Camp o nº	Nome do campo	Descrição
01	registrar-name	Razão social completa do registrador conforme registrado na IANA
02	iana-id	Nos casos em que o operador de registro atue como registrador (ou seja, sem o uso de um registrador credenciado da ICANN), deve ser usado 9998 ou 9999, dependendo do tipo de registro (conforme descrito na Especificação 5), caso contrário deve ser usado o ID da IANA do registrador responsável, 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 do EPP, exceto pendingCreate, que não tenham sido descartados
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 do EPP, exceto 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 pendingCreate do EPP) em um período inicial de um (1) ano (e não excluídos dentro do período de tolerância). A transação deve ser relatada no mês em que terminar 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 pendingCreate do EPP) em um período inicial de dois (2) anos (e não excluídos dentro do período de tolerância). A transação deve ser relatada no mês em que terminar 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 pendingCreate do EPP) em um período inicial de três (3) anos (e não excluídos dentro do período de tolerância). A transação deve ser relatada no mês em que terminar 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 pendingCreate do EPP) em um período inicial de quatro (4) anos (e não excluídos dentro do período de tolerância). A transação deve ser relatada no mês em que terminar 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 pendingCreate do EPP) em um período inicial de cinco (5) anos (e não excluídos dentro do período de tolerância). A transação deve ser relatada no mês em que terminar 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 pendingCreate do EPP) em um período inicial de seis (6) anos (e não excluídos dentro do período de tolerância). A transação deve ser relatada no mês em que terminar 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 pendingCreate do EPP) em um período inicial de sete (7) anos (e não excluídos dentro do período de tolerância). A transação deve ser relatada no mês em que terminar 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 pendingCreate do EPP) em um período inicial de oito (8) anos (e não excluídos dentro do período de tolerância). A transação deve ser relatada no mês em que terminar 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 pendingCreate do EPP) em um período inicial de nove (9) anos (e não excluídos dentro do período de tolerância). A transação deve ser relatada no mês em que terminar 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 pendingCreate do EPP) em um período inicial de dez (10) anos (e não excluídos dentro do período de tolerância). A transação deve ser relatada no mês em que terminar 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 pendingRenew do EPP) automaticamente ou por comando com um novo período de renovação de um (1) ano (e não excluídos dentro do período de renovação ou de tolerância de renovação automática). A transação deve ser relatada no mês em que terminar o período de renovação ou de tolerância de renovação automática.
16	net-renews-2-yr	o número de domínios renovados com sucesso (ou seja, não estão com status pendingRenew do EPP) automaticamente ou por comando com um novo período de renovação de dois (2) anos (e não excluídos dentro do período de renovação ou de tolerância de renovação automática). A transação deve ser relatada no mês em que terminar o período de renovação ou de tolerância de renovação automática.
17	net-renews-3-yr	o número de domínios renovados com sucesso (ou seja, não estão com status pendingRenew do EPP) automaticamente ou por comando com um novo período de renovação de três (3) anos (e não excluídos dentro do período de renovação ou de tolerância de renovação automática). A transação deve ser relatada no mês em que terminar o período de renovação ou de tolerância de renovação automática.

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

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

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

A primeira linha deverá incluir os nomes dos campos exatamente conforme descritos na tabela acima como uma “linha de cabeçalho”, conforme descrito na Seção 2 da RFC 4180. A última linha de cada relatório deve incluir os totais de cada coluna em todos os registradores; o primeiro campo dessa linha deverá ser “Totals”, enquanto que o segundo campo dessa 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 na RFC 4180.

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

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

Campo nº	Nome do campo	Descrição
01	operational-registrars	o número de registradores operacionais no sistema de produção ao final do período do relatório
02	zfa-passwords	o número de senhas ativas de acesso ao arquivo de zona no final do período do relatório; pode ser usado "CZDS" em vez do número de senhas ativas de acesso ao arquivo de zona, caso o Serviço centralizado de dados de zona (CZDS) seja usado para fornecer o arquivo de zona ao usuário final
03	whois-43-queries	o número de consultas do WHOIS (porta 43) respondidas durante o período do relatório
04	web-whois-queries	o número de consultas do Whois baseado na Web respondidas durante o período do relatório, sem incluir o Whois pesquisável
05	searchable-whois-queries	o número de consultas do Whois pesquisável respondidas durante o período do relatório, se esta opção for oferecida
06	dns-udp-queries-received	o número de consultas do DNS recebidas por transporte UDP durante o período do relatório
07	dns-udp-queries-responded	o número de consultas do DNS recebidas por transporte UDP respondidas durante o período do relatório
08	dns-tcp-queries-received	o número de consultas do DNS recebidas por transporte TCP durante o período do relatório
09	dns-tcp-queries-responded	o número de consultas do DNS recebidas por transporte TCP respondidas durante o período do relatório
10	srs-dom-check	o número de solicitações de “verificar” nomes de domínio do SRS (EPP e qualquer outra interface) respondidas durante o período do relatório
11	srs-dom-create	o número de solicitações de “criar” nomes de domínio do SRS (EPP e qualquer outra interface) respondidas durante o período do relatório
12	srs-dom-delete	o número de solicitações de “excluir” nomes de domínio do SRS (EPP e qualquer outra interface) respondidas durante o período do relatório

Campo nº	Nome do campo	Descrição
13	srs-dom-info	o número de solicitações de “informações” de nomes de domínio do SRS (EPP e qualquer outra interface) respondidas durante o período do relatório
14	srs-dom-renew	o número de solicitações de “renovar” nomes de domínio do SRS (EPP e qualquer outra interface) respondidas durante o período do relatório
15	srs-dom-rgp-restore-report	o número de solicitações de “restaurar” o RGP de nomes de domínio do SRS (EPP e qualquer outra interface) que forneceram um relatório de restauração e foram respondidas durante o período do relatório
16	srs-dom-rgp-restore-request	o número de solicitações de “restaurar” o RGP de nomes de domínio do SRS (EPP e qualquer outra interface) respondidas durante o período do relatório
17	srs-dom-transfer-approve	o número de solicitações de “transferir” nomes de domínio do SRS (EPP e qualquer outra interface) para aprovar transferências respondidas durante o período do relatório
18	srs-dom-transfer-cancel	o número de solicitações de “transferir” nomes de domínio do SRS (EPP e qualquer outra interface) para cancelar transferências respondidas durante o período do relatório
19	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
20	srs-dom-transfer-reject	o número de solicitações de “transferir” nomes de domínio do SRS (EPP e qualquer outra interface) para rejeitar transferências respondidas durante o período do relatório
21	srs-dom-transfer-request	o número de solicitações de “transferir” nomes de domínio do SRS (EPP e qualquer outra interface) para solicitar transferências respondidas durante o período do relatório
22	srs-dom-update	o número de solicitações de “atualizar” nomes de domínio do SRS (sem incluir solicitações de

Campo nº	Nome do campo	Descrição
		restauração do RGP) respondidas durante o período do relatório
23	srs-host-check	o número de solicitações de “verificar” hosts do SRS (EPP e qualquer outra interface) respondidas durante o período do relatório
24	srs-host-create	o número de solicitações de “criar” hosts do SRS (EPP e qualquer outra interface) respondidas durante o período do relatório
25	srs-host-delete	o número de solicitações de “excluir” hosts do SRS (EPP e qualquer outra interface) respondidas durante o período do relatório
26	srs-host-info	o número de solicitações de “informações” de hosts do SRS (EPP e qualquer outra interface) respondidas durante o período do relatório
27	srs-host-update	o número de solicitações de “atualizar” hosts do SRS (EPP e qualquer outra interface) respondidas durante o período do relatório
28	srs-cont-check	o número de solicitações de “verificar” contatos do SRS (EPP e qualquer outra interface) respondidas durante o período do relatório
29	srs-cont-create	o número de solicitações de “criar” contatos do SRS (EPP e qualquer outra interface) respondidas durante o período do relatório
30	srs-cont-delete	o número de solicitações de “excluir” contatos do SRS (EPP e qualquer outra interface) respondidas durante o período do relatório
31	srs-cont-info	o número de solicitações de “informações” de contatos do SRS (EPP e qualquer outra interface) respondidas durante o período do relatório
32	srs-cont-transfer-approve	o número de solicitações de “transferir” contatos do SRS (EPP e qualquer outra interface) para aprovar transferências respondidas durante o período do relatório
33	srs-cont-transfer-cancel	o número de solicitações de “transferir” contatos do SRS (EPP e qualquer outra interface) para cancelar transferências respondidas durante o período do relatório
34	srs-cont-transfer-query	o número de solicitações de “transferir” contatos do SRS (EPP e qualquer outra

Campo nº	Nome do campo	Descrição
		interface) para consultar sobre uma transferência respondida durante o período do relatório
35	srs-cont-transfer-reject	o número de solicitações de “transferir” contatos do SRS (EPP e qualquer outra interface) para rejeitar transferências respondidas durante o período do relatório
36	srs-cont-transfer-request	o número de solicitações de “transferir” contatos do SRS (EPP e qualquer outra interface) para solicitar transferências respondidas durante o período do relatório
37	srs-cont-update	o número de solicitações de “atualizar” contatos do SRS (EPP e qualquer outra interface) respondidas durante o período do relatório

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

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

No caso de gTLDs que fazem parte de uma única instância do Sistema de registro compartilhado, o Relatório de atividades das funções de registro pode incluir o total de contatos ou transações de host para todos os gTLDs do sistema.

SPECIFICATION 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 a 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 nomes 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 na 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 de uma linha em branco e uma ressalva jurídica especificando os direitos do Operador de registro e do usuário que faz a consulta ao banco de dados.

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

1.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 DE EXEMPLO 123 Cidade do registrante: QUALQUER CIDADE Estado/Província do registrante: AP

Código postal do registrante: A1A1A1 País do registrante: EX

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

E-mail do registrante: XXXXX@XXXXXXX.XXX ID do administrador: 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.5555551212 Ramal do telefone do administrador: 1234 Fax do administrador: +1.5555551213 Ramal do fax do administrador:

E-mail do Administrador: XXXXX@XXXXXXX.XXX ID 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 “registrador Exemplo Registrar, Inc.”

1.6.2 Formato da resposta:

Nome do registrador: Exemplo Registrar, Inc. Endereço: 0000 Xxxxxxxxx Xxx

Cidade: Marina del Rey Estado/Província: CA Código Postal: 90292 País: EUA

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

E-mail: xxxxxxxxxxx@xxxxxxx.xxx

Servidor WHOIS: whois.exemplo-registrador.tld

URL de referência: xxxx://xxx.xxxxxxx-xxxxxxxxxxx.xxx Contato do administrador: Xxxx Xxxxxxxxxxx

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

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

Número de fax: +1.3105551213

E-mail: xxxxxxxxxxxxxxx@xxxxxxx-xxxxxxxxxxx.xxx Contato técnico: Xxxx Xxxxx

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 “nameserver (nome do servidor de nomes)” ou whois “nameserver (endereço IP).” Por exemplo, whois “nameserver NS1.EXEMPLO.TLD”.

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: Exemplo 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 nas RFCs 5730-5734 do EPP de modo que a exibição dessas informações (ou os valores retornados em resultados de WHOIS) seja processada e compreendida de maneira uniforme.

1.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 nomes e endereço IP do servidor de nomes (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 conterão 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 acreditar 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 SFTP de Arquivo de zona FTPSFTP (ou outro Registro aceito) de uma URL especificada e gerenciada pela ICANN (especificamente, <TLD>.xxx.xxxxx.xxx onde

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

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

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

1. Cada registro deve incluir todos os campos em uma única linha como: <domain-name> <TTL> <class> <type> <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 uma marca de tabulação 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 zona vai para um arquivo separado, nomeado conforme mostrado acima com todos os arquivos combinados usando tar em um arquivo chamado

<tld>.zone.tar.

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

sistemas do Operador de registro ou de qualquer registrador credenciado pela ICANN ou (iii) interromper, encerrar ou interferir nas operações normais de negócios de qualquer registrante.

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

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

2.2. Cooperação

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

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

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

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

3.1. Acesso periódico aos dados de registro thin. No intuito de verificar e assegurar a estabilidade operacional dos Serviços de registro, 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 nomes do servidor de nomes. Para registradores responsáveis, pelo menos, fornecerá: nome de registro,

id do registrador (roidID da IANA), 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 indicado na Especificação 2.

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

3.2. Acesso excepcional aos dados de registro thick. Em caso de uma falha do registrador, descredenciamento, ordem judicial etc., que 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 que os dados especificados na Seção 3.1 desta Especificação.

SPECIFICATION 5 CRONOGRAMA DE NOMES RESERVADOS

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

sujeito aos termos e condições desta Especificação, o Operador de registro deverá reservar os rótulos a seguir do registro inicial (isto é, que não sejam renovação) no TLD. Se estiver usando a própria alocação, o Operador de registro 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. O rótulo ASCII “EXEMPLO” será retido no registro ou será alocado ao Operador de registro no segundo nível e em todos os outros níveis dentro do TLD nos quais o Operador de registro oferece registros (como segundo nível e todos os outros níveis são coletivamente referidos aqui como "Todos os níveis"). Esse rótulo não pode ser ativado no DNS e não pode ser disponibilizado para o registro a nenhuma pessoa ou entidade que não seja o Operador de registro. Após a conclusão da designação do Operador de registro como operador de registro para o TLD, tal rótulo retido ou atribuído deverá ser transferido conforme especificado pela ICANN. O Operador de registro poderá atribuir para si e renovar 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. Rótulos de dois caracteres. Todos os rótulos de dois caracteres ASCII serão retidos no registro ou serão alocados ao Operador de registro no segundo nível dentro do TLD. Esses rótulos não podem ser ativados no DNS e não podem ser liberados para o registro a nenhuma pessoa ou entidade que não seja o Operador de registro, desde que tais cadeias de caracteres de rótulos de dois caracteres possam ser liberadas na medida em que o Operador de registro chegar a um acordo com o respectivo governo e o gerenciador de código de país da cadeia de caracteres, conforme especificado no padrão ISO 3166-1 alpha-2. O Operador de registro também pode propor a liberação dessas reservas com base na implementação de medidas para evitar confusão com os códigos de países correspondentes, sujeito à aprovação pela ICANN. Após a conclusão da designação do Operador de registro como Operador de registro para o TLD, todos estes rótulos que permanecem retidos no registro ou alocados ao Operador de registro serão transferidos, conforme especificado pela ICANN. O Operador de registro poderá atribuir para si e renovar tais nomes sem o uso de um registrador credenciado pela ICANN, fato que não será considerado Transações para fins da Seção 6.1 do Contrato.

3. Reservas para operações de registro.

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

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

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

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 para 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). Se o Operador de registro escolher a opção (ii) acima, deverá identificar essas transações com o uso do ID de registrador 9998. A critério do Operador de registro e em conformidade com todos os outros termos deste Contrato, inclusive os RPMs estabelecidos na Especificação 7, esses nomes podem ser disponibilizados para registro para outra pessoa ou entidade.

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

(iii) nem afetará desfavoravelmente a qualificação do Operador de registro como um TLD .BRAND de acordo com a Especificação 13 (cláusulas do TLD

.BRAND) deste documento (conforme o caso).

4. Nomes de países e territórios. Os nomes de países e territórios (inclusive suas variações de IDN, quando aplicável) contidos nas seguintes listas reconhecidas internacionalmente, 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 para Assuntos Governamentais 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 para si e renovar tais nomes sem o uso de um registrador credenciado pela ICANN, fato que não será considerado Transações para fins da Seção 6.1 do Contrato.

5. Comitê Olímpico Internacional; Movimento Internacional da Cruz Vermelha e Crescente Vermelho. 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 Crescente Vermelho 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 Crescente Vermelho (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 para si e renovar tais nomes sem o uso de um registrador credenciado pela ICANN, fato que não será considerado Transações para fins da Seção 6.1 do Contrato.

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 para si e renovar tais nomes sem o uso de um registrador credenciado pela ICANN, fato que não será considerado Transações para fins da Seção 6.1 do Contrato.

SPECIFICATION 6

ESPECIFICAÇÕES DE INTEROPERABILIDADE E CONTINUIDADE DO REGISTRO

1. Conformidade com as normas

1.1. DNS. O Operador de registro deve cumprir as RFCs relevantes já existentes e as que serão publicadas futuramente pela Força-tarefa de engenharia da Internet (IETF), inclusive todas as normas, modificações ou aditamentos posteriores relativas ao DNS e operações do servidor de nomes, inclusive, entre outros, as RFCs 1034, 1035, 1123, 1982, 2181, 2182, 3226, 3596, 3597, 4343, 5966 e 6891. Os rótulos 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 as RFCs relevantes já existentes e as que serão publicadas futuramente pela Força-tarefa de engenharia da Internet (IETF), inclusive todas as normas, modificações ou aditamentos posteriores relativos ao fornecimento e gestão de nomes de domínio usando o Protocolo de provisionamento extensível (EPP) em conformidade com as RFCs 5910, 5730, 5731, 5732 (se estiver usando objetos de host), 5733 e 5734. Se o Operador de registro implementar o Período de tolerância do registro (RGP), ele atenderá à RFC 3915 e posteriores. Se o Operador de registro exigir o uso da funcionalidade fora das RFCs do EPP de base, o Operador de registro deve documentar as extensões de EPP no formato preliminar da Internet, seguindo as orientações descritas na RFC 3735. O Operador de registro fornecerá e atualizará a documentação pertinente de todos os objetos e extensões de EPP aceitos pela ICANN antes da implantação.

1.3. DNSSEC. O Operador de registro deverá assinar seus arquivos de zona TLD da implementação das Extensões de segurança do sistema de nomes de domínio ("DNSSEC"). Para evitar dúvidas, o Operador de registro deverá assinar o arquivo de zona de <TLD> e os arquivos de zona usados para o campo de atividade agregado dos servidores de DNS do TLD. Durante o Prazo, o Operador de registro deve cumprir as RFCs 4033, 4034, 4035, 4509 e posteriores e seguir as práticas recomendadas descritas na RFC 6781 e posteriores. Se o Operador de registro implementar Negação autenticada em hash da existência das extensões de segurança do DNS, ele deve atender à 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 na RFC 6841. A validação das DNSSEC deve estar ativada e usar o conjunto de chaves de assinatura de chave raiz do DNS da IANA (disponíveis em xxxxx://xxx.xxxx.xxx/xxxxxx/xxxxx) como uma âncora de confiança dos Serviços de registro do Operador de registro que fizer uso dos dados obtidos por meio de respostas de DNS.

1.4. IDN. Se o Operador de registro oferecer Nomes de domínio internacionalizados ("IDNs"), ele deve cumprir as 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 elas podem ser alteradas, modificadas ou substituídas 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.

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 a, pelo menos, dois dos servidores de nomes do registro relacionados na zona raiz com os endereços IPv6 correspondentes registrados pela IANA. O Operador de registro deve seguir as “Diretrizes operacionais de transporte de IPv6 do DNS”, conforme descrito na BCP 91 e as recomendações e considerações descritas na RFC 4472. O Operador de registro deve oferecer transporte de IPv6 público a 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 a seu Sistema de registro compartilhado (SRS) a qualquer registrador, o mais tardar seis (6) meses após o recebimento da primeira solicitação por escrito de um registrador credenciado pelo gTLD disposto a operar com o SRS no IPv6.

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

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

2. Serviços de registro

2.1. Serviços de registro. Os "Serviços de registro" são, para efeitos do Contrato, definidos conforme segue: (a) os serviços que são operações do registro essenciais para as seguintes tarefas: o recebimento de dados de registradores relativos aos registros de nomes de domínio e servidores de nomes; fornecimento, aos registradores, das informações de status referentes aos servidores de zona do 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 nas RFCs 1034 e 4592, ou de qualquer outro método ou tecnologia para a síntese de Registros de recursos do DNS ou que use o redirecionamento dentro do DNS pelo Registro. Quando consultados por 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 na RFC 1035 e RFCs relacionadas. Esta disposição se aplica a todos os arquivos da zona de DNS em todos os níveis na árvore do DNS, para 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. Continuidade do registro

3.1. Alta disponibilidade. O Operador de registro realizará suas operações usando servidores de rede redundantes e variados geograficamente (inclusive a redundância em nível de rede, a redundância em nível de extremidade do nó e a implementação de um esquema de balanceamento de 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 fornecerá 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. Atenuação de abusos

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. Gerenciamento de ocorrências 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é 120 dias consecutivos, no mínimo, a partir da data de vigência deste contrato. O operador de registro poderá atribuir nomes (sujeito à subseção 6.2) durante esse 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 do TLD de Registro, exceto de acordo com uma Avaliação de ocorrência de colisões de nomes fornecida pela ICANN em relação ao TLD de registro. O Operador de registro (A) implementará as medidas de atenuaçã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 de ativação de nomes; e (B) o Operador de registro bloquear todos os nomes de domínio de segundo nível identificados pela ICANN e estabelecidos em

<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 do 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 programa de novos gTLD (NGPC) da Diretoria da ICANN em 7 de outubro de 2013, conforme encontrado em

<xxxx://xxx.xxxxx.xxx/xx/xxxxxx/xxxxx/xxxxxxxxx/xxxxxxxxxxx-x ew-gtld-annex-1-07oct13-en.pdf>.

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

6.3.1 Durante os primeiros dois anos após 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.

SPECIFICATION 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") detalhados nesta Especificação. Além destes RPMs, o Operador de registro pode desenvolver e implementar outros RPMs que desestimulem ou impeçam o registro de nomes de domínio que infrinjam ou violem os direitos legais de outra parte. O Operador de registro incluirá todos os RPMs exigidos por esta Especificação 7 e quaisquer outros RPMs desenvolvidos e implementados pelo Operador de registro no Contrato entre 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ções de marcas a partir da data deste documento, conforme publicado em xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/xxxx-xxxxxxxxxxxx (os "Requisitos do centro de informações de marcas"), 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ções de marcas designado pela ICANN ou no lugar deste. No caso de conflito entre os termos e condições deste Contrato e os Requisitos do Centro de informações de marcas, os termos e condições do presente Contrato devem prevalecer. O Operador de registro deve celebrar um Contrato entre registro e registrador vinculativo e aplicável com pelo menos um registrador

credenciado pela ICANN autorizando esse(s) registrador(es) a registrar nomes de domínio no TLD da seguinte forma:

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

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

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

Nenhuma cláusula da Especificação 7 limitará ou isentará qualquer outra obrigação ou requisito deste Contrato aplicável ao Operador de registro, inclusive a Seção 2.9(a) e a Especificação 9.

2. Mecanismos de resolução de disputas. O Operador de registro cumprirá os seguintes mecanismos de resolução de disputas, pois podem ser revisados esporadicamente:

a. o Procedimento de resolução de disputas pós-autorizaçã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 http://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.

SPECIFICATION 8 INSTRUMENTO DE OPERAÇÕES CONTÍNUAS.

1. O Instrumento de operações contínuas deve (a) fornecer recursos financeiros

suficientes para garantir a continuidade da operação das funções críticas de registro relacionadas ao TLD, estabelecidas na Seção 6 da Especificação 10 do presente Contrato por um período de 3 (três) anos a partir da rescisão do presente Contrato ou antes do quinto ano a contar da data de vigência, ou por um período de um (1) ano após a rescisão deste Contrato, após o quinto ano da data de vigência, mas antes de seis anos da data de vigência ou nessa data, e (b) estar na forma de (i) uma carta de crédito de garantia irrevogável, ou (ii) depósito judicial em dinheiro irrevogável, cada um de acordo com os requisitos estabelecidos no item 50(b) do Anexo ao Módulo 2 - Perguntas e critérios de avaliação - do 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 manter a ICANN como um terceiro beneficiário deste. Se o Operador de registro optar por obter uma carta de crédito de garantia irrevogável, mas o prazo exigido acima não for viável, o Operador de registro poderá obter uma carta de crédito com o prazo de um ano e uma “condição permanente", que prevê extensões anuais, sem alterações, para um número indefinido de períodos adicionais até que o banco emissor informe à ICANN sobre seu vencimento final ou até que a ICANN libere a carta de crédito, 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 do sexto (6º) ano 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 do sexto ano a contar da Data de vigência, o Operador de registro deverá imediatamente (i) notificar a ICANN sobre tal vencimento ou rescisão e os motivos deste e (ii) providenciar um instrumento alternativo que forneça os recursos financeiros suficientes para garantir a continuidade da operação das funções críticas de registro relacionadas ao TLD, estabelecidas na Seção 6 da Especificação 10 do presente Contrato por um período de 3 (três) anos a partir da rescisão do presente Contrato ou antes do quinta ano a contar 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, 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 no sexto ano 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.

SPECIFICATION 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 sejam disponibilizadas a todos os registradores oportunidades comparáveis para se qualificar a tais preferências ou considerações em termos e sujeito substancialmente semelhantes a condições substancialmente semelhantes;

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

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

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

2. Se o Operador de registro ou uma Parte relacionada ao registro também atuar como prestador de serviços de registrador ou registrador-revendedor, o Operador de registro fará com que 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 fará 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 divulgar 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.

SPECIFICATION 10

ESPECIFICAÇÕES DE DESEMPENHO DO REGISTRO

1. Definições

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

1.2. Resolução adequada das 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 na RFC 5730 e RFCs relacionadas.

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

1.5. Sondas. Hosts de rede usados para realizar testes (DNS, EPP etc.) (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 que está 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 de pelo menos 95% das consultas
	RTT de resolução de DNS UDP	 500 ms de pelo menos 95% das consultas
	Tempo de atualização do DNS	 60 min. de pelo menos 95% das sondas
RDDS	Disponibilidade de RDDS	 tempo de inatividade de 864 min. ( 98%)
	RTT de consulta de RDDS	 2000 ms de pelo menos 95% das consultas
	Tempo de atualização de RDDS	 60 min. de pelo menos 95% das sondas
EPP	Disponibilidade do serviço de EPP	 tempo de inatividade de 864 min. ( 98%)
	RTT de comando da sessão de EPP	 4000 ms de pelo menos 90% dos comandos
	RTT do comando de consulta de EPP	 2000 ms de pelo menos 90% dos comandos
	RTT do comando de transformação de EPP	 4000 ms de pelo menos 90% dos comandos

O Operador de registro é incentivado a fazer a manutenção de diversos serviços em horas e datas que estatisticamente apresentem o menor tráfego de cada serviço. No entanto, observe que não há previsão para interrupções planejadas ou períodos semelhantes de serviço indisponível ou lento; qualquer tempo de inatividade, seja para manutenção ou devido a falhas do sistema, será observado apenas como tempo de inatividade e contabilizado para fins de 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 autorizados 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 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 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 a “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 as DNSSEC forem oferecidas 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 que corresponde ao “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 do 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, inclusive a recepção da resposta de HTTP para apenas 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ão 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 como 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 de medição dos parâmetros de RDDS serão posicionadas dentro das redes com a maioria de usuários entre as diversas 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 de 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 da RFC 5730 do EPP. 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 da RFC 5730 do EPP. 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 da RFC 5730 do EPP. 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” de um dos servidores de 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 de 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 como 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 de medição dos parâmetros de EPP serão posicionadas dentro dos pontos de acesso dos registradores com a Internet ou próximo a eles; deve ser tomado o devido cuidado para

que as sondas não sejam instaladas por trás de links com atraso de alta 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 do TLD, conforme especificado na Seção 2.13 deste Contrato.

Função crítica	Limites de emergência
Serviço de DNS	tempo de inatividade total de 4 horas/semana
Resolução adequada das DNSSEC	tempo de inatividade total de 4 horas/semana
EPP	tempo de inatividade total de 24 horas/semana
RDDS	tempo de inatividade total de 24 horas/semana
Depósito de dados	Atender a qualquer um dos critérios para a liberação de depósitos descritos na Especificação 2, Parte B, Seção 66.2 à Seção 6.6.

7. Encaminhamento de emergência

O encaminhamento é 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 encaminhamento e as investigações cooperativas posteriores não implicam na falha de um serviço monitorado nos próprios requisitos de desempenho.

Os encaminhamentos 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 encaminhamentos, antes de qualquer processamento de um encaminhamento de emergência por todas as partes relacionadas, e mantidos atualizados em todos os momentos.

7.1. Encaminhamento 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 encaminhamento de emergência com o respectivo Operador de registro. Um encaminhamento 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 encaminhado, inclusive 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,

Document Metadata

Table of Contents

CONTRATO DE REGISTRO

Document Metadata