Кратко

  • Апелляция по решению о регистрации параметра подаётся в течение двух месяцев с момента, когда решение стало публично известно; для самого решения документ называет лишь «разумный период» и не устанавливает всеобщего фиксированного срока.
  • Верхняя ступень лестницы — IAB — может аннулировать решение IESG и восстановить прежнее положение, но не может принять решение, закреплённое за IESG. Рассмотренные положения прямо не наделяют её полномочием предписать регистрацию — это чтение двух разделов вместе, а не формулировка самого документа.
  • Первое названное институциональное звено цепочки — орган, который назначает эксперта и может отстранить его по своему усмотрению.

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

Правила задаёт RFC 8126, опубликованный в июне 2017 года. Он устанавливает десять категорий регистрационной политики: Private Use, Experimental Use, Hierarchical Allocation, First Come First Served, Expert Review, Specification Required, RFC Required, IETF Review, Standards Action и IESG Approval. Два края этой шкалы важны сами по себе: значения Private Use и Experimental Use IANA не записывает вообще — они существуют вне публичного реестра, вне его нумерации и вне его апелляционной лестницы.

Самая интересная ступень — Specification Required. Она добавляет к экспертной оценке требование постоянной, публично доступной спецификации: ясной, технически состоятельной и достаточной, чтобы независимая реализация могла взаимодействовать с другими. RFC при этом не обязателен. Это порог, который нельзя измерить числом, и вокруг него идёт спор о том, что именно считается достаточным документом.

Эксперт работает не в пустоте. Согласно §§5.1–5.3 того же RFC, он оценивает заявку по опубликованным критериям конкретного реестра, а если таких критериев нет — по полноте документации, совместимости и конфликтам, и при отсутствии убедительных возражений должен исходить из того, что заявку следует удовлетворить. Основания для отказа перечислены: нехватка ресурса, неясная документация, вредные архитектурные или эксплуатационные последствия, вредные конфликты с работой IETF. Всё это — суждение, вынесенное по опубликованному стандарту, но всё же суждение.

Дальше начинается устройство власти. §5.2.1 сообщает дословно: «The IESG may remove any designated expert that it appointed, at its discretion.» Тот же раздел говорит, что экспертов для реестров IETF назначает и заменяет IESG, обычно по рекомендации директора области. Эксперт, чьё суждение можно оспорить, назначен тем же органом, который будет это возражение рассматривать первым.

Маршрут обжалования задан §10: возражение против решения о регистрации идёт в IESG, затем в IAB, а к спорам с участием экспертных групп применяется процедура из §6.5.1 RFC 2026. Лестница выглядит так: председатели рабочих групп, затем ответственные директора областей, затем полный IESG, затем IAB. Каждая инстанция обязана рассмотреть вопрос и попытаться его разрешить; IAB окончателен в вопросах соблюдения процедуры и технической состоятельности.

Теперь о сроках — и здесь возникает видимая асимметрия. §6.5.4 RFC 2026 формулирует жёстко: «All appeals must be initiated within two months of the public knowledge of the action or decision to be challenged.» Два месяца — это предел, отсчитанный от публичной известности решения, а не от его вступления в силу и не от получения уведомления. Для самого решения тот же раздел требует лишь решить и сообщить о решении «в разумный период» и прямо оговаривает, что всеобщего фиксированного срока нет. Принципы эксплуатации реестров IANA подтверждают эту логику: RFC 8720 в §3.1 определяет предсказуемость обработки как отсутствие неожиданных шагов, а не как гарантию решения за определённое число дней. Иначе говоря, тот, кто ждёт, не имеет календаря; тот, кто оспаривает, имеет дедлайн. Насколько это расхождение намеренно, здесь не устанавливается.

Верхняя ступень не равна высшей власти. §6.5.2 RFC 2026 позволяет IAB аннулировать решение IESG, восстановив прежнее положение, или рекомендовать действие, но запрещает принимать решения, закреплённые за IESG. Если сложить это с лестницей из §6.5.1, получается вывод, который принадлежит уже мне, а не документам: самый сильный исход, различимый в рассмотренной лестнице, — отмена, а не предписание. Рассмотренные положения прямо не наделяют IAB полномочием обязать внести запись в реестр; остаются открытыми рекомендация, отмена с последующим пересмотром или особый для конкретного случая путь к регистрации позднее.

