Subject: [weirds] Endpoint-centric RDAP bootstrap format

From: Gavin Brown <[email-masked]>
Date: Mon, 12 May 2014 09:53:26 +0100

Hi all,

One of the optimizations I suggested at IETF89 was that the bootstrap
file define RDAP servers as first-order objects, and then map zones in
the DNS to those servers.

I had a stab at designing syntax that would implement this, which is at
the link below. It also has a few other nice features, such as inheritance.

https://gist.github.com/jodrell/246faa9b1eb4ca617c9f

Regards,

-- 
Gavin Brown
Chief Technology Officer
CentralNic Group plc (LSE:CNIC)
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/

CentralNic Group plc is a company registered in England and Wales with
company number 8576358. Registered Offices: 35-39 Moorgate, London,
EC2R 6AR.

---

From: Andrew Newton <[email-masked]>
Date: Mon, 12 May 2014 14:06:31 +0200

Looks good. Here are a few suggestions:

1. There needs to be examples for the RIR use cases for IP addresses
and autnums.
2. Have you considered adding structures for RDAP conformance
identifiers (section 5.1 of json-response) and JSON prefixes (section
6 of using-http)?

-andy

On Mon, May 12, 2014 at 10:53 AM, Gavin Brown
<[email-masked]> wrote:
> _______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds
>

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 12 May 2014 16:14:38 +0000

> -----Original Message-----
> From: weirds [mailto:[email-masked]] On Behalf Of Gavin Brown
> Sent: Monday, May 12, 2014 4:53 AM
> To: [email-masked]
> Subject: [weirds] Endpoint-centric RDAP bootstrap format
> 
> Hi all,
> 

I think this could work. Using rdap-query as an example, I would re-write 3.1.3, the Domain Path Segment Specification, like this:

<Somewhere I'd write some new text to note that the values of the {proto) and {host} parameters are determined through the bootstrap process>

"Domain path segments are constructed using the domain lookup template specified in [bootstrap reference]. The template parameters MUST be replaced as follows:

{object}: domain
{identifier}: <domain name>

where <domain name> is a fully-qualified (relative to the root) domain name..."

Search would be similar:

"Domain search path segments are constructed using the domain search template specified in [bootstrap reference]. The template parameters MUST be replaced as follows:

{domain}: <domain name>

where <domain name> is a search pattern representing a domain name..."

Scott

---

From: "John Levine" <[email-masked]>
Date: 12 May 2014 18:18:00 -0000

>the DNS to those servers.

I'm not thrilled by this.  It makes the minimum client much more
complicated, and makes the bootstrap more fragile.  Remember that
there will be many more clients than servers, so given a choice, the
complexity belongs in the server.

If the bootstrap file is somewhat long and redundant, I don't see that
as a problem, since we have grep.  If you have a regular internal
structure to your URLs (which in fact we do, and all agreed that we do
before the get off my lawn detour), can't you use a a script at your
end to generate all the bootstrap bits and ship them off to IANA?

R's,
John

---

From: Naoki Kambe <[email-masked]>
Date: Tue, 13 May 2014 11:18:15 +0900 (JST)

From: Gavin Brown <[email-masked]>
Date: Mon, 12 May 2014 09:53:26 +0100
> https://gist.github.com/jodrell/246faa9b1eb4ca617c9f

Thank you for the interesting example. Here are my quick comments
inline:

|     // this structure maps DNS zones to RDAP endpoints:
|     "zones": {
|       "com" => "VRSN-THIN",
|       "net" => "VRSN-THIN",
|       "tv" => "VRSN",
|       "wiki" => "CNIC",
|       "la" => "CNIC",
|       "us.com" => "CNIC",
|     },

Are the above delimiters "=>" typo of ":"?

|       "us.com" => "CNIC",

I think the "us.com" rdap server would be also resolved by the "com"
rdap server. Should this bootstrap file contain SLD information?

|     // definition of global templates:
|     "templates": {
|       "default": "{proto}://{host}/{object}/{identifer}"
|     },

