Re: I-D ACTION:draft-ietf-dnsext-dnssec-trans-02.txt
Roy Arends <roy@dnss.ec> Tue, 29 November 2005 10:08 UTC
From: Roy Arends <roy@dnss.ec>
Subject: Re: I-D ACTION:draft-ietf-dnsext-dnssec-trans-02.txt
Date: Tue, 29 Nov 2005 11:08:11 +0100
Lines: 71
References: <200502242137.j1OLbqU02800@grimsvotn.TechFak.Uni-Bielefeld.DE> <Pine.GSO.4.55.0502281512240.861@filbert> <Pine.GSO.4.55.0511241958400.24204@filbert>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-From: owner-namedroppers@ops.ietf.org Tue Nov 29 12:17:59 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=AWL,BAYES_00 autolearn=ham version=3.1.0
X-X-Sender: roy@trinitario.schlyter.se
To: IETF DNSEXT WG <namedroppers@ops.ietf.org>
In-Reply-To: <Pine.GSO.4.55.0511241958400.24204@filbert>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
X-Message-ID:
Message-ID: <20140418072115.2560.84903.ARCHIVE@ietfa.amsl.com>
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 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/>
- I-D ACTION:draft-ietf-dnsext-dnssec-trans-02.txt Internet-Drafts
- Re: I-D ACTION:draft-ietf-dnsext-dnssec-trans-02.… Peter Koch
- Re: I-D ACTION:draft-ietf-dnsext-dnssec-trans-02.… Samuel Weiler
- Re: I-D ACTION:draft-ietf-dnsext-dnssec-trans-02.… Samuel Weiler
- Re: I-D ACTION:draft-ietf-dnsext-dnssec-trans-02.… Roy Arends