Кратко

  • В 2015 году Alain Durand свёл пять лет доступной статистики IANA к трём потокам: доменные имена, номерные ресурсы и параметры протоколов.
  • После появления новых gTLD выросли запросы на делегирование; обращения по номерным ресурсам оставались в целом стабильными, а многочисленные запросы PEN он показал отдельно.
  • Подсчёт обращений описывает активность, но не доказывает трудоёмкость, своевременность, точность, последствия ошибки или то, кто вправе определять и пересматривать применяемую политику.

Пользователь увидел внутреннюю работу

Публикация Alain Durand от 27 мая 2015 года начинается с признания ограниченности собственного взгляда. Более двадцати лет он работал в IETF, возглавлял рабочие группы и участвовал в подготовке RFC. Он знал реестры IANA по их использованию инженерами. Но через несколько месяцев после прихода в ICANN понял, что опыт пользователя не даёт представления о том, как устроена внутренняя обработка запросов.

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

По его статье, подразделение обслуживало свыше 2 800 реестров для трёх сообществ: доменных имён, номерных ресурсов и параметров протоколов, включая реестры IETF. Это размер каталога, а не число одинаково активных очередей. Реестр может редко меняться и при этом быть важным для непрерывности. Другой может создавать много типовых операций. Количество реестров не переводится напрямую в часы работы, сложность или риск.

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

Три потока с разной динамикой

Для доменов Durand отделил делегирование и повторное делегирование ccTLD и gTLD от изменений контактов, серверов имён и записей DS. На графике виден рост делегирований и повторных делегирований gTLD после появления новых доменов верхнего уровня. Это показывает, как новая программа изменила поступление запросов в операционную службу. Это не доказывает, что программу создала IANA или что рост числа обращений равен росту их сложности либо общественной значимости.

В сегменте номерных ресурсов была другая картина. До 2010 года региональные интернет-регистратуры запрашивали крупные блоки IPv6 unicast. В 2011 году исчерпался пул нераспределённых IPv4 unicast-адресов IANA; несколько возвращённых блоков позднее распределили между RIR согласно глобальной политике. При этом число поступавших оператору запросов по номерным ресурсам в показанной пятилетней серии оставалось в целом ровным. Это описание запросов на распределение, а не всего использования адресов, сетевого трафика или степени дефицита IPv4.

Большинство реестров параметров протоколов, которые обслуживала IANA для IETF, относились к спецификациям IETF. Чаще всего запрашивались Private Enterprise Numbers (PEN), обычно используемые при настройке SNMP MIB. Поскольку масштаб PEN затруднял чтение остальных рядов на одной шкале, Durand вынес их в отдельный график. Решение повысило читаемость, но также показывает, что группировка и выбор осей влияют на то, какие различия замечает аудитория.

В сводном графике он показал три сообщества вместе и использовал вторую ось для делегирований ccTLD и gTLD. По его оценке, общий объём был предсказуемым, кроме эффекта новых gTLD; поток номерных ресурсов оставался ровным, а запросы параметров протокола росли после затишья в середине 2012 года. Такая картина описывает движение потоков. Она не доказывает, что один запрос из каждого ряда требует одинакового труда, или что общий итог измеряет производительность.

Число — ещё не оценка услуги

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

Контрактный отчёт C.4.4 за май 2015 года измерял другие стороны работы. Для обычных изменений делегированных доменов верхнего уровня цель составляла завершение 80% в течение 21 дня; фактически в срок завершили 86,1%, точность составила 100%. Для номерных ресурсов отдельно отслеживались корректное применение политики, сроки обновления реестров, раунды уточнений, время завершения и публичная прозрачность. В том месяце не завершили ни одного запроса по номерным ресурсам. Эти сведения не опровергают график Durand: они отвечают на вопросы о времени, точности и процессе, а не о количестве.

Граница полномочий сформулирована в RFC 2860. Назначение параметров протокола в сфере IETF следует критериям и процедурам RFC; при технической неопределённости IANA обращается за указанием к IESG. Оператор выполняет работу в рамках правил, но счётчик запросов не является источником этих правил. RFC 3901, 3363 и 4472 также фиксируют техническую работу Durand по DNS и IPv6 совместно с другими авторами и редакторами. Это подтверждает опыт, а не единоличное авторство.

Итоговое предложение ICG от 10 марта 2016 года сохранило раздельные обязанности по политике и надзору за доменами, номерными ресурсами и параметрами протоколов у соответствующих операционных сообществ. В тот же день предложение принял совет ICANN. В рассмотренных документах нет утверждения, что исследование Durand вызвало или определило это решение. Его вклад можно точно описать как прояснение операционного масштаба, не приписывая ему коллективно выработанную архитектуру перехода.

Что должна добавить следующая проверка

Подтверждённая последовательность проста: Durand увидел разрыв между опытом пользователя реестров и знанием внутренней работы, собрал доступные пятилетние данные, разделил их по сообществам и типам обращений и объяснил, почему PEN нужно показывать отдельно. Публикация сделала структуру услуг понятнее. Источники не позволяют оценить затраты времени по делам, восстановить весь внутренний сбор данных или утверждать, что статья повлияла на бюджет и проект перехода.

Для оценки сервиса нужны дополнительные вопросы. Что считается запросом и кто меняет это определение? Какое правило разрешало операцию и какое сообщество его установило? Какую часть срока контролировал оператор, а какую — заявитель, RIR, эксперт или орган по политике? Был ли результат точным и доступным для проверки? Кто способен рассмотреть спор и потребовать исправления? Эти вопросы связаны, но их нельзя свести к одному числу без потери смысла.

Сегодня индекс производительности IANA публикует отдельно соглашения об уровне обслуживания для имён, показатели по номерным ресурсам, статистику назначений IETF и работу сопровождающего корневую зону. Это не доказывает прямую преемственность с графиком Durand. Но такое разделение соответствует разным обязательствам и аудиториям служб.

Устойчивый рост обращений может стать поводом проверить ресурсы, процедуры или влияние внешней программы. Сам по себе он не диктует изменение политики. Ровный поток тоже не означает отсутствия риска: редкий запрос способен иметь большие последствия. Показатель следует выбирать под конкретное решение.

Исследование Durand полезно как карта: оно показывает, откуда поступала работа и как менялся её состав. Карта не предоставляет наиболее активному сообществу дополнительных полномочий и не доказывает качество сервиса. За видимостью должны следовать проверка правил, результатов и наличие института, который способен пересмотреть решение и исправить последствия.

Источники