Resumen

  • RFC 3359 reunió los valores TLV de IS-IS en un mapa común para evitar colisiones, pero declaró expresamente que no era una norma ni una autoridad de asignación.
  • RFC 3563 convirtió después ese punto de coordinación en un registro mantenido temporalmente por IANA y revisado por expertos; registrar un número no demostraba software, despliegue ni resultado.

Dos diseñadores no necesitan actuar mal para producir una incompatibilidad. Basta con que consulten inventarios distintos, encuentren libre el mismo valor y lo asignen a extensiones diferentes. Cada programa puede ser coherente con su propia documentación. El conflicto aparece cuando ambos reciben el mismo número en el cable y ejecutan dos significados.

RFC 3359 apareció como documento Informativo en agosto de 2002 para dar memoria compartida a ese espacio. T. Przygienda recopiló valores TLV de nivel superior usados por IS-IS y por extensiones pendientes. La tabla indicaba su posible presencia en IIH, LSP y SNP y una procedencia general.

No era un catálogo normativo uniforme. Había entradas de ISO 10589, extensiones IP de RFC 1195, borradores IETF, una referencia antigua de DECnet y valores propietarios de Lucent y Nortel. Que una casilla figurara ocupada no convertía todos esos orígenes en estándares equivalentes. Su función mínima era advertir que alguien ya había dado significado al número.

La mezcla reflejaba la arquitectura institucional. El núcleo de IS-IS se mantenía en ISO; el IETF desarrollaba extensiones para Internet; empresas ya habían usado valores propios. Todos compartían el mismo espacio de ocho bits. Mirar solo el libro de una organización no bastaba para evitar la colisión global.

El RFC no ocultó su falta de poder. Dijo que buscaba evitar conflictos futuros, pero que no constituía ni representaba una norma o autoridad para asignar números. La coordinación ocurría de forma informativa entre ISO, SIF y grupos IETF. ISO no ofrecía una autoridad numérica y la competencia de IANA se describía entonces como limitada a códigos relacionados con IP. No había una autoridad central plausible.

La lista funcionaba por publicidad, no por coerción. Antes de elegir, un autor podía ver los valores usados o pendientes y apartarse. La motivación era preservar interoperabilidad. Una hoja compartida adquiría utilidad sin adquirir soberanía.

También dejaba huecos. No daba el documento exacto que definía cada valor ni resolvía los espacios de sub-TLV. Esperaba nuevas versiones o un futuro registro oficial. Por tanto, una fila era evidencia contra la reutilización, no un expediente completo.

RFC 3232 ya había sustituido el catálogo periódico Assigned Numbers por una base en línea. Esa forma viva evitaba publicar un nuevo RFC por cada alta. IS-IS necesitaba además una solución para el cruce entre ISO e IETF.

La solución institucional llegó con RFC 3563 en 2003. El acuerdo ISOC/IETF–ISO/IEC JTC1/SC6 separó ámbitos de trabajo y pidió a IANA mantener temporalmente el registro TLV hasta que JTC1 ofreciera el servicio.

Temporalmente no significa propiedad definitiva. El acuerdo permitía trasladar la autoridad de asignación a JTC1, mientras IANA podía conservar una copia informativa. Custodiar la página, aprobar un número y mantener el estándar eran funciones distintas.

El estado inicial debía sincronizarse con RFC 3359. El mapa informal no fue descartado: se convirtió en punto de partida. Las nuevas asignaciones requerían aprobación de un experto designado por IESG. El IETF informaría a JTC1/SC6 y este remitiría sus solicitudes al proceso IANA.

El registro creaba una puerta común, no software. La especificación debía definir el formato, una implementación debía programarlo, el operador configurarlo y los vecinos interpretarlo de la misma forma. Ninguna de esas etapas cabía en una casilla.

La propia tabla cambió. RFC 6233 añadió una columna Purge para señalar qué TLV podía aparecer en un LSP purgado. El contexto del PDU condiciona la validez; por eso la forma del registro también transporta una parte limitada de la semántica.

RFC 7370 refinó el proceso en 2014. Reunió registros de sub-TLV que compartían espacio y dio instrucciones para asignaciones antes de publicar un RFC. La petición debía proceder normalmente de un documento adoptado por un grupo o patrocinado por un director de área. El experto comprobaba consenso o aprobación, evaluaba mérito técnico sin imponerse al consenso IETF y aplicaba caducidad o retirada si el documento no avanzaba.

RFC 7120 proporciona disciplina general para asignaciones tempranas y RFC 7370 adapta el camino a Expert Review. RFC 8126 define las políticas de registro. Una política explica quién debe revisar y qué evidencia presentar; no asegura que una implementación funcione.

La fricción excesiva también rompe coordinación. RFC 9650 cambió en 2024 un registro de bits de atributo de enlace desde Standards Action a Expert Review. El requisito anterior impedía asignar bits a protocolos experimentales y elevaba el riesgo de usar valores no registrados, el llamado codepoint squatting. Una puerta demasiado estrecha empuja la actividad fuera del inventario.

El equilibrio consiste en hacer más fácil coordinar que ocupar en secreto. Poca revisión desperdicia valores y permite ambigüedad. Demasiada revisión vuelve incompleto el registro. Referencia pública, revisión limitada y fecha de caducidad intentan mantener el espacio común útil.

La página actual de IANA muestra el resultado vivo: registros anidados, columnas, referencias y políticas que no estaban completos en 2002. Esta investigación conserva una instantánea fechada. No presenta la forma actual como eterna.

Una fila tampoco es código ejecutándose. Prueba una asociación registrada entre número, nombre, referencia y política. No demuestra que el analizador la entienda, que aparezca en el PDU correcto, que dos proveedores interoperen, que esté activada, que se instale una ruta o que llegue tráfico.

Para eso hacen falta recibos posteriores: matrices de capacidad, pruebas, configuración, capturas, registros, estado de base y medición de tráfico. El registro alinea vocabulario; no reemplaza la operación.

Dos textos de Lu Heng sirven como lentes declaradas. “Minimum Initial Specification” ayuda a entender la utilidad de un mínimo común antes de resolver la custodia futura. “Reality Layers” separa el número, la norma, el código, el despliegue y el resultado. No atribuyen nuevas intenciones al autor del RFC.

La lista no podía ordenar una asignación. Sin embargo, ofrecía un hecho común antes de elegir, y ese hecho podía evitar que dos decisiones privadas correctas crearan un cable público imposible de interpretar.

Fuentes