Skip to main content
Resources

Notas de Implementação da RSEP

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.

Em vigor a partir de 17 de junho de 2019

Depois de vários meses de debates, o Grupo de Discussão para Melhorias da RSEP do RySG e a organização da ICANN chegaram a um acordo sobre um conjunto de melhorias operacionais para aumentar a eficiência e a previsibilidade do processo de adesão à política. Esta versão de 2019 das notas de implementação da RSEP apresenta as alterações definidas, em vigor a partir de 17 de junho de 2019.

Clique aqui para voltar para a página do Processo de RSEP.

Introdução

Em 8 de novembro de 2005 a diretoria da ICANN orientou a implementação do procedimento recomendado pela GNSO para a consideração de solicitações de novos serviços de registros, que se baseará nas disposições do Contrato de Registro .NET em relação às definições de serviços de registros. Estas notas de implementação são um resumo do processo da Política de Avaliação de Serviços de Registros (RSEP), com o objetivo de fornecer informações gerais sobre a implementação da política pela organização da ICANN. A organização da ICANN pode analisar a eficácia desta implementação periodicamente com base nos comentários dos operadores de registro e grupos constituintes relevantes.

Em 2019, um grupo de discussão do Grupo Interesse de Registros (RySG) colaborou com a organização da ICANN para atualizar as notas de implementação sem alterar a política em si. O objetivo destas notas de implementação é facilitar a compreensão do processo da RSEP, aumentar a previsibilidade e garantir o alinhamento contínuo com a política de base.

Um operador de registro de gTLD pode enviar uma solicitação de RSEP para a organização da ICANN para adicionar um serviço de registro proposto, modificar um serviço de registro existente ou remover um serviço de registro. Se a organização da ICANN definir que um serviço proposto em uma solicitação da RSEP não se qualifica como serviço de registro conforme definido no Contrato de Registro, a organização da ICANN notificará o operador de registro e encerrará a solicitação. O operador de registro pode retirar a solicitação a qualquer momento.

Devido às diferenças entre a Política Consensual da RSEP e os termos contratuais em determinados Contratos de Registro de gTLDs antigos, a organização da ICANN criou uma reconciliação entre a Política Consensual e os termos contratuais em Contratos de gTLD contendo o processo de avaliação. A reconciliação tem como objetivo demonstrar que a implementação da Política Consensual resulta em um processo que não é inconsistente com tal política nem com os termos de qualquer Contrato de gTLD atual. A organização da ICANN levará a reconciliação em conta para qualquer solicitação relacionada à RSEP no caso de Contratos de Registro com essas diferenças.

Todas as referências a dias serão definidas como dias corridos, salvo indicação em contrário.

Etapa 1 – Envio

Os operadores de registro podem enviar solicitações de RSEP para a organização da ICANN usando o formulário de solicitação adequado conforme os critérios abaixo:

  1. Formulário de solicitação padrão da RSEP:no caso de solicitações da RSEP para a adição de um serviço de registro proposto, a remoção de um serviço de registro existente ou a modificação material de um serviço de registro existente, os operadores de registro devem responder a um conjunto de perguntas padrão com o objetivo de fornecer à organização da ICANN informações suficientes para avaliar a solicitação. Os operadores de registro podem designar as informações enviadas na solicitação da RSEP como "CONFIDENCIAIS", exceto 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.

    Para cumprir os cronogramas da Política e aumentar a previsibilidade para os operadores de registro, a Política e a organização da ICANN recomendam que os operadores de registro consultem a organização da ICANN antes de enviar o formulário padrão de solicitação da RSEP. A ideia dessa etapa não é atrapalhar o operador de registro, mas sim ajudar a garantir que as informações necessárias sejam obtidas antes da consideração da solicitação da RSEP. Essa também é uma oportunidade de discutir se a solicitação se qualifica dentro da Política, observar e esclarecer dúvidas que podem surgir na análise formal da solicitação, e chegar a um acordo sobre o texto de autorização apropriado o mais rápido possível.

  2. Formulário de solicitação simplificado da RSEP: no caso de alguns serviços conhecidos(serviços analisados várias vezes pela organização da ICANN em relação à segurança e à estabilidade, que não tiveram problemas significativos de segurança nem estabilidade, já foram aprovados e têm um modelo de aditamento publicado disponível), o operador de registro preenche um formulário de solicitação simplificado e confirma o uso de um modelo de aditamento padrão sem modificações Essa etapa pode reduzir o tempo do envio até a autorização de uma solicitação da RSEP para serviços conhecidos.

