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 <dcroc...@gmail.com
<mailto:dcroc...@gmail.com>> wrote:
On 1/29/2021 12:15 PM, Murray S. Kucherawy wrote:
On Fri, Jan 29, 2021 at 7:51 AM Dave Crocker <dcroc...@gmail.com
<mailto:dcroc...@gmail.com>> 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 Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
