Return-Path: X-Original-To: regext@mail2.ietf.org Delivered-To: regext@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 16C1311B0D435 for ; Tue, 21 Jul 2026 00:00:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1784617251; bh=oWwGv7z2QQBQLtOBgZ65lniAlvIQ9iTXxndUn4YuwJI=; h=References:In-Reply-To:From:Date:Subject:To; b=gWaYXWEETPmJY0oq1GTnbNZBJZM9FSjHnRZxN3zs8ZgaGdOI3919K2q1HLGmK4F/S oTy+oD+R+hO9Aj2WbTzQHeqZBYKtao2V7aFLlTpHJtEY2aNQKGW3S7qOqHT+FGMs29 kP14YiRtyXSwK80hc22RO9Od5ia1Mi6n7I6+u1Aw= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=whisper.security Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7WAF1tL4dH4 for ; Tue, 21 Jul 2026 00:00:49 -0700 (PDT) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 05E4911B0D3C6 for ; Tue, 21 Jul 2026 00:00:32 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-69e28b554ceso9858386a12.0 for ; Tue, 21 Jul 2026 00:00:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1784617232; cv=none; d=google.com; s=arc-20260327; b=QXloV+BacuK+HGg2YWJJv4BPtQcuUDMscY5/YcSHeYMuVLFj2NfkDyf9h91zZTtbcA u0rAseRJ1gSG1b94KVezNm7rZT2JXHtG+jV6wBc5PfHE2PTMydx0bbdTsyOi4JuH06gL eNfPZ72ICoeaNhgTJR/Jq81r+skpj+2FXLmBSqbW8TxhXL9cZ5q04Hon80soyRaCsYiT HYu9l0Itqo85haEe4CNrlL4dA0o6vosv/NYn+8FZEvsI/xFXoQU8LTv7ZcSeDe9wdmJh NlnsgZUyqxeTgmUBXi276N2gFes5QHuHbH2hsOMmvG8flzZOm24Bue2yK3chBhEEwjoy 1H3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=oWwGv7z2QQBQLtOBgZ65lniAlvIQ9iTXxndUn4YuwJI=; fh=nKq6lwXFBEC6Xs+BoiFcCNh4Rcr/30VUM6Yh3gWbEhA=; b=QBdhjNd3ZY+lO9uNbUgzsusBDAiR8T9lKklYg5ltSH5bB2hLA4Yrx+Uhd7qW412Ljh JHA6MveU1soD8x6kR3WqbR6cgYIjpjx0CLvJ+QBRpRHWY9ZGfgYNOZVTvQEiv0R+FkWb Lqzt0oY65/tsxppVlOWpo7zmN9X9LzGI+9JdJuMjsaPWXDnEJtJ30RuTMo/eSkKcS5NP RGS1mDjOSd9iZ4fN0dpnxZwbFj/quypoIt2mId/3y53y8BMNRUyObEWNpeBqZXjBi5Ef hPk9C2uOLcMb6pULMxKnPwdQeFihx2kdoiCrxkkI71SP71qqKUOp1lhXDwJulHYxsLpz RBqg==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=whisper.security; s=whisper; t=1784617232; x=1785222032; darn=ietf.org; h=content-type:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to :content-type; bh=oWwGv7z2QQBQLtOBgZ65lniAlvIQ9iTXxndUn4YuwJI=; b=fKremHt7Q8NV0XlLqm1U7a4ZiIWx2rzgB3wEuW7HU+VAHiRuToXd+xK9G2jmN8VSP+ kEc8z9q8bW1DzZjbXw1Awq1DjwCrWtKEk9yDwtu+KyWLGvw/qpWmoH1dxk/WlYUW8HcH z7N/9vcTrntMzCkOUnV3L00NvkeMAgPrjPZ6Zey7vXqG/WGAgfuwUUN0/KZXC/1Z00u0 cJmGl3OngPvfzpK63QtUdyypzWTAdyk7ZB1cTz18CI9LiS8gFe6M9+tUSHQkt8ZUvFXQ 8flgTLiMsrtnSej2EiO2s8H4/IPHR0C2kiN372KUVpwyuW5AdEQCs+Tmph1eFt7lPJVx ljvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784617232; x=1785222032; h=content-type:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=oWwGv7z2QQBQLtOBgZ65lniAlvIQ9iTXxndUn4YuwJI=; b=r5evD+1CUuRY84W/OuPhFD2HIC2hAijy5XWTKNx0G4ywPKYHy9Uv2DnB+wf+ZoWmTT C0IWlNlFGVUOmhdKu1ljk3QVohRJIlCNpRes8RoUjKni5bmCZD6ihR+rD9O5voLivv+Q DL91Q9wQpZnIOgoG5dhZ4Do1He/fne3F+NL8x6gVDk2ApZb3xUbPFnlUI2hwEpo2/yHr UG8UhapN2HdyKwe2HviXTsNim8GyDwYmVGIsWN/BseX7Ffnpf/hbH52HCDy5nvKDrik5 0pi1FrmpUuJwLNstPuV5xaipJNVuyxDbNH7XPnUAeDp+QIoqdlezeaZ5sVLavQZMuMBH tCUQ== X-Gm-Message-State: AOJu0YzvyTii+Gl3FnSTyc5FwM6KlASVJfZJ8cz1dWw6uibZKRJUo5sY RiRWyEcf/J71LlQqVe93Yczv2sfvK9vjiqju+xxyRVnTSzg9i7xuwqLgRj4eCMzuMlvskasb71a WojKcHjfOsP1Q+trOdZUKvRV6rMdx31mV9Ug1PZJGTen3a4sbysGmXk6SpKT2 X-Gm-Gg: AfdE7cnjKDG6ZRunGX+Htck+pqIvuubqrDcq3+US3kPSN0Nl6nVrLiFXBVkYEbhyp2m OdtTOn2LmjLuFtrEPupnKNf7zGY1XhDiYv5NmQ+FnJcHsug6YxrXzpYUgIxaMJ7FTq6wbfqu13b P4uRLatUscqNJFPh5FzZVqYkoFIoWtB7Nzvl0hPk9XTZwsfrvNsI2F/616PwxjeER31fbXW/X4c qv8wQBu4EL+hOfWkieRV6x23ofBWFe9ifhMITC+Ki4eG4oEsuNjl4GRlbkUlk16H09yXK5e5RU2 3VI9HxVzALuoE2F748W97H+wlKcoV3y6aVmFbcQc8cKQwzZktQ== X-Received: by 2002:a17:906:7953:b0:c16:9d11:8f51 with SMTP id a640c23a62f3a-c16b48c8020mr722275866b.46.1784617231410; Tue, 21 Jul 2026 00:00:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kaveh Ranjbar Date: Tue, 21 Jul 2026 08:00:17 +0100 X-Gm-Features: AUfX_mxEb6g_uYfPcylPkT0IqjbUaV1kvsKZBu5-D0sxgARR6fSc6SAzFcBFlGs Message-ID: To: regext@ietf.org Content-Type: multipart/alternative; boundary="000000000000237709065719946d" Message-ID-Hash: QENGJ5IDMJYL4UKMW23WLCLIOQU7FWQL X-Message-ID-Hash: QENGJ5IDMJYL4UKMW23WLCLIOQU7FWQL X-MailFrom: kaveh@whisper.security X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-regext.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Bregext=5D_Re=3A_Referrals_to_holder-designated_RDAP_servers_for?= =?utf-8?q?_subordinate_resources_=28draft-ranjbar-regext-rdap-subordinate-r?= =?utf-8?q?eferrals-00=29?= List-Id: Registration Protocols Extensions Working Group Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000237709065719946d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Andy, Thank you, and I think you have caught a real imprecision in how I described this, so let me fix it rather than defend it. You are right that "base" has a settled meaning in RDAP: a URL the client processes to build a query, not one it simply dereferences. That is exactly what these relations point at. The target of rdap-base-down is the base URL of the holder's RDAP service, and a client reaching it constructs the subordinate query against that base; it does not fetch the link and expect an object back. So "base" is the correct word, and my earlier "directly dereferenceable" was the loose part, not the name. I will make the text say plainly that the target is a base URL the client queries against, so nothing is left to infer. On needing something that points directly to the resource: for the case this draft is scoped to, I think that is the redirect, not a new relation. A client that wants the specific subordinate object follows the redirect to it, which is your mechanism, and rdap-base-down is only the discovery signal that a downstream service exists and where its base is. So I do not think this use needs a cross-boundary direct-object relation. If other cases in the referrals work want one, I am glad to help define it, but it is separable from this. If, knowing all that, you still read "base" as misleading, I am open to a stem that better signals a cross-boundary base URL. I would just rather settle it with you, here and in the issues, than freeze it early. Thank you also for opening the issues on the referrals repo. That is exactly where I hoped this would go, and I will follow and work them there, the naming and the no-redirects extension especially. To keep the on-list record complete, the points we converged on are folded into a -01 I am posting today: Jasdip's directional rdap-base-down and rdap-base-up split, the registry MUST still redirect for transport with the relation advertised additively, which was Tom's backwards-compatibility point, and the scope narrowed to the off-bootstrap holder-run case. All the best, K. On Sat, Jul 18, 2026 12:53 PM, "Andrew Newton (andy)" wrote: > Hi, > > I created a bunch of issues in github on what I believe we discussed: > > https://github.com/gbxyz/draft-ietf-regext-rdap-referrals/issues > > All that said, I am fine with rdap-base-down/up but I think we need > something that can point directly to the resource. If we are saying > that rdap-up/down/top/bottom are that direct pointer, my understanding > was that those relationships are not expected to cross authoritative > boundaries. And I am fine with those relationships staying that way, > but we would need a new one. rdap-base-down/up contain the "rdap-base" > which, as used with other RDAP terminology, means a URL that the > client must process to obtain the full RDAP URL, as opposed to simply > dereferencing the URL. > > My apologies if I am confused or have caused confusion. > > -andy, no hats > > On Fri, Jul 17, 2026 at 2:47=E2=80=AFPM Kaveh Ranjbar > wrote: > > > > Tom, Andy, Jasdip, > > > > Thank you, all three of you. That was exactly the review I was hoping > for, and it has left the draft in a much better place than it started. > > > > To capture where we landed so that -01 reflects it: the server MUST > still redirect for transport, so an unchanged client continues to receive > the most-specific record with no change on its side; it MAY additionally > advertise rdap-base-down on the covering object, so a client that cares c= an > discover the delegation and cross the authority boundary deliberately; an= d > a no_redirects flag lets a client ask for the registry's own record > alongside the child's. I will take Jasdip's rdap-base-down / rdap-base-up > split, so direction is explicit at the point of use and RFC 9910's rdap-u= p > stays exactly as it is. Scope stays narrow: the holder-run server below t= he > covering allocation, off the bootstrap, and not the in-system RIR and NIR > cases, which need none of this. > > > > On where it lives, I have no strong preference and would rather follow > the chairs: either a section in the referrals draft, or a small > INR-specific document defining rdap-base-down/up and the no-redirect flag= . > Happy to go whichever way causes least confusion, and glad to pick it up = in > Vienna. > > > > I will fold all of this into -01 once the submission tool reopens. > > > > All the best, > > Kaveh > > > > On Thu, Jul 16, 2026 02:41 AM, Tom Harrison wrote: > >> > >> Hi Kaveh, > >> > >> On Wed, Jul 15, 2026 at 05:29:38PM +0100, Kaveh Ranjbar wrote: > >> > I think one word has been doing too much work in this exchange, and > >> > your LACNIC example is what made it clear to me, so thank you for > >> > it. > >> > > >> > I have not been proposing the relation in place of the redirect. I > >> > have been proposing it on top of one. The registry still redirects > >> > for transport, so an unchanged client asking for the more specific > >> > resource lands on the holder's record exactly as it does today. That > >> > is the whole of your backwards compatibility concern, and I want to > >> > meet it head on: the most specific answer stays reachable with no > >> > client change. rdap-base-down is not the path to that answer, it is > >> > a second, optional thing on the covering object that says a > >> > subordinate service exists and lets a client that cares enumerate > >> > and cross the boundary deliberately. no_redirects is the third > >> > piece, for a client that wants the registry's own record as well as > >> > the child's. Redirect for compatibility, relation for discovery, > >> > flag for the parent. Not one instead of another. > >> > > >> > On registro.br, I read that as the in-system case rather than a > >> > counter to it. registro.br is a registry, and LACNIC redirects to it > >> > because LACNIC has been configured to: the pointer lives in the > >> > system and the bootstrap-plus-redirect chain reaches it. That is > >> > exactly the RIR and NIR situation I agreed needs no new machinery. > >> > The case the draft is scoped to is narrower: a holder running RDAP > >> > for delegations below its own allocation, records the RIR keeps out > >> > of its database by design, on a server no one has configured the RIR > >> > to point at. Where the holder does register that pointer with the > >> > registry, I am happy for the server to redirect, and to say so with > >> > a MUST, which I think is the requirement you asked for earlier. What > >> > the relation adds in that case is only what the bare redirect cannot > >> > give: that a delegation exists at all, and that answering it crossed > >> > out of the registry's own data. > >> > > >> > So I think we are closer than the last few mails suggest. If I write > >> > -01 as "the server MUST still redirect, and MAY additionally > >> > advertise rdap-base-down, with no_redirects available to a client > >> > that wants both records," does that resolve the compatibility > >> > objection for you? > >> > >> Yep, that sounds fine to me, thanks. > >> > >> -Tom > --000000000000237709065719946d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Andy,

