Re: Section 4 of dnssec-protocol-03

Ólafur Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Mon, 03 November 2003 20:01 UTC

Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17859 for <dnsext-archive@lists.ietf.org>; Mon, 3 Nov 2003 15:01:56 -0500 (EST)
Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGknl-000Jbv-7Q for namedroppers-data@psg.com; Mon, 03 Nov 2003 19:55:49 +0000
Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGknX-000Jau-Ha for namedroppers@ops.ietf.org; Mon, 03 Nov 2003 19:55:35 +0000
Received: from ENGILL.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id hA3JrDuG096351; Mon, 3 Nov 2003 14:53:14 -0500 (EST) (envelope-from ogud@ogud.com)
Message-Id: <6.0.0.22.2.20031103144117.0296c7b0@localhost>
X-Sender: (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22
Date: Mon, 03 Nov 2003 14:55:19 -0500
To: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org
From: Ólafur Gudmundsson/DNSEXT co-chair <ogud@ogud.com>
Subject: Re: Section 4 of dnssec-protocol-03
In-Reply-To: <20031103180713.85D3F1394B@sa.vix.com>
References: <20031103180713.85D3F1394B@sa.vix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

<speaking as co-chair>

At 13:07 2003-11-03, Paul Vixie wrote:
> > > ... thing i heard from -editors was that it was all about clarifying
> > > 2535.  apparently then, rolling up TCR et al will come later?
> >
> > Forward (and backward) reference:
> >
> >   From: Ólafur Gudmundsson/DNSEXT co-chair <ogud@ogud.com>
> >   To: namedroppers@ops.ietf.org
> >   Subject: DNSSEC editing process (Periodic posting)
> >   Date: Fri, 31 Oct 2003 20:23:11 -0500
> >
> >   "The DNSEXT working group has started a rewrite of the DNSSEC
> >    specification into a documents that better reflect the protocol
> >    and allow a test plan to be constructed from the specification.
>
>in other words it should include TCR and anything else that's changed
>the protocol in the post-2535 era?

Yes.

> >   (...)
> >   If clarifications are needed due to conflicting definitions,
> >   imprecise specification, omission or other reason, the editors MUST
> >   bring these issues to the attention of the working group on the
> >   namedroppers mailing list.
> >   (...)
> >   "
>
>does passing WGLC meet the standard for "bring to the working group"?
>if so, then dnssec-bis will have to be fully inclusive of all post-2535
>work, and as far as i know, it is not as of this time.

In most cases publication request by chair is the trigger for editors to
incorporate the work. In some cases chairs have instructed editors to
wait for the IESG before making changes, this happened with the clarification
of the AD bit (now or soon to be RFC3655)
Another exception is if the WG shows strong preference to change the
format (not semantic content) of NSEC, chairs may ask the AD for
permission to allow the DNSSEC-records document make that change.

> > We need closure on the document set so let us not revisit issues that
> > have been fixed through the submission and acceptance of drafts that
> > where needed to clarify the specs.
> >
> > On the other hand, do bring issues to the list. It is a sign of
> > thourough review. If an issue has been covered we have the archives
> > and/or the specs to point to.
>
>i guess we've been asking the wrong question so let me start over.
>
>is dnssec-bis supposed to be fully inclusive of all post-2535 work, such
>that an implementor can just read that one doc set, or is it just a
>clarification of 2535, and an implementor will have to read dnssec-bis
>PLUS every post-2535 document?

Yes, reading the DNSSECbis set is supposed to be sufficient.
In the case of implementor has a question about why certain choices where
made she/he may need to check some of the older documents.
Example: for insertion of NSEC records in wildcard cases reading the
wildcard-clarify might be a good idea.

>the answer to this will radically influence the document review process.

Yes it will affect the review.
Please bring up any issues with the document not being a complete
replacement for one or more of the RFC's/ID's that update RFC2535 and
thus form the bases for DNSSEC version 3.

Hope this helps, sorry for any misunderstanding chairs may have
caused on this issue.

         Olafur (DNSEXT co-chair) 


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