Resumo

  • O IESG abriu em 27 de agosto a Última Chamada sobre um processo que permitiria à IANA criar um registro inteiro antes de o documento fundador ser aprovado como RFC. A tabela seria pública, temporária e válida inicialmente por dois anos.
  • O prazo do registro não determina sozinho o prazo de cada entrada. Um histórico público de transições deve ligar versão do rascunho, consenso e aprovações, procedimento provisório, mudanças de política, renovações, fechamento e consolidação.

Uma tabela provisória pode parecer simples: publica-se uma etiqueta, registra-se uma data e começa a contagem regressiva. A simplicidade desaparece quando as linhas da tabela obedecem a regras diferentes e entram em produtos que talvez continuem operando depois que a própria tabela for fechada.

É esse o ponto institucional do Early IANA Registry Creation. A Última Chamada anunciada pelo IESG em 27 de agosto recebe comentários substanciais até 10 de setembro. A versão 02 pretende seguir a trilha de padrões, mas ainda é um Internet-Draft. Não houve decisão final nem publicação como RFC.

O mecanismo procura resolver uma necessidade legítima. Um grupo de trabalho pode estar escrevendo o documento que cria um novo espaço de parâmetros enquanto outras especificações já precisam de valores coordenados. Uma entidade de padronização externa também pode depender de alocações para concluir seu trabalho. Se cada parte escolher um número local, surgem colisões. Se o grupo mantiver uma lista informal, ela pode continuar circulando depois de a IANA publicar a tabela oficial.

A proposta transforma essa fase intermediária em um processo público. Com aprovações definidas, a IANA criaria o registro antes do RFC fundador. Isso vai além de reservar antecipadamente um código em uma tabela existente: põe em operação o próprio ponto de coordenação e uma política de entrada que ainda é transitória.

A solicitação percorre uma cadeia, não um atalho

Os autores apresentam o pedido aos presidentes do grupo de trabalho. Os presidentes verificam as condições e avaliam se existe consenso no grupo para a criação antecipada. Em seguida, solicitam aprovação ao diretor de área, que pode exercer julgamento especialmente quando houver risco de a tabela nunca se tornar permanente. Só depois eles pedem à IANA que a crie.

A IANA publicaria o registro no local apropriado, marcaria sua condição temporária e mostraria as datas de criação e expiração. O período inicial seria de dois anos. Perto do fim, a IANA perguntaria aos presidentes e ao diretor de área se desejam mais dois anos. Depois da primeira extensão, uma renovação adicional também dependeria do IESG e precisaria trazer motivos e um plano para a especificação.

Se a extensão não for aprovada, a IANA fecharia o registro e o identificaria como fechado. Os presidentes poderiam pedir o encerramento a qualquer momento. O relógio deixa de correr numa situação delimitada: se o documento fundador chegar à análise do IESG enquanto o registro ainda for válido, ele não expira durante essa análise. A IANA também pode pedir ao IESG a suspensão do procedimento diante de questões de segurança ou outros problemas.

Há, portanto, freios reais. O que falta explicitar é uma forma única de ligar o estado visível à decisão que o produziu. “Temporário até 2028” não informa qual revisão foi aprovada, qual procedimento recebia entradas naquela data nem qual ato alterou a situação depois.

O prazo do recipiente não é o prazo do conteúdo

O rascunho fundador deve indicar a política que regerá o registro definitivo. Durante a fase antecipada, porém, essa política ainda não vale diretamente. A IANA aplicaria um procedimento provisório escolhido conforme a regra projetada.

Se o destino for First Come First Served ou Expert Review, que não exige RFC para cada inscrição, uma entrada dependeria da aprovação de um presidente do grupo. A proposta diz que entradas assim aprovadas não precisam de renovação. Quando o documento é patrocinado por um diretor de área, o diretor ocupa esse papel.

Quando a política definitiva exige RFC — IETF Review ou Standards Action, por exemplo —, a entrada precisa passar pelo mecanismo da proposta de revisão da alocação antecipada. Mesmo depois de o registro ficar permanente, essa linha continua temporária até que seu próprio documento seja aprovado. Specification Required cria caminhos adicionais dependendo de Internet-Drafts poderem ou não sustentar uma inscrição permanente.

Uma tabela temporária pode, assim, conter uma entrada aprovada pelo presidente sem renovação, outra com prazo próprio e uma terceira inicializada pelo documento fundador. Mais tarde, a tabela pode ser definitiva enquanto uma linha ainda aguarda sua especificação. Um único campo de validade não representa esse arranjo.

É também o que diferencia a proposta do RFC 7120 vigente. O BCP atual trata da alocação antecipada dentro de um registro que já existe. O texto de 2026 trata da criação antecipada do próprio registro. O objeto colocado em operação é maior e carrega uma superfície de governo própria.

Uma revisão do rascunho pode trocar a regra de entrada

A criação antecipada não congela o documento. Se a política futura mudar de Expert Review para IETF Review, a porta provisória correspondente também precisa mudar. A proposta exige que a IANA seja avisada e deixa claro que a IANA não acompanhará por conta própria as alterações dos documentos criadores.

Essa divisão é correta. A IANA administra e executa instruções; não deve inferir política ao comparar rascunhos. Autores e presidentes continuam responsáveis por revisar mudanças de conteúdo e estrutura. Mas a divisão só é auditável se cada aviso carregar a versão exata, a decisão, o horário de vigência, a regra anterior, a nova regra e as linhas atingidas.

Sem essa ligação, a página pode estar operacionalmente atualizada e historicamente opaca. O leitor vê o valor, mas não sabe se ele entrou por aprovação de presidente, alocação antecipada, análise de especialista ou uma regra prevista apenas para o registro definitivo.

Um histórico de transições preserva a autoridade estreita

No nível do registro, o histórico deveria guardar identificador estável, grupo, documento fundador com versão e hash, registro do consenso, decisões de presidente e diretor de área, pedido à IANA, criação, expiração atual, política definitiva projetada e procedimento provisório em vigor. Mudança estrutural ou de política deve acrescentar um evento, sem apagar o anterior. Renovação, pausa durante análise do IESG, pedido de suspensão, fechamento e consolidação também precisam permanecer atribuíveis.

No nível da entrada, devem aparecer valor, significado, referência, controlador de mudança, rota de aprovação, versão da política e estado temporal. Se a linha depender de outro rascunho, essa dependência e seu prazo pertencem à própria linha. Quando a tabela fecha ou se torna permanente, cada entrada registra o que mudou.

Esse desenho não exige divulgar correspondência privada. O papel institucional, a referência de decisão, o hash do documento, a data e o resultado bastam para provar o movimento. A IANA não passa a criar política; apenas torna verificável a instrução recebida.

Coordenar não é aprovar o uso

Uma inscrição antecipada evita que duas tecnologias tomem o mesmo valor. Ela não certifica produto, não obriga implantação e não antecipa a aprovação final da tecnologia pelo IETF. A aprovação de um presidente tem a finalidade prevista pelo procedimento. A Última Chamada é consulta, não decisão do IESG.

O fechamento também tem limites factuais. A versão 02 determina que um registro sem extensão seja fechado e marcado. Não declara que todas as linhas são apagadas, invalidadas ou liberadas para reutilização naquele instante. É preciso preservar a disposição de cada entrada em vez de inventar um efeito coletivo.

As fontes examinadas não mostram registro já criado por essa proposta, implantação dependente dele ou abuso do processo. A recomendação é preventiva: antes da primeira tabela, garantir que o contexto de autoridade seja tão transportável quanto os números que sairão dela.

Fontes