Что такое предательство принципа работающего кода в управлении RIR?

Критика Лу Хэна начинается там, где процедура, предназначенная для поддержки работающих сетей, становится источником власти над ними.

Представьте сеть, которая исправно обслуживает клиентов. Оборудование работает, соединения работают, другие сети могут до неё добраться. Затем организация, ведущая записи о её адресах, меняет условия, на которых она будет признавать эту сеть. Кабели остались на месте, но теперь оператору приходится защищать административную основу, на которую опираются другие.

Этот конфликт Лу Хэн называет предательством принципа работающего кода: институты ссылаются на традицию, созданную, чтобы помогать сетям работать, а затем используют её для оправдания власти над самими сетями. В заметке 61 его критика выходит за рамки вопроса о том, было ли собрание справедливым. Он спрашивает, почему собрание вообще должно обладать такой властью.

Что здесь означает «работающий код»?

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

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

Лу Хэн применяет это различие к региональным интернет-регистраторам, или RIR. Регистратор помогает координировать номерные ресурсы, чтобы сети могли отличать один ресурс от другого. Его полезность заключается в поддержке этой общей функции. По мнению Лу Хэна, такая функция не даёт институту неограниченной власти над теми, кто ею пользуется.

Переворот: сеть начинает служить процедуре

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

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

Переворот происходит, когда оператору приходится перестраивать работающий сервис под предпочтения института, а институт считает соблюдение своей процедуры достаточным ответом на последствия. Процесс продолжает функционировать. Меняется то, чьим интересам он служит.

Почему решение в базе данных может иметь значение за её пределами

Регистратор не передаёт каждый пакет. Изменить запись — не то же самое, что выключить все маршрутизаторы. Влияние возникает через зависимость: провайдеры, клиенты и другие системы обращаются к записям и связанным с ними подтверждениям, когда признают ресурс и решают, как с ним обращаться.

Так возникает цепочка между административным решением и услугой, которой пользуются люди. Последствия зависят от конкретной записи, задействованных технических систем и решений организаций, которые на них опираются.

Чтобы увидеть эту цепочку, проследите один адресный блок в деятельности компании. Кто поддерживает его регистрационные контакты? Кто публикует разрешения на его маршрутизацию? Какие сети передают его трафик? Какие клиенты встроили его адреса в собственные настройки? Разногласие на уровне ведения записей может потребовать работы по всей этой сети взаимоотношений.

Что даёт рассмотрение спора вокруг AFRINIC

В заметке 61 спор вокруг AFRINIC используется для развития конкретной критики: Лу Хэн утверждает, что узкая координирующая роль была расширена через трактовки регионального использования, институционального признания и условий передачи. Он также оспаривает защиту этого расширения со стороны системы регистраторов в целом.

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

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

Почему улучшения условий участия недостаточно

Более доступные собрания, более ясные объяснения и лучшие способы заявлять возражения могут улучшить процесс. Но сами по себе они не отвечают на вопрос о том, что институт вправе решать.

Поэтому критика Лу Хэна не сводится к тому, что консенсус должен учитывать больше участников. Она состоит в том, что координация должна оставаться ограниченной той работой, ради поддержки которой существует. Процедура не может сама выдать себе неограниченный мандат, объявив о согласии участников.

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

Предлагаемая альтернатива: сделать соответствие правилам независимо проверяемым

Заметка 65 развивает конструктивный ответ — приоритет работающего кода. Предлагаемый общий уровень содержит минимальные правила, необходимые для уникальности, подтверждения контроля, безопасности и совместимости. Участники должны иметь возможность проверять соблюдение этих правил локально, сверяясь с распределённым состоянием.

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

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

Зачем готовиться, пока сеть ещё работает?

Непрерывность нельзя организовать на ходу, просто сменив вывеску во время кризиса. Операторам и их контрагентам нужны пригодные для использования записи, способы их проверки и проверенное на практике понимание того, что сохранится при переходе.

Проверка для читателя проста: защищает ли правило то, что сетям действительно необходимо совместно, или сохраняет возможность администратора решать за них? Затем спросите, сможет ли полезная координация продолжаться, если этот администратор исчезнет.

Прочитайте заметку 61 с критическим разбором, заметку 65 с предлагаемым устройством системы и заметку 72 с изложением соответствующих прав. Вместе они ведут от анализа того, что пошло не так, к тому, что общий уровень действительно должен делать.