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

[Ignacio.Solis at parc.com]

On 10/10/14, 1:01 PM, "Alex Afanasyev" <alexander.afanasyev at ucla.edu>
wrote:

>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?

Basically yes.  It just doesn’t cover the static header and optional
headers (which you don’t have in NDN).



>> 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).

You still need a name, otherwise the Interest would not have been
forwarded.

Also, I’m not sure where you would get a hash only.  If you did get the
hash (and some potentially uninformative name) from the manifest, then you
already have that info, it’s in the manifest.

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

I was just clearing up the CCN methods. Even if you don’t do the same
thing in NDN, at least it would hopefully inform you of what we’re doing
in CCN so you can make good architectural choices.

Nacho


--
Nacho (Ignacio) Solis
Protocol Architect
Principal Scientist
Palo Alto Research Center (PARC)
+1(650)812-4458
Ignacio.Solis at parc.com