Resumen

  • OPSAWG adoptó VELOCE y el 25 de agosto de 2026 publicó la revisión 00 como documento del grupo. Ese estado no equivale a un RFC, un BCP ni a una regla final del IETF.
  • El resumen atribuido de la reunión de ese día dice que se confirmó el puntero de IANA. El texto del grupo aún declara explícitamente que no hay acciones IANA, y la pull request 49, con estados, hashes y rutas de aprobación, seguía abierta y sin fusionar al cierre de la investigación.
  • Una reunión de proyecto no sustituye una decisión de consenso del grupo confirmada en la lista. Una fusión en el repositorio no sustituye la aprobación del grupo, de un Area Director o del IESG. Una fila de IANA puede identificar un resultado autorizado sin adjudicarse la autoridad que lo autorizó.
  • El borrador ya exige una versión etiquetada, no la cabeza cambiante de una rama. Lo pendiente es enlazar el consenso, la versión inmutable, la solicitud de registro y la versión contra la que se puede probar conformidad.

La misma fecha no convierte cuatro actos en uno

La conclusión de la adopción encontró apoyo suficiente para convertir el texto individual en draft-ietf-opsawg-veloce-yang-00, sin otro cambio. La ficha de Datatracker registra la revisión 00 como documento de trabajo desde el 25 de agosto. Es un acto relevante de custodia del documento: el grupo se hace cargo de él. No es una aprobación anticipada de todas las decisiones que pueda contener una revisión posterior.

El experimento evita poner el módulo YANG dentro del RFC. En su lugar, el RFC enlazaría una versión concreta y etiquetada en un repositorio. La diferencia técnica tiene una consecuencia institucional. La rama principal puede cambiar después de la publicación; un commit o una etiqueta identificada permite recuperar los mismos bytes. El borrador prevé además que un módulo adoptado pueda actualizarse en un repositorio IETF y que solo cambie la referencia del RFC. Eso puede reducir el coste de corregir un módulo pequeño sin reabrir por completo el contenedor editorial. No elimina la necesidad de saber quién aprobó la corrección.

Antes de IETF 126, los autores formularon la pregunta con franqueza. Una discusión pública pregunta si el RFC debe apuntar a una etiqueta Git, a una entrada IANA u otro destino; qué debería resolver un puntero a la última versión; qué versión deben usar los implementadores; y cómo se comprueba conformidad después de una actualización. Las minutas de OPSAWG recogen posiciones distintas sobre GitHub, un entorno controlado por IETF, IANA, archivo y recuperación. La conversación se quedó sin tiempo programado y continuó en la lista. Esa divergencia documenta una decisión aún por cerrar, no una infracción de nadie.

El resumen atribuido del 25 de agosto añade que el repositorio GitHub se mantendría para el experimento, que se aceptarían issues y pull requests, que las opiniones de reuniones quincenales se resumirían en la lista y que las objeciones llevarían a más discusión antes de fusionar. También dice que se confirmó la indirección IANA. Hay que conservar la etiqueta de esa evidencia. Es el relato de una reunión de proyecto, no una llamada formal de consenso del grupo ni una decisión del IESG. RFC 8874 dice que el trabajo en GitHub no recibe un estatus especial y que las decisiones de consenso del grupo deben confirmarse en la lista de correo. La reunión puede orientar; no puede absorber ese requisito.

La revisión 00, en cambio, tiene una sección IANA que declara que el documento no requiere acciones. RFC 8126 trata una sección explícita de no acción como una determinación consciente de que IANA no tiene nada que hacer con el texto presentado. No impide que una versión siguiente incluya una instrucción correcta. Impide decir que la arquitectura de puntero ya se convirtió en una acción IANA cuando el borrador publicado aún no la contiene.

Un campo propuesto no es todavía una política de registro

La pull request 49 estaba abierta y sin fusionar en la fecha de corte. Propone un registro de referencias de archivos y módulos YANG, con estados permanente y propuesto, URL exacta, SHA-256, contactos responsables y caminos de aprobación por IESG u otros actores definidos. Es una arquitectura sensata para no mezclar funciones: el hash fija los bytes; el estado separa candidato y referencia vigente; el contacto atribuye custodia; y la ruta de aprobación nombra quién toma una decisión de fondo.

