<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="">
Ok, that’s fair to say that I am not up on current NDN naming conventions.
<div class=""><br class="">
</div>
<div class="">Is there a specification on this that I could read? There was some material on this in <a href="http://named-data.net/project/archoverview" class="">http://named-data.net/project/archoverview</a>. Is there a newer or more specific reference?</div>
<div class=""><br class="">
</div>
<div class="">I do have a problem with basic functions like in-network discovery and data transport being based on conventions and not specifications (like the packet format). I am of the position that there is no one “application” for the consumer/producer.
Data will want to be shared between many applications by many implementers. If each application must know how the source application named its data in order to fetch it, then I think that will lead to an n^2 problem of needing to know naming conventions
and transports. Applications already need to handle many data types (e.g. png, jpg, rtf, doc, html) and if they also need to handle many transport / naming conventions, I think that is adding a lot of complexity; especially if they have to guess the naming
convention based on name format without a specification.</div>
<div class=""><br class="">
</div>
<div class="">If there is a common convention, then I would make that explicit in the name somehow (there are many ways). For example, if one scheme uses version and segment and other scheme uses nonces and hash chains in the name, they are not compatible
at the transport layer. If you need a different mechanism to retrieve data, then I think there needs to be something to identify that without needing to heuristically guess it based on the format of the name. And there needs to be a specification on how
that transport naming works.</div>
<div class=""><br class="">
</div>
<div class="">In CCNx, we allocated specific name segment types to mean a specific protocol is operating at that level of the name. For example, a version has a specific type and a segment number (chunk number) has a specific type. Is there a similar mechanism
in NDN?</div>
<div class=""><br class="">
</div>
<div class="">Thank you,</div>
<div class="">Marc</div>
<div class=""><br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Apr 5, 2016, at 11:15 PM, Lixia Zhang <<a href="mailto:lixia@cs.ucla.edu" class="">lixia@cs.ucla.edu</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="">
(apology for delay in reply; time during weekdays always a challenge)
<div class="">My msg text was quoted below, but as I read the question it's not about my reply (I changed the subject line too to reflect real question). </div>
<div class="">Anyway let me throw in my 2 cents.</div>
<div class=""><br class="">
</div>
<div class="">this principle only says that the network should be able to take incomplete name and return a relevant data; from returned data the consumer learns more specifics about the existing data and may be able to construct complete name for future interests
(following some clearly defined naming conventions). </div>
<div class=""><br class="">
</div>
<div class="">(one cannot say that the sequence of actions listed below completely wrong, though clearly it didn't use any naming conventions, therefore lines 3 and 5 issued interest with the same prefix--as if one knew nothing about the naming structure,
without making use of any info one might have been derived from receiving the data packet from line 2)</div>
<div class=""><br class="">
</div>
<div class="">I dont think that the principle by itself defines the exact mechanisms.</div>
<div class="">e.g. I feel naming conventions could play an important role here. I believe we are still in early stage understanding the best way to define naming conventions. </div>
<div class=""><br class="">
</div>
<div class="">There is also a separate/separable question of what's the best way (least round trip) to get latest version; save that one for different discussion.</div>
<div class=""><br class="">
</div>
<div class="">I dont know what kind of naming convention is assumed in this particular app, I am not sure I can follow the reasoning of the sequence of exchanges...</div>
<div class=""><br class="">
</div>
<div class="">Lixia</div>
<div class=""><br class="">
</div>
<div class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On Apr 3, 2016, at 5:47 PM, <a href="mailto:Marc.Mosko@parc.com" class="">
Marc.Mosko@parc.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="">
So that I am clear on this, to use the in-network discovery approach and find the latest version of data, one would need to:
<div class=""><br class="">
</div>
<div class="">1) Issue an interest for /foo, right most child</div>
<div class="">2) Get back some /foo/ver=5/segment=0/hash=123</div>
<div class="">3) Issue an interest for /foo, excluding up to and including ver=5, right most child</div>
<div class="">4) Get back some /foo/ver=6/segment=0/hash=444</div>
<div class="">5) issue an interest for /foo excluding up to and including ver = 6</div>
<div class="">6) get back a NACK (or timeout)</div>
<div class="">7) issue an interest for /foo/ver=6/segment=0 excluding last seen hash (e.g. 444)</div>
<div class="">8) get back either a duplicate name with different hash (go to 7 and add another exclusion) or get back a NACK (or timeout)</div>
<div class=""><br class="">
</div>
<div class="">one would then need to make some sort of decision (e.g. keyid or something intrinsic in the data) to determine which version 6 to use (or maybe all).</div>
<div class=""><br class="">
</div>
<div class="">I’m not clear who issues the NACK in steps 6 and 8. I assume it would be an authoritative source (which might not exist in my connected component of the network, in which case they would be timeouts).</div>
<div class=""><br class="">
</div>
<div class="">Is that correct or did I miss something?</div>
<div class=""><br class="">
</div>
<div class="">Marc</div>
<div class=""><br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On Apr 3, 2016, at 9:00 PM, Lixia Zhang <<a href="mailto:lixia@cs.ucla.edu" class="">lixia@CS.UCLA.EDU</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<blockquote type="cite" style="font-family: Menlo-Regular; font-size: 14px; font-style: normal; font-variant: 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 Apr 3, 2016, at 12:56 PM, Dave Oran (oran) <<a href="mailto:oran@cisco.com" class="">oran@cisco.com</a>> wrote:<br class="">
<br class="">
<blockquote type="cite" class=""><br class="">
On Apr 3, 2016, at 3:06 PM, Lixia Zhang <<a href="mailto:lixia@cs.ucla.edu" class="">lixia@CS.UCLA.EDU</a>> wrote:<br class="">
<br class="">
<blockquote type="cite" class=""><br 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>
<br class="">
I can see how the wording could lead to confusion.<br class="">
my understanding of what it is meant to say is this:<br class="">
<span class="Apple-tab-span" style="white-space: pre;"></span>• /foo/bar/ICNslides/v1 is immutable data<br class="">
<span class="Apple-tab-span" style="white-space: pre;"></span><span class="Apple-tab-span" style="white-space: pre;"></span>• (for simplicity lets assume it's just one data packet here)<br class="">
<span class="Apple-tab-span" style="white-space: pre;"></span>• When I make changes to the slides, I produce /foo/bar/ICNslides/v2<br class="">
Lixia<br class="">
<br class="">
</blockquote>
What if I have a stateless producer that does not remember enough to maintain a monotonic (or worse, a sequential) counter, or if I have a distributed producer and it’s inconvenient/infeasible to run an agreement protocol to maintain the version number? Is
it in fact considered an “epic fail” for a producer to create two different bags of bits (and hence different hashes) that have identical names?<br class="">
</blockquote>
<br style="font-family: Menlo-Regular; font-size: 14px; font-style: normal; font-variant: 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: Menlo-Regular; font-size: 14px; font-style: normal; font-variant: 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
just used a simple example to mean<span class="Apple-converted-space"> </span></span><br style="font-family: Menlo-Regular; font-size: 14px; font-style: normal; font-variant: 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: Menlo-Regular; font-size: 14px; font-style: normal; font-variant: 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="">-
data is immutable</span><br style="font-family: Menlo-Regular; font-size: 14px; font-style: normal; font-variant: 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: Menlo-Regular; font-size: 14px; font-style: normal; font-variant: 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="">-
updated name should have a different name.</span><br style="font-family: Menlo-Regular; font-size: 14px; font-style: normal; font-variant: 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: Menlo-Regular; font-size: 14px; font-style: normal; font-variant: 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: Menlo-Regular; font-size: 14px; font-style: normal; font-variant: 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="">yes
name collision may occur in distributed production scenario. The ultimate way to distinguish different data packets is by their full name (i.e. name with implicit digest).</span><br style="font-family: Menlo-Regular; font-size: 14px; font-style: normal; font-variant: 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: Menlo-Regular; font-size: 14px; font-style: normal; font-variant: 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: Menlo-Regular; font-size: 14px; font-style: normal; font-variant: 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="">
In the same vein, is the following legal:<br class="">
<br class="">
At time T0, I create object with name a/b/c and bits “dsfasdfasdfadsfadfa”, and expiration time T0+deltaT.<br class="">
Then, At time T1=T0+deltaT+epsilon, I create object a/b/c with bits “fgsdfgsfgsdfgsfgfg” and expiration time T1+deltaT.<br class="">
<br class="">
If not, why not?<br class="">
</blockquote>
<br style="font-family: Menlo-Regular; font-size: 14px; font-style: normal; font-variant: 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: Menlo-Regular; font-size: 14px; font-style: normal; font-variant: 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="">Personal
view:</span><br style="font-family: Menlo-Regular; font-size: 14px; font-style: normal; font-variant: 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: Menlo-Regular; font-size: 14px; font-style: normal; font-variant: 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="">-
as far as application development is concerned: one should use different names for different data to the extend possible.</span><br style="font-family: Menlo-Regular; font-size: 14px; font-style: normal; font-variant: 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: Menlo-Regular; font-size: 14px; font-style: normal; font-variant: 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="">-
the last resort to distinguish different data is by name with digest.</span><br style="font-family: Menlo-Regular; font-size: 14px; font-style: normal; font-variant: 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: Menlo-Regular; font-size: 14px; font-style: normal; font-variant: 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: Menlo-Regular; font-size: 14px; font-style: normal; font-variant: 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="">Lixia</span><br style="font-family: Menlo-Regular; font-size: 14px; font-style: normal; font-variant: 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: Menlo-Regular; font-size: 14px; font-style: normal; font-variant: 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: Menlo-Regular; font-size: 14px; font-style: normal; font-variant: 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" 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="">
<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><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><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="">
<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="">
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>
</blockquote>
<br style="font-family: Menlo-Regular; font-size: 14px; font-style: normal; font-variant: 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: Menlo-Regular; font-size: 14px; font-style: normal; font-variant: 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: Menlo-Regular; font-size: 14px; font-style: normal; font-variant: 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="">_______________________________________________</span><br style="font-family: Menlo-Regular; font-size: 14px; font-style: normal; font-variant: 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: Menlo-Regular; font-size: 14px; font-style: normal; font-variant: 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="">Ndn-interest
mailing list</span><br style="font-family: Menlo-Regular; font-size: 14px; font-style: normal; font-variant: 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: Menlo-Regular; font-size: 14px; font-style: normal; font-variant: 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=""><a href="mailto:Ndn-interest@lists.cs.ucla.edu" class="">Ndn-interest@lists.cs.ucla.edu</a></span><br style="font-family: Menlo-Regular; font-size: 14px; font-style: normal; font-variant: 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: Menlo-Regular; font-size: 14px; font-style: normal; font-variant: 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=""><a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" class="">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a></span></div>
</blockquote>
</div>
<br class="">
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>