Re: [DNSOP] remarks on draft-ietf-dnsop-5966bis-01

"W.C.A. Wijngaards" <wouter@nlnetlabs.nl> Thu, 19 March 2015 08:57 UTC

Return-Path: <wouter@nlnetlabs.nl>
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 A137A1A00BE for <dnsop@ietfa.amsl.com>; Thu, 19 Mar 2015 01:57:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.916
X-Spam-Level:
X-Spam-Status: No, score=-4.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 me5NDHGYbQAV for <dnsop@ietfa.amsl.com>; Thu, 19 Mar 2015 01:57:03 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5C431A1A50 for <dnsop@ietf.org>; Thu, 19 Mar 2015 01:57:03 -0700 (PDT)
Received: by dicht.nlnetlabs.nl (Postfix, from userid 58) id 4B6C028EB; Thu, 19 Mar 2015 09:57:01 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1426755421; bh=rj7OMdawmYTUcbR+8km4WEegSHVRlA44YJPXY43ILuw=; h=Date:From:To:Subject:References:In-Reply-To; b=foFPPxpdpptvDpkdYzs3l5X+rDBahGNG+bMVVNsThkeGnF3jlJXAPYxrM8x3PePjd 3MsAxdPGP8fpPXZt8ziI2yOC2NwlYciLEUWoIdTfhO+CR9s1cx00QRWtd7rCLApCLd hdvORfhbPseToFpB2Q4ZS7H9M+jHu075oAa5xosU=
Received: from axiom.nlnetlabs.nl (unknown [IPv6:2a04:b900:0:1:222:4dff:fe55:4d46]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 4E82A28E4 for <dnsop@ietf.org>; Thu, 19 Mar 2015 09:56:59 +0100 (CET)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=nlnetlabs.nl
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1426755419; bh=rj7OMdawmYTUcbR+8km4WEegSHVRlA44YJPXY43ILuw=; h=Date:From:To:Subject:References:In-Reply-To; b=PrtRVF3Eux8LIZBZwrGqcLDMCgsT490XxxNLL+9qHJSxTycnUb28ZUSj69Qwr3Z4k ssQDiwx8OVuMjmPAsKdigYJtdHWip0HU7008Ss3yjDGgObiT87QYU6l1a+klZIURNy aMpHxDlJJ3PqKVlvHfVwXWyvvqrnc5+NZ5p+YOuA=
Message-ID: <550A8F58.2040009@nlnetlabs.nl>
Date: Thu, 19 Mar 2015 09:56:56 +0100
From: "W.C.A. Wijngaards" <wouter@nlnetlabs.nl>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: dnsop@ietf.org
References: <20150318013805.GH4385@mx1.yitter.info> <55093E8C.3030300@redbarn.org>
In-Reply-To: <55093E8C.3030300@redbarn.org>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/cpPrkZ619i_yubVi_ENpYd_5iXk>
Subject: Re: [DNSOP] remarks on draft-ietf-dnsop-5966bis-01
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: <http://www.ietf.org/mail-archive/web/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: Thu, 19 Mar 2015 08:57:05 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Paul,

On 18/03/15 09:59, Paul Vixie wrote:
>> Stub and recursive resolvers MUST be able to process responses
>> that arrive in a different order to that in which the requests
>> were sent, regardless of the transport protocol in use.
> 
> this does not work as a MUST, because existing implementations
> which were faithful to RFC 1035 might not be able to do this -- and
> you know this or you would not be trying to clarify the point at
> this late date. i think that if you want new behaviour you have to
> negotiate for it, not merely mandate it, since to mandate it would
> invalidate previously-valid implementations and break
> previously-working configurations.

+1.  Backwards compatibility means you cannot specify that existing
implementations have to change.  You can specify that 'upgraded'
implementations perform new actions, of course.

Best regards,
   Wouter

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJVCo9TAAoJEJ9vHC1+BF+N6kEP/3MlX8Bbhk+2OW7Bt/ARtUVw
UPvVTumltFA3RMsVOHDIL15sm5G0QczCqCnpfyr1q7gGtSeTWZJ0tyOrn60sSYVT
tVB2nDbaFQM4Ye5Uuu5WY5433mOLh05TlpTbyPbwBuNylH75A7Vsq3kbwm832xsD
e5gAI4sWETE/KSLAT7hQp+nV2R0+t7pLDmadFJpYmbLz8XA8aesXIj0ShrbHMnCk
8VwJgdueleG6PG0hI25BC2DpMl0XOVx4i/SO4ateXXSChaKGEDCGkxz/KifHlJSm
CcKbuKO6wgB1TbzUIkGejLTl5AgaK7uki+KHdCm8TIzAC4IpsqtYK94wy/zqDAaf
E5WpK3e9NeO2XZ4+cnxl+LcDJG5Z5s1RFRuEE/lShvAPk84QZeHyQxSGCC47coxy
Jo4pBbPfhFusHFCqMx3mw+io8+DF7fxXFg0p1J1l0ZVMxIIoweZuebEGcHM14T7X
/18vtyMDfkWxpjv5mawfKcrg87RGAQdFEG4yU/Gnd3e7gLJTk4nYnFXm8JdlUQhB
0wa9TteCsT1JbS7cXcbl4CdcI4/OuPB8hgRD0WbAFRk8Jilsh/3ihQ7dx4JiuiaN
8RxYP3I7EXBDCQ7II2J8VMZ5lvY7U+zrwaUvKC+eexMlso3ZFHVDhuNodg+JwCEa
h+YnLq+LT8rocRNgRh9Q
=gCfF
-----END PGP SIGNATURE-----