<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=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class="">So, my point here, is we talk about immutable objects but in truth we do not have them unless we use a hash-based name. </div></div></div></blockquote><br class=""></div><div class="">There is ndn “implicit digest”, so if you take that into account, it will not be advisory.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class="">If the client sends a nonced name the publisher can return a link (in the ccnx sense, not the routing hints) plus uniquely named data of the table of contents appended for efficiency (to avoid a second round trip).</div></div></div></blockquote></div><div class=""><br class=""></div><div class="">I might not understand this protocol well, but it seems that the discovery protocol tries to maintain immutability (given that you don’t change the data packet later, and the nonced name is unique enough.)</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class=""> NDN (from CCNx 0.x) chose to use mandatory in-network discovery base solely on name components, exclusions, and tree traversal. That’s ok, and one could claim that is sufficient. CCNx 1.0 chose to use explicit discovery protocols. My main point in asking about this is to point out that in-network mandatory discovery at the forwarder level is not a necessary condition.</div></div></div></blockquote></div><div class=""><br class=""></div><div class="">Please don’t misunderstand my previous comments; I am a supporter for immutability not in-network discovery.</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 10:22 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="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On Mar 14, 2016, at 9:53 PM, Tai-Lin Chu <<a href="mailto:tailinchu@gmail.com" class="">tailinchu@gmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div 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>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">Well, as you seemed to notice, if your system relies on an advisory feature for correctness, that’s a tenuous position. That’s probably not a correct statement for NDN, as an end node should be able to detect (hopefully) if a Data object is what it expected
via signature or something and try again with an exclusion. however, you might not have liveness.</div>
<div class=""><br class="">
</div>
<div class="">So, my point here, is we talk about immutable objects but in truth we do not have them unless we use a hash-based name. We can define that a correctly operating publisher will never re-use a name and it cryptographically binds every Data object, but that
is not immutable objects. That’s a protocol that generates unique objects. Unique is not immutable. A publisher could have a failure that causes its sequence number to reset or a memory error that causes the version number to flip a bit, etc.</div>
<div class=""><br class="">
</div>
<blockquote type="cite" class="">
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<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>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">If the client sends a nonced name the publisher can return a link (in the ccnx sense, not the routing hints) plus uniquely named data of the table of contents appended for efficiency (to avoid a second round trip).</div>
<div class=""><br class="">
</div>
<div class="">I would think that doing cursors over table of contents rows is much more efficient in a large distributed system than returning potentially large data objects and doing search. If I have 100M versions of a name and I want to scan the data for some attribute,
I think its much easier to fetch a partial tables of contents and pick the exact ones I want to retrieve than to iterate over the set using some name heuristic.</div>
<div class=""><br class="">
</div>
<div class="">This method also allows one to do discovery based on other criteria (attributes), such as signer keyids or other TLV fields, rather than just name elements. I could, for example, do a */superman.mov/* search for all names with superman.mov as a name component
(if that type of query was allowed by the protocol). Or I could ask for only data objects that were manifests.</div>
<div class=""><br class="">
</div>
<div class="">Because this matching is done via an explicit discovery protocol, not as part of the forwarder, I have a lot of flexibility in the attributes I can query and the access control I can enforce.</div>
<div class=""><br class="">
</div>
<div class="">It is a design choice. NDN (from CCNx 0.x) chose to use mandatory in-network discovery base solely on name components, exclusions, and tree traversal. That’s ok, and one could claim that is sufficient. CCNx 1.0 chose to use explicit discovery protocols.
My main point in asking about this is to point out that in-network mandatory discovery at the forwarder level is not a necessary condition.</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<br class="">
<div class="">
<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="">
<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" class="">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a><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="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div></blockquote></div><br class=""></body></html>