IETF Logo Mail Archive

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

Edward Lewis <edward.lewis@icann.org> Fri, 06 November 2015 10:08 UTC

Return-Path: <edward.lewis@icann.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A52C1B3873 for <dnsop@ietfa.amsl.com>; Fri, 6 Nov 2015 02:08:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.431
X-Spam-Level:
X-Spam-Status: No, score=-3.431 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDMW4bs3RR7O for <dnsop@ietfa.amsl.com>; Fri, 6 Nov 2015 02:08:07 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 384931B3868 for <dnsop@ietf.org>; Fri, 6 Nov 2015 02:08:07 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 6 Nov 2015 02:08:05 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1044.021; Fri, 6 Nov 2015 02:08:05 -0800
From: Edward Lewis <edward.lewis@icann.org>
To: "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: When to Clarify - was Re: [DNSOP] Ambiguous standards suck (was Re: draft-jabley-dnsop-ordered-answers)
Thread-Index: AQHRGHsH7FqKagwEJUW+PSD2skdCSA==
Date: Fri, 06 Nov 2015 10:08:05 +0000
Message-ID: <D262A608.10F0E%edward.lewis@icann.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.5.7.151005
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.47.236]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="B_3529681678_4393855"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/rEesw5jCWpT5wnYolCzqR1LEoUA>
Subject: [DNSOP] When to Clarify - was Re: Ambiguous standards suck (was Re: draft-jabley-dnsop-ordered-answers)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Nov 2015 10:08:08 -0000

On 11/6/15, 12:07, "DNSOP on behalf of Shane Kerr" <dnsop-bounces@ietf.org
on behalf of shane@time-travellers.org> 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.

v2.23.0 | Report a Bug | By Email