Resumen

  • RFC 1239 trasladó cinco raíces MIB desde arcos de 1.3.6.1.3 a las ramas estándar mib-2 y transmission.
  • El motivo no fue cosmético: renumerar tarde obligaba a revisar implementaciones aun sin cambios técnicos sustanciales, podía causar problemas de campo y retrasaba la experimentación.
  • Los códigos viejos y nuevos prueban una decisión normativa. No prueban cuándo la adoptó un dispositivo, un recolector o una base histórica.

La dirección administrativa ya era parte del producto

El breve RFC 1239 comienza con un coste. Durante el desarrollo, una MIB recibía un arco experimental. Solo al llegar a Full Standard obtenía un arco estándar. El ascenso del documento podía exigir a los proveedores revisar sus implementaciones aunque probablemente no hubiera cambiado de forma sustancial la definición de los objetos.

La SMI de RFC 1155 explica por qué. Un identificador de objeto no es solo un número editorial: es el nombre administrado del tipo de objeto. Viaja en la consulta, se reconoce en el agente, se convierte en clave de almacenamiento y aparece detrás de una etiqueta humana. Mover la raíz cambia la dirección de todos los objetos que cuelgan de ella.

La práctica antigua tenía un segundo efecto. Un proveedor podía esperar hasta Full Standard para no implementar dos veces. Eso reducía la experiencia temprana que debía ayudar a madurar el estándar. RFC 1239 propuso asignar el arco estándar desde la fase inicial y conservarlo mientras progresaba el texto.

Hoy el RFC Editor y el Datatracker registran el documento como Historic y Legacy. Esa clasificación describe el documento actual, no la configuración de un agente concreto ni una cronología de adopción.

La tabla cambió cinco raíces, no cinco flotas

Las extensiones genéricas de interfaz de RFC 1229 estaban en 1.3.6.1.3.6. La nueva raíz fue 1.3.6.1.2.1.12. Los otros cuatro cambios entraron en 1.3.6.1.2.1.10, la rama transmission.

El Token Bus de RFC 1230 pasó de experimental 7 a transmission 8. El Token Ring de RFC 1231, de 4 a 9. DS1, definido en RFC 1232, pasó de 2 a 18. DS3, en RFC 1233, pasó de 15 a 30.

La precisión de esa correspondencia puede engañar. RFC 1239 no fijó una fecha de corte, un alias, un periodo de doble respuesta, una negociación, un procedimiento de conversión ni una política para series históricas. La norma nombró el destino. Cada implementación debía construir su propio trayecto.

Registro, software y observación son expedientes distintos

El registro SMI de IANA conserva GenericIF 12 y los valores de transmisión 8, 9, 18 y 30. Algunas referencias actuales ya apuntan a RFC posteriores. El registro responde cuál es la asignación autorizada hoy; RFC 1239 conserva la decisión de 1991. Ninguno, sin una captura adicional, dice qué respondió un agente particular.

Una consulta fallida al OID nuevo admite varias causas: software antiguo, objeto no implementado, control de acceso, indisponibilidad o error de consulta. Una respuesta al OID antiguo prueba esa respuesta en ese punto, no que el arco estándar careciera de adopción. Tampoco puede presumirse que dos valores bajo raíces diferentes sean equivalentes porque el nombre legible coincida.

Una migración de recolectores puede cortar una serie sin que cambie el equipo. También puede unir dos series y ocultar un cambio simultáneo de versión o semántica. El documento no demuestra que ocurriera ninguno de esos casos. Demuestra que la evidencia debe conservar OID exacto, versión de agente y gestor, instante, respuesta, contexto de acceso, clave de almacenamiento y regla de unión.

La estabilidad del número tampoco congela el significado. Un RFC posterior puede modificar estado, acceso o interpretación y mantener la raíz. RFC 1239 intentó evitar que la graduación administrativa provocara una renumeración innecesaria. La continuidad del identificador y la continuidad semántica siguieron siendo afirmaciones diferentes.

Fuentes