Jasdip, Tom, Jasdip, yes. rdap-base-down and rdap-base-up is better than a single rdap-base: it makes the direction explicit at the point of use and leaves RFC 9910's rdap-up exactly as it is. I will adopt that split.
Tom, good to be back in this with you, and thank you for the discoverability point. That is the heart of the draft, so I am glad it lands. On the authority boundary I think we are talking past each other, and that is my fault for not scoping it sharply. Your examples are all inside the registry system: an RIR serving its own direct delegations alongside members' records, or an RIR mirroring an NIR and returning the most-specific it holds. I agree completely that there is no boundary to expose there and no client change is warranted. An RIR delegates to an NIR, the NIR decides whether to expose user-space detail or not, and either way the answer is still served by a registry the bootstrap already points to. The RIR boundary stays the RIR boundary, and RFC 9224 longest-match does exactly the right thing. The draft is not about that case. It is about the resource whose subordinate detail is held by neither the RIR nor an NIR, but by the holder, on the holder's own RDAP server, which is not in the IANA bootstrap and cannot be reached by longest-match at all. There is no most-specific record for the client to land on, because the registry does not hold one, by design. That is a genuine crossing out of the registry system, not a more-specific lookup within it, and it is the only case this draft speaks to. Which is also why it is backwards-compatible in the way your concern asks for. Because these holder servers are off-bootstrap, nothing about existing most-specific expectations against RIR or NIR data changes. A client that ignores rdap-base-down is exactly as well off as it is today. The link is purely additive: it is the one thing that lets a client discover, and cross into, a service the bootstrap can never point it to. On structure: if the chairs would rather this live as a separate INR-specific document defining rdap-base-down/up and the no-redirect flag, rather than as a section in the referrals draft, I have no objection. That keeps the INR semantics from colliding with the domain-name use of the relation you flagged. The substance is the same either way, and I am happy to take it wherever limits confusion. Kaveh On Mon, Jul 13, 2026 01:18 AM, Tom Harrison <[email protected]> wrote: > Hi Kaveh, Andy, > > On Fri, Jul 10, 2026 at 07:28:36AM +0100, Kaveh Ranjbar wrote: > > It has been a long time. > > It has, hope you are keeping well. > > > First a correction, because you are right and I was wrong to lean on > > that example. Without -L, curl shows you the redirect body, so a > > motivated operator with nothing but curl can indeed see the > > registry's content. I took Andy's point and pushed it further than > > it deserved. What survives is narrower: clients that delegate > > redirect handling to their HTTP library, which is most of them, > > never see the body carried in the 3xx. That is a real limitation of > > redirect-with-content, but it is not the argument I made. > > Right, but just to avoid any doubt, while most libraries will handle > redirects automatically, it's common enough for there to be an option > for disabling that behaviour. See e.g. allow_redirects at > https://requests.readthedocs.io/en/latest/api/, and > > https://download.java.net/java/early_access/loom/docs/api/java.net.http/java/net/http/HttpClient.html#followRedirects() > . > That in turn supports clients retrieving the chain of responses in the > redirect_with_content scenario. (Though Andy has a point regarding > the inability to access redirect bodies in the context of a > conventional browser.) > > > Now the substance, because I think we are solving two different > > problems and the thread has been treating them as one. > > > > Your proposal concerns how the answer is transported: return the > > object, or redirect to the server that holds it. This draft concerns > > how a client learns that a subordinate service exists at all. Those > > are separable, and I do not think they compete. > > > > Take the RIR case, which is the one you scoped your argument to. The > > premise here is that the registry does not hold the per-subordinate > > detail. Sub-allocation records are kept out of the RIR database on > > purpose, and the aggregation conventions exist precisely to keep > > them out. So when a client asks for a more-specific and the registry > > applies the most-specific-entry rule you cite, the most specific > > object the registry has is the covering allocation. It cannot return > > the subordinate object, because the subordinate object is not there. > > > > Which means a registry that wants to redirect must first be told, by > > the holder, where to redirect to. That is the same new piece of > > holder-designated configuration that "rdap-base" carries. Both > > designs require the registry to hold exactly the same datum. The > > only difference is whether it is visible to the client, or consumed > > silently to produce a 3xx. > > > > That difference matters in two ways. > > > > Discoverability. If the registry only redirects, a client can never > > learn that a delegation exists without guessing a subordinate query > > and seeing where it lands. It cannot ask "what is delegated below > > this allocation, and to whom". With the link present on the covering > > object, the answer is one lookup away, and a client that ignores the > > link is exactly as well off as it is today. > > I think this is a fair point. > > > Provenance. Under an automatic redirect, a client that did nothing > > new issues a query to the RIR and receives a document served by a > > third party. Nothing in that client's model tells it that it > > crossed an authority boundary. Under a link relation the boundary is > > explicit: the registry's own record answers the registry's query, > > and stepping across to holder-asserted data is a decision the client > > makes. For registration data used in abuse handling and by law > > enforcement, I would rather that boundary were visible than smooth. > > I don't think this is a good idea. In addition to the earlier > comments about RDAP's core standards being primarily about > (automatically) finding the most-specific available resource in this > context, most (all?) RIRs already host their own records (e.g. direct > delegations to members) alongside member records (e.g. delegations > from members to their own customers) within the same RDAP server. I > think you are saying that between these two sets of records, there is > an "authority boundary". Yet at least as far as I can remember, the > fact that the most-specific record is returned in this case has not > been raised as an issue by our users. (Also relevant is that there > was a period of time at APNIC where for those NIRs with their own > Whois servers we returned only the APNIC direct delegation > information, and we had a number of questions about why we weren't > instead returning the more-specific information per our mirror of the > relevant NIR's data.) > > > On bootstrap alignment. The delegation we are describing is not in > > the IANA bootstrap and realistically will not be. The bootstrap's > > more-specific entries are populated from RIR data, not by arbitrary > > holders, so a holder running RDAP for a sub-allocation inside its > > own allocation will not appear there. The behaviour you want, > > sending the client straight to the most specific server, therefore > > cannot be derived from the bootstrap in this case. It can only be > > imitated by the registry, out of holder-supplied configuration. That > > is the line I am trying to draw between a relation that points > > outward to a service the bootstrap can produce, and one that points > > to a service it cannot. > > To clarify, I wasn't trying to say that an account holder delegation > such as the one in the use case here would appear in the bootstrap > directly. Possibly a better way of describing this consideration is > that if RDAP were premised on sending the client to an "authoritative" > server only (along the lines of the "authority boundary" concept), > then there would have been no need to support the handling of > more-specific records in the bootstrap. From RFC 9224: > > For IP address space, the authoritative registration data service > is found by doing a longest match of the target address with the > values of the arrays in the corresponding RDAP Bootstrap Service > Registry for Address Space. The longest match is done the same > way as in packet forwarding: the addresses are converted in binary > form and then the binary strings are compared to find the longest > match up to the specified prefix length. The values contained in > the second element of the array are the base RDAP URLs as > described in [RFC9082]. *The longest match method enables > covering prefixes of a larger address space pointing to one base > RDAP URL while more specific prefixes within the covering prefix > are being served by another base RDAP URL.* > > (More generally on this point, there is no guarantee that the RDAP > bootstrap file will point clients only to RIRs.) > > > On consistency, which I think is your strongest point, and I concede > > it is real. A holder that registers subordinate objects in the > > registry and a holder that runs its own server do produce > > differently shaped responses to the same query. But the shape is > > tracking something true. In the first case the registry is > > authoritative for those objects. In the second it is not. Smoothing > > that away with a transparent redirect makes the two look identical > > at exactly the moment they are most different. > > See earlier comments in this respect. > > > And on cost. A flag that disables redirects, plus a subordinate > > server that emits an "up" link carrying that flag, is a new query > > parameter, a new extension identifier, and coordinated behaviour at > > both ends. That may well be the right design, but it is not free of > > client updates either. If we are comparing, let us compare like with > > like: both proposals ask a client to learn something new in order to > > get the whole picture, and both degrade to today's behaviour for a > > client that learns nothing. > > The proposal in the draft requires all clients to update their > handling of IP address queries in order to maintain existing > expectations around response handling (i.e. that the most-specific > available record will be returned). My proposal per the previous mail > requires clients who are interested in provenance and who cannot make > use of redirect_with_content to go to extra work to handle that, but > those clients were going to have to be updated anyway. IMHO, the aim > with any work in this space should be to maximise consistency and > backwards compatibility for clients so far as is possible, and simply > stating that "both proposals ask a client to learn something new" > glosses over the relative importance of the two use cases here and the > backwards-compatibility implications of the draft's proposal. > > > So here is where I think this connects, and I would value your read. > > > > This draft was written as input to draft-ietf-regext-rdap-referrals, > > and I would rather its substance were merged there than progressed > > on its own. That work already defines an explicit redirect > > mechanism. If "rdap-base" is the advertisement and the referrals > > draft is the transport, then a registry implementing explicit > > redirects can do both: carry the link on the covering object, and > > redirect on the subordinate query, with your disable-redirect flag > > available to a client that wants the parent's record as well. The > > numbers case then needs nothing beyond that, and the names case, > > where there is no covering object and no most-specific rule to lean > > on, still has a way to express the delegation. > > > > Would that split work for you? If so I will make it explicit in -01, > > which I will post once the submission tool reopens after Vienna, and > > I will drop any text that reads as though the link relation were an > > alternative to redirects rather than a companion to them. > > Although this is an improvement, I still don't think it's a good idea. > The key consideration with draft-ietf-regext-rdap-referrals is that > it's about queries for resources *related to* an answer response, > rather than the answer response itself. As far as I can tell, the > proposal above involves updating that document to say "an rdap-base > URL may exist in the response, and can be queried to find answers for > subordinate queries, but if the query is for INRs, servers MUST > perform the relevant redirection query automatically". I think most > users would be confused as to why INR RDAP servers were treated > differently from domain name RDAP servers in this respect, and that > the necessity of text like that points towards the rdap-base > relationship being sufficiently different in the two contexts that > using the same link relation name for both may be confusing. > > Having said that, given your point about discoverability earlier, > possibly a separate INR-specific draft that defines the rdap-base > relation and the no-redirect flag, while still mandating redirections > on the part of the server, would address the specific use case here > while limiting the potential for user confusion. > > -Tom >
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
