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

"Paul Hoffman" <paul.hoffman@vpnc.org> Sun, 25 March 2018 13:20 UTC

Return-Path: <paul.hoffman@vpnc.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 64F2B1250B8 for <dnsop@ietfa.amsl.com>; Sun, 25 Mar 2018 06:20:03 -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 jr7W8GfwwF2P for <dnsop@ietfa.amsl.com>; Sun, 25 Mar 2018 06:20:02 -0700 (PDT)
Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 3E87A124F57 for <dnsop@ietf.org>; Sun, 25 Mar 2018 06:20:02 -0700 (PDT)
Received: from [10.47.60.50] (dhcp-971f.meeting.ietf.org [31.133.151.31]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id w2PDJMl4032974 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 25 Mar 2018 06:19:25 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: mail.proper.com: Host dhcp-971f.meeting.ietf.org [31.133.151.31] claimed to be [10.47.60.50]
From: "Paul Hoffman" <paul.hoffman@vpnc.org>
To: "=?utf-8?b?T25kxZllaiBTdXLDvQ==?=" <ondrej@isc.org>
Cc: dnsop <dnsop@ietf.org>
Date: Sun, 25 Mar 2018 14:19:56 +0100
X-Mailer: MailMate (1.11r5462)
Message-ID: <066C83F5-5E1C-4DF8-8D45-A7E9F3A44673@vpnc.org>
In-Reply-To: <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> <20180325080558.GA18671@isc.org>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/1fH6ZyX2IuacmkhOwf6V2CoLlFo>
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: Sun, 25 Mar 2018 13:20:03 -0000

On 25 Mar 2018, at 9:05, Evan Hunt wrote:

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

Fully agree. I would hope that such guidance gets into the draft before 
it moves forwards.
>
> These RR types have text representations and wire format 
> representations,
> which from a complexity standpoint seem quite harmless to implement.

Yes.

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

...and probably needs to be kept for the future to interoperate with the 
current code bases.

> I don't see how the IETF can mandate that they be removed, nor am I 
> sure
> it's particuilarly worth doing.

Right.

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

> Perhaps that's all Ondrej has in mind?

Only he can say. :-)

--Paul Hoffman