Resumen

  • En IETF 126, PROCON acordó proponer una frase de carta que obliga a reflejar con precisión la política vigente. En la fecha límite de esta investigación, Datatracker seguía mostrando únicamente la carta aprobada en 2025; la frase nueva no era aún autoridad operativa.
  • La carta actual ya permite cambios no editoriales limitados sobre hitos de los grupos de trabajo y adopción de Internet-Drafts. También autoriza un BCP separado sobre delegación y sucesión temporal de la presidencia de IETF; otros asuntos exigen volver a constituir el mandato.
  • 2418bis reúne cambios de naturaleza distinta: elimina las referencias de 51 % y 99 % para el consenso, regula funciones auxiliares, amplía los foros públicos y explica que la adopción puede revertirse. 2026bis añade ejemplos de cómo incluso una palabra o una excepción pueden alterar el alcance.
  • Describir una práctica no demuestra que ya sea política normativa. Pero una diferencia con el RFC antiguo tampoco prueba que el grupo se haya excedido: algunas revisiones están expresamente autorizadas.
  • Conviene crear un registro ligero por diferencia relevante, con el texto base, la práctica alegada, la clasificación, la cláusula habilitante, las objeciones, la decisión del grupo y los estados posteriores de revisión y publicación.
  • El registro no sería otra puerta de aprobación. También separaría la publicación de un BCP de su adopción real en Datatracker, herramientas, formación y conducta de los grupos.

La frase que ordena describir el presente aún no forma parte del presente

PROCON intenta resolver una deuda de legibilidad. RFC 2026 y RFC 2418 siguen sosteniendo el proceso de estándares y la vida de los grupos de trabajo, pero sus actualizaciones se dispersan entre RFC posteriores, erratas y formas de trabajo que no existían cuando fueron escritos.

La carta aprobada de PROCON manda integrar los RFC que actualizan esos dos documentos y las erratas verificadas o reservadas para una actualización. También abre deliberadamente un margen no editorial en dos áreas: los hitos de un grupo de trabajo y la adopción de borradores. Un BCP sobre delegación de la presidencia de IETF y sucesión temporal constituye otro producto autorizado. Lo adicional requiere una nueva carta.

Por eso no basta con comparar una frase nueva con el texto de 1998. Una diferencia puede juntar autoridad ya aprobada; trasladar un deber intacto a herramientas actuales; convertir una práctica extendida en regla escrita; o introducir una decisión de política dentro de la discreción que la propia carta concede. El problema no es escoger de antemano la categoría más severa, sino saber qué afirmación pretende sostener el grupo.

Las diapositivas de la presidencia en IETF 126 reconocieron el choque. La lectura habitual del programa había sido documentar con exactitud y claridad el proceso vigente, dejando extensiones y cambios de política para más adelante. Pero una lectura estricta podía expulsar hasta correcciones editoriales o ajustes a una realidad operativa transformada. Se presentó primero un texto largo que nombraba RFC, declaraciones de IESG y cambios en herramientas.

Las actas de la sesión recogen una salida más breve: el grupo acordó proponer que los documentos resultantes reflejen con precisión la política vigente. Las propias actas indican que fueron redactadas con IA y revisadas y actualizadas por las presidencias y participantes. Son una relación revisada de decisiones, no una transcripción literal.

Al corte del 2 de septiembre de 2026, Datatracker seguía presentando charter-ietf-procon-01, actualizada el 9 de julio de 2025, como carta aprobada. La frase acordada en IETF 126 debe tratarse como propuesta a IESG. No es todavía el mandato vigente ni puede convalidar hacia atrás cualquier diferencia producida antes de su aprobación.

Eliminar dos porcentajes exige conservar la razón

draft-ietf-procon-2418bis-04 elimina el párrafo de RFC 2418 que advierte que un apoyo de 51 % no equivale necesariamente a consenso aproximado y que incluso 99 % puede ocultar una objeción sustantiva. La presentación de 2418bis describe los porcentajes como reglas orientativas que confunden. Las actas registran que se mantuvo la supresión y que no se añadió una referencia sugerida a RFC 7282.

La decisión puede defenderse como corrección de una pedagogía peligrosa: números tan memorables facilitan que el consenso se lea como votación. Pero el registro duradero debe unir el párrafo de base, esa justificación, el principio que permanece y la decisión del grupo. La mera supervivencia de una eliminación no explica qué se intentó conservar.

Las funciones auxiliares ilustran un tipo distinto de cambio. La revisión 04 dice que presidencias y Area Directors pueden nombrar o cesar participantes en funciones de apoyo. Aclara que esos puestos no modifican la decisión por consenso ni reducen las responsabilidades esenciales de presidencias y Area Directors. La sesión resolvió revisar la redacción, conservando esa barrera de responsabilidad.

Un mensaje público de PROCON afirma desde la experiencia del remitente que muchos grupos no nombran formalmente un Document Editor y pregunta si el nuevo texto debería recogerlo. La aportación sirve como origen atribuible de una tesis sobre la práctica. No es un censo, ni convierte por sí sola la costumbre en política. El paso normativo ocurre cuando el grupo decide qué práctica describir y con qué límites.

De la lista de correo al foro público

RFC 2418 habla desde una época dominada por listas de correo. La revisión 04 incluye entre los foros públicos el correo, los grupos de chat y otras herramientas colaborativas, y pide resumir y documentar adecuadamente sus resultados.

Si la obligación de publicidad y trazabilidad no cambia, el ajuste puede ser una corrección de mecanismo obsoleto. Pero las nuevas palabras también abren preguntas: qué chat tiene carácter oficial, qué facultades de moderación se aplican allí, cuándo una conversación efímera entra en el expediente del consenso. El evaluador necesita saber si se está preservando el mismo deber o ampliando una competencia.

