<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Immutable = one data packet cannot be changed after publication. </div><div class=""><br class=""></div><div class="">No, it is not “a single publisher will never use the same name for different contents” (I believe this is "uniquely named") nor “there is some cryptographic function possible on a packet such that one can detect if it changes”. </div><div class=""><br class=""></div><div class="">Immutability is advisory here. If I start to violate immutablity in a distributed system where everything is assumed to be immutable, I am doomed to get incorrect result (I guess this sounds mandatory). I think immutability is a good choice overall, and it is better to state it as a principle so that nobody will use ndn the wrong way.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><span class="" style="display: inline !important;">One can build a discovery protocol over exact name matching.</span></blockquote><br class=""></div><div class="">Is the table of contents immutable? I think your approach is fine and efficient but it is rather hard to manage in a large distributed system if the table is not immutable.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 14, 2016, at 9:01 PM, <<a href="mailto:Marc.Mosko@parc.com" class="">Marc.Mosko@parc.com</a>> <<a href="mailto:Marc.Mosko@parc.com" class="">Marc.Mosko@parc.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class="Apple-interchange-newline">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 style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" 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?</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" 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.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" 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=""><a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" class="">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a></blockquote></div></blockquote></div><br class=""></body></html>