Experimental Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Extension for Public Suffix Domains
draft-ietf-dmarc-psd-15

[Ballot comment]
Thank you to Sandra Murphy for the SECDIR review.  Please review those proposed clarifying edits.



** Section 4.1
Due to the inherent Privacy and Security risks associated with PSD
  DMARC for Organizational Domains in multi-organization PSDs that do
  not particpate in DMARC, any Feedback Reporting related to multi-
  organizational PSDs MUST be limited to non-existent domains except in
  cases where the reporter knows that PSO requires use of DMARC.

Is there any guidance on how the reporter might know “that [the] PSO requires use of DMARC”.

** Section B.2.
-- Please define the semantics of the “status” column and the expected/possible values

-- Reconcile the differences between the initial values noted in this this document and those at http://psddmarc.org/registry.html:
o the text in this section says “current” for the status column, but the html page has same values as set to “active”

o the PSD names in the initial values of this document are of the form “.*”, but the html page has no leading dot (i.e., “.bank” vs. “bank”)

[Ballot comment]
This document is generally in pretty good shape; my comments (and,
to some extent, my discuss as well) are pretty minor points.

Thanks to Sandra Murphy for the secdir review.  I think there were some
questions in there that are worth a response and possibly clarifications
in the document.

Section 1.2

It seems like the "branded PSD" and "multi-organization PSD" cases would
benefit from a protocol-level indication and separate handling by
message recipients.  It seems likely that the newly defined np (in
combination with the preexisting sp) provides the flexibility to
describe the different cases, but it seems like it would be helpful to
have some discussion in this document that relates these two cases to
the actual protocol mechanisms used to achieve them.

Section 3

As Lars and Éric already commented, I suggest using a phrasing that
includes something like "this experiment" and maybe "proposes", since
actually formally updating the DMARC specification would procedurally be
a bit exciting.

Section 3.2

  np:  Requested Mail Receiver policy for non-existent subdomains
      (plain-text; OPTIONAL).  Indicates the policy to be enacted by the

I assume that "subdomains" here refers only to direct children (i.e.,
one additional label), not deeper in the hierarchy.  It's not entirely
clear to me whether all readers will do likewise, though...

Section 3.3, 3.6

It sounds like this entire paragraph is appended to the section?
In other subsections we are a bit more explicit about where the new text
is going and what part is the new text.

Section 4.1

  o  Multi-organization PSDs (e.g., ".com") that do not mandate DMARC
      usage: Privacy risks for Organizational Domains that have not
      deployed DMARC within such PSDs are significant.  For non-DMARC
      Organizational Domains, all DMARC feedback will be directed to the
      PSO.  PSD DMARC is opt-out (by publishing a DMARC record at the
      Organizational Domain level) vice opt-in, which would be the more
      desirable characteristic.  This means that any non-DMARC
      organizational domain would have its feedback reports redirected
      to the PSO.  The content of such reports, particularly for
      existing domains, is privacy sensitive.

It might be worth making some statement about the applicability of PSD
DMARC for such PSDs that do not mandate DMARC usage.  (I guess the
following paragraphs mostly play that role, though perhaps editorially
tying them together more clearly is possible.)
Or, in the vein of my comment on section 1.2, an explicit protocol
mechanism could be introduced that limits the reporting to just the
indicated (public suffix) domain and does not apply to subdomains.

  organizational PSDs MUST be limited to non-existent domains except in
  cases where the reporter knows that PSO requires use of DMARC.

Do we have examples of how the reporter might come to know this?
Say ... Appendix B.2?

Appendix A

  o  Section 3.2 adds the "np" tag for non-existent subdomains (DNS
      NXDOMAIN).  [...]

Per §2.7, this is for NXDOMAIN or NODATA, not just NXDOMAIN.

Appendix B.1

  A sample stand-alone DNS query service is available at
  [psddmarc.org].  It was developed based on the contents suggested for

"DNS query service" is so generic so as to be almost meaningless.  Even
if we defer usage instructions to the external site, we should probably
say a bit more about what it is expected to do.

[Ballot discuss]
There seems to be a bit of internal inconsistency in Appendix B.2:

  Names of PSDs participating in PSD DMARC must be registered this new
  registry.  New entries are assigned only for PSDs that require use of
  DMARC.  [...]

These two sentences seem to be in conflict, since a PSD can participate
in PSD DMARC without requiring use of DMARC for all its subdomains.  The
rest of the section is clear that the registry is only intended to be
for PSDs that do require the use of DMARC for subdomains, so I expect
that a minor tweak to the wording of "PSDs participating in PSD DMARC"
would be an appropriate fix.

[Ballot comment]
This document is generally in pretty good shape; my comments (and,
to some extent, my discuss as well) are pretty minor points.

Section 1.2

It seems like the "branded PSD" and "multi-organization PSD" cases would
benefit from a protocol-level indication and separate handling by
message recipients.  It seems likely that the newly defined np (in
combination with the preexisting sp) provides the flexibility to
describe the different cases, but it seems like it would be helpful to
have some discussion in this document that relates these two cases to
the actual protocol mechanisms used to achieve them.

Section 3

As Lars and Éric already commented, I suggest using a phrasing that
includes something like "this experiment" and maybe "proposes", since
actually formally updating the DMARC specification would procedurally be
a bit exciting.

Section 3.2

  np:  Requested Mail Receiver policy for non-existent subdomains
      (plain-text; OPTIONAL).  Indicates the policy to be enacted by the

I assume that "subdomains" here refers only to direct children (i.e.,
one additional label), not deeper in the hierarchy.  It's not entirely
clear to me whether all readers will do likewise, though...

Section 3.3, 3.6

It sounds like this entire paragraph is appended to the section?
In other subsections we are a bit more explicit about where the new text
is going and what part is the new text.

Section 4.1

  o  Multi-organization PSDs (e.g., ".com") that do not mandate DMARC
      usage: Privacy risks for Organizational Domains that have not
      deployed DMARC within such PSDs are significant.  For non-DMARC
      Organizational Domains, all DMARC feedback will be directed to the
      PSO.  PSD DMARC is opt-out (by publishing a DMARC record at the
      Organizational Domain level) vice opt-in, which would be the more
      desirable characteristic.  This means that any non-DMARC
      organizational domain would have its feedback reports redirected
      to the PSO.  The content of such reports, particularly for
      existing domains, is privacy sensitive.

