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

From: Edward Lewis <[email-masked]>
Date: Fri, 6 Nov 2015 10:08:05 +0000

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

---

From: "Joe Abley" <[email-masked]>
Date: Fri, 06 Nov 2015 08:08:19 -0500

> If interoperability is achieved with insufficient original text, the text

I'll note that the discussion that kicked all this off was an observed failure to interoperate in deployed code, and whether that code was following the specification or not was a matter of some debate depending on how 1035 was interpreted.

I agree that changing the specification such that the majority of deployed code is suddenly non-compliant is a recipe for disaster. Let's not do that.

I originally proposed that all sections should be unordered, and that nobody should reject a message on the basis that it should be otherwise. It was pointed out to me that this would make several widely-deployed implementations non-compliant, so I changed the proposal such that the answer section was considered an ordered set, and all other sections unordered.

There were several examples given at the microphone the other day about additional known bad reactions in deployed code relating to OPT and TSIG in the additional section. I would argue that those should also be documented, since I think the proposal should align itself with the steps required to make new code interoperate with deployed code.

Joe

---

From: Edward Lewis <[email-masked]>
Date: Sat, 7 Nov 2015 00:52:36 +0000

On 11/6/15, 22:08, "Joe Abley" <[email-masked]> wrote:

>I'll note that the discussion that kicked all this off was an observed
>failure to interoperate in deployed code, and whether that code was
>following the specification or not was a matter of some debate depending
>on how 1035 was interpreted.
>
>I agree that changing the specification such that the majority of
>deployed code is suddenly non-compliant is a recipe for disaster. Let's
>not do that.

I'll offer up that I wrote this as a blanket comment, having in mind my
objections related to "refuse-any."  The reason I'm saying this is prevent
confusion on the "arguments."  I did respond to what Shane had said (in a
thread labeled "ordered answers", true.  In my defense I altered the
subject line but perhaps that was too subtle of a way to change context.

Meanwhile I am trying to figure out how to re-comment on refuse-any that
is non-repetitive (meaning I'd posted one already) but underscores what I
think is a needed critical change to that document.  Not saying y'all
should be waiting for more of my utterances, just to let you know what I
was thinking when I hit "send" to my previous message.

(I hope to get the other message out...it's half written in the out-box
but it's also not my top priority, despite the outward appearance that I'm
rewarded for every criticism I launch against work involving Olafur.)

(The latter is meant as a joke.)

(Really.)

Ed