Skip to main content

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

Yes

Murray Kucherawy

No Objection

Erik Kline
(Alvaro Retana)
(Martin Vigoureux)

Note: This ballot was opened for revision 12 and is now closed.

Murray Kucherawy
Yes
Erik Kline
No Objection
Roman Danyliw
No Objection
Comment (2021-04-21 for -12) Sent
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”)
Éric Vyncke
No Objection
Comment (2021-04-15 for -12) Sent
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.
Alvaro Retana Former IESG member
No Objection
No Objection (for -12) Not sent

                            
Benjamin Kaduk Former IESG member
(was Discuss) No Objection
No Objection (2021-05-25 for -13) Sent for earlier
Thank you for addressing my discuss point.
Lars Eggert Former IESG member
No Objection
No Objection (2021-04-14 for -12) Sent
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
+                                                                    +
Martin Vigoureux Former IESG member
No Objection
No Objection (for -12) Not sent

                            
Robert Wilton Former IESG member
No Objection
No Objection (2021-04-19 for -12) Sent
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