DNS Root Name Service Protocol and Deployment Requirements
RFC 7720

Note: This ballot was opened for revision 02 and is now closed.

(Adrian Farrel) (was No Objection) Discuss

Discuss (2015-03-08 for -02)
Adding a Discuss to by previous Comments (thanks to Deborah for raising this with me).

Sections 2 and 3 tell us that implementations "MUST" do stuff described in a number of RFCs. I think that makes those RFCs normative references. I'm happy to be talked out of that, but you may a long way to go to persuade me.
Comment (2015-03-06 for -02)
No email
send info
I'm balloting No Objection, but there are some relatively trivial things
that could be done to improve the document.

---

It's a shame about the passive voice in the Abstract. It makes it
unclear who has the expectation. Additionally, the choice of words makes
it unclear whether you are saying "we have an expectation that you will
do this" or "we are predict this will happen."

In fact, they are "implementation and deployment requirements." Is there
a need to say more?

---

Section 2

   Operative details are documented in [RSSAC-001] and implementation is
   left to the operators of the root name service.

Implementation of what?

---

The document really should make clear whether there are any changes to
the requirements originally espoused in 2870. If there are, they can be
flagged. If not, it is just a few words to say so.

---

The Abstract should make note of Obsoleting 2870. I believe idnits tells
you to do this.

(Pete Resnick) Discuss

Discuss (2015-03-04 for -02)
[Updating per Jari's suggestion that the words should be different now that RSSAC-001 is done.]

I strongly agree with Paul Hoffman's suggested rewording in section 1:

OLD
   The operational requirements are defined in [RSSAC-001].  This
   document defines the protocol requirements and some deployment
   requirements.
NEW
   This document only defines the protocol requirements and some
   deployment requirements; the operational requirements that were
   defined in RFC 2870 are removed. Operational requirements are
   now defined by the Root Server System Advisory Committee of ICANN
   and are documented in [RSSAC-001].
END

Stating it as it is currently written (along with the text in 1.1) makes it sound like RSSAC is somehow part of the BCP, which it obviously cannot be. Please make the above change.

Please strike section 1.1. My understanding is that the IAB does not consider it necessary to move 2870 to Historic, and the fact that this is obsoleting 2870 and replacing it in the BCP series is sufficient. (Even if this weren't so, documents don't "reclassify" other document as Historic.) Further, the above change in section 1 makes the second part of 1.1 unnecessary.

In the header: Please add "BCP: 40 (if approved)"

(Jari Arkko) Yes

(Brian Haberman) Yes

Comment (2015-03-06 for -02)
No email
send info
I agree with the points raised by Adrian, Barry, & Pete.

(Alia Atlas) No Objection

Comment (2015-03-12 for -02)
No email
send info
I do agree with Adrian's discuss as far as normative references go.

(Richard Barnes) No Objection

(Benoît Claise) No Objection

(Spencer Dawkins) (was Discuss) No Objection

(Stephen Farrell) No Objection

Comment (2015-03-10 for -02)
No email
send info
- I assume only copy editing changes will happen
to rssac001 between now and publication. If not then,
I'm confused.

- I'm not sure whether anycast ought be a protocol or a
service requirement. For now it's only in the rssac doc
but is that right? (I can buy that it's good enough.)

- I like E.3.1-B in the rssac doc, that should calm any
worries I'd have thought. (Maybe we should thank them?)

(Joel Jaeggli) No Objection

Barry Leiba (was Discuss) No Objection

Comment (2015-03-05 for -02)
No email
send info
-- Section 3 --

   The root name service:

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

During discussion, Liman agreed that it might be good to add "subject to operational considerations", or something like that.  That sounds like a wise and useful addition.  Thanks for discussing it with me.

(Ted Lemon) No Objection

(Kathleen Moriarty) No Objection

Comment (2015-03-09 for -02)
No email
send info
Thanks for your work on this draft.  I agree with the other suggestions made by Barry, Pete, & Adrian.

The SecDir review mentions the need for a privacy discussion, but I don't think this draft is the right place for that as it really should be in the referenced drafts for each of the stated requirements (IMO).  If they get updated, it would be good to add those as appropriate for each of the drafts.

(Martin Stiemerling) No Objection