--- draft-ietf-dmarc-psd-tim.xml	2021-01-24 18:50:28.355829817 +0100
+++ draft-ietf-dmarc-psd-ale.xml	2021-01-29 18:58:35.349494946 +0100
@@ -42,14 +42,14 @@
    <keyword>TLD</keyword>
 
    <abstract>
-      <t>DMARC (Domain-based Message Authentication, Reporting, and
-         Conformance) is a scalable mechanism by which a mail-originating
+      <t>Domain-based Message Authentication, Reporting, and
+         Conformance (DMARC) is a scalable mechanism by which a mail-originating
          organization can express domain-level policies and preferences for
          message validation, disposition, and reporting, that a mail-receiving
-         organization can use to improve mail handling.  The design of DMARC
-         presumes that domain names represent either nodes in the tree below
-         which registrations occur, or nodes where registrations have occurred;
-         it does not permit a domain name to have both of these properties
+         organization can use to improve mail handling.</t>
+       <t>Internet domain names can be represented by a tree.  There are nodes below
+         which registrations occur, and nodes where registrations have occurred.
+         DMARC does not permit a domain name to have both of these properties
          simultaneously.  Since its deployment in 2015, use of DMARC has shown
          a clear need for the ability to express policy for these domains as
          well.</t>
@@ -57,7 +57,7 @@
          Suffix Domains (PSDs).  This document describes an extension to DMARC
          to enable DMARC functionality for PSDs.</t>
       <t>This document also seeks to address implementations that consider a
-         domain on a public Suffix list to be ineligible for DMARC
+         Public Suffix Domain to be ineligible for DMARC
          enforcement.</t>
    </abstract>
  </front>
@@ -68,42 +68,47 @@
         organizational policy information to email receivers.  DMARC allows policy to be
         specified for both individual domains and for organizational domains
         and their sub-domains within a single organization.</t>
-     <t>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.</t>
-     <t>DMARC as specified presumes that domain names present in a PSL are not
+     <t>Representing Internet domain names in a tree, Public Suffix Domains (PSD)
+        are those right below or near to the top of the tree, which is the root.
+        DMARC allows Organizational Domains, which are those right below a PSD,
+        to publish a policy.  Subdomains can publish their policy too,
+        overriding the policy of their Organizational Domain.  However,
+        PSD currently cannot.  In other words,
+        DMARC as specified presumes that PSDs 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
+        domains, or PSDs.  For a
+        PSD, i.e., TLDs and domains that exist between TLDs and
         organization level domains, policy can only be published for the
         exact domain.  No method is available for these domains to express
         policy or receive feedback reporting for sub-domains.  This missing
         method allows for the abuse of non-existent organizational-level
         domains and prevents identification of domain abuse in email.</t>
-     <t>This document specifies experimental updates to the DMARC and PSL
-        algorithm cited above, in an attempt to mitigate this abuse.</t>
+     <t>This document specifies experimental updates to DMARC and to the
+        algorithm to locate Organizational Domains, in an attempt to mitigate this abuse.
+        A standards track update to <xref target="RFC7489"/> will take
+        into account the results of this experiment.</t>
    <section anchor="example" title="Example">
      <t>As an example, imagine a country code TLD (ccTLD) which has public
         subdomains for government and commercial use (".gov.example" and
-        ".com.example").  A PSL whose maintainer is aware of this country's
-        domain structurewould include entries for both of these in the PSL, indicating that they are PSDs below which registrations can occur.
+        ".com.example").
         Suppose further that there exists a domain "tax.gov.example",
         registered within ".gov.example", that is responsible for taxation
         in this imagined country.</t>
-     <t>However, by exploiting the typically unauthenticated nature
+     <t>By exploiting the typically unauthenticated nature
        of email, there are regular malicious campaigns to impersonate this
        organization that use similar-looking ("cousin") domains such as
        "t4x.gov.example".  Such domains are not registered.</t>
-     <t>Within the ".gov.example" public suffix, use of DMARC has been mandated,
-        so "gov.example" publishes the following DMARC DNS record:
+     <t>The domain "gov.example" is a PSD, albeit presumably only qualified
+        organizations can register domains under it.  Use of DMARC has
+        been mandated for domains published under it.
+        so "tax.gov.example" publishes the following DMARC DNS record:
          <figure><artwork>
 _dmarc.gov.example. IN TXT ( "v=DMARC1; p=reject; "
                              "rua=mailto:dmc@dmarc.svc.gov.example" )
         </artwork></figure>
          This DMARC record provides policy and a reporting destination for
-         mail sent from @gov.example. However, due to DMARC's current method
+         mail sent from @tax.gov.example. However, due to DMARC's current method
          of discovering and applying policy at the organizational domain
          level, the non-existent organizational domain of @t4x.gov.example
          does not and cannot fall under a DMARC policy.
@@ -111,7 +116,7 @@
      <t> Defensively registering all variants of "tax" is obviously not a scalable
          strategy.  The intent of this specification, therefore, is to enhance the
          DMARC algorithm by enabling an agent receiving such a message to be able to
-         determine that a relevant policy is present at "gov.example", which is
+         determine whether a relevant policy is present at "gov.example", which is
          precluded by the current DMARC algorithm.
      </t>
    </section>
@@ -153,7 +158,7 @@
                       effectively Organizational Domains as discussed in <xref
                       target="RFC7489">DMARC</xref>.  They control all
                       subdomains of the tree.  These are effectively private
-                      domains, but listed in the Public Suffix List.  They are
+                      domains, but formally they are PSDs, so they are
                       treated as Public for DMARC
                       purposes.  They require the same protections as DMARC
                       Organizational Domains, but are currently unable to
@@ -245,6 +250,11 @@
 
    <section title="PSD DMARC Updates to DMARC Requirements">
 
+     <t>The algorithm DMARC uses to find the Organizational Domain of a
+        given domain hinges on a Public Suffix List (PSL), which is a list
+        of PSDs, possibly making use of wildcards.  The process is described
+        in Section 3.2 of the DMARC specification.</t>
+
      <t>This document updates DMARC as follows:</t>
 
      <section title="General Updates">