Дальнейшее обращение, согласно §6.5.3, идёт к попечителям Internet Society и касается адекватности самих процедур, а не существа технического спора.

Остаётся вопрос, который документы не разрешают. §5.2.1 даёт IESG право по своему усмотрению отстранить назначенного им эксперта; §10 направляет возражение против решения о регистрации сначала в тот же IESG. Оба положения стоят рядом, и ни одно из них не разделяет две роли — назначающего органа и первого названного институционального этапа рассмотрения возражения; в рассмотренных положениях такого разделения нет.

Первое названное институциональное звено цепочки — тот орган, который назначает эксперта: путь §10 проходит через председателей рабочих групп и ответственных директоров областей, прежде чем доходит до полного IESG, а кто рассматривает конкретную апелляцию и действуют ли при этом одни и те же лица, здесь не установлено. Это не обвинение, а описание устройства: возможность пересмотра существует, а вот институциональной дистанции между назначившим и пересматривающим не заявлено.

Действующее право при этом не стоит на месте. RFC 9907, опубликованный в марте 2026 года, прямо обновляет RFC 8126 и отменяет RFC 8407; его §§4.30.3 и 5.3 связывают изменения в авторитетном реестре с поддержкой соответствующего модуля YANG, который ведёт IANA, и требуют, чтобы новые значения появлялись в реестре, а не добавлялись напрямую в модуль. История ошибок тоже содержательна: в реестре errata техническая ошибка 6522 была отклонена 8 апреля 2021 года. Она предлагала прямо разрешить указывать конкретные версии Internet-Draft в качестве исполнения §4.6 при экспертной оценке; проверяющий счёл это предложением об изменении политики, требующим обсуждения и консенсуса сообщества, а не исправлением ошибки. Отказ фиксирует границу: порог документации — вопрос политики, а не редакционная опечатка.

Готовится и замена. draft-ietf-ianabis-rfc8126bis-05 опубликован 2 ноября 2026 года; его аннотация говорит об отмене RFC 8126, но шапка оговаривает это условием «if approved», а статус прямо называет документ черновиком. В этом обзоре он читается как состояние незавершённой ревизии, а не как действующее правило.

Есть и практическая деталь, которая ломает привычное представление о «реестре» как о единой политике. Страница IANA «Guidance for RFC Authors» с датой обновления 13 июля 2026 года предупреждает: разные диапазоны внутри одного реестра могут использовать разные процедуры регистрации, поэтому названия реестра недостаточно, чтобы определить применимую политику. Заявка должна указывать точный реестр и необходимые поля, а RFC-ссылка может требовать шаблона с полями, которых в отображении реестра нет. При Expert Review и Specification Required IANA просит экспертов провести оценку во время IETF Last Call, с копией рабочей группе.

Границы этого обзора нужно назвать прямо. Ни одна конкретная заявка, ни один отказ, ни одна поданная апелляция или решение по ней не были изучены: всё сказанное относится к опубликованному каркасу, а не к практике его применения. Какие политики действуют в конкретном реестре, не установлено. Внутренняя работа IESG с апелляцией и неопубликованные материалы прошлых апелляций не получены. Отклонение ошибки 6522 не означает, что Internet-Draft никогда не принимался на практике: §4.6 не называет его среди допустимых форм.

Три попытки получить документы по договору об именах IANA остановились на стороне провайдера, и контракт, устав Customer Standing Committee и отчёт Naming Function Review остаются непрочитанными — это пробел в моём доступе, а не вывод о содержании этих документов.

Что из этого следует для того, кто подаёт заявку? Календарь есть только у него. Если решение состоялось и стало публичным, у него два месяца, чтобы возразить, и никакого срока, в который ему обязаны ответить по существу. Самый сильный исход, различимый в рассмотренных положениях, — восстановление прежнего положения; прямо предписать запись в реестр эти положения не дают. И первым названным институциональным этапом его возражение встретит тот, кто выбрал эксперта и вправе его отстранить.