Summary

  • Kaveh Ranjbar proposed an opt-in route from RIPE NCC’s RDAP answer to a resource holder’s own service for more-specific network records. The proposal has not become RIPE policy.
  • Leo Vegoda raised the sharpest test in the room: a holder server could show the registry one answer and everyone else another. A working referral needs answer-integrity checks as well as an uptime check.

The record ends before the network does

Ranjbar knows both sides of this handoff. RIPE 93 describes him as a former RIPE NCC chief information officer who spent fifteen years at the registry, much of it around its database. He now runs Whisper Security and operates AS219419. On 29 October, he spoke as someone who has built registry services and now has to use them as a holder.

The meeting abstract sets out the gap. An RDAP client follows discovery to the most specific object RIPE NCC holds. A holder may keep fresher registration records for networks below that allocation on its own server. The RIPE answer offers no discoverable path to them. The choices then are thin records below the allocation or bulk-loaded objects that may age out of sync with the operator’s systems.

Ranjbar’s example is his holder-side RDAP service for 2a04:2a01::/32, associated in the abstract with AS219419. An example endpoint proves that a server can answer. It does not settle whether a registry should direct public queries there.

Four parts, one uncomfortable check

He proposed four opt-in pieces: a holder RDAP base URL on the covering registry object; a redirect for subordinate lookups; an additional discovery link; and rules for validation, continued testing and withdrawal if the service fails. The address in the registry record would become a signpost. The detailed answer would come from a party with more immediate knowledge of its own assignments.

That is an attractive division of labour until the signpost points at a selective witness. In the meeting transcript, Leo Vegoda said the delegated service must keep working. He also asked how to prevent it from giving RIPE NCC a legitimate response while supplying a misleading one to another requester. Ranjbar agreed the checks need discussion. A health probe that gets HTTP 200 would miss Vegoda’s problem entirely.

Ranjbar asked the room for support to request an impact analysis and make the idea a Database Working Group item. That is the recorded decision point; the transcript supplies no adoption vote. The missing document is a dated impact analysis specifying how the registry would compare answers from independent clients, how a bad referral would be withdrawn and what record a reader gets during the failure.

Sources: RIPE 93 session and abstract; RIPE 93 Database Working Group transcript.