Resumen

  • draft-ietf-procon-2026bis-11 fue publicado el 1 de julio de 2026 y seguía en Working Group Last Call el 27 de agosto. Conserva el mecanismo de variancia de RFC 2026, pero todavía no es la BCP que sustituye al texto vigente.
  • El grupo de trabajo responsable, o un comité ad hoc cuando no existe grupo, puede recomendar una excepción para una especificación particular que se encuentre en un bloqueo o ante una laguna del proceso. Recomendar no equivale a aprobar.
  • El IESG debe justificar mérito, beneficios y costes, alternativas, efectos colaterales y de precedente, y la máxima estrechez posible. La propuesta se publica como Internet-Draft, pasa por un Last Call de al menos cuatro semanas y, si se aprueba, se publica como BCP. Cabe apelación.
  • No pueden dispensarse los plazos especificados, la apertura, la equidad, el consenso, el registro público ni varios mecanismos centrales. El resultado es un recibo de una sola excepción: no una reforma permanente, un precedente automático ni una orden para que operadores desplieguen la tecnología.

Cómo una casilla contamina el proceso

La diferencia entre una regla y una excepción parece obvia mientras ambas están delante de quienes tomaron la decisión. Se vuelve frágil cuando el expediente entra en un inventario, un tablero de cumplimiento o la memoria de una institución.

Un grupo identifica que una especificación valiosa no puede cumplir un requisito concreto. Formula una recomendación, se examinan alternativas, hay consulta pública y el IESG aprueba una salida estrecha. Hasta ahí, el sistema ha tratado una anomalía sin negar la regla. El problema empieza si la base de datos conserva sólo la frase «requisito dispensado».

En el siguiente caso, el software encuentra una decisión anterior y propone reutilizarla. La plantilla omite el nombre de la especificación, la versión, el requisito exacto, los motivos y las restricciones. Nadie ha modificado la BCP, pero la operación diaria ya actúa como si el requisito hubiese dejado de existir.

La solución no consiste en esconder las decisiones anteriores. RFC 2026 pide al IESG que considere los efectos de precedente, de modo que la historia sí es relevante. Consiste en mantener una frontera de datos: la regla vigente es un objeto; cada variancia es otro objeto, vinculado a una sola especificación y a su propia cadena de autoridad. Un caso anterior informa sobre riesgos y coherencia. No satisface la carga de prueba del caso nuevo.

Esta arquitectura también protege la reforma legítima. Si las mismas excepciones se repiten, el patrón puede apoyar una modificación permanente de la BCP mediante el procedimiento ordinario. Si cada excepción ya ha alterado silenciosamente la plantilla, la comunidad pierde tanto la regla como la evidencia necesaria para decidir si debe cambiarla.

Estado real de 2026bis

La ficha de Datatracker muestra draft-ietf-procon-2026bis-11 como documento activo del grupo PROCON. El campo Intended RFC status de la ficha dice None, mientras que la cabecera del propio borrador declara Best Current Practice como estado pretendido. Ninguno de esos rótulos equivale a una decisión ya adoptada. La revisión -11 apareció el 1 de julio de 2026 y expira el 2 de enero de 2027 si no se actualiza o progresa. El historial registra que el 21 de mayo, durante la revisión -08, el grupo lo llevó a Working Group Last Call.

El 27 de agosto aún figuraba como In WG Last Call; el estado IESG era I-D Exists y no había fecha de teleconferencia. Son señales verificables de trabajo avanzado dentro del grupo. No son una aprobación IESG, una publicación RFC ni una nueva norma en vigor.

Si termina aprobado, el texto consolidará y dejará obsoletos varios RFC del proceso, entre ellos RFC 2026, y actualizará RFC 7475. La carta de PROCON explica que las reglas fundamentales se dispersaron a través de más de veinte actualizaciones de RFC 2026 y RFC 2418. El grupo debe reunirlas, incorporar erratas verificadas y producir sucesores legibles. Sólo dos familias concretas de cambios no editoriales están incluidas; otros asuntos exigen modificar la carta.

