Resumen

  • La revisión 03 plantea que los módulos YANG normativos lleguen a la aprobación del IESG con una versión preliminar, pasen por edición controlada, reciban fecha y YANG Semver finales, se validen de nuevo y solo entonces se publiquen casi a la vez en el RFC y en IANA.
  • Quitar el sufijo, superar pyang y yanglint o comparar dos hashes responde a preguntas distintas; ninguna respuesta demuestra por sí sola preservación semántica, versión correcta, descarga, carga, compatibilidad o resultado.
  • Un módulo publicado por IETF y un módulo mantenido por IANA a partir de un registro compañero no son la misma clase de artefacto ni siguen el mismo reloj de actualización.

El detalle más importante es el que suele borrarse del relato. Cuando un documento alcanza una hipotética aprobación del IESG, el módulo normativo que contiene puede seguir marcado como prerelease. Ese estado permite al RFC Editor corregir y pulir antes de que una combinación de fecha y versión se vuelva inmutable.

La guía que propone este mecanismo sigue siendo ella misma provisional. La consulta del 11 de septiembre de 2026 muestra draft-ietf-netmod-iana-yang-guidance-03 como Internet-Draft activo del WG NETMOD, con estados WG Document e I-D Exists y destino Informational. La revisión 03 está fechada el 6 de julio de 2026 y vence el 7 de enero de 2027. El “Last updated” del 27 de agosto corresponde a cambios del AD responsable y del estado previsto, no a una revisión 04. No es un RFC y no acredita que IANA o el RFC Editor ya ejecuten este procedimiento.

La edición está autorizada por tipo de cambio

La frontera propuesta no depende de quién toca el archivo, sino de qué cambia. Clarificar una descripción sin alterar su sentido, actualizar una referencia al número RFC definitivo, corregir una errata o normalizar el formato cabe dentro del trabajo editorial. Una modificación sustantiva exige coordinación con los autores. La incertidumbre entre editorial, BC y NBC abre una consulta, no una excepción silenciosa.

Al finalizar, se actualiza la fecha de revisión y se elimina el indicador preliminar. También se decide el YANG Semver de salida. Si el módulo ya tuvo una edición publicada, hay que compararlo con ella y añadir rev:non-backwards-compatible cuando corresponda. Si cambian los bytes después, se repite la decisión de versión. El número final es así una conclusión documentada sobre un candidato concreto.

El contexto de validación forma parte del resultado

El borrador recomienda volver a validar tras la edición y el formato, en general con pyang y yanglint. No basta con nombrar la herramienta. Deben conservarse versión, parámetros, bytes y conjunto de dependencias. Varios módulos que van a publicarse juntos quizá tengan que extraerse y comprobarse como unidad.

La propia guía enumera las insuficiencias. Un programa no siempre sabe si el nuevo texto de una descripción mantiene el significado. El comparador puede detectar violaciones conocidas sin verificar todas las decisiones exactas de Semver. Existen falsos positivos, falsos negativos y casos no cubiertos. Si la versión anterior también es prerelease, la recomendación automática de una versión estable puede no estar disponible.

Por eso un resultado limpio significa “esta ejecución aceptó esta entrada”. No significa “la semántica es idéntica”, “todos los clientes compilarán lo mismo” ni “la actualización es segura”.

Dos editores coordinan el instante de publicación

El paso operativo más nítido pide que IANA espere hasta que el RFC Editor haya terminado. Solo con los bytes finales, el RFC publicaría el módulo e IANA colocaría la versión correspondiente en YANG Module Names aproximadamente al mismo tiempo. Así se evita que una copia intermedia adquiera vida propia y se corrige la referencia al RFC final.

La prueba adecuada es reproducible: extraer los bytes del RFC, recuperar el objeto IANA, registrar hora y URL, y comparar sus hashes con fecha y versión. Si coinciden, queda probado el acuerdo entre dos superficies de publicación en esos instantes. Quedan abiertos la caché de una URL mutable, el artefacto elegido por el cliente, la resolución del package, las dependencias, el proceso que cargó el módulo, el conjunto efectivo de features/deviations, YANG Library, la migración de instancias y el comportamiento observado.

La cobertura previa de BTW sobre nombres de fichero, comparación de esquemas, ramas de versión y packages conserva esos mecanismos. Esta pieza se limita a la transferencia editorial que congela un candidato y lo entrega a dos publicadores.

El registro compañero manda en la otra rama

La guía distingue además los módulos mantenidos por IANA. Suelen ser representaciones de enums e identities derivados de registros compañeros. Una asignación nueva entra primero en el registro autorizado; después IANA identifica el cambio, lo representa en el módulo, añade fecha y versión, revisa BC/NBC, valida y publica artefactos identificables por versión y fecha.

Ese proceso demuestra una correspondencia acotada entre un delta del registro y una edición del módulo. No demuestra que la proyección estuvo siempre al día, que todas las filas se mapearon bien, que un cliente la recuperó o que un dispositivo la usa. El artículo existente sobre RFC 9907 conserva la cuestión de autoridad y frescura; aquí importa no mezclarla con la coordinación de publicación de un módulo IETF.

El cierre exige una cadena, no un certificado universal

Conviene retener por separado el candidato prerelease aprobado, los cambios y consultas editoriales, el juicio final de versión, las entradas exactas de validación, los bytes del RFC, los bytes de IANA, la recuperación del cliente, la carga y el esquema efectivo del dispositivo, y la evidencia de datastore, protocolo, tráfico y servicio.

Running-Code Primacy, de Heng Lu, aporta una regla de lectura explícita y no una intención atribuida al IETF: publicar un punto de coordinación no hace que los participantes lo adopten. Minimum Initial Specification valora que cada regla común sea estrecha y verificable. Reality, Not Advocacy y Reality Layers impiden que un recibo documental se disfrace de ejecución.

Dos copias idénticas son una mejora real. Precisamente por eso deben conservar un borde limpio: certifican la publicación, no la red.

Fuentes

  1. Texto de la revisión 03
  2. Registro actual en Datatracker
  3. Historial en Datatracker
  4. RFC 9907
  5. RFC 9890
  6. RFC 7950
  7. YANG Module Versioning, revisión 17
  8. YANG Semantic Versioning, revisión 26
  9. YANG Schema Comparison, revisión 09
  10. YANG module filename, revisión 14
  11. Parámetros YANG de IANA
  12. Heng Lu — Running-Code Primacy
  13. Heng Lu — Minimum Initial Specification
  14. Heng Lu — Reality, Not Advocacy
  15. Heng Lu — Reality Layers