Subject: [dmarc-ietf] Lars Eggert's No Objection on draft-ietf-dmarc-psd-12: (with COMMENT)

From: Lars Eggert via Datatracker <[email-masked]>
Date: Wed, 14 Apr 2021 01:44:38 -0700

Lars Eggert has entered the following ballot position for
draft-ietf-dmarc-psd-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/

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

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 15 Apr 2021 19:45:00 -0400

Lars

See below. Thanks for the comments

> https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/
"To participate in this experiment, implementations should nterept RFC7489
as follows"

> Section 7.3, paragraph 1, comment:

This appears to be some artifact of the XML as the URI is listed in the
Informative
Reference section.

> reference in that section, so why not this one?

I believe I've corrected all of these quote mismatches (that is, I've found
all the
single quoted mentions and have updated them to double quotes).

> with the RFC number of this document (to make sure they are aware of the
Done

> +    DMARC [RFC7489] provides a mechanism for publishing organizational
Fixed

> organizational domains and are
Fixed

> +    handling policy for non-existent subdomains.  This is provided
Fixed

> +    (i.e., if a DMARC record were published for 'example', then mail from
Fixed

> Fixed

> Fixed

> +    supposed to be the output domain of the regular PSL lookup, i.e.,  the
Fixed