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

[Roy Arends <[e-mail]>]

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

On Thu, 24 Nov 2005, Samuel Weiler wrote:

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

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.

> Numerous editorial comments have been sent to the editors.  Here are
> 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
> 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.

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

> ----
>
> 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".

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

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

agree.

Roy

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