Etapa 2 – Verificação de integridade pela ICANN

As solicitações da RSEP não são publicadas durante a verificação de integridade. Além disso, todas as interações entre a organização da ICANN e o operador de registro em relação a essa solicitação são confidenciais. Quando uma solicitação é enviada, a organização da ICANN analisa sua integridade, o que deve levar no máximo 15 dias. As solicitações devem atender aos seguintes critérios para avançar para a etapa 3 - Análise da ICANN:

  1. Informações suficientes:a solicitação deve incluir informações suficientes para permitir que a organização da ICANN tome uma decisão preliminar bem embasada durante a Análise da ICANN. Para ser consideradas completas, as solicitações padrão da RSEP devem incluir respostas significativas a todas as perguntas relevantes, incluindo uma descrição completa do serviço proposto, uma avaliação do impacto sobre os usuários externos, uma lista e a explicação das cláusulas contratuais impactadas pelo novo serviço (se houver), o texto do aditamento proposto (se for o caso), comentários de partes externas e da comunidade (se houver) e outros documentos de apoio que possam ser úteis para a decisão preliminar.

  2. Documento de autorização:ao final da Etapa 2, a organização da ICANN e o operador de registro devem chegar a um acordo quanto ao tipo de documento de autorização e, no caso de aditamentos ao Contrato de Registro (RA), ao texto de tal aditamento, antes que a solicitação avance para a Análise da ICANN. Alguns motivos pelos quais talvez a organização da ICANN não possa concordar com um documento de autorização incluem conflitos entre o serviço proposto e a política consensual da ICANN ou as orientações da Diretoria da ICANN.

    Tipos de documento de autorização e critérios:

    • Emenda ao RA: usada quando o serviço proposto (i) contradiz as cláusulas existentes do RA ou (ii) não está contemplado no RA e, portanto, precisa ser adicionado ao Anexo A do RA e/ou como um aditamento/apêndice apropriado.

    • Carta de liberdade de implementação:usada quando o serviço proposto já está contemplado no RA e não contradiz as cláusulas contratuais.

A organização da ICANN pode identificar que são necessárias mais informações sobre a solicitação da RSEP para que a organização da ICANN faça sua avaliação. Essas informações devem ser incluídas na solicitação publicada. Nesse caso, a organização da ICANN poderá consultar o operador de registro e/ou pedir para ele enviar novamente a solicitação com essas informações adicionais, o que pode aumentar a duração da Etapa 2 - Verificação de integridade. A organização da ICANN trabalhará com o operador de registro de boa fé durante esse processo.

2A - Pedido de prosseguimento

Se as partes concordarem que o critério 1 da Etapa 2 foi atendido, mas o operador de registro e a organização da ICANN não chegarem a um acordo sobre o tipo de documento de autorização e/ou o texto do aditamento, o operador de registro pode enviar um pedido de prosseguimento para a Etapa 3 - Análise da ICANN antes da finalização do documento de autorização. A organização da ICANN considerará todos os pedidos de prosseguimento em tempo hábil e avaliará de boa fé o andamento das negociações.