Thank you, and I think= you have caught a real imprecision in how I described this, so let me fix = it rather than defend it.

You are right that "base" has a = settled meaning in RDAP: a URL the client processes to build a query, not o= ne it simply dereferences. That is exactly what these relations point at. T= he target of rdap-base-down is the base URL of the holder's RDAP servic= e, and a client reaching it constructs the subordinate query against that b= ase; it does not fetch the link and expect an object back. So "base&qu= ot; is the correct word, and my earlier "directly dereferenceable"= ; was the loose part, not the name. I will make the text say plainly that t= he target is a base URL the client queries against, so nothing is left to i= nfer.

On needing something that points directly to the resource: for= the case this draft is scoped to, I think that is the redirect, not a new = relation. A client that wants the specific subordinate object follows the r= edirect to it, which is your mechanism, and rdap-base-down is only the disc= overy signal that a downstream service exists and where its base is. So I d= o not think this use needs a cross-boundary direct-object relation. If othe= r cases in the referrals work want one, I am glad to help define it, but it= is separable from this.

If, knowing all that, you still read "= base" as misleading, I am open to a stem that better signals a cross-b= oundary base URL. I would just rather settle it with you, here and in the i= ssues, than freeze it early.

Thank you also for opening the issues o= n the referrals repo. That is exactly where I hoped this would go, and I wi= ll follow and work them there, the naming and the no-redirects extension es= pecially. To keep the on-list record complete, the points we converged on a= re folded into a -01 I am posting today: Jasdip's directional rdap-base= -down and rdap-base-up split, the registry MUST still redirect for transpor= t with the relation advertised additively, which was Tom's backwards-co= mpatibility point, and the scope narrowed to the off-bootstrap holder-run c= ase.

