Subject: Milestone reached: draft-ietf-dnsext-rfc2538bis-03

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 13 Jun 2005 16:24:03 +0200

Dear Colleagues,

Today we submitted a request for publications of
draft-ietf-dnsext-rfc2538bis-03 to the IESG (included for archival
purposes below).

We, and I am sure I speak for the WG as a whole, would like to
acknowledge Simon for the thorough job he did on editing the document.

Thanks for a job well done!

-- Olaf and Olafur

-- 
> Dear Margaret,
>
>
> Hereby a request to publish the following document.
>
> Title		: Storing Certificates in the Domain Name System (DNS)
> Author(s)	: S. Josefsson
> Filename	: draft-ietf-dnsext-rfc2538bis-03.txt
> Pages		: 14
> Date		: 2005-6-10
>
> It the intention to be "recycle" RFC2538 as proposed standard.
>
>
> Below is the questionaire, please contact me if there are any
> remaining questions.
>
> 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?
>
> The shepherding chair has reviewed the document. And believes the
> document is ready for IESG submission.
>
>
> 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?
>
>
> The editor has solicited feedback from the openPGP working group and
> from the PKIX WG. 
> See:
>    http://thread.gmane.org/gmane.ietf.openpgp/5458
>    http://thread.gmane.org/gmane.ietf.x509/21349
>
> Some feedback was received. 
>
>
> 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.)?
>
> I cannot assess if the review by the above mentioned groups has been
> thorough enough. On the other hand I do not have the concern that the
> document needs more 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.
>
>
> During the last call it was noted that the IANA registry for DNSSEC
> algorithm identifiers does not have an "applicability column" for CERT
> RRs. The editor claims that "experience is that the key tag and
> algorithm fields of CERT RRs are rarely useful, nor consistently
> populated.". After explicitly asking the list if not adding an
> applicability column to the IANA registry would cause interoperability
> issues (and not getting confirmation that it would) we decided to not
> address this issue in the document.
>
> See:
> http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00633.html,
> which is the seminal message in the thread about this issue.
>
> (In the same thread there was another issue about the IANA
> considerations too but that has been addressed.)
>
> 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?
>
> Only a few individuals participated in the discussion. 
>
> (How does one define "the WG as a whole"?)
>
> 6) Has anyone threatened an appeal or otherwise indicated extreme
>     discontent?  If so, please summarize what are they upset about.
>
> No. The document is not contentious.
>
> 7) Have the chairs verified that the document adheres to _all_ of the
>     ID nits?  (see http://www.ietf.org/ID-nits.html).
>
> idnits 1.69 (09 Apr 2005) does not complain.
> I checked the content issues of ID-Checklist revision 1.2
>
>
> On specific IPR (Checklist item 3.4): 
>
>   The editor has added in Appendix A a section of the copying
>   conditions as granted by the author. As far as I understand these
>   extend the standard copyright statement. I do not see these as
>   contentious but I am not sure if they need to be reviewed elsewhere
>   in the process.
>
>
> On the example addresses (Checklist item 3.6): 
>
>   In section 3.1 example 2 an address in RFC1918 space is used instead
>   of an address from RFC3330. Also other domain names than
>   "example.com" and relatives were used. This is because this example
>   is a verbatim copy from RFC2538.
>  
>   To maintain as much consistency between this document and 2538 it
>   was chosen not to change these examples.
>
>
> 8) For Standards Track and BCP documents, the IESG approval
>     announcement includes a writeup section with the following
>     sections:
>
>     - Technical Summary
>     - Working Group Summary
>     - Protocol Quality
>
>
> Technical Summary.
>
> This document describes how to store cryptographic public keys in RR
> records.  It updates RFC2538 by clarifying the format and handling of
> OpenPGP public keys, clarifying representation issues, aligning the
> document with DNSSECbis terminology and clarifying how owner names need
> to be (re)constructed for specific types of public keys.
>
> Working group summary.
>   
> See above.
>
> For IESG review it may be useful to know that the document Editor
> clearly documented the editorial history of the document on:
> http://josefsson.org/rfc2538bis/
>
>
> Protocol Quality.
>
> RFC2538 has been implemented. Some of the problems discovered during
> implementation of RFC2538 have been addressed in this document.
>
> It was the intention of the working group to also supply an
> interoperability report so that this document could advance RFC2538 up
> the standards track. Unfortunately the WG could not draft volunteers.
>
> It is the intention that this document updates 2538 and that the
> specification remains at proposed standard.
>
>
--end--

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