La sección 11 de la revisión -11 conserva la salida excepcional. No la inventa. La sección 9 de RFC 2026, publicada en 1996 y parte de BCP 9, ya contiene su estructura esencial. El borrador consolida y renumera; su registro de cambios no presenta la variancia como una innovación de 2026.

Por eso una descripción responsable necesita tres tiempos. RFC 2026 es la autoridad publicada actual. 2026bis-11 es la propuesta vigente que está revisando el grupo. Un eventual RFC sucesor sólo pasará a ser la nueva base cuando el proceso produzca y publique esa decisión. Mezclar los estados convierte una intención documentada en un hecho institucional consumado.

Quién puede abrir la excepción

La puerta no se abre por iniciativa indistinta. El grupo de trabajo responsable recomienda una variancia. Si no hay un grupo responsable, puede hacerlo un comité ad hoc. Esta regla localiza el conocimiento y la responsabilidad: el órgano cercano al expediente formula la necesidad, pero no se concede a sí mismo la salida.

El IESG recibe la recomendación y debe decidir si el beneficio probable para la comunidad de Internet supera el coste de incumplir el requisito. La pregunta no es sólo si la especificación es buena. Incluye su mérito técnico, la posibilidad de alcanzar los objetivos del proceso por la ruta normal, las alternativas, los daños colaterales, los efectos de precedente y la capacidad de limitar la excepción tanto como sea posible.

La lista distribuye la carga de prueba. Quien propone la variancia debe mostrar por qué el problema es específico y por qué las rutas ordinarias no bastan. Quien decide debe explicar por qué los costes institucionales están justificados. Quien consulta puede atacar tanto el diagnóstico como el alcance. La mera urgencia, la popularidad o la inversión acumulada no responden por sí solas a ninguna de esas preguntas.

Además, el IESG puede restringir la variancia a determinadas disposiciones e imponer condiciones adicionales. Una excepción a un requisito no suspende el resto del proceso. La salida debe parecerse a una incisión, no a una puerta trasera permanente.

La cadena pública de decisión

Una recomendación interna sería demasiado fácil de recordar de forma selectiva. RFC 2026 exige convertir la propuesta en un objeto público.

El texto debe identificar el problema percibido, la disposición exacta que causa la dificultad y el examen del IESG. Debe publicarse como Internet-Draft. Después, el IESG emite un Last Call extendido de no menos de cuatro semanas. Una vez concluido, adopta una decisión final y la anuncia al IETF. Si aprueba la variancia, ésta se envía para publicación como BCP. El procedimiento de apelación sigue disponible.

No todos esos actos prueban lo mismo. La recomendación prueba que un órgano responsable pide considerar la excepción. El Internet-Draft prueba qué se propuso y en qué versión. El Last Call prueba que hubo un intervalo mínimo de examen, no que el silencio equivalga a consentimiento. La decisión prueba lo que resolvió el IESG. La publicación estabiliza el resultado aprobado. La apelación, si existe, abre otra secuencia con objeto y resolución propios.

RFC 7282 aporta un criterio útil para leer la consulta. El rough consensus no es una votación disfrazada. Importan el contenido de las objeciones y la forma en que fueron atendidas. Un expediente que sólo conserva cantidades de mensajes no demuestra que la cuestión difícil fue entendida o resuelta.

Esa cadena de custodia es costosa por diseño. Una variancia trivial de conceder sería barata de repetir y difícil de distinguir de una vía ordinaria alternativa. La fricción pública hace que el órgano decisor tenga razones para mantener la salida estrecha y usarla únicamente cuando el atasco lo justifique.

Lo que nunca entra en la dispensa

