Re: [icnrg] CCNx 1.0 selector discovery

Hi Marc,

Some comments:

Section 3.3 says “The excludes must be sorted in ascending order, using the normal Name sorting rules.” What are the “normal” name sorting rules? I don’t see them in  draft-irtf-icnrg-ccnxmessages-03.

Section 4 says “A non-participating content store MUST objey the outer cache control directives, as normal…. It is RECOMMENDED that a participating node creating the encapsulated response set a short RecommendedCacheTime.” But draft-irtf-icnrg-ccnxmessages-03 section 3.4.2 says “[a Recommended Cache Time] is a recommendation only and may be ignored by the cache.”  So, for a non-participating content store, behavior “as normal” is that it can ignore the Recommended Cache Time. No? This seems to conflict with “MUST” in draft-mosko-icnrg-selectors-00.

[You know I was going to bring this up, so here we go.] I assume cache time is important because a name with a selector such as a “right” child selector can indicate a different Content Object from one second to the next. So you need non-participating content stores on the return path to not keep returning the same Content Object for a name with this selector, when the intention is to indicate a “newer” Content Object. But draft-irtf-icnrg-ccnxmessages-03 only recommends obeying RecommendedCacheTime, and downplays problems with changes to this unsigned field, saying "There is little ill effect from an attacker changing the RCT as the RCT serves as a guideline only.” But where selector behavior is concerned, it’s a little more important than “a guideline only” since an old cache hit means that the consumer won’t get what they’re asking for.

Maybe draft-mosko-icnrg-selectors-00 can say something more about this?

Thanks,
- Jeff T

On 2016/8/1, 9:07:31, "icnrg on behalf of Marc.Mosko@parc.com<mailto:Marc.Mosko@parc.com>" <icnrg-bounces@irtf.org<mailto:icnrg-bounces@irtf.org> on behalf of Marc.Mosko@parc.com<mailto:Marc.Mosko@parc.com>> wrote:

All,

Back in 2014, I believe we discussed how to use an equivalent of NDN/CCNx 0.x selector discovery in CCNx 1.0, but we never publicly published that spec.  It was tied up with some early drafts of CCNx 1.0.  Here is a writeup of how to do the equivalent of selector based discovery on top of CCNx 1.0.  I do not intend this to be the single, canonical way of doing discovery.  I think there are many ways one could do it, and CCNx 1.0 provides the flexibility to use different discovery protocols.

I had to update it a fair bit from the pre-public 1.0 spec it was written against at that time.  Therefore, there may still be a few issues with how it is written up and I would appreciate feedback.

Marc

https://www.ietf.org/id/draft-mosko-icnrg-selectors-00.txt

P.S.
Some other example discovery protocols are described here:

http://www.ccnx.org/pubs/hhg/4.8%20CCNx%201.0%20Simple%20Service%20Discovery%20for%20Content%20Centric%20Networks.pdf
http://www.ccnx.org/pubs/hhg/4.7%20CCNx%201.0%20Collection%20Synchronization.pdf

P.P.S
Also on the NDN-INTEREST mailing list, I gave another example that is more SQL-like in syntax and returns row sets (not data objects), and allows one to specifically exclude an entire Content Store.
http://www.lists.cs.ucla.edu/pipermail/ndn-interest/2016-March/001051.html

_______________________________________________
icnrg mailing list
icnrg@irtf.org<mailto:icnrg@irtf.org>
https://www.irtf.org/mailman/listinfo/icnrg