Resumen

  • RFC 3933 situó los cambios experimentales entre la decisión informal del IESG y la modificación permanente de una BCP, con Last Call, alcance limitado y caducidad explícita.
  • El diseño limitó la duración de la autoridad, pero no exigió formular el problema, fijar criterios de éxito ni publicar por qué la prueba funcionó o fracasó.

La pregunta podía llegar después del reloj

La innovación de RFC 3933 no fue declarar que el IETF debía aprender de la experiencia. Fue construir un estado documental para hacerlo sin convertir de inmediato una idea en práctica permanente. El registro del RFC Editor lo conserva como BCP 93. Frente a la discreción informal permitida alrededor de RFC 2026 y al proceso completo de consenso y grupos descrito por RFC 2418, la nueva vía aceptaba una regla limitada antes de saber si merecía permanencia. RFC 1396 documentaba el trasfondo organizativo de 1992; RFC 3933 transformó la provisionalidad en un procedimiento visible.

La secuencia era concreta. Un Internet-Draft describía el cambio. El IESG juzgaba si parecía útil. Un Last Call de cuatro semanas abría la propuesta al IETF. Un segundo borrador respondía a las objeciones y el texto se publicaba como Experimental. El alcance podía reducirse a áreas o grupos escogidos. La decisión debía reflejar rough consensus y seguía siendo apelable.

El experimento tenía que declarar un sunset, por lo general no superior a un año. El erratum verificado añade una coma, no altera la obligación. Antes de vencer, la práctica debía pasar a una BCP o expirar. El tiempo de la autorización estaba controlado.

No ocurría lo mismo con la prueba del resultado. La descripción del problema era deseable, no obligatoria. Los criterios específicos también. El IESG podía basarse en la impresión general de que la comunidad estaba mejor o peor. Un documento que explicara el éxito o el fracaso era deseable, pero no requisito realista.

Esa decisión protegía la ligereza del mecanismo. También permitía que una experiencia terminara con un estado, pero sin una explicación transportable. La fecha demuestra que la excepción no debía durar indefinidamente. No demuestra cuántas veces se utilizó, qué carga añadió, quién quedó fuera, cuántas apelaciones hubo o qué alternativa habría producido el mismo resultado.

Terminar no era lo mismo que archivar

RFC 4693 propuso las IETF Operational Notes. El ensayo duraría doce meses desde el primer ION y terminaría con una consulta: hacer permanente la serie, abandonarla o continuar. Su autor descartó las métricas objetivas y confió en que la actitud comunitaria revelaría el resultado.

El IESG cerró la experiencia en marzo de 2008. RFC 6393 no movió RFC 4693 a Historic ni la declaró obsoleta hasta septiembre de 2011. No es evidencia de un daño ni una medición del fracaso. Es evidencia de dos relojes: uno para la autoridad operativa y otro para el estado archivístico. Quien consultara solo la etiqueta Experimental durante el intervalo podía no conocer la decisión efectiva.

Otros experimentos añadieron más estructura. RFC 5111 limitó los Exploratory Groups a dieciocho meses y tres grupos, y enumeró progreso de hitos, creación posterior de un WG y actividad en la lista. RFC 4633 dio dieciocho meses a mecanismos ampliados de suspensión en listas, prohibió que la sanción sobreviviera al ensayo y exigió anuncios públicos. El plazo contenía poder; los indicadores y registros determinaban cuánto podía aprenderse.

El experimento de NomCom hizo obligatorio el puente

La interrupción de reuniones presenciales volvió inadecuado el proxy de asistencia de RFC 8713. RFC 8989 abrió una prueba de uno, como máximo dos, ciclos del NomCom. Pero no se limitó a fijar el final. Obligó a consultar a los presidentes de los ciclos, publicar un informe y discutir si se debía modificar la norma, extender una última vez, ensayar otra cosa o volver atrás.

El texto nombró lo que debía observarse: tamaño y diversidad del conjunto de voluntarios, conocimiento suficiente del IETF, representatividad y criterios comprobables de manera mecánica. RFC 9389 convirtió después vías derivadas de aquel ensayo en BCP 10 y dejó obsoleta RFC 8989. La BCP prueba una decisión normativa posterior; no prueba por sí sola cada efecto ni una causalidad exclusiva. Aun así, el vínculo documental es más fuerte porque el informe formaba parte del diseño.

La lectura histórica exige tres columnas. Autorización: quién podía probar la regla. Experiencia: qué casos y efectos quedaron registrados. Disposición: si expiró, se prolongó o entró en una BCP. Confundirlas convierte el estado de un documento en evidencia que no contiene.

Los ensayos de procedimiento también aclaran el uso editorial de los textos de Heng Lu sobre especificación mínima y adopción voluntaria y primacía del código en ejecución. La publicación coordina; la decisión institucional dispone; la conducta observada muestra lo que se volvió real. RFC 3933 disciplinó la primera y la tercera fecha, pero no garantizó el registro de la segunda capa.