Resumen

  • draft-ietf-netmod-yang-next-agreement-00 propone cuatro destinos: cambios que deberían entrar, cuestiones que podrían considerarse, trabajo que no debería entrar en la próxima versión y asuntos cerrados o propuestos para cierre.
  • El resultado es un recibo de clasificación de la revisión 00. Ni el grupo, ni closed en GitHub, ni WG Document demuestran por sí solos acuerdo punto por punto, inclusión final, significado normativo, compatibilidad, viabilidad, herramientas o adopción.

Una cola de 160 asuntos no es un diseño. Tampoco se convierte en uno por ordenar sus tarjetas.

El mérito de YANG Next Agreement consiste en reconocer esa distancia. El repositorio netmod-wg/yang-next había acumulado, según la revisión 00, unos 125 asuntos abiertos y 35 cerrados. Había correcciones pequeñas, cambios incompatibles, ideas de lenguaje y problemas que quizá pertenecían a protocolos. Si la próxima versión se definía solo por quién tenía tiempo para trabajar en cada incidencia, el resultado podía ser grande, desigual y difícil de adoptar.

El borrador coloca una decisión de alcance antes de la escritura normativa. Esa inversión es importante. Sin ella, una contribución bien preparada puede adquirir más peso que un objetivo compartido simplemente porque ya tiene autor y código.

El estado del documento no resuelve su contenido

El registro actual del Datatracker identifica la revisión 00 como Internet-Draft activo del grupo NETMOD, actualizado el 23 de junio de 2026. Muestra WG Document como estado del grupo y I-D Exists como estado IESG. El campo estructurado de Intended RFC status no contiene valor. La cabecera del propio texto dice Intended status: Informational y fija el 25 de diciembre de 2026 como fecha de expiración.

Es una diferencia documental que debe conservarse, no corregirse por narración. El Datatracker y la cabecera responden a superficies distintas. Ninguna autoriza a decir que el IETF aprobó el listado o que cada elemento de la primera categoría formará parte de un estándar.

El borrador es más modesto: quiere discutir y, con suerte, encontrar acuerdo sobre el alcance y la forma de la siguiente versión de YANG. También afirma que no tiene como objetivo publicarse como RFC. Su función es hacer visible un mapa de problemas para que el grupo pueda evaluarlo.

Cuatro destinos para contener la segunda versión

La primera categoría reúne cambios que los autores creen que deben añadirse a una futura versión. La segunda deja espacio a cuestiones que merecen estudio si hay suficiente interés. La tercera aplaza ideas para una versión posterior. La cuarta contiene asuntos que no deberían seguir, ya están cerrados o se proponen para cierre.

El valor estratégico está en las dos últimas. Un proyecto de lenguaje suele crecer porque cada necesidad local parece razonable y porque eliminar una función futura cuesta reputación. Hacer explícito el aplazamiento permite elegir una especificación inicial menor. El grupo puede experimentar con un núcleo y reservar decisiones difíciles para cuando existan mejores datos.

Pero “debería añadirse” sigue siendo juicio de los autores. La misma sección advierte que algunas aclaraciones quizá no requieran cambios después de examinarlas. El apéndice Issue 152 presenta una clasificación alternativa. Eso demuestra que la tabla no es una fotografía neutral del consenso; es una propuesta trazable para producirlo.

Cerrado no equivale a refutado

La sección de cierres mezcla al menos seis situaciones: asuntos ya cerrados en GitHub, asuntos abiertos cuyo cierre propone el autor, duplicados, malentendidos sobre YANG, cambios considerados dañinos y problemas que deberían vivir en un rastreador de protocolos. También aparecen razones como poca prioridad, complejidad o existencia de una solución alternativa.

