[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [193.110.157.68]) (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 [76.10.157.69]) (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 [127.0.0.1]) 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
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. NITS: 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". Paul
- Re: [DNSOP] Fwd: New Version Notification for dra… Jim Reid
- [DNSOP] Fwd: New Version Notification for draft-s… Ondřej Surý
- Re: [DNSOP] Fwd: New Version Notification for dra… Joe Abley
- Re: [DNSOP] [Ext] Fwd: New Version Notification f… Paul Hoffman
- Re: [DNSOP] [Ext] Fwd: New Version Notification f… Evan Hunt
- Re: [DNSOP] [Ext] Fwd: New Version Notification f… Paul Hoffman
- Re: [DNSOP] [Ext] Fwd: New Version Notification f… Miek Gieben
- Re: [DNSOP] [Ext] Fwd: New Version Notification f… Joe Abley
- Re: [DNSOP] [Ext] Fwd: New Version Notification f… Jim Reid
- Re: [DNSOP] [Ext] Fwd: New Version Notification f… Martin Hoffmann
- Re: [DNSOP] [Ext] Fwd: New Version Notification f… Shane Kerr
- [DNSOP] reply (and free review) Re: [Ext] Fwd: Ne… Paul Wouters
- Re: [DNSOP] [Ext] Fwd: New Version Notification f… Evan Hunt
- Re: [DNSOP] [Ext] Fwd: New Version Notification f… Paul Vixie
- Re: [DNSOP] [Ext] Fwd: New Version Notification f… Andrew Sullivan
- Re: [DNSOP] Fwd: New Version Notification for dra… Donald Eastlake
- Re: [DNSOP] Fwd: New Version Notification for dra… Patrick Mevzek