Subject: Re: [icnrg] CCNx drafts

From: <[email-masked]>
Date: Wed, 6 Apr 2016 21:05:54 +0000

On 4/6/16, 1:04 PM, "icnrg on behalf of Ravi Ravindran" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Hi Nacho,

Can you clarify if Nameless Objects are within the scope of these draft ?. I tried looking for its reference and couldn’t find it in the drafts. These are some of my concerns if nameless objects are in scope:

Yes, Nameless Objects are within the scope of the drafts.

1.       With Nameless Objects the Interest names are locators and Contentobject hash digest which serve as an identifier is part of the hash restriction. Though at this point the protocol doesn’t  separate the ID/locator name space explicitly in the protocol, it will be good to clarify that names can also be locators when nameless objects are requested. Towards this, I would suggest to define locator names as another namespace  in the semantics document and differentiate it from the names assigned by applications i.e. the producers. This would also be in line with the Manifest proposal which distinguishes Hash IDs and Locators in its definition. This ID/Locator name space separation is what we have been arguing for through the forwarding-label draft.  To complement the nameless object proposal, we also updated the draft with the use case of using Content HashIDs with forwarding-labels in Section 9.2 of the draft https://tools.ietf.org/html/draft-ravi-ccn-forwarding-label-02

Names are network names.  Their use is for forwarding.  The documents should not describe where these names come from, just like they don’t describe how you fill in your FIBs.

In the semantics document the only place the mentions applications is in the application name components. These are reserved name segment types that the applications can use.  In the messages document applications are mentioned in how they have space reserved in a few of the fields.

The current spec does not prevent the use that you describe in your draft.  As a matter of fact, it enables it.

2.       Also I would suggest to introduce nameless objects as a new type of content object itself, instead of it being defined as a regular content object which doesn’t have a name TLV for two reasons: Firstly, producers may choose to publish named and nameless version at the same time, explicitly distinguishing them would help forwarders to apply appropriate processing; Second, this differentiates from the case of a malformed named object for which the router may end up computing its hash unnecessarily.

This is an interesting consideration, but it doesn’t work very well for us, it adds complexity.  Right now, as things are defined, the hash is computed over the message. This allows us to have a way to calculated the message hash independently of the message.  We can calculate the hash of nameless objects as well as regular objects.  This means we can do manifests and nameless objects, as well as secure retrieval of named objects (like the manifests themselves).

For the first case, named and nameless versions of the same object are allowed. The spec does not prohibit that. We don’t need 2 different content types for this.  The same processing would apply to both.

For the second case, I don’t understand what you mean. How are you improving the way that we detect that something is malformed by having a second content type?

Nacho

