SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)
draft-ietf-dane-smtp-with-dane-19

[Ballot comment]
Thanks for this. I only have a few trivial comments:

2.1.3, first paragraph:

The seems redundant to similar normative language in 2.1.1

2.1.3, last paragraph: "...it may need to issue a
  separate query..."

I assume that means it also may _not_ need to do so. Is it worth elaborating on that case?

Editorial:

2.3.3, first sentence: This is pretty convoluted. You might consider breaking it into a few simpler sentences.

[Ballot comment]
References and terminology:
You use RFC 1034 to define "RR", and RFC 5598 to define "MSA", "MTA", and "MUA".  And these are definitions that must be understood in order to properly understand this document.  I think that makes those normative references, not informative ones, and they should be changed.  (5598 is already in the downref registry, so,there's no problem with the downref here.)

>> Author will move the references.


In Section 2.2.1:

   When DANE TLS is mandatory (Section 6) for
   a given destination, delivery MUST be delayed when the MX RRSet is
   not "secure".

This contradicts the "delivery MAY proceed" in the previous paragraph (and it also doesn't really fit into the paragraph about logging anyway).  If you want to restrict things, I think you should put the most restrictive condition first, so move this sentence to the top of the previous paragraph.

>> Author will make this change:

OLD
  If the MX RRSet (or any CNAME leading to it) is "insecure" (see
  Section 2.1.1), DANE TLS need not apply, and delivery MAY proceed via
  pre-DANE opportunistic TLS.
NEW
   If the MX RRSet (or any CNAME leading to it) is "insecure" (see
   Section 2.1.1), then if DANE TLS is mandatory (Section 6) for
   the given destination, delivery MUST be delayed.  If DANE TLS
   is not mandatory, then DANE does not apply and delivery proceeds
   with pre-DANE opportunistic TLS (perhaps even in cleartext).
END

-- Section 2.2 --

   contrast, DNSSEC validated TLSA records MUST NOT be published for
   servers that do not support TLS.  Clients can safely interpret their
   presence as a commitment by the server operator to implement TLS and
   STARTTLS.

I don't know that this needs any text changes, though perhaps a mention of this in the Security Considerations would be good: I'm not sure how "safely" they will be able to do that in practice.  Remember that the people running the email severs often have no connection to the people who will insert or remove the TLSA records from the DNS.  It's possible that a software change in the mail servers will remove support for DANE, and the TLSA record will not be correspondingly removed.

I'm hoping that once this really gets rolled out, that won't be a real issue, but it could be for a while.  It might be worth saying in the Security Considerations that such a situation needs to be avoided, and coordination is important, to make sure it doesn't happen.  Otherwise, according to Section 2.2, mail delivery from DANE-aware MTAs will fail.

>> Author will decide here -- probably not necessary to change anything: already sufficiently obvious.


>> Author agrees with all of the following, and will adjust the text appropriately:

-- Sections 2.2.1 and 2.2.2 --

In 2.2.1:
  In the absence of DNS lookup errors (Section 2.1.1), if the MX RRset
  is not "insecure" then it is "secure", and the SMTP client MUST treat
  each MX hostname as a separate non-MX destination for opportunistic
  DANE TLS (as described in Section 2.2.2).

In 2.2.2:
  This section describes the algorithm used to locate the TLSA records
  and associated TLSA base domain for an input domain that is not
  subject to MX resolution or that lacks MX records.

I find this combination unnecessarily confusing -- it starts to sound a bit like Fizzbin .  I know it's explained further (which is why this isn't a DISCUSS point), but I think clarity in the introduction would help a lot.  I suggest this, but anything similar would be equally helpful:

NEW
  In the absence of DNS lookup errors (Section 2.1.1), if the MX RRset
  is not "insecure" then it is "secure", and the SMTP client MUST treat
  each MX hostname as described in Section 2.2.2.
END

NEW
  This section describes the algorithm used to locate the TLSA records
  and associated TLSA base domain for an input domain that is not
  subject to MX resolution, that represents a hostname from a secure MX
  RRset, or that lacks MX records.
END

That latter ordering matches the order of the bullet list, and I think that's useful for making the text understandable.  You might also re-think the title for Section 2.2.2, but I think that's less important.

-- Section 2.2.3 --

  If the ultimate response is a "secure" TLSA RRSet, then the candidate
  TLSA base domain will be the actual TLSA base domain and the TLSA
  RRSet will constitute the TLSA records for the destination.  If none
  of the candidate TLSA base domains yield "secure" TLSA records then
  delivery MAY proceed via pre-DANE opportunistic TLS.  SMTP clients
  MAY elect to use "insecure" TLSA records to avoid STARTTLS downgrades
  or even to skip SMTP servers that fail authentication, but MUST NOT
  misrepresent authentication success as either a secure connection to
  the SMTP server or as a secure delivery to the intended next-hop
  domain.

When SMTP clients elect to use insecure TLSA records, this text implies, but doesn't make it completely clear, that they should only do that after checking all candidates.  It would be good to be clear: check all candidates, stopping at the first secure TLSA.  If no candidates produce secure TLSA, then you MAY use an insecure one, or you MAY use pre-DANE TLS.  Is that right?

In general, I strongly encourage you to review Section 2.2.3 and make sure that it reads smoothly to someone who's not already familiar with the DANE SMTP work.  I'm not sure the organization of the thoughts in this section is very good as it's currently written.

-- Section 3.1 --

  In summary, we RECOMMEND the use of either "DANE-EE(3) SPKI(1)
  SHA2-256(1)" or "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA records
  depending on site needs.

But later, in Section 3.1.1, you specifically single out the former:

  TLSA records published for SMTP servers SHOULD, in most cases, be
  "DANE-EE(3) SPKI(1) SHA2-256(1)" records.

To be more consistent in your advice, I suggest changing the advice in 3.1 thus:

NEW
  In summary, we RECOMMEND the use of "DANE-EE(3) SPKI(1)
  SHA2-256(1)", with "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA
  records as a second choice, depending on site needs. See
  the following two subsections for more details.
END

If that's not the advice you mean to give, then something is unclear.

-- Section 3.1.1 --

  Similarly, the expiration date of the server certificate MUST be
  ignored, the validity period of the TLSA record key binding is
  determined by the validity interval of the TLSA record DNSSEC
  signature.

Editorial: "Similarly" to what?  I'd remove the word.  Also, the comma after "ignored" needs to be a colon (or a semicolon, but I think a colon is better here; the comma splice is just wrong).

  With DANE-EE(3) servers need not employ SNI (may ignore the client's
  SNI message) even when the server is known under independent names

Editorial: This needs a comma after "DANE-EE(3)", and would do well with "they" before "may ignore").

