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
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail