Resumo

  • O draft-ietf-netmod-node-tags-11 descreveu tags definidas no módulo, atribuídas pela implementação e configuradas pelo usuário, com remoção das correspondências exatas registradas em masked-tag antes da exibição operacional.
  • O que sobra comprova apenas a resposta daquele servidor, para aquele seletor, datastore e perfil de acesso. Não comprova existência atual do nó, frescor, implementação correta, adoção do draft ou comportamento da rede.

Imagine uma ferramenta que descobre os pontos de telemetria classificados para uso em segurança. Ela recebe quatro seletores e não vê um quinto, conhecido pela equipe. A ausência não traz sua própria explicação. O tag pode nunca ter sido criado, pode ter sido mascarado, filtrado por NACM, invalidado por outra revisão do esquema ou consultado no datastore errado.

Essa dificuldade não é um defeito lateral. É a fronteira central de YANG Data Model for Node Tags. O módulo proposto, ietf-node-tags, usa uma lista de associações com id inteiro, node-selector do tipo nacm:node-instance-identifier, valores tag e valores masked-tag. O seletor pode apontar para um nó de esquema ou para uma instância de dados. O texto apresenta <get-data> no datastore operacional como rota de descoberta e menciona <get-schema> para nós de esquema. No apêndice, o caminho encontrado é reutilizado em establish-subscription.

O exemplo mostra como componentes poderiam ser encadeados. Ele não registra produto entregue, segunda implementação, interoperabilidade nem produção. O conjunto de fontes desta análise não contém evidência de implantação.

A descrição das origens deixa uma emenda

O draft trata separadamente das tags incorporadas pelo autor do módulo, das que a implementação adiciona e das que o usuário configura. Também permite ao usuário mascarar qualquer tag, seja qual for a origem.

Quando passa para a construção do estado operacional, porém, a enumeração acrescenta tags de origem system atribuídas na definição do módulo, acrescenta tags do usuário com origem intended e remove toda tag igual a masked-tag. Não há uma etapa nominal para a implementação.

Ler as adições automáticas da implementação como material do lado servidor ou system é coerente. Ainda assim, trata-se de uma conciliação interpretativa. Um registro de auditoria não deve fabricar uma quarta etapa mais clara que o documento.

A máscara também não reescreve a proveniência. Ela subtrai uma string exata do conjunto visível. Não prova que a classificação nunca existiu ou que era falsa. Uma tag que permanece tampouco informa autor, data, versão do software ou observação que motivou a escolha.

Os prefixos ietf:, vendor: e user: separam namespaces. O texto aceita ainda prefixos não registrados e recomenda que sejam processados. O registro coordena nomes; não garante a proposição escrita depois dos dois-pontos.

O seletor precisa de um esquema fora dele

O tipo estruturado do node-selector reduz ambiguidades sintáticas, mas seu significado depende do contexto. A RFC 7950 define YANG. A RFC 8525 descreve, na YANG Library, os módulos, revisões, features e deviations efetivos. Uma mudança nesse conjunto ou em um contexto montado pode fazer a mesma rota parar de resolver ou alcançar outro nó.

A RFC 8342 separa intended de operational. O draft usa essa distinção para a configuração do usuário e para o resultado composto. “Operacional”, aqui, continua sendo uma visão mediada pelo servidor; não é sinônimo de realidade física ou de pacote encaminhado.

A RFC 8341 permite que NACM restrinja a associação e o alvo. As RFCs 6241 e 8040 oferecem NETCONF e RESTCONF, mas o êxito de uma transação só comprova o que foi entregue àquela identidade. Um resultado ausente continua compatível com várias causas.

A RFC 7952 ajuda a enxergar outra escolha de design: metadata annotations acompanham instâncias de dados, enquanto node-tags mantém associações centrais por seletor. Nenhuma das duas formas cria sozinha autoria, horário, cadeia de custódia ou frescor.

Cada ação precisa de um degrau de evidência

O arquivo do draft prova que a proposta existiu. O Datatracker prova sua situação documental. Um prefixo registrado prova uma alocação de namespace. Uma tag retornada prova que o servidor expôs o valor depois da composição, dentro de um contexto de acesso e datastore.

Resolver o seletor contra uma captura de YANG Library comprova o alvo naquele esquema. Uma leitura autorizada comprova o valor devolvido naquela operação. Frescor, completude, implementação fiel, entrega de notificações, estado da FIB, encaminhamento e resultado de serviço exigem outras observações.

As RFCs 8639 e 8641 permitem criar subscriptions e YANG-Push. As RFCs 9195 e 9196 modelam dados de instância e capacidades. Esses mecanismos não transformam a classificação em prova de que todos os eventos chegaram ou de que o dispositivo executou o significado sugerido. A RFC 9371 ajuda a organizar identificadores de fornecedor; não homologa comportamento.

O próprio draft alerta que tags podem expor o uso de um nó e um vetor de ataque. Adição e remoção devem ter controle de privilégio, e ações baseadas nas tags ficam fora do escopo. Se uma organização usa um rótulo para bloquear, autorizar ou alterar configuração, ela precisa assumir e documentar essa decisão.

A RFC vizinha não transfere seu status

A revisão 11 é de 21 de outubro de 2023 e previa expiração em 23 de abril de 2024. O Datatracker a registra como Expired Internet-Draft, Expired & archived, Dead WG Document e IESG Expired. O status pretendido era Proposed Standard; ela não se tornou RFC.

A validação YANG aparece com zero erros e zero avisos. Isso comprova que os módulos submetidos passaram pelas verificações indicadas. Não comprova adoção, interoperabilidade, implantação ou composição operacional correta.

A RFC 8819 é o precedente formal mais próximo e padroniza tags para módulos YANG. Ela distingue definição, implementação, usuário e máscaras. Node-tags tentou levar o padrão aos nós. O fato de a RFC 8819 ser Standards Track não concede esse status ao draft expirado.

Os textos de Heng Lu sobre especificação mínima, autoridade, poder de implementação, camadas de realidade e running code entram apenas como lente editorial. Eles ajudam a separar instrumentos simbólicos de coordenação da operação observável. Não criam requisitos IETF. A aplicação prática é manter a tag como pista, sem permitir que ela tome emprestada a autoridade do documento, do registro ou do servidor.

Fontes

Registro principal: revisão 11, situação no Datatracker e histórico.

Modelo e acesso: RFC 6241, RFC 7950, RFC 7952, RFC 8040, RFC 8341, RFC 8342, RFC 8407, RFC 8525 e RFC 8526.

Tags, assinaturas e modelos próximos: RFC 8639, RFC 8641, RFC 8819, RFC 9195, RFC 9196 e RFC 9371.

Lente analítica: Minimum Initial Specification, On Authority, Implementation Power, Reality Layers e Running Code Primary.