Summary

  • RFC 5237 удалил путь Expert Review для нераскрываемых сведений. IESG Approval и Standards Action сохранились, но опираются на публичные спецификации, доступные для проверки.
  • Запись координирует уникальный смысл. Она не доказывает реализацию, совместимость, безопасность, внедрение или трафик. Публичность обосновывает расход номера, но не подтверждает эксплуатацию.

Секрет создавал обязанность для посторонних

RFC 2780 разрешал выделять значения IPv4 Protocol через Expert Review, IESG Approval или Standards Action. Экспертная проверка предназначалась для особых случаев с соглашением о неразглашении; эксперта назначал IESG.

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

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

RFC 5237 изменил именно эту асимметрию. Разрабатывать втайне не запретили. Запретили превращать закрытость в постоянную непрозрачную бронь этого ограниченного поля.

Дефицит требует доказать уровень

Поле содержит 256 значений. RFC 5237 сообщал, что в 2008 году, когда документ создавался, использовалось 55 процентов. Это исторический снимок, а не текущий показатель реестра.

Ограниченность пространства требовала проверки здравого смысла. Существует ли стабильная спецификация? Есть ли сообщество пользователей? Не дублируется ли назначение? Действительно ли нужен номер IP-протокола, или задачу правильнее решить портом TCP либо UDP?

Standards Action остался для стандартов. IESG Approval остался для оправданных не-IETF и не-Standards-Track применений. Реестр не закрыли; исчез лишь маршрут, скрывавший основание расхода.

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

Открытая спецификация позволяет сравнивать архитектуру, искать дубли и обсуждать границу слоя. Она не становится автоматически стандартом IETF. Само сохранение IESG Approval показывает, что допустимое назначение возможно вне Standards Action.

Публикация также не решает автоматически вопросы патентов, лицензий и собственности. RFC 5237 требует видимости той части, которая задаёт общий смысл номера, а не переписывает все коммерческие отношения вокруг разработки.

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

IANA ведёт строку, а не создаёт технологию

IANA Protocol Numbers — авторитетный реестр значений и ссылок. Строка не означает, что IANA разработала протокол, оценила рынок или проверила безопасность.

Это ограничивает как администратора, так и заявителя. Хранитель уникальности не становится владельцем технологии. Получатель номера не получает знак качества.

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

У эксперимента есть отдельная дорога

RFC 4727 зарезервировал 253 и 254 для экспериментов и испытаний. Идею можно проверить до требования постоянного глобального смысла.

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

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

Правило имеет узкую границу

RFC 5237 прямо не распространяет свою позицию на NDA в других пространствах параметров. Реестры различаются размером, делегированием и ценой коллизии. Конкретное изменение относится к IPv4 Protocol и через ссылку RFC 2780 к IPv6 Next Header.

Общий вопрос стимулов сохраняется. Тайна выгодна заявителю, а уменьшение общего пространства затрагивает всех. Политика не должна скрывать этот перенос издержек.

RFC 8126 позднее обновил терминологию регистрационных политик IANA. Он помогает читать механизмы, но не меняет исторический акт BCP 37, опубликованного в феврале 2008 года.

Не повышать назначение до работающей реальности

Цепочка начинается с заявки, публичной спецификации, уполномоченного решения и записи. Затем могут появиться реализации, испытания совместимости, внедрение и наблюдаемый трафик.

Каждый переход способен провалиться. Публичный текст может показать плохой проект. Выделенный номер может остаться без кода. Две программы могут не взаимодействовать. Рабочий продукт может не попасть в сеть.

Приоритет работающей реальности у Lu Heng не позволяет занять последующий уровень предыдущей квитанцией. Прозрачность сильнее тайного обещания, но документ не является running code. Строка реестра подтверждает уникальность, а не производительность.

Sources

Additional standards record

  1. Текст RFC 5237
  2. Информация о RFC 5237
  3. RFC 5237 в Datatracker
  4. История RFC 5237
  5. Исправления RFC 5237
  6. Документы, ссылающиеся на RFC 5237