Re: (short version) Re: Last Call: <draft-faltstrom-uri-10.txt> (The Uniform Resource Identifier (URI) DNS Resource Record) to Proposed Standard

John C Klensin <john-ietf@jck.com> Thu, 26 February 2015 08:29 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B85A01A1B3D for <ietf@ietfa.amsl.com>; Thu, 26 Feb 2015 00:29:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 zi9-2u44e74w for <ietf@ietfa.amsl.com>; Thu, 26 Feb 2015 00:29:19 -0800 (PST)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62AD71A1B0C for <ietf@ietf.org>; Thu, 26 Feb 2015 00:29:19 -0800 (PST)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1YQtor-0002kT-Sh; Thu, 26 Feb 2015 03:29:17 -0500
Date: Thu, 26 Feb 2015 03:29:12 -0500
From: John C Klensin <john-ietf@jck.com>
To: Sam Hartman <hartmans-ietf@mit.edu>
Subject: Re: (short version) Re: Last Call: <draft-faltstrom-uri-10.txt> (The Uniform Resource Identifier (URI) DNS Resource Record) to Proposed Standard
Message-ID: <3BFE62AC6FAD9C47E36ED219@JcK-HP8200.jck.com>
In-Reply-To: <tslvbip8io6.fsf@mit.edu>
References: <54C9DA42.5040901@cisco.com> <9EB44D8A-278B-42FC-A542-1C182AD43128@netnod.se> <A74A30F4D1214630918FD4CA@JcK-HP8200.jck.com> <20150223153757.GI1260@mournblade.imrryr.org> <20150223155241.GJ1260@mournblade.imrryr.org> <tsl8ufoh9ko.fsf@mit.edu> <2DF7230C-D1D8-4B21-9003-B336108A38CB@vpnc.org> <20150224172649.GX1260@mournblade.imrryr.org> <tslvbircj0d.fsf@mit.edu> <0325DF3F-17F3-4400-BDEA-EDB5334BF35C@frobbit.se> <20150225180227.GT1260@mournblade.imrryr.org> <7AB921D35A7F9B23A53BD11A@JcK-HP8200.jck.com> <tslvbip8io6.fsf@mit.edu>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/1s6FBWsUNyyAHGV2xSiXgbP0A80>
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Feb 2015 08:29:20 -0000


--On Wednesday, February 25, 2015 22:18 -0500 Sam Hartman
<hartmans-ietf@mit.edu> wrote:

>     John> I think the rest is a bit of a judgment call.  While
> I'd be     John> happy to see a comprehensive document that
> would address all     John> of those issues, I would also like
> to get a good description     John> of the RRTYPE published
> somewhere soon, ideally a couple of     John> years ago.  It
> seems to me that making a complete analysis of     John>
> security alternatives, or a complete analysis of the URI
> John> situation as it relates to this RRTYPE, much less both
> are     John> likely to be a _lot_ of effort and that, if we
> want to get the     John> document published, what should be
> done should probably be     John> confined to explicitly
> noting the issues, e.g., that any     John> indirection
> through the DNS raises security issues that need     John>
> careful understanding and for which there is no magic bullet.
> 
> I'm happy with an informational document that does the above
> and claims only to describe the existing RR type.
> I'm not happy with a standards-track document that fails to
> cover the security issues in significantly better detail.

I'm inclined to be a little more flexible, but certainly a
choice between a narrowly-written Informational document and a
comprehensive Standards-track one -- with "comprehensive"
including careful discussion of both security considerations and
relationships to other alternatives -- would be my first
preference.

The current I-D is none of the above.  Instead, it is a mixture
of description of a new RRTYPE with an update to an existing
RRTYPE and weak coverage of relationships, alternatives,
security, and other tradeoffs.

   john