Resumen

  • En RFC 2020, escribir una configuración expresaba intención; el entrenamiento mediaba entre esa petición y el modo realmente aceptado por el enlace.
  • La separación tenía efectos medibles: el entramado vigente fijaba una MTU de 1.500 o 4.464 octetos, y solo el estado opened hacía que ifOperStatus fuera up.

El valor escrito no cerraba el cambio

La tabla de configuración colocaba dot12DesiredFramingType junto a dot12CurrentFramingType, pero no los trataba como sinónimos. El primero elegía para el próximo entrenamiento un formato compatible con IEEE 802.3, compatible con IEEE 802.5 o cualquiera de ambos. El segundo decía cuál se usaba en ese momento. Incluso una preferencia abierta debía resolverse en un formato actual concreto.

De esa resolución dependía ifMtu: 1.500 octetos con el formato 802.3 y 4.464 con el 802.5. Cambiar el valor deseado podía alterar la MTU después del siguiente entrenamiento. Por tanto, un SET aceptado demostraba una solicitud, no la MTU resultante.

La apariencia de la trama tampoco identificaba el método de acceso. IEEE 802.12 podía usar formatos Ethernet o Token Ring, pero ejecutaba Demand Priority Access Method. Por eso RFC 2020 desaconsejaba aplicar las MIB MAC de Ethernet o Token Ring solo por el formato visible. La excepción era más estrecha: formato Token Ring y soporte real de encaminamiento por origen.

Entrenar era producir evidencia

Las tramas de entrenamiento solo intervenían al inicializar el enlace. El dispositivo esclavo iniciaba el intercambio y el maestro respondía. La RFC exigía 24 tramas consecutivas sin error para terminarlo, con la intención declarada de impedir que enlaces marginales completaran el proceso.

dot12Status distinguía cerrado, abriendo, abierto, fallo de apertura y fallo de enlace. ifOperStatus era up únicamente en el estado abierto. Ordenar apertura o reinicio, cambiar el entramado deseado o modificar el papel de control podía iniciar otro entrenamiento; ninguno de esos actos era prueba de que había terminado.

El modo promiscuo repetía la arquitectura. dot12DesiredPromiscStatus indicaba lo que se pediría en el siguiente paquete de entrenamiento; el maestro podía no concederlo. Escribir ifPromiscuousMode cambiaba ese deseo y provocaba un intento. Después, el objeto debía mostrar el modo en uso, no el solicitado. dot12LastTrainingConfig guardaba los bits del último intercambio sin errores y permitía contrastar petición y respuesta.

También dot12ControlMode delimitaba una función. Maestro significaba el participante que concedía turnos de transmisión; esclavo, quien no ejercía ese control. No significaba propiedad, soberanía administrativa ni entrega exitosa.

Contar no era probar un resultado

Algunos contadores normales de transmisión se omitieron porque podían derivarse restando la alta prioridad de los totales. En recepción, las tramas erróneas y los octetos ilegibles obligaban a conservar observaciones adicionales. La aritmética describía relaciones entre medidas, pero no demostraba recepción en destino, éxito de una aplicación ni cumplimiento de un servicio.

La propia RFC dejó otra frontera: no discutió cuestiones de seguridad. Un enlace abierto o una configuración aceptada no eran autenticación, confidencialidad ni garantía de operación segura.

El RFC y el estándar IEEE siguieron relojes distintos

Los registros actuales del RFC Editor y del IETF mantienen RFC 2020 como Proposed Standard y no señalan un RFC que lo sustituya. La consulta de erratas no encontró coincidencias el 11 de septiembre de 2026; eso describe la base consultada, no una promesa permanente.

IEEE registra hoy IEEE 802.12-1995 como Inactive-Withdrawn, retirado el 15 de enero de 2001, y sitúa al grupo Demand Priority entre los grupos disueltos. Es información posterior sobre otro ciclo documental. No mide despliegue, rendimiento ni éxito comercial. Convertir esas etiquetas en hechos de operación confundiría, otra vez, el estado administrativo con el sistema en marcha.

Fuentes