Política de Informações Adicionais de RDDS (Serviços de Diretório de Dados de Registro)

As versões em inglês de todos os conteúdos e documentos traduzidos são as versões oficiais, e as traduções para outros idiomas são apenas para fins informativos.

As palavras-chave “DEVE(M)”, “NÃO DEVE(M)”, “EXIGIDO(A, OS, AS)”, “DEVERÁ(ÃO)”, “NÃO DEVERÁ(ÃO)”, “PRECISA(M)”, “NÃO PRECISA(M)”, “RECOMENDADO(A, OS, AS)”, “NÃO RECOMENDADO(A, OS, AS)”, “PODERÁ(ÃO)” e “OPCIONAL(AIS)” neste documento deverão ser interpretadas conforme descrito na BCP 14 [RFC2119] [RFC8174] quando, e somente quando, elas estiverem em letras maiúsculas, conforme exibidas neste parágrafo.

A seção 1 desta política detalha os requisitos independentes de tecnologia que se aplicam a todos os Serviços de Diretório de Dados de Registro.

A seção 2 desta política detalha os requisitos de implementação referentes apenas ao WHOIS (disponível pela porta 43) e aos serviços de diretório do WHOIS baseados na web.

Os registradores credenciados pela ICANN e os registros de gTLDs (generic Top-Level Domains, Domínios Genéricos de Primeiro Nível) são obrigados, de acordo com seus respectivos contratos com a ICANN, a fornecer o acesso baseado em consultas a certos Dados de Registro. Para ajudar os usuários do RDDS a identificar melhor o registrador patrocinador de um registro e compreender os códigos de status usados por registros e registradores, esta Política de Informações Adicionais de RDDS ainda requer que os registradores e os registros incluam em suas informações de saída de RDDS o seguinte:

1. Os Operadores de Registro e Registradores DEVERÃO implementar os requisitos a seguir.

   1.1 incluir no resultado do RDDS a seguinte mensagem: “For more information on domain status codes, please visit https://icann.org/epp” (Para saber mais sobre códigos de status de domínios, acesse https://icann.org/epp)*

   * O formato mais longo do link acima incluído anteriormente na seção 1(c), ou seja, https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-en, também está em conformidade com esta Política.

   1.2 Os Registros DEVERÃO usar o número de GURID (Globally Unique Registrar Identification, ID Global Exclusivo de Registrador) emitido pela ICANN, também conhecido como ID IANA, em seus resultados do RDDS.

2. Os Operadores de Registro e Registradores DEVERÃO implementar os requisitos a seguir para o WHOIS (disponível pela porta 43) e serviços de diretório do WHOIS baseados na web.

   2.1 o(s) status DEVERÁ(ÃO) ser exibidos usando seus respectivos códigos de status do EPP;

   2.2 um link ou URL DEVERÁ ser exibido ao lado de cada código de status de EPP que direcionar a uma página da web da ICANN com uma descrição e definição para o respectivo código de status do EPP. Uma lista de URLs está disponível em https://www.icann.org/resources/pages/epp-status-codes-list-2014-06-18-en;

   2.3 os Registradores NÃO DEVERÃO remover os links e a mensagem mencionados acima ao fornecer dados de WHOIS de serviços próprios ou do serviço de WHOIS de outros registradores ou registros.

Observações: A AWIP (Additional WHOIS Information Policy, Política de Informações Adicionais de WHOIS), renomeada para ARIP (Additional RDDS Information Policy, Política de Informações Adicionais de RDDS), foi adotada pela ICANN como uma política consensual em 6 de maio de 2012. A data de início de vigência dessa política é 31 de janeiro de 2016. Todos os registradores credenciados pela ICANN e os registros de gTLDs deverão estar em conformidade com a ARIP com relação aos registros que patrocinam em todos os gTLDs administrados por eles ou para os quais são credenciados a partir da data de início de vigência.

O objetivo desta política é esclarecer o significado dos códigos de status de EPP nos dados do RDDS e solicitar a identificação consistente de registradores por seus GURIDs no RDDS.

Histórico: Em 24 de junho de 2009, o Conselho da GNSO iniciou um PDP (Policy Development Process, Processo de Desenvolvimento de Políticas) relacionado à IRTP (Inter-Registrar Transfer Policy, Política de Transferência entre Registradores) (http://gnso.icann.org/en/council/resolutions#200906 – resolução 20090624-2) e o grupo de trabalho do PDP (Grupo de Trabalho IRTP B) enviou seu Relatório Final em 30 de maio de 2011 com um conjunto de recomendações (http://gnso.icann.org/issues/transfers/irtp-b-final-report-30may11-en.pdf [PDF, 971 KB]), incluindo a Recomendação nº 8: padronizar e esclarecer as mensagens de status do RDDS referentes ao status “Registrar Lock” (Bloqueado pelo Registrador). Em 22 de junho de 2011, o Conselho da GNSO resolveu que antes de considerar a aprovação da recomendação referente à padronização e ao esclarecimento das mensagens de status do RDDS com relação ao status “Registrar Lock” (Bloqueado pelo Registrador), o Conselho da GNSO solicitaria que a equipe da ICANN fornecesse uma proposta elaborada para garantir uma abordagem tecnicamente viável que pudesse ser desenvolvida para atender a essa recomendação. Em resposta a essa solicitação, a equipe da ICANN desenvolveu uma proposta em consulta com o grupo de trabalho. Essa proposta foi publicada para comentários públicos e subsequentemente adotada pelo Conselho da GNSO em 16 de fevereiro de 2012 (http://gnso.icann.org/en/council/resolutions#20120216-1). Após outro fórum para comentários públicos sobre a recomendação e a proposta (http://www.icann.org/en/news/public-comment/irtp-b-rec8-21feb12-en.htm), elas foram adotadas pela Diretoria da ICANN em 6 de maio de 2012. (https://www.icann.org/en/groups/board/documents/resolutions-06may12-en.htm#1.5)

Um grupo de trabalho adicional da GNSO (Grupo de Trabalho IRTP C) foi formado em 22 de setembro de 2011 para considerar três questões relacionadas à IRTP, inclusive se o processo poderia ser aperfeiçoado por um requisito de que os registros usassem IDs IANA para os registradores, em vez de IDs particulares (https://community.icann.org/display/gnsoirtppdpwg/3.+WG+Charter). O grupo de trabalho emitiu um relatório inicial que foi objeto de um comentário público e, posteriormente, um relatório final, adotado pelo Conselho da GNSO em 17 de outubro de 2012. Após outro fórum para comentários públicos, a Diretoria da ICANN adotou as recomendações do relatório final em 20 de dezembro de 2012 (http://www.icann.org/en/groups/board/documents/minutes-20dec12-en.htm#2.a).