Resumen

  • RFC 9907 es la Best Current Practice 216, publicada en marzo de 2026. Deja obsoleta RFC 8407 y actualiza RFC 8126. Ofrece pautas para autores y revisores de especificaciones que contienen modelos de datos YANG, incluidos los módulos mantenidos por IANA.
  • Su mecanismo es editorial, pero su objetivo es operativo: delimitadores de componentes de código, nombres únicos, encabezados completos, trazabilidad de revisiones hacia las RFC, semántica explícita de datastores, ejemplos, análisis de seguridad y procedimientos de registro.
  • No es un cambio del protocolo de cable y no garantiza implementaciones interoperables. Es disciplina de proceso para aumentar la interoperabilidad y usabilidad de NETCONF y RESTCONF.

Un modelo de datos YANG es la descripción conceptual de la información de gestión y sus relaciones. Un módulo individual es una realización de ese modelo en YANG; no deben tratarse como sinónimos. La diferencia importa cuando el revisor examina código extraído, importaciones, revisiones, ejemplos y el texto que los acompaña.

RFC 9907 trata los módulos y submódulos YANG normativos como componentes de código. Deben estar delimitados por las etiquetas CODE BEGINS y CODE ENDS. Los nombres publicados deben ser únicos: los módulos IETF normativos deben comenzar por ietf-, mientras que los módulos de ejemplo deben usar example-. Son controles sencillos que identifican el componente autoritativo y reducen la confusión entre material normativo e ilustración.

El encabezado del módulo forma parte de la especificación. Debe incluir la declaración vigente de copyright del IETF Trust e identificar el registro YANG Parameters. Las referencias que no provienen de módulos importados deben aparecer en declaraciones reference. Cada revisión publicada necesita una declaración cuya referencia identifique el documento que contiene el módulo. Así, el código extraído se convierte en un artefacto auditable y no en un fragmento sin procedencia.

La revisión también debe ir más allá de la sintaxis. YANG 1.1 establece las reglas del lenguaje, mientras que la arquitectura NMDA aporta la terminología de datastores y el contexto del estado operativo. Los autores deben explicar qué pertenece a cada datastore, cómo se relacionan configuración y estado, y qué significan el ciclo de vida y la operación de cada nodo. Que el módulo se analice sin errores no resuelve una frontera de autoridad omitida.

Los ejemplos ayudan a revisar, pero no son módulos normativos. Deben aclarar la estructura prevista sin presentarse como requisitos de implementación. El documento también debe analizar las consecuencias de seguridad, incluida la exposición de gestión creada por los datos y acciones modelados. En un módulo mantenido por IANA, la autoridad es un procedimiento explícito del registro; editar de forma ad hoc el texto generado no lo reemplaza.

Lista de comprobación antes de publicar

  1. ¿Todos los módulos y submódulos normativos están delimitados por CODE BEGINS y CODE ENDS?
  2. ¿Los nombres publicados son únicos, con ietf- para módulos IETF normativos y example- para ejemplos?
  3. ¿El encabezado contiene la declaración vigente del IETF Trust e identifica el registro YANG Parameters?
  4. ¿Las referencias externas a módulos importados aparecen en declaraciones reference?
  5. ¿Cada revisión identifica la RFC o el documento que contiene el módulo?
  6. ¿El texto distingue el modelo de datos de cada módulo que lo implementa?
  7. ¿Son explícitos los datastores NMDA, la configuración, el estado operativo, el ciclo de vida y la autoridad?
  8. ¿Los ejemplos están claramente marcados como no normativos y se analizan las implicaciones de seguridad?
  9. Para módulos mantenidos por IANA, ¿la política del registro es explícita y prevalece sobre cualquier edición del texto generado?
  10. ¿Puede rastrearse cada componente de código hasta su documento contenedor?

Camino de decisión para la aceptación del operador

Acepte el modelo solo cuando las diez preguntas tengan respuesta en el expediente de revisión. Si falta un delimitador, nombre, encabezado, referencia de revisión, límite semántico, etiqueta de ejemplo, análisis de seguridad o procedimiento de registro, devuélvalo para corregir la especificación. Si las respuestas están completas, acepte el documento como evidencia de preparación para la revisión, no como promesa de que todas las implementaciones serán interoperables. Escale antes de publicar cualquier duda sobre NMDA o autoridad registral: una vez que los consumidores construyen supuestos operativos, resulta más difícil revertirlos.

Fuentes