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 <[email protected]> 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 <[email protected]> wrote: > >> On 1/29/2021 12:15 PM, Murray S. Kucherawy wrote: >> >> On Fri, Jan 29, 2021 at 7:51 AM Dave Crocker <[email protected]> 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 [email protected] > 408.329.0791 > > Volunteer, Silicon Valley Chapter > American Red [email protected] > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
