Эволюция IANA: подготовка новой фазы

Андрей Робачевский

Андрей Робачевский

Мы продолжаем серию статей, рассказывающих об истории и эволюции IANA, включая текущую стадию передачи надзорной роли правительства США в руки международного сообщества. Се­годня мы остановимся на структуре IANA, рассмотрим вопросы разделения ролей определения политики, надзора и исполнения. Наконец, расскажем о сути проектов передачи, операционны­ми сообществами, — параметров протоколов, номерных ресурсов и имен. А также — о спорных вопросах и процессе формирования согласованного предложения.

Cоздание ICANN обозначило важную веху в системе координации цен­трализованных функций Интернета – администрирование корневой зоны, гло­бального пула адресного пространства IP и уникальных параметров протоколов Интер­нета.
В духе стратегии приватизации Интерне­та была создана формально независимая от правительства США частная корпорация. В духе общей тенденции глобализации Интернета в процесс принятия решений относительно администрирования этих критических ресурсов были вовлечены гло­бальные сообщества. Часть этих сообществ, например, сообщество разработчиков про­токолов IETF, адресное сообщество вокруг РИРов, сформировалась в ходе эволюции Интернета и функционировала в соответ­ствии с нормами и политиками, проверен­ными практикой. С именами дело обстояло гораздо сложнее.
Монопольная позиция NSI в отношении администрирования корневой зоны и ос­новных доменов верхнего уровня была причиной отсутствия организованного сообщества, объединенного общими инте­ресами, совместно принятыми правилами и политиками. Для заполнения этого про­бела сообщество имен в рамках структуры ICANN было организовано следующим об­разом:

• Представители администрации нацио­нальных доменов были объединены в организацию поддержки национальных доменов – ccNSO.
• Для общих доменных имен также была создана организация поддержки – GNSO, однако ее структура оказалась куда более сложной и отражала широкий круг за­интересованных сторон: коммерческих организаций (бизнес, интеллектуальная собственность, интернет сервис-провай­деры), некоммерческих организаций, а также регистратур и регистраторов.
• Наконец, интересы интернет-пользова­телей и правительств государств были учтены путем создания консультацион­ных комитетов – ALAC (At-Large Advisory Committee) и GAC (Government Advisory Committee).

Описанная выше структура представляет органы, принимающие решения и опреде­ляющие политику, на основании который IANA создает и обслуживает соответству­ющие реестры. При этом IANA, оставаясь подразделением ICANN, выполняет адми­нистративные функции и не принимает ак­тивного участия в разработке политик.

Определение политик, обслуживание регистратур и надзор
Для того, чтобы лучше увидеть роль NTIA и других участников «экосистемы» IANA (Рис. 1), стоит поподробнее остановиться на трех основных аспектах глобальной регистрату­ры – политики, исполнения и надзора.
Задачей всех вышеописанных структур принятия решений в отношении IANA явля­ется выработка соответствующих по­литик, начиная от создания специальных реестров и заканчивая правилами внесения изменений.
Так, сообщество IETF в процессе раз­работки протокола определяет необхо­димость создания реестра и правила его сопровождения. Эта “политика” докумен­тируется в разделе “IANA considerations” соответствующего стандарта. Документ RFC 5226 «Guidelines for Writing an IANA Considerations Section in RFCs» содержит практические рекомендации по разработ­ке таких правил и их документации в этом разделе. Хочу отметить, что ICANN в плане разработки или утверждения таких правил не имеет никакой роли.

В отношении номерных ресурсов – IP адресов и номеров автономных систем – дело касается утверждения глобальных политик – правил управления глобальным пулом номерных ресурсов, который адми­нистрирует IANA. Сами политики разра­батываются РИР-сообществами, но затем утверждаются ASO (Address Supporting Organization, Организация поддержки адресов) ICANN. Заключительным шагом является ратификация глобальной поли­тики советом директоров ICANN. Эти по­литики действительны только в отношении реестров так называемых глобальных но­мерных ресурсов, делегированных РИРам для последующего распределения. Часть адресного пространства (и соответству­ющие реестры) обслуживается в соответ­ствии с политикой IETF и является либо за­резервированной, либо предназначенной для специального использования (см., на­пример, www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml).
Разработка политики в отношении доме­нов верхнего уровня, общих и националь­ных, происходит в рамках соответвтующих организаций поддержки и координирует­ся соответствующими советами – советом ccNSO и советом gNSO. Политики утвержда­ются советом директоров ICANN. Замечу, что большинство политик и рекомендаций, разработанных этими сообществами, непо­средственно к IANA отношения не имеют. Эти политики регулируют деятельность регистраторов имен второго уровня в об­щих доменах верхнего уровня. Основные же правила, относящиеся к администриро­ванию корневой зоны, либо внешние (как, например, допустимые имена националь­ных доменов, определяемые стандартом ISO 3166-1), либо проходят как инструкции и рекомендации, разработанные самой ICANN (например, процесс ре-делегирова­ния).
Сама же IANA выполняет сугубо адми­нистративную функцию, а именно обслуживает запросы на изменение соответствующих реестров:

