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

"Joe Abley" <> Fri, 06 November 2015 13:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5701A1A87F2 for <>; Fri, 6 Nov 2015 05:08:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PlNTRYEUfUhA for <>; Fri, 6 Nov 2015 05:08:21 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C3A331A6FD9 for <>; Fri, 6 Nov 2015 05:08:21 -0800 (PST)
Received: by vkbk63 with SMTP id k63so1749421vkb.0 for <>; Fri, 06 Nov 2015 05:08:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-type; bh=wy1GTqMMw63YJgbpjoL97HgLhuW8P6M0mQsJ9zFJLSI=; b=PIu0fPdrm2wfhL6rEvMLbYNfdIYrNUijHpCs/a7lQO3eKA7EiprWpSwDr2ZQYNEFKx ug3TD+upW3qiqQg7dM/UTPBrL7dMUMikX7Ff7/4SEWEOGaf46/f1OheZcntuGpRO/Eno ax0Sa5NMXbs6oKqNPtrpz4FyuROk0Hg85oNUw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=wy1GTqMMw63YJgbpjoL97HgLhuW8P6M0mQsJ9zFJLSI=; b=ktuVUaAmLiWRHsKT0UPCyK5S8pC3nNs/vNf6hXT1m/eCpweXrcNd2P3f9ciRbl0TJb i9JR7STLwmLkyVqLI3g3/JT/6GxxqOhnWCJSyXN1jmZe45vxAbn8dadlDgGfCc2S9t3N vg5WQdOyoUb0h2FA2Or+zD1gZ9BlmDuRjDHfnzpHsgA5ANRgRDjNtbF/zWz+mUi/IHjy ZiMyjtyjy5aiHpsC2wpH3sMdDctZbxnnrcbiW5ncaCztDADVpGs9LZytyZK2qnPhCQE8 Ys9bE/g+9EYDnKpyDk2pBDHKh00uUVNhseiobWpJnQcRLR+SzcJ8fWtUMc1Nqx48cbry WXTw==
X-Gm-Message-State: ALoCoQkycvWfEJUv0UDLF7wtnumI5z0bYHvSNOf5MfLsKM+GMC1o8Ur2PG8v3P4XKI/Xk8poQ5zl
X-Received: by with SMTP id w205mr12690929vke.95.1446815300638; Fri, 06 Nov 2015 05:08:20 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id q126sm50207vke.16.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 06 Nov 2015 05:08:20 -0800 (PST)
From: Joe Abley <>
To: Edward Lewis <>
Date: Fri, 06 Nov 2015 08:08:19 -0500
Message-ID: <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_DB4BF9DA-3AEF-49D3-98B9-EB0772AC21E4_="; micalg="pgp-sha1"; protocol="application/pgp-signature"
X-Mailer: MailMate (1.9.2r5141)
Archived-At: <>
Cc: "" <>
Subject: Re: [DNSOP] When to Clarify - was Re: Ambiguous standards suck (was Re: draft-jabley-dnsop-ordered-answers)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 06 Nov 2015 13:08:23 -0000

On 6 Nov 2015, at 5:08, Edward Lewis wrote:

> 3. Running code trumps written documents.
> If interoperability is achieved with insufficient original text, the text
> is evidently sufficient.

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.