Subject: Publication request draft-ietf-dnsext-2929bis-04.txt

From: Ólafur Guðmundsson /DNSEXT co-chair <[email-masked]>
Date: Wed, 17 Jan 2007 12:11:39 -0500

Mark,

This is a request to publish the document as BCP it obsoletes
RFC2929/BCP 42.

Title		: Domain Name System (DNS) IANA Considerations
Author(s)	: Donald E. Eastlake 3rd
Filename	: draft-ietf-dnsext-2929bis-04.txt
Date		: January 17 2006
Document shepherd: Olafur Gudmundsson [email-masked]

1) Have the chairs personally reviewed this version of the ID and do
     they believe this ID is sufficiently baked to forward to the IESG
     for publication?

There are no nits according to idnits 1.121 (via tools.ietf.org).
As this is a a replacement to an existing RFC where only some sections
have changed. The biggest change is in relaxing the rules for
allocation of new RR types. To test this new process DNSEXT is running
an experiment of this process. The result of the experiment is expected
before the IESG will process this document.

2) Has the document had adequate review from both key WG members and
     key non-WG members? Do you have any concerns about the depth or
     breadth of the reviews that have been performed?

Yes during last-call this document has been reviewed in depth by (at
least) the following people.
-----------------

2) Has the document had adequate review from both key WG members and
     key non-WG members? Do you have any concerns about the depth or
     breadth of the reviews that have been performed?

Yes during last-call this document has been reviewed in depth by (at
least) the following people.

     Peter Koch
     http://psg.com/lists/namedroppers/namedroppers.2006/msg00972.html

     Scott Rose
     http://psg.com/lists/namedroppers/namedroppers.2006/msg00973.html

     Thierry Moreau
     http://psg.com/lists/namedroppers/namedroppers.2006/msg00973.html

     Måns Nilsson
     http://psg.com/lists/namedroppers/namedroppers.2006/msg01041.html

     Sam Weiler (multiple postings)
     Thomas Narten (multiple postings)

Following people made comments on the document during the last call
without explicitly stating support or not.
    Simon Josefsson
    Edward Lewis
    Bill Manning

There is rough consensus to advance the document.

3) Do you have concerns that the document needs more review from a
     particular (broader) perspective (e.g., security, operational
     complexity, someone familiar with AAA, etc.)?

We think this document has had sufficient review.

4) Do you have any specific concerns/issues with this document that
     you believe the ADs and/or IESG should be aware of? For example,
     perhaps you are uncomfortable with certain parts of the document,
     or whether there really is a need for it, etc., but at the same
     time these issues have been discussed in the WG and the WG has
     indicated it wishes to advance the document anyway.

There are no issues that are decisive in this document, there was
some undercurrent that the document was overly bureaucratic and
division of number spaces where there has been no demand is an
overkill. In the chairs opinion these are natural disagreements on
what is best in a world where people have differences of opinion on
how processes should work. This does not change the fact there is
consensus this document is an improvement over its predecessor and
should be advanced in current form.

5) How solid is the WG consensus behind this document?  Does it
     represent the strong concurrence of a few individuals, with others
     being silent, or does the WG as a whole understand and agree with
     it?

The consensus is strong, on the document as whole, less strong on
certain sections.

6) Has anyone threatened an appeal or otherwise indicated extreme
     discontent?  If so, please summarize what are they upset about.

No one has threatened an appeal.

7) Have the chairs verified that the document adheres to _all_ of the
     ID nits?  (see http://www.ietf.org/ID-nits.html).

Yes.

8) For Standards Track and BCP documents, the IESG approval
     announcement includes a write up section with the following
     sections:

     - Technical Summary

     The document updates rules for how certain DNS parameter values
     are allocated. In most cases this is a relaxation of the existing
     rules. The document is giving guidance to IANA on policies for
     allocation. The DNS community wants to simplify the rules for
     allocation of new RR types, and this document combined with the
     rules in RFC3597 makes this possible. For RR types that fit within
     the rules a simple template and review by WG and a designated
     expert is the new process. Most other changes from RFC2929 are
     insignificant.

     - Working Group Summary

     There is a broad consensus that this document is an improvement
     over its predecessor.

     - Protocol Quality

     This is document about IETF/IANA process so there are no
     implementations. The working group and sponsoring AD are running an
     experiment of the new RR type process concurrently with the
     publication request. see:
       http://psg.com/lists/namedroppers/namedroppers.2006/msg01601.html
       http://psg.com/lists/namedroppers/namedroppers.2006/msg01603.html
       http://psg.com/lists/namedroppers/namedroppers.2007/msg00068.html
       http://psg.com/lists/namedroppers/namedroppers.2007/msg00070.html

       Olafur

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