<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><blockquote type="cite" class="">On Apr 3, 2016, at 6:21 AM, Ralph Droms (rdroms) <<a href="mailto:rdroms@cisco.com" class="">rdroms@cisco.com</a>> wrote:<br class=""><br class="">In the icnrg meeting, we didn't have time to discuss this sub-bullet of principle 2:<br class=""><br class=""> Although data packets are immutable, applications can make changes to the communicated content by creating new versions of immutable data packets.<br class=""><br class="">I need help understanding how the phrase "new versions of immutable data packets" makes sense. "new version" and "immutable" seem contradictory. Jeff promised get me some help, here, if I moved the discussion to the mailing list.<br class=""><br class="">- Ralph<br class=""></blockquote><div class=""><br class=""></div>I can see how the wording could lead to confusion.<div class="">my understanding of what it is meant to say is this:<div class=""><ul class=""><li class="">/foo/bar/ICNslides/v1 is immutable data</li><ul class=""><li class=""> (for simplicity lets assume it's just one data packet here)</li></ul><li class="">When I make changes to the slides, I produce /foo/bar/ICNslides/v2</li></ul></div><div class="">Lixia</div><div class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">On Mar 15, 2016, at 1:01 AM 3/15/16, <a href="mailto:Marc.Mosko@parc.com" class="">Marc.Mosko@parc.com</a> wrote:<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Mar 14, 2016, at 8:44 PM, Tai-Lin Chu <<a href="mailto:tailinchu@gmail.com" class="">tailinchu@gmail.com</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">sure - I don't want to expose names that identify me, or expose my communication activities. given that, the "network" doesn't have the job of finding things for me by partial names - I only want to expose the details of my communication to a service that I have authenticated, and only when those details are encrypted. the "names" visible to the network in that sort of world just get the packets moving - and the only LPM needed is LPM in the FIB to get me to one or more instances of a service.<br class=""></blockquote><br class="">Immutability is related to in-network discovery with LPM. If all packets are immutable, and there is no in-network discovery, ndn must rely on some other protocol that cannot not build on top of ndn for discovery (we should all agree that randomly guessing a version number or a certain name is not going to work well as “discovery”). This devalues ndn as an “universal" protocol.<br class=""></blockquote><br class="">Could you please define immutable? Do you mean that a single publisher will never use the same name for different contents? Is that mandatory or enforceable? Or do you mean that there is some cryptographic function possible on a packet such that one can detect if it changes? Are those cryptographic primitives mandatory in each packet?<br class=""><br class="">I disagree that it is a necessary condition that one have name suffix completion matching of a data object to an interest to facilitate discovery. One can build a discovery protocol over exact name matching. I usually build these where the cache returns a chunked table of contents listing possible matches instead of the CCNx 0.x / NDN approach of having to return a (potentially very large) data object and walk a tree which is really only efficient if you expect what you want to be left-most or right-most child and not require iteration.<br class=""><br class=""><br class=""><blockquote type="cite" class=""><br class=""><br class=""><blockquote type="cite" class="">On Mar 14, 2016, at 12:10 PM, Mark Stapp <<a href="mailto:mjs@cisco.com" class="">mjs@cisco.com</a>> wrote:<br class=""><br class="">interesting -<br class=""><br class="">On 3/14/16 11:27 AM, Burke, Jeff wrote:<br class=""><blockquote type="cite" class=""><br class=""></blockquote>[...]<br class="">RFC 6973 takes a nice approach, for example, by offering<br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">definitions of some technical properties and mechanisms, but not trying<br class="">to formulate an overall definition of "privacy".<br class=""></blockquote><br class="">So I can try to understand your point here - do you agree with the<br class=""></blockquote>authors that the primary privacy concerns are those of individuals? (Or,<br class="">more generally, are corporations people here for this discussion - a<br class="">more generic "data owner"?)<br class=""><blockquote type="cite" class=""><br class=""></blockquote><br class="">hmm - well, I don't think corporations are people, in the citizens united sense, but I think there's lots of commercial communication that needs to have the best possible protection, whether it's B2C or B2B?<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">The editors there say<br class="">that the body of the document, the discussion of the tradeoffs and<br class="">alternatives, is the best way they could come up with to approach that<br class="">abstraction. in practical terms, as you know well I think there's been<br class="">an over-reliance on opportunistic caching in ICN generally, and as a<br class="">result observability and correlation are defined to be positive<br class="">properties of ICN communication rather than harmful ones.<br class=""></blockquote><br class=""><br class="">Would I be correct to parse your concerns into two pieces that may<br class=""></blockquote>have different implications:<br class=""><blockquote type="cite" class=""><br class="">- Confidentiality of request (e.g., the consumer side)<br class="">- Confidentiality of publication (e.g., the publisher side)<br class=""><br class=""></blockquote><br class="">I think I have a mental image of "confidential request" - where an observer cannot see much beyond the routeable prefix needed to reach an instance of the service I want to communicate with. I'm not sure what "confidential publication" means, though? I think I want the replies to my requests to be encrypted with ephemeral, forward-secure key material, I don't want the names in the replies to expose any more than the names in the requests, and I want to be able to authenticate the service before I expose anything about my own identity or intentions. is that what you meant by "the publisher side"?<br class=""><br class="">[...]<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><br class="">most of these six "principles" sounded like "mechanisms" to me - the<br class="">list felt like the end of a discussion about alternatives and the best<br class="">ways to implement an architecture, rather than the start of one. it<br class="">sounded like "we're tired of questions about LPM in the PIT, so we're<br class="">going to stop calling that a possible mechanism and start calling it an<br class="">inevitable, immutable, unquestionable 'principle'".<br class=""></blockquote><br class="">Well, to take LPM for an example - it's actually not mentioned in<br class="">the<br class=""></blockquote>principle doc that Alex sent. The principle I suspect that you are<br class="">referring to is:<br class=""><blockquote type="cite" class=""><br class="">[5] In-Network Name Discovery: Interests should be able use<br class="">incomplete<br class=""></blockquote>names to retrieve data packets.<br class=""><blockquote type="cite" class="">A consumer may not know the complete network-level name for data, as<br class=""></blockquote>some parts of the name cannot be guessed, computed, or inferred<br class="">beforehand. Once initial data is received, naming conventions can help<br class="">determine complete names of other related data:<br class=""><blockquote type="cite" class=""><br class=""><br class="">* majority of interests will carry complete names<br class=""><br class="">* in-network name discovery expected to be used to bootstrap<br class=""></blockquote>communication)<br class=""><blockquote type="cite" class=""><br class=""><br class=""><br class="">Can you explain your objection in these terms?<br class=""><br class=""></blockquote><br class="">sure - I don't want to expose names that identify me, or expose my communication activities. given that, the "network" doesn't have the job of finding things for me by partial names - I only want to expose the details of my communication to a service that I have authenticated, and only when those details are encrypted. the "names" visible to the network in that sort of world just get the packets moving - and the only LPM needed is LPM in the FIB to get me to one or more instances of a service.<br class=""><br class="">Thanks,<br class="">Mark<br class="">_______________________________________________<br class="">Ndn-interest mailing list<br class=""><a href="mailto:Ndn-interest@lists.cs.ucla.edu" class="">Ndn-interest@lists.cs.ucla.edu</a><br class="">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest<br class=""></blockquote><br class=""><br class="">_______________________________________________<br class="">Ndn-interest mailing list<br class=""><a href="mailto:Ndn-interest@lists.cs.ucla.edu" class="">Ndn-interest@lists.cs.ucla.edu</a><br class="">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest<br class=""></blockquote><br class=""><br class="">_______________________________________________<br class="">Ndn-interest mailing list<br class=""><a href="mailto:Ndn-interest@lists.cs.ucla.edu" class="">Ndn-interest@lists.cs.ucla.edu</a><br class="">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest<br class=""></blockquote><br class="">_______________________________________________<br class="">Ndn-interest mailing list<br class=""><a href="mailto:Ndn-interest@lists.cs.ucla.edu" class="">Ndn-interest@lists.cs.ucla.edu</a><br class="">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest<br class=""></blockquote><br class=""></div></div></body></html>