Una buena excepción define tanto la zona flexible como el suelo inmóvil. RFC 2026 impide que una variancia rebaje plazos expresamente fijados. Tampoco permite prescindir de apertura, equidad o consenso, ni de registros adecuados de reuniones y conversaciones en listas. Protege además secciones esenciales sobre revisión de BCP, inicio de actuaciones, examen del IESG, publicación, resolución de conflictos, apelaciones y la propia variancia. 2026bis-11 conserva ese diseño con referencias renumeradas.

La prohibición tiene una razón estructural. Si la excepción pudiera eliminar el registro, la consulta o el recurso que permiten controlarla, el resultado sería imposible de distinguir de una decisión informal de poder. El mecanismo seguiría teniendo nombre, pero habría borrado las pruebas que hacen verificable su legitimidad.

El mínimo de cuatro semanas refuerza esa idea. No es tiempo muerto antes de un resultado ya decidido. Permite que personas que no participaron en el grupo inspeccionen la disposición concreta, los efectos laterales y la estrechez de las condiciones. Reducir ese tiempo mediante la propia variancia convertiría la urgencia alegada en autoridad para ocultar sus consecuencias.

El suelo no garantiza unanimidad ni elimina la discreción del IESG. Garantiza que la discreción deja rastro, ocurre ante una comunidad capaz de objetar y no destruye el procedimiento de recurso.

El recibo que debe sobrevivir al resumen

Una variancia debería poder reconstruirse sin recurrir a recuerdos. El recibo empieza con un identificador, la especificación objetivo, su revisión y huella, el grupo o comité responsable, la fecha y el texto de la recomendación. Debe nombrar la disposición de BCP, el bloqueo o vacío observado, el requisito incumplido y la razón por la que la vía normal no resuelve el caso.

La parte analítica conserva el mérito técnico, la comparación de beneficios y costes, las alternativas descartadas, los efectos colaterales y de precedente, el alcance exacto y cualquier restricción añadida. La parte pública vincula el Internet-Draft y su huella, las fechas de apertura y cierre del Last Call, las objeciones materiales y su tratamiento.

La parte decisoria registra la resolución del IESG, el anuncio, la identidad de la BCP si se aprobó, las apelaciones y la condición que termina la excepción. Al final deben aparecer dos límites expresos: esta decisión no autoriza otra especificación y no demuestra que un operador haya adoptado o desplegado la tecnología.

El recibo evita que la palabra BCP produzca otra confusión. Una variancia aprobada se publica como BCP para que la decisión sea estable y pública. Eso no cambia su alcance de un solo caso. La reforma de la regla reutilizable sigue otra ruta: la sustitución de la BCP de proceso mediante los procedimientos abiertos normales.

Proceso interno y decisión de despliegue

Una variancia modifica el tratamiento de una especificación dentro del proceso IETF. No decide lo que una empresa, un operador, una administración o un proyecto de software debe hacer después.

RFC 9281 describe los papeles del grupo, el IESG y otras entidades que intervienen en el proceso. La autoridad está distribuida y atribuida; una excepción no habilita a terceros para cambiar estados documentales por inferencia. RFC 3935 recuerda, por su parte, que un estándar explica cómo hacer algo cuando se afirma conformidad, y que el IETF no pretende obligar ni vigilar universalmente su uso.

El registro operativo debe quedar separado. Una decisión de despliegue necesita responsable, versión, pruebas, superficie afectada, fecha, criterios de reversión y evidencia de adopción real. La variancia puede formar parte del contexto, pero no sustituye ese expediente. Presentarla como orden externa convertiría una salida procesal interna en un mandato que ninguna de sus fuentes concede.

El marco de Heng Lu sobre especificación inicial mínima, decisión futura localizada y adopción voluntaria permite expresar la misma frontera: cada capa decide sólo dentro de su autoridad y conserva la procedencia de la decisión. Se usa aquí como lente de gobernanza, no como fuente de las reglas IETF.

Fuentes