Re: WGLC: draft-ietf-dnsext-nsec3-09

[Matt Larson <[e-mail]>]

On Wed, 10 Jan 2007, Olaf Kolkman wrote:
> Please review the draft and put that fact on record through a post to
> the mailing-list.

I have (re-)read the draft and after a thorough review, I support its
going foward.

I have only minor comments relating to wording clarity, which are
below.

Matt


> 6.  Opt-Out
> 
> [...]
>    An Opt-Out NSEC3 record is said to cover a delegation if the hash of
>    the delegation's Next Closer Name to its closest provable encloser is
>    between the NSEC3 ownername and next hashed ownername.

I had some difficulty parsing this sentence.  Once I figured out its
meaning, I determined the cause of my trouble was the use of the word
"hash" followed by the word "to" in a sense that did not refer to the
output of the hash algorithm: "to" here does not refer to what
something "hashes to".  I believe a minor reordering of the sentence
might help comprehension:

     An Opt-Out NSEC3 record is said to cover a delegation if the hash
     of the Next Closer Name of its closest provable encloser of the
     delegation is between the NSEC3 ownername and next hashed
     ownername.

But maybe I'm the only one with a problem here, which is entirely
possible.

>    An Opt-Out NSEC3 record MAY have the same original owner name as an
>    insecure delegation.  In this case, the delegation is proven insecure
>    by the lack of a DS bit in type map and the signed NSEC3 record does
                               ^ the
>    assert the existence of the delegation.

I know the word MAY appears in big letters here, but would it be worth
a clarification sentence explaining that NSEC3 records at insecure
delegations are not necessary in Opt-Out zones and that if one's
purpose for using Opt-Out is to reduce zone size, this case is
expected to be unusual?  I'm just thinking of a signer implementor
coming along in a few years who's not steeped in the material as we
all are and trying to figure things out from the RFC as a starting
point.

> 7.2.2.  Name Error Responses
> 
>    To prove the nonexistence of QNAME a closest encloser proof and an
>    NSEC3 RRset covering the wildcard record at the closest encloser MUST
                             ^ (nonexistent)
>    be included in the response.

I think adding "(nonexistent)" increases clarity.

> 7.2.7.  Referrals to Unsigned Subzones
> 
> [...]
>    If the zone in Opt-Out, then there may not be an NSEC3 record

s/in/is

> 7.5.  Dynamic Update
> 
>    A zone signed using NSEC3 may accept dynamic updates.  [...]

Should there be an informative reference to RFC 2136 here?

> 8.1.  Responses with Unknown Hash Types
> 
>    A validator MUST ignore NSEC3 records with unknown hash types.  The
>    practical result of this is that responses containing such NSEC3
                                                          ^ only
>    records will generally be considered bogus.

If a response contains a combination of NSEC3 records with known and
unknown hash types, the validator ignores the ones with unknown types
and can proceed using the ones with known types, right?  If so, adding
"only" above helps make that more clear.

> 8.3.  Closest Encloser Proof
> 
> [...]
>    3.  Truncate SNAME by one label, go to step 2.
> 
>    Once the closest encloser has been discovered, the validator MUST
>    check that the NSEC3 that has the closest encloser as an ownername is
                                                             ^ original
>    from the proper zone.

I think adding "original" increases clarity.

> 8.5.  Validating No Data Responses, QTYPE is not DS
> 
>    The validator MUST verify that an NSEC3 RR that matches QNAME is
>    present and that both the QTYPE and the CNAME type are not set in its
>    Type Bit Maps field.
> 
>    Note that this test also covers the case where the NSEC3 record
>    exists because it corresponds to an empty non-terminal, in which case
>    the NSEC3 will usually have an empty Type Bit Maps field.

Why "usually" and not "always"?  Won't an empty non-terminal's NSEC3
always have an empty Type Bit Maps field?

> 10.1.  Domain Name Length Restrictions
> 
>    Zones signed using this specification have additional domain name
>    length restrictions imposed upon them.  In particular, zone with
                                                                ^ s
>    names that, when converted into hashed ownernames, exceed the 255
>    octet length limit imposed by RFC 1035 [3].

i.e., s/zone/zones

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>