A organização da ICANN pode tomar uma das medidas a seguir caso um pedido de prosseguimento seja enviado:

  • Se as negociações estiverem perto da conclusão, a organização da ICANN poderá atender ao pedido de prosseguimento, e a solicitação da RSEP passará para a Etapa 3 – Análise da ICANN. Nesse momento, a solicitação da RSEP será publicada. As duas partes continuarão as negociações durante a Etapa 3 com o objetivo de chegar a um acordo até o final da análise da ICANN.

  • Se as negociações estiverem longe de uma conclusão, a organização da ICANN poderá solicitar mais negociações, com escalonamento para a liderança da organização. Tal escalonamento acontecerá antes que a solicitação da RSEP passe para a Etapa 3. Caso atenda ao pedido de prosseguimento depois do escalonamento, a organização da ICANN poderá publicar o documento de autorização proposto para comentários públicos se o serviço de registro proposto definir novos precedentes ou tiver efeitos significativos sobre a ICANN, terceiros ou o DNS (Sistema de Nomes de Domínio). Os comentários públicos aconteceriam depois da Etapa 3 – Análise da ICANN.

  • Se considerar que o operador de registro não negociou de boa fé, a organização da ICANN poderá rejeitar o pedido de prosseguimento.

Etapa 3 – Análise da ICANN

Quando considerar que uma solicitação está completa ou atender a um pedido de prosseguimento na Etapa 2, a organização da ICANN começará o processo de análise de 15 dias e publicará o serviço de registro proposto.

Durante a Análise da ICANN, será definido de forma preliminar se o serviço de registro proposto traz problemas significativos de segurança, estabilidade ou concorrência. A organização da ICANN seguirá as orientações publicadas sobre a determinação preliminar de problemas de concorrência, e poderá pedir conselhos de especialistas individuais ou membros de entidades, sujeitos aos contratos de confidencialidade, sobre as implicações do serviço de registro proposto para a segurança, a estabilidade e a concorrência. Esses especialistas podem ser membros do Painel de Avaliação Técnica de Serviços de Registros (RSTEP). Essa avaliação terá no máximo 15 dias de duração, conforme exigido pela Política.

Ao final da Etapa 3 – Análise da ICANN, a organização da ICANN notificará o operador de registro solicitante sobre a determinação preliminar relacionada ao serviço de registro proposto.

Etapa 4 - Aprovação ou Encaminhamento

A determinação preliminar da Etapa 3 terá um dos seguintes resultados:

  1. Aprovação da solicitação da RSEP;

  2. Encaminhamento para o Painel de Avaliação Técnica dos Serviços de Registros (RSTEP);

  3. Encaminhamento para o órgão governamental responsável pela concorrência; ou

  4. Encaminhamento para o RSTEP e o órgão governamental responsável pela concorrência.

Se a determinação preliminar tiver os resultados 2-4, o operador de registro será notificado e deverá confirmar se pretende continuar com o processo de análise ou retirar a solicitação da RSEP. Se necessário, o operador de registro poderá consultar a organização da ICANN em relação ao resultado.

Resultado

Determinação

Próximas etapas

(1) Aprovação

Nenhum problema aparente de segurança, estabilidade ou concorrência

A solicitação é considerada concluída e passará para a Etapa 6 - Autorização.

(2) Encaminhamento para o RSTEP

Poderia provocar problemas significativos de segurança ou estabilidade

Se o operador de registro confirmar que gostaria de avançar, o serviço proposto será avaliado pelo RSTEP (a lista dos membros do RSTEP foi publicada aqui). Quando uma solicitação é encaminhada para o RSTEP, o painel tem 45 dias para analisar o serviço proposto e criar um relatório sobre qualquer problema de segurança ou estabilidade. Uma versão completa do relatório final do RSTEP será fornecida ao operador de registro. Etapa 5 - São necessários comentários públicos e a consideração da ICANN

(3) Encaminhamento para o órgão governamental responsável pela concorrência

Poderia provocar problemas significativos de concorrência

Se o operador de registro confirmar que gostaria de avançar, a organização da ICANN encaminhará a questão ao órgão governamental responsável pela concorrência ou aos órgãos com jurisdição sobre o tema dentro de cinco dias úteis a partir de tal confirmação. Etapa 5 - São necessários comentários públicos e a consideração da ICANN

(4) Encaminhamento para o RSTEP e o órgão governamental responsável pela concorrência

Poderia provocar problemas significativos de segurança ou estabilidade e concorrência

