On Monday, December 6, 2021 1:01:51 PM EST Dave Crocker wrote: > 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/
OK. What's your recommendation then? Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
