Naming Things with Hashes
draft-farrell-decade-ni-10

[Ballot comment]
After a very good conversation with Ted Hardie (which should be written up as an Informational document), I agree that this does *not* belong as a URN (since this is not a managed namespace, which is the purpose of URNs) and that other URIs are names instead of locators. So, with the changes in the intro which explain better that these are names, I am fine with this document going forward.

*Please* undo the changes to section 3 changing "Required" and "Optional" to capitalized RFC2119 keywords. They are inappropriate. And they're inexact: Query Parameter Separator is *required* if any Query Parameter follows. Personally, I'd rather see them entirely dropped; they are already self-evident from the ABNF. 3986 doesn't use 2119 language; this document shouldn't either.

[Ballot discuss]
I do not think this document has a reasonable URI registration and I would like more information from the Expert Reviewer of how this passed muster. The current registration template says:

Applications/protocols that use this URI scheme name: General
  applicability.

I do not see how that satisfies the requirements of a URI registration. Moreover, I think this is indicative of a deeper problem: I cannot find an example of a URI that works the way ni: URI seems to work. The document provides no resolution mechanism for these URIs. The resolution mechanism seems to be "this will be resolved however your local implementation decides that they are to be resolved." This is not interoperable. And as far as I can tell, this is a big architectural shift from the normal use case of URIs. I think this needs pretty serious discussion.

[Ballot comment]
Wes makes an interesting point about whether this should be experimental.

If ever there were a good case for embedded mp4 in an RFC it is the nih example in section 8.3

[Ballot discuss]
In s2 you point out that sha-256-32 is useful for naming but not so much for security.  When values are included in the hash algorithm registry should a column be included to indicate whether they are useful for security and naming or just naming?  If not in the registry then in the document in which they are defined?

[Ballot comment]
1) r/sha-256 with SHA-26 to match 180-3 ;)

2) s3: r/Required/REQUIRED and Optional/OPTIONAL - assuming these are supposed to be 2119 words

3) s4: did you mean to reference 2818 for HTTPS or 2617?

4) s6: Should probably add that Res fields SHOULD be ignore upon receipt too.

5) s7: liked the joke

6) s7: OPTIONALLY isn't a 2119 keyword.

7) s9: Shame we can't reuse https://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xml but I guess IANA registries are cheap.

8) s9.4: Is the sentence about before approving the request only about deprecating or is that in general?  I'd love to give some advice to the initial expert along the lines of if anybody tries to register md2/4/5 then they can only be used for naming?  Maybe add references to 6149-6151?

9) s12.1: Any reason you can't point to 180-3?

[Ballot comment]
I don't have any technical problem with this document.

I doubt that it needs to go on the standards track though; it smells experimental to me.  There are lots of potential uses, but who is using it?

There's a note that it's similar to magnet URIs, but no mention of why it's better.  Since magnet is in widespread use, this seems important to give the analysis for, otherwise we should just be putting magnet on the standards track.

[Ballot comment]
I have no objection to the publication of this document. Here are a couple of minor thoughts you might consider before publication...

---

It would be helpful if the Abstract briefly stated the motivation for
this work.

---

In Section 2

  Truncated hashes MAY be supported if needed.

That is a bit confusing! "If needed" implies there could be cases where
there is a need - "need" sounds like "MUST". If you stick with "MAY"
then you will need to explain what happens when there is a "need" and
truncated hashes are not supported.

Alternatively, you need to scope when truncated hashes are needed and
direct implementations to support truncated hashes (MUST) when they are
operating in that environment.

---

Section 7

The redefinition of "nih" merits a reference to RFC 5513

IANA has reviewed draft-farrell-decade-ni and has the following comments:

IANA has questions about the actions related to IANA in this document.

IANA understands that, upon approval of this document, there are five actions
which IANA must complete.

First, this document requests adding two URI schemes to the URI scheme registry
located at:

http://www.iana.org/assignments/uri-schemes.html

The two URI schemes to be added are:

ni
nih

Currently the URI scheme registry is maintained through expert review as defined
in RFC 5226.

IANA Question -> has the document been reviewed by the URI Scheme registry expert?

Second, this document requests adding one Well-Known URI to the Well-Known URI
registry located at:

http://www.iana.org/assignments/well-known-uris/well-known-uris.xml

The Well-Known URI to be added is:

ni

Currently the Well-Known URI registry is maintained through expert review as
defined in RFC 5226.

IANA Question -> has the document been reviewed by the Well-Known URL registry
expert?

Third, IANA is requested to create a new registry. The registry will be called
the "ni Hash Algorithm Registry".

Future management of the registry will be done via Expert Review as defined in
RFC 5226.

Each registry entry will have five fields, the suite ID, the hash algorithm name
string, the truncation length, the underlying algorithm reference and a status
field.

There are initial values for this registry as follows:

ID Hash name string Value length Reference Status
0 Reserved
1 sha-256 256 bits [SHA-256] current
2 sha-256-128 128 bits [SHA-256] current
3 sha-256-120 120 bits [SHA-256] current
4 sha-256-96 96 bits [SHA-256] current
5 sha-256-64 64 bits [SHA-256] current
6 sha-256-32 32 bits [SHA-256] current
32 Reserved

