Re: [DNSOP] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

Viktor Dukhovni <ietf-dane@dukhovni.org> Sat, 24 March 2018 17:22 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE1312D7E5 for <dnsop@ietfa.amsl.com>; Sat, 24 Mar 2018 10:22:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 VYvPpoQSm4cZ for <dnsop@ietfa.amsl.com>; Sat, 24 Mar 2018 10:22:51 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2360F126DED for <dnsop@ietf.org>; Sat, 24 Mar 2018 10:22:51 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id DB2EF7A330E; Sat, 24 Mar 2018 17:22:49 +0000 (UTC)
Date: Sat, 24 Mar 2018 17:22:49 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dnsop WG <dnsop@ietf.org>
Message-ID: <20180324172249.GK3322@mournblade.imrryr.org>
Reply-To: dnsop@ietf.org
References: <40ABB9EB-58EC-48FF-8117-60EE0E7006EF@isc.org> <CA+nkc8BfMKRUHuW+3EzOCeZHfmu1jeOgfVcszTbTYh9k2VTBcA@mail.gmail.com> <002DCABB-24CE-42FA-8DA6-2A458E5F89A1@isc.org> <5AB53F8B.9070504@redbarn.org> <7CF21F70-9419-4D6A-B555-FC229F90E8A9@isc.org> <5AB546CB.3030408@redbarn.org> <CCAE4014-67F8-4E73-A893-AA06B83E880B@isc.org> <20180324124958.GA29255@puck.nether.net> <CAJhMdTPRn=mUQ6xh_HFdFLBk109b_M2+saS86KFxsttb8_oVvw@mail.gmail.com> <4B5F0AAC-76CE-4A88-900D-2CA99993A9B6@rfc1035.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4B5F0AAC-76CE-4A88-900D-2CA99993A9B6@rfc1035.com>
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/HUVm5pz4vNbT4BJB0V5J8Z4Gy4g>
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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, 24 Mar 2018 17:22:53 -0000

On Sat, Mar 24, 2018 at 02:58:55PM +0000, Jim Reid wrote:

> IMO there's no need to do this in the protocol unless there is convincing
> proof that nobody anywhere is using a now-obsolete RRtype. An RFC saying
> a server could return FORMERR (or whatever) when it gets a query for one
> of these dead/zombie QTYPEs might be OK I suppose.

Absolutely no!  *THAT* would add substantial run-time complexity
for no reason, achieving the opposite of any simplification that
might result from dropping support for the RRtype. If there's no
such data in your zone, return NODATA or NXDOMAIN as appropriate.
If there is such data, return that data.

This would be grossly misguided.  Perhaps time to reread:

    https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-08

As for removing parsing code from tools, I sympathise with the view
that this does not remove much complexity that matters.  The
complexity we really should care about is wire (protocol) complexity,
not tool complexity.  One might say that *new* tools may skip
implementing obsolete RRtypes, and that users should avoid new
uses of obsolete RRtypes, but there's not IMHO much impetus
for removing support from existing tools.

That said, legacy code has some costs, and one should attempt to
eventually shed bits nobody uses. So while I agre that the priorities
are elsewhere, this too is something one might eventually pay
attention to.  So I am not opposed to dropping parser support for
essentially unused types.  It just needs to be down with care,
first issue deprecation warnings for a few releases, then if there
are few enough complaints, remove support.

-- 
	Viktor.