Re: Last Call: <draft-farrell-decade-ni-07.txt> (Naming Things with Hashes) to Proposed Standard

Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 11 June 2012 12:51 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC9121F85AA for <ietf@ietfa.amsl.com>; Mon, 11 Jun 2012 05:51:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.149
X-Spam-Level:
X-Spam-Status: No, score=-102.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62I+TYAerXYD for <ietf@ietfa.amsl.com>; Mon, 11 Jun 2012 05:51:29 -0700 (PDT)
Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id A9A5B21F8566 for <ietf@ietf.org>; Mon, 11 Jun 2012 05:51:28 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id ABDDC157557; Mon, 11 Jun 2012 13:51:24 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1339419084; bh=Hezzpi88W9vePs tEnA1wKnOd15R06W9ihOK2oxdRl48=; b=X7n8TuLhNZEeC5O5mX5CTEcOoExc7R Ce5N1jwdW6B9GXCaaY9O1+h6T8qawkthhzHpwZqiYI5CwW6fGkPSNIjzmxF0H1Fx aLKK4ryhCCyXkOwz9+GDWXiY85yn4m7TAIjqIozBE9xQtqI3KfXGI81QpWtKlQGJ 9k59dSjUF57UD+pyAXO0OAZ++J0NY+8v745crgUHyVsNE0cmtw4HsrxOjdx9LF6w Cl5fg5UBMNA9jjk4sPDYsw2H1RLrOrpHa1/z5r5TgnSmyITQDK5+oNV5FAs9PIgB 4fUFnGsNFJsyanRowjdhENbsq6f49mwczRph9PkvJTiX4epHsMLzYsZw==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id knD0OGUnKxAg; Mon, 11 Jun 2012 13:51:24 +0100 (IST)
Received: from [IPv6:2001:770:10:203:d29:9f2:c54f:4963] (unknown [IPv6:2001:770:10:203:d29:9f2:c54f:4963]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 01C27157554; Mon, 11 Jun 2012 13:51:23 +0100 (IST)
Message-ID: <4FD5E9CB.4040906@cs.tcd.ie>
Date: Mon, 11 Jun 2012 13:51:23 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: SM <sm@resistor.net>
Subject: Re: Last Call: <draft-farrell-decade-ni-07.txt> (Naming Things with Hashes) to Proposed Standard
References: <20120604141804.23098.42455.idtracker@ietfa.amsl.com> <6.2.5.6.2.20120611042706.095ba210@resistor.net>
In-Reply-To: <6.2.5.6.2.20120611042706.095ba210@resistor.net>
X-Enigmail-Version: 1.4.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org, draft-farrell-decade-ni@tools.ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
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: Mon, 11 Jun 2012 12:51:30 -0000

On 06/11/2012 01:30 PM, SM wrote:
> At 07:18 04-06-2012, The IESG wrote:
>> The IESG has received a request from an individual submitter to consider
>> the following document:
>> - 'Naming Things with Hashes'
>>   <draft-farrell-decade-ni-07.txt> as Proposed Standard
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action. Please send substantive comments to the
>> ietf@ietf.org mailing lists by 2012-07-02. Exceptionally, comments may be
> 
> Here's an editorial comment about Section 9.4 and Section 10.
> 
> Move the following to the first paragraph or a separate paragraph as it
> is not related to the second paragraph:
> 
>   'Note that if the status is not "deprecated" (it is empty), then that
>    does not necessarily mean that the algorithm is "good" for any
>    particular purpose, since the cryptographic strength requirements
>    will be set by other applications or protocols.'

Ok.

> 
> And for:
> 
>   'The expert SHOULD seek IETF review before approving a request to
>    mark an entry as "deprecated."  Such requests may simply take the
>    form of a mail to the designated expert (an RFC is not required).
>    IETF review can be achieved if the designated expert sends a mail
>    to the IETF discussion list.  At least two weeks for comments MUST
>    be allowed thereafter before the request is approved and actioned.'
> 
> Suggested text with pointers to comments:
> 
>   A request to mark an entry as "deprecated" can be done by sending
>   a mail to the designated expert.  Before approving the request,
>   the community should be consulted via a "call for comments" of
>   at least two weeks by sending a mail to the IETF discussion list.
> 
> Near the end of Page 14:
> 
>  "The expert MAY request IETF review before allocating a
>   suite ID."
> 
> Suggested:
> 
>  The designated expert may consult the community via a "call for
>  comments" by sending a mail to the IETF discussion list before
>  allocating a suite ID.
> 
> I avoided using the term "IETF review" because it is used policy
> definition in the BCP.  I leave it to the authors to apply RFC 2119
> casing as appropriate.

That looks better all right, thanks.

> 
> In Section 10:
> 
>   "While a name-data integrity service can be provided using ni URIs,
>    that does not in any sense validate the authority part of the name,
>    for example, there is nothing to stop anyone creating an ni URI
>    containing a hash of someone else's content so application developers
>    MUST NOT assume any relationship between the owner of a domain name
>    that is part of an ni URI and some matching content just because the
>    ni URI matches that content."
> 
> Suggested text:
> 
>    While a name-data integrity service can be provided using ni URIs,
>    that does not in any sense validate the authority part of the name.
>    For example, there is nothing to stop anyone creating an ni URI
>    containing a hash of someone else's content.  Application developers
>    MUST NOT assume any relationship between the registrant of the domain
>    name that is part of an ni URI and some matching content just because
>    the ni URI matches that content.
> 
> I don't understand why the last sentence is phrased as a requirement. 
> The first two sentences has a clear explanation about the authority part
> of the name.  I would remove the third sentence.

Looks better all right, thanks.

Updated at [1] again.

S.

[1] http://down.dsg.cs.tcd.ie/misc/draft-farrell-decade-ni.txt

> 
> Regards,
> -sm
>