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

Andrew Sullivan <ajs@anvilwalrusden.com> Thu, 19 March 2015 10:56 UTC

Return-Path: <ajs@anvilwalrusden.com>
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 740891A0023 for <dnsop@ietfa.amsl.com>; Thu, 19 Mar 2015 03:56:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.141
X-Spam-Level:
X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no
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 Sw7mlZx1bZ00 for <dnsop@ietfa.amsl.com>; Thu, 19 Mar 2015 03:56:48 -0700 (PDT)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97FA81A883A for <dnsop@ietf.org>; Thu, 19 Mar 2015 03:56:48 -0700 (PDT)
Received: from mx1.yitter.info (unknown [67.211.120.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id B18CE8A035 for <dnsop@ietf.org>; Thu, 19 Mar 2015 10:56:47 +0000 (UTC)
Date: Thu, 19 Mar 2015 06:56:45 -0400
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dnsop@ietf.org
Message-ID: <20150319105640.GH6046@mx1.yitter.info>
References: <20150318013805.GH4385@mx1.yitter.info> <55093E8C.3030300@redbarn.org> <550A8F58.2040009@nlnetlabs.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <550A8F58.2040009@nlnetlabs.nl>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/gUCTwVRJtKh4EHyyKOP3z9hb6q4>
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 10:56:49 -0000

On Thu, Mar 19, 2015 at 09:56:56AM +0100, W.C.A. Wijngaards wrote:
> 
> +1.  Backwards compatibility means you cannot specify that existing
> implementations have to change.  You can specify that 'upgraded'
> implementations perform new actions, of course.

No RFC can make changes that apply to implementations that do not
conform with that RFC.  This is true by definition.  The draft does
not somehow magically retroactively change the text in RFC 1035.  It
specifies new behaviour, and old implementations that don't conform to
this new text will therefore obviously not exhibit the new behaviour.
What's the problem?

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com