Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

["Murray S. Kucherawy" <[e-mail]>]

On Tue, Jan 19, 2021 at 2:31 AM Alessandro Vesely <[e-mail]> wrote:

> I guess "[this document]" refers to the RFC number to be.  I think it's
> useless
> and can be safely removed, all of the five occurrences of it.
>

That's fine too.

>> I believe that my strongest critique was that section 1 is difficult to
> >> understand if one does not already understand DMARC, and it does not
> >> seem that the section has been revised.  Re-reading it, I notice that it
> >> says "DMARC leverages public suffix lists to determine which domains are
> >> organizational domains."  [...]
>
> In fact, those are the two terms appearing in the title.  BTW, I'd change
> the
> title to:
>
>      Domain-based Message Authentication, Reporting, and Conformance
> (DMARC)
>      Extension For Public Suffix Domains (PSDs)
>
> Anyway, I agree it is correct to introduce /both/ terms.
>

I think that's needlessly verbose.  A compromise:

"Experimental DMARC Extension for Public Suffix Domains"

>     To determine the organizational domain for a message under evaluation,
> >     and thus where to look for a policy statement, DMARC makes use of a
> >     Public Suffix List.
> >     The process for doing this can be found in Section 3.2 of the DMARC
> >     specification.
>
> Couldn't we skip that kind of functional intro and say something general,
> such
> as anticipating Section 2.2:
>
>      Public Suffix Domains (PSDs) are domain names publicly accessible for
>      domain registration.  As explained in Section 2.2, they include all
> top
>      level domains and some more.  The way delegations occur on the global
>      Internet makes it difficult to establish whether a domain is a PSD.  A
>      community maintained Public Suffix List (PSL) exists for that purpose.
>
> Thinking twice, perhaps we don't need to introduce the PSL until Section
> 3.4.
> In that case, strike the last two sentences of the above paragraph.
>

It's not obvious to me that this is better, but sure, let's discuss it.

>     DMARC as specified presumes that domain names present in a PSL are not
> >     organizational domains and thus not subject to DMARC processing;
> domains
> >     are either organizational domains, sub-domains of organizational
> >     domains, or listed on a PSL.  For domains listed in a
> >     PSL, i.e., TLDs and domains that exist between TLDs and
> >     organization level domains, policy can only be published for the
> >     exact domain.
>
> That's still overly specific for an introduction.  It only serves to
> present
> the concept that there are domains that are not actually organizational
> domains
> but are characterized by a sort of organizational flavor.  The "these
> domains"
> of the following sentence.  We don't need seven lines of text for that.
>

This is text in -09, not something I'm adding.  Apparently this context was
valuable before.

>> Looking at the second paragraph of section 1, I notice that despite all
> >> the special terms for classifying domain names in section 2, the example
> >> in this section does not describe which of the domain names that it
> >> mentions fall into which of these classes.  E.g. "tax.gov.example" is
> >> said to be registered, but it looks like it is also the organizational
> >> domain, and "gov.example" is its longest PSD.  It would also help to
> >> mention that "tax.gov.example" is "registered at" "gov.example" to
> >> introduce the details of the usage "registered at".
> >>
> >>     Suppose there exists a domain "tax.gov.example" (registered at
> >>     "gov.example") ...
> >>
> >
> > Introduce a new Section 1.1: "Example" with this:
>
> I don't fully agree.  The example only lasts until the end of page 3.
> From
> page 4 on, the text describes the core of the experiment, so it shouldn't
> be
> under an "Example" heading.  If we skip the PSL, the example remains quite
> compact even after adding those "registered at".
>

I don't think you read my suggestion correctly.  I proposed a new Section
1.2 to contain the text you're talking about.  You cited it below but
appear to have missed it.

> A suggestion for 2.4:
> >
> > NEW:
> >
> > The longest PSD is the Organizational Domain with one label removed.
> > It names the immediate parent node of the Organizational Domain in the
> > DNS namespace tree.
>
> s/one/the leftmost/
>

Sure.

-MSK