Subject: [Last-Call] Opsdir last call review of draft-ietf-dmarc-psd-08

From: Qin Wu via Datatracker <[email-masked]>
Date: Wed, 01 Apr 2020 00:06:54 -0700

Reviewer: Qin Wu
Review result: Ready

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.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 1 Apr 2020 18:04:57 -0700

On the process questions raised:

> which functionality is not.

It's helpful here, I think, that the IANA Considerations section includes
the IANA stuff, and an Appendix contains the other stuff.  I don't think
this is particularly confusing; the two are well-separated.

> abbreviation section in the terminology section.

This is an experiment to see if RFC7489 should be augmented, i.e., is the
experiment described here useful to DMARC?  If it turns out it is not, then
saying this updated the base specification wouldn't be such a good thing.
If it turns out that it is, then the DMARCbis work (which is about to start
up) will incorporate the experiment such that it becomes permanent.

Section 3.2
> applicable to other places.

I'll leave this bit to the authors and co-chairs to resolve.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 02 Apr 2020 06:20:29 -0400

> On Wed, Apr 1, 2020 at 12:06 AM Qin Wu via Datatracker <[email-masked]>
...

Since I'm the draft author, I'll weigh in:

> > and ‘p’tag is present), MUST be applied for non-existent subdomains. "

The current text is crafted to define the new tag the same way that the 
existing tags are defined.  I would prefer not to be novel about 'np'.  I think 
this would be better as a working group input for DMARCbis to consider 
rewording how all the tag definitions are constructed.  In this case I think 
consistency is important.

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

I have no problem with this proposed change.  I think it improves clarity.
> I'll leave this bit to the authors and co-chairs to resolve.

That's my thought.  I'll wait for the co-chairs before taking any actions to 
update the draft.

Scott K

---

From: Seth Blank <[email-masked]>
Date: Thu, 2 Apr 2020 08:33:30 -0700

> That's my thought.  I'll wait for the co-chairs before taking any actions

Scott, please prepare a new version of the I-D based upon your comments,
but don't post it until IETF Last Call finishes and all other feedback, if
any, has been folded in.

Seth, as co-Chair

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 02 Apr 2020 14:48:54 -0400

> but don't post it until IETF Last Call finishes and all other feedback, if

Done.  The updated version (XML, text, and rfcdiff) can be found in the WG 
GitHub repository [1].

Scott K

[1] https://github.com/ietf-dmarc-wg/draft-ietf-dmarc-psd