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(_at_)ietf(_dot_)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