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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx 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


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]