Resumen

  • RFC 2155 reservó DisplayableDlcAddress para presentación y remitió a una MIB específica del DLC para los bytes reales de la cabecera.
  • El estado operativo, la procedencia XID del vecino, los valores configurados localmente, el historial excepcional y el éxito de sesión eran comprobantes distintos.
  • Una identificación defendible une etiqueta, instancia y ámbito, RowPointer, bytes inferiores, tiempo y estado, origen del nombre del par y resultado de sesión.

La comodidad visual tenía un límite explícito

Una cadena limpia en una consola invita a copiarla como clave de inventario. RFC 2155, publicada en junio de 1997 como Proposed Standard para APPN, anticipó el error. DisplayableDlcAddress permitía de cero a 64 caracteres ASCII, pero la estación de gestión debía usarla únicamente para mostrarla.

La dirección DLC “real”, los bytes que circulan en la cabecera, estaba a menudo disponible en la MIB propia del DLC. El texto no promete que siempre lo estuviera ni declara falsa la representación humana. Limita su autoridad. Una cadena vacía significaba que el agente desconocía la dirección; una cadena no vacía no garantizaba unicidad, vigencia, vecindad activa ni sesión establecida.

El puntero llevaba a la capa competente

Las filas de puerto y estación de enlace combinaban direcciones visibles con appnPortSpecific y appnLsSpecific. Esos RowPointer podían señalar objetos del DLC correspondiente; 0.0 significaba que el agente no sabía identificarlos. Para correlacionar hacía falta conservar instancia APPN, tipo de DLC, puntero, interfaz, dirección inferior y momento de observación.

La RFC 1747 muestra el caso SDLC: su dirección de estación es un valor de sondeo entre 1 y 255, único dentro del ámbito definido, y el estado de contacto vive en otro objeto. La RFC 2024 presenta formas DLSw distintas, como una MAC de seis bytes o una IP de cuatro bytes en orden de red. Una cadena de pantalla no conserva por sí sola todos esos ámbitos y codificaciones.

Un nombre conocido podía ser una configuración

appnLsAdjCpName podía contener el nombre del punto de control recibido mediante XID. Si aún no se había recibido XID, el agente podía devolver un valor definido localmente; si no existía ninguno, devolvía vacío. La consola podía enseñar una observación del par o la expectativa del operador con el mismo aspecto.

El identificador del nodo asociado se extraía de cuatro bytes de XID y usaba 00000000 cuando no estaba disponible. Otra forma terminada en cinco ceros indicaba que el identificador no era único en el nodo. El número de grupo de transmisión 256 significaba no negociado o desconocido. Nada de ello se resolvía porque el texto pareciera familiar.

Una fila persistente no era un enlace actual

La estación podía estar inactiva, pendiente de activación, activa o pendiente de desactivación. Los contadores de XID buenos y malos, el tiempo de activación y la entrada en el estado actual se exponían por separado. La dirección no resumía esas mediciones.

La tabla de estado guardaba eventos excepcionales o potencialmente excepcionales de activación, XID y terminación. La operación normal no generaba fila, y el producto decidía cuánto historial conservar. Por ello una fila antigua prueba un suceso registrado, no una vecindad viva. Además, RFC 2155 excluía la monitorización y el control de sesiones de extremo: incluso una estación activa necesita evidencia aparte para probar sesión y resultado de aplicación.

El registro del RFC Editor y el historial de Datatracker fijan el contexto. RFC 2455 sustituyó el documento en noviembre de 1998 tras ampliaciones de APPN y experiencia de implementación, pero mantuvo la misma frontera entre pantalla y cabecera. La primacía del código en ejecución, la especificación inicial mínima y las capas de realidad de Heng Lu son aquí lentes editoriales declaradas, no requisitos del RFC.

Fuentes