From: "Joe Abley" <jabley@hopcount.ca>
To: "Edward Lewis" <edward.lewis@icann.org>
Date: Fri, 06 Nov 2015 08:08:19 -0500
Message-ID: <BD3F97B7-4BEA-493E-923B-4B359631A8DA@hopcount.ca>
In-Reply-To: <D262A608.10F0E%edward.lewis@icann.org>
References: <D262A608.10F0E%edward.lewis@icann.org>
MIME-Version: 1.0
Content-Type: multipart/signed;
 boundary="=_MailMate_DB4BF9DA-3AEF-49D3-98B9-EB0772AC21E4_=";
 micalg=pgp-sha1; protocol="application/pgp-signature"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/viIYz_JJa6MUpE_Ub6_rnGbDbMA>
Cc: "dnsop@ietf.org" <dnsop@ietf.org>
Subject: Re: [DNSOP] When to Clarify - was Re: Ambiguous standards suck (was
 Re: draft-jabley-dnsop-ordered-answers)
Precedence: list

This is an OpenPGP/MIME signed message (RFC 3156 and 4880).

--=_MailMate_DB4BF9DA-3AEF-49D3-98B9-EB0772AC21E4_=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable



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 te=
xt
> is evidently sufficient.

I'll note that the discussion that kicked all this off was an observed fa=
ilure to interoperate in deployed code, and whether that code was followi=
ng 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 deploye=
d code is suddenly non-compliant is a recipe for disaster. Let's not do t=
hat.

I originally proposed that all sections should be unordered, and that nob=
ody 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 implem=
entations non-compliant, so I changed the proposal such that the answer s=
ection was considered an ordered set, and all other sections unordered.

There were several examples given at the microphone the other day about a=
dditional known bad reactions in deployed code relating to OPT and TSIG i=
n the additional section. I would argue that those should also be documen=
ted, since I think the proposal should align itself with the steps requir=
ed to make new code interoperate with deployed code.


Joe

--=_MailMate_DB4BF9DA-3AEF-49D3-98B9-EB0772AC21E4_=
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename=signature.asc
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iEYEARECAAYFAlY8pkMACgkQNI8MvYZSOix1/QCdH68UdWSpSZ+LlKvYSXm/nWut
rVEAn0UnO4UbKfLbbvQ3PZqIwEuV7Kzm
=s+db
-----END PGP SIGNATURE-----

--=_MailMate_DB4BF9DA-3AEF-49D3-98B9-EB0772AC21E4_=--