Кратко

  • Tsungyi Yu в prop-163 предложил перенаправлять запросы RWhois о переданных ресурсах к ответственному RIR, затем к базам национальных регистров и данным о назначениях клиентам.
  • Секретариат APNIC указал, что RDAP уже перенаправляет запросы между RIR, а данные NIR и последующие назначения имеют каналы публикации. На APNIC 59 консенсуса не было; в сентябре 2025 года Yu отозвал предложение из-за недостатка откликов.

У номера может смениться владелец реестра, а табличка Whois останется прежней. В первом тексте prop-163 Yu описал ASN, переведённый из APNIC в другой RIR: поиск через IANA всё ещё мог указывать на старую базу. Он предложил сервер направлений, ведущий к новому RIR, национальному реестру и, возможно, к сведениям о дальнейшей выдаче клиентам. Одна строка запроса должна была вести к тому, кто действительно хранит ответ.

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

NIR с собственными базами Whois уже отправляли данные APNIC для публикации в рамках местных ограничений, а поле source показывало происхождение записи. Участники могли публиковать дальнейшие делегирования через MyAPNIC или API. Часть назначений разрешалось скрывать от публики, оставляя видимой лишь Секретариату. Дополнительная прозрачность могла показать связи с клиентами, которые политика разрешала держать закрытыми.

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

Официальная история отмечает отсутствие консенсуса в феврале 2025 года, возврат в рассылку в марте и отзыв 12 сентября из-за слабого отклика. После этого стоит начать с точного неудачного запроса: где он теряется, кто управляет следующим шагом и какие сведения нельзя показывать всем?