Эволюция IANA: на финишной кривой

Редакция

Эта третья и последняя статья из серии, рассказывающей об истории и эволюции IANA, включая текущую стадию передачи надзорной роли правительства США в руки международного сообщества. В этой статье рассматривается заключительный этап работы международного сообщества над проектом предложения, завершившийся 10 марта 2016. В этот день Координирующая Группа ICG объявила, что она одобрила общий согласованный план передачи IANA и направила окончательное предложение на рассмотрение NTIA через Правление ICANN.
В предыдущей статье на тему эволюции IANA мы говорили о процессе и основных моментах предложений по передаче координирующей роли NTIA в осуществлении функций IANA в руки мирового сообщества. Предложений было подано три, от каждого «операционного сообщества» – сообщества, непосредственно пользующегося услугами IANA. От сообщества протоколов, сообщества номерных ресурсов и сообщества имен.
Каждое из сообществ независимо определило процесс разработки предложения. Так, сообщество протоколов в лице IETF создало рабочую группу IANAPLAN, которая провела работу, руководствуясь процессом разработки стандартов IETF. Сообщество номерных ресурсов в лице РИРов выбрало 15 представителей в специальную группу по разработке Консолидированного предложения РИР по координирующей роли – CRISP. Для разработки предложения для имен была создана группа CWG – Сквозная рабочая группа сообщества имен (также получившая название CWG-Stewardship, CWG-Координирующая роль), сформированная из представителей поддерживающих организаций и комитетов, имеющих отношение к доменным именам. В изначально установленный срок – 15 января 2015 года – были поданы два предложения – от протоколов и номерных ресурсов.
Предложение от имен поступило пять месяцев спустя – 25 июня 2015 года. Наконец, к концу октября того же года группа ICG (Координационная группа по передаче координирующей роли в исполнении функций IANA) завершила работу над консолидированным предложением. Однако уже к концу лета было очевидно, что изначальный план нереалистичен, и в сентябре 2015 года NTIA продлило контракт еще на один год, установив очередную целевую дату – сентябрь 2016 года.
Дело в том, что хотя консолидированное предложение было формально готово, оно не могло быть отправлено в NTIA через Правление ICANN из-за существенной неразрешенной зависимости. Часть предложения, относящегося к именам, зависела от реализации механизмов подотчетности ICANN. Перед отправкой заключительного предложения группа ICG запросила подтверждение от CWG в том, что ее требования подотчетности выполнены.
Как я писал в предыдущей статье, над этой проблемой работала другая группа – Сквозная рабочая группа сообщества по повышению подотчетности ICANN (Cross-Community WG Group – Accountability, CCWG). В ее состав вошли 28 членов, номинированных поддерживающими организациями и комитетами ICANN, а также 169 участников. Работать группа начала еще в 2014 году, но год спустя конца этому проекту еще не была видно.
Как же получилось, что задача передачи ограниченной и во многом формальной роли NTIA переросла в реформу ICANN?