Se o operador de registro confirmar que gostaria de continuar, a organização da ICANN seguirá as etapas dos resultados 2 e 3.

Etapa 5 - São necessários comentários públicos e a consideração da ICANN (se for o caso)

Um período de comentários públicos sobre o documento de autorização proposto com base na solicitação da RSEP será exigido caso o serviço de registro proposto seja encaminhado ao RSTEP ou a um órgão responsável pela concorrência na Etapa 4 ou também nas situações descritas na Etapa 2A - Pedido de prosseguimento.

  • Encaminhamento ao RSTEP: o serviço de registro proposto e o documento preliminar de autorização serão publicados para comentários públicos enquanto o RSTEP conduz sua avaliação. Quando for concluído, o relatório de avaliação do RSTEP será incluído no período de comentários públicos em andamento. Depois da conclusão do período de comentários públicos, o operador de registro poderá responder aos comentários, e o documento preliminar de autorização poderá ser atualizado.

  • Encaminhamento a um órgão responsável pela concorrência: O serviço de registro proposto e o documento de autorização serão publicados para comentários públicos durante o encaminhamento para o órgão governamental responsável pela concorrência, que pode durar 45 dias.

    • Caso tal órgão levante questões dentro dessa janela de 45 dias, o operador de registro poderá trabalhar com a organização da ICANN para resolver os problemas, e o documento preliminar de autorização poderá ser atualizado.

    • Caso o órgão responsável pela concorrência não levante questões na janela de 45 dias ou caso a solicitação seja aprovada antes, a organização da ICANN levará isso em conta para analisar os comentários públicos. 

    • Depois da conclusão do período de comentários públicos, o operador de registro poderá responder aos comentários, e a autorização preliminar poderá ser atualizada.

Depois do período de comentários públicos, a aprovação da solicitação da RSEP será considerada pela organização da ICANN ou será encaminhada para a Diretoria da ICANN.

Caso seja encaminhada para a Diretoria da ICANN, o objetivo da Diretoria será tomar uma decisão dentro de 30 dias a partir da conclusão do relatório de análise e resumo dos comentários públicos. A Diretoria da ICANN poderá decidir 1) aprovar a solicitação da RSEP, 2) recusar a solicitação da RSEP ou 3) deferir a solicitação a fim de obter mais informações.

Caso a organização ou a Diretoria da ICANN aprovem a solicitação da RSEP, o operador de registro e a organização da ICANN prosseguirão para a Etapa 6 - Autorização. Caso a Diretoria da ICANN recuse a solicitação, essa solicitação não prosseguirá.

Etapa 6 – Autorização

Assim como com a antiga implementação da Política pela ICANN, uma vez que uma solicitação da RSEP seja aprovada, e a organização da ICANN e o operador de registro cheguem a um acordo sobre o documento de autorização, a organização da ICANN iniciará o processo de autorização. Dentro de 5 dias depois do cumprimento dessas condições, a organização da ICANN vai:

  1. Emitir a carta de liberdade de implementação para o operador de registro (conforme a Etapa 2). Nesse momento, o operador de registro poderá implementar o serviço; ou

  2. Iniciar o processo de execução do aditamento do RA seguindo a Etapa 2 ou, caso sejam feitas atualizações depois dos comentários públicos, a Etapa 5. O operador de registro poderá implementar o serviço solicitado depois da execução do aditamento por ele e pela organização da ICANN.

A organização da ICANN publicará uma notificação do serviço de registro aprovado, bem como o documento de autorização, no site da RSEP e no site do Contrato de Registro específico dos TLDs.

Caso faça a implementação sem um documento de autorização, o operador de registro poderá ser considerado fora de conformidade.

Fluxo de trabalho do processo da RSEP

Confira o Fluxo de trabalho do processo da RSEP para ver uma representação geral do processo da RSEP, com referências a estas Notas de Implementação.

Arquivo

Esta página foi atualizada em junho de 2019 dentro das melhorias operacionais do processo da RSEP (consulte a publicação no blog da organização da ICANN). As notas de implementação arquivadas estão disponíveis aqui.

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."