Кратко

  • RFC 2860 зафиксировал соглашение IETF и ICANN о технической работе IANA для протоколов IETF и IRTF. RFC задают критерии; при технической неопределённости ориентир даёт IESG, а часть споров передаётся в IAB.
  • Политические вопросы присвоения доменных имён и блоков IP-адресов исключены из меморандума, но некоторые технические назначения в этих пространствах остаются в его пределах. Документ также требует открытых записей, публичного канала запросов, технических оснований для отказа, процедуры апелляции и шестимесячного уведомления о расторжении одной стороной.

Разбор

Ключ к RFC 2860 — не само слово IANA, а порядок определения того, чьи правила применяются. Меморандум посвящён технической работе для параметров протоколов в сфере IETF и IRTF. В разделе 4.1 первыми указаны критерии и процедуры RFC: предлагаемые, предварительные и полные стандарты Интернета, документы Best Current Practice и любые другие RFC, требующие назначения параметра IANA. Когда явного правила нет или оно допускает неоднозначность, IANA продолжает традиционную практику, если IESG не распорядится иначе.

При сомнении или техническом споре IANA запрашивает техническое руководство IESG и следует ему; при необходимости IESG может назначить эксперта. Недостающие правила стороны намерены вырабатывать со временем, а IANA применяет их после указания IESG.

Для параметров, главным образом связанных с исследованиями, раздел 5 задаёт параллельный вариант. В процедурах раздела 4 вместо IETF и IESG используются IRTF и IRSG — руководящая группа исследовательского направления. Если неясно, относится ли параметр преимущественно к IETF или IRTF, классификацию определяет IAB. Поэтому роль регистрационного оператора сама по себе не отвечает на вопрос о применимом процессе: сначала определяется область параметра, затем соответствующая линия управления.

Если конфликт возникает уже между IANA и IESG, раздел 4.2 переводит его на уровень IAB, чьё решение согласно меморандуму является окончательным. Раздел 4.5 описывает путь для заявителя: IANA должна предоставить онлайн-средство подачи запроса на назначение параметра и своевременно выполнить запрос либо отказать из-за несоответствия техническим требованиям. Отказать можно только по законным техническим основаниям. Для регистра, созданного действием IETF, отказ можно обжаловать сначала перед IESG, затем перед IAB. Текст задаёт последовательность рассмотрения, но не сообщает, сколько отказов и апелляций произошло на практике.

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

Предел соглашения особенно заметен в разделе 4.3. Вопросы политики при назначении доменных имён и блоков IP-адресов в меморандум не входят. Но домены для обратного DNS, специальные блоки для multicast или anycast и экспериментальные назначения остаются под процедурой раздела 4, когда не рассматриваются как политические вопросы. Если политика ICANN мешает соблюдать эти положения для названных случаев, ICANN должна уведомить IETF; после этого IETF может воспользоваться правом расторжения из раздела 2. Это граница между видами решения, а не исключение любых операций с именами и адресами.

У оператора есть и каналы обратной связи со стандартизацией. По разделу 4.6 IANA получает места связи без права голоса в подходящих комитетах, определённых IETF, и может участвовать в обсуждении технических требований к назначению параметров. Раздел 4.7 поручает IANA просматривать документы IETF на стадии Last Call и сообщать о замечаниях IESG. Эти положения дают операционной практике возможность выявлять пробелы в правилах, но сохраняют различие между консультацией и инструкцией.

Сам RFC 2860 опубликован в июне 2000 года со статусом Informational и прямо говорит, что не устанавливает стандарт Интернета. Он воспроизводит меморандум, подписанный IETF и ICANN 1 марта и ратифицированный советом ICANN 10 марта. Цель соглашения — исключительно определить техническую работу IANA от имени IETF и IRTF. При этом признаётся, что ICANN может предоставлять аналогичные услуги реестрам за пределами действий этих организаций.

Соглашение можно было изменить или отменить по взаимному согласию; каждая сторона могла также прекратить его, предупредив другую не менее чем за шесть месяцев. Это описанная возможность выхода, а не свидетельство того, что она была использована. RFC 6220, опубликованный в 2011 году, позднее описал функции делегированных операторов реестров параметров IETF и отметил, что IETF сохраняет ответственность за управление этими параметрами. Он помогает понять позднейшее описание роли оператора, но не доказывает неизменность всех условий 2000 года.

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

Источники

Основной источник — RFC 2860, Memorandum of Understanding Concerning the Technical Work of the IANA, особенно разделы 1–5. Более позднее описание операторов приведено в RFC 6220.