Re: [dmarc-ietf] draft-ietf-dmarc-psd review

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

Sorry, I hit "send" when I didn't mean to.  Finishing up:

On Mon, Jul 22, 2019 at 9:23 AM Murray S. Kucherawy <[e-mail]>
wrote:

>
>    o  Multi-organization PSDs that require DMARC usage (e.g., ".bank"):
>       PSD DMARC based reports will only be generated for domains that do
>       not publish a DMARC policy at the organizational or host level.
>       For domains that do publish the required DMARC policy records, the
>       feedback reporting addresses (RUA and RUF) of the organization (or
>       hosts) will be used.  The only direct feedback leakage risk for
>       these PSDs are for Organizational Domains that are out of
>       compliance with PSD policy.  Data on non-existent cousin domains
>       would be sent to the PSO.
>
>
 This is the second use of "cousin domain". An example here or at the first
use might be a good idea.

>
>    o  Multi-organization PSDs (e.g., ".com") that do not mandate DMARC
>       usage: Privacy risks for Organizational Domains that have not
>       deployed DMARC within such PSDs are significant.  For non-DMARC
>       Organizational Domains, all DMARC feedback will be directed to the
>       PSO.  PSD DMARC is opt-out (by publishing a DMARC record at the
>       Organizational Domain level) vice opt-in, which would be the more
>
> "vice" should be "versus"?

   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 ought to be limited to non-existent domains
>    except in cases where the reporter knows that PSO requires use of
>    DMARC.
>
>
Feedback about non-existent domains is generated by virtue of the fact that
such mail never passes SPF or bears a valid signature, correct?  If so,
that should probably be stated explicitly somewhere.

5.  Security Considerations
>
>    This document does not change the Security Considerations of
>    [RFC7489] and [RFC7960].
>
>
s/and/or/


> Appendix B.  DMARC PSD Registry Examples
>
>    To faciliate experimentation around data leakage mitigation, samples
>
>
typo

B.2.  DMARC Public Suffix Domain (PSD) Registry
>
>    [psddmarc.org] provides an IANA like DMARC Public Suffix Domain (PSD)
>    Registry as a stand-alone DNS query service.  It follows the contents
>    and structure described below.  There is a Comma Separated Value
>    (CSV) version of the listed PSD domains which is suitable for use in
>    build updates for PSD DMARC capable software.
>
>    Names of PSDs participating in PSD DMARC must be registered this new
>    registry.  New entries are assigned only for PSDs that require use of
>
>
Missing verb in the first sentence.

-MSK