Do we also need a default search-type template here?

|     // definition of an RDAP endpoint:
|     "servers": [
|       {
...
|         // supported protocols
|         "protos": [ "http", "https" ],

I think "https" should be preferred than "http".  It would be better
that the order is reverse.

|         // URI templates
|         "templates": {
...
|           // templates for lookups
|           "lookup": {
...
|             // this one is a "custom" template
|             "host": "{proto}://{host}/nameserver/{host}",

Two "{host}" variables seem to be used at the different meanings. This
might be confusion.  Could you rename either one or replace the
former one with the actual name?

Regards,

Naoki Kambe

---

From: Gavin Brown <[email-masked]>
Date: Tue, 13 May 2014 07:44:47 +0100

> Are the above delimiters "=>" typo of ":"?

Yes - my brain was still thinking in Perl.

> rdap server. Should this bootstrap file contain SLD information?

Other than the fact that Verisign delegates us.com from com, the .us.com
registry is unrelated to the .com registry, and will have a different
RDAP endpoint. I certainly hope that SLDs such as us.com have a place in
this file.

> Do we also need a default search-type template here?

Yes - the example is not complete but shows a minimal set of options.

> that the order is reverse.

The order isn't meant to be meaningful, and I imagine that most clients
would choose which protocol they prefer.

> former one with the actual name?

Agreed - the second one should probably be {nameserver}.

G.

---

From: Naoki Kambe <[email-masked]>
Date: Tue, 13 May 2014 19:54:20 +0900 (JST)

From: Gavin Brown <[email-masked]>
Date: Tue, 13 May 2014 07:44:47 +0100
> RDAP endpoint. I certainly hope that SLDs such as us.com have a place in

That's right, but I'm just afraid that the file might be so big and it
might be hard for RDAP clients to parse it. In addition to such SLDs
case, hundreds of new gtlds are being delegated from now. I'm just
suspicious about whether this might be scalable well.

Regards,

Naoki Kambe

---

From: "John Levine" <[email-masked]>
Date: 13 May 2014 12:57:12 -0000

>suspicious about whether this might be scalable well.

The more I think about this proposal, the more it looks like's an
administrative nightmare, as well as .  It adds a new name space, a
server directory that someone would have to manage.  

If two organizations both send in a server named FOONIC, who wins?
(Keep in mind that ccTLDs can feel strongly about things like this.)

If there's an existing definition of FOONIC, and someone sends in 
a new one, how do you handle it?  If the list of zones isn't the
same as the old list do you merge them?  If there are names missing
from the new list, do you keep the old server definition around as
FOONIC-OLD?  If the new one adds new names and changes the server
definition, do you assume they meant to update the existing names?

IANA will make its own policies about what zones are eligible for the
bootstrap server, but if an update includes a mixture of zones they
handle because they're delegated directly (TLDs) and zones they don't
(ac.uk, us.com), do they reject the whole thing?  Skip the bad ones?

It's also relatively difficult to verify the validity of a bootstrap
in this format, since you need to do a tree walk from every listed
zone to make sure there is a server with a working inheritance path,
and that the zone names with the servers match the names in the
directory.  If there's a server with no zones, is that a bug?

In my experience, the point of a bootstrap is to provide the simplest
startup path for whatever software is using it.  While this plan is an
elegant way to store the information, it's not a good bootstrap.  If
you want, store it this way internally, but for the actual bootstrap,
we need to flatten it so that if I want to find the contacts for, say,
CHEESE.HOCKEY, I can get the entry for .HOCKEY and it's got the URLs I
need.

Earlier I said the bootstrap might have a single global default.
That's probably still a reasonable idea, because in practice I expect
every server will use the URI syntax in the draft, and only the prefix
will vary.

R's,
John

PS: I sure hope there aren't separate VRSN-THIN and VRSN-THICK
bootstraps.  One of the points of RDAP is that these are unified, and
a thin registry does a 302 redirect to the registrar that can answer
the question.