Resumen

  • DAWN figuraba como grupo Proposed el 27 de agosto de 2026. Su primera carta, 00-00, estaba en revisión interna del IESG/IAB; la votación preguntaba si podía abrirse la revisión externa, no si el WG quedaba constituido.
  • NETCONF sí era Active, pero 20-02 era una propuesta de cambio de carta. Datatracker mantenía la versión 20 como carta actualmente aprobada.
  • RFC 2418 trata la carta aprobada como un compromiso institucional limitado a determinadas tareas y separa redacción, examen comunitario, aprobación del IESG y anuncio de la Secretaría.
  • Una carta aprobada autoriza dónde estudiar un problema. No adopta un Internet-Draft, no demuestra consenso técnico, no convierte el resultado en RFC ni obliga a ningún operador a desplegarlo.

El problema de confundir actualidad con vigencia

En un repositorio técnico, «actual» suele significar la revisión que contiene las últimas correcciones. En un registro de gobernanza, la palabra tiene al menos dos sentidos. Uno identifica el texto más nuevo sometido a consideración. El otro identifica el texto del que la institución obtiene hoy sus facultades.

La diferencia se vuelve visible al comparar creación y reforma. En una carta inicial, todavía no existe un mandato aprobado; el campo de carta vigente debe ser nulo aunque el proyecto sea completo. En una reforma, el grupo ya existe; la carta anterior sigue delimitando su trabajo hasta que una decisión identificable la sustituya.

Guardar una sola referencia latest falla de dos maneras. Para DAWN adelanta el nacimiento del grupo. Para NETCONF adelanta la muerte de la versión 20. Un registro fiel necesita dos referencias autónomas —propuesta más reciente y carta aprobada vigente— y debe tratar el vacío de la primera creación como información, no como dato defectuoso.

El error no se queda en la pantalla. El alcance anticipado empieza a recibir agenda, editores y código. Una contribución individual puede ser presentada como dirección del WG. Otro grupo o una entidad de normalización externa puede ceder terreno. Una empresa puede vender como compromiso del IETF lo que todavía es una solicitud. Si el texto termina estrechándose, el historial de inversiones no se estrecha con él.

DAWN estaba preparado para ser cuestionado

La página de DAWN decía «Proposed WG Discovery of Agents With Names». El estado era Proposed; la carta, charter-ietf-dawn-00-00; y la etapa, Start Chartering/Rechartering (Internal Steering Group/IAB Review).

La propuesta no era vaga. Describía el descubrimiento de agentes y recursos de IA, escenarios locales, intraorganizacionales e interorganizacionales, mecanismos que podían contribuir a la solución, responsables previstos, entregables, fechas y exclusiones. Precisamente por ser concreta podía examinarse. Una propuesta no adquiere vigencia por parecer ejecutable.

La papeleta de la carta formulaba la decisión del momento: «Is this charter ready for external review?». Éric Vyncke registró Yes; Mohamed Boucadair, Block; los demás nombres mostraban No Record. El resumen indicaba que había posiciones suficientes para superar esa etapa una vez resuelto el bloqueo.

El comentario de Boucadair apoyaba la iniciativa, pero pedía aclarar qué desencadena el descubrimiento, qué modelos de operación se contemplan, cómo cambian los límites de confianza entre lo local y lo interorganizacional y si un solo protocolo puede cubrir todos los casos. Era una objeción sustantiva al alcance. No era una condena definitiva del tema ni una facultad personal para impedirlo para siempre.

Tampoco el Yes aprobaba más de lo preguntado. Borrar la pregunta transformaría «puede exponerse a revisión externa» en «ya existe el grupo». El historial de DAWN mostraba la publicación de 00-00, la apertura de la papeleta y el paso a examen interno el 24 de agosto, seguido del Block del día 25. No mostraba la decisión final de constitución.

