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

Ondřej Surý <ondrej@isc.org> Sat, 24 March 2018 15:23 UTC

Return-Path: <ondrej@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 AC4F412D7E4 for <dnsop@ietfa.amsl.com>; Sat, 24 Mar 2018 08:23:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 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] 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 0bAzMRDbYyaW for <dnsop@ietfa.amsl.com>; Sat, 24 Mar 2018 08:23:30 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 02C3D12D7E5 for <dnsop@ietf.org>; Sat, 24 Mar 2018 08:23:30 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 84B333AB1CB; Sat, 24 Mar 2018 15:23:29 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 6FF66160052; Sat, 24 Mar 2018 15:23:29 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 599B1160070; Sat, 24 Mar 2018 15:23:29 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id af5dS188Su8V; Sat, 24 Mar 2018 15:23:29 +0000 (UTC)
Received: from [10.10.0.192] (40.20.broadband5.iol.cz [88.100.20.40]) by zmx1.isc.org (Postfix) with ESMTPSA id 0AE42160052; Sat, 24 Mar 2018 15:23:29 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= <ondrej@isc.org>
X-Mailer: iPhone Mail (15D100)
In-Reply-To: <CAJhMdTPRn=mUQ6xh_HFdFLBk109b_M2+saS86KFxsttb8_oVvw@mail.gmail.com>
Date: Sat, 24 Mar 2018 16:23:25 +0100
Cc: Jared Mauch <jared@puck.nether.net>, Bob Harold <rharolde@umich.edu>, dnsop <dnsop@ietf.org>, Paul Vixie <paul@redbarn.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <4D137B73-160E-4D95-99A6-2708E5079612@isc.org>
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>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/gFafzao3QMQCbG2qyrcoOgBhDwU>
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 15:23:32 -0000

Joe,

it’s actually not the complexity in BIND (although I view everything as extra complexity), it’s the interop for new players that need to implement every piece of rusty junk that's in the protocol to be interoperable.

While it seems to be attractive to keep the existing open-source tetrapoly (insert your favorite Greek numerical prefix), the fact is that new implementations do pop up from time to time, and if we can reduce the protocol a little bit, so they can actually implement what’s important, that would be the noble goal here.

Let me repeat again - we are speaking about stuff that was declared either OBSOLETE or EXPERIMENTAL already in RFC1035.

I’ll elaborate more about why I think we locked ourselves into this when I am not typing on small phone screen in reply to Jared’s message later today.

Cheers,
Ondrej

--
Ondřej Surý — ISC

> On 24 Mar 2018, at 14:48, Joe Abley <jabley@hopcount.ca>; wrote:
> 
>> On Mar 24, 2018, at 13:49, Jared Mauch <jared@puck.nether.net>; wrote:
>> 
>>   isc/bind can and perhaps should implement logging for these
>> rrtypes that say they may be going away so folks can see the impact.
> 
> I'm actually surprised to see that support for rarely-used RRTypes is
> really upsetting the camel.
> 
> 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.
> 
> 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.
> 
> 
> Joe