La adopción de borradores dispone de una autorización más explícita. El texto explica que adoptar una propuesta solo la convierte en base de un asunto de trabajo, sin expresar consenso sobre su contenido, y que el grupo puede devolverla a estado no adoptado. La carta vigente incluye justamente la adopción entre los ámbitos donde cabe un cambio no editorial. Esta custodia reversible puede ser una reforma deliberada y legítima, no una desviación que deba esconderse bajo la palabra «actualización».

La retirada de un texto no borra el desacuerdo sobre su clase

Las diapositivas de 2026bis separan ajustes llamados editoriales, cuestiones aplazadas y trabajo previo a otra última llamada del grupo. En IETF 126 se decidió revertir el texto de la revisión 09 sobre discusiones no públicas de una apelación y sustituir Unicode por IEEE 802 Ethernet como ejemplo de estándar externo.

La discusión pública sobre alcance conserva argumentos enfrentados. Un participante consideró que permitir esa discreción cambiaba la política fuera del mandato; una respuesta la relacionó con RFC 2026 y la práctica actual. Solo prueba que esas posiciones fueron planteadas. No constituye una sentencia institucional. Al revertir el texto, el grupo resuelve la siguiente versión, no la cuestión general de cómo reconocer una clarificación frente a una reforma.

También se aplazó cambiar «expired» por «inactive». En el intercambio público se admite que el segundo término refleja mejor Datatracker, pero no está claro que sea meramente editorial. Si sincroniza un nombre de interfaz sin alterar consecuencias, parece una corrección técnica. Si redefine un estado procesal, entra en política. El tamaño tipográfico de una diferencia no revela su importancia.

Un registro mínimo para no perder el fundamento

No hace falta una segunda maquinaria de estándares. El registro puede limitarse a diferencias que afecten quién actúa, cómo se expresa el consenso, qué foro deja constancia, cuándo cambia la custodia de un documento o cómo opera una apelación. Cada entrada tendría doce elementos:

  1. revisión inmutable y sección o diff exacto;
  2. RFC, errata o declaración que sirve de base;
  3. prueba pública de la práctica o de la herramienta invocada;
  4. clasificación como consolidación, corrección de mecanismo obsoleto, codificación de práctica o revisión deliberada;
  5. cláusula de la carta, nueva carta propuesta o explicación de por qué no hace falta potestad adicional;
  6. motivo editorial;
  7. objeciones relevantes, debidamente atribuidas;
  8. decisión y fecha del grupo;
  9. modificaciones de la última llamada del grupo;
  10. tratamiento en IETF Last Call e IESG;
  11. texto finalmente publicado;
  12. evidencia separada de adopción operativa.

Una diferencia puede tener dos etiquetas. Actualizar el concepto de lista pública puede corregir una herramienta y codificar una práctica a la vez. Lo que no debería aceptar el sistema es un vacío sin justificación. «Práctica vigente» debe apuntar a evidencia; «corrección» debe decir qué deber permanece; «revisión» debe indicar la vía autorizante.

Incluir objeciones no les concede poder de veto. Un correo mantiene su autor y su contexto. La decisión del grupo ocupa otro campo. Si la propuesta se retira, el registro conserva ese desenlace sin darle vida normativa.

La Nota 64 de Heng Lu aporta una lente: fijar un mínimo común, localizar decisiones futuras en la autoridad competente y mantener aparte la adopción voluntaria u operativa. No es fuente factual sobre PROCON ni regla de IETF. Sirve para advertir que base, decisión posterior y adopción no son un único acontecimiento.

La cadena de revisión decide, pero no ordena sola su memoria

IETF ya dispone de controles importantes. El consenso del grupo, Working Group Last Call, IETF Last Call, revisión del Area Director y evaluación de IESG pueden corregir un mal resultado. En IETF 126, el Area Director dijo que 2026bis quedaría dentro del alcance con la actualización propuesta, aunque reconoció no haber estudiado aún en profundidad los diffs de 2418bis.

El inventario de documentos de PROCON mostraba 2026bis-11 en última llamada del grupo y 2418bis-04 como documento del grupo. Ningún estado significa aprobación de IESG ni publicación como BCP. Las revisiones posteriores pueden resolver parte de la incertidumbre que hoy se observa.

Pero aprobar por etapas no conserva automáticamente por qué cada cambio se consideró consolidación, corrección, codificación o reforma. La razón puede estar en un correo, el desacuerdo en una presentación, la decisión en las actas y la versión resultante en un changelog. Todo es público y, a la vez, difícil de reconstruir como una sola historia de autoridad.

El registro no compite con esos controles. Si una revisión posterior cambia la clasificación, lo deja visible. Si la diferencia desaparece, registra el cierre. Si una alegación de práctica resulta débil, permite sustituirla por otro fundamento o retirar el texto. La revisión mantiene su libertad y gana memoria.

Fuentes

  1. Carta aprobada de PROCON
  2. Inventario de documentos de PROCON
  3. Actas de PROCON en IETF 126
  4. Diapositivas de la presidencia de PROCON
  5. Actualización de 2026bis
  6. Presentación de 2418bis
  7. Nota 64 de Heng Lu
  8. Discusión pública sobre el alcance
  9. Discusión pública sobre la práctica del Document Editor
  10. Discusión pública sobre inactive y expired
  11. draft-ietf-procon-2026bis-11
  12. draft-ietf-procon-2418bis-04
  13. RFC 2026
  14. RFC 2418