[rssac-caucus] FOR REVIEW: Technical Analysis of the Naming Scheme used for Individual Root Servers

Paul Hoffman paul.hoffman at icann.org
Wed Jan 4 20:13:10 UTC 2017


I'll take a stab at responding to these since it's the end of the call for comments.

On Dec 23, 2016, at 7:14 AM, Shane Kerr <shane at time-travellers.org> wrote:

> * First, I think it makes sense to make an "executive summary" at the
>  top of the document. I passed out a few times since I was holding my
>  breath to know the actual recommendations, which I didn't find until
>  near the bottom of page 17, and even then not really highlighted in
>  any way. ;)

RSSAC and SSAC documents don't seem to put the recommendations at the top, always at the end. I guess the folks reading them have mostly gotten used to that.

> * In this paragraph:
> 
>  "However, given today’s Internet environment, the RSSAC would like to
>  study the naming scheme used for individual root servers and consider
>  whether changes need to be made."
> 
>  We should change "would like to study" to "has studied" and
>  "consider" to "considered". The work is done, not pending.

Agree, now that this is ready for publication.

> * Minor nit... some of the RFC references are a lovely shade of blue,
>  but not all. Probably these should all be made into clickable links
>  and all presumably blue, or all left as formal black.

Agree.

> * I think that this paragraph needs some tweaking:
> 
>  "In order to maintain compatibility with current resolvers, this list
>  does not include any proposal that would cause the response to a
>  priming query that includes all 13 of the current root servers’ IPv4
>  addresses to be larger than 512 bytes."
> 
>  I just did a quick check, and at least I, J, and L currently sometimes
>  return answers that do not include 13 root server IPv4 addresses in
>  their response to 512-byte queries. On example is where the name
>  servers are returned sorted, with A followed by AAAA records.
> 
>  Actually some root servers return only IPv6 glue if queried without
>  EDNS using IPv6. I guess the assumption is that "current resolvers"
>  don't run IPv6 so are not included in this description?
> 
>  I guess what is really meant is something like, "to be conservative,
>  we want to return a response that fits all 13 of the current root
>  servers' IPv4 addresses in 512 bytes for resolvers that do not use
>  EDNS or IPv6"?

Disagree. The sentence as it stands is correct: we want a root server operator that wants to send all 13 of the current root servers’ IPv4 addresses to be able to do so in less than 512 bytes. If a root server operator wants to send a different set of addresses, they can.

> * "scheme.." should be "scheme.", or possibly "scheme...." ;)

Sure.

> * I'm not sure how to take this paragraph:
> 
>  "However, different name server implementations differ on whether or
>  not they return RRSIG information for the name server names within
>  the shared TLD."
> 
>  It reads like a limitation, whereas since there are only 13 root
>  server operators they could co-ordinate and make sure that the
>  software they run is consistent if this is important (or varies in
>  behavior if that is important). 

We are not claiming that the behavior is important, so it is not a limitation that we know of.

--Paul Hoffman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3906 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/rssac-caucus/attachments/20170104/e046df8e/smime.p7s>


More information about the rssac-caucus mailing list