On 11/6/15, 12:07, "DNSOP on behalf of Shane Kerr" <[email protected] on behalf of [email protected]> wrote: > >If people were opposed to adopting ANY straightforward clarification, >let me ask them to please reconsider. I beg of you all. Think of the >children.
My response this is intended to apply to "refuse-any" (i.e., https://tools.ietf.org/html/draft-jabley-dnsop-refuse-any-01). Based on my experience in writing clarifications RFCs: 0. Clarification means change. There's no sugar coating it, clarification disrupts backwards compatibility. So set a high bar before adopting a clarification. 1. Insufficient original text is not sufficient cause to change (clarify) the specification. ("Insufficient" is a subjective term.) 2. Reason to change (clarify) the original specification is when demonstrable barriers to interoperability exist (that cannot be dismissed as buggy code). I.e., if by design, due to diverging, plausible interpretations of the specifications, two or more implementations cannot interoperate, there's grounds for a clarification. 3. Running code trumps written documents. If interoperability is achieved with insufficient original text, the text is evidently sufficient. --- I haven't been following "ordered answers" but have been following "refuse any". Both raise the question about the appropriateness of a clarification effort, so I'm responding to the thread on "ordered answers." I'm not claiming "ordered answers" is a bad document/clarifications effort, just enumerating how I personally evaluate the need to clarify something.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
