<div dir="ltr"><br><br><div class="gmail_quote">On Wed, Apr 1, 2015 at 10:57 AM Mark Stapp <<a href="mailto:mjs@cisco.com">mjs@cisco.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Apologies for being a little ignorant about the 'repo' process. How does<br>
the local forwarder know whether to send an interest to the repo process<br>
or to the application process that 'registered' a particular name<br>
prefix? or does the repo process intermediate - somehow - between every<br>
application and the host's forwarder, by default, like a proxy? does the<br>
repo do exact-match on the names it sees, or something ... else?<br></blockquote><div><br></div><div>Current implementation called 'repo-ng' is just a simple application and doesn't have any interaction with other applications except receiving commands and accepting data from them. The forwarder can decide where to send the interest based on forwarding strategies (broadcast, best route, etc.). The interest/data matching semantics is the same as what the content store in NFD does (i.e., longest prefix matching, child selector, exclude, ...)</div><div><br></div><div>Wentao</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks,<br>
Mark<br>
<br>
On 4/1/15 12:59 PM, Wentao Shang wrote:<br>
> I think this problem shows one limitation of in-memory cache (and repo<br>
> in general). The cache/repo is a "passive" storage: once the data gets<br>
> in, it never gets out unless someone explicitly request it. The<br>
> applications, on the other hand, can be more "active" in deciding when<br>
> to send out data in response to previous interests.<br>
><br>
> I remember Illya and Lijing's ndnvideo implementation also needs to<br>
> handle similar problem. Their current solution (as far as I understand)<br>
> is to push out the data twice: once to the NFD for satisfying request,<br>
> once to the repo for archiving. The second push uses repo insertion<br>
> command so it's not just a plain data packet (like in the first push).<br>
><br>
> Wentao<br>
><br>
> On Wed, Apr 1, 2015 at 8:38 AM Burke, Jeff <<a href="mailto:jburke@remap.ucla.edu" target="_blank">jburke@remap.ucla.edu</a><br>
> <mailto:<a href="mailto:jburke@remap.ucla.edu" target="_blank">jburke@remap.ucla.edu</a>><u></u>> wrote:<br>
><br>
><br>
>     Thanks for all of the discussion. I am not sure if I have been able<br>
>     to extract an answer to the original question I was asking.  Let me<br>
>     try again with more information:<br>
><br>
>     - The original question was intended to be only about a local NFD<br>
>     (for now).<br>
>     - The use case is a (soft) real-time application, like<br>
>     videoconferencing or streaming sensor data for interactive<br>
>     applications. Specifically, we have encountered the issue in 1)<br>
>     ndnrtc/ndncon <<a href="https://github.com/remap/ndncon/" target="_blank">https://github.com/remap/<u></u>ndncon/</a>> for<br>
>     videoconferencing and 2) ndn-opt, which streams data from OpenPTrack<br>
>     <<a href="http://openptrack.org/" target="_blank">http://openptrack.org/</a>>, a person tracking system built on the<br>
>     robot operating system (ROS).<br>
><br>
>     - In these use cases, consumers want to receive data with low<br>
>     latency, so they send interests intended to arrive before the time<br>
>     the data is produced, but not so long before that the Interests<br>
>     expire before corresponding data is produced.<br>
><br>
>     - As they are born, samples are signed and put into a repository by<br>
>     the publisher.  Currently these apps use an in-memory repo specific<br>
>     to the application, via the MemoryContentCache class provided by the<br>
>     NDN-CCL library. But this could just as well be a repo outside the<br>
>     application.<br>
><br>
>     - So, when Interests arrive, they go in the local  NFD's PIT, and<br>
>     are forwarded to the application.   We are interested in the case<br>
>     where the data is not born /yet/, so the publisher cannot respond to<br>
>     the Interest.<br>
><br>
>     - Then, before the Interest expires from the local NFD's PIT, the<br>
>     corresponding data is born in the application and /should/ be used<br>
>     to answer the Interest.  But how does that data get back to the<br>
>     local forwarder?<br>
><br>
>     - What should the application do?  1) Maintain its own PIT?   2) Or,<br>
>     push the data to the local NFD, letting it drop it if it doesn't<br>
>     satisfy anything.  3) Or, as we have previously discussed about the<br>
>     MemoryContentCache, do we need to consider a more sophisticated<br>
>     interaction model between the application and the daemon's content<br>
>     store and/or PIT that reduces duplication of these capabilities in<br>
>     applications?<br>
><br>
>     - For now, we have implemented an in-application PIT in ndnrtc.  (I<br>
>     am not sure what method we ended up using in ndn-opt, perhaps the<br>
>     unsolicited data method.)<br>
><br>
>     - Discussion on this topic will help inform what library support<br>
>     will be provided in the short term.  (I don't think we want every<br>
>     application author to have to write a PIT, so am thinking in the<br>
>     short term we should provide one to complement the<br>
>     MemoryContentCache class.  But this is duplicating data structures<br>
>     and functionality in NFD – is that natural, or should we look to<br>
>     handle it through a different interaction with the local forwarder?)<br>
><br>
>     Thanks,<br>
>     Jeff<br>
><br>
><br>
>     From: <<a href="mailto:Ignacio.Solis@parc.com" target="_blank">Ignacio.Solis@parc.com</a> <mailto:<a href="mailto:Ignacio.Solis@parc.com" target="_blank">Ignacio.Solis@parc.com</a><u></u>>><br>
>     Date: Tue, 31 Mar 2015 00:06:33 +0000<br>
>     To: <<a href="mailto:wentaoshang@gmail.com" target="_blank">wentaoshang@gmail.com</a> <mailto:<a href="mailto:wentaoshang@gmail.com" target="_blank">wentaoshang@gmail.com</a>><u></u>>,<br>
>     <<a href="mailto:Marc.Mosko@parc.com" target="_blank">Marc.Mosko@parc.com</a> <mailto:<a href="mailto:Marc.Mosko@parc.com" target="_blank">Marc.Mosko@parc.com</a>>><br>
><br>
>     Cc: <<a href="mailto:nfd-dev@lists.cs.ucla.edu" target="_blank">nfd-dev@lists.cs.ucla.edu</a> <mailto:<a href="mailto:nfd-dev@lists.cs.ucla.edu" target="_blank">nfd-dev@lists.cs.ucla.<u></u>edu</a>>><br>
>     Subject: Re: [Nfd-dev] Handling new content in app for pending<br>
>     interest in NFD<br>
><br>
>         I'm going to guess that caching data rules will be the same as<br>
>         forwarding rules. If the interface is not allowed to produce<br>
>         that content (due to routing / fib entries, local naming policy)<br>
>         data should not be forwarded OR cached.<br>
><br>
>         NDN has a slightly more complicated problem with caching than<br>
>         CCN given then LPM matching rules.<br>
><br>
>         If you have a repo that has permission to serve this content<br>
>         then you changed the problem. Now you need the repo protocol to<br>
>         give you trust.<br>
><br>
>         For regular forwarding you are relying on trusting routing. For<br>
>         local apps you will rely (I assume)  on local permissions. For<br>
>         repo you will need both of those plus now a repo permission<br>
>           protocol.<br>
><br>
>         Dropping unsolicited data may end up being your only recourse.<br>
><br>
>         There are obviously other approaches for pre-populating caches<br>
>         that involve higher level protocols, but I assume that's not<br>
>         what you're talking about.<br>
><br>
>         Nacho (Ignacio) Solis<br>
>         Principal Scientist<br>
>         Palo Alto Research Center<br>
><br>
>         *From:* Wentao Shang <<a href="mailto:wentaoshang@gmail.com" target="_blank">wentaoshang@gmail.com</a><br>
>         <mailto:<a href="mailto:wentaoshang@gmail.com" target="_blank">wentaoshang@gmail.com</a>><u></u>><br>
>         *Sent:* Mar 30, 2015 4:50 PM<br>
>         *To:* "Solis, Ignacio <<a href="mailto:Ignacio.Solis@parc.com" target="_blank">Ignacio.Solis@parc.com</a><br>
>         <mailto:<a href="mailto:Ignacio.Solis@parc.com" target="_blank">Ignacio.Solis@parc.com</a><u></u>>>" <<a href="mailto:Ignacio.Solis@parc.com" target="_blank">Ignacio.Solis@parc.com</a><br>
>         <mailto:<a href="mailto:Ignacio.Solis@parc.com" target="_blank">Ignacio.Solis@parc.com</a><u></u>>>;Mosko, Marc<br>
>         <<a href="mailto:Marc.Mosko@parc.com" target="_blank">Marc.Mosko@parc.com</a> <mailto:<a href="mailto:Marc.Mosko@parc.com" target="_blank">Marc.Mosko@parc.com</a>>><br>
>         *Cc:* <a href="mailto:nfd-dev@lists.cs.ucla.edu" target="_blank">nfd-dev@lists.cs.ucla.edu</a> <mailto:<a href="mailto:nfd-dev@lists.cs.ucla.edu" target="_blank">nfd-dev@lists.cs.ucla.<u></u>edu</a>><br>
>         *Subject:* Re: [Nfd-dev] Handling new content in app for pending<br>
>         interest in NFD<br>
><br>
>         Hi Nacho,<br>
><br>
>         I don't have any argument against this rule right now. But it<br>
>         seems more relevant to "forwarding" data packets, while the<br>
>         problem we were discussing is about "caching" unsolicited data<br>
>         packets, which cannot be forwarded anyway because there is no<br>
>         PIT. The simplest solution I would suggest to the problem is to<br>
>         drop any unsolicited data in the forwarder.<br>
><br>
>         Wentao<br>
><br>
>         On Mon, Mar 30, 2015 at 3:42 PM <<a href="mailto:Ignacio.Solis@parc.com" target="_blank">Ignacio.Solis@parc.com</a><br>
>         <mailto:<a href="mailto:Ignacio.Solis@parc.com" target="_blank">Ignacio.Solis@parc.com</a><u></u>>> wrote:<br>
><br>
>             This rule is important, router or not. You can't have<br>
>             "non-priviledged"  applications generating replies at<br>
>             servers. Specially important at systems with multiple users,<br>
>               tenants, virtual systems.<br>
><br>
>             At the local router there are even more restrictions.  We<br>
>             haven't even gotten to talking about privileged names and<br>
>             restrictions and end-h out behavior.   We have a design  for<br>
>             this for CCN that we'll be talking about at CCNxCon.<br>
><br>
>             Nacho (Ignacio) Solis<br>
>             Principal Scientist<br>
>             Palo Alto Research Center<br>
><br>
>             *From:* Wentao Shang <<a href="mailto:wentaoshang@gmail.com" target="_blank">wentaoshang@gmail.com</a><br>
>             <mailto:<a href="mailto:wentaoshang@gmail.com" target="_blank">wentaoshang@gmail.com</a>><u></u>><br>
>             *Sent:* Mar 30, 2015 1:07 PM<br>
>             *To:* Mosko, Marc <<a href="mailto:Marc.Mosko@parc.com" target="_blank">Marc.Mosko@parc.com</a><br>
>             <mailto:<a href="mailto:Marc.Mosko@parc.com" target="_blank">Marc.Mosko@parc.com</a>>><br>
><br>
>             *Cc:* <a href="mailto:nfd-dev@lists.cs.ucla.edu" target="_blank">nfd-dev@lists.cs.ucla.edu</a><br>
>             <mailto:<a href="mailto:nfd-dev@lists.cs.ucla.edu" target="_blank">nfd-dev@lists.cs.ucla.<u></u>edu</a>><br>
>             *Subject:* Re: [Nfd-dev] Handling new content in app for<br>
>             pending interest in NFD<br>
><br>
>             On Mon, Mar 30, 2015 at 12:52 PM <<a href="mailto:Marc.Mosko@parc.com" target="_blank">Marc.Mosko@parc.com</a><br>
>             <mailto:<a href="mailto:Marc.Mosko@parc.com" target="_blank">Marc.Mosko@parc.com</a>>> wrote:<br>
><br>
>                 I’ll add that in addition to the content having a PIT<br>
>                 entry, Nacho Solis has suggested that a router should<br>
>                 verify that a Content Object came in a face from which<br>
>                 it was requested.  Otherwise, there’s a potential for<br>
>                 off-path attacks sending content objects that match<br>
>                 popular well-known names.  A variation on that, rather<br>
>                 than tracking forward paths, would be to at minimum<br>
>                 verify that a content object comes from a face for which<br>
>                 there’s a corresponding FIB entry for the name.<br>
><br>
><br>
>             This requirement makes sense for transit routers that<br>
>             receive packets from other routers. But I'm not sure whether<br>
>             this is necessary for forwarding daemons handling local<br>
>             applications... The pushed data should never get out of the<br>
>             local forwarder unless there is a PIT entry specifying a<br>
>             path pointing to some other router.<br>
><br>
>             Wentao<br>
><br>
><br>
>                 Marc<br>
><br>
>                 On Mar 30, 2015, at 12:08 PM, Wentao Shang<br>
>                 <<a href="mailto:wentaoshang@gmail.com" target="_blank">wentaoshang@gmail.com</a> <mailto:<a href="mailto:wentaoshang@gmail.com" target="_blank">wentaoshang@gmail.com</a>><u></u>><br>
>                 wrote:<br>
><br>
>>                 I agree with Dave.<br>
>><br>
>>                 In principle, router should not cache unsolicited<br>
>>                 data. In the situation we are discussing, the<br>
>>                 application should either just push the data out,<br>
>>                 which may be dropped by NFD if the interest has<br>
>>                 expired, or store the data in some application-level<br>
>>                 cache (or repo) for future fetching.<br>
>><br>
>>                 Wentao<br>
>><br>
>>                 On Mon, Mar 30, 2015 at 11:52 AM Dave Oran (oran)<br>
>>                 <<a href="mailto:oran@cisco.com" target="_blank">oran@cisco.com</a> <mailto:<a href="mailto:oran@cisco.com" target="_blank">oran@cisco.com</a>>> wrote:<br>
>><br>
>>                     Isn’t this what the repo was invented for?<br>
>><br>
>>                     Holding packets in a router that has forgotten<br>
>>                     that they were asked for is a giant invitation to<br>
>>                     cache pollution/poisoning attacks.<br>
>><br>
>>                     > On Mar 30, 2015, at 2:24 PM, Haowei Yuan <<a href="mailto:hyuan@wustl.edu" target="_blank">hyuan@wustl.edu</a> <mailto:<a href="mailto:hyuan@wustl.edu" target="_blank">hyuan@wustl.edu</a>>> wrote:<br>
>>                     ><br>
>>                     > I think as long as the data has actually been requested by an Interest<br>
>>                     > packet, it is safe to send the Data packet to NFD. The NFD will either<br>
>>                     > forward or drop the Data packet by checking if the Interest has<br>
>>                     > expired.<br>
>>                     ><br>
>>                     > If the Interest has expired, Data packet is dropped, and the consumer<br>
>>                     > is still interested in the data, the consumer could resend the<br>
>>                     > Interest. Hopefully this time, the Data packet can be generated and<br>
>>                     > sent faster by the application so that NFD will forward it.<br>
>>                     ><br>
>>                     > Haowei<br>
>>                     ><br>
>>                     ><br>
>>                     > On Mon, Mar 30, 2015 at 1:12 PM, Anil Jangam <<a href="mailto:anilj.mailing@gmail.com" target="_blank">anilj.mailing@gmail.com</a><br>
>>                     <mailto:<a href="mailto:anilj.mailing@gmail.com" target="_blank">anilj.mailing@gmail.<u></u>com</a>>> wrote:<br>
>>                     >><br>
>>                     >> On Mar 30, 2015 11:08 AM, "Dehart, John" <<a href="mailto:jdd@wustl.edu" target="_blank">jdd@wustl.edu</a> <mailto:<a href="mailto:jdd@wustl.edu" target="_blank">jdd@wustl.edu</a>>> wrote:<br>
>>                     >>><br>
>>                     >>><br>
>>                     >>> Is there any harm in it pushing the data out without knowing for sure if<br>
>>                     >>> the<br>
>>                     >>> Interest is still active?<br>
>>                     >>><br>
>>                     >> If data is so critical, can the Interest be refreshed proactively before it<br>
>>                     >> expires?<br>
>>                     >><br>
>>                     >> /anil<br>
>>                     >><br>
>>                     >>> John<br>
>>                     >>><br>
>>                     >>>> On Mar 30, 2015, at 1:05 PM, Burke, Jeff <<a href="mailto:jburke@remap.ucla.edu" target="_blank">jburke@remap.ucla.edu</a><br>
>>                     <mailto:<a href="mailto:jburke@remap.ucla.edu" target="_blank">jburke@remap.ucla.edu</a>><u></u>> wrote:<br>
>>                     >>>><br>
>>                     >>>><br>
>>                     >>>><br>
>>                     >>>>><br>
>>                     >>>>><br>
>>                     >>>>> On Mon, Mar 30, 2015 at 10:28 AM Burke, Jeff <<a href="mailto:jburke@remap.ucla.edu" target="_blank">jburke@remap.ucla.edu</a> <mailto:<a href="mailto:jburke@remap.ucla.edu" target="_blank">jburke@remap.ucla.edu</a>><u></u>><br>
>>                     >>>>> wrote:<br>
>>                     >>>>>><br>
>>                     >>>>>><br>
>>                     >>>>>> Hi folks,<br>
>>                     >>>>>><br>
>>                     >>>>>> We are facing this scenario in a few applications:<br>
>>                     >>>>>><br>
>>                     >>>>>> 1) Interest received by NFD, passed to an application<br>
>>                     >>>>>> 2) Application not able to respond to interest, so interest stays in<br>
>>                     >>>>>> NFD PIT<br>
>>                     >>>>>> 3) Some time passes, but not enough for the Interest to expire<br>
>>                     >>>>>> 4) Application generates data (e.g., from a sensor reading) that would<br>
>>                     >>>>>> answer the Interest in the NFD PIT<br>
>>                     >>>>>><br>
>>                     >>>>>> Question: How does app know to inform NFD it has the data after step 4,<br>
>>                     >>>>>> and how should it do that?<br>
>>                     >>>>>><br>
>>                     >>>>>> - In this type of app, should it push the data unsolicited to the NFD<br>
>>                     >>>>>> and let it decide if there is something to do?<br>
>>                     >>>>><br>
>>                     >>>>><br>
>>                     >>>>> In my opinion, as long as the application is certain that the Interest<br>
>>                     >>>>> has arrived and is stored in NFD's PIT, it can just push the data out to<br>
>>                     >>>>> NFD.<br>
>>                     >>>><br>
>>                     >>>><br>
>>                     >>>><br>
>>                     >>>> How certain does it have to be?  There is a chance it could have<br>
>>                     >>>> expired...<br>
>>                     >>>> jeff<br>
>>                     >>>><br>
>>                     >>>><br>
>>                     >>>><br>
>>                     >>>><br>
>>                     >>>><br>
>>                     >>>>><br>
>>                     >>>>> Wentao<br>
>>                     >>>>><br>
>>                     >>>>>><br>
>>                     >>>>>> - Is it recommended to implement an application-level PIT so the app is<br>
>>                     >>>>>> sure this data is solicited?  (Why add another PIT?)<br>
>>                     >>>>>><br>
>>                     >>>>>> Thank you,<br>
>>                     >>>>>> Jeff<br>
>>                     >>>>>><br>
>>                     >>>>>> ______________________________<u></u>___________________<br>
>>                     >>>>>> Nfd-dev mailing list<br>
>>                     >>>>>><a href="mailto:Nfd-dev@lists.cs.ucla.edu" target="_blank">Nfd-dev@lists.cs.ucla.<u></u>edu</a><br>
>>                     <mailto:<a href="mailto:Nfd-dev@lists.cs.ucla.edu" target="_blank">Nfd-dev@lists.cs.ucla.<u></u>edu</a>><br>
>>                     >>>>>><a href="http://www.lists.cs.ucla.edu/__mailman/listinfo/nfd-dev" target="_blank">http://www.lists.cs.<u></u>ucla.edu/__mailman/listinfo/<u></u>nfd-dev</a><br>
>>                     <<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev" target="_blank">http://www.lists.cs.ucla.edu/<u></u>mailman/listinfo/nfd-dev</a>><br>
>>                     >>>><br>
>>                     >>>> ______________________________<u></u>___________________<br>
>>                     >>>> Nfd-dev mailing list<br>
>>                     >>>><a href="mailto:Nfd-dev@lists.cs.ucla.edu" target="_blank">Nfd-dev@lists.cs.ucla.edu</a><br>
>>                     <mailto:<a href="mailto:Nfd-dev@lists.cs.ucla.edu" target="_blank">Nfd-dev@lists.cs.ucla.<u></u>edu</a>><br>
>>                     >>>><a href="http://www.lists.cs.ucla.edu/__mailman/listinfo/nfd-dev" target="_blank">http://www.lists.cs.ucla.<u></u>edu/__mailman/listinfo/nfd-dev</a><br>
>>                     <<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev" target="_blank">http://www.lists.cs.ucla.edu/<u></u>mailman/listinfo/nfd-dev</a>><br>
>>                     >>><br>
>>                     >>><br>
>>                     >>><br>
>>                     >>> ______________________________<u></u>___________________<br>
>>                     >>> Nfd-dev mailing list<br>
>>                     >>><a href="mailto:Nfd-dev@lists.cs.ucla.edu" target="_blank">Nfd-dev@lists.cs.ucla.edu</a><br>
>>                     <mailto:<a href="mailto:Nfd-dev@lists.cs.ucla.edu" target="_blank">Nfd-dev@lists.cs.ucla.<u></u>edu</a>><br>
>>                     >>><a href="http://www.lists.cs.ucla.edu/__mailman/listinfo/nfd-dev" target="_blank">http://www.lists.cs.ucla.<u></u>edu/__mailman/listinfo/nfd-dev</a><br>
>>                     <<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev" target="_blank">http://www.lists.cs.ucla.edu/<u></u>mailman/listinfo/nfd-dev</a>><br>
>>                     >>><br>
>>                     > ______________________________<u></u>___________________<br>
>>                     > Nfd-dev mailing list<br>
>>                     ><a href="mailto:Nfd-dev@lists.cs.ucla.edu" target="_blank">Nfd-dev@lists.cs.ucla.edu</a><br>
>>                     <mailto:<a href="mailto:Nfd-dev@lists.cs.ucla.edu" target="_blank">Nfd-dev@lists.cs.ucla.<u></u>edu</a>><br>
>>                     ><a href="http://www.lists.cs.ucla.edu/__mailman/listinfo/nfd-dev" target="_blank">http://www.lists.cs.ucla.edu/<u></u>__mailman/listinfo/nfd-dev</a><br>
>>                     <<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev" target="_blank">http://www.lists.cs.ucla.edu/<u></u>mailman/listinfo/nfd-dev</a>><br>
>><br>
>><br>
>>                     ______________________________<u></u>___________________<br>
>>                     Nfd-dev mailing list<br>
>>                     <a href="mailto:Nfd-dev@lists.cs.ucla.edu" target="_blank">Nfd-dev@lists.cs.ucla.edu</a><br>
>>                     <mailto:<a href="mailto:Nfd-dev@lists.cs.ucla.edu" target="_blank">Nfd-dev@lists.cs.ucla.<u></u>edu</a>><br>
>>                     <a href="http://www.lists.cs.ucla.edu/__mailman/listinfo/nfd-dev" target="_blank">http://www.lists.cs.ucla.edu/_<u></u>_mailman/listinfo/nfd-dev</a><br>
>>                     <<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev" target="_blank">http://www.lists.cs.ucla.edu/<u></u>mailman/listinfo/nfd-dev</a>><br>
>><br>
>>                 ______________________________<u></u>_________________<br>
>>                 Nfd-dev mailing list<br>
>>                 <a href="mailto:Nfd-dev@lists.cs.ucla.edu" target="_blank">Nfd-dev@lists.cs.ucla.edu</a><br>
>>                 <mailto:<a href="mailto:Nfd-dev@lists.cs.ucla.edu" target="_blank">Nfd-dev@lists.cs.ucla.<u></u>edu</a>><br>
>>                 <a href="http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev" target="_blank">http://www.lists.cs.ucla.edu/<u></u>mailman/listinfo/nfd-dev</a><br>
><br>
>         ______________________________<u></u>_________________ Nfd-dev mailing<br>
>         list <a href="mailto:Nfd-dev@lists.cs.ucla.edu" target="_blank">Nfd-dev@lists.cs.ucla.edu</a><br>
>         <mailto:<a href="mailto:Nfd-dev@lists.cs.ucla.edu" target="_blank">Nfd-dev@lists.cs.ucla.<u></u>edu</a>><br>
>         <a href="http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev" target="_blank">http://www.lists.cs.ucla.edu/<u></u>mailman/listinfo/nfd-dev</a><br>
><br>
>     ______________________________<u></u>___________________<br>
>     Nfd-dev mailing list<br>
>     <a href="mailto:Nfd-dev@lists.cs.ucla.edu" target="_blank">Nfd-dev@lists.cs.ucla.edu</a> <mailto:<a href="mailto:Nfd-dev@lists.cs.ucla.edu" target="_blank">Nfd-dev@lists.cs.ucla.<u></u>edu</a>><br>
>     <a href="http://www.lists.cs.ucla.edu/__mailman/listinfo/nfd-dev" target="_blank">http://www.lists.cs.ucla.edu/_<u></u>_mailman/listinfo/nfd-dev</a><br>
>     <<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev" target="_blank">http://www.lists.cs.ucla.edu/<u></u>mailman/listinfo/nfd-dev</a>><br>
><br>
><br>
><br>
> ______________________________<u></u>_________________<br>
> Nfd-dev mailing list<br>
> <a href="mailto:Nfd-dev@lists.cs.ucla.edu" target="_blank">Nfd-dev@lists.cs.ucla.edu</a><br>
> <a href="http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev" target="_blank">http://www.lists.cs.ucla.edu/<u></u>mailman/listinfo/nfd-dev</a><br>
><br>
</blockquote></div></div>