All the best,
K.

On Sat, Jul 18, 2026 12:53 PM, "Andrew Newton (andy)" &= lt;andy@hxr.us> wro= te:
Hi,

I created a bunch of issues in github on what I believe we discussed:

https://github.com/gbxyz/draft-ietf-= regext-rdap-referrals/issues

All that said, I am fine with rdap-base-down/up but I think we need
something that can point directly to the resource. If we are saying
that rdap-up/down/top/bottom are that direct pointer, my understanding
was that those relationships are not expected to cross authoritative
boundaries. And I am fine with those relationships staying that way,
but we would need a new one. rdap-base-down/up contain the "rdap-base&= quot;
which, as used with other RDAP terminology, means a URL that the
client must process to obtain the full RDAP URL, as opposed to simply
dereferencing the URL.

My apologies if I am confused or have caused confusion.

-andy, no hats

On Fri, Jul 17, 2026 at 2:47=E2=80=AFPM Kaveh Ranjbar <kaveh@whisper.sec= urity> wrote:
>
> Tom, Andy, Jasdip,
>
> Thank you, all three of you. That was exactly the review I was hoping = for, and it has left the draft in a much better place than it started.
>
> To capture where we landed so that -01 reflects it: the server MUST st= ill redirect for transport, so an unchanged client continues to receive the= most-specific record with no change on its side; it MAY additionally adver= tise rdap-base-down on the covering object, so a client that cares can disc= over the delegation and cross the authority boundary deliberately; and a no= _redirects flag lets a client ask for the registry's own record alongsi= de the child's. I will take Jasdip's rdap-base-down / rdap-base-up = split, so direction is explicit at the point of use and RFC 9910's rdap= -up stays exactly as it is. Scope stays narrow: the holder-run server below= the covering allocation, off the bootstrap, and not the in-system RIR and = NIR cases, which need none of this.
>
> On where it lives, I have no strong preference and would rather follow= the chairs: either a section in the referrals draft, or a small INR-specif= ic document defining rdap-base-down/up and the no-redirect flag. Happy to g= o whichever way causes least confusion, and glad to pick it up in Vienna. >
> I will fold all of this into -01 once the submission tool reopens.
>
> All the best,
> Kaveh
>
> On Thu, Jul 16, 2026 02:41 AM, Tom Harrison <tomh@apnic.net> wrote:
>>
>> Hi Kaveh,
>>
>> On Wed, Jul 15, 2026 at 05:29:38PM +0100, Kaveh Ranjbar wrote:
>> > I think one word has been doing too much work in this exchang= e, and
>> > your LACNIC example is what made it clear to me, so thank you= for
>> > it.
>> >
>> > I have not been proposing the relation in place of the redire= ct. I
>> > have been proposing it on top of one. The registry still redi= rects
>> > for transport, so an unchanged client asking for the more spe= cific
>> > resource lands on the holder's record exactly as it does = today. That
>> > is the whole of your backwards compatibility concern, and I w= ant to
>> > meet it head on: the most specific answer stays reachable wit= h no
>> > client change. rdap-base-down is not the path to that answer,= it is
>> > a second, optional thing on the covering object that says a >> > subordinate service exists and lets a client that cares enume= rate
>> > and cross the boundary deliberately. no_redirects is the thir= d
>> > piece, for a client that wants the registry's own record = as well as
>> > the child's. Redirect for compatibility, relation for dis= covery,
>> > flag for the parent. Not one instead of another.
>> >
>> > On registro.br, I read that as the in-system case rather than = a
>> > counter to it. registro.br is a registry, and LACNIC redirects t= o it
>> > because LACNIC has been configured to: the pointer lives in t= he
>> > system and the bootstrap-plus-redirect chain reaches it. That= is
>> > exactly the RIR and NIR situation I agreed needs no new machi= nery.
>> > The case the draft is scoped to is narrower: a holder running= RDAP
>> > for delegations below its own allocation, records the RIR kee= ps out
>> > of its database by design, on a server no one has configured = the RIR
>> > to point at. Where the holder does register that pointer with= the
>> > registry, I am happy for the server to redirect, and to say s= o with
>> > a MUST, which I think is the requirement you asked for earlie= r. What
>> > the relation adds in that case is only what the bare redirect= cannot
>> > give: that a delegation exists at all, and that answering it = crossed
>> > out of the registry's own data.
>> >
>> > So I think we are closer than the last few mails suggest. If = I write
>> > -01 as "the server MUST still redirect, and MAY addition= ally
>> > advertise rdap-base-down, with no_redirects available to a cl= ient
>> > that wants both records," does that resolve the compatib= ility
>> > objection for you?
>>
>> Yep, that sounds fine to me, thanks.
>>
>> -Tom
--000000000000237709065719946d--