Кратко

  • В RFC 2020 запись настройки фиксировала намерение; между запросом и фактически принятым режимом стояло обучение канала.
  • Разделение имело прямые последствия: текущий формат задавал MTU 1500 или 4464 октета, а ifOperStatus становился up только при dot12Status=opened.

Запись значения не завершала переход

dot12DesiredFramingType выбирал для следующего обучения совместимый с IEEE 802.3 формат, совместимый с IEEE 802.5 формат или любой из них. dot12CurrentFramingType отвечал на другой вопрос: что используется сейчас? Даже свободный выбор должен был разрешиться в одно фактическое значение.

От него зависел ifMtu: 1500 октетов при текущем формате 802.3 и 4464 при 802.5. Изменение желаемого значения могло изменить MTU после следующего обучения. Успешный SET доказывал наличие запроса, но не переход и не новую MTU.

Внешний вид кадра также не определял метод доступа. IEEE 802.12 могла использовать форматы Ethernet или Token Ring, но работала по собственной Demand Priority Access Method. Поэтому RFC запрещала механически применять MAC MIB для Ethernet или Token Ring по одному сходству. Узкое исключение возникало лишь при сочетании Token Ring framing с реальной поддержкой source routing.

Обучение создавало границу доказательства

Учебные кадры применялись только при инициализации канала. Ведомое устройство на нижнем конце начинало обмен, ведущее отвечало. RFC требовала 24 последовательных кадра без ошибок, чтобы пограничный по качеству канал не завершил обучение.

dot12Status различал закрытое состояние, открытие, открытое состояние, неудачу открытия и отказ канала. ifOperStatus был up только при открытом состоянии. Команды открытия или сброса, смена желаемого формата, запроса неразборчивого режима либо режима управления могли начать переобучение; начало не было результатом.

dot12DesiredPromiscStatus переносил пожелание в следующий учебный пакет, однако ведущее устройство могло его не разрешить. Запись ifPromiscuousMode обновляла пожелание и запускала попытку; после обучения объект обязан был показывать используемый, а не запрошенный режим. dot12LastTrainingConfig сохранял биты последнего учебного кадра без ошибок.

Слово «ведущий» обозначало только протокольную роль участника, выдающего узлам разрешение на передачу. Оно не доказывало владение оборудованием, административную власть или доставку данных.

Вычисление не становилось итогом

Счётчики обычного приоритета на передаче не вводились, поскольку их можно было получить, вычтя высокий приоритет из общих значений. На приёме ошибки и нечитаемые октеты требовали дополнительных наблюдений. Формулы связывали измерения, но не доказывали доставку, завершение приложения или исполнение услуги.

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

Два жизненных цикла документов

Нынешние записи RFC Editor и IETF по-прежнему относят RFC 2020 к Proposed Standard и не называют заменивший её RFC. Поиск исправлений 11 сентября 2026 года не дал совпадений; это результат базы на указанную дату.

IEEE сегодня помечает IEEE 802.12-1995 как Inactive-Withdrawn с датой отзыва 15 января 2001 года, а рабочую группу Demand Priority относит к распущенным. Эта поздняя документальная история не измеряет распространённость, производительность или рыночный успех. Выдать статус документа за рабочее состояние означало бы повторить ошибку, от которой защищала RFC.

Источники