Resumo

  • A RFC 9911 é um IETF Proposed Standard de dezembro de 2025; ela revisa ietf-yang-types e ietf-inet-types e obsoleta a RFC 6991.
  • Os nomes dos módulos e os namespaces continuam familiares, mas uma revisão pode alterar espaço de valores, formas canônicas, patterns e descrições. Igualdade de namespace não prova compatibilidade semântica.
  • A decisão operacional deve partir da revisão exata importada: inventariar dependências, reproduzir valores reais de datastore e comparar validação e serialização entre implementações.

O mecanismo: identidade estável, contrato revisável

É comum tratar o nome do módulo como uma fronteira permanente. A RFC 9911 mostra por que isso é insuficiente. A mesma identidade de módulo pode publicar uma nova data de revisão; assim, um modelo dependente pode conservar o mesmo nome em import e ainda receber novos typedefs, patterns, regras de forma canônica ou descrições. Continuidade do namespace não garante compatibilidade semântica. Da mesma forma, não se deve concluir que todos os valores da RFC 6991 passaram a ser inválidos.

A RFC 9911 revisa os dois módulos comuns e acrescenta tipos de data e hora, duration, language-tag, números de protocolo, endereços link-local, address-and-prefix, host-name e email-address. Também alinha yang-identifier ao YANG 1.1, definido na RFC 7950, e corrige ou aprimora vários statements de pattern e description. Para uma ferramenta que só compara a estrutura do módulo, isso pode parecer uma alteração editorial. Para um servidor, cliente, banco de configuração ou gerador de código, a alteração pode aparecer como uma divergência de validação ou de interoperabilidade.

O tipo date-and-time merece um caso de teste próprio. Pela semântica da RFC 9557 incorporada à RFC 9911, Z e +00:00 expressam UTC, mas não afirmam exatamente a mesma coisa: Z expressa UTC; +00:00 também afirma UTC como ponto de referência local. Um parser que sempre transforma os dois em uma única representação pode perder informação semântica. Um serializador que reescreve a forma pode alterar assinaturas, chaves de cache, comparações ou registros de auditoria. Isso não é uma acusação contra uma implementação específica; é uma exigência para decidir se a aplicação preserva o instante, a forma lexical original ou ambos.

As alterações de endereço e de nome de host também precisam de fixtures de migração. Tipos novos para link-local, address-and-prefix, host-name e email podem exigir nova análise de uma string antes aceita ou oferecer uma expressão mais clara para uma entrada antes rejeitada. A RFC 9911 ainda registra, para alguns tipos, equivalência ou não equivalência com textual conventions de SMIv2. Portanto, uma ponte entre SNMP, YANG e ferramentas de conversão não deve ser construída apenas a partir do nome do tipo.

O que migra, além do schema

O risco não termina na compilação. Um servidor pode selecionar uma revisão diferente no carregamento do schema; valores antigos podem ser revalidados ao recarregar, editar ou exportar o datastore; clientes NETCONF, RESTCONF e código gerado podem aplicar regras de normalização distintas. Um valor aceito por uma implementação não necessariamente será aceito com a mesma forma lexical por outra. Se um serializador produz +00:00, isso não prova que todos os consumidores tratarão essa entrada como idêntica a Z.

A RFC 9911 não permite declarar adoção universal, nem sustenta uma incompatibilidade total. Um cliente que fixa a revisão, um modelo que não usa os typedefs afetados ou um conjunto de dados que não é revalidado pode apresentar risco menor. Ainda é necessário descobrir quais servidores adotaram as revisões de 2025, se cada cliente fixa revisões e quais valores existentes falhariam sob os patterns revisados. Não se deve inferir o comportamento de um fornecedor sem evidência.

Fontes