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 <> Thu, 26 February 2015 08:29 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B85A01A1B3D for <>; Thu, 26 Feb 2015 00:29:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.61
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zi9-2u44e74w for <>; Thu, 26 Feb 2015 00:29:19 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 62AD71A1B0C for <>; Thu, 26 Feb 2015 00:29:19 -0800 (PST)
Received: from [] ( by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) 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 <>
To: Sam Hartman <>
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: <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
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-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 26 Feb 2015 08:29:20 -0000

--On Wednesday, February 25, 2015 22:18 -0500 Sam Hartman
<> 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

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.