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

From: SM <[email-masked]>
Date: Mon, 11 Jun 2012 05:30:38 -0700

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
>[email-masked] 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

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 11 Jun 2012 13:51:23 +0100

On 06/11/2012 01:30 PM, SM wrote:
> Move the following to the first paragraph or a separate paragraph as it
> is not related to the second paragraph:
> 

Ok.

> definition in the BCP.  I leave it to the authors to apply RFC 2119

That looks better all right, thanks.

> 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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 22 Jun 2012 22:20:31 +0100

Hi All,

I went back through the IETF LC comments and think that we've
resolved them all on the list and have the changes in this
version [1] of the draft, with the possible exception of those
below.

The issues raised but not so far obviously resolved on the
list were I think:

1) inclusion of content type
2) nih as a URI scheme or not

For (1) this version includes ct= in draft-farrell-decade-ni
(the only changes to draft-hallambaker-decade-ni-params [2]
made so far are those that flow from moving that text), so
I'd hope that this version resolves that but would welcome
feedback on the new text from folks who commented. I'd hope
it should be ok, modulo some text tweaks.

For (2) we've left nih in as a URI scheme in this version.
We're still in favour of keeping it that way and have added
some language about why its there and is done like that. I'm
guessing that Martin at least won't be happy (but who knows;-),
so again comments are welcome as to whether the new text helps
or not. But in the end we'll go with Barry's consensus call
on this if he judges that we're in the rough, rather than the
folks who've commented on this topic. In that case I'll put
out a version with no nih scheme and the "human speakable"
format as just a textual convention (with a check-digit,
which'd be plain odd IMO, the uri scheme is the right idea
really:-)

Please let me know if I've missed addressing anything else
or if you have any other comments.

Cheers,
S.

[1] http://tools.ietf.org/html/draft-farrell-decade-ni
[2] http://tools.ietf.org/html/draft-hallambaker-decade-ni-params

(Note: only [1] is in IETF LC...just in case someone's
confused about that:-)

On 06/04/2012 03:18 PM, The IESG wrote:
> sent to [email-masked] 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/
> 
> 
> 
> 
>

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 25 Jun 2012 19:35:33 +0900

Hello Stephen, others,

On 2012/06/23 6:20, Stephen Farrell wrote:
> or not.

When reading your explanations, I had hoped that there would be some 
text along the lines of "different use case" that would really explain 
why two separate schemes are necessary. For example something similar to 
what Graham was mentioning at
http://www.ietf.org/mail-archive/web/ietf/current/msg73760.html, which I 
understand is similar to what I mentioned as fingerprints in our discussion.

Unfortunately, what I find is the following:

 > The justification for using a URI scheme for this is that that might
 > help a user agent for the speaker to better display the value, or
 > perhaps if there was some use-case for a machine to speak the value.

So we are creating a new URI scheme because *perhaps* there is a use 
case? Or because it *might* help? In the whole discussion, I was always 
ready to accept that there are different use cases, assuming that they 
could be clearly explained. I'm really wondering why this is so 
difficult. If these use cases really exist, it shouldn't be that 
difficult, and it shouldn't sound so vague, or should it? I'm not 
necessarily blaming you, but between you, your coauthors, and the WG 
that apparently proposed this, it shouldn't be that hard to come up with 
a better and more definite explanation than the sentence above.

 > We do not include the query string since there is no way to ensure
 > that its value might be spoken unambiguously, and similarly for the
 > authority, where e.g. internationalised forms of domain name could
 > not be usefully spoken.  This leaves the hash value as the only part
 > of the ni URI that we feel can be usefully included.  But since
 > speakers or listeners (or speech recognition) may err, we also
 > include a check-digit to catch common errors.

It is really strange to assume that text-to-speech software would work 
for English (or ASCII in general), but not for other scripts or 
languages. Sure, the level of text-to-speech software may not be exactly 
the same for each script and each language, but that's no reason to 
prohibit a domain name. There are definitely millions of domain names in 
e.g. Chinese or Japanese or Russian,... that can be spoken and re-typed 
quite unambiguously, and that users would have much less problems with 
than a long string of hex digits. (And we would still have the check 
digit, anyway.) On the other hand, it is quite possible to create domain 
names with ASCII/English that neither humans nor text-to-speech engines 
will be able to pronounce right.

