Subject: [icnrg] CCNx drafts

From: <[email-masked]>
Date: Wed, 6 Apr 2016 16:59:35 +0000

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]

---

From: Ravi Ravindran <[email-masked]>
Date: Wed, 6 Apr 2016 20:04:58 +0000

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:

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

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.

Regards,
Ravi

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

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

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 7 Apr 2016 16:09:41 +0000

Hi,

On 2016-04-06, at 18:59, [email-masked] wrote:
> The ccnx:// one adopting it and moving it towards publication.

quick comment: It doesn't seem that RFC7595 is cited, and it doesn't seem that this document follows the procedure RFC7595 specifies for requesting a new URI scheme?

Lars

---

From: <[email-masked]>
Date: Thu, 7 Apr 2016 16:45:50 +0000

It’s on the todo list.  We were looking to get the doc adopted and then work on it to get it up to spec.  

We’ll want to get that going in the path to publication as soon as possible since it’s used from the other docs.  The other option is to not use it in the other base docs and wait until the WG to cross-reference.

Nacho

---

From: <[email-masked]>
Date: Fri, 8 Apr 2016 01:55:02 +0000

We also need to determine if running this through ICNRG is the right course.  If we’re going to go down the RFC 7595 path, we need to decide how to publish our usage specification.  I believe it could be any form of RFC (i.e. Experimental), in which case getting it approved as Experimental via ICNRG and the name allocated via IANA via 7595 should be sufficient.

As Nacho mentioned, we’ve not dotted all the i’s and crossed all the t’s on any of our drafts yet.  Now that it looks like they will move forward, we will revise them towards that goal.

We also need to finalize how we’re structuring the ccnx uri scheme.  We had originally written the draft as “labelled segment URIs”, being a general purpose “label=value” syntax for path segments and then a separate draft on the CCNx specifics using LS-URI.  At some point (due to too many drafts floating around) we collapsed that in to one draft.  If it’s going to stay one draft, we should probably collapse it even more to just be the usage conventions of the ccnx schema.  It would simplify the draft quite a bit.

Marc
 
> On Apr 7, 2016, at 1:45 PM, [email-masked] wrote:
> 
> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg