On 12/6/2021 9:38 AM, Scott Kitterman wrote:
In the interests of future-proofing, should there ever be additional
underlying authentication protocols, I propose this:
Should any authentication failures for systems
under the Domain Owner's control be found in the reports, in cases
where the failures are caused by local misconfiguration or omission
the Domain Owner can take steps to address such failures.
I think that's good.
Sorry, but I think it's not.
1. A specification should specify. It should specify things that are
concrete, precise, reliably actionable, and generally produce the same
understanding across widely differing readers. Specification language
that does not satisfy the list in the preceding sentence is not a
specification. Rather it is commentary.
2. When a specifications says that something vague and operational is
allowed or not allowed, consider whether it would be meaningful to
switch the bit. The above text is saying that local problems are
allowed to be fixed by taking local action. Could it make sense here to
prohibit taking that action? I sure hope not. So this text is, really,
entirely gratuitous. It purports to be saying something useful, but it
isn't.
3. IETF specification culture is quite nice in also allowing commentary
about background or use or 'issues' with the specification. The
downside is that this often produces text that is, really, none of the
things listed in the preceding sentence. Rather, it is language that
might feel comfortable to the authors but has no practical utility.
On 12/6/2021 5:35 AM, Todd Herr wrote:
SPF normally fails on forwarding. Should we mention that?
I don't know if it's necessary. SPF breaking due to forwarding is a
well-known condition, and I don't think it has to be documented in
every text that mentions SPF.
Kudos for that point.
4. Duplication of specification details or commentary text invites
divergence and/or misunderstanding. Sometimes a caution is helpful, not
not when it is long-standing issue with another specification and is
already well-understood. To the extent that there is a continuing
concern about the reader's understanding the fact of the caution, there
should be a basic pointer, early in the specification, to material that
discusses this (other) specification.
The problems here come from good intentions, but from the problematic
view that adding bits of vague or redundant text will provide meaningful
protection against the points of concern. They won't.
d/
--
Dave Crocker
[email protected]
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
[email protected]
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
