Кратко

  • Реестр адресного пространства IPv4 IANA вписывает AFRINIC в шесть блоков /8 в двух формах: четыре с простым обозначением AFRINIC, статусом ALLOCATED и отмеченными датами 2005, 2008, 2010 и 2011 годов; два с пометкой «Administered by AFRINIC», статусом LEGACY и отмеченной датой 1993-05.
  • В полученном фрагменте каждая запись представляет собой набор из пяти элементов: блок, назначенный регистратор, дата, сервер whois и статус; ни одна запись не называет резолюцию, соглашение или решение, которыми изменилось какое-либо обозначение.

Шесть блоков, два глагола

Африканский региональный регистратор появляется в реестре адресного пространства IPv4 IANA под двумя разными обозначениями, и разница не косметическая. Полученный в этом обзоре фрагмент читается в формате полей реестра так:

041/8 AFRINIC 2005-04 whois.afrinic.net ... ALLOCATED 102/8 AFRINIC 2011-02 whois.afrinic.net ... ALLOCATED 105/8 AFRINIC 2010-11 whois.afrinic.net ... ALLOCATED 154/8 Administered by AFRINIC 1993-05 whois.afrinic.net ... LEGACY 196/8 Administered by AFRINIC 1993-05 whois.afrinic.net ... LEGACY 197/8 AFRINIC 2008-10 whois.afrinic.net ... ALLOCATED

Этот отрывок — фрагмент реестра в том виде, в каком его передал поставщик, а не прочтение страницы целиком; он приводится здесь потому, что сам формат полей и составляет находку. Четыре блока несут простое обозначение AFRINIC со статусом ALLOCATED. Два несут более длинную формулу «Administered by AFRINIC» со статусом LEGACY, и у обоих одна и та же отмеченная дата: 1993-05.

Арифметика — это то место, где стоит остановиться. Дата 1993-05 предшествует 2005-04, самой ранней отмеченной дате ALLOCATED для AFRINIC, почти на двенадцать лет. Поэтому дата на двух блоках LEGACY не может быть датой, в которую действовала AFRINIC. Это сохранившаяся дата более раннего выделения, приписанного теперь регистратору, которого в момент фиксации этой даты не существовало. Читатель, принимающий реестр за хронологию африканской регистрации, прочтёт эти две строки как факт об AFRINIC. Они — факт об адресном пространстве, сохранённый в тот момент, когда менялся столбец администратора.

Именно это различение и сглаживает повествовательная версия перехода. Делегирование блока регистратору и административное назначение блока, выделенного задолго до существования этого регистратора, — два разных действия, записанных в одну и ту же таблицу. Таблица построена так, чтобы отвечать на один вопрос — к кому должен обращаться держатель, — и отвечает на него одинаково в обеих строках. Сервер whois один и тот же во всех шести записях. На практике исторический держатель 154/8 и держатель 041/8, получивший блок после 2005 года, направляются в одно и то же место.

Пункт назначения — не полномочие

Здесь проходит граница документа, и это граница полей, а не вопрос толкования. В полученном фрагменте каждая запись состоит из пяти элементов: блок, назначенный регистратор, дата, сервер whois и статус. Ничто в этой структуре не предусматривает места для документа. Ни одна запись не ссылается на резолюцию, соглашение, решение совета или политику, в силу которых изменилось какое-либо обозначение, и ни одна не называет орган, который это изменение санкционировал.

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

На этот вопрос реестр молчит точно и проверяемо. Он показывает, что административная ответственность за 154/8 и 196/8 лежит на AFRINIC. Он не показывает, когда это отнесение было сделано, каким действием и на каких условиях. Дата 1993-05 на это ответить не может, потому что она фиксирует выделение, а не переотнесение. Тот, кто ищет документ перехода, не найдёт его в этой таблице, и молчание таблицы не доказывает, что документа нет вовсе, — только то, что этот документ его не содержит.

Три класса документов, которые решили бы вопрос, и почему их здесь нет

Документы, способные ответить на вопрос о полномочии, поддаются определению, и ни один из них в этом обзоре получен не был. Это архив управления регистратора-предшественника, а именно протоколы исполнительного совета RIPE NCC, где находилось бы решение о прекращении регистрации в африканском регионе, если оно было зафиксировано в такой форме; архив признающего органа, а именно материалы резолюций совета ICANN от 8 апреля 2005 года, где находилось бы признание регистратора региональным для Африки, отличное от любой передачи регистрационных дел; и собственное опубликованное изложение регистратора на странице истории AFRINIC, естественном месте для хронологии создания и начала работы.

Граница поиска, вместе с её арифметикой: в этом обзоре было сделано пять попыток поиска, из которых две завершились отказами ёмкости поставщика с неизвестным исходом, а три вернули результат. В рамках этих попыток преследовались четыре класса документов. Один был прочитан — реестр IANA, — три получить не удалось. Три непрочитанных класса — это протоколы исполнительного совета RIPE NCC, материалы резолюций ICANN и страница истории AFRINIC. Это полное разделение: четыре класса, один прочитан, три не получены.

Дальнейшее дробление этих чисел здесь не утверждается, поскольку попытки пересекались между классами и подсчёты по классам не давали бы в сумме общего числа попыток.

Следствие для этой статьи узкое, и его нужно назвать без оговорок в обе стороны. Что говорит документ признания от апреля 2005 года, что RIPE NCC зафиксировал относительно африканских регистраций и что AFRINIC публикует о собственном начале работы, здесь не устанавливается. Фрагмент реестра сам по себе состоятелен как прочтение на уровне документа. Всё, что касается актов полномочия, остаётся непрочитанным.

Почему участнику важно знать, какую из двух форм он видит

Запись справочника, из которой возникла эта статья, — запись RIPE NCC to AFRINIC Transition. То, что она называет, — это переход, а обычное прочтение перехода есть прочтение преемственности: те же регистрации, обслуживаемые новым администратором, в рамках договорённости, которую кто-то заключил. Реестр поддерживает половину этого прочтения, касающуюся преемственности, — тот же сервер whois, те же держатели, шесть блоков — и ничего не говорит о договорённости.

Этот разрыв тяжелее всего для держателей, чьи блоки самые старые. Историческая регистрация — тот вид актива, статус которого оспаривается именно там, где требуются документы: заявка на передачу, правопреемство компании, спор о том, вправе ли регистратор пересмотреть цену или отозвать регистрацию. В этот момент вопрос не «кто мой регистратор» — на это таблица отвечает, — а «какой документ поместил мою регистрацию туда, где она есть, и что этот документ позволял». Таблица на это ответить не может, а три документа, которые могли бы, — ровно те три, что здесь получить не удалось.

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