Resumo

  • RFC 2860 registra o acordo de março de 2000 pelo qual IETF e ICANN delimitaram o trabalho técnico da IANA para protocolos de IETF e IRTF. Os RFCs definem os critérios; o IESG orienta ambiguidades e o IAB resolve certos conflitos.
  • O memorando exige dados públicos das atribuições, um canal on-line para pedidos, recusas baseadas apenas em motivos técnicos legítimos e recursos. Ele exclui questões de política sobre nomes de domínio e blocos IP, mas mantém dentro do procedimento algumas atribuições técnicas desses espaços.

Análise

O registro público é um dos mecanismos concretos do acordo. Pela seção 4.4, informações sobre cada atribuição vigente, incluindo os dados de contato do responsável, devem estar disponíveis on-line e gratuitamente. Uma atribuição publicada em RFC pelo editor dos RFCs pode cumprir essa obrigação. A seção 4.5 acrescenta um canal on-line para pedidos de parâmetros de protocolo. A IANA deve executá-los ou recusá-los em tempo hábil, com base na conformidade com requisitos técnicos aplicáveis; uma recusa só pode se apoiar em motivos técnicos legítimos.

Para registros criados por ação da IETF, o pedido recusado pode ser levado ao IESG e depois ao IAB.

Isso faz da visibilidade parte do mecanismo de revisão. Quem implementa um protocolo pode conferir a atribuição publicada, os critérios citados e os contatos correspondentes. A existência de uma entrada, porém, não prova que todos os pedidos relacionados tenham sido aceitos nem que a informação esteja implantada em cada sistema. O memorando define um dever de publicação, não uma auditoria de resultados operacionais.

O caminho começa nos documentos normativos. A seção 4.1 manda a IANA atribuir e registrar parâmetros segundo os critérios e procedimentos dos RFCs, que incluem padrões propostos, em versão preliminar ou completos, documentos de Best Current Practice e qualquer RFC que solicite uma atribuição. Se o critério não existir ou for ambíguo, a prática tradicional continua, salvo instrução diferente do IESG. Havendo dúvida ou disputa técnica, a IANA busca e segue a orientação técnica do IESG; quando apropriado, o grupo pode nomear um especialista.

O texto também prevê que IANA e IETF desenvolvam os critérios que faltam, que serão adotados mediante instrução do IESG.

Quando a divergência é entre IANA e IESG, a seção 4.2 prevê a orientação do IAB, cuja decisão é final nos termos do memorando. A seção 4.5 oferece outra rota: o requerente pode recorrer de uma negativa ao IESG e, depois, ao IAB. A separação distingue quem recebe pedidos, quem orienta critérios técnicos e quem resolve o conflito entre operador e órgão de gestão técnica. O RFC descreve a rota, mas não apresenta estatísticas de pedidos, recusas ou recursos.

O limite mais conhecido aparece na seção 4.3. Questões de política associadas à atribuição de nomes de domínio e blocos de endereços IP ficam fora do memorando. Ainda assim, nomes para DNS reverso, blocos especializados para multicast ou anycast e atribuições experimentais permanecem sob a seção 4 quando não são tratados como questões de política. Se uma política da ICANN impedisse o cumprimento das regras para esses casos específicos, a ICANN deveria avisar a IETF, que poderia exercer o direito de cancelamento previsto na seção 2.

A fronteira acompanha a natureza técnica ou política da questão; não elimina todos os trabalhos que envolvem nomes ou endereços.

O próprio documento tem escopo limitado. RFC 2860 foi publicado em junho de 2000 como Informational e afirma que não especifica nenhum padrão da Internet. Registra um memorando assinado pela IETF e ICANN em 1º de março e ratificado pelo conselho da ICANN em 10 de março. O propósito declarado é definir exclusivamente o trabalho técnico que a IANA realiza em nome de IETF e IRTF. O texto reconhece que ICANN também pode prestar serviços semelhantes a registros fora do escopo dessas organizações.

Há canais para incorporar a experiência operacional. A seção 4.6 permite que a IANA ocupe assentos de ligação sem voto em comitês apropriados determinados pela IETF e participe das discussões sobre requisitos de atribuição. A seção 4.7 manda revisar os documentos em Last Call da IETF e levar preocupações ao IESG. Para parâmetros principalmente relacionados à pesquisa, a seção 5 aplica procedimento equivalente à IRTF e à IRSG; se houver dúvida sobre qual dos dois campos é principal, a decisão cabe ao IAB.

O acordo podia ser alterado ou encerrado por consentimento mútuo; qualquer parte também podia encerrá-lo com aviso de pelo menos seis meses. Essa possibilidade delimita a relação, mas não comprova que tenha sido usada. O RFC 6220, de 2011, descreve depois as funções delegadas aos operadores dos registros de parâmetros de protocolo da IETF e diz que a IETF mantém responsabilidade por esses parâmetros. É uma descrição posterior, não evidência de que cada detalhe de 2000 permaneceu igual.

O que se pode sustentar é específico: os critérios apontam para RFCs, os registros devem ser públicos, a orientação técnica passa pelo IESG e há um caminho de revisão. O documento não demonstra a conformidade de cada decisão, o resultado de um recurso hipotético ou a autoridade competente para as questões de política excluídas. Uma leitura responsável conserva a lacuna em vez de preenchê-la.

Fontes

A fonte primária é RFC 2860, Memorandum of Understanding Concerning the Technical Work of the IANA, sobretudo as seções 1–5. A descrição posterior dos operadores está em RFC 6220.