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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Le 2014-10-28 à 04:48, Alessandro Vesely <vesely@xxxxxxx> a écrit :
> 
> Marc,
> 
> On Mon 27/Oct/2014 19:22:18 +0100 Marc Blanchet wrote:
>>> Le 2014-10-15 à 15:20, Alessandro Vesely <vesely@xxxxxxx> 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






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]