Subject: Re: NSEC2 01

From: Samuel Weiler <[email-masked]>
Date: Tue, 27 Jul 2004 10:53:19 -0400 (EDT)

General comments on the doc:

I'd like to see a higher-level discussion of the fundamental changes
being made here: in particular, I was confused by the first sentence
of Section 2:
      "The NSEC2 resource record lists ...: the SHA-1 hash
      of the owner name of the next RRset in the canonical ordering
      of the zone."
This does not make it clear that you're discarding all sense of
canonical ordering EXCEPT of the NSEC2 records, and that the NSEC2
ordering is based on the canonical order of the hashed name, not the
actual owner name

I see no discussion saying that hash algorithm, salt, and iterations
are zone properties.  The document needs to describe how to change
these, and if the only method is to make the zone insecure for an
interval, that limitation needs to be explained.

Section 4 still mentions NSECINFO.  The doc should probably explain
why a validator will always know what hash, salt, etc. to use and why
NSECINFO or extra NSEC2 queries aren't needed.  That discussion should
consider that a validator does not always know what zone an answer is
in (see the DS grandparent problem).

I'm not convinced that the wildcard discussion/example is correct.
Perhaps Ed Lewis or Bob Halley can comment?

Nits:

The example in 2.4 looks wrong: wouldn't the NSEC2 chain have to
contain the example.com zone apex, too?

The IANA section is woefully inadequate, but this can be fixed later.
Can we reuse the hash registry from DS, or do we really need a new
one?

The date header needs to be updated, except on the first page.

The first citation can be updated to RFC3755.

Section 2.1.3, paragraph on domain name compression: Section 4 of
RFC3597 recommends that this text remain.  Perhaps cite 3597.

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