Re: [icnrg] CCNx drafts

[<[e-mail]>]

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 <[e-mail]<mailto:[e-mail]>> wrote:

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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]
Sent: Wednesday, April 06, 2016 2:06 PM
To: Ravi Ravindran; [e-mail]<mailto:[e-mail]>
Subject: Re: [icnrg] CCNx drafts

On 4/6/16, 1:04 PM, "icnrg on behalf of Ravi Ravindran" <[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> 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:[e-mail]] On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Wednesday, April 06, 2016 2:00 PM
To: [e-mail]<mailto:[e-mail]>
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)
[phone]
[e-mail]<mailto:[e-mail]>
_______________________________________________
icnrg mailing list
[e-mail]<mailto:[e-mail]>
https://www.irtf.org/mailman/listinfo/icnrg