Subject: Re: I-D ACTION:draft-ietf-dnsext-dnssec-trans-02.txt

From: Samuel Weiler <[email-masked]>
Date: Thu, 24 Nov 2005 20:15:52 -0500 (EST)

I've partially reviewed trans-03.  I don't think the doc is ready for
WGLC.

Overall recommendation: I have concerns about the wisdom of a partial
typecode rollover (especially of DS, with it's oh-so-funky
only-RR-not-in-the-child semantics), which is what this doc
recommends.  I'm OK with pushing this doc forward as a historical
record, but it needs to be clearly noted (in the abstract, intro, and
section 3) that the recommendation was current as of date XXX (~1 year
ago), not the date of publication.

Numerous editorial comments have been sent to the editors.  Here are
some slightly more substantive ones:

----

2.2.3

I don't necessarily assume that the NSEC RR type won't change -- I
think algorithm number signaling might be used with or without a RR
type code change.  Perhaps that means we should duplicate this
section.  Or just suggest that these signaling mechanisms might be
mixed-and-matched.

----

2.2.3.2 and 2.2.4.2

As I wrote in February, I see no need to split the algorithm number or
digest algorithm number space -- we could specifcy NSEC v. NSEC3 on a
per-number basis rather than saying "numbers above X are for NSEC3".

On Mon, 28 Feb 2005, Samuel Weiler wrote:

> I also noticed that 2.2.3.2 suggests splitting the algorithm space
> with each version of DNSSEC.  As David Blacka's experiments draft
> suggests, there might be more efficient ways to do this, and blindly
> allocating half of the algorithm numbers at each versioning sounds
> very limiting.

-- Sam

--
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/>

---

From: Roy Arends <[email-masked]>
Date: Tue, 29 Nov 2005 11:08:11 +0100 (CET)

disclaimer: I'm one of the authors of this draft and of the nsec3-draft.

> ago), not the date of publication.

I agree. I do not see this document as standards track, more likely
informational. The recommendation is from the authors, not particular the
entire wg.

> some slightly more substantive ones:

Thanks for the editorial comments.

> ----
>
> 2.2.3
>
> I don't necessarily assume that the NSEC RR type won't change

Yes. I would assume the NSEC RR type stay the same and for an alternative
denial mechanism, use a new type, like NSEC3 (as an example), with a
different typecode and its own interpretation independent of the NSEC RR
type.

> -- I

Good point. Will think about this a little bit more.

> per-number basis rather than saying "numbers above X are for NSEC3".

Agreed, splitting space is costly. Per-number basis is more
straightforward.

> > allocating half of the algorithm numbers at each versioning sounds

agree.

Roy