La agenda del BoF en IETF 126 añadía pruebas de trabajo preparatorio: terminología, casos de uso, requisitos y una discusión extensa de la carta. Un BoF puede demostrar interés, capacidad y desacuerdo. No reemplaza al órgano que la propia regla señala para crear el WG.

Después de la fecha de observación, DAWN puede avanzar, cambiar o detenerse. El artículo no presume el desenlace. Exige únicamente que una decisión futura opere hacia adelante y no reescriba la preparación como ejercicio retroactivo de una competencia todavía inexistente.

NETCONF conservaba una carta mientras examinaba otra

La ficha de NETCONF lo presentaba como grupo Active, con trabajo consolidado en torno a NETCONF, RESTCONF, YANG, telemetría y gestión de redes.

La página de su carta mostraba charter-ietf-netconf-20-02, actualizada el 12 de agosto y en revisión interna como reforma. Pero incluía una frase de control: la información correspondía a una propuesta de nueva carta, mientras que la carta actualmente aprobada era la versión 20.

No había un único objeto llamado «carta de NETCONF». Había un grupo activo, una versión 20 que seguía otorgando alcance y un texto 20-02 que solicitaba modificarlo. La revisión del tercero no suspendía los dos primeros.

La papeleta de NETCONF también preguntaba por la preparación para revisión externa. Christopher Inacio conservaba un Block porque faltaban hitos. Mahesh Jethanandani registró Yes y varios miembros No Objection. El resumen decía que el trámite podía avanzar una vez resuelto el Block. Ninguna de esas posiciones convirtió 20-02 en la carta aplicable ese día.

Una petición de cambios puede producir 20-03 o una revisión posterior; una retirada deja intacta la versión 20; una aprobación debe señalar qué texto final entra en vigor, qué versión sale y en qué momento. El estado histórico puede expresar cualquiera de esas salidas sin fingir que el proyecto se aplicó desde su fecha de publicación.

El adelanto altera además los incentivos. Mientras el alcance es propuesto, quien lo amplía debe justificar la necesidad y la ubicación. Si se permiten reuniones, adopciones e implementaciones como si el permiso ya existiera, la revisión llega después de una inversión acumulada. El revisor pasa a defender una «retirada» y el solicitante obtiene una presunción que el procedimiento nunca le concedió.

El proceso distribuye conocimiento y responsabilidad

La base publicada seguía siendo RFC 2418, parte de BCP 25. La carta se negocia normalmente entre la futura presidencia y el Area Director competente; el IAB aporta asesoramiento y el IESG da la aprobación final. Tras la revisión interna, la propuesta se difunde a una comunidad más amplia. El IESG puede aprobar, cambiar o rechazar, y la Secretaría registra y anuncia el grupo aprobado.

RFC 2418 llama a la carta un contrato entre el IETF y el WG para un conjunto de tareas. No se trata de un contrato mercantil ni de una delegación política de toda persona afectada. Es un límite institucional: concede un foro abierto, dirección procedimental y atención colectiva para preguntas identificadas.

El límite sirve a quienes están dentro y fuera. La presidencia puede aplazar intervenciones ajenas al alcance sin cerrar la participación. Grupos vecinos pueden detectar solapamientos. Otras organizaciones pueden saber cuándo coordinarse. Los posibles colaboradores pueden decidir dónde invertir. Si las premisas cambian, la reforma, el cambio de presidencia o el cierre siguen siendo opciones formales.

RFC 3710 asigna piezas distintas. La iniciativa puede nacer de participantes o de un Area Director. La futura presidencia convierte la idea en un plan. Los participantes aportan experiencia, apoyo y objeciones. El IAB mira consecuencias arquitectónicas. La revisión abierta expone problemas de seguridad, privacidad, operación o relación con terceros. El Area Director coordina; el IESG responde por la decisión institucional.

Que participar no equivalga a autorizar no convierte la consulta en ceremonia. Una objeción puede modificar el texto, reducir tareas, añadir coordinación o mostrar que el grupo aún no es viable. La participación crea legitimidad como fuente de evidencia y contradicción; no como ficción de que cada participante representa a todo afectado.

