[Nfd-dev] Please review the update of NDN-TLV spec, introducing implicit digest name component

[Alex Afanasyev]

On Oct 10, 2014, at 12:48 PM, <Ignacio.Solis at parc.com> <Ignacio.Solis at parc.com> wrote:

>>> Yes, the parc's proposal introduces hash restriction (aka selector).  As
>>> I understand correctly, this restriction is based on "content hash",
>>> rather than "data packet hash".   This is very different thing from the
>>> implicit hash and has very different use case:  content hash identifies
>>> "content", while implicit digest identifies specific Data packet (which
>>> is the atomic unit in NDN sense).  With just content hash it is
>>> impossible to "exclude" wrong data, since it is not really known whether
>>> the content is wrong or signature is wrong.  It also has implications
>>> while requesting Data: what you would get back is "content", which can
>>> have any name.  This may be acceptable in some cases, while not so in
>>> others where name is used by the application (e.g., if app needs to know
>>> which segment this returned piece of content belongs).
> 
> The ContentObjectHash restriction in CCN is over the Content Object (as
> the name implies).  This includes the name and signature (if present).

Sorry. I misunderstood then.  So, this basically exactly the same thing, covering Name, meta parts of the data packet, Content, and signature parts?


> It is the same as the implicit hash in the sense that the hash is implicit
> in the content object.  This is calculated over the message. The static
> headers and the optional headers are NOT part of the message.
> 
> We don¹t exclude data, so that is, effectively, impossible for CCN.
> Having said that, if you followed the SelectorProtocol described in the
> NDN-interest list this ContentObjectHash would be able to be used for
> excludes just like the ones on NDN.  It servers the same purpose but it¹s
> not part of a name.
> 
> It is NOT true that the content you get can have any name.  The content
> has either a) the exact same name as the interest (after all, we do exact
> matching), or b) no name at all.
> 
> Also, I don¹t understand why you say that the app needs to know what
> segment you¹re getting.  Didn¹t you request the content with a name
> anyway?  Use that name.  Also, if you have a ContentObjectHash, that means
> somebody gave you that hash, did they not tell you what this hash was for?

I just gave an example of what can go wrong with this.  Yes, you're requesting by hash.  But if the only thing you know is the hash, how would you reliably reconstruct the whole thing without relying on something extra (like the order in manifest).

In any case, this is a separate discussion and the primary goal for my original email is to move the NDN spec forward.

---
Alex