Resumo

  • draft-fedyk-netmod-yang-normal-form-00 propõe manter a representação lexical recebida e derivar uma forma determinística para igualdade, chaves de listas e unicidade de leaf-lists de configuração.
  • No exemplo MAC, dois-pontos ou hífens e letras hexadecimais maiúsculas ou minúsculas convergem para o mesmo valor comparativo de 12 dígitos. pattern valida sintaxe; não transforma duas strings válidas em iguais.
  • O Datatracker registra um Internet-Draft individual ativo, sem status RFC pretendido e com estado IESG I-D Exists; o cabeçalho interno diz Intended status: Standards Track. Isso não prova adoção pelo NETMOD nem endosso do IETF.

A grafia deixa de acumular duas funções

Sistemas de gestão podem expressar o mesmo endereço de 48 bits com textos diferentes. O tipo comum do IETF no RFC 6991 e em sua revisão atual RFC 9911 usa seis octetos separados por dois-pontos e descreve letras minúsculas como forma canônica. O tipo IEEE mostrado em material do IETF usa hífens e descreve maiúsculas. Para um engenheiro é o mesmo endereço; para uma chave string, são caracteres diferentes.

A revisão 00 separa apresentação e comparação. O valor lexical continua disponível para codificação e consulta. Uma extensão opcional normalized-form indica o algoritmo cujo resultado deve governar = e !=, unicidade de chave de lista e de leaf-list configurável.

Em mac-48, a implementação valida primeiro a entrada pelo tipo correspondente, remove separadores, converte os dígitos hexadecimais em maiúsculas e usa os doze restantes. Assim, aa:bb:cc:dd:ee:ff, AA:BB:CC:DD:EE:FF, aa-bb-cc-dd-ee-ff e AA-BB-CC-DD-EE-FF derivam AABBCCDDEEFF. O texto exibe 0xAABBCCDDEEFF; a identidade de doze dígitos é a parte sem o prefixo.

Uma expressão regular mais permissiva não resolve a comparação. O RFC 7950 usa pattern para restringir strings aceitas. A forma canônica do string embutido é sua própria representação lexical, sem normalização Unicode. Admitir duas caixas ou dois separadores não instrui o comparador a tratá-los como equivalentes.

Uma entrada pode ser duplicada em um motor e nova em outro

O suporte é opt-in. A implementação que o declara usa a forma normalizada; a que não o declara segue processando o tipo lexical. A regra de extensões do YANG permite ignorar inteiramente uma extensão desconhecida e exige que extensões suportadas sejam executadas conforme sua especificação.

Se aa:bb:cc:dd:ee:ff já existe e AA-BB-CC-DD-EE-FF chega a um nó cujo tipo permite essa forma, um motor compatível pode rejeitar a segunda entrada como a mesma chave normalizada. Um motor não compatível pode enxergar duas strings. A diferença alcança XPath, listas com chave e leaf-lists de configuração.

Por isso, um recibo de duplicidade deve trazer revisão do módulo, nó e tipo base, identidade de normalização, produto e versão, evidência de suporte e valor calculado. As duas grafias e um código de erro não reconstroem a regra que decidiu.

O cabeçalho não promove o documento

A página do Datatracker mostra Internet-Draft individual ativo, nenhum RFC stream, nenhum status RFC pretendido e I-D Exists. Também avisa que qualquer pessoa pode submeter um I-D e que este não tem endosso do IETF ou posição formal no processo. O corpo imutável registra Intended status: Standards Track e expira em 2 de janeiro de 2027.

O primeiro dado é a posição processual; o segundo, uma intenção escrita pelos autores. Até a menção “IETF NETMOD Working Group” no campo organization do módulo incluído não serve como prova de adoção do WG.

Os autores são Don Fedyk, da LabN Consulting, e Scott Mansfield, da Ericsson. O perfil de Fedyk lista 24 RFCs; o de Mansfield, cinco RFCs e funções de ligação IETF–UIT-T. Experiência é contexto para avaliação, não aprovação institucional.

As lâminas do NETMOD no IETF 124 registram a origem: confrontaram os formatos IETF e IEEE e avaliaram uma grafia única, patterns inclusivos, uma mecânica de equivalência, outro armazenamento ou nenhuma mudança. A revisão 00 escolhe a identidade de comparação paralela.

Igualdade é um comprovante limitado

Formas normalizadas iguais provam que duas entradas válidas passaram pela mesma transformação declarada. Um resultado XPath prova como aquela implementação avaliou aquele contexto. Uma rejeição prova o acionamento de uma restrição local.

Nada disso identifica o mesmo equipamento físico. Também não prova ausência de colisões em outros algoritmos, implementações idênticas, suporte bilateral, mesmo schema e árvore visível, migração de dados antigos, intenção, autorização, deduplicação no encaminhamento ou efeito na rede.

Essa proposta não é canonicalização comum. XDR produz uma representação externa única; aqui, múltiplas grafias permanecem e uma identidade separada atende apenas algumas comparações. Nome de arquivo, versão de módulo ou diff de schema tampouco comprovam que o algoritmo rodou.

A pergunta operacional é mais estreita: qual evidência mostra que o sistema comparou o valor declarado, não a tipografia do string?