Resumen

  • RFC 6410 redujo de tres a dos los niveles de madurez, pero los Draft Standards ya existentes conservaron su clasificación salvo reclasificación explícita.
  • Las nuevas reglas permitían avanzar con pruebas de despliegue o que el IESG optara por volver a Proposed Standard después de dos años; no hubo limpieza automática.

Análisis

Qué exigía el nivel anterior

En octubre de 1996, RFC 2026 definió tres niveles de madurez para los estándares: Proposed Standard, Draft Standard e Internet Standard. Una especificación podía llegar a Draft Standard después de que existieran al menos dos implementaciones independientes e interoperables, basadas en código distinto, y suficiente experiencia operativa satisfactoria. El presidente del grupo de trabajo debía documentar las implementaciones que cumplían el requisito y sus pruebas de interoperabilidad. Draft Standard era una categoría de madurez para una especificación publicada, no otro nombre para un Internet-Draft.

El nivel siguiente respondía a otra pregunta. RFC 2026 asociaba Internet Standard con experiencia significativa de implementación y operación y con una creencia ampliamente compartida de que el protocolo beneficiaba a la comunidad de Internet. La escala separaba la primera evidencia de implementación de una madurez más extensa.

El cambio de 2011

RFC 6410 señaló que muy pocas especificaciones habían avanzado durante la década anterior y que la gran mayoría seguía como Proposed Standard. Fusionó Draft Standard y Standard en un nivel: Internet Standard. El despliegue y la experiencia operativa siguieron siendo parte de los criterios: al menos dos implementaciones independientes e interoperables debían tener despliegue amplio y un funcionamiento satisfactorio. También se revisaban erratas que impidieran interoperar y funciones sin uso que añadieran mucha complejidad.

La revisión retiró otras dos obligaciones. RFC 2026 pedía revisiones anuales de las especificaciones que no habían alcanzado el nivel más alto; según RFC 6410, en la práctica no se hacían, así que se eliminó ese ciclo. También dejó de exigir un informe formal de interoperabilidad. Las pruebas seguían siendo importantes: RFC 6410 consideró que el despliegue y el uso bastaban para mostrar interoperabilidad, y RFC 5657 seguía siendo una guía útil para preparar informes.

Una transición, no una reclasificación general

La regla transitoria trató los estados anteriores de forma distinta. Los Proposed Standards siguieron como Proposed. Los Internet Standards existentes pasaron de inmediato a Internet Standard. En cambio, un documento que ya era Draft Standard conservaba esa clasificación mientras no hubiera una acción explícita. Podía avanzar si cumplía los nuevos criterios. Tras dos años desde la aprobación de RFC 6410 como Best Current Practice, el IESG también podía decidir reclasificarlo como Proposed Standard.

No fue una degradación automática, una promoción ni un reinicio de toda la lista. La etiqueta anterior seguía asociada al documento hasta que otra decisión la cambiara. RFC 6410 no cuenta cuántos documentos permanecieron así ni indica cuándo se reclasificó cada uno.

La etiqueta y la red

RFC 6410 simplificó el avance futuro, pero una categoría no se convirtió en un censo del software en uso. Un Draft Standard heredado de la escala anterior no demostraba por sí solo interoperabilidad actual ni despliegue amplio. A la inversa, dejar de exigir un informe formal después de 2011 no volvió irrelevantes las pruebas: los criterios revisados conservaron las implementaciones independientes y el uso satisfactorio.

El registro es acotado: un cambio en el proceso y sus reglas transitorias. No muestra qué había desplegado cada operador. Es fácil pasar por alto la diferencia operativa cuando una etiqueta sobrevive al proceso que la creó.

Fuentes