IETF Logo Mail Archive

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

Matthijs Mekking <matthijs@pletterpet.nl> Mon, 26 March 2018 08:07 UTC

Return-Path: <matthijs@pletterpet.nl>
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 D48B71205F0 for <dnsop@ietfa.amsl.com>; Mon, 26 Mar 2018 01:07:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 fI45k0iPt4VY for <dnsop@ietfa.amsl.com>; Mon, 26 Mar 2018 01:07:54 -0700 (PDT)
Received: from aserp2130.oracle.com (aserp2130.oracle.com [141.146.126.79]) (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 E545F1200C5 for <dnsop@ietf.org>; Mon, 26 Mar 2018 01:07:53 -0700 (PDT)
Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w2Q83uWv024175 for <dnsop@ietf.org>; Mon, 26 Mar 2018 08:07:53 GMT
Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp2130.oracle.com with ESMTP id 2gxw06r0u4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <dnsop@ietf.org>; Mon, 26 Mar 2018 08:07:53 +0000
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w2Q87qJ5015554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <dnsop@ietf.org>; Mon, 26 Mar 2018 08:07:52 GMT
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w2Q87p1w001674 for <dnsop@ietf.org>; Mon, 26 Mar 2018 08:07:51 GMT
Received: from [192.168.178.27] (/83.160.139.153) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 26 Mar 2018 01:07:51 -0700
To: dnsop@ietf.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>
From: Matthijs Mekking <matthijs@pletterpet.nl>
Message-ID: <dc666131-be55-4d20-254d-0f77fc338be5@pletterpet.nl>
Date: Mon, 26 Mar 2018 10:07:47 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <CAJhMdTPRn=mUQ6xh_HFdFLBk109b_M2+saS86KFxsttb8_oVvw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8843 signatures=668695
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=1 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803260088
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/o947WkQI2G6jz7vWhfNFDWUg5bU>
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: Mon, 26 Mar 2018 08:07:56 -0000


On 24-03-18 14:48, Joe Abley 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.

To me this deprecating obsolete records is more an exercise of picking 
the low hanging fruit. Start with an easy task, gain experience for more 
difficult "unloading the camel".

Best regards,
   Matthijs


> 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
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>

v2.23.0 | Report a Bug | By Email