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

Jim Reid <jim@rfc1035.com> Sat, 24 March 2018 14:59 UTC

Return-Path: <jim@rfc1035.com>
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 626B91243F6 for <dnsop@ietfa.amsl.com>; Sat, 24 Mar 2018 07:59:01 -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, T_RP_MATCHES_RCVD=-0.01] 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 AzLpDykAE_dc for <dnsop@ietfa.amsl.com>; Sat, 24 Mar 2018 07:59:00 -0700 (PDT)
Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 154921201F2 for <dnsop@ietf.org>; Sat, 24 Mar 2018 07:59:00 -0700 (PDT)
Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id CF432242147B; Sat, 24 Mar 2018 14:58:55 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Jim Reid <jim@rfc1035.com>
In-Reply-To: <CAJhMdTPRn=mUQ6xh_HFdFLBk109b_M2+saS86KFxsttb8_oVvw@mail.gmail.com>
Date: Sat, 24 Mar 2018 14:58:55 +0000
Cc: dnsop WG <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <4B5F0AAC-76CE-4A88-900D-2CA99993A9B6@rfc1035.com>
References: <152180695934.17546.2068402636242578841.idtracker@ietfa.amsl.com> <9CEA4F8F-4E71-4508-A088-103DD58F88E1@isc.org> <CA+nkc8DhXEEhiDqwHuA-_zNQc0n=rTZ-VZ6X8-0w-tY_0SC0eA@mail.gmail.com> <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>
To: Joe Abley <jabley@hopcount.ca>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/9FY-tcBjeZD_6tuObsDiPEkjLag>
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 14:59:01 -0000


> On 24 Mar 2018, at 13:48, Joe Abley <jabley@hopcount.ca>; wrote:
> 
> But I think brushing the grains RRType parsing dust off the
> camel is not going to do much for its posture.

+1.

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.
That way, an implementer can delete the crufty code -- or not write any -- and still do the right thing (sort of) if their server sees one of these RRtypes in the wild.

If there are corner cases where codes were allocated for an organisation-specific purpose* and the organisation can confirm the type codes are no longer used or needed, these could be dropped from the DNS. In some respects, old DNS type codes are like pre-RIR IPv4 allocations and we’re just stuck with those legacy choices.

Obsoleted RRtypes shouldn’t overload the camel enough to matter. It might be a different story if one of those zombie RRtypes required additional processing. None spring to mind though.

* I’m thinking of things like Telnic’s NINFO and RKEY*. I have no idea if those two are actually used these days and would prefer not to find out. Although they seemed a reasonable idea at the time, I’ve disowned these wayward stepchildren. And .tel FWIW.