-- Section 3.1.1 --

  Such servers MUST either publish DANE-TA(2)
  records for an intermediate certificate or MUST instead use DANE-
  EE(3) TLSA records.

The first "MUST" should be moved one word later, after "either" (or else the second "MUST" should be removed).

-- Section 3.1.3 --

  Note, this section applies to MTA-to-MTA SMTP on port 25.

Earlier, in 2.2.3, you note that "the destination TCP port is typically 25, but this may be different with custom routes specified by the MTA administrator".  I don't think you mean for this section not to apply in the latter case, so I suggest changing this to, "Note, this section applies to MTA-to-MTA SMTP, which is normally on port 25."

  Nothing is lost since the
  PKIX certificate usages cannot aid SMTP TLS security, they can only
  impede SMTP TLS interoperability.

Editorial: You need a comma after "lost", and the existing comma needs to be a semicolon.

The last paragraph of the section is missing a final period.

-- Section 6 --

  Administrators of mail servers that employ mandatory DANE TLS, need
  to carefully monitor their mail logs and queues.

Nit: the comma should be removed.

[Ballot discuss]
Nothing fundamental here; I just have three things I'd like to sort out before balloting "yes" on this, and they should all be easy to resolve:

1. References and terminology:
You use RFC 1034 to define "RR", and RFC 5598 to define "MSA", "MTA", and "MUA".  And these are definitions that must be understood in order to properly understand this document.  I think that makes those normative references, not informative ones, and they should be changed.  (5598 is already in the downref registry, so,there's no problem with the downref here.)

2. Section 2.2.1 says this:

   That said, the protocol in this memo is
   an "opportunistic security" protocol, meaning that it strives to
   communicate with each peer as securely as possible, while maintaining
   broad interoperability.  Therefore, the SMTP client MAY proceed to
   use DANE TLS (as described in Section 2.2.2 below) even with MX hosts
   obtained via an "insecure" MX RRSet.  For example, when a hosting
   provider has a signed DNS zone and publishes TLSA records for its
   SMTP servers, hosted domains that are not signed may still benefit
   from the provider's TLSA records.

That makes sense.  Why doesn't the same thing apply for insecure TLSA records?  Section 2.2 says that when TLSA records are insecure, you don't use them, and SHOULD use pre-DANE security.  Please explain why they shouldn't use insecure TLSA records for opportunistic encryption.

3. In Section 2.2.1:

   When DANE TLS is mandatory (Section 6) for
   a given destination, delivery MUST be delayed when the MX RRSet is
   not "secure".

This contradicts the "delivery MAY proceed" in the previous paragraph (and it also doesn't really fit into the paragraph about logging anyway).  If you want to restrict things, I think you should put the most restrictive condition first, so move this sentence to the top of the previous paragraph this way:

OLD
  If the MX RRSet (or any CNAME leading to it) is "insecure" (see
  Section 2.1.1), DANE TLS need not apply, and delivery MAY proceed via
  pre-DANE opportunistic TLS.
NEW
  If the MX RRSet (or any CNAME leading to it) is "insecure" (see
  Section 2.1.1), then if DANE TLS is mandatory (Section 6) for
  the given destination, delivery MUST be delayed.  If DANE TLS
  is not mandatory, then it need not apply, and delivery MAY proceed
  via pre-DANE opportunistic TLS.
END

[Ballot comment]
-- Section 2.2 --

   contrast, DNSSEC validated TLSA records MUST NOT be published for
   servers that do not support TLS.  Clients can safely interpret their
   presence as a commitment by the server operator to implement TLS and
   STARTTLS.

I don't know that this needs any text changes, though perhaps a mention of this in the Security Considerations would be good: I'm not sure how "safely" they will be able to do that in practice.  Remember that the people running the email severs often have no connection to the people who will insert or remove the TLSA records from the DNS.  It's possible that a software change in the mail servers will remove support for DANE, and the TLSA record will not be correspondingly removed.

I'm hoping that once this really gets rolled out, that won't be a real issue, but it could be for a while.  It might be worth saying in the Security Considerations that such a situation needs to be avoided, and coordination is important, to make sure it doesn't happen.  Otherwise, according to Section 2.2, mail delivery from DANE-aware MTAs will fail.

-- Sections 2.2.1 and 2.2.2 --

In 2.2.1:
  In the absence of DNS lookup errors (Section 2.1.1), if the MX RRset
  is not "insecure" then it is "secure", and the SMTP client MUST treat
  each MX hostname as a separate non-MX destination for opportunistic
  DANE TLS (as described in Section 2.2.2).

In 2.2.2:
  This section describes the algorithm used to locate the TLSA records
  and associated TLSA base domain for an input domain that is not
  subject to MX resolution or that lacks MX records.

I find this combination unnecessarily confusing -- it starts to sound a bit like Fizzbin .  I know it's explained further (which is why this isn't a DISCUSS point), but I think clarity in the introduction would help a lot.  I suggest this, but anything similar would be equally helpful:

NEW
  In the absence of DNS lookup errors (Section 2.1.1), if the MX RRset
  is not "insecure" then it is "secure", and the SMTP client MUST treat
  each MX hostname as described in Section 2.2.2.
END

NEW
  This section describes the algorithm used to locate the TLSA records
  and associated TLSA base domain for an input domain that is not
  subject to MX resolution, that represents a hostname from a secure MX
  RRset, or that lacks MX records.
END

That latter ordering matches the order of the bullet list, and I think that's useful for making the text understandable.  You might also re-think the title for Section 2.2.2, but I think that's less important.

-- Section 2.2.3 --

  If the ultimate response is a "secure" TLSA RRSet, then the candidate
  TLSA base domain will be the actual TLSA base domain and the TLSA
  RRSet will constitute the TLSA records for the destination.  If none
  of the candidate TLSA base domains yield "secure" TLSA records then
  delivery MAY proceed via pre-DANE opportunistic TLS.  SMTP clients
  MAY elect to use "insecure" TLSA records to avoid STARTTLS downgrades
  or even to skip SMTP servers that fail authentication, but MUST NOT
  misrepresent authentication success as either a secure connection to
  the SMTP server or as a secure delivery to the intended next-hop
  domain.

When SMTP clients elect to use insecure TLSA records, this text implies, but doesn't make it completely clear, that they should only do that after checking all candidates.  It would be good to be clear: check all candidates, stopping at the first secure TLSA.  If no candidates produce secure TLSA, then you MAY use an insecure one, or you MAY use pre-DANE TLS.  Is that right?

In general, I strongly encourage you to review Section 2.2.3 and make sure that it reads smoothly to someone who's not already familiar with the DANE SMTP work.  I'm not sure the organization of the thoughts in this section is very good as it's currently written.

-- Section 3.1 --

  In summary, we RECOMMEND the use of either "DANE-EE(3) SPKI(1)
  SHA2-256(1)" or "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA records
  depending on site needs.

But later, in Section 3.1.1, you specifically single out the former:

  TLSA records published for SMTP servers SHOULD, in most cases, be
  "DANE-EE(3) SPKI(1) SHA2-256(1)" records.

To be more consistent in your advice, I suggest changing the advice in 3.1 thus:

NEW
  In summary, we RECOMMEND the use of "DANE-EE(3) SPKI(1)
  SHA2-256(1)", with "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA
  records as a second choice, depending on site needs. See
  the following two subsections for more details.
END

If that's not the advice you mean to give, then something is unclear.

-- Section 3.1.1 --

  Similarly, the expiration date of the server certificate MUST be
  ignored, the validity period of the TLSA record key binding is
  determined by the validity interval of the TLSA record DNSSEC
  signature.

Editorial: "Similarly" to what?  I'd remove the word.  Also, the comma after "ignored" needs to be a colon (or a semicolon, but I think a colon is better here; the comma splice is just wrong).

  With DANE-EE(3) servers need not employ SNI (may ignore the client's
  SNI message) even when the server is known under independent names

Editorial: This needs a comma after "DANE-EE(3)", and would do well with "they" before "may ignore").

