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

Shane Kerr shane at time-travellers.org
Fri Dec 23 15:14:38 UTC 2016


Andrew,

At 2016-12-21 18:09:40 +0000
Andrew Mcconachie <andrew.mcconachie at icann.org> wrote:

> On behalf of the Caucus Work Party on Root Server Naming Schemes,
> please find the draft Technical Analysis of the Naming Scheme used
> for Individual Root Servers for your review.
> 
> The Work Party has considered the comments of the RSSAC Caucus and
> considers them resolved in the current document. Specifically, the
> Work Party would like to draw the reviewers’ attention to the 3rd
> paragraph of the Introduction that describes the motivation for this
> study.
> 
> This review will last until January 4th, 2017(2 weeks). Please send
> any comments you have to this list.

I have a few comments, and then I'd like to respond to some others that
people have sent separately. In particular, I haven't reviewed all of
Duane's comments yet.

* 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. ;)

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

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

* 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"?

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

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

Cheers,

--
Shane
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mm.icann.org/pipermail/rssac-caucus/attachments/20161223/86314815/attachment.sig>


More information about the rssac-caucus mailing list