Skip to main content
Resources

Procedimento da Comunidade para Solicitações de Alteração de gTLD

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.

Introdução

O Procedimento da Comunidade para Solicitações de Alteração de gTLD foi desenvolvido pelo Grupo de Trabalho sobre o Processo da Comunidade para a Solicitação de Alteração de gTLD (grupo de trabalho) e pela Organização ICANN com a contribuição do Grupo de Partes Interessadas de Registros e da Comunidade da ICANN. Os princípios que norteiam esse procedimento permitem que um operador de registro de gTLD da comunidade solicite modificações à Especificação 12, sem remover as Políticas de Registro da Comunidade, que ampliam ou limitam excessivamente a elegibilidade do registrante e/ou os requisitos para a seleção de nomes ou resultam em um impacto negativo evidente na Comunidade de TLDs.

A Organização ICANN disponibilizou o procedimento preliminar para Comentários Públicos em fevereiro de 2018. Depois de considerar os comentários recebidos, a Organização ICANN e o grupo de trabalho concluíram que os comentários não indicaram nenhum conflito entre o procedimento e as políticas existentes e apresentaram algumas atualizações para o procedimento. Além disso, em 26 de abril de 2018, o Conselho da GNSO concordou [PDF, 574 KB] que a "Organização ICANN deve continuar tratando o Processo da Comunidade para a Solicitação de Alteração de gTLD como um assunto de implementação". A versão publicada do Procedimento foi acordada pelo grupo de trabalho e a Organização ICANN em abril de 2018.

Procedimento

Versão: abril de 2018

Solicitação de Alteração de gTLD da Comunidade

A Solicitação de Alteração de gTLD da Comunidade (a "Solicitação") é o procedimento usado por um operador de registro de gTLDs da comunidade para solicitar a aprovação da ICANN para modificar as Políticas de Registro da Comunidade enumeradas na Especificação 12 no Contrato de Registro. De acordo com a Seção 2.19 do Contrato de Registro de gTLD da 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 de um gTLD da comunidade pode solicitar alterações que removeriam as Políticas de Registro da Comunidade, que ampliam ou limitam excessivamente a elegibilidade do registrante e/ou os requisitos para a seleção de nomes ou resultam em um impacto negativo evidente na Comunidade de TLDs.

Como em todos os procedimentos da ICANN, a ICANN poderá analisar a eficiência desse procedimento periodicamente com pareceres dos operadores de registro e dos grupos constituintes relevantes.

1. Definições

1.1 Um gTLD da Comunidade é definido como um gTLD que tem um Contrato de Registro com a ICANN que inclua a Especificação 12 com o título de seção "Políticas de Registro da Comunidade" ou "Políticas de TLD".

1.2 Uma Alteração de gTLD da Comunidade é definida como uma alteração à Especificação 12 do Contrato de Registro com a ICANN.

1.3 O TLD da Comunidade é definido pelos requisitos de elegibilidade descritos na Especificação 12 do Contrato de Registro com a ICANN.

1.4 Operador de Registro é definido como uma entidade com um Contrato de Registro para administrar um gTLD da Comunidade.

1.5 Todas as referências a dias neste procedimento são definidas como dias consecutivos.

2. Procedimento de Solicitação de Alteração de gTLD da Comunidade

2.1 O Operador de Registro envia uma Solicitação de Alteração de gTLD da Comunidade (a "Solicitação")

O Operador de Registro poderá enviar a Solicitação a qualquer momento. A Solicitação deverá ser enviada por escrito para a ICANN, acompanhada do Questionário da Solicitação de Alteração de gTLD da Comunidade (veja o Anexo A) [PDF, 38 KB] preenchido e deverá incluir a documentação de apoio para a alteração pela Comunidade do TLD (inclusive com as entidades que representarem qualquer extensão proposta da Comunidade do TLD, se aplicável), bem como pelos órgãos governamentais representantes, se aplicável.

2.2 Revisão preliminar da Solicitação pela ICANN

Após o recebimento de uma Solicitação, a ICANN verificará se ela está completa e notificará o Operador de Registro por escrito sobre quaisquer discrepâncias dentro de um prazo de cinco dias. O Operador de Registro poderá reenviar uma versão revisada da Solicitação para a ICANN a qualquer momento para ser avaliada novamente. Se todos os itens do Questionário forem preenchidos e os documentos de apoio forem fornecidos, a Solicitação será considerada como completa.

