Resumo

  • O Datatracker registrou a aprovação de draft-ietf-intarea-legacy-registries-00 como versão do grupo em 11 de setembro de 2026. O texto segue como Internet-Draft, não como RFC.
  • A proposta reúne ações diferentes: fechar um registro, atribuir IESG Approval a outro, definir First Come First Served para duas listas e remover ou reescrever a nota do registro de TTL.
  • As cinco superfícies públicas da IANA ainda mostram o estado anterior. Um comprovante por ação deve separar adoção, aprovação, execução e preservação histórica.

A sigla no nome mudou antes dos registros

A página atual do Datatracker apresenta “Updates to Legacy IANA Registries” como documento ativo da INTAREA. O histórico da versão de grupo registra, em 11 de setembro, a aprovação do -00 e a substituição da série individual.

Esse passo dá ao grupo de trabalho a responsabilidade de desenvolver o texto. Comentários deixam de mirar apenas uma proposta de autor e passam a integrar uma pauta coletiva. Ainda assim, o prefixo draft-ietf não é aprovação de Proposed Standard. As solicitações na seção de considerações para a IANA permanecem no futuro.

O histórico do texto individual mostra como a adoção foi delimitada. Em 27 de agosto, os presidentes registraram consenso para adotar, reconheceram uma objeção já ouvida e discutida e disseram que o documento trata de manutenção de registros, não de uma posição sobre o futuro do IPv4. O grupo decidiu trabalhar no problema sem declarar encerrada toda controvérsia.

O conteúdo das ações tampouco mudou na passagem. A revisão individual 03 e a revisão 00 da INTAREA diferem apenas por uma correção gramatical nas considerações de segurança e um nome acrescentado aos agradecimentos. A novidade é a custódia institucional do texto.

Quatro verbos cabem na mesma proposta

“Limpeza” serve como rótulo geral, mas não descreve o que acontecerá em cada lugar.

Para NetWare/IP Option Type 63 Sub-Option Codes, o pedido é fechar o registro porque o NetWare não recebe extensões. Fechamento impede novas inscrições sem invalidar as antigas. A RFC 8126 diz que as informações continuam válidas, podem ser atualizadas e permanecem disponíveis para fins históricos.

Em IP Option Numbers, a proposta é definir IESG Approval. O registro não seria fechado. Essa política permite que o IESG aprove uma atribuição caso a caso, sem exigir uma RFC em todas as situações, e lhe dá liberdade para pedir documentação ou ouvir a comunidade. A RFC 8126 ressalta que esse caminho é excepcional e pouco usado, não uma rotina.

Para Machine Names e Terminal Type Names, a escolha é First Come First Served. É uma política de documentação mínima, sem análise técnica. O projeto admite a possibilidade de pedidos sem sentido e menciona a filtragem ordinária da IANA. Dar uma regra leve a duas listas paradas há décadas é uma abertura administrativa, não um encerramento.

O registro IP Time to Live Parameter seria removido. O argumento é que o TTL de IPv4 pode ser escolhido pelo sistema operacional ou aplicativo, logo esse registro não deveria existir. Caso a remoção completa seja impossível, o texto oferece uma nova nota. Remover a página e conservar a página com outra explicação deixam trilhas diferentes.

O site da IANA conserva o ponto de partida

Nos parâmetros DHCP e BOOTP, os subcódigos NetWare continuam publicados e o procedimento aparece como Not defined. Não há marca de fechamento.

Nos parâmetros IPv4, IP Option Numbers também continua com Not defined. O registro de TTL e a recomendação de valor padrão 64 seguem na página. Os valores experimentais de opções estão preservados, mas a política IESG Approval ainda não consta ali.

Machine Names mantém Not defined. Terminal Type Names conserva Not defined?, inclusive com o ponto de interrogação. Nenhuma das duas páginas anuncia First Come First Served.

Isso não demonstra demora da IANA. A RFC 8126 explica que as ações normalmente ocorrem quando um documento é aprovado para publicação. Este ainda é um rascunho em desenvolvimento. A lista de documentos da INTAREA informa o estágio do texto; os registros informam a regra vigente. São fontes para perguntas diferentes.

A discordância também foi adotada

As atas da INTAREA no IETF 126 preservam preocupações importantes. Um participante questionou se dificultar novos números de opções IPv4 poderia impedir usos legítimos em domínios limitados. Outro pediu que dados antigos não desaparecessem. O autor apontou os valores experimentais e afirmou que as entradas existentes seriam mantidas.

Na discussão de adoção, houve contestação à maneira como o projeto caracteriza o funcionamento das opções IPv4 e receio de que a justificativa fosse citada depois como verdade mais ampla. Também houve apoio. A decisão dos presidentes coloca essas questões sob responsabilidade da INTAREA; não as transforma em unanimidade retroativa.

Por isso, a descrição correta é contida: o grupo adotou o documento para trabalhar nele. Ainda não aprovou cada ação como texto final, e a IANA não publicou seus efeitos.

Um comprovante para cada ação

Uma futura ficha de execução registral poderia ligar a instrução ao resultado. É uma sugestão editorial, não uma exigência atual do IETF ou da IANA.

Cada ficha teria o nome e a URL exatos do registro, o estado anterior com data, a versão e a impressão digital do projeto, o verbo solicitado, os marcos do grupo e do IESG, a confirmação de execução pela IANA, a referência efetiva, o estado posterior e o tratamento dado às entradas antigas.

Machine Names e Terminal Type Names precisariam de fichas separadas, embora recebam a mesma política. NetWare seria descrito como fechado com valores preservados, nunca como apagado. A ficha de TTL distinguiria remoção de troca da nota. Se outra revisão mudar a política de IP Option Numbers, o pedido anterior continuaria visível como etapa superada.

Esse registro enxuto impede que um fato substitua outro. O novo nome do arquivo comprova que o grupo assumiu o trabalho. Uma futura RFC comprovaria a aprovação das instruções. Só a mudança nas páginas da IANA comprovará a execução. A governança fica mais clara quando cada prova ocupa seu lugar.

Fontes

  1. IETF Datatracker — documento atual
  2. Histórico do documento de grupo
  3. Revisão 00 da INTAREA
  4. Histórico do documento individual substituído
  5. Revisão individual 03
  6. Atas da INTAREA no IETF 126
  7. Discussão de adoção
  8. IANA — parâmetros DHCP e BOOTP
  9. IANA — parâmetros IPv4
  10. IANA — Machine Names
  11. IANA — Terminal Type Names
  12. RFC 8126 — orientação para registros da IANA
  13. Documentos da INTAREA