Подотчетность
Дело здесь в основном связано с функцией IANA по координации внесения изменений в корневую зону DNS. Задача эта не такая уж сложная, но политически очень значимая. Можно сказать, что собственно эта функция и является основным мотивирующим фактором в процессе передачи роли NTIA, призванным во многом устранить асимметричную роль правительства США в управлении корнем DNS.
Задача выбора модели управления также усложнялась тем, что в отличие от сообщества номерных ресурсов и параметров протоколов, не существует единого сообщества имен. Вместо этого имеется сообщество администраторов национальных доменов и сообщество общих доменных имен. Поскольку управление корневой зоны имеет ключевое значение для работы всей глобальной системы DNS, необходимо учитывать интересы и интернет-пользователей, и правительств государств.
Наконец, и это, пожалуй, самое важное, все эти сообщества представлены организациями поддержки – ccNSO, gNSO – и различными комитетами – ALAC (At-Large Advisory Committee) и GAC (Government Advisory Committee). Все эти структуры являются частью самой ICANN, то есть для имен не существует внешней по отношению к ICANN организации, или организаций, которые представляли бы интересы различных сообществ имен. В этом еще одно существенное отличие от номерных ресурсов и параметров протоколов, для которых эту представительскую роль выполняют РИРы и IETF соответственно. И если эти сообщества выбрали договорные отношения с оператором IANA как наиболее простую форму установления подотчетности, в случае имен эта возможность отсутствовала: получалось, что ICANN заключала договор с ICANN и являлась подотчетной самой себе.
Как я писал в предыдущей статье, для разрешения этой загвоздки было предложено создание нового отдельного юридического лица «IANA после передачи» (Post Transition IANA, PTI) в форме некоммерческой корпорации (точнее — корпорации по обеспечению общественных интересов, зарегистрированной в штате Калифорния). В соответствии с планом, эта корпорация должна была являться филиалом или дочерней компанией ICANN, а ICANN — ее полным и единственным собственником.
Хотя заключение договора с отдельной организацией-провайдером услуг IANA вроде бы передавало контроль за этой функцией сообществу, неувязка все же оставалась.
В конце концов, ICANN заключала договор со своей же дочерней организацией, что хотя безусловно обеспечивало лучшее разделение функций определения политик от администрирования реестров и корневой зоны в соответствии с этими политиками и прозрачность этих отношений, по-прежнему оставляло значительную часть контроля в руках ICANN и ее Правления. Например, ICANN могла не утвердить или недопустимо урезать бюджет PTI, также, ICANN могла вставлять палки в колеса, зайди речь о передаче функций IANA от PTI к какой-либо сторонней организации.
Поэтому вопрос общей подотчетности ICANN оказался неотделимым от вопроса передачи координирующей роли.

