ietf
[Top] [All Lists]

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

2014-10-28 09:01:14
Le 2014-10-28 à 04:48, Alessandro Vesely <vesely(_at_)tana(_dot_)it> a écrit :

Marc,

On Mon 27/Oct/2014 19:22:18 +0100 Marc Blanchet wrote:
Le 2014-10-15 à 15:20, Alessandro Vesely <vesely(_at_)tana(_dot_)it> a 
écrit :

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?

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
 and policy reasons.

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

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. 


- 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.

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.


Thank you for your editing and attention
Ale