Skip to main content

Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows
draft-ietf-dmarc-interoperability-18

Revision differences

Document history

Date Rev. By Action
2016-09-29
18 (System)
Received changes through RFC Editor sync (created alias RFC 7960, changed title to 'Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and …
Received changes through RFC Editor sync (created alias RFC 7960, changed title to 'Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows', changed abstract to 'Domain-based Message Authentication, Reporting, and Conformance (DMARC) introduces a mechanism for expressing domain-level policies and preferences for email message validation, disposition, and reporting.  However, the DMARC mechanism enables potentially disruptive interoperability issues when messages do not flow directly from the author's administrative domain to the final Recipients.  Collectively, these email flows are referred to as "indirect email flows".  This document describes these interoperability issues and presents possible methods for addressing them.', changed pages to 27, changed standardization level to Informational, changed state to RFC, added RFC published event at 2016-09-29, changed IESG state to RFC Published)
2016-09-29
18 (System) RFC published
2016-09-21
18 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2016-08-23
18 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2016-07-25
18 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2016-07-19
18 (System) RFC Editor state changed to EDIT
2016-07-19
18 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2016-07-19
18 (System) Announcement was received by RFC Editor
2016-07-19
18 (System) IANA Action state changed to No IC from In Progress
2016-07-19
18 (System) IANA Action state changed to In Progress
2016-07-19
18 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent::Point Raised - writeup needed
2016-07-19
18 Cindy Morgan IESG has approved the document
2016-07-19
18 Cindy Morgan Closed "Approve" ballot
2016-07-19
18 Cindy Morgan Ballot approval text was generated
2016-07-18
18 Kurt Andersen New version available: draft-ietf-dmarc-interoperability-18.txt
2016-06-21
17 Kurt Andersen IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2016-06-21
17 Kurt Andersen New version available: draft-ietf-dmarc-interoperability-17.txt
2016-06-20
16 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'No Response'
2016-06-17
16 Tero Kivinen Request for Last Call review by SECDIR Completed: Ready. Reviewer: Sean Turner.
2016-06-16
16 Cindy Morgan IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation
2016-06-16
16 Kathleen Moriarty [Ballot comment]
I'd also like to see the adjusted text per Stephen's first 2 comments.
2016-06-16
16 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2016-06-16
16 Stephen Farrell
[Ballot comment]

- I think the abstract and intro are too coy in saying that
DMARC "can" introduce interop issues when we know that it …
[Ballot comment]

- I think the abstract and intro are too coy in saying that
DMARC "can" introduce interop issues when we know that it
definitely does introduce such issues. Better to be up front
about that I think. The same issue arises elsewhere (e.g.  in
3.2.3.1) and I don't see any real benefit in almost pretending
that this isn't a real issue.

- I think the abstract and intro would be better if they
explicitly ack'd that DMARC affects mailing lists. So maybe
replacing the relevant sentence with something like:
"Collectively these email flows are referred to as indirect
email flows, and include mailing lists, such as those used to
discuss this document."

- 2.3: I'm surprised that we don't know the prevalence of simple
vs. relaxed support and use.

- 3.1.2: Saying that the MTA is the thing to "introduce" the
interop issue here seems a bit wrong - isn't the issue caused by
the existing MTA practice combined with the introduction of
DMARC?
2016-06-16
16 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2016-06-16
16 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2016-06-15
16 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2016-06-15
16 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2016-06-14
16 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2016-06-14
16 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2016-06-14
16 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2016-06-14
16 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2016-06-14
16 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2016-06-13
16 Ben Campbell
[Ballot comment]
- Abstract: Please expand DMARC on first mention.

- 4.1.1.1, last bullet: "However, for known brands, all active domains are likely to be …
[Ballot comment]
- Abstract: Please expand DMARC on first mention.

- 4.1.1.1, last bullet: "However, for known brands, all active domains are likely to be
      targeted equally by abusers."

I'm not sure quite what is meant by "known brands". Is this the same as well known email services?

6. Some of the mentioned mitigations involved relaxing alignment checks. Do those warrant a mention here?

-- last paragraph: " Section 4.1.3.3 warns that rewriting the RFC5322.From header field
  and changing the domain name should not be done with any domain."

I'm not sure I understand that sentence, especially around "not be done with any domain". Nor do I see which text in 4.1.3.3 specifically says that.
2016-06-13
16 Ben Campbell [Ballot Position Update] New position, Yes, has been recorded for Ben Campbell
2016-06-13
16 Mirja Kühlewind [Ballot Position Update] New position, Yes, has been recorded for Mirja Kühlewind
2016-06-10
16 Peter Yee Request for Telechat review by GENART Completed: Ready. Reviewer: Peter Yee.
2016-06-09
16 Jean Mahoney Request for Telechat review by GENART is assigned to Peter Yee
2016-06-09
16 Jean Mahoney Request for Telechat review by GENART is assigned to Peter Yee
2016-06-09
16 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2016-06-08
16 Alexey Melnikov Ballot has been issued
2016-06-08
16 Alexey Melnikov [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov
2016-06-08
16 Alexey Melnikov Created "Approve" ballot
2016-06-08
16 Alexey Melnikov Ballot writeup was changed
2016-06-08
16 Alexey Melnikov IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2016-06-08
16 Alexey Melnikov
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)?
   
Informational.

    Why …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)?
   
Informational.

    Why is this the proper type of RFC?

This document discusses interoperability considerations for the DMARC protocol.
It does not specify any sort of  standard and while it does describe various
mitigation strategies for DMARC interoperability problems, it carefully
avoids labeling them as best practices.

    Is this type of RFC indicated in the title page header?

Yes.

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

  DMARC introduces a mechanism for expressing domain-level policies and
  preferences for email message validation, disposition, and reporting.
  The DMARC mechanism can encounter interoperability issues when
  messages do not flow directly from the author's administrative domain
  to the final recipients.  Collectively these email flows are referred
  to as indirect email flows.  This document describes interoperability
  issues between DMARC and indirect email flows.  Possible methods for
  addressing interoperability issues are presented.

Working Group Summary:

  This document was initially posted on January 29, 2015. The WGLC began
  September 30, 2015, with no substantive comments being made during the
  last call period.

Document Quality:

  This is an informational specification; it does not specify a standard
  or best practices.

Personnel:

  Ned Freed  is acting as the Document Shepherd. The
  responsible Area Director is Alexey Melnikov .

(3) Briefly describe the review of this document that was performed by the
    Document Shepherd.
   
The entire document was carefully reviewed. A number of issues were found,
most of which are editorial in nature. The resulting issues list was posted
to the WG list, leading to the -15 revision.

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

No.

(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?
   
The usual concern with informational documents is particularly acute here:
The possibility that people will, because it's an RFC, treat it as a standard,
or worse, a list of best practices. It may be appropriate to insert
additional warnings about this given this document's description of various
techniques that are decidedly not best practices.

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

  Franck Martin - fmartin@linkedin.com - confirmed
  Eliot Lear - lear@cisco.com - confirmed
  Tim Draegen - tim@dmarcian.com - confirmed
  Elizabeth Zwicky - zwicky@yahoo-inc.com - confirmed
  Kurt Andersen - kandersen@linkedin.com - confirmed

(8) Has an IPR disclosure been filed that references this document?

No.

(9) How solid is the WG consensus behind this document?

It's fairly solid.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?

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).
   
There's nit about one of the IP addresses possibly being in the wrong format;
These were fixed in -16.

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

N/A.

(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?
   
N/A.

(15) Are there downward normative references references (see RFC 3967)?

N/A.

(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,
    especially with regard to its consistency with the body of the document.
   
This document has no IANA considerations and the section is marked to be
removed prior to publication.

(18) List any new IANA registries that require Expert Review for future
  allocations.
 
N/A.

(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.
   
There is no use of ABNF, MIBs, XML, or anything similar in this document.

The two sample mail messages in Appendix A were run through the message lint
utility. The results of that run were included in the document shepherd
review which led to revision -15.

2016-06-08
16 Kurt Andersen IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2016-06-08
16 Kurt Andersen New version available: draft-ietf-dmarc-interoperability-16.txt
2016-06-04
15 Peter Yee Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Peter Yee.
2016-06-03
15 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2016-05-26
15 Jean Mahoney Request for Last Call review by GENART is assigned to Peter Yee
2016-05-26
15 Jean Mahoney Request for Last Call review by GENART is assigned to Peter Yee
2016-05-26
15 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2016-05-26
15 Sabrina Tanamal
(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-dmarc-interoperability-15.txt, which is currently in Last Call, and has the following comments:

We understand that this …
(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-dmarc-interoperability-15.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

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

Thank you,

Sabrina Tanamal
IANA Specialist
ICANN
2016-05-26
15 Tero Kivinen Request for Last Call review by SECDIR is assigned to Sean Turner
2016-05-26
15 Tero Kivinen Request for Last Call review by SECDIR is assigned to Sean Turner
2016-05-23
15 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tim Wicinski
2016-05-23
15 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tim Wicinski
2016-05-20
15 Amy Vezza IANA Review state changed to IANA - Review Needed
2016-05-20
15 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: draft-ietf-dmarc-interoperability@ietf.org, ned.freed@mrochek.com, dmarc@ietf.org, alexey.melnikov@isode.com, "Ned Freed" , …
The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: draft-ietf-dmarc-interoperability@ietf.org, ned.freed@mrochek.com, dmarc@ietf.org, alexey.melnikov@isode.com, "Ned Freed" , dmarc-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Interoperability Issues Between DMARC and Indirect Email Flows) to Informational RFC


The IESG has received a request from the Domain-based Message
Authentication, Reporting & Conformance WG (dmarc) to consider the
following document:
- 'Interoperability Issues Between DMARC and Indirect Email Flows'
  as Informational RFC

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 2016-06-03. 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


  DMARC introduces a mechanism for expressing domain-level policies and
  preferences for email message validation, disposition, and reporting.
  The DMARC mechanism can encounter interoperability issues when
  messages do not flow directly from the author's administrative domain
  to the final recipients.  Collectively these email flows are referred
  to as indirect email flows.  This document describes interoperability
  issues between DMARC and indirect email flows.  Possible methods for
  addressing interoperability issues are presented.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/ballot/


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


2016-05-20
15 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2016-05-20
15 Alexey Melnikov Placed on agenda for telechat - 2016-06-16
2016-05-20
15 Alexey Melnikov Last call was requested
2016-05-20
15 Alexey Melnikov Ballot approval text was generated
2016-05-20
15 Alexey Melnikov IESG state changed to Last Call Requested from AD Evaluation
2016-05-20
15 Alexey Melnikov Ballot writeup was changed
2016-05-20
15 Alexey Melnikov Ballot writeup was generated
2016-05-20
15 Alexey Melnikov Last call announcement was generated
2016-05-15
15 Ned Freed
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)?
   
Informational.

    Why …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)?
   
Informational.

    Why is this the proper type of RFC?

This document discusses interoperability considerations for the DMARC protocol.
It does not specify any sort of  standard and while it does describe various
mitigation strategies for DMARC interoperability problems, it carefully
avoids labeling them as best practices.

    Is this type of RFC indicated in the title page header?

Yes.

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

  DMARC introduces a mechanism for expressing domain-level policies and
  preferences for email message validation, disposition, and reporting.
  The DMARC mechanism can encounter interoperability issues when
  messages do not flow directly from the author's administrative domain
  to the final recipients.  Collectively these email flows are referred
  to as indirect email flows.  This document describes interoperability
  issues between DMARC and indirect email flows.  Possible methods for
  addressing interoperability issues are presented.

Working Group Summary:

  This document was initially posted on January 29, 2015. The WGLC began
  September 30, 2015, with no substantive comments being made during the
  last call period.

Document Quality:

  This is an informational specification; it does not specify a standard
  or best practices.

Personnel:

  Ned Freed  is acting as the Document Shepherd. The
  responsible Area Director is Alexey Melnikov .

(3) Briefly describe the review of this document that was performed by the
    Document Shepherd.
   
The entire document was carefully reviewed. A number of issues were found,
most of which are editorial in nature. The resulting issues list was posted
to the WG list, leading to the -15 revision.

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

No.

(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?
   
The usual concern with informational documents is particularly acute here:
The possibility that people will, because it's an RFC, treat it as a standard,
or worse, a list of best practices. It may be appropriate to insert
additional warnings about this given this document's description of various
techniques that are decidedly not best practices.

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

  Franck Martin - fmartin@linkedin.com - confirmed
  Eliot Lear - lear@cisco.com - confirmed
  Tim Draegen - tim@dmarcian.com - confirmed
  Elizabeth Zwicky - zwicky@yahoo-inc.com - confirmed
  Kurt Andersen - kandersen@linkedin.com - confirmed

(8) Has an IPR disclosure been filed that references this document?

No.

(9) How solid is the WG consensus behind this document?

It's fairly solid.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?

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).
   
There's nit about one of the IP addresses possibly being in the wrong format;
I don't really understand the issue but I included a suggestion that
will hopefully fix it in the shephard review. However, this change was not
implement in the -15 revision; but it can wait for a subsequent revision.

Boilerplate checks are not enough; this check needs to be thorough.

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

N/A.

(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?
   
N/A.

(15) Are there downward normative references references (see RFC 3967)?

N/A.

(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,
    especially with regard to its consistency with the body of the document.
   
This document has no IANA considerations and the section is marked to be
removed prior to publication.

(18) List any new IANA registries that require Expert Review for future
  allocations.
 
N/A.

(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.
   
There is no use of ABNF, MIBs, XML, or anything similar in this document.

The two sample mail messages in Appendix A were run through the message lint
utility. The results of that run were included in the document shepherd
review which led to revision -15.

2016-05-14
15 Alexey Melnikov IESG state changed to AD Evaluation from AD is watching
2016-05-14
15 Alexey Melnikov IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2016-05-14
15 Alexey Melnikov Changed consensus to Yes from Unknown
2016-05-13
15 Ned Freed
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)?
   
Informational.

    Why …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)?
   
Informational.

    Why is this the proper type of RFC?

This document discusses interoperability considerations for the DMARC protocol.
It does not specify any sort of  standard and while it does describe various
mitigation strategies for DMARC interoperability problems, it carefully
avoids labeling them as best practices.

    Is this type of RFC indicated in the title page header?

Yes.

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

  DMARC introduces a mechanism for expressing domain-level policies and
  preferences for email message validation, disposition, and reporting.
  The DMARC mechanism can encounter interoperability issues when
  messages do not flow directly from the author's administrative domain
  to the final recipients.  Collectively these email flows are referred
  to as indirect email flows.  This document describes interoperability
  issues between DMARC and indirect email flows.  Possible methods for
  addressing interoperability issues are presented.

Working Group Summary:

  This document was initially posted on January 29, 2015. The WGLC began
  September 30, 2015, with no substantive comments being made during the
  last call period.

Document Quality:

  This is an informational specification; it does not specify a standard
  or best practices.

Personnel:

  Ned Freed  is acting as the Document Shepherd. The
  responsible Area Director is Alexey Melnikov .

(3) Briefly describe the review of this document that was performed by the
    Document Shepherd.
   
The entire document was carefully reviewed. A number of issues were found,
most of which are editorial in nature. The resulting issues list was posted
to the WG list, leading to the -15 revision.

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

No.

(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?
   
The usual concern with informational documents is particularly acute here:
The possibility that people will, because it's an RFC, treat it as a standard,
or worse, a list of best practices. It may be appropriate to insert
additional warnings about this given this document's description of various
techniques that are decidedly not best practices.

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

  Franck Martin - fmartin@linkedin.com - confirmed
  Eliot Lear - lear@cisco.com - confirmed
  Tim Draegen - tim@dmarcian.com -
  Elizabeth Zwicky - zwicky@yahoo-inc.com - confirmed
  Kurt Andersen - kandersen@linkedin.com - confirmed

(8) Has an IPR disclosure been filed that references this document?

No.

(9) How solid is the WG consensus behind this document?

It's fairly solid.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?

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).
   
There's nit about one of the IP addresses possibly being in the wrong format;
I don't really understand the issue but I included a suggestion that
will hopefully fix it in the shephard review. However, this change was not
implement in the -15 revision; but it can wait for a subsequent revision.

Boilerplate checks are not enough; this check needs to be thorough.

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

N/A.

(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?
   
N/A.

(15) Are there downward normative references references (see RFC 3967)?

N/A.

(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,
    especially with regard to its consistency with the body of the document.
   
This document has no IANA considerations and the section is marked to be
removed prior to publication.

(18) List any new IANA registries that require Expert Review for future
  allocations.
 
N/A.

(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.
   
There is no use of ABNF, MIBs, XML, or anything similar in this document.

The two sample mail messages in Appendix A were run through the message lint
utility. The results of that run were included in the document shepherd
review which led to revision -15.

2016-05-13
15 Kurt Andersen New version available: draft-ietf-dmarc-interoperability-15.txt
2016-05-11
14 Ned Freed
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)?
   
Informational.

    Why …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)?
   
Informational.

    Why is this the proper type of RFC?

This document discusses interoperability considerations for the DMARC protocol.
It does not specify any sort of  standard and while it does describe various
mitigation strategies for DMARC interoperability problems, it carefully
avoids labeling them as best practices.

    Is this type of RFC indicated in the title page header?

Yes.

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

  DMARC introduces a mechanism for expressing domain-level policies and
  preferences for email message validation, disposition, and reporting.
  The DMARC mechanism can encounter interoperability issues when
  messages do not flow directly from the author's administrative domain
  to the final recipients.  Collectively these email flows are referred
  to as indirect email flows.  This document describes interoperability
  issues between DMARC and indirect email flows.  Possible methods for
  addressing interoperability issues are presented.

Working Group Summary:

  This document was initially posted on January 29, 2015. The WGLC began
  September 30, 2015, with essentially no substantive comments being made. 

Document Quality:

  This is an informational specification; it does not specify a standard
  or best practices.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

(3) Briefly describe the review of this document that was performed by the
    Document Shepherd.
   
The entire document was carefully reviewed. A number of issues were found,
most of which are editorial in nature. The resulting issues list has been posted
to the WG mailing list so the document can be updated.

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

No.

(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?
   
The usual concern with informational documents is particularly acute here:
The possibility that people will, because it's an RFC, treat it as a standard,
or worse, a list of best practices. It may be appropriate to insert
additional warnings about this given this document's description of various
techniques that are decidedly not best practices.

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

  Franck Martin - fmartin@linkedin.com - confirmed
  Eliot Lear - lear@cisco.com -
  Tim Draegen - tim@dmarcian.com -
  Elizabeth Zwicky - zwicky@yahoo-inc.com -
  Kurt Andersen - kandersen@linkedin.com - confirmed

(8) Has an IPR disclosure been filed that references this document?

No.

(9) How solid is the WG consensus behind this document?

It's fairly solid.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?

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).
   
There's nit about one of the IP addresses possibly being in the wrong format;
I don't really understand the issue but I included a suggestion that
will hopefully fix it in the shephard review.

Boilerplate checks are not enough; this check needs to be thorough.

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

N/A.

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

(15) Are there downward normative references references (see RFC 3967)?

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,
    especially with regard to its consistency with the body of the document.
   
This document has no IANA considerations and the section is marked to be
removed prior to publication.

(18) List any new IANA registries that require Expert Review for future
  allocations.
 
N/A.

(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.
   
There is no use of ABNF, MIBs, XML, or anything similar in this document.

The two sample mail messages in Appendix A were run through the message lint
utility. The results of that run were included in the document shepherd
review that has been posted to the WG list.

2016-05-05
14 Tim Draegen IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2016-05-03
14 Alexey Melnikov Notification list changed to "Ned Freed" <ned.freed@mrochek.com>
2016-05-03
14 Alexey Melnikov Document shepherd changed to Ned Freed
2016-05-03
14 Alexey Melnikov Intended Status changed to Informational
2016-05-03
14 Alexey Melnikov IESG process started in state AD is watching
2016-05-03
14 (System) Earlier history may be found in the Comment Log for /doc/draft-dmarc-interoperability/
2016-01-18
14 Kurt Andersen New version available: draft-ietf-dmarc-interoperability-14.txt
2015-12-08
13 Kurt Andersen New version available: draft-ietf-dmarc-interoperability-13.txt
2015-11-30
12 Kurt Andersen New version available: draft-ietf-dmarc-interoperability-12.txt
2015-11-12
11 Kurt Andersen New version available: draft-ietf-dmarc-interoperability-11.txt
2015-11-09
10 Kurt Andersen New version available: draft-ietf-dmarc-interoperability-10.txt
2015-11-05
09 Kurt Andersen New version available: draft-ietf-dmarc-interoperability-09.txt
2015-10-20
08 Tim Draegen IETF WG state changed to In WG Last Call from WG Document
2015-10-19
08 Kurt Andersen New version available: draft-ietf-dmarc-interoperability-08.txt
2015-09-28
07 Franck Martin New version available: draft-ietf-dmarc-interoperability-07.txt
2015-08-28
06 Franck Martin New version available: draft-ietf-dmarc-interoperability-06.txt
2015-08-17
05 Franck Martin New version available: draft-ietf-dmarc-interoperability-05.txt
2015-06-09
04 Franck Martin New version available: draft-ietf-dmarc-interoperability-04.txt
2015-05-22
03 Franck Martin New version available: draft-ietf-dmarc-interoperability-03.txt
2015-04-28
02 Franck Martin New version available: draft-ietf-dmarc-interoperability-02.txt
2015-03-23
01 Franck Martin New version available: draft-ietf-dmarc-interoperability-01.txt
2015-01-29
00 Tim Draegen This document now replaces draft-dmarc-interoperability instead of None
2015-01-29
00 Franck Martin New version available: draft-ietf-dmarc-interoperability-00.txt