Subject: [weirds] bootstrap: Figure out a way to handle sub-TLD registry entries (#27)

From: Andrew Sullivan <[email-masked]>
Date: Wed, 14 May 2014 14:22:21 -0400

Hi,

Ticket 27 says that we need a way to include subordinate domains in
the IANA registry.  I don't understand why.  Why shouldn't these be
simple referrals from the top level RDAP system?

(That this problem would crop up, by the way, is why I thought an IANA
registry for this bootstrapping purpose was a bad idea.  SRV records
in the DNS would IMO still be better.)

A

PS: I didn't put this in the trac, because apparently the credentials for
the trac are not what I thought they are, and the computer that knows
about those credentials is in my apartment & not at this office.
Hurray for passwords!

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 15 May 2014 02:51:09 -0000

>simple referrals from the top level RDAP system?

There are two administrative situations here, exemplified by ac.uk and
uk.com.

The ac.uk tree is run by Janet, while the rest of .uk is run by
Nominet.  When I brought this up, people said that Nominet would
likely do the referral to Janet, because of their longstanding
relationship.  The uk.com tree is run by Centralnic, and nobody I know
thinks Verisign is likely to do referrals other than to the
registrars for thin registries.

This impresses me as the sort of administrative issue that the IETF
should not try to specify.  If IANA runs the bootstrap site, they'll
decide who qualifies to add entries to it.  I realize this won't make
everyone happy, but it's hard to imagine anything that the IETF could
do here that would be unambiguously better.

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 14 May 2014 23:35:47 -0400

> do here that would be unambiguously better.

It's hard to think of anything the IETF could do that would be
unambiguously worse, too.  What you are proposing is to dump the
(mostly political) problem of (in effect) what constitutes a public
suffix onto a protocol parameters registry operated by IANA.  I
thought we got rid of that kind of problem by hiving it off to ICANN.
This is going to introduce it again through the back door.

The reason I always liked using SRV or some such records is because
they are certain to work for the top-most level, they could be made to
work for levels under that (but referrals will work just as well) when
there is co-operation across the parts of the DNS tree, and if the
client wanted to look for them they would work at every level.  At the
same time, the ability to publish the record would be fully aligned
with control over the DNS name in question; and since this is supposed
to be a registry data service for things that can be so nicely
represented in the DNS, that seems a nice bit of symmetry.  A central
registry requires a central policy for what gets into the registry,
which inevitably invites a fight about how to handle disputes,
national regulations on what is permitted, &c. &c.  If you don't
believe me, I have months of (other) mailing list archives I will
cheerfully send your way.

I don't think we should paint that sort of target on the IANA protocol
parameters registries.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 15 May 2014 04:16:54 -0000

>suffix onto a protocol parameters registry operated by IANA.

Not really.  Remember, this is WEIRDS, not DBOUND.

IANA currently publishes its Root Zone Database here:

http://www.iana.org/domains/root/db

Each entry in that database is a TLD, and most of them include the
name of the WHOIS server for the TLD.  I certainly don't speak for
IANA, but my working assumption has been that the same entities that
provide their WHOIS servers there will provide their WEIRDS bootstrap
info.

R's,
John

PS: I scrape the WHOIS server info every day into <tld>.ws.sp.am, like
whois-servers.net but more up to date.

---

From: Frederico A C Neves <[email-masked]>
Date: Fri, 16 May 2014 10:02:10 -0300

... 
> do here that would be unambiguously better.

This is a good reason on why we should keep it simple and specify only
the bootstrap of the first level. Further indirection should be
handled by redirects and policy along the publishing of then is a
future work for ccTLDs policy bodies or the GNSO in the case of ICANN.

Fred

---

From: "John Levine" <[email-masked]>
Date: 18 May 2014 16:33:07 -0000

In article <[email-masked]> you write:
>Not really.  Remember, this is WEIRDS, not DBOUND. ...

Assuming IANA just publishes the bootstraps for TLDs for which they
currently publish WHOIS servers, we're roughly where we are now.  You
can do a WHOIS lookup for a domain whose WHOIS server isn't in the
IANA list, but you have to find the server some other way.  This is
already an issue, since there are a fair number of TLDs that have
WHOIS servers but for whatever reason aren't in the IANA WHOIS
database.  (I have a manual exception list I use for my ws.sp.am
hack.)

If we publish a standard bootstrap format, there's nothing keeping
other parties from publishing their own bootstrap lists that add more
entries to the IANA list.

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 19 May 2014 13:43:40 -0400

On Thu, May 15, 2014 at 04:16:54AM -0000, John Levine wrote:
> Each entry in that database is a TLD

By definition, yes.

> provide their WHOIS servers there will provide their WEIRDS bootstrap

Right.  And from there, the RDAP server can provide a referral to
the next level down, in case that's appropriate.  Otherwise, IANA
needs to make up some sort of policy about what further levels go in.

The original point, I thought, was that attempting to deal with either
"co.uk" or "uk.com" is going to be problematic.  I still think that is
true, and I don't want to get IANA into that mess.  You seemed to be
arguing that those things ought to be coped with in the IANA
repository; I believe doing so would be a mistake.
 
> IANA list, but you have to find the server some other way.

Sure.  The fact that you have to keep these extra lists on scraps of
paper or whatever, however, seems like a problem with the existing
system, not something that should be enshrined permanently.  Which is
why I at least preferred the DNS-based approach.  I get it that the WG
didn't select that approach, and I'm not trying to reopen that
discussion.  But IMO rejecting that approach meant that we also
rejected publishing stuff _except_ the top level servers, and
therefore I think this ticket should be closed "will not fix".

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

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

>"co.uk" or "uk.com" is going to be problematic.

Not quite.  Dealing with co.uk is not a problem, because it's run by
the same people who run .uk.  Dealing with ac.uk is probably not a
problem because of the long relationship Janet (ac.uk) has with
Nominet (uk).  Dealing with uk.com is a problem, because Centralnic
(uk.com) has no relationship with Verisign other than the one that the
rest of the 100,000,000 registrants do.

>  I still think that is

Oh, no, we agree.  IANA publishes what it publishes, we don't attempt
to make rules for what they include, only what the syntax and query
scheme is.

R's,
John

---

From: Gavin Brown <[email-masked]>
Date: Tue, 20 May 2014 08:46:41 +0100

> entries to the IANA list.

Wouldn't that defeat the whole point of having a bootstrap? Instead of a
single authoritative list of endpoints, the use of which is enshrined in
an interoperable standard, there would be instead be multiple different
lists, and different clients would be trained to use a different subset
of those lists, resulting in exactly the sort of crappy user experience
that whois provides now.

As the operator of a registry service under a number of ccTLDs, newly
delegated gTLDs and second-level domains, we see operational issues
every day that are caused by the lack of an interoperable bootstrap
mechanism for whois: transfer authorisation emails, SSL certificate
authorisations and abuse takedown requests are regularly mis-addressed
because there is a whois client somewhere that doesn't know where to
query for a .wiki or a .uk.com. It would be a shame to propagate this
state of affairs to the new protocol.

G.

-- 
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: "John R Levine" <[email-masked]>
Date: 20 May 2014 11:15:48 -0400

> single authoritative list of endpoints, ...

The problem is the word "authoritative".  I expect that IANA considers its 
list to be authoritiative, even though it contains neither uk.com, nor 
watkins-glen.ny.us.  (The previous .us registry delegated it and several 
other locality registries to me over a decade ago, and I doubt that 
Neustar has thought about whether they'll do RDAP redirects.)

The IETF is pretty good at building mechanism, and totally unable to build 
policy, since all of our standards are voluntary.  When WEIRDS was new, 
some people demanded that each domain's RDAP entry MUST contain full 
unredacted contact info.  While I sympathize with their goals, that's not 
how MUST works, and I told them so.

We've now been around the bootstrap issue enough times that it seems 
unlikely there's any mechanism we've missed.  For domains, it's either 
someone collects the bootstrap info in one place and publishes it, or the 
registries publish the info in the DNS, probably using DDDS and NAPTR. 
(I'd be OK with SRV but I expect the URI police would not.)  I don't see 
any plausible way to look for NAPTR other than the two options of only 
look at the TLD, or do a tree walk of every name suffix, which the DNS 
crowd would hate, and would likely lead to chaos since not everyone who 
might purport to sell subdomains would do it as responsibly as you do.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.