Краткое содержание
- Опубликованный в списке рассылки RPD 9 февраля 2016 года документ AFPUB-2016-V4-001-DRAFT-01 предлагал снизить максимум Фазы 1 с
/13, который авторы относили к действующей политике Soft Landing, до/15. Переход к Фазе 2 должен был происходить, когда незарезервированного пространства Final/8оставалось не более/11. - Проект сочетал этот меньший потолок с тестом на использование 90 %, обязательным наличием ресурсов IPv6 и отдельными каналами для критической инфраструктуры, новых LIR или конечных пользователей, а также непредвиденных будущих потребностей. Это были содержательные решения о практическом доступе к дефицитному административному пулу, а не просто техническая рутина.
- Его арифметика воспроизводилась лишь частично. D1 размещал инфраструктурный резерв
/16и резерв для новых участников/14в финальном/11, но описывал резерв на непредвиденные случаи/13как выделяемый из Final/8. В документе не было ни точных префиксов, ни карты, доказывающей, что все резервы не пересекаются, поэтому из него нельзя ответственно вывести единственный остаток общего пула. - AFRINIC могла законно вести уникальный реестр распределений и применять опубликованное правило запросов в рамках частных административных и договорных отношений. Публикация, дефицит и консультации не могли дать ей право собственности на интернет-адреса, суверенитет над Африкой, регуляторную юрисдикцию, а также полицейские, карательные, конфискационные или судебные полномочия.
Меньшие ворота в последний пул
Сделка начиналась с трёх архитектурных элементов. Во-первых, крупнейшее выделение или назначение в Фазе 1 снижалось с потолка/13, который, по словам авторов, действовал в рамках политики Soft Landing, до/15. Во-вторых, Фаза 1 завершалась, когда оставшееся незарезервированное пространство в Final/8достигало не более/11. В-третьих, не каждый адрес за этими воротами открывался для одинаковых притязаний: проект выделял отдельные резервы для критической интернет-инфраструктуры, заявителей без предыдущего пространства IPv4 от AFRINIC и непредвиденных будущих потребностей.
Эти решения важны, потому что потолок префикса — это правило распределения./13содержит 524 288 адресов IPv4, а/15— 131 072. Следовательно, только по ёмкости адресов предложенный максимум составлял четверть максимума, который D1 приписывал прежней политике. Это сравнение ничего не говорит о том, сколько организаций подадут заявки, сколько они получат, как быстро используют ресурсы и как долго продержится пул. Но оно показывает, что изменилось на уровне отдельного решения: ни один соответствующий запрос Фазы 1 не мог быть удовлетворён выдачей, равной прежнему заявленному потолку.
Это делало предложение перезагрузкой, а не косметической поправкой. Меньшие максимальные выдачи могут не дать одному запросу поглотить большую часть истощающегося пула и распределяют дефицит по большему числу моментов принятия решений. Однако то же правило может заставить растущую сеть возвращаться чаще, заново подавать доказательства и сильнее зависеть от последовательности, скорости и прозрачности администрирования реестра. Поэтому потолок распределял не только адреса, но и транзакционные издержки и подверженность процессу принятия решений. Справедливая оценка должна учитывать оба эффекта.
Порог был не менее значимым./11содержит 2 097 152 адреса. D1 не утверждал, что Фаза 2 начинается, когда весь Final/8достигает такого размера. Предложенная формулировка касалась момента, когда незарезервированного пространства Final/8оставалось не более/11. Резервы уже входили в определение ворот. Чтобы воспроизвести переход, оператору нужно было бы знать, какие блоки считаются зарезервированными, какие — незарезервированными и что показывал реестр в определённый момент. Одной длины префикса было недостаточно.
Проект также не ограничивал выдачи Фазы 1 одним явно названным блоком. Он предлагал, чтобы выделения или назначения могли производиться из Final/8или другого пространства IPv4, доступного AFRINIC, до достижения порога. Это делает необходимым консолидированный реестр пула. Если запросы могли удовлетворяться из нескольких источников запасов, администратор должен был показывать, какой запас изменился и как был рассчитан баланс незарезервированного Final/8. Иначе два наблюдателя могли соглашаться со словами/11, но расходиться в том, был ли преодолён порог.
Проект затрагивал и пограничный случай. Заявки, ещё находившиеся в обработке на момент достижения порога Фазы 2, должны были оцениваться по новой политике. Это положение могло повлиять на заявителя, не меняя дату подачи: применимое правило могло зависеть от состояния пула, пока запрос оставался в ожидании. D1 не называет такого заявителя и не доказывает фактического применения этой нормы. Однако как проектное решение оно делает часы перехода частью содержательных условий. Воспроизводимая система должна была бы фиксировать время подачи, время достижения порога, статус незавершённой работы и применённую версию правила.
Один проект, две документальные даты
Документальная хронология коротка, но точна. Панель сведений D1 указывает 4 февраля 2016 года как дату подачи. История изменений проекта и архивные записи предложений AFRINIC указывают 9 февраля 2016 года как дату публикации версии 1 в списке рассылки RPD. Эти даты описывают разные действия. Подача может предшествовать публичному размещению, и запись не устанавливает точное время или канал более раннего действия.
Институциональным событием, рассматриваемым здесь, является публикация AFPUB-2016-V4-001-DRAFT-01 9 февраля. Официальная страница обозначала его как версию 1.0 в статусе «Обсуждается» и указывала, что он изменяет AFPUB-2010-v4-005, не отменяя ничего. Авторами были названы Omo Oaiya из WACREN, Joe Kimaili из Ubuntunet Alliance и Alain P. Aina из TRS. Опубликованные материалы не распределяют между ними отдельные аргументы или мотивы, поэтому их индивидуальные обоснования не следует додумывать.
«Обсуждается» — важное ограничение. Оно говорит нам, что D1 был предложением, вынесенным на процесс обсуждения, а не записью о действующей системе выдачи. Сохранившиеся материалы подтверждают факт публикации и содержание предложения. Они не устанавливают его последующего принятия. Они не могут сказать нам, что какой-либо заявитель получил, не получил, с задержкой получил или был лишён адресного блока по этим пунктам. Поэтому анализ должен проверять предложенную архитектуру на её собственных условиях, а не переносить задним числом более поздние результаты в первый проект.
Базовая линия требует той же дисциплины. D1 указывал, что Совет AFRINIC ратифицировал действующую политику Soft Landing 11 ноября 2011 года. Он характеризовал эту политику как имеющую две фазы исчерпания: максимум Фазы 1/13; максимум Фазы 2/22и минимум/24; отсутствие различий между существующими и новыми LIR или конечными пользователями; и отсутствие условия о внедрении IPv6. Это изложение авторов тех условий, которые они хотели изменить. Оно полезно, поскольку проект выстраивал каждое вмешательство относительно него, но не заменяет независимую реконструкцию или полную редакцию инструмента 2011 года.
Относительно этой заявленной базовой линии D1 предлагал четыре изменения. Он снижал максимум Фазы 1. Он требовал, чтобы заявитель на IPv4 в период исчерпания имел ресурсы IPv6, запросил их одновременно или получил от вышестоящего провайдера. Он создавал именованные резервы для критической инфраструктуры, новых участников и будущей неопределённости. И он убирал явный минимальный размер выделения. Вместе эти меры меняли размер, доказательства, классификацию и внутреннее деление пула.
Четыре изменения были связаны, но не взаимозаменяемы. Меньший максимум ограничивал крупнейшую единицу, доступную при одном решении. Условия использования и IPv6 определяли, что должен показать заявитель. Резервы определяли, какие запросы могли получить доступ к конкретным сегментам. Удаление явного минимума давало правилу больше свободы на нижнем конце. Опубликованная политика распределения могла закрепить все четыре положения и всё равно не работать операционно, если реестр не раскрывал состояние пула, правила измерения и записи решений, связывающие их.
Дефицит делал правило важным, но не суверенным
Практические доводы в пользу нормирования понять несложно. Конечный пул порождает конфликт между текущим масштабом и будущим доступом. Более крупный блок сейчас может сократить повторные административные процедуры, но лишает возможностей будущих заявителей. Более мелкие блоки могут сохранить эти возможности, но увеличивают число взаимодействий и могут налагать издержки на сети, которые продолжают расти. Резервирование пространства защищает выбранные будущие запросы, но неизбежно изымает это пространство из общего спроса. D1 встроил эти компромиссы в предлагаемую последовательность распределения.
Чего дефицит не мог сделать, так это расширить характер института, управляющего этой последовательностью. AFRINIC была частным техническим реестром и координатором. Её полезная функция заключалась в том, чтобы поддерживать записи о номерных ресурсах уникальными, точными и операционно пригодными и применять известный процесс запросов к запасам, которыми она управляла. Эта функция может поддерживать договорно ограниченное правило нормирования. Она не делает реестр собственником адресов, правительством для региона обслуживания, регулятором сетей или трибуналом по вопросам поведения.
Это различие не является абстрактным возражением против координации. Именно оно делает координацию надёжной. Когда роль реестра узка и ясна, оператор знает, какие доказательства относятся к запросу ресурсов и какие последствия отражаются в реестре. Когда административные условия раздуваются до публичной власти, последствия становится труднее ограничить. Спор о доказательствах использования может начать звучать как неповиновение; условие, привязанное к частной услуге, может начать звучать как территориальный закон; предпочтение, высказанное в списке рассылки, — как демократический мандат.
Ни одно из этих превращений не следует из необходимости нормировать дефицитный пул.
Поэтому D1 следует читать одновременно в двух регистрах. В первом это была серьёзная попытка определить, кто мог получить доступ к какой части оставшихся запасов, через какие доказательственные ворота и в каких максимальных единицах. Во втором каждое такое решение оставалось актом частного администрирования. Качество предложения зависело от того, можно ли было воспроизвести и исправить его правило, не делая вид, что реестр создаёт право собственности или суверенитет. Это высокий стандарт, но и практичный.
Источники
- https://afrinic.net/backup-policy-list
- https://afrinic.net/policy/2016-v4-001
- https://afrinic.net/policy/2016-v4-001-d1
- https://heng.lu/on-when-the-bookkeeper-auditions-for-olympus/
- https://heng.lu/why-registries-must-never-become-enforcers/
- https://heng.lu/why-rirs-do-not-have-authority-and-why-community-sovereignty-breaks-the-system/
- https://larus.net/blog/how-rir-governance-decisions-can-quietly-break-your-infrastructure/
- https://nrs.help/what-is-afrinic/
- https://web.archive.org/web/20220602064123id_/https://www.afrinic.net/policy/2016-v4-001-d1
- https://web.archive.org/web/20220602064930id_/https://www.afrinic.net/policy/2016-v4-001
- https://web.archive.org/web/20220602120506id_/https://afrinic.net/backup-policy-list
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