-- Section 3.1.1 --

  Such servers MUST either publish DANE-TA(2)
  records for an intermediate certificate or MUST instead use DANE-
  EE(3) TLSA records.

The first "MUST" should be moved one word later, after "either" (or else the second "MUST" should be removed).

-- Section 3.1.3 --

  Note, this section applies to MTA-to-MTA SMTP on port 25.

Earlier, in 2.2.3, you note that "the destination TCP port is typically 25, but this may be different with custom routes specified by the MTA administrator".  I don't think you mean for this section not to apply in the latter case, so I suggest changing this to, "Note, this section applies to MTA-to-MTA SMTP, which is normally on port 25."

  Nothing is lost since the
  PKIX certificate usages cannot aid SMTP TLS security, they can only
  impede SMTP TLS interoperability.

Editorial: You need a comma after "lost", and the existing comma needs to be a semicolon.

The last paragraph of the section is missing a final period.

-- Section 6 --

  Administrators of mail servers that employ mandatory DANE TLS, need
  to carefully monitor their mail logs and queues.

Nit: the comma should be removed.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-dane-smtp-with-dane-16, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA Actions that need completion.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (SMTP security via opportunistic DANE TLS) to Proposed Standard


The IESG has received a request from the DNS-based Authentication of
Named Entities WG (dane) to consider the following document:
- 'SMTP security via opportunistic DANE TLS'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-05-07. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This memo describes a downgrade-resistant protocol for SMTP transport
  security between Mail Transfer Agents (MTAs) based on the DNS-Based
  Authentication of Named Entities (DANE) TLSA DNS record.  Adoption of
  this protocol enables an incremental transition of the Internet email
  backbone to one using encrypted and authenticated Transport Layer
  Security (TLS).




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