Após o término da verificação, a ICANN realizará uma revisão preliminar e preparará a Solicitação e a versão preliminar da alteração para o período de comentários públicos em até dez dias. Se, durante a revisão preliminar, a ICANN determinar que a Solicitação não está dentro do escopo deste procedimento ou levanta questões preocupantes que provavelmente resultariam na rejeição dela, a ICANN poderá identificar essas preocupações e iniciar um período de consulta com o Operador de Registro antes do período de comentários.

2.3 Período de comentários da Solicitação de Alteração

Após a revisão preliminar da Solicitação pela ICANN, a ICANN disponibilizará a Solicitação e uma versão preliminar da alteração para um período de comentários de 30 dias.

2.4 Período de resposta do Operador de Registro

Se forem apresentadas dúvidas sobre a Solicitação durante o período de comentários, a ICANN iniciará um período de consulta com o Operador de Registro e pedirá a ele uma resposta aos comentários recebidos em até 15 dias após o recebimento do pedido da ICANN. Durante esse período, a ICANN também poderá consultar o Operador de Registro para esclarecer os comentários que poderão afetar negativamente a aprovação da Solicitação e/ou responder os comentários recebidos diretamente, se necessário.

3. Revisão e Determinação da ICANN

3.1 Revisão da ICANN

A ICANN analisará se a Solicitação deverá ser aprovada ou rejeitada, e essa avaliação será baseada nos seguintes critérios:

  1. Descrição da Comunidade do TLD – A descrição dos requisitos de elegibilidade do TLD e da maneira que eles serão afetados pela Solicitação é clara?
  2. Evidência de divulgação e apoio da Comunidade do TLD – Existem evidências razoáveis que corroborem a divulgação para a Comunidade do TLD mostrando o empenho do Operador de Registro para "operar o TLD de maneira que permita à Comunidade do TLD debater e participar no desenvolvimento e na modificação das políticas e práticas do TLD"? Existem evidências razoáveis do apoio da Comunidade do TLD à Solicitação?
  3. Benefícios para a Comunidade do TLD – As respostas fornecidas nas seções 1.3 e 1.4 do Questionário da Solicitação de Alteração explicam adequadamente como a Solicitação beneficiará a Comunidade do TLD? A aprovação da alteração resultaria em prejuízos para a Comunidade do TLD?
  4. Preocupações apresentadas durante o período de comentários – Foram apresentadas preocupações significativas durante o período de comentários, que identificaram prejuízo para a Comunidade do TLD ou a comunidade da Internet? O Operador de Registro forneceu uma resposta adequada a essas preocupações? Uma resposta adequada poderá incluir evidências de apoio do Operador de Registro que (1) não haverá nenhum dano à reputação da comunidade; (2) não haverá interferências nas atividades principais da comunidade; ou (3) não haverá prejuízos econômicos à comunidade.

3.2 Determinação da ICANN

3.2.1 Aprovação

Se a ICANN determinar que a Solicitação foi aprovada, a ICANN enviará a aprovação ao Operador do Registro em até 30 dias após o encerramento do período de comentários ou a contar do envio das respostas do Operador de Registro às preocupações apresentadas durante o período de comentários. Em caso de atraso, a ICANN deverá fornecer uma explicação por escrito e informar o novo prazo.

Juntamente com a aprovação, a ICANN enviará um texto da alteração para ser executado. Se necessário, a ICANN poderá modificar a alteração, conforme adequado, para implementar a Solicitação aprovada e enviará esse texto modificado para ser revisado pelo Operador de Registro antes da execução.

3.2.2 Rejeição

Se a ICANN determinar que a Solicitação foi rejeitada, a ICANN notificará o Operador do Registro sobre a rejeição da Solicitação de Alteração e enviará uma justificativa clara com os motivos pelos quais a Solicitação foi rejeitada em até 30 dias a contar do encerramento do período de comentários ou do envio das respostas pelo Operador do Registro às preocupações apresentadas durante o período de comentários. Em caso de atraso, a ICANN deverá fornecer uma explicação por escrito e informar o novo prazo.

ANEXO A: Questionário da Solicitação de Alteração de gTLD da Comunidade [PDF, 38 KB]

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