On 29 Mar 2023, at 5:20, Todd Herr wrote:
In my estimation, the language you propose here establishes the primacy of interoperability over the needs/wishes of the domain owner.
As is appropriate for such normative language. From RFC 2119: 6. Guidance in the use of these Imperatives Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability.
My preference is for language that acknowledges the primacy of the domain owner over interoperability.
Not only ought there not be primacy of the needs/wishes of the domain owner over interoperability, the IETF has repeatedly rejected such a principle. An implementer might decide to implement a security backdoor, but our protocol documents say that you MUST NOT do that. An implementer might decide to violate TCP retransmission timer requirements to get better performance, but our protocol documents say that you MUST NOT do that. We document interoperability; we do not give primacy to the wishes of of domain owners.
If you agree that interoperability is increased, then I'd suggest that you actually do agree that the proposed text is appropriate.
pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
