Summary

  • An individual Internet-Draft dated 29 October proposes six RDAP lookup paths for Internet Routing Registry data; support for three set types and route-policy fields stays optional.
  • RIPE NCC’s live RDAP help response does not advertise irr0, the draft’s extension identifier. Operators still need a server-by-server coverage receipt before they can retire a Whois path.

The exit sign has an asterisk

At RIPE 93, an operator called support for RIR routing-registry objects the last feature they were waiting for before leaving Whois behind. That is a large expectation to hang on six new path names.

On 29 October, Datatracker published draft-aggarwal-regext-rdap-irr-00. Mahesh Aggarwal of RIPE NCC and Jasdip Singh of ARIN are among its four authors. The document sketches a way to retrieve Internet Routing Registry (IRR) data through RDAP: structured JSON over HTTPS, alongside the registration data RDAP already serves.

The proposal is concrete. It names six lookup paths: irr0_route, irr0_routeSet, irr0_autnumSet, irr0_rtrSet, irr0_peeringSet and irr0_filterSet. A route lookup pairs a prefix with an originating ASN. Set objects can expose membership as arrays. An aut-num response may carry ordered import and export policies, including multi-protocol and import-via or export-via forms.

The catch appears in the same draft. Support for peering-set, router-set and filter-set is optional at an implementer’s discretion. The irr0_policies member is optional too. A client can therefore speak the new vocabulary and still find that a server has no answer for one of the objects its routing workflow uses. Six paths on paper do not create six working doors.

That distinction matters because an IRR is not just a lookup screen. ARIN says its IRR is separate from its public Whois information. Resource holders submit RPSL objects; other IRRs retrieve them for network routing decisions. ARIN offers NRTM, downloadable files and Whois on port 43. Its description of the ARIN NRTM stream calls its objects “authorized” and explains the registry and agreement checks behind that label. Those are operational details a migration must preserve, not just strings to wrap in JSON.

RIPE Database documentation currently lists four RDAP types: autnum, domain, ip and entity. Its live /help response advertises several extensions but does not include irr0. That is one server’s state, not a verdict on other RIRs. It is enough to show the distance between a draft and an implemented endpoint.

The status page is equally plain. Datatracker calls the new document an individual Internet-Draft, says it is not endorsed by the IETF and has no formal standing in the standards process. Its IESG state is I-D Exists. The proposal’s next test is not another appealing diagram. It is implementation evidence.

JSON is the easy half

The draft does useful work: it maps RPSL route and set concepts into RDAP-shaped objects, gives clients stable path names and carries policy strings in ordered fields. That can spare software from juggling a separate HTTPS and JSON parser for each source. The conversion still has to preserve the object’s meaning. A route-policy string is a declaration; it is not a BGP observation. A returned route object does not prove that a network announces or accepts that route.

Optionality also pushes a decision down to each server. An RIR can decide which set families and policy data it exposes. That flexibility makes implementation easier to stage, but it prevents an operator from treating irr0 as a universal completeness badge. The draft requires a supporting server to advertise irr0 in rdapConformance, including its help response. Clients can inspect that declaration; they still need a class-by-class test against the objects their own filters and automation consume.

The draft’s privacy section points to another implementation choice: these lookups can affect people represented in registry data. A common JSON envelope does not decide which contact details a server should expose. Each implementation still needs to make that boundary legible.

The migration scorecard should be boring and exact: Does the help response advertise irr0? Which of the six classes answer? Are membership and ordered policy values preserved? What happens when a class is absent? Do registration and last-change events survive? Can the operator compare the returned record with the existing RPSL object and mirror feed?

The draft supplies no deployed cross-RIR coverage matrix. A versioned matrix backed by queries against each participating service, with field-level comparisons to its existing RPSL output, would change the verdict.

An operator at RIPE 93 was right to ask peers to check the objects they actually use. That is where the work begins. “We have RDAP” answers the transport question. The exit from Whois waits for the record itself to arrive intact.

Sources