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@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.' 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 >