It might be worth making some statement about the applicability of PSD
DMARC for such PSDs that do not mandate DMARC usage.  (I guess the
following paragraphs mostly play that role, though perhaps editorially
tying them together more clearly is possible.)
Or, in the vein of my comment on section 1.2, an explicit protocol
mechanism could be introduced that limits the reporting to just the
indicated (public suffix) domain and does not apply to subdomains.

  organizational PSDs MUST be limited to non-existent domains except in
  cases where the reporter knows that PSO requires use of DMARC.

Do we have examples of how the reporter might come to know this?
Say ... Appendix B.2?

Appendix A

  o  Section 3.2 adds the "np" tag for non-existent subdomains (DNS
      NXDOMAIN).  [...]

Per §2.7, this is for NXDOMAIN or NODATA, not just NXDOMAIN.

Appendix B.1

  A sample stand-alone DNS query service is available at
  [psddmarc.org].  It was developed based on the contents suggested for

"DNS query service" is so generic so as to be almost meaningless.  Even
if we defer usage instructions to the external site, we should probably
say a bit more about what it is expected to do.

[Ballot comment]
Thanks for this document.  A few minor clarifying comments that may help this document:

  o  Branded PSDs (e.g., ".google"): These domains are effectively
      Organizational Domains as discussed in [RFC7489].  They control
      all subdomains of the tree.  These are effectively private
      domains, but listed in the current public suffix list.  They are
      treated as Public for DMARC purposes.  They require the same
      protections as DMARC Organizational Domains, but are currently
      unable to benefit from DMARC.

I found this paragraph confusing.  In "These are effectively private domains", it wasn't clear to me what "these" refers to.  Is it the domains or the subdomains.  Otherwise it says "these are effectively" twice, with two different descriptions.  ​Perhaps, check if this paragraph can be reworded to make it clearer.


  ​These
  ​issues are not typically applicable to PSDs, since they (e.g., the
  ​".gov.example" used above) do not typically send mail.
  ​
I presume that this means that emails are not directly sent from @gov.example, rather than there is no mail below .gov.example.  Perhaps worth clarifying?

    For DMARC purposes, a non-existent domain is a domain for which there
  is an NXDOMAIN or NODATA response for A, AAAA, and MX records.  This
  is a broader definition than that in NXDOMAIN [RFC8020].
 
I presume that this means that there is no response for any of A, AAAA and MX records, not that there is no response for a particular type of record.  Should this be clarified? Although arguably it seems pretty obvious.

Thanks,
Rob

[Ballot comment]
Thank you for the work put into this document. It is easy to read and specify an experiment, which could be useful.

Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Sections 1 and 3--
I share Lars' concern about the "update" in the last paragraph.

-- Section 5.1 --
Editorial comment: why using a sub-section ? Let's 'glue' its contents to the first § of section 5. BTW, interesting read this section.

== NITS ==

-- Section 2.2 --
Unsure whether "Requests for Comment (RFC)" is really required ;-) cfr https://www.rfc-editor.org/materials/abbrev.expansion.txt

-- Sections 2.2 ... 2.7 --
Mostly cosmetic but I would have preferred the usual presentation to introduce terminology, i.e., a list and not several sub-sections.

[Ballot comment]
Section 3, paragraph 2, comment:
> 3.  PSD DMARC Updates to DMARC Requirements
>
>    This document updates DMARC as follows:

If I understand things correctly, this document specifies an experiment that -
if successful - would lead to an update of RFC7489. It's therefore confusing to
see the text in Section 3 that is written as if that update was already being
brought into effect. I'd much prefer text that said things like "to participate
in this experiment, implementations should do X or Y or Z and/or interpret
Section foo of RFC7489 as bar", etc.

Section 7.3, paragraph 1, comment:
> 7.3.  URIs

It's unusual for an RFC to have reference sections other than for normative and
informative references, because it's not clear what category references here
would fall into. Also, I'll note that [psddmarc.org] was cited as an informative
reference in that section, so why not this one?

-------------------------------------------------------------------------------
All comments below are very minor change suggestions that you may choose to
incorporate in some way (or ignore), as you see fit. There is no need to let me
know what you did with these suggestions.

Section 3.2, paragraph 3, nit:
>      to that of the "p" tag defined below.  If the 'np' tag is absent,

The document uses both single and double quotes throughput (above is an
example), and it's not clear if this is deliberate (i.e., there is a meaning to
this) or whether this is an editorial oversight that should be corrected.

Section 6.1, paragraph 5, nit:
>    +----------+-----------+---------+-------------------------------+
>    | Tag Name | Reference | Status  | Description                  |
>    +----------+-----------+---------+-------------------------------+
>    | np      | this      | current | Requested handling policy for |
>    |          | document  |        | non-existent subdomains      |
>    +----------+-----------+---------+-------------------------------+
>

You should add an RFC Editor Note instructing them to replace "this document"
with the RFC number of this document (to make sure they are aware of the
action).

Section 1, paragraph 2, nit:
-    DMARC ([RFC7489]) provides a mechanism for publishing organizational
-          -        -
+    DMARC [RFC7489] provides a mechanism for publishing organizational

Section 1, paragraph 3, nit:
-    found in Section 3.2 of the DMARC specification.  Currently the
+    found in Section 3.2 of the DMARC specification.  Currently, the
+                                                              +

Section 1, paragraph 4, nit:
-    In the basic DMARC model, PSDs are not organizational domains and are
+    In the basic DMARC model, Public Suffix Domains (PSDs) are not organizational domains and are
+                              +++++++++++++++++++++++  +

Section 1.2, paragraph 7, nit:
-    handling policy for non-existent subdommains.  This is provided
-                                          -
+    handling policy for non-existent subdomains.  This is provided

Section 1.2, paragraph 7, nit:
-    of requesting harsh policy treatment (e.g. reject) is lower.
+    of requesting harsh policy treatment (e.g., reject) is lower.
+                                              +

