Резюме
Учредительная граница.Условия RIPE 1989 года оставляли исполнительные полномочия над каждой сотрудничающей сетью за её собственной организацией. Впоследствии документ RIPE-019 предложил создать небольшое сервисное бюро с тремя классами задач: ведение реестра, управление сетевой информацией и общая поддержка RIPE.
Зафиксированные полномочия и взвешенный вывод.К 1992 году NCC обслуживал центральную базу данных и действовал как делегированный реестр номеров. В RIPE-065 было зафиксировано правило, согласно которому запросы на блоки класса B должны сопровождаться обоснованием для проверки NCC. Европейские NIC и NOC, принимавшие блоки класса C, брали на себя обязанности по отчётности, предотвращению накопления номеров и возврату неиспользуемых номеров. Более поздние внутренние обзоры и управленческая отчётность описывали ограниченную делегированную деятельность в значительных масштабах. Документы подтверждают выполнение существенных административных функций в рамках определённого регистрационного канала при сохранении операторского контроля над сетями. Любые более широкие полномочия в последующем потребовали бы нового документа.
Проблема координации
Документ RIPE-001 появился в Амстердаме 29 ноября 1989 года, ещё до существования NCC. Его шестью авторами были Rob Blokzijl, Mats Brunel, Francois Fluckiger, Daniel Karrenberg, Olivier Martin и Enzo Valente. RIPE расшифровывалось как «Réseaux IP Européens» и определяло Европу как зону своей ответственности. Эти условия отвечали на распространение глобальных IP-систем, выходящих за пределы локальных сетей через национальные и международные каналы. Европейские IP-сети описывались как совокупность национальных и международных систем, управляемых отдельными организациями.
Целью RIPE была административная и техническая координация, необходимая для эксплуатации и расширения общеевропейской IP-сети. Организация призывала все стороны, эксплуатирующие глобальные IP-сети, участвовать в работе и способствовала объединению сетей в Европе и с другими континентами. Практическая задача возникала между независимо управляемыми системами: операторам требовались надёжные контакты, обмен технической информацией и площадка для согласования общих практик. Слово «общеевропейский» обозначало масштаб этой координационной проблемы.
Составные сети сохраняли собственные линии управления, круги заинтересованных сторон и эксплуатационные обязанности.
Условия возлагали на RIPE три взаимосвязанные роли. Он был форумом для обмена технической информацией и опытом, координационным центром для деятельности, представляющей общий интерес, и площадкой для согласования практик управления сетями и оперативного управления взаимосвязанными сетями. Все документы RIPE должны были быть общедоступными. Публикация давала операторам общую письменную основу, которая могла распространяться за пределами встреч, однако реализация по-прежнему проходила через организацию, управляющую каждой сетью.
RIPE мог созывать обсуждения, фиксировать выводы и организовывать совместную работу, не поглощая ресурсы или персонал участников. Его непосредственным институциональным результатом была координация между операторами — общая площадка, на которой отдельно управляемые сети могли решать вопросы в точках соприкосновения своих систем.
Одно предложение устанавливало решающую границу. RIPE не был поставщиком сетевых услуг, и каждая сотрудничающая IP-сеть оставалась под исполнительной властью соответствующей организации. Маршрутизаторы, персонал и операционные решения, таким образом, оставались за сетевыми организациями. Такое распределение определяет и рамки для последующего NCC. Специализированный офис мог выполнять важные региональные функции и принимать решения в рамках делегированной процедуры, не получая исполнительного управления над участвующими сетями.
Исторический вопрос имеет два измерения: насколько значимыми были последствия порученной задачи и как далеко простирался инструмент, несущий эту задачу. Техническая взаимозависимость может делать согласованные записи и общие процедуры необходимыми, но сама по себе взаимозависимость оставляет управленческие границы нетронутыми.
Документ RIPE-019, датированный 16 сентября 1990 года и подготовленный R. Blokzijl, Y. Devillers, D. Karrenberg и R. Volk, касался практической слабости кооперативной модели. Встречи RIPE и добровольные группы могли запускать проекты, но повторяющаяся административная работа требовала внимания каждый рабочий день. Предложение предусматривало выделенный технический персонал и известный офис, где ведение записей, обмен данными и запросы могли стать закреплёнными обязанностями. RIPE-019 также представлял центр как строительный блок формирующейся глобальной административной архитектуры интернета со ссылкой на RFC 1174.
Заявленной главной целью была поддержка сетевых организаций, сотрудничающих в RIPE, включая координацию, которая позволила бы их собственным сотрудникам NOC предоставлять услуги. Постоянство представлялось как ответ на нерегулярность исполнения, а не как конституционная трансформация. Оплачиваемый персонал мог поддерживать общие сервисы между встречами RIPE, позволяя добровольцам сосредоточиться на разработке, а участвующим организациям — продолжать эксплуатировать собственные системы.
Предлагаемый центр, таким образом, был сервисным бюро в буквальном смысле: компактным офисом, созданным для того, чтобы дать повторяющимся региональным задачам стабильное пристанище.
Предлагаемые ресурсы соответствовали этой цели. В RIPE-019 указывались: 1,0 ставки полной занятости для руководителя, 1,0 для технической работы и 1,5 для административной. Предусматривались рабочие станции X Window, миникомпьютер, способный размещать базы данных, надёжное IP- и почтовое подключение, связь по OSI, два офиса и обычные вспомогательные службы. Предположения о командировках охватывали все встречи RIPE, шесть других европейских встреч и четыре встречи за пределами Европы в год.
Позже RIPE-035 запросил минимальные сроки готовности: три года для руководителя, один год для технического специалиста и два года для административного сотрудника. Также близость к действующему NOC и другой активности RIPE считалась существенной. Требования к руководителю сочетали крупномасштабные интернет-технологии, управление и международную работу; техническая должность требовала опыта работы с крупными сетями и международного опыта. От административного персонала ожидалось как использование передового вычислительного оборудования, так и выполнение офисной работы.
Вместе эти предложения описывали навыки, оборудование, расположение и непрерывность, ожидаемые от небольшого технического офиса.
Небольшой масштаб не делал предлагаемую работу тривиальной. Поддерживаемый реестр мог стать общим справочником; офис, обрабатывающий запросы на номера, мог занять значимую точку в цепочке распределения. RIPE-019 предусматривал регулярное обслуживание наряду с ограниченными полномочиями по принятию решений, но его центр должен был получать функции от RIPE, работать с участвующими организациями и координироваться с вышестоящим интернет-реестром.
В предложенном списке поддержки назывались сбор данных о глобальном состоянии, мониторинг производительности, распространение европейской DNS, документация операционных инструментов и управление информационным сервером RIPE. Такая структура помещает NCC между двумя вводящими в заблуждение карикатурами. Он был больше, чем просто стол для копирования, поскольку некоторые порученные операции могли влиять на доступ к признанным регистрационным каналам. Он был меньше, чем региональный суверен, поскольку окружающие операторы, реестры и координационные органы сохраняли собственные функции.
Поэтому каждое заявляемое полномочие должно прослеживаться до конкретного акта, документа и действующего лица, которые его обеспечили.
Хронология важна не меньше, чем формулировки. RIPE-001 устанавливал условия кооперативного форума. RIPE-019 предлагал создать центр. RIPE-035 представил план деятельности. Эти документы фиксируют последовательные проектные решения, а не единый момент исполнения. Операционные процедуры и отчёты о состоянии позже показывают, как отдельные функции переходили в практику, и иногда раскрывают портфель, отличный от того, который представляли планировщики.
Таким образом, история создания представляет собой последовательность институциональных состояний: принципы координации в 1989 году, предложение сервисного центра в 1990-м, детальная рабочая программа в 1991-м и задокументированная деятельность в 1992 и 1993 годах. Следование этой последовательности позволяет аналитически различать предложенный офис, запланированную программу и наблюдаемую регистрационную службу.
Возложенная задача
В RIPE-019 были названы ровно три класса задач: функция реестра, управление сетевой информацией и функция общей поддержки RIPE. Поддержка конечных пользователей и эксплуатация сетей оставались за сетевыми службами участвующих организаций. Предложение также разделяло труд между централизованными задачами, выполняемыми сотрудниками NCC, и распределёнными задачами, которые выполняли участвующие организации под координацией NCC. Четыре отношения связывали офис с RIPE: RIPE должен был определять задачи и функции центра; NCC — отчитываться перед RIPE; организации RIPE — участвовать в его работе; а RIPE — регулярно пересматривать его деятельность.
Периодическая оценка со стороны RIPE сопровождала распределённую программу. В такой конструкции центр получал свою сферу деятельности от RIPE и совмещал активность собственного персонала с вкладом более широкого сообщества.
Предлагаемая функция реестра помещала центр между европейскими локальными реестрами и интернет-реестром. Он должен был вести реестр номеров IP-сетей и номеров автономных систем, получать блоки для распределения через локальные реестры, собирать информацию, предоставляемую на местах, и делать сводные материалы доступными по всему миру. Он также должен был обрабатывать запросы, выходящие за пределы локальных возможностей, и тесно координироваться с интернет-реестром.
Локальные реестры оставались ответственными за распределение из своих блоков; региональный центр вёл общий реестр и принимал случаи, выходящие за пределы локальных возможностей; вышестоящий реестр оставался частью схемы. Таким образом, предложение создавало административный узел, где информация и исключительные запросы могли перемещаться между локальным и глобальным уровнями.
Управление сетевой информацией составляло второй класс задач. RIPE-019 выделял информацию о номерах IP-сетей, номерах автономных систем, доменах DNS и связанных с ними людях. Описывалось движение информации в четырёх направлениях: от европейских организаций к центру, от центра обратно к этим организациям, между центром и координационными органами за пределами Европы, а также от центра к более широкому сообществу. Базы данных и инструменты запросов должны были сделать эту информацию доступной через сервисы, связанные с IP и OSI. В предложении центр назывался авторитетным источником информации о сообществе RIPE.
Такая авторитетность относилась к обслуживанию и представлению общего набора данных, исходные факты которого часто поступали от организаций, ближайших к сетям.
Предложение также проводило целевую границу вокруг персональной информации. Его база данных не задумывалась как общий телефонный справочник. Авторы призывали изучить вопросы конфиденциальности с учётом европейского законодательства и определили индивидуальное согласие как минимальное условие для включения персональной информации в общедоступную базу данных. Таким образом, предложение отличало операционные контактные данные от общего справочника людей.
Подход к согласию был проектным заявлением: контактная информация, связанная с администрированием сети, могла входить в предлагаемый информационный сервис только при соблюдении указанного минимального условия. RIPE-019 ставил вопрос конфиденциальности рядом с техническими требованиями к центру ещё до того, как более поздние отчёты о состоянии описывали базу данных в действии.
Общая поддержка RIPE была третьим классом, но детальные поручения появились в RIPE-035 от 5 мая 1991 года. Этот план деятельности предписывал NCC поддерживать хранилище документов RIPE в онлайне и в удобном доступе, оказывать техническую и секретарскую поддержку исследованиям и целевым группам RIPE, а также помогать в организации встреч RIPE. Ожидалось, что в ближайшем будущем встречи будут посещать около 40 человек. Поддержка исследований должна была обеспечивать работу между встречами; канцелярская помощь позволяла организаторам готовить продуктивные сессии.
Эти задачи превращали широкую категорию поддержки из RIPE-019 в набор регулярных обязанностей, связанных с документами, рабочими группами и встречами.
RIPE-035 называл себя техническим приложением к RIPE-019. В нём говорилось, что соответствующие задачи оказалось крайне трудно выполнять регулярно на добровольных началах, и ожидалось, что централизованное исполнение повысит эффективность. Для базы данных перечислялись шесть исходных классов объектов: сети, ответственные лица, домены, маршрутизаторы, международные линии и серверы имён. Планируемая работа включала сбор записей, проверку отдельных записей и тестирование согласованности и целостности базы данных. Вторичные копии могли устанавливаться по запросу, при этом NCC отслеживал эти копии и поддерживал их согласованность.
Обмен с центрами за пределами Европы должен был обеспечить пользователям базы данных единый глобальный набор информации. Для вторичных копий NCC должен был вести онлайн-запись о площадках и поддерживать согласованность их содержимого. Задание по обмену охватывало как координацию, так и исполнение с NCC за пределами Европы. Ежемесячные карты планировались в виде файлов PostScript, доступных онлайн для удалённого получения и воспроизведения. План переводил прежний информационный мандат в конкретные обязанности, которые более поздние отчёты могли сравнивать с фактической деятельностью.
Техническая программа выходила за пределы хранения базы данных. RIPE-035 планировал вести записи о связности внутри Европы, между Европой и другими континентами, а также внутри стран или сетей, при этом внутреннее и национальное картирование зависело от сотрудничества NOC. Центр должен был поддерживать операционные контакты на случай сетевых инцидентов и инцидентов безопасности, сопровождать рекомендованное программное обеспечение DNS и информацию об известных ошибках, тестировать взаимодействие серверов имён и собирать выборочные данные о трафике и производительности.
Разработка охватывала инструменты управления базами данных и выполнения запросов, инструменты статистики и производительности, утилиты контроля качества DNS и средства для построения схем сетей. Утилита whois должна была поддерживаться как программа файлового сервера для удалённого опроса базы данных. Специализированные инструменты должны были поставляться с базовой поддержкой, а не с обещанием полной поддержки каждой установки. Операторы оставались центральным звеном в предоставлении наблюдений и реагировании на состояние сети.
Список операционных контактов должен был служить NOC во время сетевых инцидентов и инцидентов безопасности, с еженедельной подпиской на обновления. Отчёты об изменениях DNS и известных ошибках имели собственную службу подписки; обнаруженные ошибки серверов имён должны были доводиться до ответственных лиц с последующими корректирующими действиями.
RIPE-035 также предлагал конкретную схему отчётности. Еженедельные отчёты должны были охватывать изменения в базе данных и статистику записей. Ежемесячные материалы включали карты связности. Ежеквартальные отчёты о деятельности и нерешённых проблемах должны были направляться участвующим организациям RIPE и Совету RARE (RARE CoA). NCC должен был отчитываться перед встречами RIPE, которые тогда проводились три раза в год, а годовой отчёт должен был готовиться к 31 января года, следующего за отчётным. Это была запланированная еженедельная, ежемесячная, ежеквартальная, привязанная к встречам и годовая периодичность.
В плане также говорилось, что регулярная отчётность о ходе работ — еженедельная, ежемесячная и ежегодная — предусматривалась по всем направлениям работы, а ежеквартальные административные отчёты имели указанных получателей: участвующие организации RIPE и Совет RARE. Это делало регулярное раскрытие информации частью предлагаемой рабочей программы и выносило нерешённые проблемы перед названными институциональными аудиториями. Позже ежеквартальные отчёты стали исходными материалами для RIPE-099, но такое наблюдаемое использование относится к периоду обзора, два года спустя после того, как RIPE-035 изложил более широкую конструкцию.
RIPE-052 даёт компактную картину операционной деятельности. Отчёт о состоянии базы данных, подготовленный Daniel Karrenberg и опубликованный 24 апреля 1992 года, охватывал период с 25 марта по 24 апреля. В нём зафиксировано 4 574 запроса к whois-серверу RIPE NCC, в том числе 169 запросов, исходивших из самого NCC, то есть в среднем один запрос каждые десять минут. Karrenberg назвал этот объём поразительным для сервиса, который, по его описанию, не имел широкой огласки. Единицей измерения был запрос, а не человек или результат. В отчёте также говорилось, что централизованное сопровождение перешло от добровольцев к NCC, запрашивалось сотрудничество NOC, отдавалось предпочтение предварительно проверенным массовым обновлениям, и утверждалось, что информация из любого источника будет приниматься. К апрелю 1992 года названный хранитель обслуживал центральную базу данных и фиксировал месячный объём серверных транзакций. Отчёт направлял обновления наauto-dbm@ripe.net, а актуальные шаблоны были доступны по анонимному FTP с archive.ripe.net или по электронной почте от NCC. Сообщалось, что новый дистрибутив программного обеспечения базы данных почти готов, и площадкам предлагалось его протестировать. Предсказанные Karrenberg улучшения частоты и согласованности обновлений оставались перспективными, отделёнными от измеренного общего числа запросов.
Операционные полномочия
Документ RIPE-065 даёт наиболее ясное для того периода свидетельство того, как регистрационные полномочия входили в действие. Опубликованный 1 июля 1992 года и позже заменённый документом RIPE-072, он гласил, что с 1 мая 1992 года RIPE NCC действовал как делегированный реестр номеров IP-сетей для европейских NIC и NOC. Процедура отдавала предпочтение передаче номеров поставщикам услуг и NIC перед прямым назначением отдельным организациям. NIC и NOC должны были переназначать фактические номера запрашивающим организациям. Слово «делегированный» обозначало полномочия, полученные в рамках существующей системы регистрации.
NCC занимал региональную позицию, посредники выполняли переназначение, а организации получали номера ниже по цепочке. RIPE-065 фиксирует операционную схему, действовавшую с мая 1992 года. Позже RIPE-099 поместил более широкий переход вокруг этой процедуры. Его внутренняя комиссия сообщила, что в июле 1992 года интернет-реестр попросил NCC обрабатывать все заявки на номера IP-сетей от европейских организаций. После быстрой консультации с председателем RIPE и соответствующими рабочими группами NCC согласился, хотя комиссия отметила, что не все необходимые процедуры были к тому времени полностью установлены.
С 1 августа интернет-реестр пересылал европейские заявки, поступавшие по электронной почте и письмам, в NCC.
Для пространства класса B RIPE-065 описывал перспективную процедуру. Поставщик услуг мог подать запрос с обоснованием, касающимся запрашивающей организации, и RIPE NCC должен был рассмотреть это обоснование. Поставщик был посредником, подающим заявку; организация — описываемым субъектом; центр выполнял задокументированную функцию проверки. Такая формулировка устанавливает правило о том, как подобные запросы должны были представляться и рассматриваться. Она не содержит ни завершённой заявки, ни завершённого решения NCC.
Её значение состоит в закреплении перспективной административной роли: процедура помещала проверку требуемого обоснования в региональный офис внутри цепочки регистрации номеров.
Блоки класса C влекли продолжающиеся обязанности для одной точно определённой группы: европейских NIC и NOC, принявших такие блоки. Они должны были незамедлительно сообщать полную информацию о переназначении как в RIPE NCC, так и в NIC США. Отдельные переназначения приходилось вносить, поскольку база данных RIPE тогда не поддерживала записи о блоках. Посредникам предписывалось избегать переназначения номеров, оканчивающихся на 0 или 255, предотвращать накопление блоков и возвращать номера, оставшиеся неназначенными, по первому требованию RIPE NCC. Эти NIC и NOC сохраняли ответственность за назначение фактических номеров организациям.
RIPE-065 связывал обязанности по отчётности, предотвращению накопления и возврату неиспользуемых номеров с посредниками, державшими делегированный запас класса C.
Такая схема давала центру значимую позицию, не превращая его в универсального регулятора. Правило класса B наделяло его перспективной функцией проверки представленного обоснования. Процедура класса C делала его получателем информации о переназначении и субъектом, уполномоченным требовать возврата номеров, всё ещё не назначенных. Каждое полномочие имело определённый объект: обоснование, сопровождающее запрос, регистрационную информацию или неиспользованный запас, удерживаемый участвующим посредником. Процедура ничего не говорила о маршрутизаторах, сотрудниках, клиентских договорах или политике маршрутизации держателя блока.
Её административная сила возникала из положения внутри механизма распределения, где узкое указание могло влиять на обращение с признанными номерными ресурсами.
Документ RFC 1366, датированный октябрём 1992 года, даёт внешний контекст, а не устав NCC. В нём интернет-реестр описывался как вариант по умолчанию там, где не был определён делегированный реестр. IANA и интернет-реестр могли уполномочить региональный орган специально выполнять функцию регистрации номеров сетей для географической области, и в RFC наличие одного реестра на регион называлось важным для эффективного и справедливого вторичного распределения. Прямой доступ абонентов к интернет-реестру оставался доступным при необходимости, даже там, где было возможно перенаправление в региональный орган.
Ответственность за пространство классов A и B в то время также оставалась за IANA и интернет-реестром. RFC предлагал распределённую архитектуру регистрации, в которой региональные органы выполняли специализированную функцию.
Транзакции, видимые в этих документах, следует рассматривать отдельно. Запрос whois опрашивал существующие записи. Обновление базы данных изменяло информацию, переданную в общий репозиторий. Правило класса B закрепляло перспективную проверку NCC обоснования, прилагаемого к запросу. Отчёт о переназначении класса C вносил нижестоящую транзакцию в реестр, а запрос на возврат касался номеров, всё ещё удерживаемых без переназначения. Эти действия опирались на общую информационную инфраструктуру, но задействовали разных действующих лиц, объекты и последствия.
4 574 запроса из RIPE-052 измеряют серверные транзакции за один месяц; они не служат показателем активности по распределению. RIPE-065 определяет регистрационную процедуру, включая обязанности, возложенные на европейские NIC и NOC.
Язык региональности описывал зону обслуживания и разделение регистрационного труда, а не публично-правовую территорию. NCC обрабатывал европейскую информацию и запросы на номера в системе, включавшей локальные реестры, поставщиков услуг, страновые реестры, интернет-реестр и IANA. Запасной вариант прямого доступа к реестру из RFC 1366 создавал ещё один путь рядом с региональным органом. К середине 1992 года NCC уже вышел за рамки предложения: он обслуживал базу данных и действовал как делегированный реестр в рамках заявленной процедуры.
Его влияние было связано с признанными административными транзакциями, при этом вокруг оставались независимые операторы и другие уровни реестров. Это существенные, но ограниченные полномочия — более значимые, чем пассивное ведение записей, и более узкие, чем управление европейскими сетями, описанными в документах. По данным комиссии за первый год, распределённая система включала более 60 реестров поставщиков услуг и 21 страновой реестр, не относящийся к поставщикам услуг, а европейская регистрационная система назначила более 14 000 номеров сетей.
Эти цифры описывают систему, отражённую в RIPE-099, а не знаменатель количества заявителей или решений.
RIPE-099 также описывал путь для работ, отсутствовавших в RIPE-035: рабочая группа или NCC подавал предложение в RIPE; RIPE обсуждал его; NCC реализовывал его после положительного заключения. На 13-й встрече RIPE в сентябре 1992 года RIPE решил координировать деятельность по технической разработке с RARE. Комиссия связала это решение с проектами European Route Server и Generic Internet Service Description, которые выполнялись в NCC с привлечением дополнительного персонала и независимо финансируемых ресурсов.
Утверждения о том, что оба проекта завершились успешно и что работа над сервером маршрутов привела к Policy Based Routing Implementation and Deployment in Europe, были оценками комиссии. Задокументированная цепочка действующих лиц шла от предложения и обсуждения в RIPE к реализации в NCC, а для этих проектов — к решению о координации от сентября 1992 года.
Пробел в подотчётности
Документ RIPE-099, выпущенный 25 октября 1993 года R. Blokzijl, M. Sterba и W. Woeber, рассматривал первые 18 месяцев работы NCC изнутри RIPE. Комиссия использовала RIPE-035 и ежеквартальные отчёты NCC о ходе работ в качестве исходных материалов. В нём зафиксировано, что деятельность началась 1 апреля 1992 года с тремя постоянными сотрудниками. По оценке проверяющих, большинство запланированных целей было достигнуто, хотя некоторые направления не начались или не получили достаточного развития; руководство своевременно сообщало об этих отставаниях.
Комиссия также отметила, что направления, отсутствовавшие в RIPE-035, запускались с предварительного согласия сообщества RIPE. Её главной рекомендацией было согласовать в RIPE новый план деятельности к январю 1994 года, приведя формальную программу в соответствие с изменившимся портфелем офиса. В обзорном документе говорилось, что он был одобрен как отражающий взгляды RIPE. В его справочных данных насчитывалось более 60 участвующих организаций и более 450 000 доступных европейских хостов в сентябре 1993 года, при общемировой оценке, близкой к двум миллионам.
В перечень сервисов комиссии входили база данных, делегированный реестр, скоординированная статистика, координация DNS, карты, репозиторий программного обеспечения, хранилище документов и интерактивная информационная служба.
Для работ за пределами унаследованного плана RIPE-099 описывал путь принятия. Рабочая группа RIPE или NCC вносила предложение в RIPE, RIPE обсуждал его, а NCC реализовывал предложение после положительного заключения. Именно такую последовательность комиссия ожидала для добавления работ. Её описание показывает, как обсуждение в RIPE должно было связывать предложения с реализацией, и наполняет содержанием упоминание проверяющих о согласии сообщества.
Комиссия также зафиксировала более быстрый переход для регистрационных заявок в 1992 году, когда консультация с председателем RIPE и соответствующими рабочими группами предшествовала действиям в условиях нехватки времени. Две сцены показывают, как проверяющие описывали обычное принятие программы и срочное расширение регистрационной работы.
Обзор рассматривал программу базы данных строка за строкой. В нём говорилось, что деятельность соответствовала RIPE-035, что согласованные объекты и атрибуты были добавлены и что внедрялись новые инструменты проверки, сопровождения и распространения. Распространение базы данных было возможно и в нескольких случаях имело место. Комиссия объясняла ограниченный спрос на копии тем, что считала центральный сервер чрезвычайно надёжным. Также сообщалось, что формат обмена был определён совместно с InterNIC и Merit, при этом задержки фактического обмена находились за пределами NCC.
Работа по записям о связности продвигалась медленно, и проверяющие предположили, что более распределённый подход, которого придерживалась рабочая группа RIPE по связности, может оказаться уместным. Сравнение разделяло реализованные функции базы данных, ограниченное внедрение и работу, всё ещё находившуюся в разработке. Также отмечалось, что ещё не объединённая инфраструктура фиксировалась в базе данных только с того момента, когда NCC начал регистрировать европейские сети.
Инструменты управления базой данных определялись с рабочими группами по маршрутизации, Local-IR и базам данных, а улучшенное клиентское программное обеспечение, как сообщалось, широко использовалось и было интегрировано с распространёнными средствами поиска информации.
Несколько запланированных направлений получили более сдержанную оценку. RIPE-099 сообщал об отсутствии, по существу, какого-либо прогресса в сборе статистики трафика и данных о производительности сети. Комиссия считала эти задачи прежде всего относящимися к сетевым операторам, хотя допускала, что NCC мог бы предложить нейтральное хранение данных, предоставляемых провайдерами. RIPE ещё предстояло обсудить роль центра в сборе информации о качестве обслуживания. Проверяющие также отметили незначительный прогресс в инструментах для сетевой статистики и представления производительности и попросили более чётко определить роль и ресурсы NCC.
Репозиторий и общая схема именования карт сети существовали, но дальнейшее развитие остановилось. Комиссия предположила, что работа над картами могла бы лучше подойти в качестве специального проекта, смещая внимание с задержки на правильное институциональное место для задачи. Инструменты контроля качества DNS были доступны с сервера NCC, а программа карт успела создать репозиторий и общую схему именования до остановки дальнейшего развития. Роль в области качества обслуживания всё ещё ждала обсуждения в RIPE, отделяя измерения, предоставляемые операторами, от централизованно назначенной функции сбора.
Другие сервисы стали настолько рутинными, что комиссия могла описать конкретные результаты. RIPE-099 сообщал о списках операционных контактов, реализованных через почтовые рассылки, об архиве NCC с программным обеспечением и документацией DNS, а также о ежемесячном анализе европейского пространства DNS, который давал подсчёт хостов и отчёты об ошибках. Он положительно оценивал хранилище документов, техническую и секретарскую помощь, поддержку встреч и ежеквартальную отчётность. По словам проверяющих, ежеквартальные отчёты описывали достижения и нерешённые проблемы, давали обзоры европейского интернета и представлялись на каждой встрече RIPE.
Здесь ежеквартальные отчёты выступали как наблюдаемые исходные материалы и регулярные презентации, в отличие от более широкой еженедельной, ежемесячной, привязанной к встречам и годовой схемы, предложенной в RIPE-035. Комиссия сообщила, что первый годовой отчёт только что был подготовлен. Также описывались презентации текущей работы и нерешённых проблем на каждой встрече RIPE, где, по оценке проверяющих, многие нерешённые вопросы требовали участия и решения RIPE.
Регистрационная работа была самым крупным направлением, отсутствовавшим в первоначальном плане. RIPE-099 сообщал, что в июле 1992 года интернет-реестр попросил NCC обрабатывать все заявки на номера IP-сетей от европейских организаций. NCC быстро проконсультировался с председателем RIPE и соответствующими рабочими группами, после чего согласился, хотя времени было недостаточно для полного установления всех необходимых процедур. Комиссия назвала целью разгрузку интернет-реестра и как можно более раннее улучшение сроков ответа для европейских организаций.
С 1 августа 1992 года, как сообщалось, интернет-реестр пересылал европейские заявки, поступавшие по электронной почте и письмам, в NCC. Изложение комиссии привязывает запрос, консультацию, переход и порядок пересылки к июлю и августу 1992 года.
Комиссия отметила, что NCC с самого начала строил распределённый реестр. Он стремился выявить как можно больше поставщиков услуг и делегировать им блоки класса C для переназначения. Страновые реестры приглашались заявить о себе, чтобы обслуживать организации, не имеющие поставщика IP-услуг. Через год RIPE-099 сообщал о более чем 60 реестрах поставщиков услуг, 21 страновом реестре, не относящемся к поставщикам услуг, и более чем 14 000 номеров IP-сетей, назначенных европейской регистрационной системой.
Проверяющие назвали регистрационную работу выполненной чрезвычайно хорошо и объяснили организованный рост системы своевременной и точной ежедневной работой. Эти оценки принадлежали комиссии; цифры фиксируют масштаб, о котором она сообщала за первый год.
Второе расширение последовало за 13-й встречей RIPE в сентябре 1992 года. RIPE-099 сообщал, что RIPE решил тогда координировать деятельность по технической разработке с RARE. Проекты European Route Server и Generic Internet Service Description были затем определены и выполнялись в NCC в рамках технической программы RARE. Дополнительный персонал и ресурсы, финансировавшиеся независимо от другой деятельности NCC, осуществляли проекты, при этом NCC предоставлял ресурсы для их запуска и управления.
Комиссия сообщила, что оба проекта завершились успешно, и отметила, что работа над сервером маршрутов привела к Policy Based Routing Implementation and Deployment in Europe. Она сочла сотрудничество полезным и заявила, что два проекта не оказали негативного влияния на основную ежедневную работу.
Формальное разделение всё же оставляло практическое соприкосновение между проектами и основными ресурсами. В заключении RIPE-099 говорилось, что размещение специальных проектов автоматически отвлекало определённое управленческое и техническое внимание NCC, даже если их персонал и финансирование были отдельными. Комиссия охарактеризовала этот вклад как намеренный и выходящий за рамки RIPE-035. Она использовала этот аргумент в поддержку пересмотренного плана деятельности, который отражал бы фактический портфель офиса.
Замечание касалось классификации и планирования: проекты с отдельным финансированием всё же могли опираться на центр, который их размещал и управлял ими. К январю 1994 года проверяющие хотели, чтобы базовая программа включала работу, которую NCC фактически взял на себя. В обзоре также говорилось, что регистрационная работа потребовала гораздо больше ресурсов, чем первоначально предполагалось, и отмечалось, что сама эта деятельность не была явно указана в RIPE-035.
Обзор также описывал небольшие незапланированные услуги. Когда потенциальные клиенты спрашивали об интернет-услугах, NCC избегал выбора поставщика. Он пересылал запрос и контактные данные обратившегося в почтовую рассылку поставщиков услуг, участники которой могли связаться с заявителем по своему желанию. Комиссия охарактеризовала этот метод как беспристрастный и хорошо принятый. Она также сообщала о регулярных запросах на презентации о работе NCC и процедурах европейского интернета, расценивая их повторяемость как признание.
Схема пересылки и презентации, по описанию проверяющих, показывают офис как нейтральный информационный узел, при этом поставщики услуг впоследствии сами выходили на связь. Комиссия отметила, что NCC выполнял множество запросов на презентации от поставщиков услуг и конференций для распространения информации о своей работе и процедурах европейского интернета.
Документ RIPE-113 — годовой отчёт за 1993 год, подготовленный Daniel Karrenberg, — представляет управленческую картину по итогам года. В нём NCC описывался как структура, поддерживающая европейских поставщиков интернет-услуг и финансируемая этими поставщиками через формальную схему, предоставленную RARE. Руководство сообщило, что число европейских интернет-хостов, зарегистрированных в системе доменных имён, за 1992 и 1993 годы примерно удвоилось. В части регистрации отчёт описывал 83 локальных реестра, управляемых поставщиками услуг, и говорил, что NCC делегировал им адресное пространство.
Было зафиксировано 16 871 номер сети, назначенный европейскими интернет-реестрами в течение 1993 года. NCC также обрабатывал крупные запросы и запросы от предприятий, не имевших подходящего локального реестра. Эти цифры относятся к заявленным в годовом отчёте совокупностям и отчётному периоду. Karrenberg назвал себя менеджером RIPE NCC. RIPE-099 давал более раннюю картину финансирования: RARE предоставлял формальную схему, а EARN, национальные члены RARE, Израиль и EUnet финансировали первый год работы. Эта картина и описание финансирования поставщиками в RIPE-113 относятся к разным моментам отчётности.
Аналогично, более 60 реестров поставщиков и 21 страновой реестр из RIPE-099 и 83 локальных реестра поставщиков из RIPE-113 используют разные периоды и совокупности.
Тот же отчёт давал подробную картину базы данных. В RIPE-113 говорилось, что база данных содержала информацию об IP-сетях, доменах DNS, политиках маршрутизации и соответствующих контактных лицах. Рост числа записей ускорился после того, как европейская система интернет-реестров стала полностью работоспособной в сентябре 1992 года, по терминологии руководства. В течение 1993 года NCC полностью перепроектировал и заново реализовал процесс обновления, сделав его полностью автоматическим почти для всех обновлений, и обработал 157 004 обновления.
Хранилище документов содержало документы RIPE и связанную информацию и было доступно через классические интернет-сервисы, распространённые средства поиска ресурсов и публичные сети X.25. Таким образом, руководство сообщало и о большой нагрузке по обновлениям, и о нескольких путях доступа к документальным сервисам центра.
В RIPE-113 перечислялись три специальных проекта, выполнявшихся в NCC в рамках технической программы RARE в 1993 году. Руководство сообщило, что проекты European Route Server и Generic Internet Service Description завершились успешно. Среди их результатов был европейский сервер маршрутов, развёрнутый в GIX. Проект PRIDE — Policy-Based Routing Implementation and Deployment in Europe — стартовал, создал хорошо наполненный европейский реестр маршрутизации и выпустил первый набор инструментов, использующих информацию из этого реестра; проект планировалось продолжить в 1994 году.
В годовом отчёте говорилось, что заинтересованные стороны финансировали все специальные проекты отдельно от основных услуг NCC. Его изложение прослеживает последовательность от решения RIPE о координации в сентябре 1992 года до развёртывания в GIX и реестра маршрутизации PRIDE.
Таблица расходов в RIPE-113 была выражена в kECU. В ней сообщалось об общем бюджете на 1993 год в размере 216 при фактических расходах 181; персонал — 140 против 133; вычислительное оборудование — 20 против 15; командировки — 25 против 9; аренда и услуги — 29 против 22; наём персонала — 2 против 2. Руководство объяснило меньшие расходы на командировки тем, что крупные встречи IETF и RIPE проходили в Амстердаме. Сообщалось, что штат оставался неизменным с начала деятельности в апреле 1992 года, и прогнозировалось, что рост нагрузки от расширения европейского интернета потребует большего числа сотрудников в 1994 году.
Таблица, объяснение по командировкам, заявление о штате и прогноз вместе составляли управленческий отчётный нарратив за 1993 год. Получившиеся расхождения составили 35 kECU в целом, 7 по персоналу, 5 по вычислительному оборудованию, 16 по командировкам, 7 по аренде и услугам и ноль по найму персонала. Это арифметические разности между бюджетными и фактическими строками годового отчёта.
Сохранившиеся материалы имеют концентрированный набор ограничений доказательной базы. В них нет ни исполненного соглашения о размещении или финансировании, распределяющего обязанности между RIPE, RARE, провайдерами и NCC, ни документов о найме, стоящих за заявленной численностью персонала. RIPE-113 — это управленческая отчётность, а не независимый аудит. Ни процедура класса B, ни более поздние обзоры не дают знаменателя для запросов и решений, наблюдаемой совокупности запросов или записи об отказах и апелляциях.
Документы закрепляют административные функции в отношении номерных ресурсов, не устанавливая права собственности на сети или адресное пространство. Европа определяет зону обслуживания, но документы не предоставляют территориальной юрисдикции или общего командования сетями. Ссылки на участие и согласие сообщества оставляют нерешённым вопрос о качестве и представительности этого согласия. Пересмотр программы может изменить работу офиса, однако в материалах не выявлено средства правовой защиты, способного изменить результат отдельного регистрационного решения.
Эти границы обозначают то, что заявление о более широких полномочиях должно было бы установить за пределами задокументированных сервисных и регистрационных функций.
Тем не менее RIPE-099 и RIPE-113 освещают две реальные формы подотчётности. Комиссия сравнивала ежеквартальные описания хода работ с RIPE-035, выявляла завершённые, застопорившиеся и добавленные направления и рекомендовала новый план. Руководство классифицировало расходы, подтверждало неизменность штата, описывало проекты и сообщало объёмы услуг. Пересмотр программы мог менять приоритеты; годовая отчётность могла представлять деятельность и расходы институциональным аудиториям. Индивидуальное средство правовой защиты служит другой цели, поскольку проверяет, может ли конкретный административный результат быть пересмотрен и изменён.
Ранние документы показывают первые два механизма в действии на институциональном уровне и оставляют третий как наблюдаемый вопрос для оценки любого последующего расширения полномочий.
Более поздний независимый контрпример подчёркивает различие между значимостью и суверенитетом. В анализе, подготовленном в 1996 году и опубликованном в 1997 году, Sharon Eisner Gillett и Mitchell Kapor сравнивали децентрализованную организацию с системами, в которых рутинные механизмы обрабатывают 99 % ежедневной активности, а множество органов власти занимаются исключительным одним процентом. Это соотношение было аналогией, а не измерением.
Они относили распределение адресов к исключительным координационным вопросам, различали провайдеров, региональные реестры и IANA и описывали RIPE NCC и APNIC как сервисные организации, управляемые и финансируемые консорциумами провайдеров. Их модель с несколькими властными центрами показывала, как значимая регистрация может сосуществовать с децентрализованным контролем маршрутизации. Она даёт более позднюю независимую проверку метафоры суверена: специализированные полномочия в одной точке реестра могут оставаться частью распределённого институционального порядка.
Вывод
Отчёты зафиксировали ограниченную делегированную деятельность в заявленных масштабах. NCC совмещал регулярную сервисную работу со значимыми функциями в рамках регистрации номеров, однако исполнительный контроль над сетями оставался за их организациями. Административная центральность создавала материальное влияние в пределах определённого канала; сама по себе она не наделяла суверенной властью.
Любое более широкое заявление о полномочиях в последующем требует нового документа. Наличие средств правовой защиты — один из наблюдаемых показателей для оценки такого заявления, а не юридическая предпосылка. Учредительные материалы поддерживают представление о подотчётном сервисном бюро с ограниченными регистрационными полномочиями, а не о контроле над собственностью, территориальной юрисдикции или общем командовании европейскими сетями.