CCWG – основные вопросы
Окончательное предложение от сообщества имен, разработанное группой CWG и интегрированное в совместное предложение ICG, содержало семь требований подотчетности ICANN. Эти вопросы и стали основой работы и рекомендаций CCWG (https://www.icann. org/en/system/files/files/ccwg-accountabilitysupp-proposal-work-stream-1-recs-23feb16-en.pdf). Давайте кратко рассмотрим каждое из них.

1. Бюджет ICANN и IANA

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

2. Механизмы наделения сообщества большими полномочиями

В основном, здесь имеются в виду полномочия по отношению к Правлению ICANN – возможность отзыва отдельных членов или роспуск всего Правления, возможность осуществления надзора над ключевыми решениями Правления, в частности, относительно рекомендаций по результатам проверки функций IANA (IFR) и бюджета ICANN. Также сюда была включена возможность утверждения изменений в основной устав ICANN.
Рекомендация №4 предложения CCWG наделяет сообщество так называемыми семью дополнительными полномочиями (см. рис 1). Например, сообщество отвечает за утверждение изменений в Основной устав, а также уполномочено как отозвать отдельного члена Правления, так и расформировать Правление целиком.

3. Проверка функционирования IANA (IFR) и процесс отделения

Процесс проверки функционирования IANA помимо рекомендаций по улучшению может указать на необходимость начала процесса отделения – поиска нового «дома» для IANA. Этот процесс не имеет предопределенного разрешения и включается только тогда, когда остальные механизмы разрешения конфликтов ни к чему не привели. Управлением этим процессом будет заниматься созданная для этой цели специальная группа, и ее рекомендации могут распространяться от «дальнейших действий не требуется» до поиска нового оператора функций IANA или реорганизации PTI. Для того, чтобы проверки имели силу, они должны быть отражены в Уставе ICANN. Это является сутью рекомендации №9 CCWG.

4. Постоянный комитет потребителей

Создание Комитета, уполномоченного эскалировать неразрешенные проблемы организациям поддержки ccNSO и gNSO. Эти организации, в свою очередь, должны получить полномочия, позволяющие им эффективно решать указанные проблемы.
Рекомендация №3 предложения CCWG требует включения этой структуры в Основной устав ICANN.

5. Процесс обжалования

Суть этого требования заключается в предоставлении возможности обжалования проблем, не получивших удовлетворительного разрешения, например, посредством эскалации через Постоянный комитет потребителей. Эта возможность может быть реализована путем создания Независимой группы рассмотрения (Independent Review Panel, IRP). Рекомендация №7 CCWG предлагает соответствующие изменения в Основной устав и содержит более детальную структуру процесса.

Что за реестры обслуживает IANA?
В процессе обсуждения различных предложений по передаче координирующей роли NTIA в руки мирового сообщества много говорилось о функциях IANA, о реестрах, которые она обслуживает. Но что собой представляют эти реестры?
Реестры различны по формату и содержанию. Объединяет их одно – они все призваны обеспечить уникальность присвоенных имен, адресов, номеров и других идентификаторов. Все реестры делятся на три основные категории: реестры параметров протоколов, реестры IP-адресов и реестры имен.
Реестр параметров протоколов определяет уникальные значения определенных полей протокола и их семантику. Например, для протокола маршрутизации BGP в IANA существует несколько реестров: BGP Message Types, BGP OPEN Optional Parameter Types, BGP Path Attributes и еще пара десятков.
Например, часть реестра BGP Path Attributes показана в таблице 1.

Ссылка определяет спецификацию RFC, в которой определено поле, и его значения, а также даны инструкции IANA по обслуживанию (и во многих случаях – созданию) реестра. Документ RFC, который создает реестр, также определяет «политику», или правила, по которым новые значения могут быть присвоены. Эта относящаяся к реестрам информация определена в секции RFC «IANA Considerations», или «Соображения для IANA».
Для адресов реестров меньше, но принцип такой же. Основная структура определяется IETF. Так, например, IETF через RFC4291 определяет адресное пространство IPv62000::/3 как «Global Unicast», предназначенное для распределения между сетями, подключенными к глобальному Интернету через региональные регистратуры (РИРы). Большая часть оставшегося пространства IPv6 зарезервирована IETF для будущего использования.  Наконец, когда речь идет о доменных именах, то наиболее часто упоминаемый реестр – это корневая база данных (http://www.iana.org/domains/root/db), содержащая информацию, относящуюся к делегированию того или иного домена: тип домена (национальный, общего назначения), организацию-спонсор, административный и технический контакты, а также серверы имен, обслуживающих домен.
Но IANA также обслуживает и несколько других, связанных с доменными именами реестров. Например, реестр IDN, представляющий коллекцию так называемых IDN-таблиц, которые представляют собой разрешенные кодовые точки (буквы), допустимые для регистрации многоязычных доменных имен в соответствующих реестрах.
Сам же реестр «Global Unicast» выглядит примерно, как показано в таблице 2.

6. Структура управления PTI

В своем предложении группа CWGStewardship определила основные моменты структуры PTI. В частности, определено, что юридически PTI является дочерней организацией ICANN. Также были задокументированы основные требования к Правлению PTI. Для закрепления этих решений, они должны быть отражены в Уставе ICANN. Хотя в предложении группы CCWGAccountability отсутствуют конкретные статьи Устава, оно рекомендует (Рекомендация №3), что эти статьи должны войти в Основной устав.

7. Основной устав

Все перечисленные предложения должны быть отображены в Уставе ICANN. Соответствующие статьи Устава формируют так называемый Основной устав, внесение изменений в который требует утверждения сообществом и в результате имеет более высокий порог. В настоящий момент отсутствует требование проведения публичных консультаций с сообществом – и любые изменения могут быть внесены в Устав 2/3 голосов Правления.
Как мы уже видели, Основной устав предлагается в Рекомендации №3.
Интеллектуальные права
Другим важным моментом, который остался неразрешенным в консолидированном предложении ICG, был вопрос, относящийся к интеллектуальным правам, – а именно к торговому знаку IANA и домену iana.org.
В предыдущей статье я отметил,что предложение сообщества номерных ресурсов (группа CRISP) содержало четкие требования относительно независимости держателя этих ресурсов, который, очевидно, не мог являться оператором IANA.
По мнению группы CRISP, если ICANN продолжала бы быть держателем этих ресурсов, это могло существенно затруднить возможность перезаключения контракта и перехода к другому оператору – ключевой элемент решения вопроса надзора.
План CRISP предлагал передать эти ресурсы в руки независимой организации, а IETF Trust (http://trustee.ietf.org/) рассматривался в качестве возможного кандидата.
IETF согласился с этим предложением и Правление IETF Trust выступило с заявлением о готовности Trust принять на себя эти обязательства. Сообщество имен пребывало в нерешительности относительно этого вопроса и формально не высказалось ни в пользу, ни против такого решения. Вместо этого юридической компании Sidley Austin LLP было поручено провести анализ нескольких сценариев решения вопроса с различными держателями интеллектуальной собственности.
Юристы Sidley рассмотрели три сценария:
ICANN продолжает являться держателем этих ресурсов, PTI становится держателем интеллектуальной собственности и, наконец, ресурсы передаются независимой организации, такой как, например, IETF Trust.
Однако после непродолжительного обсуждения этих предложений стало очевидно, что первые два сценария неприемлемы, так как противоречат принципам управления интеллектуальной собственностью IANA, разработанным сообществом номерных ресурсов (CRISP).
Вопрос повис в воздухе.
Между тем, IETF Trust представил схему, как управление интеллектуальной собственностью может быть осуществлено путем отдельных договоров с операционными сообществами. Эта рамочная схема была призвана разрешить сомнения относительно возможности одного из сообществ – IETF – узурпировать права. И случилось чудо – было принято совместное (между представителями операционных сообществ) прагматичное решение взять за основу IETF Trust как держателя собственности – и не заниматься разработкой более сложных и теоретически более элегантных решений, как, например, создание новой организации.
Таким образом, этот элемент перешел в разряд вещей, относительно которых существует принципиальная договоренность, и реализация которых должна произойти до окончания контракта NTIA.
Зри в корень
Вопрос управления корневой зоной DNS, разумеется, является одним из ключевых в процессе передачи координирующей роли NTIA. Здесь можно выделить три элемента:

• Утверждение изменений в корневую зону, в настоящий момент выполняемое NTIA.

В ходе обсуждений группой CWG было решено полностью исключить этот шаг.
Проще решения трудно было придумать.

• Утверждение существенных архитектурных и операционных изменений в систему обслуживания корневой зоны, в настоящий момент также выполняемое NTIA.

Примером такого изменения является внедрение DNSSEC в корне. Эта функция будет передана Правлению ICANN, действующему по рекомендации специального комитета с достаточно широким представительством.
• Договор на обслуживание корневой зоны в настоящее время существует в виде Кооперативного соглашения между NTIA и Verisign. Об этом договоре я писал в предыдущей статье. Будущее этого договора неизвестно, но ясно, что если он будет продолжать существовать, он должен быть модифицирован для исключения требования утверждения изменений. Также в любом случае должен быть заключен дополнительный договор между ICANN/PTI и Verisign. Этот вопрос относится к фазе реализации.
Последний рывок
10 Марта 2016. «Координирующая Группа ICG объявляет сегодня, что она одобрила общий согласованный план передачи IANA и направила окончательное предложение для передачи NTIA через Правление ICANN.
ICG единогласно поддерживает это предложение и рекомендует, чтобы все затронутые стороны реализовали его. ICG утверждает, что это предложение и все связанные с ним процессы соответствуют критериям, изложенным в нашем уставе и мандате, в том числе критериям NTIA».
Днем позже Правление ICANN постановило передать это предложение на рассмотрение NTIA.
В тот же день NTIA опубликовало на своем сайте заявление руководителя NTIA Лоренса Стриклинга (Lawrence E. Strickling) (https://www.ntia.doc.gov/blog/2016/ reviewing-iana-transition-proposal). В частности, он отметил: «Теперь NTIA начнет процесс рассмотрения этого предложения – мы надеемся, в течение 90 дней, – чтобы определить, соответствует ли он критериям, которые мы определили, когда объявили о передаче».
Что ж, будем ждать.