Subject: [dane] Publication requested for draft-ietf-dane-protocol-18

From: Warren Kumari <[email-masked]>
Date: Mon, 12 Mar 2012 14:47:00 -0600

This is a publication request for http://tools.ietf.org/html/draft-ietf-dane-protocol-18

Attached please find the Document Shepherd writeup.

--------------------------------
(1) What type of RFC is being requested...

  This document is requested to be published as Proposed Standard.
  The title page header identifies: "Intended status: Standards Track".
  The description in RFC 2026 Section 4.1.1 (Proposed Standard) covers
  this draft, and so it is the correct "type".

(2) The IESG approval announcement includes a Document Announcement
Write-Up...

Technical Summary

  Encrypted communication on the Internet often uses Transport Level
  Security (TLS), which depends on third parties to certify the keys
   used.  This document improves on that situation by enabling the
   administrator of a domain name to publish the keys used in the 
   DNS, secured with DNSSEC.

Working Group Summary

  The working group made extensive use of the issue tracker: 
  listing, opening, discussing and then calling consensus on
  each issue. This gave everyone the opportunity to participate
  and be heard. There have been approximately 2,000 messages 
  discussing this (and closely related) documents.

Document Quality

  There is a tool (Swede - https://github.com/pieterlexis/swede)
  that generates TLSA records, and a proof-of-concept implementation
  of DANE for NSS (https://mattmccutchen.net/cryptid/#nss-dane).
  A number of vendors have mentioned that they are planning on 
  implementing the specification.

  I do not think that it would be fair (or possible) to single
  out any specific reviewers -- we have had a large number of very
  active reviewers / participants and they have all been very diligent
  (and sometimes vocal :-)) in providing feedback.

Personnel

  Warren Kumari is acting as the Document Shepherd. 
  Stephen Farrell is the  Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The Document Shepherd is also one of the WG Co-chairs, and has been
  involved in reviewing, calling consensus, etc. He has reviewed the
  document and believes that it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

  No. This document has received lots of review. We have been
  fortunate in having folk from many other working groups participating,
  and believe that we are good for both breadth and depth.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

   This document requests a new DNS RR type (TLSA). A
   request for expert review for the RRTYPE has been submitted.
   http://www.ietf.org/mail-archive/web/dnsext/current/msg12303.html

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? 

None.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes -- authors have been polled and state that they have no IPR to
disclose.
   
(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosures have been filed (yay!).

(9) 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?  

In the chairs opinion there is strong to very strong consensus. As
with any complex document that has had a lot of discussion, a number of
folk have points that they are not 100% happy with. These points don't 
overlap very much though.

(10) Has anyone threatened an appeal or otherwise indicated extreme 
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.) 

(11) Identify any ID nits the Document Shepherd has found in this
document...

ID Nits found 1 nit:
Missing Reference: 'This' is mentioned on line 654, but not defined

This is *not* an issue, it is simply a reference to this document (but
mentioned for completeness).

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

It meets the requirements by not having any!

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement...

No.

(15) Are there downward normative references references...

No.

(16) Will publication of this document change the status of any
existing RFCs?

No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, ...

The document creates 3 new registries. They clearly state the
requirements to get an allocation, contain a clear list of the current
allocations, and have reasonable names.

(18) List any new IANA registries that require Expert Review...

None.

(19) No formal language.

---------------------------------------------------

--
Don't be impressed with unintelligible stuff said condescendingly.
    -- Radia Perlman.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 12 Mar 2012 20:58:15 +0000

Thanks folks, I'll do the AD-review thing in the next few days.
S