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

[SM <[e-mail]>]

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
>[e-mail] 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.'

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.

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.

Regards,
-sm