Nada de eso era aún una fila pública de IANA. El registro actual de nombres de módulos YANG usa la política RFC Required y muestra nombre, archivo, espacio de nombres, prefijo, referencia y notas. No muestra los campos VELOCE propuestos para hash, estado de aprobación, contacto controlador o recibo de decisión. De ello se sigue una cautela sencilla: no hay base en el registro congelado para afirmar que IANA creó ese espacio, aceptó su regla o descargó una versión del proyecto.

Los verbos tienen sujeto distinto. Un autor abre un cambio. Un revisor y un mantenedor pueden aceptarlo en el repositorio. El grupo puede formar consenso. Un Area Director o el IESG puede realizar la aprobación que el diseño especifique. IANA ejecuta una inscripción limitada. La fila resultante preserva la identidad de una versión. Una etiqueta, una fusión, una decisión de consenso y una fila no son sinónimos ni pruebas automáticas entre sí.

Separarlos defiende a todos los participantes. Si una fila IANA decide que un cambio es maduro, el registrador deja de ser registrador. Si una fusión basta para acreditar consenso, la regla del repositorio ocupa el lugar de la deliberación del grupo. Si una etiqueta prueba adopción, se confunden bytes repetibles con una elección del operador. La lectura más equilibrada reconoce que VELOCE ya conserva consenso en su texto y excluye una rama móvil; que PR 49 intenta limitar, no ampliar sin freno, la discreción de IANA; y que una primera revisión del grupo puede legítimamente ir detrás de un debate no resuelto.

El recibo mínimo entre aprobación y puntero

La solución no requiere un RFC nuevo para cada modificación delimitada ni crea una nueva instancia de veto. Para cada versión posterior, un recibo público podría enlazar:

  1. el efecto normativo reclamado y el grupo que controla el asunto;
  2. la llamada de consenso de la lista, sus fechas, objeciones y disposición de la presidencia;
  3. la versión exacta del texto que solicita el registro y el actor de aprobación;
  4. URL del repositorio, commit, etiqueta y suma SHA-256;
  5. autor, revisores, persona que fusiona y autoridad aprobadora como roles separados;
  6. solicitante de IANA, hora de solicitud, bytes recuperados, verificación y transición desde la fila previa;
  7. versión de publicación, última versión aprobada y versión objetivo de las pruebas de conformidad;
  8. compatibilidad, pruebas, espejos, respaldo, reversión y retirada; y
  9. evidencia de implementación u operación, guardada aparte del acto de registro.

El recibo no llama consenso a una conversación productiva. Enlaza la posterior confirmación pública. Tampoco convierte la transacción IANA en un juicio técnico. El actor autorizado decide si una versión candidata puede ser vigente; IANA verifica y registra el artefacto aprobado bajo la norma acordada. Así el puntero se convierte en prueba consultable, no en un parlamento pequeño.

La nota 63 de Heng Lu sirve como lente institucional, no como evidencia sobre VELOCE. Custodia y procedencia pueden hacer auditable una decisión sin apropiarse del derecho a tomarla. Eso es justamente lo que debe hacer el registro. La disciplina alcanza también a la conformidad: RFC 9907 sigue siendo el BCP publicado para módulos YANG, con afirmaciones normativas tratadas como prosa normativa de RFC y registros IETF XML y YANG Module Names para módulos nuevos o actualizados. VELOCE puede ofrecer otra disposición; al cierre aún no había sustituido ese punto de partida.

Sources

  1. OPSAWG charter
  2. VELOCE Datatracker record
  3. IETF 126 OPSAWG minutes
  4. Pull request 49
  5. Heng Lu Note 63
  6. IANA YANG parameters
  7. OPSAWG VELOCE adoption result
  8. VELOCE pointer discussion
  9. 25 August VELOCE call summary
  10. draft-ietf-opsawg-veloce-yang-00
  11. RFC 8126
  12. RFC 8874
  13. RFC 8875
  14. RFC 9907