Resumo

  • O draft-ietf-netconf-yp-transport-capabilities-07 permite descobrir transportes, codificações e protocolos de segurança para notificações YANG, a partir de informação de implementação ou de um servidor em execução.
  • O registro é um catálogo de possibilidades. Ele não seleciona uma combinação exata, não concede autorização, não provisiona o receptor, não aceita establish-subscription e não comprova entrega.
  • Informação publicada antes da operação e leitura em tempo de execução têm origem e validade diferentes. A automação precisa preservar qual delas orientou a ação.
  • Um recibo de decisão entre capacidade e assinatura pode unir observação, combinação, política, destino, pedido, resultado e contingência. É proposta editorial, não requisito do IETF.

Uma boa resposta ainda não é uma ordem

A revisão 07 de YANG Notification Transport Capabilities resolve uma parte concreta da gestão de rede. Antes de solicitar notificações, um sistema pode consultar quais mecanismos o servidor declara. A árvore acrescenta uma entrada por protocolo de transporte e, dentro dela, listas de formatos de codificação e protocolos de segurança.

O exemplo associa HTTPS a XML e JSON, além de TLS 1.2 e TLS 1.3. Outra entrada associa UDP-notif a JSON e CBOR, com DTLS 1.2 e DTLS 1.3. O orquestrador deixa de propor opções que o equipamento nem sequer anuncia.

O ganho desaparece quando a interface resume a árvore em um ponto verde chamado “notificações suportadas”. Essa cor mistura capacidade observada, escolha, aprovação pela política, aceitação pelo publicador e entrega ao receptor. Cada etapa pertence a atores distintos e produz evidência distinta.

A revisão 07 foi publicada em 17 de agosto de 2026. O Datatracker recebeu atualização em 8 de setembro, também a data final para comentários da última chamada do IETF anunciada em 25 de agosto. No corte de 9 de setembro, o texto continuava um Internet-Draft ativo, destinado a Proposed Standard, submetido ao IESG e no estado “Waiting for AD Go-Ahead”. A passagem do prazo não é aprovação, nem publicação como RFC.

A palavra “suporta” opera em dois relógios

O RFC 9196, base do modelo, prevê duas fontes de capacidade. O implementador pode oferecer um arquivo de dados de instância YANG antes de haver um nó em operação. O servidor ativo pode expor a informação por NETCONF ou RESTCONF.

A fonte de implementação ajuda o projetista do NMS, o integrador e quem decide uma compra. Ela descreve uma família de produto ou uma implementação. A fonte de execução serve a aplicações orientadas por modelos e pode refletir licença, restrição de hardware ou mudança operacional. O RFC 9196 apresenta a leitura ao vivo também como verificação do que o publicador efetivamente implementou em relação ao material anterior.

Assim, dois relatos honestos podem divergir. O arquivo do produto não conhece necessariamente a placa instalada. A leitura das dez horas pode ficar velha às dez e cinco. Quando a capacidade muda durante a execução, o RFC recomenda notificação on-change do contêiner; ainda cabe ao consumidor recebê-la e relacioná-la à escolha já feita.

Um registro confiável precisa nomear a fonte, a revisão do módulo, o aparelho e sua versão, o método e o local de obtenção, o momento observado e a política de expiração. Sem essas coordenadas, “suporta” pode estar correto e ainda ser insuficiente para uma máquina agir.

Listas delimitam o espaço; não narram a tentativa

A lista transport-capability usa o protocolo de transporte como chave. Em cada item, security-protocol e encoding-format são listas separadas. Isso funciona como mecanismo de descoberta, não como recibo de uma composição executada.

Também seria errado inventar uma falha: o formato não prova que o servidor promete todas as combinações cartesianas. A conclusão segura é menor. A presença isolada de transporte, codificação e segurança não comprova que a tripla exata escolhida pelo controlador funciona agora. Essa tripla precisa ser explicitada, tentada e registrada.

