Skip to main content

Prazo adiado: Solicitação de proposta para a análise organizacional do SSAC.

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

O prazo foi adiado para a Solicitação de proposta para a análise independente do Comitê Consultivo de Segurança e Estabilidade (SSAC). A nova data de vencimento do prazo é 21 de agosto de 2017, às 11:59 PM PDT.

A Corporação da Internet para Atribuição de Nomes e Números (ICANN) está buscando um fornecedor para fazer uma avaliação independente do Comitê Consultivo de segurança e estabilidade (SSAC).

O provedor deveria ter conhecimentos ou experiência técnica em questões de segurança da comunidade técnica da Internet e dos operadores e administradores de serviços críticos de infraestrutura do DNS; ele/ela deveria demonstrar que entende os estatutos do SSAC e seus Procedimentos Operacionais [PDF, 420 KB]; deveria demonstrar que tem conhecimentos das áreas técnicas cobertas pelos estatutos do SSAC, incluindo a segurança e integridade dos sistemas de alocação de nomes e endereços da Internet.

O objetivo desta Solicitação de Proposta (RFP, pela sigla em inglês) é identificar uma examinadora independente que faça uma avaliação geral do SSAC, incluindo, embora não se limitando:

  • Uma avaliação do estado da implementação da análise prévia do SSAC;
  • Uma avaliação sobre se o objetivo do SSAC dentro da estrutura da ICANN é contínuo;
  • Uma avaliação para definir o grau de eficácia com que o SSAC cumpre seu objetivo e se é necessário fazer alguma alteração na estrutura ou nas operações para melhorar a eficácia, e
  • Uma avaliação para definir em que medida o SSAC, em geral, é transparente e presta contas à comunidade da ICANN como um todo.

A análise está programada para começar em outubro de 2017 até julho de 2018. Para ter uma visão geral completa e um cronograma da RFP, veja aqui [PDF 608 KB].

As manifestações de interesse deverão ser enviadas por e-mail a SSACReview-RFP@icann.org. As propostas deverão ser encaminhadas por meios eletrônicos até às 11:59 PM PDT de 21 de agosto de 2017 usando a ferramenta de sourcing da ICANN, cujo acesso pode ser solicitado através do mesmo endereço de e-mail mencionado acima.

Histórico

Segundo os Estatutos da ICANN, a função do Comitê Consultivo de segurança e estabilidade ("Security and Stability Advisory Committee" ou "SSAC") é fazer recomendações à comunidade e à Diretoria da ICANN sobre assuntos relacionados com a segurança e a integridade do sistema de alocação de nomes e endereços da Internet. Ele tem as seguintes responsabilidades:

  1. Comunicar-se sobre assuntos de segurança com a comunidade técnica da Internet e os operadores e gerentes de serviços críticos de infraestrutura do DNS, para incluir a comunidade de operadores de servidores de nome-raiz, os registros e registradores de domínio de topo, os operadores das árvores de delegação reversa, como "in-addr.arpa" e "ip6.arpa", e outros que os eventos e as circunstâncias possam ditar. O SSAC deverá reunir e articular requerimentos para oferer aos participantes da revisão técnica dos protocolos relacionados ao DNS e alocação de endereços e àqueles participantes do planejamento de operações.
  2. Engajar-se na avaliação contínua de ameaças e análise de riscos da alocação de nomes e endereços da Internet para avaliar onde estão as principais ameaças à estabilidade e segurança e para aconselhar à comunidade ICANN conforme a isso. O SSAC deverá recomendar qualquer atividade de auditoria necessária para avaliar o status atual do DNS e da segurança de alocação de endereços com relação à identificação de riscos e ameaças.
  3. Comunicar-se com aqueles que tenham responsabilidade direta por assuntos de segurança de alocação de nomes e endereços da Internet (IETF, RSSAC - conforme definido na seção 12.1(c)(i), RIRs, registros de nomes etc.), para assegurar que sua assessoria sobre riscos, problemas e prioridades de segurança esteja sincronizada corretamente com as atividades de padronização, implantação, operacionais e de coordenação existentes. O SSAC deverá monitorar essas atividades e informar à comunidade e à Diretoria da ICANN sobre seu andamento, se corresponder.
  4. Notificar periodicamente suas atividades à Diretoria.
  5. Fazer recomendações de políticas à comunidade e à Diretoria da ICANN.

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