Clarifications and Implementation Notes for DNS Security (DNSSEC)
draft-ietf-dnsext-dnssec-bis-updates-20

Substantive comments; these are non-blocking, but please consider them
seriously, and feel free to chat with me about them:

Ditto Sean's comments about DNSSEC vs DNSSECbis, and about Draft Standard -> Internet Standard.

-- 2.1 --
   signal that a zone MAY be using NSEC3, rather than NSEC.

This MAY and the one in the following paragraph are misused: they should not be 2119 terms.  Describing what a zone "may be using" is simply a descriptive phrase, not anything normative.  Actually, I would say "might be using".

-- 5.2 --
Isn't the point really more general: that if the validator is unable to validate the signature, *for whatever reason*, it treats the zone as unsigned?  Wouldn't it be better to make that general point clear... and then give unknown or unsupported key or message digest algorithms as reasons it would be unable to validate?

========
Other comments; no need to respond to these. Take them or modify them
as you please:

-- 2 --
There's a SSnake in the graSSS in the SSection title.

Is there a reference that could be added to section 3.1 to where the scaling concerns called out there are discussed?

These are my preliminary sets of comments:

1) Any reason you can't just refer to DNSSECbis as DNSSEC?  I guess does the outside world know DNSSECbis isn't DNSSEC?

2) General: r/RFCXXXX/[RFCXXXX] throughout except for the abstract.  A couple of times I thought the RFC references needed to be included in [] so it's probably better to just do it everywhere.  You also need to add [RFC2308] as a reference.

3) s1 paragraph two: RFC 6410 got rid of Draft Standard so either r/Draft/Internet or r/from Proposed Standard to Draft Standard/along the Internet Standards track.    Or something like that.

4) s1.2: To cut down on the possible "where is X defined" you could add something like: "Readers are assumed to be familiar with DNSSECbis documents as the terminology used herein comes from those documents."

5) s2, s2.1, s2.2: Could you replace the three instances of "should {also} be" with "are"?  If the WG considers them part of the core, then aren't they?  It also avoids the whole question about whether it ought to be SHOULD (not that I'm asking to change that).

6) s2.1: Pet peeve requirements in a paragraph that starts with Note.  Couldn't you just r/Note that the/The

7) s5.5: Might be worth pointing out that this was filed as an errata.

8) s5.6, s5.7, and s5.10: I was already to give you the kudos for each section being clear about which document was being updated until I got to these sections.  Please state which RFC you're updating in these sections.  In s5.6 is it updating 3225?

9) s5.11: could you just strike "note that"

During the "no answer" mega-discussion on the DANE list, [1] I
seem to recall this comment was made more than once: "you're
seeing all this because you're maybe the first new
application that really needs DNSSEC," or words to that
effect. Should any of that discussion be reflected in this
document? (I assume its not already there for timing reasons
if nothing else.)

   [1] http://www.ietf.org/mail-archive/web/dane/current/msg04845.html