Resumo

  • O BBF informou que WT-477i2 depende dos módulos do modelo BGP do IETF e pediu informação sobre uma data de publicação. A fonte registra uma dependência e uma pergunta, não uma data que o IETF aceitou entregar.
  • IDR respondeu em 1º de agosto que o rascunho estava em Working Group Last Call e listou revisão de Area Director, IETF-wide Last Call e revisão do IESG antes da fila do RFC Editor.
  • Em 21 de agosto, o Area Director responsável disse que a WGLC continuava aberta e que silêncio não indicava prontidão para publicação.
  • A versão 21 continua identificada como Internet-Draft; o Datatracker mostra “Waiting for Implementation” no grupo, “I-D Exists” no IESG e nenhuma data de teleconferência.
  • Um recibo público deve ligar a dependência BBF, a versão IETF e cada etapa de revisão sem transformar necessidade de calendário em consenso ou RFC.

O BBF descreveu o seu problema de compatibilidade

A liaison de acompanhamento do Broadband Forum, de dezembro de 2025, é específica. Ela afirma que os modelos YANG de WT-477i2 dependem de ietf-bgp e de módulos associados então definidos em draft-ietf-idr-bgp-model-18. A mensagem junta uma versão de trabalho BBF, diz que WT-477i2 se aproximava da conclusão e pede informações sobre datas-alvo do modelo BGP.

É correto chamar isso de dependência. Também é incorreto chamar isso de aprovação ou de calendário contratado. A mensagem não cria um prazo dentro da IETF, não reserva um número RFC e não demonstra que o próprio WT-477i2, um equipamento ou uma rede adotou o modelo. Ela permite reconhecer um interesse técnico externo e saber onde esse interesse deve ser ligado ao registro do IETF.

Esse tipo de ligação é desejável quando dois organismos evitam construir vocabulários incompatíveis. Uma dependência não é uma captura de processo. RFC 2418 trata da consideração de trabalho relevante em outros padrões e da necessidade de liaison adequada em temas sobrepostos. Essa coordenação reduz duplicação; ela não entrega a uma instituição a competência para declarar finalizado o trabalho da outra.

A resposta de IDR preserva a sequência das decisões

Na resposta de 1º de agosto, o IDR informa que draft-ietf-idr-bgp-model estava em Working Group Last Call. Depois do grupo, ainda seriam necessários revisão de Area Director, IETF Last Call e exame abrangente do IESG antes da entrada na fila de publicação do RFC Editor. A resposta recomenda que interessados do BBF participem da lista IDR com discussão e comentários técnicos.

Participação é uma via de contribuição, não uma votação automática sobre publicação. Um comentário pode corrigir, apoiar ou questionar partes do modelo. Ele não substitui o julgamento de consenso nem as etapas posteriores. A própria resposta, ao não oferecer uma data, mostra por que informação de calendário e disposição de norma devem continuar como campos separados.

O aviso de 21 de agosto torna o estado ainda mais nítido. A versão 21 fora postada, porém a WGLC continuava aberta. O Area Director diz que procurará apoio positivo e revisões concluídas para julgar consenso; silêncio não é indicação de que o documento está pronto para publicação. Como os três chairs de IDR são coautores, o próprio Area Director chamará o consenso nessa WGLC, e há um shepherd identificado para a revisão.

Esses detalhes não acusam ninguém; fazem o oposto. Eles permitem separar autoria, revisão e ato processual. Um leitor não precisa supor que uma ausência de mensagem é aprovação, nem que um pedido de uma instituição externa decide uma etapa na qual ela pode apenas participar.

A página do rascunho ainda não é a página de uma norma

O Datatracker da versão 21 chama o texto de Internet-Draft, data-o de 14 de agosto de 2026 e lembra que rascunhos podem ser atualizados, substituídos ou tornados obsoletos, devendo ser citados apenas como trabalho em progresso. Os campos “Waiting for Implementation”, “I-D Exists” e ausência de telechat não equivalem a entrada na fila ou publicação.

A carta do IDR estabelece que desenvolver e manter BGP como protocolo interdomínios para IPv4 e IPv6 é objetivo prioritário do grupo. É uma definição de escopo, não certificado de maturidade para cada rascunho. RFC 2026 descreve a trajetória de padrões e exige uma ação específica do IESG para Proposed Standard; experiência adicional pode mudar ou retirar uma especificação antes de avanços futuros.

Assim, há pelo menos cinco registros que não se substituem: a dependência de WT-477i2; o estado da WGLC; evidência e disposição de consenso; estados de Area Director, IETF e IESG; e, por fim, fila do RFC Editor e RFC publicado. O modelo pode ser importante para o BBF sem que seu estado documental possa ser adivinhado a partir da importância.

A pequena ficha que evita uma grande confusão

Uma ficha pública de dependência deveria reter documento BBF + versão, rascunho IETF + versão, data e termos da solicitação, estado da WGLC, revisões concluídas, disposição de consenso, etapas posteriores, fila e RFC final. Cada linha deve carregar um limite negativo. A dependência não prova compromisso. WGLC aberta não prova rejeição nem uma data futura. Uma entrada de fila não prova adoção. Um RFC, caso publicado, não prova implantação por operadora ou sucesso de WT-477i2.

As fontes deste artigo não medem implementações, interoperabilidade, uso comercial, suporte de fornecedores ou impacto operacional. Tampouco mostram litígio, atraso culposo ou veto. A conclusão é menor e mais útil: os registros públicos descrevem um trabalho cuja revisão continua aberta, não uma data cuja autoridade já foi transferida.

Fontes