Standards Track


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

This document explians in  detail how MTAs (Mail-Transfer-Agent) use
TLSA records in setting up SSL proteced sessions. This document is
based on implementation and deployment experience. The
document covers offers guidance on many corner cases in both in DANE
SSL setup as well in mail transport.

This document has been implemented in two major MTA distributions, and
there is growing usage base.


Working Group Summary:

There has been good solid discussion on this document, there is strong
consensus about the whole document.

Document Quality:

The document is detailied and covers many corner cases some of with are
DNS related to email. The protocol specified here is tested in
practice and that is reflected in the document. The document educates
the readers about choices to avoid pitfalls in implmentations and operations.
Email people are encouraged to review the document.
It is helpful to read this document along with its companion document
draft-ietf-dane-srv-xx.  The two document cross referene
each other to avoid dupliaiton.

Personnel:

Document Shepherd: Olafur Gudmundsson
Area Director: Stephen Farrell


(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 shepert has reviewed the document multiple times. This
document is ready for publication. Editors have been responsive
in addressesing issues.


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

NO

(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.

No, but email people should take a look.


(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? For example, perhaps he or she is
uncomfortable with certain parts of the document, or has concerns
whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

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


(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

NO


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

STRONG


(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.)

No

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

None left.


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

Not needed

(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 or are otherwise in an unclear state? If such
normative references exist, what is the plan for their completion?

There is one document that is normative that is in WG progress we will
be attemtpting to advance it soon, thus the expection is that this
document will wait for the missing document draft-ietf-dane-ops-xx to
catch up in publication process.


(15) Are there downward normative references references (see RFC
3967)? If so, list these downward references to support the Area
Director in the Last Call procedure.

NO


(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are
not listed in the Abstract and Introduction, explain why, and point to
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.

No

(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC
5226).

No IANA actions

(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

NONE,

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

Does not apply

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

Standards Track


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

This document explians in  detail how MTAs (Mail-Transfer-Agent) use
TLSA records in setting up SSL proteced sessions. This document is
based on implementation and deployment experience. The
document covers offers guidance on many corner cases in both in DANE
SSL setup as well in mail transport.

This document has been implemented in two major MTA distributions, and
there is growing usage base.


Working Group Summary:

There has been good solid discussion on this document, there is strong
consensus about the whole document.

Document Quality:

The document is detailied and covers many corner cases some of with are
DNS related to email. The protocol specified here is tested in
practice and that is reflected in the document. The document educates
the readers about choices to avoid pitfalls in implmentations and operations.
Email people are encouraged to review the document.
It is helpful to read this document along with its companion document
draft-ietf-dane-srv-xx.  The two document cross referene
each other to avoid dupliaiton.

Personnel:

Document Shepherd: Olafur Gudmundsson
Area Director: Stephen Farrell


(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 shepert has reviewed the document multiple times. This
document is ready for publication. Editors have been responsive
in addressesing issues.


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

NO

(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.

No, but email people should take a look.


(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? For example, perhaps he or she is
uncomfortable with certain parts of the document, or has concerns
whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

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


(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

NO


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

STRONG


(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.)

No

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

None left.


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

Not needed

(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 or are otherwise in an unclear state? If such
normative references exist, what is the plan for their completion?

There is one document that is normative that is in WG progress we will
be attemtpting to advance it soon, thus the expection is that this
document will wait for the missing document draft-ietf-dane-ops-xx to
catch up in publication process.


(15) Are there downward normative references references (see RFC
3967)? If so, list these downward references to support the Area
Director in the Last Call procedure.

NO


(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are
not listed in the Abstract and Introduction, explain why, and point to
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.

No

(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC
5226).

No IANA actions

(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

NONE,

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

Does not apply