Кратко

  • Первая версия prop-173 создаст, если будет принята, отдельные условия для обычных запросов и покажет их в WHOIS, RDAP и веб-интерфейсах. Сейчас документ только опубликован в списке Policy SIG для обсуждения и не является принятой политикой.
  • Центральный текст получит номер версии, дату вступления в силу, историю и архив. Но отдельному ответу достаточно ссылки на нынешнюю политику: в нём не будет номера применимой редакции, даты её действия или хеша документа.

Обычный запрос не равен выгрузке

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

На официальной странице prop-173 сказано, что версия 1 направлена в рассылку Policy SIG 17 августа 2026 года. Текущий статус — “Published to Mailing List”. В проверенной записи нет оценки влияния Секретариата, решения о консенсусе, принятия или уведомления о внедрении. Поэтому проект только установит правила при успешном прохождении процесса; он не доказывает их нынешнее применение.

Текст версии 1 охватывает людей и системы, обращающиеся к авторитетным данным APNIC через WHOIS, RDAP, веб-поиск и равнозначные API. Для зеркальных или перенаправленных данных сохраняются условия авторитетного реестра-источника. Высокие объёмы, значимые извлечения, зеркала и замещающие базы остаются в отдельном порядке массового доступа.

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

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

Адрес остаётся тем же, текст — нет

Раздел об уведомлении заставит каждую поверхность сообщать об условиях. WHOIS будет говорить, что данные справочника регулируются политикой, а запрос или использование означает согласие. RDAP получит уведомление о политике, ссылку с отношением terms-of-service, оговорку об интеллектуальной собственности и текущий URL. Веб-интерфейс покажет ту же связь при отправке запроса.

URL должен быть стабильным, поддерживаемым, работать по HTTPS и не зависеть от перенаправления. Отдельно проект требует от центральной политики номер версии, дату вступления в силу, журнал изменений и архив старых редакций. APNIC будет заранее публично сообщать о поправках, а некоторые существенные изменения вернёт на консультацию сообщества.

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

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

Архив способен помочь, если у клиента есть надёжная отметка времени, а границы действия редакций указаны точно. Журнал программы, сохранённый HTTP-заголовок или запись трафика могут дать такую отметку. Однако это внешнее доказательство. Сам ответ не несёт ключа, соединяющего его с текстом, который сервис предъявлял при выдаче.

Текущий пример показывает форму, а не внедрение

Сохранённый для анализа ответ APNIC RDAP на 1.1.1.1 уже содержит уведомление “Terms and Conditions” и ссылку terms-of-service. Там же указаны источник данных и путь сообщения о неточности. Версии политики, даты её действия и хеша документа нет.

Один ответ не доказывает внедрение prop-173 и не описывает WHOIS, веб или все узлы RDAP. Он подтверждает только структурную возможность: реальный результат указывает место условий, но не редакцию, которая находилась в этом месте при запросе.

RFC 9083 определяет уведомления RDAP как сведения о сервисе или обо всём ответе. Описание обязательно, ссылки возможны. Значит, техническое место для ссылки и короткой идентичности версии уже существует. Стандарт не создаёт специальную квитанцию политики APNIC автоматически. Соответствие протоколу и временная подотчётность — разные проверки.

Версия условий не заменяет происхождение прав

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

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

Заявление APNIC о конфиденциальности помещает Whois и RDAP в контекст обработки регистрационной и контактной информации. Точная версия не делает любое использование законным и не подтверждает силу каждого пункта. Она лишь не позволяет незаметно заменить документ при последующей проверке.

Проект ещё можно дополнить

Процесс разработки политик APNIC строится на открытом обсуждении и консенсусе. Первая публикация в рассылке — материал для проверки, а не финальная команда. Единый идентификатор версии можно добавить в комментарий WHOIS и уведомление RDAP без отказа от защиты, разделения доступа и процедуры пересмотра.

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

Источники

Использованы страница prop-173, текст первой версии, соглашение о массовом Whois, сохранённый ответ RDAP, заявление о конфиденциальности, процесс разработки политик и RFC 9083. Они подтверждают требования проекта и форму одного ответа, а не спор по внедрённой политике.