Subject: Re: Last Call: <draft-ietf-weirds-bootstrap-09.txt> (Finding the Authoritative Registration Data (RDAP) Service) to Proposed Standard

From: Alessandro Vesely <[email-masked]>
Date: Wed, 15 Oct 2014 21:20:03 +0200

On Tue 14/Oct/2014 00:25:29 +0200 The IESG wrote: 
> 
> The IESG has received a request from the Web Extensible Internet
> Registration Data Service WG (weirds) to consider the following document:
> - 'Finding the Authoritative Registration Data (RDAP) Service'
>   <draft-ietf-weirds-bootstrap-09.txt> as Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2014-10-27.

A couple of notes.  In the *Introduction*:

   The required new functionality in support of RDAP could be
   accomplished by augmenting these registries to contain new fields,
   or creating second parallel registries containing the extra fields
   whose entries mirror the existing ones.  Either approach will
   satisfy the needs of this document.

This is a hint to IANA, which might be moved to Section 12.  It may
sound confusing to client implementors.  If it is moved, the next
sentence could be reworded to read, e.g.:

   This document requests IANA to make an augmented version of the
   existing registries available for the specific purpose of RDAP
   use, herein named RDAP Bootstrap Service Registries.

In Section 4, *Domain Name RDAP Bootstrap Service Registry*, the
concept of longest match doesn't make sense.  Say url1 does "com" and
"net" while url2 does "com" only, then one will find:

   "services": [[["com", "net"], [url1]], [["com"], [url2]]]

(An alternative, possibly easier for a client who needs to resolve a
"com" domain, would be:

   "services": [[["com"], [url1, url2]], [["com", "net"], [url1]]]
)

IANA delegates root entries only (not co.uk) so the /longest/ match is
actually an /equal/ match, meaning that there might be multiple
entries for a given name in different second-level arrays, as in the
non-parenthesized case above.  Correct?

Finally, in Section 6 *Entity*, it is not obvious what one means by
"entity".  Perhaps is might be worth to insert a preamble, e.g.:

   Entities (such as contacts, registrants, or registrars) can be
   queried by handle as described in [I-D.ietf-weirds-rdap-query].
   However, since there is no global namespace for entities, this
   document does not describe how to find...

jm2c
Ale

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 27 Oct 2014 14:22:18 -0400

> Le 2014-10-15 à 15:20, Alessandro Vesely <[email-masked]> a écrit :
> 

done in -10.

> non-parenthesized case above.  Correct?

disagree. This has been discussed a lot during the wg work. 
- we don’t want to restrict the lookup to single TLD, for technical and policy reasons. 
- given large concentration of registries managed by single organisations, and the fact that just for tlds, there is a large amount of tlds coming…, there was an agreement for the structure in the draft to support multiple entries per rdap server.

so rejecting this one. 

>   document does not describe how to find…

ok. thanks. done in -10.

Marc.

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 28 Oct 2014 09:48:12 +0100

Marc,

> disagree. This has been discussed a lot during the wg work.

I'm not arguing about whatever design decisions that section makes.
I'm saying they are not presented clearly.  The example I made was 
meant to show a question I'd ask if I were coding a client, "I'm 
resolving 'com', do I need to check the whole array or can I stop the 
first time I find it?"  As an answer, longest match doesn't seem to be 
very clear, because subdomain-in-IANA is a doubtful concept.

> - we don’t want to restrict the lookup to single TLD, for technical

Do you mean IANA can serve subdomain data if they want to?

> - given large concentration of registries managed by single
>   organisations, and the fact that just for tlds, there is a large
>   amount of tlds coming…, there was an agreement for the structure in
>   the draft to support multiple entries per rdap server.

A sentence like that would help readers, IMHO.  People with no 
specific knowledge of tld assignments might think the array is 
arranged the other way around.

Thank you for your editing and attention
Ale

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 28 Oct 2014 10:00:47 -0400

Le 2014-10-28 à 04:48, Alessandro Vesely <[email-masked]> a écrit :
> I'm saying they are not presented clearly.  The example I made was meant to show a question I'd ask if I were coding a client, "I'm resolving 'com', do I need to check the whole array or can I stop the first time I find it?"  As an answer, longest match doesn't seem to be very clear, because subdomain-in-IANA is a doubtful concept.
> 

I’m just saying this is not our(IETF) business. We have done a technical specification. The policies, as discussed in the draft, will be set by IANA, based on current registries. 

> A sentence like that would help readers, IMHO.  People with no specific knowledge of tld assignments might think the array is arranged the other way around.

you are right that there is various design considerations that were debated during the wg work that is not discussed in the document. If there is a need for another iteration of the document, I’ll look into adding text about this. 

Marc.