• Для доменных имен – собственно корне­вую зону, файл хинтов*, и базу данных доменов верхнего уровня, т.н. whois, со­держащую помимо прочего контактную информацию администратора домена. В зону ответственности IANA также входит регистрация имен в домене .int, а также информация и реестры, относящиеся к DNSSEC – ключи точек доверия, материа­лы церемоний подписания и т.п. (https:// www.iana.org/domains).
• Для номерных ресурсов – реестры гло­бальных адресов и реестры номеров ав­тономных систем (https://www.iana.org/ numbers).
• Для параметров протоколов – различные реестры для протоколов, разработанных IETF (https://www.iana.org/protocols).

Наконец, функцию надзора выполняет правительство США в лице NTIA, посколь­ку именно это агентство министерства тор­говли является держателем договора на предоставление услуг IANA. Этот договор, как я говорил в предыдущей статье, был заключен в начале 2000 года и фактически легитимировал поглощение ICANN IANA, но также восстановил контроль правитель­ства США над этими ключевыми функци­ями.
В рамках стандартной практики прави­тельства США происходит периодическое перезаключение этого договора, формаль­но открывающее возможность для других, кроме ICANN, претендентов завоевать этот контракт и стать IANA. Хотя бы на три года** .
Для доменных имен NTIA выполняет еще и дополнительную надзорную функцию – а именно утверждает любые изменения в корневой зоне и базе данных whois. Це­лью этой функции является проверка, что при обслуживании запроса на изменение ICANN следовала существующим правилам и процессу. Без этого утверждения Verisign, которая собственно технически обслужива­ет и публикует корневую зону, изменений в нее не внесет.
О передаче именно этой надзорной функции и шла речь, когда NTIA опубли­ковала заявление о намерении передать ключевые функции глобальной системы имен DNS в руки мирового сообщества.

Адреса и протоколы

• В своем заявлении NTIA обозначила про­цесс разработки плана передачи и основ­ные требования к нему. ICANN поруча­лось созвать заинтересованные стороны глобального интернет-сообщества для разработки плана. Результат должен быть поддержан широкими массами и удовлет­ворять четырем основным принципам:
• поддерживать и укреплять модель муль­тистейколдеризма;
• обеспечивать безопасность, стабильность и прочность системы DNS;
• удовлетворять потребности и ожидания глобальных потребителей и партнеров услуг IANA;
• поддерживать открытость Интернета.

Отдельной строкой было выделено усло­вие, что роль NTIA не может быть передана государственной или межгосударственной организации.
В результате нескольких месяцев интен­сивных дискуссий был согласован план соз­дания плана передачи, согласно которому «операционные сообщества» — протоколов, номерных ресурсов и имен – должны разра­ботать части плана, соответствующие их об­ласти деятельности, а созданная Координи­рующая группа (IANA Stewardship Transition Coordination Group, ICG) должна будет скомпилировать общий согласованный план, при этом не добавляя отсебятины.
Общий план предполагал, что все три ча­сти будут готовы к 15 января 2015 года, что позволит ICG консолидировать их в единое предложение, собрать комментраии, пре­доставить NTIA на рассмотрение, получить утверждение и перейти к исполнению. И все это – до окончания действия контракта 30 сентября 2015 года. Как вскоре стало понят­но, план оказался нереалистичным.
План сообщества IETF разработать было достаточно просто – он по существу доку­ментировал статус кво. Присутствие NTIA в IETF ощущалось только при перезаключе­нии контракта, который с точки зрения са­мого IETF был совершенно излишним. Дело в том, что уже в 2000 году между IETF и ICANN был заключен меморандум, опреде­ляющий роли ICANN как провайдера услуг IANA и IETF как потребителя этих услуг, до­кументирующий требования к предоставля­емым услугам, – другими словами, договор на предоставление услуг IANA. Каждая из сторон вправе расторгнуть данный договор с 6-месячным уведомлением.
Договор решает проблему подотчетности – если провайдер не выполняет оговорен­ных задач и не обеспечивает качества услуг, договор может быть расторгнут и найден но­вый провайдер.
Разработка плана проводилась в духе IETF согласно процессу разработки стандартов. Для этого была организована рабочая груп­па IANAPLAN – и к концу 2014 года консен­сус был достигнут и план был готов. Струк­тура этих взаимоотношений представлена на рис.2.
Сообщество номерных ресурсов взяло подход IETF за основу, однако выработало специальный процесс для разработки плана. Процесс разработки глобальных политик являлся слишком длительным (консенсус должен быть достигнут во всех региональ­ных сообществах), чтобы иметь практиче­ское применение. Вместо этого РИРы пред­ложили создание небольшой группы из 15 представителей региональных сообществ (по три от каждого) для разработки и об­суждения плана, который получил название Консолидированного предложения РИР по координирующей роли (Consolidated RIR IANA Stewardship Proposal, CRISP).
Для номерных услуг IANA роль NTIA также сводилась к держателю контракта с ICANN. Эту роль предлагалось передать пяти РИРам, которыe, в свою очередь, за­ключили бы договор, или Соглашение об уровне услуг (Service Level Agreement, SLA) непосредственно с ICANN. Предлагалось также создать ревизионный комитет из представителей сообщества для контроля качества предоставляемых услуг. Эту роль предлагается совместить с существующей группой Совета ASO. Комитет имеет чисто консультативную роль, решения в плане пе­ресмотра контракта или параметров предо­ставляемых услуг остается за РИРами.
Оставался один с виду незначительный момент, в отношении которого по не впол­не понятным причинам IETF не решился занять сильную позицию. Я имею в виду торговые знаки и интеллектуальную соб­ственность. Или, более конкретно, – знак и имя IANA, доменное имя iana.org и содер­жимое регистратур. Группе CRISP было оче­видно, что если ICANN будет продолжать быть держателем этих ресурсов, это может существенно затруднить возможность пере­заключения контракта и перехода к другому оператору – ключевой элемент решения во­проса надзора.
План CRISP предлагал передать эти ресур­сы в руки независимой организации, а IETF Trust рассматривался в качестве возможно­го кандидата.
Таже одним из условий договора являлась возможность его расторжения без конкрет­ных причин, но с достаточным уведомлением.
И этот план был готов в срок, и еще до 15 января был передан в группу ICG для рас­смотрения. Схематично он представлен на рис.2.
Имена
С именами дело обстояло гораздо сложнее. Как видно из рисунка 1, вся деятельность со­общества имен тесно интегрирована в струк­туру самой ICANN. Другими словами, орга­низации, представляющие интересы этого сообщества – ccNSO, gNSO, – сами являются частью ICANN. Поэтому простой подход до­говорных отношений, который был принят сообществами протоколов и номеров, здесь не работал.
Для разработки плана была создана груп­па CWG – Сквозная рабочая группа сооб­щества имен (также получившая название CWG-Stewardship, CWG-Координирующая роль). Рабочая группа была сформирована из представителей поддерживающих орга­низаций и комитетов, имеющих отношение к именам: ccNSO, SSAC, GNSO, ALAC, GAC. В дополнение к этим 19 членам группы в дискуссиях приняли активное участие 137 “наблюдателей” (в принципе, эта категория была открыта для всех заинтересованных лиц), которые впоследствии были переиме­нованы в “участников”. При этом утвержде­ние консенсуса и принятие решений являет­ся прерогативой членов группы.
После продолжительных обсуждений, встреч и телеконференций сообщество имен предложило решить проблему подотчетно­сти ICANN самой себе путем создания но­вого отдельного юридического лица «IANA после передачи» (Post Transition IANA, PTI) в форме некоммерческой корпорации (точ­нее – корпорации по обеспечению обще­ственных интересов, зарегистрированной в штате Калифорния). В соответствии с пла­ном, эта корпорация является филиалом или дочерней компанией ICANN, а ICANN – ее полным и единственным собственником.
В рамках предложения предполагалось, что ICANN заключит с PTI контракт на вы­полнение деятельности в качестве Операто­ра функций IANA (IANA Functions Operaotr, IFO) в части функций, связанных с имена­ми. Весь персонал теперешнего отдела IANA и соответствующие ресурсы, процессы, дан­ные и «ноу-хау» будут переданы PTI.
В структуре были предусмотрены два орга­на надзора – IFR (Группа проверки функций IANA) и CSC (Постоянный комитет потреби­телей). В задачу первого органа входит пе­риодический (раз в несколько лет) анализ качества работы PTI на соответствие дого­вору между ICANN и PTI, а также описанию работ IANA (IANA SOW) в части функций, связанных с именами. В задачу CSC входит оперативный контроль для обеспечения постоянного удовлетворительного качества исполнения функций IANA для прямых потребителей услуг, связанных с именами. Это, в первую очередь, операторы регистра­тур доменов верхнего уровня, но также и другие организации, например, операторы корневых серверов. Эти органы показаны на рис. 2.

Обслуживание корневой зоны
Не секрет, что хотя в задачу IANA и входит внесение изменений в корневую зону DNS, техническое обслуживание и публикация зоны в глобальной DNS выполняется ком­панией Verisign. Об истории этого соглаше­ния, включая неудавшуюся попытку Джона Постела (Jon Postel) изменить его, я рас­сказывал в предыдущей статье «Эволюция IANA: от записной книжки Джона Постела до ICANN».
Удивительно, но этот ключевой элемент не попал в поле зрения группы CWG, пред­ложение которой не содержит никаких требований касательно отношений между Оператором функций IANA и организаци­ей, отвечающей за техническое обслужива­ние и публикацию – Verisign. В то же время этот элемент был подготовлен в ходе част­ных переговоров между ICANN и Verisign по просьбе NTIA. Сообщество потребовало, чтобы этот контракт прошел публичное об­суждение, но пока форма и содержание его неизвестно. В любом случае, это соглашение осталось за рамками предложения по пере­даче координирующей функции.
Также неясно будущее существующего со­глашения между NTIA и Verisign. История этого договора берет начало в 1993 году. Из­начально это был договор между NSI и NSF, позже перешедший в руки NTIA, по которо­му NSI, а затем Verisign выполняли функции технического обслуживания корневой зоны (внесение изменений и предоставление зоны корневым серверам), а также функцию регистратуры доменов .com, .net и .org. Этот договор сегодня содержит 32 поправки, от­ражающие постепенно менявшуюся роль Verisign от монополиста до аккредитован­ного регистратора и регистратуры доменов .com и .net.
Подотчетность
Хотя заключение договора с отдельной ор­ганизацией-провайдером услуг IANA вроде бы передавало контроль за этой функцией сообществу, неувязка все же оставалась. В конце концов, ICANN заключала договор со свей же дочерней организацией, что хотя безусловно обеспечивало лучшее раз­деление функций определения политик от администрирования реестров и корневой зоны в соответствии с этими политиками, и прозрачность этих отношений, но по-прежнему оставляло значительную часть этого контроля в руках ICANN и ее Правления. Например, ICANN могла не утвердить или недопустимо урезать бюджет PTI, также ICANN могла вставлять палки в колеса, зайди речь о передаче функций IANA от PTI к какой-либо сторонней организации.
Поэтому неотделимым от вопроса пере­дачи координирующей роли встал вопрос общей подотчетности ICANN. Простого ре­шения здесь также не предвиделось.
Для решения этой проблемы была создана еще одна группа – Сквозная рабочая груп­па сообщества по повышению подотчет­ности ICANN (Cross-Community WG Group – Accountability, CCWG). В ее состав вошли 28 членов, номинированных поддерживаю­щими организациями и комитетами ICANN, а также 169 участников.
Предложение CCWG, которое все еще находится в стадии разработки, призвано увеличить контроль сообщества в лице под­держивающих организаций и комитетов за действиями Правления. Например, досроч­но отозвать члена Правления, делегирован­ного организацией. Или расформировать Правление целиком. Сообщество также должно получить дополнительные полно­мочия в отношении обсуждения и возмож­ного отклонения бюждета, стратегического плана и внесений изменений в устав. Также будет разработан процесс апелляций для разрешения конфликтов. Основным меха­низмом принятия решений предполагается использовать консенсус.

Что дальше?
Предложение CWG было передано в ICG 25 июня 2015 года. К концу июля был ском­пилирован черновик общего предложения, который был открыт для общественного обсуждения. Период обсуждения длился до 8 сентября, а 29 октября группа выступила со следующим заявлением:
«Координирующая группа ICG закончи­ла работу над предложением по передаче координирующей роли, за исключением од­ного незавершенного пункта. Часть пред­ложения, относящегося к именам, зависит от релизации механизмов подотчетно­сти ICANN, которые в настоящее время находятся в стадии разработки в рам­ках Сквозной рабочей группы сообщества по повышению подотчетности ICANN (CCWG). Перед отправкой заключитель­ного предложения в NTIA через Правление ICANN ICG должна получить от CWG под­тверждение того, что ее требования по­дотчетности выполнены».
Схема взаимоотношений в консолидиро­ванном предложении показана на рис. 2.
Общий процесс подготовки предложения представлен на рис. 3.

Сможет ли группа CCWG прийти к удов­летворительному соглашению в ближайшее время? Выскажет ли Правление ICANN осо­бое мнение при передаче окончательного предложения NTIA? Как пойдет процесс об­суждения внутри правительства США и ка­кую роль будет играть Конгресс? Сможет ли NTIA дать зеленый свет процессу передачи до того, как предвыборная лихорадка США отодвинет эти вопросы на второй план?
Возможно, ответы на эти вопросы мы сможем обсудить в следующей статье этой серии.

*Файл хинтов (hints) содержит адреса всех корневых серверов и необходим для из­начального запуска процесса трансляции имен резолвером.
**Три года – такова стандартная продол­жительность контракта с возможностью двухразового продления, растягивающей его до максимального срока в семь лет.­