Cuando aparece trabajo valioso fuera de alcance, el procedimiento permite reformar, usar otro grupo, trabajar fuera de un WG o crear uno nuevo. La alternativa a la anexión silenciosa no es necesariamente la parálisis.

Del permiso para preguntar a la decisión de desplegar

La carta aprobada habilita un espacio de problemas, no una solución. Dentro de ese espacio, una contribución individual puede ser evaluada. Adoptar un Internet-Draft significa escoger una base de trabajo, no aceptar todas sus afirmaciones. Rough consensus, Working Group Last Call, evaluación del IESG y publicación como RFC llegan después y tienen responsables diferentes. Incluso al publicarse, el flujo y la categoría determinan su estatus.

La operación forma otro escalón. RFC 3935 describe una IETF que produce documentos técnicos relevantes, pero no controla ni patrulla Internet y no puede imponer su utilización. El despliegue exige un propietario, una versión concreta, pruebas, alcance, condiciones de reversión y evidencia del sistema en marcha.

El propio draft-ietf-procon-2418bis-04 confirmaba esta separación. El 27 de agosto era un WG Document con estado IESG I-D Exists. Su cabecera decía que haría obsoletos RFC 2418 y RFC 3934 si fuese aprobado. Omitir ese condicional inventaría la aprobación.

El texto del draft define la carta como compromiso con un alcance y aclara que la adopción de un Internet-Draft no demuestra consenso sobre el contenido. La carta de PROCON autoriza consolidar una cadena concreta de RFC de proceso y exige reformar la carta para otros cambios sustanciales. El permiso para redactar no es la aprobación anticipada de lo redactado.

Qué debe contener el recibo de sustitución

El primer dato es el tipo de acto: INITIAL_CHARTER o RECHARTER. Después vienen el grupo, su estado, el identificador y la revisión de la propuesta, y una huella exacta del texto. En otra referencia independiente se guarda la carta actualmente aprobada y su huella, o un nulo explícito antes de la creación.

El ámbito debe registrar tareas añadidas, eliminadas y conservadas, exclusiones, entregables, grupos colindantes y coordinaciones externas. El examen debe conservar Area Director, presidencias, fecha de apertura, pregunta exacta de cada votación, posiciones, Blocks, condiciones de resolución, estado del asesoramiento del IAB, anuncio externo y tratamiento de objeciones materiales.

La decisión debe nombrar el resultado del IESG, la razón pública, la fecha, el anuncio de la Secretaría, la entrada en vigor y la carta sustituida. Aprobación, devolución, continuidad de la carta anterior, retirada, rechazo y disolución son resultados expresos, no ausencia de datos.

Por último, la carta aprobada necesita dos límites transportables: no prueba consenso sobre un documento concreto y no exige implementarlo. Decir lo que la carta no hace preserva la fuerza de lo que sí hace.

Fuentes

  1. IETF Datatracker: grupos en creación o reforma
  2. IETF Datatracker: grupo DAWN propuesto
  3. IETF Datatracker: papeleta de la carta DAWN
  4. IETF Datatracker: historial de la carta DAWN
  5. IETF Datatracker: agenda del BoF DAWN en IETF 126
  6. IETF Datatracker: propuesta de nueva carta NETCONF
  7. IETF Datatracker: carta NETCONF aprobada, versión 20
  8. IETF Datatracker: grupo NETCONF activo
  9. IETF Datatracker: papeleta de la carta NETCONF
  10. RFC 2418: directrices y procedimientos de los WG del IETF
  11. RFC 3710: carta del IESG
  12. RFC 6292: requisitos de las herramientas de cartas
  13. IETF Datatracker: estado de draft-ietf-procon-2418bis
  14. IETF Datatracker: texto de draft-ietf-procon-2418bis
  15. IETF Datatracker: carta del WG PROCON
  16. RFC 3935: declaración de misión del IETF
  17. RFC 9281: entidades del proceso de estándares del IETF