Кратко

  • RFC 1264 раскладывал зрелость протокола маршрутизации на воспроизводимую спецификацию, управление, архитектуру безопасности, независимые реализации, полные испытания, эксплуатационный опыт и границы масштаба.
  • RFC 4794 в 2006 году убрал дополнительное обязательное правило для всех документов маршрутизации ради своевременности, но оставил IESG право требовать опыт и рабочим группам возможность сохранять свои процедуры.
  • Позднейшие правила продолжили отделять статус от исполнения: RFC 6410 связал Internet Standard с независимой совместимостью, широким развёртыванием и успешной эксплуатацией; RFC 7942 сделал сведения о реализациях полезными, добровольными и не обязательно проверенными.

В кабинет входило несколько папок

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

Поэтому существовали отдельные записи: спецификация и применение, MIB для удалённого управления, архитектура безопасности, происхождение кода, сценарии и результаты испытаний, рабочая среда и анализ масштаба. Ясный текст показывал возможность независимой реализации, но не доказывал обмен маршрутами или работу аутентификации.

MIB определяла наблюдаемое состояние, но не факт наблюдения оператором. Архитектура называла защиту, но не её исполнение двумя продуктами. Проект, реализация и результат не заменяли друг друга.

Независимость начиналась с происхождения

RFC 1264 обычно требовал несколько совместимых реализаций, причём не менее двух написанных независимо. Два продукта из одной кодовой базы могут повторить одно толкование и один дефект. Раздельное происхождение сильнее проверяет, несёт ли координацию сама спецификация.

Список реализаций должен был указывать источник кода, а отчёт — сценарии и результаты. Для Draft Standard все функции, включая защитные, должны были работать между как минимум двумя реализациями и давать обещанную защиту. Количество продуктов не заменяло матрицу функций.

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

Эксплуатационному опыту требовались координаты

Отчёт содержал топологию, среду, время, длительность, реализации, результаты и выводы. Значимые функции следовало реально задействовать. Внешний протокол нёс полный набор внешних маршрутов; внутренний — внутренние и внешние, если последние не обслуживал отдельный механизм.

Нагрузка росла по ступеням. Proposed Standard нуждался в реализации и испытании основных функций, но не в обязательной эксплуатации. Draft Standard требовал существенного опыта с умеренным числом маршрутизаторов и сложностью в действующем Интернете. Standard — большого числа, сложной топологии и разных производителей.

Это были условия продвижения, а не утверждение RFC 1264 о том, что конкретный кандидат их выполнил. Решение и подтверждающий отчёт оставались разными объектами.

Второй отчёт спрашивал о точке разрушения

Кроме отчёта о реализациях, документ требовал анализ алгоритмов, нормального расхода полосы, памяти и CPU, роста в среде хотя бы на порядок больше, пределов и неподходящих условий.

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

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

В 2006 году контроль переместился

RFC 4794 перевёл RFC 1264 в Historic. Причина была институциональной: постоянная надстройка для одного класса протоколов задерживала публикацию, а общий процесс уже давал средства контроля. Маршрутизация не стала простой, опыт не стал бесполезным.

Исчезло широкое обязательство. Руководители Routing Area могли по RFC 2026 требовать реализацию или эксплуатацию. Рабочие группы могли продолжать процедуры RFC 1264. Управляемость и безопасность оставались в общих правилах.

Полномочие перешло от универсального списка к решению IESG и групп. Гибкость выросла, а запись решения должна была яснее назвать риск, требуемое доказательство и причину достаточности.

Две ступени сохранили материальную разницу

RFC 2026 называл Proposed Standard ранней ступенью, способной измениться с опытом. Обычно реализация и эксплуатация не требовались, но IESG мог потребовать их для базовых протоколов или значимого операционного воздействия.

RFC 6410 позже оставил Proposed Standard и Internet Standard. Для верхней ступени сохранились две независимо взаимодействующие реализации, широкое развёртывание и успешный опыт, а также проверки ошибок, неиспользуемых функций и лицензий.

Широкое развёртывание всё равно не описывает конкретную сеть. Без версии, охвата, периода и наблюдения оно не доказывает включение функции или полученный результат.

Лёгкий реестр объявил свою границу

RFC 7942 предложил добровольный раздел Implementation Status для Internet-Drafts. Он мог перечислять зрелость, лицензию, опыт, контакты и отчёты совместимости, чтобы работающий код раньше влиял на обсуждение.

Типовой текст предупреждал: сведения участников не являются одобрением IETF, могут не иметь независимой проверки и не образуют полного каталога. Такая запись помогает решению, но не заменяет артефакты испытаний, телеметрию и доказательство развёртывания.

Источники и пределы

Критерии 1991 года взяты из RFC 1264, общий процесс — из RFC 2026, отмена — из RFC 4794. Две ступени заданы RFC 6410, добровольные сведения — RFC 7942.

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