Last Call Review of draft-ietf-dmarc-psd-08
review-ietf-dmarc-psd-08-opsdir-lc-wu-2020-04-01-00

Request Review of draft-ietf-dmarc-psd
Requested rev. no specific revision (document currently at 08)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2020-04-08
Requested 2020-03-18
Authors Scott Kitterman
Draft last updated 2020-04-01
Completed reviews Genart Last Call review of -08 by Dale Worley
Secdir Last Call review of -08 by Sandra Murphy
Opsdir Last Call review of -08 by Qin Wu
Assignment Reviewer Qin Wu
State Completed
Review review-ietf-dmarc-psd-08-opsdir-lc-wu-2020-04-01
Posted at https://mailarchive.ietf.org/arch/msg/ops-dir/m1gc194W2KxexISg-ieSIQ2yj74
Reviewed rev. 08
Review result Ready
Review completed: 2020-04-01

Review
review-ietf-dmarc-psd-08-opsdir-lc-wu-2020-04-01

I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

This document defines DMARC (Domain-based Message Authentication, Reporting, and Conformance) extension to enable DMARC functionality for Public Suffix Domains. It allows operators of Public Suffix Domains (PSDs) to express policy at the level of the PSD that covers all organizational domains that do not explicitly publish DMARC records.

Major issue:
Not found

Minor issue:
This document provide two registries, one is update of DMARC Tag Registry with one new element, requested from IANA, the other is DMARC PSD registry maintained by [psddmarc.org] and following IANA registry style, I see one is standard registry, the other is non-standard registry, it is not clear to me non-standard registry should be discussed in this document, which introduce confusion, if we keep both, I am wondering why section 6 still requests to add an element to standard registry, which functionality we add is experimental, which functionality is not.

Second related question, this draft updates informational RFC7489 with additional components and rules, should the front page of this Experimental RFC reflect this or not?
Nits:
Section 1
Somewhere subdommains is used, somewhere sub-dommains is used, please be consistent.
Section 3.5 said:
"Specifically, this is
   not a mechanism to provide feedback addresses (RUA/RUF) when an
   Organizational Domain has declined to do so.
"
Should a reference be added to RUA/RUF, RUA/RUF needs to be expanded or add abbreviation section in the terminology section.

Section 3.2
 OLD TEXT:
"
If the 'np' tag is absent, the policy specified by the "sp" tag (if the 'sp' tag is present) or the policy specified by the "p" tag, if the 'sp' tag is not present, MUST be applied for non-existent subdomains. 
"
NEW TEXT:
"
If the 'np' tag is absent, the policy specified by the "sp" tag (if the 'sp' tag is present) or the policy specified by the "p" tag( if the 'sp' tag is not present and ‘p’tag is present), MUST be applied for non-existent subdomains. 
"
Section 3.2
Change section 3.2 title from 
"3.2.  Section 6.3 General Record Format"
To 
3.2.  Changes in Section 6.3 "General Record Format"
Similar changes can be applicable to other places.