Resumen

  • La RFC 9650 cambia de Standards Action a Expert Review el procedimiento del registro IS-IS Neighbor Link-Attribute Bit Values para permitir asignaciones experimentales coordinadas y reducir colisiones por valores no registrados.
  • El experto juzga una solicitud de asignación según una guía pública; no garantiza seguridad, interoperabilidad, implementación, adopción ni efecto en el encaminamiento.
  • Una decisión operativa exige recibos separados para solicitud, revisión, registro, compilación, habilitación autorizada, anuncio, análisis del vecino, política local, ruta y servicio observado.

La negativa que un buen experto debe conservar

Una revisión concluye que una extensión puede recibir un bit. El resultado no contiene una opinión sobre el producto que algún día la implemente. Tampoco afirma que los routers vecinos la entenderán. Esa ausencia no es una carencia: es la frontera que mantiene responsable a cada actor.

La RFC 9650 modifica un único procedimiento. La RFC 5029 exigía Standards Action para futuras asignaciones en un campo de 16 bits. Según la nueva RFC, la exigencia era demasiado restrictiva para protocolos experimentales y elevaba el riesgo de usar puntos de código sin registrar, práctica llamada code point squatting. La sustitución por Expert Review facilita reservar un símbolo antes de disponer de un estándar terminado.

La coordinación llega antes. La aprobación técnica total no.

El objeto de la decisión cabe en 16 bits

La RFC 5029 define el sub-TLV Link-Attributes, subtipo 19, con un campo de banderas de dos octetos. Asignó 0x1 a Local Protection Available y 0x2 a Link Excluded from Local Protection. El sub-TLV es opcional, debe aparecer como máximo una vez por vecino y un router no compatible lo ignora silenciosamente.

El registro de IANA muestra hoy el procedimiento Expert Review, identifica a los expertos y referencia las RFC 5029, 9667 y 9650. 0x4, Local Edge Enabled for Flooding, aparece ligado a la RFC 9667.

IANA ofrece una respuesta decisiva sobre el espacio común: ese valor ya tiene este significado documentado. No ofrece una respuesta sobre un paquete concreto. El paquete puede no haberse emitido, puede proceder de una versión no autorizada, puede ser ignorado por el receptor o no cambiar la ruta seleccionada.

La fricción excesiva puede destruir la disciplina

La RFC 8126 explica por qué un registro no se fortalece automáticamente al elegir el procedimiento más duro. Criterios desproporcionados y costes excesivos desaniman las solicitudes. Cuando lo que se usa deja de aparecer en el registro, la coordinación empeora y el propio registro pierde valor.

Expert Review conserva una puerta y un responsable. La petición debe estar documentada y el experto designado aplica criterios publicados. La RFC 7370 orienta este trabajo para IS-IS: normalmente se examinan documentos de grupo de trabajo o patrocinados por un Area Director, se comprueba el consenso o la aprobación pertinente y se estudia el mérito técnico. El experto no debe anular el consenso de la IETF. IANA registra la asignación aprobada; si el documento no progresa, se aplica la expiración o desasignación.

La revisión responde a si la solicitud merece un lugar único en ese registro. Deja abiertas, conscientemente, las preguntas que pertenecen al desarrollo y a la operación.

Ocupar un bit privado aplaza el coste

La RFC 7120 describe por qué las implementaciones tempranas eligen valores que parecen libres: necesitan experiencia antes de que termine el proceso formal. El ahorro inicial oculta dos deudas. IANA puede asignar después otro valor al mismo mecanismo, rompiendo la compatibilidad con versiones tempranas, o puede asignar el valor privado a otra extensión y crear una colisión semántica.

Una asignación pública convierte una suposición privada en un hecho coordinado, con referencia y ciclo de vida. Si la propuesta fracasa, ese ciclo también debe ser visible. La desasignación no elimina mágicamente binarios o configuraciones que sigan usando el bit.

Del registro al resultado hay seis autoridades más

El expediente de asignación debe guardar la revisión exacta del documento, la petición, el experto, los criterios, la decisión y la captura fechada del registro. Después, el equipo de ingeniería registra el commit, la compilación, las pruebas del emisor y del analizador y el tratamiento de banderas desconocidas o sub-TLV duplicados.

La autoridad de cambio decide en qué nodos se habilita la función y bajo qué reversión. Una captura demuestra el anuncio. En cada vecino hacen falta veredictos distintos para recepción, sintaxis, soporte semántico y aceptación de política. El cálculo de ruta produce otro recibo; la experiencia del servicio, otro más.

La primacía del código en ejecución obliga a consultar el binario y el estado ejecutado cuando la pregunta es qué ocurrió. Un registro puede probar qué debería significar el bit, pero no que esa fue la conducta de la máquina.

La política de seguridad no cambió

La RFC 9650 dice expresamente que no altera las consideraciones de seguridad de la RFC 5029. Esta última advierte que los LSP pueden exponer información adicional de capacidad y que su modificación puede ser relevante. Las especificaciones deben describir la divulgación y modificación de sus datos y considerar integridad cuando el riesgo lo exija.

Expert Review no autentica el origen del LSP, no vuelve seguro un analizador ni autoriza una política. Reducir el riesgo de colisión es valioso precisamente porque se hace sin apropiarse de competencias ajenas.

La especificación inicial mínima exige compartir sólo lo necesario para evitar ambigüedad y dejar explícita la autoridad futura. Las capas de realidad permiten nombrar petición, revisión, fila, código, paquete, política y resultado sin promover una capa al rango de otra.

Sources