Skip to main content
Resources

Política de Avaliação de Serviços de Registros

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

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

Página do processo da RSEP

(Publicada em 25 de julho de 2006, Data de Início da Vigência: 15 de agosto de 2006)

1. Definições

1.1 Serviços de Registros são definidos da seguinte maneira:

  1. serviços que são: (i) operações do registro essenciais para as seguintes tarefas: o recebimento de dados de registradores referentes aos registros de nomes de domínio e servidores de nomes; o provisionamento aos registradores de informações de status referentes aos servidores de zonas do TLD; a disseminação de arquivos de zona de TLD; a operação dos servidores de zona de registro; e a disseminação de contato e outras informações relacionadas a registros de servidores de nome de domínio no TLD, conforme exigido pelo Contrato de Registro; e (ii) fornecidos pelo Operador de Registro a partir da Data de Início da Vigência constante no Contrato de Registro, conforme o caso;
  2. outros produtos ou serviços que o Operador de Registro seja obrigado a fornecer devido ao estabelecimento de uma Política de Consenso (conforme definido acima);
  3. quaisquer outros produtos ou serviços que somente um operador de registro seja capaz de fornecer, em virtude de sua designação como o operador de registro; e
  4. alterações significativas a qualquer Serviço de Registro dentro do escopo de (A), (B) ou (C) acima. (Essa definição foi retirada do Contrato .NET, conforme especificado pela Diretoria da ICANN em 8 de novembro de 2005, http://www.icann.org/minutes/resolutions-08nov05.htm.)

1.2 Segurança - Um efeito na segurança pelo Serviço de Registro proposto significa (A) a divulgação, a alteração, a inserção ou a destruição não autorizadas de Dados de Registro, ou (B) o acesso ou a divulgação não autorizados de informações ou de recursos na Internet por sistemas que funcionam de acordo com todos os padrões aplicáveis. (Essa definição foi retirada da Recomendação da GNSO, localizada em http://gnso.icann.org/issues/registry-services/final-rpt-registry-approval-10july05.htm#5.)

1.3 Estabilidade - Um efeito na estabilidade significa que o Serviço de Registro proposto (A) não está em conformidade com os padrões relevantes aplicáveis oficiais e publicados por um órgão bem estabelecido, reconhecido e oficial responsável pela elaboração de padrões, como o Standards-Track ou as RFCs de práticas recomendadas atuais da IETF, ou (B) cria uma condição que afeta negativamente a produtividade, o tempo de resposta, a consistência ou a coerência de respostas aos servidores da Internet ou aos sistemas finais, operando de acordo com os padrões relevantes aplicáveis oficiais e publicados por um órgão bem estabelecido, reconhecido e oficial responsável pela elaboração de padrões, como o Standards-Track ou as RFCs de práticas recomendadas atuais, e contando com as informações de autorização ou os serviços de provisionamento do Operador de Registro. (Essa definição foi retirada da Recomendação da GNSO, localizada em http://gnso.icann.org/issues/registry-services/final-rpt-registry-approval-10july05.htm#5.)

1.4 Painel de Avaliação Técnica dos Serviços de Registros - O Painel de Avaliação Técnica dos Serviços de Registros será composto por um total de 20 pessoas, especialistas no projeto, no gerenciamento e na implementação dos sistemas e padrões/protocolos complexos utilizados na infraestrutura da Internet e no DNS (o "Painel de Avaliação Técnica dos Serviços de Registros"). Os membros do Painel de Avaliação Técnica dos Serviços de Registros serão selecionados por seu Presidente. O Presidente do Painel de Avaliação Técnica dos Serviços de Registros será uma pessoa aceita pela ICANN e pelo grupo constituinte de registros das organizações de apoio então responsáveis pelas políticas de registro de domínio de primeiro nível. Todos os membros do Painel de Avaliação Técnica dos Serviços de Registros e o Presidente firmarão um acordo estabelecendo que eles considerarão as questões apresentadas ao painel de maneira neutra e em conformidade com as definições de Segurança e Estabilidade. Para cada assunto encaminhado ao Painel de Avaliação Técnica dos Serviços de Registros, o Presidente selecionará até cinco membros do Painel de Avaliação Técnica dos Serviços de Registros para avaliar o assunto encaminhado, sendo que nenhum desses membros poderá apresentar conflitos de interesses de natureza competitiva, financeira ou legal, e prestando a devida consideração aos problemas técnicos específicos relatados. (Essa definição foi retirada da Recomendação da GNSO, localizada em http://gnso.icann.org/issues/registry-services/final-rpt-registry-approval-10july05.htm#5.)

2. Processo para a Consideração de Serviços de Registros Propostos

2.1 O Operador de Registro ou a Organização Responsável considerará o novo serviço de registro

Um operador de registro ou uma organização responsável poderá, a qualquer momento, decidir alterar a arquitetura ou a operação de um serviço de registro de TLD existente ou lançar um novo serviço de registro de TLD (consulte a Introdução das Notas de Implementação da RSEP).

2.2 Determinar se a alteração requer uma revisão da ICANN

Um operador de registro de gTLD ou uma organização responsável, em consulta com a ICANN, conforme descrito na Seção 2.4, determinará se uma alteração em um serviço exigirá aprovação com base no contrato entre a ICANN e o operador de registro (consulte a Introdução das Notas de Implementação da RSEP).

2.3 Fornecer à ICANN as informações sobre a alteração proposta

A Política incentiva que os proponentes de um novo serviço de registro colaborem com a ICANN antes de enviar uma solicitação por novos serviços de registro. O objetivo da Política de Avaliação de Serviços de Registros e do processo de aprovação é criar um ambiente que incentive os operadores de registro de gTLDs a discutir com a ICANN sobre quaisquer alterações que possam afetar terceiros antes que elas sejam efetivadas.

O operador de registro de gTLD ou a organização responsável deverá fornecer à ICANN informações suficientes sobre uma alteração, de modo que a ICANN possa avaliar se a alteração estará sujeita a um processo de aprovação. As informações devem incluir uma descrição técnica da alteração como ela seria percebida pelos usuários externos, bem como uma avaliação do impacto que ela teria nos usuários externos. Se o operador de registro ou a organização responsável tiver buscado feedback de partes externas e da comunidade, os detalhes do processo e os resultados desse feedback devem ser incluídos. Nessa etapa do processo, as informações devem ser consideradas pela equipe da ICANN como confidenciais (consulte as etapas 1 e 2 das Notas de Implementação da RSEP).

2.4 Período de determinação preliminar

Após uma notificação por escrito do Operador de Registro para a ICANN, informando que o Operador de Registro poderá fazer uma alteração em um Serviço de Registro dentro do escopo do parágrafo anterior:

  1. A ICANN terá 15 dias consecutivos para fazer uma "determinação preliminar" sobre se um Serviço de Registro requer maior consideração pela ICANN, caso determine de maneira razoável que esse Serviço de Registro: (i) pode resultar em problemas significativos de Segurança ou Estabilidade ou (ii) pode resultar em problemas significativos de concorrência.
  2. O Operador de Registro deverá fornecer informações suficientes no momento da notificação para a ICANN de que ele poderá implementar o Serviço de Registro proposto a fim de permitir que a ICANN possa fazer uma "determinação preliminar" bem informada. As informações fornecidas pelo Operador de Registro e marcadas como "CONFIDENCIAL" serão tratadas como confidenciais pela ICANN. O Operador de Registro não designará como "CONFIDENCIAL" as informações necessárias para descrever a finalidade do Serviço de Registro proposto e o efeito que ele terá nos usuários do DNS.
  3. A ICANN poderá buscar o conselho de especialistas durante o período de determinação preliminar (com entidades ou pessoas sujeitas a contratos de confidencialidade) sobre as implicações na concorrência, na Segurança e na Estabilidade resultantes do Serviço de Registro para que possa fazer sua "determinação preliminar". Na medida em que a ICANN determinar a divulgação de informações confidenciais para esses especialistas, ela fornecerá notificação ao Operador do Registro quanto à identidade do(s) especialista(s) e as informações que pretende transmitir. Para implicações de Segurança e Estabilidade, a ICANN poderá selecionar um especialista do Painel de Avaliação Técnica de Serviços de Registros, descrito em 2.4 (F) abaixo.
  4. Se a ICANN determinar durante o período de 15 dias consecutivos de "determinação preliminar" que o Serviço de Registro proposto não resultará em problemas significativos de Segurança ou Estabilidade (conforme definido nas Seções 1.3 e 1.4) e nem de concorrência, o Operador de Registro poderá implementá-lo livremente mediante essa determinação.

Se a implementação do serviço proposto exigir uma alteração significativa em um Contrato de Registro, a determinação preliminar será encaminhada para a Diretoria da ICANN (consulte a Etapa 5 das Notas de Implementação da RSEP).

2.5 Problemas de concorrência

Se a ICANN determinar de maneira razoável durante o período de 15 dias consecutivos da "determinação preliminar" que o Serviço de Registro poderá resultar em problemas significativos de concorrência, a ICANN deverá encaminhar o problema à(s) autoridade(s) de concorrência governamental(ais) apropriada(s) com jurisdição sobre a questão dentro de cinco dias úteis depois de fazer a determinação, ou dois dias úteis após o término do período de 15 dias, o que ocorrer antes, com notificação ao Operador de Registro.

Essa comunicação de encaminhamento deverá ser publicada no site da ICANN na data da transmissão.

Após esse encaminhamento, a ICANN não terá mais responsabilidade, e o Operador de Registro não terá mais compromisso com a ICANN, no que diz respeito a quaisquer problemas de concorrência relacionados ao Serviço de Registro. Se esse encaminhamento for efetivado, o Operador de Registro não implementará o Serviço de Registro até 45 dias consecutivos após o encaminhamento, a menos que a questão seja esclarecida antes disso pelo órgão governamental responsável pela concorrência ao qual foi encaminhada (consulte as Etapas 4 a 6 das Notas de Implementação da RSEP).

2.6 Problemas de Segurança e Estabilidade

Se a ICANN determinar de maneira razoável durante o período de 15 dias consecutivos da "determinação preliminar" que o Serviço de Registro proposto poderá resultar em problemas significativos de Estabilidade ou Segurança (conforme definido nas Seções 1.3 e 1.4), a ICANN encaminhará a proposta ao Painel de Avaliação Técnica dos Serviços de Registros (conforme definido na Seção 1.5) em até cinco dias úteis a partir de sua determinação, ou dois dias úteis após o término desse período de 15 dias, o que ocorrer antes, e solicitará simultaneamente comentários públicos sobre a proposta.

O Painel de Avaliação Técnica de Serviços de Registros terá 45 dias consecutivos a partir do encaminhamento para preparar um relatório por escrito referente ao efeito do Serviço de Registro proposto na Segurança ou na Estabilidade (conforme definido nas Seções 1.2 e 1.3). Esse relatório (juntamente com um resumo de quaisquer comentários públicos) será encaminhado à Diretoria da ICANN. O relatório incluirá as opiniões do Painel de Avaliação Técnica de Serviços de Registros, incluindo, entre outros, uma declaração detalhada da análise, dos motivos e das informações nos quais o painel se baseou para chegar às suas conclusões, juntamente com a resposta a quaisquer questões específicas incluídas no encaminhamento da equipe da ICANN. Após o encaminhamento da ICANN para o Painel de Avaliação Técnica dos Serviços de Registros, o Operador de Registro poderá enviar informações ou análises adicionais relacionadas ao seu efeito provável sobre a segurança ou a estabilidade do serviço de registro.

Depois de avaliar o Serviço de Registro proposto, o Painel de Avaliação Técnica dos Serviços de Registros emitirá um relatório sobre a probabilidade e a importância dos efeitos do Serviço de Registro proposto na Segurança ou na Estabilidade, inclusive se o Serviço de Registro proposto cria um risco razoável de efeito negativo significativo na Segurança ou na Estabilidade (consulte as Etapas 4 a 6 das Notas de Implementação da RSEP).

2.7 Decisão da Diretoria da ICANN

Após o recebimento do relatório do Painel de Avaliação Técnica dos Serviços de Registros, que será publicado (com as alterações textuais apropriadas por motivo de confidencialidade após consulta junto ao Operador de Registro) e disponibilizado para comentários públicos, a Diretoria da ICANN terá 30 dias consecutivos para tomar uma decisão. Se a Diretoria da ICANN determinar, de maneira lógica, que o Serviço de Registro proposto cria um risco razoável de efeito negativo significativo sobre a Estabilidade ou a Segurança, o Operador de Registro não deverá oferecer o Serviço de Registro proposto.

Uma versão completa do relatório do Painel de Avaliação Técnica dos Serviços de Registros será fornecida ao Operador de Registro após a publicação do relatório. O Operador de Registro poderá responder ao relatório do Painel de Avaliação Técnica dos Serviços de Registros ou enviar à Diretoria da ICANN informações ou análises adicionais relacionadas ao efeito provável do Serviço de Registro na Segurança ou na Estabilidade (consulte a Etapa 5 das Notas de Implementação da RSEP).

3. Reconsideração

Os operadores de registro de gTLDs ou as organizações responsáveis pelo registro afetadas por uma decisão da ICANN sobre um novo serviço de registro proposto poderão usar os processos de reconsideração existentes no estatuto da ICANN.

A fonte autoritativa para obter informações sobre o processo de Reconsideração é o estatuto da ICANN (consulte o Artigo IV: Seção 2 http://www.icann.org/general/bylaws.htm#IV). A reconsideração se aplica às ações da equipe que contradizem uma política da ICANN, ou a uma ação da Diretoria da ICANN sem a consideração de informações importantes. As informações sobre processos anteriores de reconsideração estão disponíveis em http://www.icann.org/committees/reconsideration.

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."