Re: Last Call: <draft-iab-2870bis-01.txt> (DNS Root Name Service Protoco

Hi,

General comments:

* Given RSSAC-001 has not (to my knowledge) been published, I do not feel this 
document should be in last call, particularly given it is to move an existing 
BCP to historic (a bit more on this below).

* The sections on requirements is overly minimalistic. A bit of explanation 
about those requirements would be useful.

Specific comments:

* Section 1, 2nd paragraph:

   They currently also serve the root-
   servers.net zone and the zone for the .arpa top-level
   domain[ARPAZONE].

The "J" root server does not serve .ARPA.  Perhaps:

"They currently also serve the root-servers.net zone and some root servers 
serve the .arpa zone."

* Section 1.1, 2nd sentence:

   This document and [RSSAC-001] together functionally replace
   [RFC2870].

Given the IETF does not maintain change control of RSSAC-001, I'm unsure if it 
is appropriate to reference it as a component of something that is obsoleting 
2870.  

* Section 3, title:

      3. Deployment Requirements

I feel this section is talking more about root zone publication requirements. 
"Deployment Requirements" suggests to me a discussion of the requirements for 
deploying root servers (e.g., geographical distribution, anycast routing, etc.)

* Section 3, 2nd sentence:

      MUST answer queries from any entity conforming to [RFC1122] with a
      valid IP address.

This requires the root servers to not use any form of response rate limiting, 
nor impose any sort of sanity checks to where responses will be sent. I believe 
this is risky and inappropriate in the world of spoofed source address DDoS.

* Section 3, 3rd sentence:

    MUST serve the unique [RFC2826] root zone[ROOTZONE].

As far as I understand, RFC 2826 talks about why a unique root zone is 
required, it doesn't actually talk about the Internet's root zone.   Perhaps 
something more along the lines of "MUST, as a result of the technical 
considerations documented in [RFC2826], serve the Internet's unique root 
zone[ROOTZONE]." 

This would also probably be place to mention that the unique root zone MUST be 
published without modification.

* Section 3, 3rd sentence:

      MAY also serve the root-servers.net zone, and the zone for the
      .arpa top-level domain [ARPAZONE],[RFC3172].

Section 3 is talking about requirements, so it isn't clear to me that a "MAY" 
should be in this section.

* Section 5

I believe it would be appropriate to document that IANA has a responsibility to 
publish [ROOTZONE], update the root hints, and ensure the root zone trust 
anchor is published.

Regards,
-drc

signature.asc
Description: Message signed with OpenPGP using GPGMail