Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

[Douglas Foster <[e-mail]>]

This wording attempts to address the objections by giving
"registration" a specific context.    I also rewrote some of it for
readability.

- -

DMARC (Domain-based Message Authentication, Reporting, and
Conformance) is a scalable mechanism by which a mail-originating
organization can policies and preferences for validation and
disposition of messages which purport to come from owned domains,
as well as requesting feedback reporting about those message
validation and disposition actions.  These features allow the domain
owner to detect and inhibit domain name abuse.

DMARC is designed for use by domain owners.  Consequently it has no
applicability for domains that have no owner because the domain has
never been registered with an Internet Naming Authority.  Those
authorities have an interest in detecting and inhibiting abuse of the
name registration process, and message recipients have an interest
in preventing deception by entities using unregistered organization
domain names.

Domains at which Internet Naming Authorities perform registration are
referred to as Public  Suffix Domains (PSDs).  This document describes
an extension to DMARC to enable DMARC functionality for PSDs.

 This document also seeks to address implementations that consider a
 domain on a public Suffix list to be ineligible for DMARC
 enforcement.

On Fri, Feb 19, 2021 at 11:12 PM Dave Crocker <[e-mail]> wrote:

> On 2/18/2021 9:10 AM, Murray S. Kucherawy wrote:
>
> Circling back to this:
>
> On Fri, Jan 29, 2021 at 12:56 PM Dave Crocker <[e-mail]> wrote:
>
>> On 1/29/2021 12:15 PM, Murray S. Kucherawy wrote:
>>
>> On Fri, Jan 29, 2021 at 7:51 AM Dave Crocker <[e-mail]> wrote:
>>
>>>    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
>>>
>>> DMARC does not have 'registrations'.
>>>
>>
>> ...
>>
>>
>> I'm struggling to understand the concern here.  I think we all know what
> it means to register a domain, and that the namespace is arranged as a
> tree,
>
>
> With the intent of building upon Barry's note:
>
> <pedanty> Specification writing requires clarity of who the reader is and
> empathy with the experience they will have reading the document.
> </pedantry>
>
> In that context "we all know" is automatically a red flag for requiring
> overly insider expertise.
>
> However in this case, I think the problem is worse.
>
> Simply put, I believe the text does not say what it means to distinguish,
> even for an expert reader.  So, yes, we all know what you say we know.
>
> But in fact that's not the point of the text.  It's trying to make some
> other point,  I assume it's about a type of boundary status, but it doesn't
> say that, nevermind saying it clearly and with enough technical and
> semantic detail to distinguish it.
>
> The text you offer:
>
> Maybe this is better, just for the sake of having something else to look
> at?
>
>    DMARC (Domain-based Message Authentication, Reporting, and
>    Conformance) 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 nodes in the DNS tree that are either
>    reserved as points below which new domain name registrations are made, or are
>    the results of those registrations; it does not permit a node 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.
>
> moves closer to the mark, I think, but still doesn't get there.
>
> EVERY node can have sub-nodes registered.  So it isn't clear what
> 'reserved' means.
>
> Worse is that:
>
>    reserved as points below which new domain name registrations are made, or are
>    the results of those registrations; it does not permit a node to have both of these
>    properties simultaneously.
>
> doesn't make sense to me.  I suspect an average technical reader will be
> at least as confused as I am.
>
> d/
>
>
> --
>
> Dave [e-mail]
> 408.329.0791
>
> Volunteer, Silicon Valley Chapter
> American Red [e-mail]
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>