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

Paul Vixie <paul@redbarn.org> Sat, 21 March 2015 18:08 UTC

Return-Path: <paul@redbarn.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 41C901A1BDD for <dnsop@ietfa.amsl.com>; Sat, 21 Mar 2015 11:08:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 H_L2Q4dqPB4m for <dnsop@ietfa.amsl.com>; Sat, 21 Mar 2015 11:08:55 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BAE81A1BDC for <dnsop@ietf.org>; Sat, 21 Mar 2015 11:08:55 -0700 (PDT)
Received: from [IPv6:2001:559:8000:cb:5892:b17e:4bf6:559c] (unknown [IPv6:2001:559:8000:cb:5892:b17e:4bf6:559c]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 06240184D7; Sat, 21 Mar 2015 18:08:55 +0000 (UTC)
Message-ID: <550DB3B0.3080601@redbarn.org>
Date: Sat, 21 Mar 2015 11:08:48 -0700
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 3.0.11 (Windows/20140602)
MIME-Version: 1.0
To: Florian Weimer <fw@deneb.enyo.de>
References: <20150318013805.GH4385@mx1.yitter.info> <55093E8C.3030300@redbarn.org> <550A8F58.2040009@nlnetlabs.nl> <87a8z630ed.fsf@mid.deneb.enyo.de>
In-Reply-To: <87a8z630ed.fsf@mid.deneb.enyo.de>
X-Enigmail-Version: 1.2.3
Content-Type: multipart/alternative; boundary="------------010601030608030802060808"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/VUCWZph9aoayApxRudMnsIb7Wzg>
Cc: dnsop@ietf.org
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: Sat, 21 Mar 2015 18:08:56 -0000


Florian Weimer wrote:
> * W. C. A. Wijngaards:
>
>> > +1.  Backwards compatibility means you cannot specify that existing
>> > implementations have to change.
>
> Does it matter if they do not exist or are not considered practically
> relevant?

not usually. if there's a standard for it, our burden is to assume that
there are faithful implementations of it. only if there is no way to
negotiate for the new behaviour (as there would be for tcp stay-open, so
this exception does not apply to the draft under consideration) would we
even consider assuming otherwise.

> As a counterexample, RFC 6891 requires FORMERR responses without OPT
> RRs from implementations which do not support EDNS:
>
>    Responders that choose not to implement the protocol extensions
>    defined in this document MUST respond with a return code (RCODE) of
>    FORMERR to messages containing an OPT record in the additional
>    section and MUST NOT include an OPT record in the response.

this language was very careful. older implementations cannot "choose" behaviour relative to this standard. so, as an example of what you're trying to convey, this text fails. 


-- 
Paul Vixie