Fourth, IANA is requested to crate a new registry. The new registry will be
called "Named Information URI Parameter Definitions".

Management of the registry will be done through Expert Review as defined in RFC
5226.

The fields in this new registry are the parameter name, a description and a
reference.

There is an initial registration in this registry, as follows:

Parameter Meaning Reference
----------- -------------------------------------------- ---------
ct Content Type [ RFC-to-be ]

IANA understands that these four actions are the only ones required upon
approval of this document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (Naming Things with Hashes) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'Naming Things with Hashes'
  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
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document defines a set of ways to identify a thing using the
  output from a hash function, specifying URI, URL, binary and human
  "speakable" formats for these names.  The various formats are
  designed to support, but not require, a strong link to the referenced
  object such that the referenced object may be authenticated to the
  same degree as the reference to it.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-farrell-decade-ni/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-farrell-decade-ni/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1773/
  http://datatracker.ietf.org/ipr/1775/

The PROTO writeup:

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

This document is targeted at becoming a Proposed Standard, as
indicated in the title page header. The document describes 2 new URI
schemes and some associated mapping procedures intended for widespread
use, thus Proposed is appropriate.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This document defines a set of ways to identify a thing using the
output from a hash function, specifying URI, URL, binary and human
"speakable" formats for these names.  The various formats are
designed to support, but not require, a strong link to the referenced
object such that the referenced object may be authenticated to the
same degree as the reference to it.

Working Group Summary

This is not a product of a WG and it never tried to become one.
However it was discussed in DECADE, CORE, and WEBSEC.  The CoAP
base protocol will normatively reference this document.

Document Quality

There is at least one implementation of an earlier draft. It looks
like this work might be applicable to multiple protocols (such as CoAP),
so I think more implementations will come. It is also partially based
on an unregistered magnet URI scheme, so there is desire in the
community to implement something like this.

Personnel

Alexey Melnikov is the document shepherd. Barry Leiba is the Responsible AD.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document shepherd read the whole document, trying to identify
issues with clarity, issues that might affect interoperability, etc,
in particular invalid use of URI constructs. Some minor issues were
reported and corrected.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No particular concerns, as this was already presented and reviewed by
participants of several WGs.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

The document had a good number of review by Applications and Security
Area people, so no additional reviews are needed.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the interested community has
discussed those issues and has indicated that it still wishes to advance
the document, detail those concerns here.

Use of the authority field in the "ni" URI scheme is unusual (because the scheme
is not tied to any access protocol), but doesn't seem to be problematic
according to URI reviews.  No other concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes, each author confirmed that no IPR disclosures need to be filed.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any discussion and conclusion regarding the IPR
disclosures.

There is an IPR disclosure from Xerox, a patent from 1998, filed on the
document.  The inventor became aware of this document just as it was
ready for last call, and filed the disclosure immediately.  As this is
an individual submission, any discussion of the IPR disclosure will
happen during last call.  In any case, the patent in question has
expired.
http://datatracker.ietf.org/ipr/1773/

(9) How solid is the consensus of the interested community behind this
document? Does it represent the strong concurrence of a few individuals,
with others being silent, or does the interested community as a whole
understand and agree with it?

I think there is solid support for this work.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

idnits 2.12.13 reports no errors, except for complaining about
"[required]" and "[optional]" not being references, and they aren't.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

The document requires URI scheme and .well-known reviews.  The latter
has been completed, and the designated expert has approved the assignment.
The former continues in parallel with the last call. Issues identified
earlier were discussed and addressed, but more changes might be needed
once the reviews finish.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

All normative references point to Standards Track RFCs except for one
that points to an ISO document, ISO/IEC 7812-1:2006.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No downrefs.

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs
is discussed. If this information is not in the document, explain why
the interested community considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document.

The IANA Considerations section creates 1 new registry for hash
functions (the document explains why a new registry), plus registers 2
new URI schemes and 1 .well-known URI scheme. I believe this is
correct and complete as far as the rest of the document is concerned.

Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.

Yes.

Confirm that any referenced IANA registries have been clearly
identified.

Yes.

Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

Yes.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

This document creates a new registry that is used for defining hashed
functions (and their truncated variants) for use in binary protocols
such as CORE. The ideal candidate should have expertise in Security,
with additional experience with low bandwidth/restricted power usage
technologies being desirable.

(19) Describe reviews and automated checks performed by to validate
sections of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, etc.

BAP was used to verify ABNF.

State Change Notice email list changed to stephen.farrell@cs.tcd.ie, cdannewitz@upb.de, Borje.Ohlman@ericsson.com, kutscher@neclab.eu, philliph@comodo.com, ari.keranen@ericsson.com, draft-farrell-decade-ni@tools.ietf.org, Alexey.Melnikov@isode.com from stephen.farrell@cs.tcd.ie, cdannewitz@upb.de, Borje.Ohlman@ericsson.com, kutscher@neclab.eu, philliph@comodo.com, ari.keranen@ericsson.com, draft-farrell-decade-ni@tools.ietf.org