Для связи ISP/LIR у ARIN нужен журнал критериев

Кратко

Проект политики ARIN-2025-1 утверждает, что все Internet Service Providers являются Local Internet Registries, хотя не каждый LIR является ISP. Предлагаемое определение LIR требует функции Internet Registry, членства в RIR, получения выделений и распределения номеров клиентам, конечным пользователям и инфраструктуре.
Предлагаемое определение ISP требует лишь оказания интернет-услуг внешним сторонам. Связность, веб-сервисы, colocation, выделенные серверы, VPS и VPN сами по себе не подтверждают реестровые признаки, необходимые для заявленного отношения множеств.
Исправление не требует, чтобы ARIN проектировал бизнес заявителя. Достаточно связать каждую классификацию с версией словаря, жизненным циклом ресурса, функцией делегирования и применимой нормой, а каждую значимую замену ISP на LIR занести в защищённую карту миграции.

Две карточки, которые не складываются одна в другую

На примере обычного оператора доступа ISP и LIR выглядят как два названия одной организации. Компания продаёт подключение, напрямую получает блок, передаёт части блока клиентам и регистрирует распределение. Рыночная роль и функция в цепочке номерных ресурсов совпадают.

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

Независимый трекер NOG Alliance указывает ARIN-2025-1 как Draft Policy и датирует последнее изменение 13 августа 2026 года. Проект начинается с реального недостатка: LIR определён, а отдельного определения ISP нет. Затем постановка проблемы устанавливает точное отношение: по смыслу и обычной деловой практике все ISPs являются LIRs, но не все LIRs являются ISPs.

Это не просто наблюдение о частом пересечении. Любая организация, удовлетворяющая определению ISP, должна тем самым удовлетворять определению LIR. Знакомые телекоммуникационные компании в пересечении множеств ничего не доказывают о пограничных случаях.

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

LIR описывает цепочку номерного ресурса

Текст, сохранённый в независимом архиве PPML за март 2026 года, задаёт LIR несколькими звеньями. Это Internet Registry и член RIR, который получает от него allocations интернет-номеров и выделяет их клиентам, конечным пользователям и инфраструктуре.

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

Та же архивная рассылка показывает масштаб миграции: заголовки и операционные нормы переходят от ISP к LIR, а терминологическая норма считает ISP подмножеством LIR. Это не примечание к глоссарию, а перенос роли через allocation, reassignment, утилизацию и обязанности перед downstream-клиентом.

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

ISP описывает рыночную деятельность

Предложенное определение ISP построено на другой оси. Internet Service Provider — организация, оказывающая интернет-услуги другим организациям, клиентам или физическим лицам, не являющимся её сотрудниками. В перечень входят связность, веб-сервисы, colocation, выделенные серверы, виртуальные частные серверы и виртуальные частные сети.

В этой фразе нет требования быть Internet Registry. Нет требования получать allocation напрямую от RIR, иметь конкретное членство, перераспределять или переназначать ресурсы клиентам.

Двусмысленность видна в независимо сохранённом обмене PPML о руководстве для заявителей. Участник цитирует краткую формулу «LIR — это ISP» и одновременно определение, где LIRs лишь «обычно» являются ISPs, а затем спрашивает, совпадают ли множества, вложены ли они или выбор опционален для держателей direct allocation. Архив подтверждает поставленный вопрос, но не решение по конкретной заявке.

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

Есть несколько последовательных вариантов. ISP можно снова прямо определить как разновидность LIR. Услуговое определение можно сузить до провайдера, выполняющего квалифицирующую функцию распределения. Множества можно назвать пересекающимися, но не вложенными. Наконец, ISP можно убрать из нормативных условий, привязав путь запроса прямо к использованию и делегированию ресурса.

Сообщество должно выбрать модель. Читатель не должен выбирать её вместо сообщества.

Недостающее следствие

Разрыв удобно показать пятью аналитическими предикатами. Это не терминология ARIN и не предложение схемы данных.

Пусть IR(x) означает, что организация x распределяет номерные ресурсы и регистрирует такое распределение. M(x) означает указанное отношение членства в RIR, A(x) — получение allocation от этого RIR, D(x) — нисходящее выделение или делегирование, а S(x) — предоставление внешней стороне хотя бы одной перечисленной услуги.

Тогда предложенное определение допускает запись LIR(x) = IR(x) ∧ M(x) ∧ A(x) ∧ D(x). Для ISP получается ISP(x) = S(x).

Чтобы каждый ISP был LIR, необходим переход S(x) → IR(x) ∧ M(x) ∧ A(x) ∧ D(x). В опубликованном тексте его нет.

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

Синтетический провайдер на границе

Представим вымышленную компанию, продающую управляемый веб-сервис и VPN-доступ. Все адреса она получает от вышестоящего провайдера. Прямого allocation от RIR у неё нет, и она не выступает Internet Registry, который распределяет и регистрирует номерные ресурсы для клиентов.

Это искусственный логический тест, а не названный оператор, реальный запрос ARIN или описание действий персонала.

Компания выполняет опубликованный предикат ISP: она оказывает внешним лицам две услуги из списка. При этом она не выполняет как минимум условия прямого выделения и нисходящего распределения из определения LIR. В зависимости от смысла member of an RIR может отсутствовать и этот признак.

На рынке такую компанию разумно называть ISP. Её разумно направить и к руководству для ISP: там можно определить, оправдывают ли планируемые клиентские назначения прямое allocation. Однако направление к инструкции не создаёт уже существующего выделения и не превращает использование upstream-адресов в реестровую функцию.

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

