I have been selected as the Applications Area Directorate reviewer 
for this draft (for background on AppsDir, please see 
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

The comments in this review do not bear more weight than comments 
submitted by an individual during a Last Call.  It is suggested that 
the author asks the document shepherd for guidance about any changes 
suggested in a review.

Document: draft-ietf-dnsext-dnssec-bis-updates-18
Title: Clarifications and Implementation Notes for DNSSECbis
Reviewer: S. Moonesamy
Review Date: May 22, 2012
IETF Last Call Date: May 17, 2012

Summary: This document is not ready for publication as a Proposed Standard.

The proposal is a collection of technical clarifications to the 
DNSSECbis document set. DNSSEC is useful for application-related 
specifications which perform service location.  The proposal does not 
directly affect any application-related specification.

The proposal seems targeted at implementers who are fully conversant 
with the ins and outs of DNSSEC.  Although the proposal is 
well-written, it lacks clarity as to what is being changed in the 
"DNSSECbis document set".  It may end up being more confusing.

There was an announcement that the DNSEXT WG would be shut down.  The 
rush to publish these clarifications raises questions about whether 
the DNSSECbis documents will ever be advanced in the near future from 
Proposed Standard to Internet Standard.

I erred on the side of caution in making the publication 
recommendation especially as the Security Considerations Section 
mentions that the validation algorithm clarifications in Section 4 
are critical for preserving the security properties DNSSEC offers.

Minor issues:

In the Abstract Section:

   "This document is a collection of technical clarifications to the
    DNSSECbis document set.  It is meant to serve as a resource to
    implementors as well as a repository of DNSSECbis errata."

"DNSSECbis" seems more like an internal IETF term to identify the 
document set.  RFC 4033, for example, does not have any mention of 
"DNSSECbis".  I suggest using "DNSSEC protocol document set" and 
amending the title accordingly.

In the Introduction Section:

   "This document lists some additions, clarifications and corrections to
    the core DNSSECbis specification".

See above comment.

In Section 2.1:

   "Note that the algorithm identifiers defined in RFC5155 (DSA-NSEC3-
    SHA1 and RSASHA1-NSEC3-SHA1) and RFC5702 (RSASHA256 and RSASHA512)
    signal that a zone MAY be using NSEC3, rather than NSEC.  The zone
    MAY be using either and validators supporting these algorithms MUST
    support both NSEC3 and NSEC responses."

It is not clear from the above text which parts of RFC 5155 is being 
modified.

In Section 3.1:

   "Section 4.7 of RFC4035 permits security-aware resolvers to implement
    a BAD cache.  Because of scaling concerns not discussed in this
    document, that guidance has changed: security-aware resolvers SHOULD
    implement a BAD cache as described in RFC4035."

 From Section 4.7 of RFC 4035:

   "To prevent such unnecessary DNS traffic, security-aware resolvers MAY
    cache data with invalid signatures, with some restrictions."

If I understood the text from this draft, the "MAY" is being changed 
into a recommendation.  In which cases would it better not to follow 
the recommendation?

In Section 4.1:

   "In particular, the algorithm as presented would incorrectly allow
    an NSEC or NSEC3 RR from an ancestor zone to prove the non-existence
    of RRs in the child zone."

Where is ancestor zone defined?

   "Ancestor delegation NSEC or NSEC3 RRs MUST NOT be used to assume non-
    existence of any RRs below that zone cut, which include all RRs at
    that (original) owner name other than DS RRs, and all RRs below that
    owner name regardless of type."

It is not clear what is being clarified.

Nits:

In the Introduction Section:

The IETF is now using two maturity levels. "Draft Standard" has been 
changed to "Internet Standard"

In Section 6.3:

This section discusses about errors in the examples in RFC 4035.  As 
a stylistic comment, it is clearer to the reader if he/she could see 
the actual examples with the corrections made.

Regards,
S. Moonesamy