Resumen

  • RFC 1264 dividió la madurez de un protocolo de enrutamiento entre especificación reproducible, gestión, arquitectura de seguridad, implementaciones independientes, pruebas completas, experiencia operativa y límites de escala.
  • RFC 4794 eliminó en 2006 ese requisito adicional para todo documento de enrutamiento por su coste temporal, pero mantuvo la facultad del IESG de pedir experiencia y la opción de los grupos de trabajo de conservar procedimientos propios.
  • Los procesos posteriores no fundieron estatus y ejecución: RFC 6410 vinculó Internet Standard con interoperabilidad independiente, despliegue amplio y operación satisfactoria; RFC 7942 hizo útil, aunque voluntario y no necesariamente verificado, el registro de implementaciones.

La entrada no llevaba un solo sello

RFC 1264 trató el enrutamiento como un algoritmo distribuido y en tiempo real. Un programa podía funcionar en un entorno y fallar cuando otro código interpretaba un borde de forma distinta. Una topología pequeña podía ser estable mientras un límite imprevisto esperaba a una red diez veces mayor.

Por eso el expediente tenía cajones distintos. La especificación y su uso debían permitir que terceros desarrollaran implementaciones interoperables sin consultar a los autores. La MIB definía el estado administrable. La arquitectura de seguridad describía la autenticación. El origen del código, los escenarios, los resultados, el entorno operativo y el análisis de escala respondían preguntas posteriores.

Ningún cajón completaba a los demás. Definir autenticación no demostraba que dos implementaciones la ejecutaran; publicar una MIB no demostraba que un operador detectara un fallo; escribir con claridad no probaba un despliegue.

La independencia era una afirmación de procedencia

La regla general pedía varias implementaciones interoperables y al menos dos escritas independientemente. Dos productos derivados del mismo código pueden repetir la misma lectura y el mismo error. Dos orígenes separados comprueban mejor si el documento coordina por sí mismo.

La lista debía identificar la procedencia del código, y el informe debía describir casos y resultados. Para Draft Standard, todas las funciones tenían que operar entre al menos dos implementaciones, incluidas las funciones de seguridad y la protección que pretendían ofrecer. Contar productos no sustituía una matriz de cobertura.

La interoperabilidad observada seguía limitada a versiones, entradas y condiciones. No probaba automáticamente escala multivendedor, resistencia a todas las amenazas ni un resultado de servicio.

La experiencia operativa necesitaba coordenadas

El informe debía incluir topología, entorno, fecha, duración, implementaciones, resultados y conclusiones. Había que ejercitar las funciones significativas. Un EGP debía transportar el conjunto completo de rutas exteriores; un IGP debía manejar rutas interiores y exteriores salvo que otro mecanismo asumiera estas últimas.

La carga cambiaba por nivel. Proposed Standard requería una implementación y pruebas de las funciones principales, pero no experiencia operativa. Draft Standard exigía experiencia significativa con un número moderado de routers y una topología moderadamente compleja dentro de Internet operativo. Standard elevaba la prueba a muchos routers, complejidad y operación multivendedor.

Eran condiciones de avance, no una certificación automática de que cada candidato las hubiera cumplido. La decisión y su informe debían conservar identidades propias.

El segundo informe preguntaba por la rotura

Además del expediente de implementación, RFC 1264 pedía un análisis de los algoritmos y del consumo normal de ancho de banda, memoria y CPU. Debía proyectar el crecimiento en entornos al menos un orden de magnitud mayores y nombrar los límites y contextos inadecuados.

Así, “escalable” dejaba de ser un adjetivo. Pasaba a depender de supuestos, recursos y una frontera. La comparación con protocolos existentes permitía examinar la mejora alegada.

Pero un modelo seguía sin ser una observación. El límite previsto, el ensayado y el encontrado en producción podían ser distintos. Separarlos evitaba que una curva se presentara como recibo de despliegue.

En 2006 cambió la autoridad

RFC 4794 reclasificó RFC 1264 como Historic. Sostuvo que aplicar siempre una regla extra a una clase de protocolos demoraba la publicación y que el proceso general ya podía contener propuestas poco razonables. No afirmó que el enrutamiento se hubiera vuelto sencillo ni que la operación dejara de importar.

La retirada fue precisa: desapareció el requisito amplio para todos los documentos. Los directores del área aún podían pedir implementaciones u operación mediante RFC 2026. Los grupos de trabajo podían mantener procedimientos inspirados en RFC 1264. Gestión y seguridad seguían bajo políticas generales.

La potestad pasó de una lista universal al juicio del IESG y de cada grupo. La flexibilidad aumentó, pero también la necesidad de explicar quién pidió qué evidencia, ante qué riesgo y por qué bastaba.

Dos niveles conservaron una diferencia material

RFC 2026 ya describía Proposed Standard como una etapa inmadura que podía cambiar. Normalmente no requería implementación ni operación, aunque el IESG podía exigirlas para protocolos centrales o con impacto operativo significativo.

RFC 6410 redujo después la vía a Proposed Standard e Internet Standard. Para este último mantuvo dos implementaciones independientes interoperando, despliegue amplio y experiencia operativa satisfactoria, además de controles sobre erratas, funciones no usadas y licencias.

“Despliegue amplio” tampoco describe por sí solo una red concreta. Sin versiones, población, periodo y observación, no prueba que un operador activara una función ni que obtuviera un resultado.

El registro ligero declaró sus límites

RFC 7942 propuso una sección voluntaria de Implementation Status para Internet-Drafts. Podía registrar madurez, licencia, experiencia, contactos e informes de interoperabilidad, de modo que el código real informara antes el debate.

Su texto advertía que una entrada aportada por contribuyentes no era aprobación del IETF, podía no haber sido verificada independientemente y no constituía un catálogo completo. Era una frontera de procedencia: ayudaba a decidir, pero no reemplazaba artefactos de prueba, telemetría ni evidencia de despliegue.

Fuentes y límites

La lista de 1991 procede de RFC 1264, la autoridad general de RFC 2026, y la retirada de RFC 4794. El modelo de dos niveles está en RFC 6410, y el estado voluntario de implementaciones en RFC 7942.

Estas fuentes establecen procedimientos y motivos. No demuestran que un protocolo concreto cumpliera la lista, que una implementación declarada fuera verificada, que un operador la desplegara ni que los usuarios recibieran un resultado. Historic no borra la evidencia antigua ni vuelve falsa una afirmación por sí solo.