[DNSOP] reply (and free review) Re: [Ext] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-01.txt

Paul Wouters <paul@nohats.ca> Mon, 13 May 2019 14:51 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 21B99120094 for <dnsop@ietfa.amsl.com>; Mon, 13 May 2019 07:51:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id byvCy5Lv6s8q for <dnsop@ietfa.amsl.com>; Mon, 13 May 2019 07:51:24 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca []) (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 7F29012009C for <dnsop@ietf.org>; Mon, 13 May 2019 07:51:24 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 452kKP6s8DzFDt for <dnsop@ietf.org>; Mon, 13 May 2019 16:51:21 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1557759081; bh=HgA4XpMyJ/6YR9lISMbK5CfWi00KcnS09LikbIHIkEQ=; h=Date:From:To:Subject:In-Reply-To:References; b=BD3ZU6A1jP349u4wG7FN6eqql3Qc+qpPhVXNiey1kxAizgI3ZPcx8jgdXvH+teymU PTtuwi7kYk8Tgfbxk/6X2K+P9ZNeh6IBJmia1cO5PP0HIyLm/UDvVgqVpgS0ApEaTE hn12eYgRbpp6ys2b0RW4fCHTdkrhvFsNV/3Q1OHk=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id EBzI7wUuMEx9 for <dnsop@ietf.org>; Mon, 13 May 2019 16:51:20 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for <dnsop@ietf.org>; Mon, 13 May 2019 16:51:19 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id EC3E6372C; Mon, 13 May 2019 10:51:17 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca EC3E6372C
Received: from localhost (localhost []) by bofh.nohats.ca (Postfix) with ESMTP id DC5A641C02C8 for <dnsop@ietf.org>; Mon, 13 May 2019 10:51:17 -0400 (EDT)
Date: Mon, 13 May 2019 10:51:17 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: dnsop <dnsop@ietf.org>
In-Reply-To: <F8E0E608-524F-452A-9549-B5085C927487@icann.org>
Message-ID: <alpine.LRH.2.21.1905131035080.16634@bofh.nohats.ca>
References: <155771990790.31813.2767356343632633845.idtracker@ietfa.amsl.com> <7023B4C5-5207-4183-A945-244E65F00302@isc.org> <1A7FE19D-E4B1-48FB-8225-DCD055E4FDCD@icann.org> <20190513080019.GB28485@isc.org> <F8E0E608-524F-452A-9549-B5085C927487@icann.org>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/1FK_gdfdYxOIy8brNXaqbyYEaUI>
Subject: [DNSOP] reply (and free review) Re: [Ext] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-01.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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, 13 May 2019 14:51:27 -0000

On Mon, 13 May 2019, Paul Hoffman wrote:

>> I'm not sure I understand the distinction you're making here?
>> What you said sounds similar to what the document proposes, so
>> perhaps the document is unclear, or perhaps I've misunderstood you.
> I am proposing that we don't need a document, nor changes to the IANA registry: just treat whatever RRtypes you as a developer feel are no longer used as unknown types and move on.

It would be helpful for new developers to know which ones to treat this
way, and the best place for that would be an IANA indication that they
shouldn't bother implementing those RRtypes specifically.

I also think it should be a dnsop decision when to make an RRtype
deprecated, not a decision by the IANA Expert.

As a quick review of draft-sury-deprecate-obsolete-resource-records-01

- Include mentioning in the abstract what deprecating means here (eg
   treat as unknown RR rather than exploding)

- The "dns paramaters" IANA reference is not good enough. It should
   specifically link to the "Resource Record (RR) TYPEs" IANA Registry.

- It should not change the Meaning field, but request IANA to add a
   deprecated field and populate that.

- Stating that Recursive DNS Servers "SHOULD warn" is bad. That is a
   denial of service in the waiting, so implementers will rate limit or
   ignore this advise anyway.

- [REcursive DNS servers ...] and they MUST NOT be re-transmitted;
   That sounds like a protocol change that should not be done by
   this document.

- "DNS Clients which receive DEPRECATED RR Types MAY interpret them
   as unknown RR types ([RFC3597]), and MUST NOT interfere with
   their transmission;"
   If they MAY treat these as unknown RRs, what else MAY they do with
   this that it is not a MUST? How do such other MAYs affect the MUST
   NOT interfere ?

- "DEPRECATED RR Types MUST never be treated as a known-type with
    respect to the wire protocol."
    Wouldn't this make all existing implementations immediately violate
    the DNS standards?

- Security Considerations - You must do better here. What happens when
   old and new implementations talk to each other, when something is no
   longer "processed" like before. Convince me there are really no
   security things to worry about. It seems the next section talks about
   "problems" so how are those not security problems?

- Operational Section - You mention problems without describing the
   actual problems. Tell us what the problems are and how to
   operationally avoid those problems when implementing this document.
   "should not cause significant operational problems" is WAAAAAY to
   weak. You are basically admitting implementing things might blow up
   in your face. Do more testing, meassuring, etc and write an actual
   Implementation Considerations section showing there are no problems
   implementing this.


 	This document updates [RFC1035], [RFC1035],

did you forget to update the 2nd to another number?

 	are no longer in common use

Remove the word "common".