Regards,   Martin.

> But in the end we'll go with Barry's consensus call

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 25 Jun 2012 13:05:56 +0100

Hi Martin,

> a better and more definite explanation than the sentence above.

IMO the use-case is clear, and is stated in the first sentence
of section 7.

I believe that Graham got the use-case, and accepted that its
different from ni URIs, but was questioning the need for nih to
be a uri scheme. He can confirm or refute that himself I guess,
but quoting his mail [1] (just before the one you reference):

"I can see that there are distinct use-cases here, and I
think you have reasonable grounds for not wanting to combine
them."

   [1] http://www.ietf.org/mail-archive/web/ietf/current/msg73758.html

Maybe the language I added for why we want nih as a uri
scheme is not sufficiently clear, or isn't convincing, but
that's a different argument.

> will be able to pronounce right.

The point is that we only leave in the ascii-hex. The
goal being to reduce this to something that can be
unambiguously spoken, and I think ascii-hex is about
as close as one can get to that. Anything else brings
additional ambiguity and hence is left out.

Its true that the machine-reading/recognition bit is
speculative though, but I don't think its much of a leap,
nor is it really crucial to the argument.

Cheers,
S.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 26 Jun 2012 20:11:37 +0900

Hello Stephen,

> IMO the use-case is clear, and is stated in the first sentence

That sentence reads:

   "Sometimes a name may need to be referred to in a format that is easy
    or unambiguous for humans to read out, for example, over the phone."

I continue to be convinced that this is not a separate use case. URIs 
are not a priori separable into those that are written down on napkins 
(or copy-pasted into emails,...) and those that are spoken over the phone.

If I send you an URI with a hash, I don't know whether you read your 
mail with your eyes (for which ni: seems appropriate) or whether you 
have a screen reader that does a text-to-speech conversion (for which 
nih: seems to be appropriate).

>     [1] http://www.ietf.org/mail-archive/web/ietf/current/msg73758.html

I think what Graham refers to as the "distinct use-cases" is identified 
in the second-to-last sentence of his mail:

     "I think you said somewhere in this exchange, nih: is intended to
      be used to confirm some information that you already have."

For all that I know about URIs, that would be consistent with Graham's 
questioning of the need for an URI scheme (because a resource is only 
confirmed, not identified). It would also be supported by the fact that 
the examples for "nih:" show only shortened hashes (which, as far as I 
understand, are okay for confirmation but not for search).

[One of my editorial comments was to streamline the examples so that the 
examples for ni: and nih: would appear with the same truncation lengths, 
in pairs. When I wrote that comment, I didn't realize that there might 
be a deeper reason for having different truncation lengths for ni: and 
nih:, mostly because that wasn't really very much explained in the draft.]

So the question is really, what's the use case, and what's just a 
consequence of that use case. If confirmation of already available 
resources (e.g. like a fingerprint) is the (main?) use case, and the 
greater weight on "speakability" just a design consequence, then it 
makes sense to have two separate things. If identification is the main 
purpose in both cases, then two separate schemes don't make sense.

> that's a different argument.

Let's for a moment concentrate on what is use case, and what are the 
design properties that follow from that. We can go back to language once 
we have made some progress on substance.

Regards,    Martin.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 26 Jun 2012 12:26:45 +0100

Hi again Martin,

On 06/26/2012 12:11 PM, "Martin J. Dürst" wrote:
> makes sense to have two separate things.

Yes, confirmation is the main current use-case for nih as I understand
it and have said previously. (Of course the resource might not yet
be present, so "already available" isn't quite right, but that's a
nit.)

Have we beaten this to death sufficiently now? I hope so;-)

If you want to suggest a sentence that says that, feel free.

Stephen.

---

From: SM <[email-masked]>
Date: Tue, 26 Jun 2012 13:06:11 -0700

Hi Stephen,
>2) nih as a URI scheme or not

[snip]

>which'd be plain odd IMO, the uri scheme is the right idea

I read Section 7 of draft-farrell-decade-ni-08.  The justification 
for a nih URI scheme elicits a smile.  The idea is futuristic. :-)  I 
suggest having a version without the nih scheme.

Regards,
-sm