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

Samuel Weiler <weiler@tislabs.com> Fri, 25 November 2005 01:15 UTC

From: Samuel Weiler <weiler@tislabs.com>
Subject: Re: I-D ACTION:draft-ietf-dnsext-dnssec-trans-02.txt
Date: Thu, 24 Nov 2005 20:15:52 -0500
Lines: 47
References: <200502242137.j1OLbqU02800@grimsvotn.TechFak.Uni-Bielefeld.DE> <Pine.GSO.4.55.0502281512240.861@filbert>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Cc: IETF DNSEXT WG <namedroppers@ops.ietf.org>
X-From: owner-namedroppers@ops.ietf.org Fri Nov 25 02:28:07 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level:
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0
X-X-Sender: weiler@filbert
To: Peter Koch <pk@TechFak.Uni-Bielefeld.DE>
In-Reply-To: <Pine.GSO.4.55.0502281512240.861@filbert>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
X-Message-ID:
Message-ID: <20140418072112.2560.57241.ARCHIVE@ietfa.amsl.com>

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 namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>