Кратко

  • Таблицы Admin в RFC 2051 только показывали ожидаемые значения, а Oper свидетельствовали о текущем или согласованном состоянии. Строку Admin для режима можно было удалить, сохранив активный сеанс и его Oper-строку.
  • У сеансов, разговоров, необязательных счётчиков и истории аномалий были разные сроки жизни. Ни один слой сам по себе не доказывал конфигурацию, согласие партнёра, успех приложения, полноту или безопасность.

Главный объект RFC 2051 — отсутствующая строка. appcModeAdminEntry разрешалось удалить, когда активный сеанс ещё использовал этот режим; соответствующая appcModeOperEntry оставалась. Пустота в административной части и активность в операционной могли одновременно быть правдой.

Admin представляла значения по умолчанию или ожидания. MIB не создавала и не меняла эту конфигурацию, поэтому объекты были только для чтения. Oper представляла текущие или согласованные значения. Динамический объект мог возникнуть по административному шаблону, а затем жить самостоятельно.

Отсюда пять разных утверждений: настроено, запрошено, принято агентом, согласовано и работает. Удаление шаблона не отменяет установленный сеанс. Сохранившаяся Oper-строка не подтверждает, что прежняя конфигурация разрешена для будущих сеансов.

RFC охватывала global, LU, transaction program, session, conversation и CPI-C. Это не делало MIB универсальным пультом. Обычно она не создавала и не удаляла партнёрские LU, режимы и программы, не активировала LU, не начинала разговоры и не поднимала сеансы.

Отдельные средства управления были: включение статистики и трассировки, команды CNOS, запрос деактивации. Запись подтверждала запрос на управляющей поверхности, но не результат.

В CNOS Admin содержала желаемые числа, а Oper — фактически согласованные. Текущая документация IBM о запуске сеансов раскрывает CNOS как Change Number Of Sessions. Это контекст термина, а не доказательство реализации RFC или успеха переговоров.

Активный сеанс проходил unbound, pendingBind, bound и pendingUnbind. Агент создавал и удалял строки по этому циклу. Запись unbound для связанного сеанса могла начать деактивацию; последующее состояние требовалось для подтверждения результата.

Даже bound означал только состояние сеанса. Он не показывал выделение разговора, завершение программы, правильный ответ партнёра или успешную деловую операцию.

Разговор жил короче сеанса. Агент создавал строку при начале и удалял при завершении. Несколько разговоров могли пройти через один продолжающийся сеанс.

Статистика была отдельным необязательным слоем. При активном сборе создавалась строка на сеанс. Счётчики использовали Counter32 из RFC 1902 и сопровождались uptime. Без интервала, учёта переполнения и статуса сбора число не является полной историей.

Если административно отключить сбор, все строки статистики исчезали. Сеансы при этом могли продолжаться. Пустая таблица могла означать выключенное измерение, а не отсутствие активности.

История тоже была выборочной: аномально завершённые сеансы и разговоры с ошибками. Объём и срок хранения зависели от реализации. Пустой архив не доказывал отсутствие нормальной работы или сохранение всех прошлых ошибок.

RFC 1666 показывает родство с управлением SNA. Это не доказательство внедрения. Стандарт определяет объекты, но не свидетельствует об установке, включении, защите или правильной интерпретации.

Формальный статус столь же точен. IETF Datatracker и RFC Editor называют документ Proposed Standard на Standards Track, опубликованным в октябре 1996 года. В замороженном индексе смены статуса RFC 2051 отсутствует; обновляющий или заменяющий RFC не указан. Документ старый и о наследуемой технологии, но официальный статус Historic источниками не подтверждён.

Поиск errata совпадений не дал. Это уменьшает одну документальную неопределённость, но не сертифицирует реализацию, совместимость или актуальность.

RFC прямо говорит, что вопросы безопасности не обсуждаются. Standards Track не доказывает контроль доступа, безопасность записей или надёжность счётчиков. Операционный сеанс может быть небезопасным.

Каждый свидетель имеет ограниченную компетенцию: Admin — представленная конфигурация; control — запрос; агент — переход; CNOS Oper — итог переговоров; session — активная связь; conversation — одно взаимодействие; статистика — окно измерения; история — выбранные аномальные окончания. Партнёр и приложение должны свидетельствовать отдельно.

Источники