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

Ondřej Surý <ondrej@isc.org> Mon, 26 March 2018 12:09 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 454DA120724 for <dnsop@ietfa.amsl.com>; Mon, 26 Mar 2018 05:09:19 -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 VIyj6xA7LnyB for <dnsop@ietfa.amsl.com>; Mon, 26 Mar 2018 05:09:18 -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 342F9127137 for <dnsop@ietf.org>; Mon, 26 Mar 2018 05:09:18 -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 041DF3AB002; Mon, 26 Mar 2018 12:09:18 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id DB7A916006B; Mon, 26 Mar 2018 12:09:17 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id BF99B160066; Mon, 26 Mar 2018 12:09:17 +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 Wl5gxsztei2z; Mon, 26 Mar 2018 12:09:17 +0000 (UTC)
Received: from [10.10.0.193] (40.20.broadband5.iol.cz [88.100.20.40]) by zmx1.isc.org (Postfix) with ESMTPSA id 1D7FA160043; Mon, 26 Mar 2018 12:09:16 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Ondřej Surý <ondrej@isc.org>
In-Reply-To: <066C83F5-5E1C-4DF8-8D45-A7E9F3A44673@vpnc.org>
Date: Mon, 26 Mar 2018 14:09:14 +0200
Cc: dnsop <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <DCE31CFA-534E-451F-B743-E022F62C7516@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> <20180325080558.GA18671@isc.org> <066C83F5-5E1C-4DF8-8D45-A7E9F3A44673@vpnc.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/qf1jfyXddo39dk80bPSnzY6p_s8>
Subject: Re: [DNSOP] 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 12:09:19 -0000

> On 25 Mar 2018, at 15:19, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
> 
>> We can make them optional to implement in
>> the future, though.
> 
> ...except that, if some implementer reads this document as meaning that they don't have to handle the listed RRtypes in any special way, they could get nailed when interoperating with implementations that handle the compression correctly.

That’s one of the goals of the document - saying: “it’s ok to not implement those RR Types, and it’s ok to break if you receive them"

> 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.

Correct, and I was also seeking more feedback from the DNS people on that matter.

Currently, there are RR Types already marked as “OBSOLETE” in the IANA registry without clear understanding what that does really mean.  I guess the document might be able to specify what “OBSOLETE” means for RR Types (in the line of ^^^ “it’s ok to …”.)

Ondrej
--
Ondřej Surý
ondrej@isc.org