[DNSOP] When to Clarify - was Re: Ambiguous standards suck (was Re: draft-jabley-dnsop-ordered-answers)

[Edward Lewis <[e-mail]>]

On 11/6/15, 12:07, "DNSOP on behalf of Shane Kerr" <[e-mail]
on behalf of [e-mail]> 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.