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

Pete Resnick <> Fri, 27 February 2015 16:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D15D41ACDA8 for <>; Fri, 27 Feb 2015 08:24:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.011
X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ea804Pi2wFA3 for <>; Fri, 27 Feb 2015 08:24:25 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EDFBC1ACD9E for <>; Fri, 27 Feb 2015 08:24:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=qcdkim; t=1425054266; x=1456590266; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=AnS1zbyfqmRZdYzrXJ/0/M8yevSrutLl2GJoGbhLooI=; b=VU00Gzi7tqxH8IVunbfsswKrY+eOGehgpge103P0QthjHRg7LJ8utR8i R+pddUm7/suOKJLWdumYjjPXYRCCxPIXsVBhQsnjlc8KEPg7pTewrd68w +ahLGGjE4GO0NWSw+7q4IRTkr+DpsO8pw/8c1p1uHVeXeGug6+e970Bli M=;
X-IronPort-AV: E=McAfee;i="5600,1067,7724"; a="84789118"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Feb 2015 08:24:25 -0800
X-IronPort-AV: E=Sophos;i="5.09,660,1418112000"; d="scan'208";a="913825049"
Received: from ([]) by with ESMTP/TLS/RC4-SHA; 27 Feb 2015 08:24:24 -0800
Received: from presnick-mac.local ( by ( with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 27 Feb 2015 08:24:23 -0800
Message-ID: <>
Date: Fri, 27 Feb 2015 10:24:21 -0600
From: Pete Resnick <>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv: Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: <>
Subject: Re: (short version) Re: Last Call: <draft-faltstrom-uri-10.txt> (The Uniform Resource Identifier (URI) DNS Resource Record) to Proposed Standard
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: []
X-ClientProxiedBy: ( To (
Archived-At: <>
Cc: John C Klensin <>, Sam Hartman <>, =?ISO-8859-1?Q?F=E4ltstr=F6m_Patrik?= <>
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: Fri, 27 Feb 2015 16:24:28 -0000

On 2/25/15 9:18 PM, Sam Hartman wrote:
>>>>>> "John" == John C Klensin<>  writes:
>      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.

After speaking with Patrik, I think you have convinced us: The correct 
thing to do at this point is to take out all of the information beyond a 
simple description of the RR, beef up the security considerations to 
describe the security issue, and make that document Informational.

I'm going to ask Patrik to publish a revised ID at this point, which I 
expect to see in the next couple of days. Unless I hear loud objections 
(and I will cormfirm with the rest of the IESG as well), I'm inclined to 
simply extend the current Last Call by 2 weeks after the revised ID 
instead of restarting an entirely new 4 week Last Call. I think the 
discussion is active enough here on the list that nobody is going to 
lose track of it, and we're now talking about an Informational document 
rather than something that's going to be Standards Track, so the level 
of required scrutiny is certainly less. If we make this go another 4 
weeks, I'll be off of the IESG and someone else is going to have to pick 
up the ball, which I'd rather avoid having to do. Either way, I'll be 
sure to make an announcement.


Pete Resnick<>
Qualcomm Technologies, Inc. - +1 (858)651-4478