Summary

  • A versão de 26 de outubro da minuta IANABIS instrui a IANA a criar o campo Change Controller em novos registros cujas inscrições não exijam um RFC da linha editorial da IETF. A lista inclui First Come First Served, Expert Review, Specification Required e RFC Required. Registros antigos sem o campo receberiam inicialmente espaços vazios no futuro. A proposta ainda é um Internet-Draft.
  • O RFC 8126 já recomendava identificar o responsável por alterações. O registro atual de extensões de funções JSONPath da IANA mostra a separação em prática: Glyn Normington aparece como especialista, enquanto IETF consta como controladora das mudanças nas cinco entradas.

A segunda decisão sobre o mesmo código

É fácil imaginar a administração de um registro como uma fila de pedidos novos. Um código chega, a política de inscrição é aplicada e a linha é publicada. Mas um registro longevo também recebe pedidos para alterar linhas antigas. Uma referência ficou desatualizada; a descrição precisa acompanhar a especificação; o contato mudou de instituição. Nessa hora, o endereço que responde mensagens pode não ter competência para aprovar a alteração. O especialista que julga a consistência técnica também pode exercer outro papel. A tabela precisa distinguir esses poderes no local em que eles serão usados.

O RFC 8126 em vigor já tratava disso. Para registros e inscrições originados em RFCs da linha editorial da IETF, a IETF detém por padrão o controle das alterações por meio do IESG. Para registros abertos a inscrições fora desse caminho, o documento aconselha identificar o controlador. Em novos registros First Come First Served e Expert Review, recomenda incluir um campo específico. A ideia, portanto, não nasceu na minuta de 2026; o que muda é a instrução dirigida ao trabalho de criação dos registros.

A minuta IANABIS -04 explicita essa instrução na seção 11.2. Todo novo registro com procedimento que dispense um RFC da linha editorial da IETF deve receber o campo. O texto cita First Come First Served, Expert Review, Specification Required e RFC Required. Na seção 2.5, orienta registrar IETF para inscrições da linha editorial da IETF, porque o IESG atua em seu nome; documentos de origem que determinem IESG continuam sendo exceções. O detalhe evita confundir o titular institucional do controle com a instância que o exerce.

Uma coluna sem nome é um diagnóstico

Para registros existentes sem o campo, a minuta fala em acrescentar campos vazios no futuro. Não coloca automaticamente o autor antigo, o contato atual ou o especialista na posição de controlador. A lacuna ficaria exposta ao próximo operador. É uma escolha melhor do que transformar conveniência administrativa em direito de assinatura. O texto não informa quantos registros entram nessa situação nem quando os campos receberiam nomes. Uma relação pública dos registros afetados e dos fundamentos usados para preenchê-los mudaria a avaliação do esforço.

O registro de extensões de funções JSONPath da IANA oferece um exemplo de tabela já preenchida. O procedimento é Expert Review e o especialista indicado é Glyn Normington. Nas cinco entradas length, count, match, search e value, o Change Controller é IETF. A página mostra que um parecer técnico e a autoridade de alteração podem ser publicados como atribuições separadas. Ela antecede a eventual adoção da minuta; não é prova de execução da nova instrução.

Há ainda o problema de trocar o próprio nome do controlador. A seção 3.1.2 propõe que o procedimento de inscrição também governe a modificação, salvo regra específica. Para inscrições feitas sem RFC, a IANA pode confirmar e aprovar atualizações de contato e controle, recorrendo a especialistas ou diretores de área quando necessário. Um campo correto depende desse percurso. Sem ele, a placa na porta pode ser substituída por quem tiver acesso à chave.

O RFC 8126 continua sendo a orientação vigente. A proposta IANABIS ainda está em estágio de Internet-Draft. A versão final, o estado no IESG e as mudanças efetivas nas tabelas da IANA serão recibos distintos dessa evolução.