[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