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

Lars Eggert via Datatracker <noreply@ietf.org> Wed, 14 April 2021 08:44 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: dmarc@ietf.org
Delivered-To: dmarc@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D753A1590; Wed, 14 Apr 2021 01:44:38 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Lars Eggert via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dmarc-psd@ietf.org, dmarc-chairs@ietf.org, dmarc@ietf.org, alexey.melnikov@isode.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.27.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Lars Eggert <lars@eggert.org>
Message-ID: <161838987873.7792.14994930450767048926@ietfa.amsl.com>
Date: Wed, 14 Apr 2021 01:44:38 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/ac2ADbJw19mrRuTXDUBKk9EGAyQ>
Subject: [dmarc-ietf] Lars Eggert's No Objection on draft-ietf-dmarc-psd-12: (with COMMENT)
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Apr 2021 08:44:39 -0000

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