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

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

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.

Consider explicitly calling out that padding (=) is not included when base64url-ing.

Thanks for adding the text!

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

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.