Функция ресурса и коммерческий ярлык лежат на разных осях

RFC 7020 описывает систему номерных реестров как иерархию, где реестры allocates ресурсы клиентам, а LIRs обычно являются ISPs. «Обычно» описывает повторяющееся отношение; оно не тождественно роли реестра и каждой компании, продающей интернет-услугу.

На ресурсной оси находятся заявитель, держатель direct allocation, downstream-распределитель, end user и пользователь upstream-пространства. На сервисной оси — связность, хостинг, colocation и VPN. Классификация может читать обе, но должна назвать сочетание, запускающее нормативную роль.

Альтернативное определение из обсуждения PPML делало выбор явным: связывало LIR с системой RFC 7020, а важным признаком ISP называло потребление и обоснование номерных ресурсов для клиентов. Это предложение участника, а не принятый текст. Его диагностическая ценность в том, что при известной ресурсной функции мост помещается в одно предложение.

Если member of an RIR останется условием LIR, нужно назвать точное отношение и момент проверки. Коммерческая услуга не создаёт такой статус по смыслу, а ресурсное отношение нельзя выводить из рыночного названия.

Административная история сохраняла разные роли

RFC 2901, информационное руководство 2000 года, направляло организации к разным материалам в зависимости от получения и использования адресов. Это история, а не текущее требование ARIN. Но она сохраняет аналитический факт: ISP давно служит ярлыком пути заявки, LIR относится к реестровой иерархии.

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

Публичная дискуссия уже нашла слабый мост

Архивная дискуссия была не только стилистической. Ответ от марта 2026 года согласился, что предложенная фраза LIR грамматически незавершена, и поставил под сомнение at a local level, поскольку некоторые LIRs работают за пределами одного региона RIR. В том же сообщении воспроизведено сервисное определение ISP.

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

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

Минимальная карта роли и предиката

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

Для начальной карты и манифеста миграции достаточно шестнадцати полей.

Идентичность организации и Org ID. Зафиксировать юридический и реестровый субъект, использованный при классификации, вместе с соответствующей временной границей.
Идентичность запроса или решения. Дать делу стабильный ключ, время подачи и явные связи с редакциями или заменяющими запросами.
Версия словаря и дата действия. Назвать точный NRPM, проект или реализацию, по которым толковались ISP, LIR, IR, end user и делегирование.
Цель классификации. Указать политическое решение, ради которого проверяется роль; один универсальный бизнес-ярлык не должен управлять несвязанными действиями.
Предикат коммерческой услуги. Зафиксировать ограниченный класс внешней услуги, не затягивая в политику весь закрытый каталог продуктов.
Предикат Internet Registry. Указать, распределяет ли организация номерные ресурсы и регистрирует ли распределение, со ссылкой на защищённое доказательство.
Состояние прямого allocation. Различать отсутствие, запрос, одобрение, выдачу, возврат, отзыв и замену, связывая состояние с событием ресурса.
Функция нисходящего делегирования. Записать reallocation или reassignment, класс получателя и управляющую норму.
Внутреннее инфраструктурное использование. Отделить ограниченное собственное использование от распределения клиентам.
Состояние членства. Записать non-member applicant, Service, General, General in Good Standing либо Trustee по соответствующему правилу; не выводить право голоса из ресурсной роли.
Состояние соглашения и полномочий. Связать покрытие RSA или LRSA и полномочие представителя с защищёнными доказательствами, не публикуя документы о полномочиях.
Применимый политический путь. Назвать нормы, тесты квалификации и исключения, выбранные проверенной ресурсной функцией.
Карта вхождений терминов. Для каждого значимого употребления хранить старый и новый термин, раздел, поверхность и ограниченный код смыслового эффекта.
Привязка реализации. Связать смысл политики с совпадающими версиями публичного руководства, внутренней инструкции, обучения, поля заявки и тестового вектора.
Результат, объяснение и исправление. Сохранить решающие предикаты, исход, путь пересмотра, последующий переход роли и историю коррекции.
Агрегированная проекция с защитой приватности. Публиковать количества путей, изменений классификации, расхождений версий формы и исправлений без имён заявителей и продуктовых секретов.

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

Общий слой знает функцию, но не проектирует компанию

Minimum Initial Specification проводит полезную границу. Общая координация должна быть строгой в отношении детерминированных фактов, необходимых для уникальности, совместимости, доказуемости, безопасности и защиты. Коммерческие договорённости, институциональные амбиции и дискреционные предпочтения остаются локальными.

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

Состав продукта остаётся локальным. Реестру не нужно решать, является ли веб-хостинг главным бизнесом, продаётся ли VPN вместе с доступом, какой гипервизор обслуживает VPS, какой маршрутизатор стоит на площадке colocation или как университет устроил факультеты. Эти сведения нужны лишь тогда, когда их требует названный политический предикат.

Минимальность не означает расплывчатость. Определение, претендующее на меньшую власть над компанией, должно быть особенно точным в той малой части, которую оно делает общей.

Источники

Чего доказательства не показывают

Ни один источник пакета не называет реальную организацию, которую ARIN направила бы по неверному пути из-за терминов ISP и LIR. Нет измерений дополнительных обращений, задержки, отказов или изменения размера allocation. Не раскрыты текущие внутренние поля заявки, обучение персонала и полная логика классификации.

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

Они также не предсказывают исход политики. Независимый трекер классифицирует ARIN-2025-1 как Draft Policy. Новая версия может вернуть прямую связь, удалить утверждение о подмножестве, оставить только LIR или перестроить определения. Оценка нового объекта будет новым фактом, а не подтверждением сегодняшнего вывода.