From: icnrg [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Wednesday, April 06, 2016 2:00 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [icnrg] CCNx drafts

Hi folks.

We are interested in moving the CCNx documents forward. The base docs, moving them towards publication. The ccnx:// one adopting it and moving it towards publication.

https://tools.ietf.org/html/draft-irtf-icnrg-ccnxmessages-02
https://tools.ietf.org/html/draft-irtf-icnrg-ccnxsemantics-02
https://tools.ietf.org/html/draft-mosko-icnrg-ccnxurischeme-00

The drafts have been pretty stable for a while. We made some minor updates to the documents with the Paris feedback and we will be discussing these tomorrow. We know this can be a lengthy process and we wanted to start the discussion on the list.

Please start voicing feedback and concerns.  The base documents are group documents and we would like the group to be ok with what they say.

Cheers,

Nacho

--
Nacho (Ignacio) Solis
Protocol Architect
Principal Scientist
Palo Alto Research Center (PARC)
+1(650)812-4458
[email-masked]<mailto:[email-masked]>

---

From: Ravi Ravindran <[email-masked]>
Date: Wed, 6 Apr 2016 22:07:13 +0000

I think that’s where I differ that we don’t simply define “Names as simply Network names”. In ICN, any base protocol definition has to define the source of the name, its features (being topological or not,  flat-names (self-certified), URI etc), particularly now when we are differentiating the producer of the content objects from the distributors.

I would’ve no problem, if the base protocol scope was only limited to named content objects, and explicitly state that  only those names are be used in the Interest as well. In this case we are only talking about names coming from application space. However, this discussion will eventually surface, when Manifests are formalized in which we callout for ID and locators and how they will be used in the base protocol.

My comment on having a new type for nameless content object was if, producer inadvertently produce a named content object without a name, and publish it, this is a error scenario which the forwarder can reject immediately. The main point here was that in the future there may  be more considerations towards a nameless objects (considering for example, computation efficiency  or other security concerns) where this clear distinction will help.

Regards,
Ravi

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, April 06, 2016 2:06 PM
To: Ravi Ravindran; [email-masked]
Subject: Re: [icnrg] CCNx drafts

Hi Nacho,

Nacho

Hi folks.

Cheers,

Nacho

---

From: <[email-masked]>
Date: Wed, 6 Apr 2016 22:28:08 +0000

On 4/6/16, 3:07 PM, "icnrg on behalf of Ravi Ravindran" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

I’m fine if you (or somebody else) wants to define a larger architecture scope document.  The documents we’ve been working on at ICNRG are a specific protocol definition.
They define:
- a data packet that has a “name” (optional), signature (optional) and an implicit hash.
- a request packet that has a “name” (required for forwarding), a keyId restriction (optional) and a hash restriction (optional).
- a request/response protocol based on these attributes.

Note that the hash in the documents does not depend on there being a name.  Any message has a hash that can be calculated. For manifests, the hash (that you call ID) and the name (that you call locator) work in the exact same way as the protocol describes now.

How/why would a producer _inadvertently_ produce a named content object without a name?  In the future there may also be considerations on name length or number of segments, and we may want to limit the name (architecturally) . When that day comes, we can consider those issues.

Right now, I don’t see a competing case for this.  It’s pretty easy to determine if the message has a name or not.

Do note that you will _still_ have to calculate hashes (if that’s what you’re doing) whether there is a name or not. There can always be a hash restriction on the interest independently of whether the content object has a name or no name.

Nacho

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Wednesday, April 06, 2016 2:06 PM
To: Ravi Ravindran; [email-masked]<mailto:[email-masked]>
Subject: Re: [icnrg] CCNx drafts

Hi Nacho,

Nacho

Hi folks.

Cheers,

Nacho

---

From: <[email-masked]>
Date: Wed, 6 Apr 2016 23:00:30 +0000

Ravi,

I see there are a few issues from your email we should discuss on Thursday.  I didn’t see a way to open issues against the document, so we’ll just need to track issues in email for right now (if someone can point me to how to open issues against the document, I’ll do it there).

I’m trying to separate the issues you bring up in your email into individual issues so we can make specific progress on them.

1) Should nameless objects be in the specs.

2) Should there be an explicit separation of locator names from identifier names.

3) How does this all affect the forwarding label draft.

4) Introduce a 3rd message type as NamelessContentObject in addition to a (Named)ContentObject.

Marc

On Apr 6, 2016, at 7:07 PM, Ravi Ravindran <[email-masked]<mailto:[email-masked]>> wrote:

Regards,
Ravi

Hi Nacho,

Nacho

Hi folks.

Cheers,

Nacho

--
Nacho (Ignacio) Solis
Protocol Architect
Principal Scientist
Palo Alto Research Center (PARC)
+1(650)812-4458
[email-masked]<mailto:[email-masked]>
_______________________________________________
icnrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/icnrg

---

From: Ravi Ravindran <[email-masked]>
Date: Thu, 7 Apr 2016 01:32:40 +0000

Hi Marc,

Those are good issues to discuss during the meeting.

I won’t be there for the Thursdays meeting, if there is a way to track how these issues are being addressed in the drafts, that would be nice.

Regards,
Ravi

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, April 06, 2016 4:01 PM
To: Ravi Ravindran
Cc: [email-masked]; [email-masked]
Subject: Re: [icnrg] CCNx drafts

Ravi,

Marc

Regards,
Ravi

Hi Nacho,

Nacho

Hi folks.

Cheers,

Nacho

---

From: Ravi Ravindran <[email-masked]>
Date: Thu, 7 Apr 2016 01:32:39 +0000

Please see inline for  my comments…

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, April 06, 2016 3:28 PM
To: Ravi Ravindran; [email-masked]
Subject: Re: [icnrg] CCNx drafts

Ravi> My issue is with the definition of a name in the Interest, which can be a locator and a application identifier as well; a forwarder  should distinguish these two cases.

Ravi > I don’t think so,  a CCNx forwarder will have to process Interests differently now that the names are not only application IDs but multiplexed with locator names too. So one has to always first look if there is a ContentHashId first, if not use the name in the Interest to index into the PIT. Instead using name always for application ID (ContentHashId is a implicit object ID by defintition, so why use it as a hash restriction ?) and introducing a locator for locator names can avoid this confusion.

Ravi > The case is a corner case, just as discussions have pointed out that same names can be reused making contentobjects muteable. Architecturally IMO, the distribution of nameless content objects have implications on the control and the forwarding plane. For e.g. named objects can be distributed over a routing plane, but a  nameless objects have to use something like a manifest, which has bearing on how a producer or the distributing mechanism has to handle these two kinds of content objects.

Nacho

Hi Nacho,

Nacho

Hi folks.

Cheers,

Nacho