O RFC 8639 define a fronteira seguinte. A assinatura dinâmica não existe no publicador apenas porque o assinante enviou o pedido. Ela nasce quando establish-subscription é aceito. O publicador pode recusar por vários motivos e devolver indicações estruturadas sobre parâmetros que talvez funcionem numa nova tentativa.

A aceitação também não prova entrega duradoura. Ela cria o estado no publicador. O destino pode não ser alcançável, o fluxo pode ser suspenso, e a primeira notificação pode nunca chegar. Uma visão operacional honesta separa descoberto, escolhido, aprovado, aceito e entregando.

A porta de gestão não configura a saída

O rascunho assume uma rede de gestão disponível entre orquestrador e aparelho. A conectividade e o ponto de acesso de gestão do equipamento já devem estar provisionados. É essa premissa que permite ler a árvore.

Ela não provisiona o receptor das notificações. Nem declara que todo principal autenticado por NETCONF ou RESTCONF pode criar uma assinatura para qualquer destino. Autenticação identifica o ator; NACM e a política local limitam a ação; segurança pode definir o perfil permitido; a equipe de telemetria controla o receptor; outra equipe controla o caminho.

Em operações divididas, cada área pode supor que a outra aprovou a etapa decisiva. A equipe de rede vê capacidade, segurança imagina que só a opção preferida será usada, e o receptor espera que o equipamento teste o destino. Sem um vínculo comum, nenhuma dessas expectativas equivale a uma decisão.

O texto caracteriza os novos nós como somente leitura e não sensíveis, e prevê NETCONF ou RESTCONF seguro, mutuamente autenticado, com controle NACM. Não é preciso transformar o catálogo em segredo. O risco é outro: um fato não confidencial pode ser usado como instrução não autorizada. Ler TLS 1.2 na lista não concede permissão para adotá-lo em um receptor regulado.

Evidência de processo conserva seu limite

Em 8 de setembro, o Datatracker informava zero erros e zero alertas na validação YANG. A revisão de segurança atual estava “Ready”, a de transporte “Almost ready”; a IANA ainda tinha ações e as análises de especialistas estavam de acordo. São fatos úteis sobre a maturidade do documento, não medições de serviço.

A seção de implementação afirma que Huawei adotou o documento em um publicador YANG-Push da plataforma VRP e Cisco no IOS XR. A mesma seção pede remoção antes da publicação pelo RFC Editor. Há código declarado, mas não uma matriz pública de interoperabilidade da revisão 07, participação de mercado, certificação ou teste de todas as triplas.

O item dtls12 ensina outra cautela: sua descrição chama DTLS 1.2 de obsoleto e não recomenda habilitá-lo. Isso não proíbe TLS 1.2, que aparece sob HTTPS no exemplo. Uma política por busca de texto em “1.2” confundiria identidades e documentos normativos diferentes.

O recibo que impede a conclusão automática

O recibo de decisão entre capacidade e assinatura pode ser um artefato operacional, sem alterar o protocolo. Ele identifica equipamento, família, revisão do módulo e versão de software. Declara se a fonte foi um arquivo de implementação ou uma leitura NETCONF/RESTCONF, onde e quando foi obtida e quando deve ser considerada vencida.

Depois, conserva a entrada anunciada e a tripla realmente selecionada: transporte, codificação e segurança. Inclui o principal que agiu, identidade e endpoint do receptor, versão da política, parâmetros e horário do pedido. Distingue aceito, recusado, expirado, terminado depois e aceito sem primeira entrega.

As indicações de erro, nova tentativa, contingência e autoridade que aprovou uma opção mais fraca permanecem juntas. A automação não pode chamar um recuo silencioso de mera descoberta de compatibilidade.

The Policy Mirror manda localizar o campo que governa o efeito: a árvore escreve possibilidade; a política escreve permissão; o publicador escreve existência; o receptor prova utilidade. Running-Code Primacy exige que os vestígios de execução se encontrem. Reality, Not Advocacy mantém a conclusão justa: o rascunho promete melhor descoberta, não entrega automática. O operador responde pelo item que seleciona.

Fontes