Section 1.2, paragraph 8, nit:
-    (i.e. if a DMARC record were published for 'example', then mail from
+    (i.e., if a DMARC record were published for 'example', then mail from
+        +

Section 2.7, paragraph 2, nit:
-    is a broader definition than that in NXDOMAIN [RFC8020].
-                                        ---------
+    is a broader definition than that in [RFC8020].

Section 4.1, paragraph 7, nit:
-    not particpate in DMARC, any Feedback Reporting related to multi-
+    not participate in DMARC, any Feedback Reporting related to multi-
+              +

"B.3.", paragraph 3, nit:
-    supposed to be the output domain of the regular PSL lookup, i.e.  the
+    supposed to be the output domain of the regular PSL lookup, i.e.,  the
+                                                                    +

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

The IANA Functions Operator has completed its review of draft-ietf-dmarc-psd-11. If any part of this review is inaccurate, please let us know.

In the DMARC Tag Registry on the Domain-based Message Authentication, Reporting, and Conformance (DMARC) Parameters registry page located at:

https://www.iana.org/assignments/dmarc-parameters/

a new registration is to be made as follows:

Tag Name: np
Reference: [ RFC-to-be ]
Status: current
Description: Requested handling policy for non-existent subdomains

The IESG-designated expert for the DMARC Tag Registry has approved this registration.

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

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

The intended document status is Experimental, which is shown in the title page header.  This status is appropriate for this document because it specifies a development effort that is intended only to collect data as input to a later revision of the main DMARC specification.  The content has enough community support to be worth implementing and testing on live email traffic feeds to test its efficacy in assisting the accuracy and applicability of DMARC.

(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

  Domain-based Message Authentication, Reporting, and Conformance
  (DMARC) permits a domain-controlling organization to express domain-
  level policies and preferences for message validation, disposition,
  and reporting, which a mail-receiving organization can use to improve
  mail handling.

  DMARC distinguishes the portion of a name that is a Public Suffix
  Domain (PSD), below which organizational domain names are created.
  The basic DMARC capability allows organizational domains to specify
  policies that apply to their subdomains, but it does not give that
  capability to PSDs.  This document describes an extension to DMARC to
  fully enable DMARC functionality for PSDs.

  Some implementations of DMARC consider a PSD to be ineligible for
  DMARC enforcement.  This specification addresses that case.

Working Group Summary

  The working group came to consensus fairly quickly about this proposal
  because it's fairly minimal, straightforward, and well understood.

Document Quality

There is one implementation already (by the author), and numerous operators have expressed intent to participate, including open source and private operators, once the document is approved.

Personnel

Murray Kucherawy is the responsible Area Director, though he was the document shepherd at the time this went to IETF Last Call.
Alexey Melnikov is the new document shepherd.

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

I reviewed the document for both editorial and technical quality.  It has appropriate IANA and Security Considerations sections.  An appropriate WGLC was performed and feedback received was folded in by the author.  The WG secretary also assured that all raised issues were addressed somehow.

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

None; ART and SEC reviews are expected in due course, and otherwise enough of the usual IETF email community and participants in M3AAWG also provided input.

(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 such specialist reviews are needed.

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

The community believes there is a strong need for this work.  As ARC was also recently published as experimental (RFC8617), this is a ripe time for considering ecosystem solutions such as this.

(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 such disclosure has been filed.

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

There are about 15-20 regular active working group participants, and consensus among them for this experimental document appears to be firm.

The document lingered a bit in post IETF LC editing, which necessitated adding of a new document editor. Version -11 addresses GenArt review.

(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 expressions of appeal-level discontent have been observed so far.  However, it is worth noting here that Dave Crocker raised and pressed an objection that the work should not be published without going back to first principles with DMARC itself, which would set the already glacial working group back months.  Given the WG intends to reopen its base document anyway after this experiment is published, that seems like an unnecessary constraint.  In any case, his assertion does not appear to have swayed consensus away from proceeding.

He also contends that an experiment meant to collect data and then be destroyed is not the kind of thing the IETF should be publishing in the first place, since it represents something that could introduce confusion or cruft into the deployed base.  I disagreed with this position because there are existence proofs of Experimental status not observing such constraints.  His objection has not been sustained by the working group generally; one person was concerned about us publishing an experiment of any kind, but this was not enough to give the impression that consensus has eroded.  Nevertheless, the working group is prepared to accept Informational status if the IESG concurs with this objection.

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

No ID nits have been identified.

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

No formal reviews are needed; this document makes no registrations of media types or other major code points.

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

No; all referenced documents are published.

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

This is an experimental document.  There can only be up-refs.

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

This document describes an experiment.  Should the experiment move to the standards track, it will update RFC7489.  RFC7489 was an Independent Submission and therefore currently has Informational status.  RFC7489 is under review by the DMARC working group, which intends to republish it on to the standards track at some future date.  It will take the results of this experiment as input.  However, this document does not formally modify RFC7489.

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

I have reviewed the IANA Considerations section.  It makes a single registration in an extant registry for which Murray is the designated expert.  The section is well-formed and clear.

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

This document creates no new registry.

(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 ABNF, XML, or MIB definition in this document.

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

The intended document status is Experimental, which is shown in the title page header.  This status is appropriate for this document because it specifies a development effort that is intended only to collect data as input to a later revision of the main DMARC specification.  The content has enough community support to be worth implementing and testing on live email traffic feeds to test its efficacy in assisting the accuracy and applicability of DMARC.

(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 (Domain-based Message Authentication, Reporting, and
  Conformance) is a scalable mechanism by which a mail-originating
  organization can express domain-level policies and preferences for
  message validation, disposition, and reporting, that a mail-receiving
  organization can use to improve mail handling.  DMARC policies can be
  applied to individual domains or to all domains within an
  organization.  The design of DMARC precludes grouping policies for
  domains based on policy published above the organizational level,
  such as TLDs (Top Level Domains).  Domains at this higher level of
  the DNS tree (but not necessarily at the top of the DNS tree) can be
  collectively referred to as Public Suffix Domains (PSDs).  This
  document describes an extension to DMARC to enable DMARC
  functionality PSDs.

Working Group Summary

The working group came to consensus fairly quickly about this proposal because it's fairly minimal, straightforward, and well understood.

Document Quality

There is one implementation already (by the author), and numerous operators have expressed intent to participate, including open source and private operators, once the document is approved.

Personnel

Murray Kucherawy is the responsible Area Director, though he was the document shepherd at the time this went to IETF Last Call.
Alexey Melnikov is the new document shepherd.

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

I reviewed the document for both editorial and technical quality.  It has appropriate IANA and Security Considerations sections.  An appropriate WGLC was performed and feedback received was folded in by the author.  The WG secretary also assured that all raised issues were addressed somehow.

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

None; ART and SEC reviews are expected in due course, and otherwise enough of the usual IETF email community and participants in M3AAWG also provided input.

(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 such specialist reviews are needed.

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

The community believes there is a strong need for this work.  As ARC was also recently published as experimental (RFC8617), this is a ripe time for considering ecosystem solutions such as this.

(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 such disclosure has been filed.

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

There are about 15-20 regular active working group participants, and consensus among them for this experimental document appears to be firm.

The document lingered a bit in post IETF LC editing, which necessitated adding of a new document editor. Version -11 addresses GenArt review.

(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 expressions of appeal-level discontent have been observed so far.  However, it is worth noting here that Dave Crocker raised and pressed an objection that the work should not be published without going back to first principles with DMARC itself, which would set the already glacial working group back months.  Given the WG intends to reopen its base document anyway after this experiment is published, that seems like an unnecessary constraint.  In any case, his assertion does not appear to have swayed consensus away from proceeding.

He also contends that an experiment meant to collect data and then be destroyed is not the kind of thing the IETF should be publishing in the first place, since it represents something that could introduce confusion or cruft into the deployed base.  I disagreed with this position because there are existence proofs of Experimental status not observing such constraints.  His objection has not been sustained by the working group generally; one person was concerned about us publishing an experiment of any kind, but this was not enough to give the impression that consensus has eroded.  Nevertheless, the working group is prepared to accept Informational status if the IESG concurs with this objection.

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

No ID nits have been identified.

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

No formal reviews are needed; this document makes no registrations of media types or other major code points.

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

No; all referenced documents are published.

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

This is an experimental document.  There can only be up-refs.

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

This document describes an experiment.  Should the experiment move to the standards track, it will update RFC7489.  RFC7489 was an Independent Submission and therefore currently has Informational status.  RFC7489 is under review by the DMARC working group, which intends to republish it on to the standards track at some future date.  It will take the results of this experiment as input.  However, this document does not formally modify RFC7489.

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

I have reviewed the IANA Considerations section.  It makes a single registration in an extant registry for which Murray is the designated expert.  The section is well-formed and clear.

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

This document creates no new registry.

(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 ABNF, XML, or MIB definition in this document.

The following Last Call announcement was sent out (ends 2021-04-05):

From: The IESG
To: IETF-Announce
CC: alexey.melnikov@isode.com, dmarc-chairs@ietf.org, dmarc@ietf.org, draft-ietf-dmarc-psd@ietf.org, superuser@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Experimental DMARC Extension For Public Suffix Domains) to Experimental RFC


The IESG has received a request from the Domain-based Message Authentication,
Reporting & Conformance WG (dmarc) to consider the following document: -
'Experimental DMARC Extension For Public Suffix Domains'
  as Experimental 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
last-call@ietf.org mailing lists by 2021-04-05. 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


  Domain-based Message Authentication, Reporting, and Conformance
  (DMARC) permits a domain-controlling organization to express domain-
  level policies and preferences for message validation, disposition,
  and reporting, which a mail-receiving organization can use to improve
  mail handling.

  DMARC distinguishes the portion of a name that is a Public Suffix
  Domain (PSD), below which organizational domain names are created.
  The basic DMARC capability allows organizational domains to specify
  policies that apply to their subdomains, but it does not give that
  capability to PSDs.  This document describes an extension to DMARC to
  fully enable DMARC functionality for PSDs.

  Some implementations of DMARC consider a PSD to be ineligible for
  DMARC enforcement.  This specification addresses that case.




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



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?

The intended document status is Experimental, which is shown in the title page header.  This status is appropriate for this document because it specifies a development effort that is intended only to collect data as input to a later revision of the main DMARC specification.  The content has enough community support to be worth implementing and testing on live email traffic feeds to test its efficacy in assisting the accuracy and applicability of DMARC.

(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 (Domain-based Message Authentication, Reporting, and
  Conformance) is a scalable mechanism by which a mail-originating
  organization can express domain-level policies and preferences for
  message validation, disposition, and reporting, that a mail-receiving
  organization can use to improve mail handling.  DMARC policies can be
  applied to individual domains or to all domains within an
  organization.  The design of DMARC precludes grouping policies for
  domains based on policy published above the organizational level,
  such as TLDs (Top Level Domains).  Domains at this higher level of
  the DNS tree (but not necessarily at the top of the DNS tree) can be
  collectively referred to as Public Suffix Domains (PSDs).  This
  document describes an extension to DMARC to enable DMARC
  functionality PSDs.

Working Group Summary

The working group came to consensus fairly quickly about this proposal because it's fairly minimal, straightforward, and well understood.

Document Quality

There is one implementation already (by the author), and numerous operators have expressed intent to participate, including open source and private operators, once the document is approved.

Personnel

Murray Kucherawy is the responsible Area Director, though he was the document shepherd at the time this went to IETF Last Call.
Alexey Melnikov is the new document shepherd.

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

I reviewed the document for both editorial and technical quality.  It has appropriate IANA and Security Considerations sections.  An appropriate WGLC was performed and feedback received was folded in by the author.  The WG secretary also assured that all raised issues were addressed somehow.

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

None; ART and SEC reviews are expected in due course, and otherwise enough of the usual IETF email community and participants in M3AAWG also provided input.

(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 such specialist reviews are needed.

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

The community believes there is a strong need for this work.  As ARC was also recently published as experimental (RFC8617), this is a ripe time for considering ecosystem solutions such as this.

(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 such disclosure has been filed.

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

There are about 15-20 regular active working group participants, and consensus among them for this experimental document appears to be firm.

(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 expressions of appeal-level discontent have been observed so far.  However, it is worth noting here that Dave Crocker raised and pressed an objection that the work should not be published without going back to first principles with DMARC itself, which would set the already glacial working group back months.  Given the WG intends to reopen its base document anyway after this experiment is published, that seems like an unnecessary constraint.  In any case, his assertion does not appear to have swayed consensus away from proceeding.

He also contends that an experiment meant to collect data and then be destroyed is not the kind of thing the IETF should be publishing in the first place, since it represents something that could introduce confusion or cruft into the deployed base.  I disagreed with this position because there are existence proofs of Experimental status not observing such constraints.  His objection has not been sustained by the working group generally; one person was concerned about us publishing an experiment of any kind, but this was not enough to give the impression that consensus has eroded.  Nevertheless, the working group is prepared to accept Informational status if the IESG concurs with this objection.

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

No ID nits have been identified.

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

No formal reviews are needed; this document makes no registrations of media types or other major code points.

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

No; all referenced documents are published.

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

This is an experimental document.  There can only be up-refs.

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

This document describes an experiment.  Should the experiment move to the standards track, it will update RFC7489.  RFC7489 was an Independent Submission and therefore currently has Informational status.  RFC7489 is under review by the DMARC working group, which intends to republish it on to the standards track at some future date.  It will take the results of this experiment as input.  However, this document does not formally modify RFC7489.

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

I have reviewed the IANA Considerations section.  It makes a single registration in an extant registry for which I am the designated expert.  The section is well-formed and clear.

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

This document creates no new registry.

(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 ABNF, XML, or MIB definition in this document.  There's not even ASCII art.  Stop smothering me.

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

The intended document status is Experimental, which is shown in the title page header.  This status is appropriate for this document because it specifies a development effort that is intended only to collect data as input to a later revision of the main DMARC specification.  The content has enough community support to be worth implementing and testing on live email traffic feeds to test its efficacy in assisting the accuracy and applicability of DMARC.

(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 (Domain-based Message Authentication, Reporting, and
  Conformance) is a scalable mechanism by which a mail-originating
  organization can express domain-level policies and preferences for
  message validation, disposition, and reporting, that a mail-receiving
  organization can use to improve mail handling.  DMARC policies can be
  applied to individual domains or to all domains within an
  organization.  The design of DMARC precludes grouping policies for
  domains based on policy published above the organizational level,
  such as TLDs (Top Level Domains).  Domains at this higher level of
  the DNS tree (but not necessarily at the top of the DNS tree) can be
  collectively referred to as Public Suffix Domains (PSDs).  This
  document describes an extension to DMARC to enable DMARC
  functionality PSDs.

Working Group Summary

The working group came to consensus fairly quickly about this proposal because it's fairly minimal, straightforward, and well understood.

Document Quality

There is one implementation already (by the author), and numerous operators have expressed intent to participate, including open source and private operators, once the document is approved.

Personnel

Murray Kucherawy is the responsible Area Director, though he was the document shepherd at the time this went to IETF Last Call.
Alexey Melnikov is the new document shepherd.

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

I reviewed the document for both editorial and technical quality.  It has appropriate IANA and Security Considerations sections.  An appropriate WGLC was performed and feedback received was folded in by the author.  The WG secretary also assured that all raised issues were addressed somehow.

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

None; ART and SEC reviews are expected in due course, and otherwise enough of the usual IETF email community and participants in M3AAWG also provided input.

(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 such specialist reviews are needed.

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

The community believes there is a strong need for this work.  As ARC was also recently published as experimental (RFC8617), this is a ripe time for considering ecosystem solutions such as this.

(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 such disclosure has been filed.

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

There are about 15-20 regular active working group participants, and consensus among them for this experimental document appears to be firm.

(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 expressions of appeal-level discontent have been observed so far.  However, it is worth noting here that Dave Crocker raised and pressed an objection that the work should not be published without going back to first principles with DMARC itself, which would set the already glacial working group back months.  Given the WG intends to reopen its base document anyway after this experiment is published, that seems like an unnecessary constraint.  In any case, his assertion does not appear to have swayed consensus away from proceeding.

He also contends that an experiment meant to collect data and then be destroyed is not the kind of thing the IETF should be publishing in the first place, since it represents something that could introduce confusion or cruft into the deployed base.  I disagreed with this position because there are existence proofs of Experimental status not observing such constraints.  His objection has not been sustained by the working group generally; one person was concerned about us publishing an experiment of any kind, but this was not enough to give the impression that consensus has eroded.  Nevertheless, the working group is prepared to accept Informational status if the IESG concurs with this objection.

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

No ID nits have been identified.

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

No formal reviews are needed; this document makes no registrations of media types or other major code points.

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

No; all referenced documents are published.

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

This is an experimental document.  There can only be up-refs.

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

This document describes an experiment.  Should the experiment move to the standards track, it will update RFC7489.  RFC7489 was an Independent Submission and therefore currently has Informational status.  RFC7489 is under review by the DMARC working group, which intends to republish it on to the standards track at some future date.  It will take the results of this experiment as input.  However, this document does not formally modify RFC7489.

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

I have reviewed the IANA Considerations section.  It makes a single registration in an extant registry for which I am the designated expert.  The section is well-formed and clear.

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

This document creates no new registry.

(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 ABNF, XML, or MIB definition in this document.  There's not even ASCII art.  Stop smothering me.

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

The IANA Functions Operator has completed its review of draft-ietf-dmarc-psd-08. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the DMARC Tag Registry on the Domain-based Message Authentication, Reporting, and Conformance (DMARC) Parameters registry page located at:

https://www.iana.org/assignments/dmarc-parameters/

a new registration is to be made as follows:

Tag Name: np
Reference: [ RFC-to-be ]
Status: current
Description: Requested handling policy for non-existent subdomains

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. We are currently requesting that an expert be designated for this registry. This review must be completed before the document's IANA state can be changed to "IANA OK."

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-04-08):

From: The IESG
To: IETF-Announce
CC: dmarc@ietf.org, superuser@gmail.com, draft-ietf-dmarc-psd@ietf.org, alexey.melnikov@isode.com, Murray Kucherawy , dmarc-chairs@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (DMARC (Domain-based Message Authentication, Reporting, and Conformance) Extension For PSDs (Public Suffix Domains)) to Experimental RFC


The IESG has received a request from the Domain-based Message Authentication,
Reporting & Conformance WG (dmarc) to consider the following document: -
'DMARC (Domain-based Message Authentication, Reporting, and
  Conformance) Extension For PSDs (Public Suffix Domains)'
  as Experimental 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
last-call@ietf.org mailing lists by 2020-04-08. 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 (Domain-based Message Authentication, Reporting, and
  Conformance) is a scalable mechanism by which a mail-originating
  organization can express domain-level policies and preferences for
  message validation, disposition, and reporting, that a mail-receiving
  organization can use to improve mail handling.  The design of DMARC
  presumes that domain names represent either nodes in the tree below
  which registrations occur, or nodes where registrations have
  occurred; it does not permit a domain name to have both of these
  properties simultaneously.  Since its deployment in 2015, use of
  DMARC has shown a clear need for the ability to express policy for
  these domains as well.

  Domains at which registrations can occur are referred to as Public
  Suffix Domains (PSDs).  This document describes an extension to DMARC
  to enable DMARC functionality for PSDs.

  This document also seeks to address implementations that consider a
  domain on a public Suffix list to be ineligible for DMARC
  enforcement.




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

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/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?

The intended document status is Experimental, which is shown in the title page header.  This status is appropriate for this document because it specifies a development effort that is intended only to collect data as input to a later revision of the main DMARC specification.  The content has enough community support to be worth implementing and testing on live email traffic feeds to test its efficacy in assisting the accuracy and applicability of DMARC.

(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 (Domain-based Message Authentication, Reporting, and
  Conformance) is a scalable mechanism by which a mail-originating
  organization can express domain-level policies and preferences for
  message validation, disposition, and reporting, that a mail-receiving
  organization can use to improve mail handling.  DMARC policies can be
  applied to individual domains or to all domains within an
  organization.  The design of DMARC precludes grouping policies for
  domains based on policy published above the organizational level,
  such as TLDs (Top Level Domains).  Domains at this higher level of
  the DNS tree (but not necessarily at the top of the DNS tree) can be
  collectively referred to as Public Suffix Domains (PSDs).  This
  document describes an extension to DMARC to enable DMARC
  functionality PSDs.

Working Group Summary

The working group came to consensus fairly quickly about this proposal because it's fairly minimal, straightforward, and well understood.

Document Quality

There is one implementation already (by the author), and numerous operators have expressed intent to participate, including open source and private operators, once the document is approved.

Personnel

Murray Kucherawy is the document shepherd.
Alexey Melnikov 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.

I reviewed the document for both editorial and technical quality.  It has appropriate IANA and Security Considerations sections.  An appropriate WGLC was performed and feedback received was folded in by the author.  The WG secretary also assured that all raised issues were addressed somehow.

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

None; ART and SEC reviews are expected in due course, and otherwise enough of the usual IETF email community and participants in M3AAWG also provided input.

(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 such specialist reviews are needed.

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

The community believes there is a strong need for this work.  As ARC was also recently published as experimental (RFC8617), this is a ripe time for considering ecosystem solutions such as this.

(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 such disclosure has been filed.

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

There are about 15-20 regular active working group participants, and consensus among them for this experimental document appears to be firm.

(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 expressions of appeal-level discontent have been observed so far.  However, it is worth noting here that Dave Crocker raised and pressed an objection that the work should not be published without going back to first principles with DMARC itself, which would set the already glacial working group back months.  Given the WG intends to reopen its base document anyway after this experiment is published, that seems like an unnecessary constraint.  In any case, his assertion does not appear to have swayed consensus away from proceeding.

He also contends that an experiment meant to collect data and then be destroyed is not the kind of thing the IETF should be publishing in the first place, since it represents something that could introduce confusion or cruft into the deployed base.  I disagreed with this position because there are existence proofs of Experimental status not observing such constraints.  His objection has not been sustained by the working group generally; one person was concerned about us publishing an experiment of any kind, but this was not enough to give the impression that consensus has eroded.  Nevertheless, the working group is prepared to accept Informational status if the IESG concurs with this objection.

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

No ID nits have been identified.

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

No formal reviews are needed; this document makes no registrations of media types or other major code points.

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

No; all referenced documents are published.

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

This is an experimental document.  There can only be up-refs.

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

This document describes an experiment.  Should the experiment move to the standards track, it will update RFC7489.  RFC7489 was an Independent Submission and therefore currently has Informational status.  RFC7489 is under review by the DMARC working group, which intends to republish it on to the standards track at some future date.  It will take the results of this experiment as input.  However, this document does not formally modify RFC7489.

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

I have reviewed the IANA Considerations section.  It makes a single registration in an extant registry for which I am the designated expert.  The section is well-formed and clear.

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

This document creates no new registry.

(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 ABNF, XML, or MIB definition in this document.  There's not even ASCII art.  Stop smothering me.

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

The intended document status is Experimental, which is shown in the title page header.  This status is appropriate for this document because it specifies a development effort that is intended only to collect data as input to a later revision of the main DMARC specification.  The content has enough community support to be worth implementing and testing on live email traffic feeds to test its efficacy in assisting the accuracy and applicability of DMARC.

(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 (Domain-based Message Authentication, Reporting, and
  Conformance) is a scalable mechanism by which a mail-originating
  organization can express domain-level policies and preferences for
  message validation, disposition, and reporting, that a mail-receiving
  organization can use to improve mail handling.  DMARC policies can be
  applied to individual domains or to all domains within an
  organization.  The design of DMARC precludes grouping policies for
  domains based on policy published above the organizational level,
  such as TLDs (Top Level Domains).  Domains at this higher level of
  the DNS tree (but not necessarily at the top of the DNS tree) can be
  collectively referred to as Public Suffix Domains (PSDs).  This
  document describes an extension to DMARC to enable DMARC
  functionality PSDs.

Working Group Summary

The working group came to consensus fairly quickly about this proposal because it's fairly minimal, straightforward, and well understood.

Document Quality

There is one implementation already (by the author), and numerous operators have expressed intent to participate, including open source and private operators, once the document is approved.

Personnel

Murray Kucherawy is the document shepherd.
Alexey Melnikov 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.

I reviewed the document for both editorial and technical quality.  It has appropriate IANA and Security Considerations sections.  An appropriate WGLC was performed and feedback received was folded in by the author.  The WG secretary also assured that all raised issues were addressed somehow.

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

None; ART and SEC reviews are expected in due course, and otherwise enough of the usual IETF email community and participants in M3AAWG also provided input.

(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 such specialist reviews are needed.

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

The community believes there is a strong need for this work.  As ARC was also recently published as experimental (RFC8617), this is a ripe time for considering ecosystem solutions such as this.

(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 such disclosure has been filed.

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

There are about 15-20 regular active working group participants, and consensus among them for this experimental document appears to be firm.

(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 expressions of appeal-level discontent have been observed so far.  However, it is worth noting here that Dave Crocker raised and pressed an objection that the work should not be published without going back to first principles with DMARC itself, which would set the already glacial working group back months.  Given the WG intends to reopen its base document anyway after this experiment is published, that seems like an unnecessary constraint.  In any case, his assertion does not appear to have swayed consensus away from proceeding.

He also contends that an experiment meant to collect data and then be destroyed is not the kind of thing the IETF should be publishing in the first place, since it represents something that could introduce confusion or cruft into the deployed base.  I disagreed with this position because there are existence proofs of Experimental status not observing such constraints.  His objection has not been sustained by the working group generally; one person was concerned about us publishing an experiment of any kind, but this was not enough to give the impression that consensus has eroded.  Nevertheless, the working group is prepared to accept Informational status if the IESG concurs with this objection.

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

No ID nits have been identified.

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

No formal reviews are needed; this document makes no registrations of media types or other major code points.

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

No; all referenced documents are published.

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

This is an experimental document.  There can only be up-refs.

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

This document describes an experiment.  Should the experiment move to the standards track, it will update RFC7489.  RFC7489 was an Independent Submission and therefore currently has Informational status.  RFC7489 is under review by the DMARC working group, which intends to republish it on to the standards track at some future date.  It will take the results of this experiment as input.  However, this document does not formally modify RFC7489.

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

I have reviewed the IANA Considerations section.  It makes a single registration in an extant registry for which I am the designated expert.  The section is well-formed and clear.

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

This document creates no new registry.

(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 ABNF, XML, or MIB definition in this document.  There's not even ASCII art.  Stop smothering me.

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

The intended document status is Experimental.  This status is appropriate for this document because it specifies a development effort that is intended only to collect data as input to a later revision of the main DMARC specification.  The conent has enough community support to be worth implementing and testing on live email traffic feeds to test its efficacy in assisting the accuracy and applicability of DMARC.

(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 (Domain-based Message Authentication, Reporting, and
  Conformance) is a scalable mechanism by which a mail-originating
  organization can express domain-level policies and preferences for
  message validation, disposition, and reporting, that a mail-receiving
  organization can use to improve mail handling.  DMARC policies can be
  applied to individual domains or to all domains within an
  organization.  The design of DMARC precludes grouping policies for
  domains based on policy published above the organizational level,
  such as TLDs (Top Level Domains).  Domains at this higher level of
  the DNS tree (but not necessarily at the top of the DNS tree) can be
  collectively referred to as Public Suffix Domains (PSDs).  This
  document describes an extension to DMARC to enable DMARC
  functionality PSDs.

Working Group Summary

The working group game to consensus fairly quickly about this proposal because it's fairly minimal, straightforward, and well understood.  Also, since it's purely experimental for now, there was little concern about being exceedingly tough about rolling it out.

Document Quality

There is one implementation already (by the author), and numerous operators have expressed intent to participate, including open source and private operators.

Personnel

Murray Kucherawy is the document shepherd.
Alexey Melnikov 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.

I reviewed the document for both editorial and technical quality.  It has appropriate IANA and Security Considerations sections.  An appropriate WGLC was performed and feedback received was folded in by the author.  The WG secretary also assured that all raised issues were resolved somehow.

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

None; ART and SEC reviews are expected in due course, and otherwise enough of the usual IETF email community and participants in M3AAWG also provided input.

(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 such specialist reviews are needed.

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

The community believes there is a strong need for this work.  As ARC was also recently published as experimental (RFC8617), this is a ripe time for considering ecosystem solutions such as this.

(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 such disclosure has been filed.

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

There are about 15-20 regular active working group participants, and consensus among them for this experimental document appears to be firm.

(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 expressions of appeal-level discontent have been observed so far.  However, it is worth noting here that Dave Crocker raised and pressed an objection that the work should not be published without going back to first principles with DMARC itself, which would set the already glacial working group back months.  Given the WG intends to reopen its base document anyway after this experiment is published, that seems like an unnecessary constraint.  In any case, his assertion does not appear to have swayed consensus away from proceeding.

He also contends that an experiment meant to collect data and then be destroyed is not the kind of thing the IETF should be publishing in the first place, since it represents something that could introduce confusion or cruft into the deployed base.  I disagreed with this position because there are existence proofs of Experimental status not observing such constraints.  His objection has not been sustained by the working group generally; one person was concerned about us publishing an experiment of any kind, but this was not enough to give the impression that consensus has eroded.

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

No ID nits have been identified.

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

No formal reviews are needed; this document makes no registrations of media types or other major code points.

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

No; all referenced documents are published.

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

This is an experimental document.  There can only be up-refs.

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

This document describes an experiment.  Should the experiment move to the standards track, it will update RFC7489.  RFC7489 was an Independent Submission and therefore currently has Informational status.  RFC7489 is under review by the DMARC working group, which may republish it on to the standards track at some future date.  It will take the results of this experiment as input.  However, this document does not formally modify RFC7489.

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

I have reviewed the IANA Considerations section.  It makes a single registration in an extant registry.  The section is well-formed and clear.

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

This document creates no new registry.

(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 ABNF, XML, or MIB definition in this document.  There's not even ASCII art.  Stop smothering me.

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

The intended document status is Experimental.  This status is appropriate for this document because it specifies a development effort that is intended only to collect data as input to a later revision of the main DMARC specification.  The conent has enough community support to be worth implementing and testing on live email traffic feeds to test its efficacy in assisting the accuracy and applicability of DMARC.

(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 (Domain-based Message Authentication, Reporting, and
  Conformance) is a scalable mechanism by which a mail-originating
  organization can express domain-level policies and preferences for
  message validation, disposition, and reporting, that a mail-receiving
  organization can use to improve mail handling.  DMARC policies can be
  applied to individual domains or to all domains within an
  organization.  The design of DMARC precludes grouping policies for
  domains based on policy published above the organizational level,
  such as TLDs (Top Level Domains).  Domains at this higher level of
  the DNS tree (but not necessarily at the top of the DNS tree) can be
  collectively referred to as Public Suffix Domains (PSDs).  This
  document describes an extension to DMARC to enable DMARC
  functionality PSDs.

Working Group Summary

The working group game to consensus fairly quickly about this proposal because it's fairly minimal, straightforward, and well understood.  Also, since it's purely experimental for now, there was little concern about being exceedingly tough about rolling it out.

Document Quality

There is one implementation already (by the author), and numerous operators have expressed intent to participate, including open source and private operators.

Personnel

Murray Kucherawy is the document shepherd.
Alexey Melnikov 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.

I reviewed the document for both editorial and technical quality.  It has appropriate IANA and Security Considerations sections.  An appropriate WGLC was performed and feedback received was folded in by the author.  The WG secretary also assured that all raised issues were resolved somehow.

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

None; ART and SEC reviews are expected in due course, and otherwise enough of the usual IETF email community and participants in M3AAWG also provided input.

(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 such specialist reviews are needed.

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

The community believes there is a strong need for this work.  As ARC was also recently published as experimental (RFC8617), this is a ripe time for considering ecosystem solutions such as this.

(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 such disclosure has been filed.

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

There are about 15-20 regular active working group participants, and consensus among them for this experimental document appears to be firm.

(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 expressions of appeal-level discontent have been observed so far.  However, Dave Crocker raised and pressed an objection that the work should not be published without going back to first principles with DMARC itself, which would set the already glacial working group back months.  He also contends that an experiment meant to collect data and then be destroyed is not the kind of thing the IETF should be publishing in the first place, since it represents something that could introduce confusion or cruft into the deployed base.  I proposed a compromise that we conduct the experiment for a limited time and then deliberately tear down its structure, assuring that it cannot endure in the infrastructure past conclusion of the experiment.

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

No ID nits have been identified.

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

No formal reviews are needed; this document makes no registrations of media types or other major code points.

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

No; all referenced documents are published.

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

This is an experimental document.  There can only be up-refs.

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

This document describes an experiment.  Should the experiment move to the standards track, it will update RFC7489.  RFC7489 was an Independent Submission and therefore currently has Informational status.  RFC7489 is under review by the DMARC working group, which may republish it on to the standards track at some future date.  It will take the results of this experiment as input.  However, this document does not formally modify RFC7489.

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

I have reviewed the IANA Considerations section.  It makes a single registration in an extant registry.  The section is well-formed and clear.

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

This document creates no new registry.

(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 ABNF, XML, or MIB definition in this document.  There's not even ASCII art.  Stop smothering me.

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

The intended document status is Experimental.  This status is appropriate for this document because it specifies a development effort that is not yet ready for standardization, but has enough community support to be worth implementing and testing on live email traffic feeds to test its efficacy in assisting the accuracy and applicability of DMARC.

(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 (Domain-based Message Authentication, Reporting, and
  Conformance) is a scalable mechanism by which a mail-originating
  organization can express domain-level policies and preferences for
  message validation, disposition, and reporting, that a mail-receiving
  organization can use to improve mail handling.  DMARC policies can be
  applied to individual domains or to all domains within an
  organization.  The design of DMARC precludes grouping policies for
  domains based on policy published above the organizational level,
  such as TLDs (Top Level Domains).  Domains at this higher level of
  the DNS tree (but not necessarily at the top of the DNS tree) can be
  collectively referred to as Public Suffix Domains (PSDs).  This
  document describes an extension to DMARC to enable DMARC
  functionality PSDs.

Working Group Summary

The working group game to consensus fairly quickly about this proposal because it's fairly minimal, straightforward, and well understood.  Also, since it's purely experimental for now, there was little concern about being exceedingly tough about rolling it out.

Document Quality

There is one implementation already (by the author), and numerous operators have expressed intent to participate, including open source and private operators.

Personnel

Murray Kucherawy is the document shepherd.
Alexey Melnikov 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.

I reviewed the document for both editorial and technical quality.  It has appropriate IANA and Security Considerations sections.  An appropriate WGLC was performed and feedback received was folded in by the author.  The WG secretary also assured that all raised issues were resolved somehow.

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

None; ART and SEC reviews are expected in due course, and otherwise enough of the usual IETF email community and participants in M3AAWG also provided input.

(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 such specialist reviews are needed.

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

The community believes there is a strong need for this work.  As ARC was also recently published as experimental (RFC8617), this is a ripe time for considering ecosystem solutions such as this.

(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 such disclosure has been filed.

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

There are about 20 regular active working group participants, and consensus among them for this experimental document appears to be firm.

(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 expressions of discontent have been observed.

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

No ID nits have been identified.

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

No formal reviews are needed; this document makes no registrations of media types or other major code points.

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

No; all referenced documents are published.

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

This is an experimental document.  There can only be up-refs.

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

This document describes an experiment.  Should the experiment move to the standards track, it will update RFC7489.  RFC7489 was an Independent Submission and therefore currently has Informational status.  RFC7489 is under review by the DMARC working group, which may republish it on to the standards track at some future date.  It will take the results of this experiment as input.  However, this document does not formally modify RFC7489.

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

I have reviewed the IANA Considerations section.  It makes a single registration in an extant registry.  The section is well-formed and clear.

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

This document creates no new registry.

(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 ABNF, XML, or MIB definition in this document.  There's not even ASCII art.  Stop smothering me.