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

Evan Hunt <each@isc.org> Sun, 25 March 2018 08:06 UTC

Return-Path: <each@isc.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 538711267BB for <dnsop@ietfa.amsl.com>; Sun, 25 Mar 2018 01:06:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=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 1U6t_MqznyYQ for <dnsop@ietfa.amsl.com>; Sun, 25 Mar 2018 01:06:01 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 573C812422F for <dnsop@ietf.org>; Sun, 25 Mar 2018 01:06:01 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 7067C3AB040; Sun, 25 Mar 2018 08:05:58 +0000 (UTC)
Received: by bikeshed.isc.org (Postfix, from userid 10292) id 559D9216C1C; Sun, 25 Mar 2018 08:05:58 +0000 (UTC)
Date: Sun, 25 Mar 2018 08:05:58 +0000
From: Evan Hunt <each@isc.org>
To: Joe Abley <jabley@hopcount.ca>
Cc: Jared Mauch <jared@puck.nether.net>, =?utf-8?B?T25kxZllaiBTdXLDvQ==?= <ondrej@isc.org>, dnsop <dnsop@ietf.org>, Paul Vixie <paul@redbarn.org>, Bob Harold <rharolde@umich.edu>
Message-ID: <20180325080558.GA18671@isc.org>
References: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAJhMdTPRn=mUQ6xh_HFdFLBk109b_M2+saS86KFxsttb8_oVvw@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/vH5iP2yMSnIdt_ur3U4P7MwYWDg>
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: Sun, 25 Mar 2018 08:06:03 -0000

On Sat, Mar 24, 2018 at 06:48:35AM -0700, Joe Abley wrote:
> I'm actually surprised to see that support for rarely-used RRTypes is
> really upsetting the camel.

It's an interesting object lesson in the complexity of unloading camels,
though.  (Perhaps it's time to add something about "the eye of a needle" to
our camel metaphor.)

> A combinatorial explosion of annoying workarounds for the inability of
> middleboxes or upstream authority servers to implement EDNS(0)
> properly seems like a much more plausible camel irritant to me. I'm
> sure there are many more like that.

Wholeheartedly agree, and efforts to address this are under way.

> I can see why you could strip out lines of code by eliminating the
> need to parse the canonical formatting of WKS and friends, but I'm
> surprised that it's a notable source of complexity. It is, after all,
> complexity that I heard is causing the camel strain, not just lines of
> code.
> 
> If future-BIND stops parsing an archaic RRType that I happen to use,
> I'm going to have to change whatever code or processes that depend on
> it. Maybe someone (ISC, even) is going to publish a filter that will
> turn all the old RRs in canonical syntax into TYPExxxx representation,
> and back again. New RRTypes might then need to get implemented in both
> BIND (because presumably they are camel-friendly) and also in the
> filter or filters, because perhaps we are targeting multiple
> nameserver implementations with our zone file.
> 
> This all sounds like we're just sharing the complexity around. It
> doesn't sound any simpler. Maybe it's a silly example? I don't know.
> Could be. But I think brushing the grains RRType parsing dust off the
> camel is not going to do much for its posture.

I think it would help if there were more clarity on what exactly is being
proposed, other than adding the words "obsolete" or "deprecated" to a list
of RRtypes on a website somewhere. The draft didn't seem to have
particularly clear guidance to implementers.

These RR types have text representations and wire format representations,
which from a complexity standpoint seem quite harmless to implement.  There
are the old annoying rules about name compression and sorting, which do add
some complexity, but are already implemented in all the existing codebases.
I don't see how the IETF can mandate that they be removed, nor am I sure
it's particuilarly worth doing.  We can make them optional to implement in
the future, though.  Perhaps that's all Ondrej has in mind?

(With respect to BIND, if these types are declared obsolete by the working
group, then my inclination would be to a log a message saying so if you
tried to load them in a zone, same as with SPF.  In a future relase I might
start treating them as opague types when rendering to wire format, but
would probably retain the ability to parse them and display them as text.)

-- 
Evan Hunt -- each@isc.org
Internet Systems Consortium, Inc.