Resumen

  • Las tablas Admin de RFC 2051 eran vistas de solo lectura de valores esperados; las Oper declaraban el estado actual o negociado. Una fila Admin de modo podía borrarse aunque continuaran una sesión activa y su fila Oper.
  • Una sesión, una conversación, los contadores opcionales y el historial de fallos obedecían ciclos distintos. Ninguno demostraba por sí solo configuración, aceptación del par, éxito de la aplicación, integridad o seguridad.

La fila más instructiva de RFC 2051 es la que ya no está. El documento permite eliminar una appcModeAdminEntry cuando una sesión activa aún usa ese modo; la appcModeOperEntry correspondiente permanece. La ausencia arriba y la actividad abajo pueden ser dos observaciones verdaderas.

Admin mostraba valores predeterminados o esperados, pero el MIB no creaba ni cambiaba esa configuración. Por eso eran objetos de solo lectura. Oper mostraba valores presentes o negociados. Un objeto dinámico podía nacer a partir de una plantilla administrativa y después conservar su propio ciclo de vida.

Así se separan cinco verbos: configurar, solicitar, aceptar, negociar y ejecutar. Quitar la plantilla no rebobina una sesión establecida. Mantener la fila operativa tampoco demuestra que la configuración anterior siga autorizada para futuras sesiones.

El MIB abarcaba grupos globales, LU, programas de transacción, sesiones, conversaciones y CPI-C. No por ello era un mando general. No creaba ni eliminaba normalmente LU asociadas, modos o programas, ni activaba LU, iniciaba conversaciones o activaba sesiones.

Sí ofrecía controles concretos: seleccionar estadísticas o trazas, emitir CNOS y pedir la desactivación de una sesión. La escritura probaba una petición en la superficie de control; el estado posterior debía demostrar el efecto.

En CNOS, los objetos Admin indicaban cantidades deseadas y los Oper, las cantidades negociadas. La explicación actual de IBM sobre inicio de sesiones desarrolla CNOS como Change Number Of Sessions. Sirve de contexto terminológico, no de prueba de implementación ni de éxito en un sistema concreto.

La tabla de sesiones activas seguía unbound, pendingBind, bound y pendingUnbind. El agente creaba o quitaba filas según esa vida. Escribir unbound sobre una sesión enlazada podía iniciar la desactivación. La orden no era la confirmación.

Tampoco bound equivalía a resultado comercial. No indicaba si se asignó una conversación, terminó un programa, respondió correctamente el par o concluyó una transacción. El estado remoto y el resultado de aplicación quedaban fuera de la fila.

Una conversación era más breve que su sesión. El agente añadía la fila al comenzar y la retiraba al terminar. Varias conversaciones podían atravesar una sesión cuyo vínculo seguía activo.

Las estadísticas formaban otra capa opcional. Al activarse la recopilación se creaba una fila por sesión activa. Los valores eran Counter32 de RFC 1902 y tenían un uptime de referencia. Sin intervalo, tratamiento de vuelta a cero y estado de recopilación, un contador no constituye historia completa.

El RFC dice además que desactivar administrativamente la recopilación elimina todas las filas estadísticas. No ordena terminar las sesiones. Una tabla vacía puede significar que se apagó la medición, no que cesó el tráfico.

El historial también era parcial: sesiones terminadas anormalmente y conversaciones acabadas con error. La cantidad o duración conservada dependía de la implementación. Un archivo vacío no prueba ausencia de actividad, ni que todos los fallos anteriores sigan disponibles.

RFC 1666 ubica esta instrumentación en el modelo de gestión SNA. La genealogía no demuestra despliegue. Una norma puede definir objetos sin demostrar que alguien los instaló, habilitó, protegió o interpretó bien.

El estado formal exige la misma disciplina. El Datatracker de IETF y la ficha de RFC Editor lo registran como Proposed Standard de Standards Track, octubre de 1996. El índice de cambios congelado no incluye RFC 2051 y no aparece un RFC que lo actualice o sustituya. Es antiguo y trata tecnología heredada, pero la evidencia oficial no permite llamarlo Historic.

La consulta de erratas no devolvió coincidencias. Eso limita una incertidumbre documental, sin certificar implementaciones, interoperabilidad o vigencia.

El propio RFC dice que no discute seguridad. Standards Track no prueba control de acceso, escrituras seguras ni contadores fiables. Una sesión operativa puede ser insegura y un objeto de gestión no revela quién estaba autorizado a cambiar el sistema.

La lectura correcta asigna jurisdicción a cada testigo: Admin describe la configuración visible; el control, la solicitud; el agente, la transición; CNOS Oper, la negociación; la sesión, el vínculo activo; la conversación, una interacción; los contadores, una ventana medida; el historial, ciertos cierres anómalos. El par y la aplicación necesitan pruebas propias.

Fuentes