Una única bandera no puede representar esas decisiones. Un duplicado conserva el problema en otro identificador. Trasladar un asunto a protocolos cambia el responsable, no niega la necesidad. Un cierre propuesto aún requiere discusión. Una idea rechazada por incompatibilidad con YANG 1.1 puede volver a evaluarse bajo una ruptura de versión mayor. De hecho, el borrador explica que algunos asuntos cerrados reaparecen en otras listas porque las circunstancias cambiaron.

Por eso el registro mínimo de una decisión debe unir identidad, fecha, conversación, categoría en una revisión concreta, motivo y resolución posterior del grupo. Si una base de datos conserva solo closed, ha conservado una posición de flujo y ha perdido el razonamiento.

El consenso comienza donde aparece una objeción

Las actas de NETMOD ayudan a separar etapas. En IETF 120 había interés, pero no claridad sobre si el objetivo era YANG 1.1, 1.2 o 2.0. El presidente pidió motivaciones y objetivos, y recordó que Git no sustituía el proceso de consenso. En IETF 121, un equipo auto-seleccionado había puntuado los asuntos. La discusión insistió en devolver el resultado al grupo y crear una visión de alto nivel antes de invertir años en cambios.

Adoptar un documento resumen como trabajo del grupo ofrecía un modo de pedir respaldo a esa dirección. No significaba que el respaldo para cada fila ya existiera.

RFC 7282 refuerza esta lectura. Rough consensus no es una mayoría visible. Requiere encontrar objeciones razonadas, entenderlas y demostrar que fueron atendidas. Para cada propuesta YANG Next, la evidencia de consenso debe mostrar qué texto se discutió, qué objeciones surgieron, cómo se resolvieron y qué alcance tuvo la conclusión de los presidentes.

El mapa ocupa solo el segundo peldaño

Hay una secuencia verificable. Primero, inventario: asunto exacto, autor, ejemplo, estado y fecha. Segundo, clasificación: categoría de la revisión 00, motivo y alternativas. Tercero, consenso: lista, reunión, objeciones, respuestas y evaluación de presidencia. Cuarto, norma: texto exacto y dependencias de una revisión posterior.

Luego llegan compatibilidad —gramática, semántica, módulos, extensiones, deviations, clientes y servidores—; implementación —herramientas independientes, casos negativos e interoperabilidad—; y despliegue —migración gradual, observabilidad, reversión y efectos medidos—.

El borrador ofrece sobre todo el segundo peldaño. Eso ya reduce una incertidumbre real. Pretender que ofrece los demás solo desplaza el riesgo a quienes mantienen y operan los sistemas.

Mantener separadas las obras vecinas

El borrador YANG 2.0 propone una base de lenguaje. Module versioning describe identidad y ramas. Schema comparison clasifica diferencias bajo entradas declaradas. Module filename trata nombres y alias. YANG Packages resuelve composiciones de módulos. Ninguno demuestra que las cuatro categorías tengan consenso; las categorías tampoco definen esos mecanismos.

Una empresa proveedora debería leer “incluir” como petición de diseño y pruebas. Un mantenedor, como motivo para abrir una rama experimental y un corpus. Un operador, como señal de seguimiento, no de migración. El grupo debería usarlo para plantear preguntas pequeñas que puedan recibir una evaluación precisa.

La disciplina de especificación inicial mínima de Heng Lu encaja aquí: publicar primero el perímetro comprobable, localizar las decisiones futuras y permitir que la adopción voluntaria siga a resultados reproducibles. Las etiquetas pertenecen a la capa simbólica de coordinación. La realidad empieza cuando el texto compila, dos implementaciones coinciden y un operador puede observar y revertir la consecuencia.

Fuentes

Documento e historial: YANG Next Agreement revisión 00; registro Datatracker; historial Datatracker.

Proceso y contexto: actas NETMOD de IETF 120; actas NETMOD de IETF 121; RFC 7282; RFC 7950, YANG 1.1; borrador YANG 2.0 revisión 00.

Marco interpretativo: Minimum Initial Specification; On Reality Layers; Running Code Primary.