From shijunxiao at email.arizona.edu Sun Nov 2 06:29:07 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Sun, 2 Nov 2014 07:29:07 -0700 Subject: [Nfd-dev] Install dependency packages in Jenkins script Message-ID: Dear folks There are a few instances that build fails on Jenkins due to missing dependency on slaves. All projects that depend on ndn-cxx contains a script in their repository that installs ndn-cxx. Shall we do the same for system package dependencies? Specifically, a build step of Jenkins script can determine current OS version, and execute either apt-get or MacPorts to install the necessary packages. This would simplify the process of installing new Jenkins slaves. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Sun Nov 2 09:20:02 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Sun, 2 Nov 2014 10:20:02 -0700 Subject: [Nfd-dev] C++11 code style Message-ID: Dear folks We need to define some new code style rules for C++11 syntax. I'd start with three new rules: rule x. Range-based for should be in the following form: for (auto i : range) { statements; } rule x. Lambda expression should be in the following form: [&capture1, capture2] (Type1 arg1, Type2 arg2) { statements; } If the function body has only one line, and the whole expression can fit in one line, the following form is also acceptable: [&capture1, capture2] (Type1 arg1, Type2 arg2) { statement; } rule x. `auto` type should only be used for local variables. What other rules do we need? Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.afanasyev at UCLA.EDU Sun Nov 2 12:03:57 2014 From: alexander.afanasyev at UCLA.EDU (Alex Afanasyev) Date: Sun, 2 Nov 2014 12:03:57 -0800 Subject: [Nfd-dev] C++11 code style In-Reply-To: References: Message-ID: > On Nov 2, 2014, at 9:20 AM, Junxiao Shi wrote: > > Dear folks > > We need to define some new code style rules for C++11 syntax. > > I'd start with three new rules: > > rule x. Range-based for should be in the following form: > > for (auto i : range) { > statements; > } > > > rule x. Lambda expression should be in the following form: > > [&capture1, capture2] (Type1 arg1, Type2 arg2) > { > statements; > } I prefer different style, which more aligns with the existing code (and is more gnu style): [&capture1, capture2] (Type1 arg1, Type2 arg2) { statements; } > > If the function body has only one line, and the whole expression can fit in one line, the following form is also acceptable: > > [&capture1, capture2] (Type1 arg1, Type2 arg2) { statement; } that?s fine too > > rule x. `auto` type should only be used for local variables. Where else, potentially, it can be used? > > What other rules do we need? > > Yours, Junxiao > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.afanasyev at ucla.edu Sun Nov 2 12:15:22 2014 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Sun, 2 Nov 2014 12:15:22 -0800 Subject: [Nfd-dev] Install dependency packages in Jenkins script In-Reply-To: References: Message-ID: > On Nov 2, 2014, at 6:29 AM, Junxiao Shi wrote: > > Dear folks > > There are a few instances that build fails on Jenkins due to missing dependency on slaves. > All projects that depend on ndn-cxx contains a script in their repository that installs ndn-cxx. > Shall we do the same for system package dependencies? > > Specifically, a build step of Jenkins script can determine current OS version, and execute either apt-get or MacPorts to install the necessary packages. > This would simplify the process of installing new Jenkins slaves > Just in case. OS X buildbots do not use macports (it was easier and more uniform to set up using brew). We had something like this for several projects (NLSR). The only issue with that I see is OSX 10.8, which requires special way of installing dependencies (which may fail if the process is completely offloaded to project-specific scripts). For all other systems, this can definitely be done. ? Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Sun Nov 2 12:41:51 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Sun, 2 Nov 2014 13:41:51 -0700 Subject: [Nfd-dev] C++11 code style In-Reply-To: References:

Message-ID: Dear folks The choice between [&capture1, capture2] (Type1 arg1, Type2 arg2) { statements; } and [&capture1, capture2] (Type1 arg1, Type2 arg2) { statements; } depends on whether a lambda expression is more like a function, or a block statement (similar to if/for/while). A lambda expression is an inline function and rule 1.5 mandates the first style for functions. Another possible understanding is: put "{" on the next line for everything down to named function level, and put "{" on the same line for everything inside a named function. This makes the second style preferred. What do others on nfd-dev think? `auto` specifier can be used to declare variables at any scope: block scope, namespace scope, init statement of for loop. The proposed rule is to forbid using `auto` specifier at namespace scope, because such usage makes the code less readable. Yours, Junxiao On Sun, Nov 2, 2014 at 1:03 PM, Alex Afanasyev wrote: > > On Nov 2, 2014, at 9:20 AM, Junxiao Shi > wrote: > > Dear folks > > We need to define some new code style rules for C++11 syntax. > > I'd start with three new rules: > > rule x. Range-based for should be in the following form: > > for (auto i : range) { > statements; > } > > > > rule x. Lambda expression should be in the following form: > > [&capture1, capture2] (Type1 arg1, Type2 arg2) > { > > statements; > > } > > > I prefer different style, which more aligns with the existing code (and is > more gnu style): > > [&capture1, capture2] (Type1 arg1, Type2 arg2) { > statements; > } > > > If the function body has only one line, and the whole expression can fit > in one line, the following form is also acceptable: > > [&capture1, capture2] (Type1 arg1, Type2 arg2) { statement; } > > > that?s fine too > > > rule x. `auto` type should only be used for local variables. > > > Where else, potentially, it can be used? > > > What other rules do we need? > > Yours, Junxiao > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.afanasyev at ucla.edu Sun Nov 2 12:57:25 2014 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Sun, 2 Nov 2014 12:57:25 -0800 Subject: [Nfd-dev] C++11 code style In-Reply-To: References:

Message-ID: <4907E5C1-00C7-4553-9C64-D5AC5E043A56@ucla.edu> > On Nov 2, 2014, at 12:41 PM, Junxiao Shi wrote: > > Dear folks > > The choice between > [&capture1, capture2] (Type1 arg1, Type2 arg2) > { > statements; > } > and > [&capture1, capture2] (Type1 arg1, Type2 arg2) { > statements; > } > depends on whether a lambda expression is more like a function, or a block statement (similar to if/for/while). > A lambda expression is an inline function and rule 1.5 mandates the first style for functions. > Another possible understanding is: put "{" on the next line for everything down to named function level, and put "{" on the same line for everything inside a named function. This makes the second style preferred. > What do others on nfd-dev think? Even though lambda function is logically a function, it is used as a block statement. Therefore, the rule (if any) should be closer to a block statement rule, then to function. > `auto` specifier can be used to declare variables at any scope: block scope, namespace scope, init statement of for loop. > The proposed rule is to forbid using `auto` specifier at namespace scope, because such usage makes the code less readable. I would avoid making such an explicit rule. I would rather take case by case approach, where namespace-scope auto should be generally avoided, but if it makes sense to use it, it can be used. ? Alex > Yours, Junxiao > > On Sun, Nov 2, 2014 at 1:03 PM, Alex Afanasyev > wrote: > >> On Nov 2, 2014, at 9:20 AM, Junxiao Shi > wrote: >> >> Dear folks >> >> We need to define some new code style rules for C++11 syntax. >> >> I'd start with three new rules: >> >> rule x. Range-based for should be in the following form: >> >> for (auto i : range) { >> statements; >> } >> >> >> rule x. Lambda expression should be in the following form: >> >> [&capture1, capture2] (Type1 arg1, Type2 arg2) >> { >> statements; >> } > > I prefer different style, which more aligns with the existing code (and is more gnu style): > > [&capture1, capture2] (Type1 arg1, Type2 arg2) { > statements; > } > >> >> If the function body has only one line, and the whole expression can fit in one line, the following form is also acceptable: >> >> [&capture1, capture2] (Type1 arg1, Type2 arg2) { statement; } > > that?s fine too > >> >> rule x. `auto` type should only be used for local variables. > > Where else, potentially, it can be used? > >> >> What other rules do we need? >> >> Yours, Junxiao >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Sun Nov 2 13:02:37 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Sun, 2 Nov 2014 14:02:37 -0700 Subject: [Nfd-dev] C++11 code style In-Reply-To: <4907E5C1-00C7-4553-9C64-D5AC5E043A56@ucla.edu> References:

<4907E5C1-00C7-4553-9C64-D5AC5E043A56@ucla.edu> Message-ID: Hi Alex This rule (and many other rules) uses the keyword "should". "should" is to be interpreted according to RFC2119, which means an exception can be granted when properly justified. What about: rule x. `auto` type specifier SHOULD only be used for local variables. Yours, Junxiao On Sun, Nov 2, 2014 at 1:57 PM, Alex Afanasyev wrote: > > rule x. `auto` type should only be used for local variables. > > >> Where else, potentially, it can be used? >> >> `auto` specifier can be used to declare variables at any scope: block > scope, namespace scope, init statement of for loop. > The proposed rule is to forbid using `auto` specifier at namespace scope, > because such usage makes the code less readable. > > > I would avoid making such an explicit rule. I would rather take case by > case approach, where namespace-scope auto should be generally avoided, but > if it makes sense to use it, it can be used. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.afanasyev at ucla.edu Sun Nov 2 13:16:17 2014 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Sun, 2 Nov 2014 13:16:17 -0800 Subject: [Nfd-dev] C++11 code style In-Reply-To: References:

<4907E5C1-00C7-4553-9C64-D5AC5E043A56@ucla.edu> Message-ID: <2F98FEF3-DFD1-4C50-AB55-2EFABE8F047F@ucla.edu> > On Nov 2, 2014, at 1:02 PM, Junxiao Shi wrote: > > Hi Alex > > This rule (and many other rules) uses the keyword "should". > "should" is to be interpreted according to RFC2119, which means an exception can be granted when properly justified. > > What about: > rule x. `auto` type specifier SHOULD only be used for local variables. That?s ok. > > Yours, Junxiao > > On Sun, Nov 2, 2014 at 1:57 PM, Alex Afanasyev > wrote: >> rule x. `auto` type should only be used for local variables. >> >> Where else, potentially, it can be used? >> >> `auto` specifier can be used to declare variables at any scope: block scope, namespace scope, init statement of for loop. >> The proposed rule is to forbid using `auto` specifier at namespace scope, because such usage makes the code less readable. > > I would avoid making such an explicit rule. I would rather take case by case approach, where namespace-scope auto should be generally avoided, but if it makes sense to use it, it can be used. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davide.pesavento at lip6.fr Sun Nov 2 16:14:11 2014 From: davide.pesavento at lip6.fr (Davide Pesavento) Date: Mon, 3 Nov 2014 01:14:11 +0100 Subject: [Nfd-dev] C++11 code style In-Reply-To: <4907E5C1-00C7-4553-9C64-D5AC5E043A56@ucla.edu> References:

<4907E5C1-00C7-4553-9C64-D5AC5E043A56@ucla.edu> Message-ID: On Sun, Nov 2, 2014 at 9:57 PM, Alex Afanasyev wrote: > > On Nov 2, 2014, at 12:41 PM, Junxiao Shi > wrote: > > Dear folks > > The choice between > > [&capture1, capture2] (Type1 arg1, Type2 arg2) > { > statements; > } > > and > > [&capture1, capture2] (Type1 arg1, Type2 arg2) { > statements; > } > > depends on whether a lambda expression is more like a function, or a block > statement (similar to if/for/while). > A lambda expression is an inline function and rule 1.5 mandates the first > style for functions. > Another possible understanding is: put "{" on the next line for everything > down to named function level, and put "{" on the same line for everything > inside a named function. This makes the second style preferred. > What do others on nfd-dev think? > > > Even though lambda function is logically a function, it is used as a block > statement. Therefore, the rule (if any) should be closer to a block > statement rule, then to function. > It's really a minor matter, but I agree with Alex wrt braces positioning. The rationale is that most of the time lambdas are directly passed as arguments to function calls, e.g. myfunc(foo, [&bar] (int baz) { bar += baz; }); and the above style looks more natural to me. Thanks, Davide From davide.pesavento at lip6.fr Sun Nov 2 17:29:44 2014 From: davide.pesavento at lip6.fr (Davide Pesavento) Date: Mon, 3 Nov 2014 02:29:44 +0100 Subject: [Nfd-dev] C++11 code style In-Reply-To: References: Message-ID: On Sun, Nov 2, 2014 at 6:20 PM, Junxiao Shi wrote: > Dear folks > > We need to define some new code style rules for C++11 syntax. > [...] > > What other rules do we need? > * Initializer lists and uniform initializations [1]. Where can we use them and how? Spaces around braces? * New function declaration syntax with trailing return type. Can we use it? (I'd say yes but only if really necessary) * Static assertions [2]. Are they preferred to BOOST_STATIC_ASSERT? * Right angle brackets. `list >` or `list>`? (the latter syntax was not allowed in C++98) * Strongly-typed (aka scoped) enumerations [3]. Can we use them? Are they preferred to old-style enums? `enum struct` or `enum class`? * Should we prefer new classes and functions of the standard library (std::) when they're also available in boost? [1] http://en.cppreference.com/w/cpp/language/list_initialization [2] http://en.cppreference.com/w/cpp/language/static_assert [3] http://en.cppreference.com/w/cpp/language/enum Best, Davide From shijunxiao at email.arizona.edu Sun Nov 2 18:29:47 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Sun, 2 Nov 2014 19:29:47 -0700 Subject: [Nfd-dev] C++11 code style In-Reply-To: References: Message-ID: Dear folks List initialization: I suggest the following rule: rule x. List initialization should have the following form: T object { arg1, arg2 }; T { arg1, arg2 }; new T { arg1, arg2 }; return { arg1, arg2 }; function({ arg1, arg2 }, otherArgument); object[{ arg1, arg2 }]; T({ arg1, arg2 }) class Class { private: T m_member = { arg1, arg2 }; }; Class::Class() : m_member { arg1, arg2 } { } T object = { arg1, arg2 }; Static assertion: I suggest the following rule: rule x. BOOST_ASSERT and BOOST_ASSERT_MSG are preferred over assert. BOOST_STATIC_ASSERT and BOOST_STATIC_ASSERT_MSG are preferred over static_assert. The reason is that BOOST_* macros are more eye-catching with upper case. Right angle brackets: std::list> should be preferred. This doesn't need a new rule because it's not forbidden by any rule. Strongly-typed enumerations: Yes we can use them. This doesn't need a new rule because it's not forbidden by any rule. STL classes and functions vs Boost classes and functions: This isn't a code style problem. Generally STL is preferred. Yours, Junxiao On Sun, Nov 2, 2014 at 6:29 PM, Davide Pesavento wrote: > > * Initializer lists and uniform initializations [1]. Where can we use > them and how? Spaces around braces? > > * New function declaration syntax with trailing return type. Can we use it? > (I'd say yes but only if really necessary) > > * Static assertions [2]. Are they preferred to BOOST_STATIC_ASSERT? > > * Right angle brackets. `list >` or `list>`? (the > latter syntax was not allowed in C++98) > > * Strongly-typed (aka scoped) enumerations [3]. Can we use them? Are > they preferred to old-style enums? `enum struct` or `enum class`? > > * Should we prefer new classes and functions of the standard library > (std::) when they're also available in boost? > > [1] http://en.cppreference.com/w/cpp/language/list_initialization > [2] http://en.cppreference.com/w/cpp/language/static_assert > [3] http://en.cppreference.com/w/cpp/language/enum > > Best, > Davide > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Sun Nov 2 20:44:14 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Sun, 2 Nov 2014 21:44:14 -0700 Subject: [Nfd-dev] ndn-cxx deprecated feature removal: Face::Face(shared_ptr) and Face::ioService() Message-ID: Dear folks The following deprecated function will be removed from ndn-cxx soon: - Face::Face(shared_ptr) - shared_ptr Face::ioService() These functions deprecated before ndn-cxx v0.2.0 release. If you have code that depend on this feature, please reply no later than Nov 08 12:00 UTC. Otherwise, we'll proceed with the removal. You can try compile your projects with ndn-cxx Change http://gerrit.named-data.net/1374 and verify it works. I've verified that the following projects are unaffected: ndn-tlv-ping, ndn-traffic-generator, NFD. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Mon Nov 3 19:14:29 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Mon, 3 Nov 2014 20:14:29 -0700 Subject: [Nfd-dev] Fwd: remote registration In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: Tai-Lin Chu Date: Mon, Nov 3, 2014 at 12:31 PM Subject: remote registration To: Junxiao Shi hi, Just some ideas to confirm: for remote registration, nfd can be either "remote nfd (dedicated)" or "local nfd (laptop)". For "remote nfd", routing like NLSR is enabled (LSA and route calculation) For local nfd (laptop), routing is disabled (local nfd works like intermediate "proxy"; any prefix applications register, it will also register to remote nfd.) Did I miss any hard problem? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Tue Nov 4 08:31:01 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Tue, 4 Nov 2014 09:31:01 -0700 Subject: [Nfd-dev] ndn-cxx deprecated feature removal: tlv::ConentType Message-ID: Dear folks The following deprecated feature will be removed from ndn-cxx soon: - tlv::ConentType, please change to tlv::ContentTypeValue If you have code that depend on this feature and cannot be fixed now, please reply no later than Nov 09 12:00 UTC. Otherwise, we'll proceed with the removal after that time. You can compile your projects with ndn-cxx Change http://gerrit.named-data.net/1386 and verify it works. I've verified that the following projects are unaffected: ndn-tlv-ping, ndn-traffic-generator, NFD. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Tue Nov 4 09:03:12 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Tue, 4 Nov 2014 10:03:12 -0700 Subject: [Nfd-dev] Install dependency packages in Jenkins script In-Reply-To: References:

Message-ID: Hi Alex If buildbots use Brew instead of MacPorts, we should recommend customers/users use Brew as well. Please explain what's the "special way" in OSX 10.8, and why it cannot be offloaded to project-specific scripts. Yours, Junxiao On Sun, Nov 2, 2014 at 1:15 PM, Alex Afanasyev wrote: > Just in case. OS X buildbots do not use macports (it was easier and more > uniform to set up using brew). > > We had something like this for several projects (NLSR). The only issue > with that I see is OSX 10.8, which requires special way of installing > dependencies (which may fail if the process is completely offloaded to > project-specific scripts). For all other systems, this can definitely be > done. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nnaren1902 at gmail.com Wed Nov 5 22:54:25 2014 From: nnaren1902 at gmail.com (NAREN N) Date: Wed, 5 Nov 2014 22:54:25 -0800 Subject: [Nfd-dev] NFN Developers Documentation Message-ID: Hello, In section 3.3.1 of the newly published NFD Developers Guide, it is said and I quote >"An in-record expires when InterestLifetime has elapsed after the last Interest packet arrives." This is applicable only as of today because each interest packet has the same Life time. Suppose say a previously arrived packet from a face(Not the last arriving packet) has a bigger InterestLifetime, it would be wrong to delete the Face entry when the last packets InterestLifetime expires right? I hope it is clear to everyone. regards, Naren -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Thu Nov 6 02:36:37 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Thu, 6 Nov 2014 03:36:37 -0700 Subject: [Nfd-dev] in-record deletion Message-ID: Hi Naren It is correct to delete the in-record according to the LAST incoming Interest from a face. The downstream is supposed to send us an Interest with InterestLifetime set to the longest lifetime its downstreams want the content. Yours, Junxiao On Nov 5, 2014 11:54 PM, "NAREN N" wrote: > Hello, > In section 3.3.1 of the newly published NFD Developers Guide, it is said > and I quote > > >"An in-record expires when InterestLifetime has elapsed after the last > Interest packet arrives." > > This is applicable only as of today because each interest packet has the > same Life time. Suppose say a previously arrived packet from a face(Not the > last arriving packet) has a bigger InterestLifetime, it would be wrong to > delete the Face entry when the last packets InterestLifetime expires right? > > I hope it is clear to everyone. > > regards, > Naren > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.afanasyev at ucla.edu Wed Nov 12 15:15:37 2014 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Wed, 12 Nov 2014 15:15:37 -0800 Subject: [Nfd-dev] Install dependency packages in Jenkins script In-Reply-To: References:

Message-ID: <2B91E51B-A88C-4D3D-B745-AB9061CAE6AE@ucla.edu> > On Nov 4, 2014, at 9:03 AM, Junxiao Shi wrote: > > Hi Alex > > If buildbots use Brew instead of MacPorts, we should recommend customers/users use Brew as well. MacPorts is recommended because we ?packaging? ndn-cxx/nfd/tools as ports. For OS X 10.8, we no longer can do such recommendation. If somebody writes comparable brew packages, we can start recommending brew. But not until then. The simplification of brew is that it uses /usr/local as a home, which, similarly to Ubuntu slaves, does not require any path configuration (e.g., PKG_CONFIG_PATH vairable) > Please explain what's the "special way" in OSX 10.8, and why it cannot be offloaded to project-specific scripts. For this, I created a redmine issue, which may result in a wiki page: http://redmine.named-data.net/issues/2169 ? Alex > Yours, Junxiao > > On Sun, Nov 2, 2014 at 1:15 PM, Alex Afanasyev > wrote: > Just in case. OS X buildbots do not use macports (it was easier and more uniform to set up using brew). > > We had something like this for several projects (NLSR). The only issue with that I see is OSX 10.8, which requires special way of installing dependencies (which may fail if the process is completely offloaded to project-specific scripts). For all other systems, this can definitely be done. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Wed Nov 12 20:18:12 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Wed, 12 Nov 2014 21:18:12 -0700 Subject: [Nfd-dev] ndn-cxx feature deprecation: MetaInfo::TYPE_* Message-ID: Dear folks The following items are deprecated in ndn-cxx: - tlv::ContentType_Default - MetaInfo::TYPE_DEFAULT - MetaInfo::TYPE_BLOB - MetaInfo::TYPE_LINK - MetaInfo::TYPE_KEY - MetaInfo::TYPE_NACK If you have code that uses any of those features, please migrate to the new syntax as described in Doxygen. I will add DEPRECATED macro onto those items soon, but no earlier than Nov 18 12:00 UTC. This means compiler will produce a warning whenever they are used. If your project uses "-Werror" flag, this would become an error. Try compiling your projects with http://gerrit.named-data.net/1427 to see what happens. Those deprecated items will be deleted in v0.4. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.afanasyev at UCLA.EDU Thu Nov 13 13:54:50 2014 From: alexander.afanasyev at UCLA.EDU (Alex Afanasyev) Date: Thu, 13 Nov 2014 13:54:50 -0800 Subject: [Nfd-dev] Question about std::chrono::duration conversion to/from time::duration Message-ID: We have decided to stay with boost::chrono, as it provides more functionality for IO operations with time. However, in some cases, ndn-cxx dependent applications will be using and std::thread, and in particularly std::this_thread::sleep_for, which requires std::chrono::duration* type as a parameter. My question is do we need to make sure that ndn::time::duration* is convertible to std::chrono::duration. And if we want, are there a way to do it? --- Alex From shijunxiao at email.arizona.edu Thu Nov 13 13:58:36 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Thu, 13 Nov 2014 14:58:36 -0700 Subject: [Nfd-dev] Question about std::chrono::duration conversion to/from time::duration In-Reply-To: References: Message-ID: Dear folks Whether ndn::time is using boost::chrono or std::chrono shall be an implementation detail. I think we should provide implicit conversion operators between ndn::time::duration and std::chrono::duration, when Rep is the same and Period is equivalent. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.afanasyev at ucla.edu Thu Nov 13 14:25:42 2014 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Thu, 13 Nov 2014 14:25:42 -0800 Subject: [Nfd-dev] Question about std::chrono::duration conversion to/from time::duration In-Reply-To: References: Message-ID: > On Nov 13, 2014, at 1:58 PM, Junxiao Shi wrote: > > Dear folks > > Whether ndn::time is using boost::chrono or std::chrono shall be an implementation detail. > I think we should provide implicit conversion operators between ndn::time::duration and std::chrono::duration, when Rep is the same and Period is equivalent. Is there a way to do it without us creating our own class? I don?t seem to find a simple way for that. I really don?t want us to create duration class and implement everything that is implemented in std/boost::chrono From shijunxiao at email.arizona.edu Thu Nov 13 15:17:41 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Thu, 13 Nov 2014 16:17:41 -0700 Subject: [Nfd-dev] Question about std::chrono::duration conversion to/from time::duration In-Reply-To: References:

Message-ID: Hi Alex We can: - declare time::duration as a new class that inherits from boost::chrono::duration - in time::duration, provide an implicit conversion function to std::chrono::duration, and use enable_if to restrict the equivalence of Rep-Rep2 and Period-Period2 - in time::duration, provide an implicit constructor from std::chrono::duration, and use enable_if to restrict the equivalence of Rep-Rep2 and Period-Period2 The alternate is: - typedef std::chrono::duration as time::duration - implement operator<<(std::ostream&, time::duration) overloads that prints the duration by internally converting to boost::chrono::duration Yours, Junxiao On Thu, Nov 13, 2014 at 3:25 PM, Alex Afanasyev < alexander.afanasyev at ucla.edu> wrote: > > > On Nov 13, 2014, at 1:58 PM, Junxiao Shi > wrote: > > > > Dear folks > > > > Whether ndn::time is using boost::chrono or std::chrono shall be an > implementation detail. > > I think we should provide implicit conversion operators between > ndn::time::duration and std::chrono::duration, when > Rep is the same and Period is equivalent. > > Is there a way to do it without us creating our own class? I don?t seem > to find a simple way for that. I really don?t want us to create duration > class and implement everything that is implemented in std/boost::chrono > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.ARIZONA.EDU Fri Nov 14 13:55:02 2014 From: shijunxiao at email.ARIZONA.EDU (Junxiao Shi) Date: Fri, 14 Nov 2014 14:55:02 -0700 Subject: [Nfd-dev] [Ndn-app] Close NFD backdoor In-Reply-To: <1DBD3AF1-6A51-4E11-8996-764CA74D4893@cs.ucla.edu> References: <1DBD3AF1-6A51-4E11-8996-764CA74D4893@cs.ucla.edu> Message-ID: Dear folks 20141114 conference call decides that NFD will no longer accept unsolicited Data from local apps into ContentStore. http://redmine.named-data.net/issues/2181 Local apps are advised to use InMemoryStorage. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.afanasyev at UCLA.EDU Mon Nov 17 11:04:08 2014 From: alexander.afanasyev at UCLA.EDU (Alex Afanasyev) Date: Mon, 17 Nov 2014 14:04:08 -0500 Subject: [Nfd-dev] [Ndn-interest] compiling ndn-cxx issues on CentOS 6.4 In-Reply-To: References: Message-ID: <4B0BB212-CD92-41BA-AA29-01353FFED9EA@ucla.edu> I?m redirecting to nfd-dev mailing list, as it is more appropriate for this discussion. Redmine, suggested by Junxiao, would be even more appropriate. Which exactly version of ndn-cxx you?re trying to compile? ? Alex > On Nov 17, 2014, at 10:20 AM, Shuo Chen wrote: > > Dear all, > > I am trying to compiling ndn-cxx on CentOS 6.4. When I start ./waf, it comes with these errros: > > In file included from ./../src/common-pch.hpp:28, > from :0: > ./../src/common.hpp:109: error: using typename outside of template > ./../src/common.hpp:110: error: using typename outside of template > ./../src/common.hpp:111: error: using typename outside of template > ./../src/common.hpp:112: error: using typename outside of template > ./../src/common.hpp:113: error: using typename outside of template > ./../src/common.hpp:114: error: using typename outside of template > ./../src/common.hpp:115: error: using typename outside of template > ./../src/common.hpp:116: error: using typename outside of template > ./../src/common.hpp:117: error: using typename outside of template > > The gcc version is 4.6.4 boost version is 1.5.7 > > The ndn-cxx can be compiled on ubuntu but not CentOS. How to solve this issue? > > ---- > Shuo Chen > Tsinghua University From alexander.afanasyev at ucla.edu Mon Nov 17 12:19:26 2014 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Mon, 17 Nov 2014 15:19:26 -0500 Subject: [Nfd-dev] [Ndn-interest] compiling ndn-cxx issues on CentOS 6.4 In-Reply-To: References: Message-ID: <79FF9F53-2970-4321-A558-43CC8A372ED8@ucla.edu> I was able to reproduce this error on CentOS 6.4. However, the compiler that is used on CentOS 6.4 by default is 4.4.7, which doesn?t really support C++11 features. I was able to compile ndn-cxx, however, by installing gcc 4.8 from Devtoolset v2. Add .repo file into /etc/yum.repos.d [root at localhost ~]# cat /etc/yum.repos.d/princeton.repo [DevToolset-2] name=RedHat DevToolset v2 $releasever - $basearch baseurl=http://puias.princeton.edu/data/puias/DevToolset/$releasever/$basearch/ enabled=1 gpgcheck=0 then yum install devtoolset-2-gcc devtoolset-2-gcc-c++ devtoolset-2-binutils then . /opt/rh/devtoolset-2/enable ./waf configure ? > On Nov 17, 2014, at 10:20 AM, Shuo Chen wrote: > > Dear all, > > I am trying to compiling ndn-cxx on CentOS 6.4. When I start ./waf, it comes with these errros: > > In file included from ./../src/common-pch.hpp:28, > from :0: > ./../src/common.hpp:109: error: using typename outside of template > ./../src/common.hpp:110: error: using typename outside of template > ./../src/common.hpp:111: error: using typename outside of template > ./../src/common.hpp:112: error: using typename outside of template > ./../src/common.hpp:113: error: using typename outside of template > ./../src/common.hpp:114: error: using typename outside of template > ./../src/common.hpp:115: error: using typename outside of template > ./../src/common.hpp:116: error: using typename outside of template > ./../src/common.hpp:117: error: using typename outside of template > > The gcc version is 4.6.4 boost version is 1.5.7 > > The ndn-cxx can be compiled on ubuntu but not CentOS. How to solve this issue? > > ---- > Shuo Chen > Tsinghua University > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest From chenatu2006 at gmail.com Tue Nov 18 03:54:38 2014 From: chenatu2006 at gmail.com (Shuo Chen) Date: Tue, 18 Nov 2014 19:54:38 +0800 Subject: [Nfd-dev] [Ndn-interest] compiling ndn-cxx issues on CentOS 6.4 In-Reply-To: <79FF9F53-2970-4321-A558-43CC8A372ED8@ucla.edu> References: <79FF9F53-2970-4321-A558-43CC8A372ED8@ucla.edu> Message-ID: I think it would be better to check the version of gcc in ./waf configure ---- Shuo Chen On Tue, Nov 18, 2014 at 4:19 AM, Alex Afanasyev < alexander.afanasyev at ucla.edu> wrote: > I was able to reproduce this error on CentOS 6.4. However, the compiler > that is used on CentOS 6.4 by default is 4.4.7, which doesn?t really > support C++11 features. > > I was able to compile ndn-cxx, however, by installing gcc 4.8 from > Devtoolset v2. > > Add .repo file into /etc/yum.repos.d > > [root at localhost ~]# cat /etc/yum.repos.d/princeton.repo > [DevToolset-2] > name=RedHat DevToolset v2 $releasever - $basearch > baseurl= > http://puias.princeton.edu/data/puias/DevToolset/$releasever/$basearch/ > enabled=1 > gpgcheck=0 > > then yum install devtoolset-2-gcc devtoolset-2-gcc-c++ > devtoolset-2-binutils > > then > > . /opt/rh/devtoolset-2/enable > > ./waf configure > ? > > > > > On Nov 17, 2014, at 10:20 AM, Shuo Chen wrote: > > > > Dear all, > > > > I am trying to compiling ndn-cxx on CentOS 6.4. When I start ./waf, it > comes with these errros: > > > > In file included from ./../src/common-pch.hpp:28, > > from :0: > > ./../src/common.hpp:109: error: using typename outside of template > > ./../src/common.hpp:110: error: using typename outside of template > > ./../src/common.hpp:111: error: using typename outside of template > > ./../src/common.hpp:112: error: using typename outside of template > > ./../src/common.hpp:113: error: using typename outside of template > > ./../src/common.hpp:114: error: using typename outside of template > > ./../src/common.hpp:115: error: using typename outside of template > > ./../src/common.hpp:116: error: using typename outside of template > > ./../src/common.hpp:117: error: using typename outside of template > > > > The gcc version is 4.6.4 boost version is 1.5.7 > > > > The ndn-cxx can be compiled on ubuntu but not CentOS. How to solve this > issue? > > > > ---- > > Shuo Chen > > Tsinghua University > > _______________________________________________ > > Ndn-interest mailing list > > Ndn-interest at lists.cs.ucla.edu > > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Tue Nov 18 08:33:58 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Tue, 18 Nov 2014 09:33:58 -0700 Subject: [Nfd-dev] TPM for NFD Management Message-ID: Dear folks On OSX, ndn-cxx KeyChain can use either SecTpmFile or SecTpmOsx. NFD itself uses ndn-cxx KeyChain for signing Data in management module. How can I determine which TPM is used for this purpose? Which configuration file should I edit to choose a TPM for this purpose? Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.afanasyev at UCLA.EDU Tue Nov 18 09:06:14 2014 From: alexander.afanasyev at UCLA.EDU (Alex Afanasyev) Date: Tue, 18 Nov 2014 12:06:14 -0500 Subject: [Nfd-dev] TPM for NFD Management In-Reply-To: References: Message-ID: <7CB0B382-FA92-44B9-B7CB-9232671AE0DE@ucla.edu> It depends on how nfd was started / compiled. If it was compiled with /usr/local prefix and started manually using nfd-start, then ~/.ndn/client.conf /usr/local/etc/ndn/client.conf If it is installed with macports and started with macports version of nfd-start, then /usr/local/var/lib/ndn/nfd/.ndn/client.conf /opt/local/etc/ndn/client.conf If it is installed using PPA packages on Ubuntu and started with upstart (or PPA version of nfd-start) /var/lib/ndn/nfd/.ndn/client.conf /etc/ndn/client.conf ? Alex > On Nov 18, 2014, at 11:33 AM, Junxiao Shi wrote: > > Dear folks > > On OSX, ndn-cxx KeyChain can use either SecTpmFile or SecTpmOsx. > NFD itself uses ndn-cxx KeyChain for signing Data in management module. > > How can I determine which TPM is used for this purpose? > Which configuration file should I edit to choose a TPM for this purpose? > > Yours, Junxiao From davide.pesavento at lip6.fr Tue Nov 18 09:10:24 2014 From: davide.pesavento at lip6.fr (Davide Pesavento) Date: Tue, 18 Nov 2014 18:10:24 +0100 Subject: [Nfd-dev] TPM for NFD Management In-Reply-To: <7CB0B382-FA92-44B9-B7CB-9232671AE0DE@ucla.edu> References: <7CB0B382-FA92-44B9-B7CB-9232671AE0DE@ucla.edu> Message-ID: To avoid confusion, NFD should print the full path of the configuration file that's being used when it starts up... On Tue, Nov 18, 2014 at 6:06 PM, Alex Afanasyev wrote: > It depends on how nfd was started / compiled. > > If it was compiled with /usr/local prefix and started manually using nfd-start, then > > ~/.ndn/client.conf > /usr/local/etc/ndn/client.conf > > If it is installed with macports and started with macports version of nfd-start, then > > /usr/local/var/lib/ndn/nfd/.ndn/client.conf > /opt/local/etc/ndn/client.conf > > If it is installed using PPA packages on Ubuntu and started with upstart (or PPA version of nfd-start) > > /var/lib/ndn/nfd/.ndn/client.conf > /etc/ndn/client.conf > > ? > Alex > >> On Nov 18, 2014, at 11:33 AM, Junxiao Shi wrote: >> >> Dear folks >> >> On OSX, ndn-cxx KeyChain can use either SecTpmFile or SecTpmOsx. >> NFD itself uses ndn-cxx KeyChain for signing Data in management module. >> >> How can I determine which TPM is used for this purpose? >> Which configuration file should I edit to choose a TPM for this purpose? >> >> Yours, Junxiao > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev From alexander.afanasyev at ucla.edu Tue Nov 18 09:18:20 2014 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Tue, 18 Nov 2014 12:18:20 -0500 Subject: [Nfd-dev] TPM for NFD Management In-Reply-To: References: <7CB0B382-FA92-44B9-B7CB-9232671AE0DE@ucla.edu> Message-ID: This specific setting is not NFD's per se. It is more or less hack to ensure some local NFD/library connection policies (either local to the node or local to the user). > On Nov 18, 2014, at 12:10 PM, Davide Pesavento wrote: > > To avoid confusion, NFD should print the full path of the > configuration file that's being used when it starts up... > > On Tue, Nov 18, 2014 at 6:06 PM, Alex Afanasyev > wrote: >> It depends on how nfd was started / compiled. >> >> If it was compiled with /usr/local prefix and started manually using nfd-start, then >> >> ~/.ndn/client.conf >> /usr/local/etc/ndn/client.conf >> >> If it is installed with macports and started with macports version of nfd-start, then >> >> /usr/local/var/lib/ndn/nfd/.ndn/client.conf >> /opt/local/etc/ndn/client.conf >> >> If it is installed using PPA packages on Ubuntu and started with upstart (or PPA version of nfd-start) >> >> /var/lib/ndn/nfd/.ndn/client.conf >> /etc/ndn/client.conf >> >> ? >> Alex >> >>> On Nov 18, 2014, at 11:33 AM, Junxiao Shi wrote: >>> >>> Dear folks >>> >>> On OSX, ndn-cxx KeyChain can use either SecTpmFile or SecTpmOsx. >>> NFD itself uses ndn-cxx KeyChain for signing Data in management module. >>> >>> How can I determine which TPM is used for this purpose? >>> Which configuration file should I edit to choose a TPM for this purpose? >>> >>> Yours, Junxiao >> >> >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev From shijunxiao at email.arizona.edu Wed Nov 19 10:13:01 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Wed, 19 Nov 2014 11:13:01 -0700 Subject: [Nfd-dev] How to start a certificate chain from scratch Message-ID: Dear folks While we are able to request testbed certificates from ndncert website, when doing experiments, it's undesirable to request testbed certificates for all nodes. Suppose someone wants to start a certificate chain from scratch, how could this be done? Specifically, what are the commands to: 1. generate a root certificate: /example/KEY/ksk-1/ID-CERT 2. generate a site certificate and sign it by root certificate: /example/KEY/site1/ksk-2/ID-CERT 3. generate a user certificate and sign it by site certificate: /example/site1/KEY/user1/ksk-3/ID-CERT 4. publish root, site, user certificate in a repository or ndns system 5. generate a data signing certificate and sign it by user certificate: /example/site1/user1/KEY/dsk-4/ID-CERT Another question is: why is testbed root certificate named /ndn/KEY/ksk-xxxx/ID-CERT, instead of /KEY/ndn/ksk-xxxx/ID-CERT Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From yingdi at CS.UCLA.EDU Wed Nov 19 10:23:08 2014 From: yingdi at CS.UCLA.EDU (Yingdi Yu) Date: Wed, 19 Nov 2014 10:23:08 -0800 Subject: [Nfd-dev] How to start a certificate chain from scratch In-Reply-To: References: Message-ID: <024D7A01-E5BB-4204-9DAD-72372C17992D@cs.ucla.edu> > On Nov 19, 2014, at 10:13 AM, Junxiao Shi wrote: > > Dear folks > > While we are able to request testbed certificates from ndncert website, when doing experiments, it's undesirable to request testbed certificates for all nodes. > Suppose someone wants to start a certificate chain from scratch, how could this be done? Just to clarify, the scenario you describe is a trust model for the ndncert only. For apps that just want to use simple trust model, it is not necessary to create so many keys. > > Specifically, what are the commands to: > generate a root certificate: /example/KEY/ksk-1/ID-CERT > generate a site certificate and sign it by root certificate: /example/KEY/site1/ksk-2/ID-CERT > generate a user certificate and sign it by site certificate: /example/site1/KEY/user1/ksk-3/ID-CERT > publish root, site, user certificate in a repository or ndns system > generate a data signing certificate and sign it by user certificate: /example/site1/user1/KEY/dsk-4/ID-CERT > > Another question is: why is testbed root certificate named /ndn/KEY/ksk-xxxx/ID-CERT, instead of /KEY/ndn/ksk-xxxx/ID-CERT Because the root of the testbed is "/ndn" rather than "/", and testbed publish its root cert under its own prefix. Yingdi -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.ARIZONA.EDU Wed Nov 19 11:23:58 2014 From: shijunxiao at email.ARIZONA.EDU (Junxiao Shi) Date: Wed, 19 Nov 2014 12:23:58 -0700 Subject: [Nfd-dev] How to start a certificate chain from scratch In-Reply-To: <024D7A01-E5BB-4204-9DAD-72372C17992D@cs.ucla.edu> References: <024D7A01-E5BB-4204-9DAD-72372C17992D@cs.ucla.edu> Message-ID: Hi Yingdi Suppose one wants to mirror the same trust model as testbed and ndncert website, how can he do that? What are the commands? Yours, Junxiao On Nov 19, 2014 11:23 AM, "Yingdi Yu" wrote: > > Just to clarify, the scenario you describe is a trust model for the ndncert only. For apps that just want to use simple trust model, it is not necessary to create so many keys. > >> >> Specifically, what are the commands to: >> generate a root certificate: /example/KEY/ksk-1/ID-CERT >> generate a site certificate and sign it by root certificate: /example/KEY/site1/ksk-2/ID-CERT >> generate a user certificate and sign it by site certificate: /example/site1/KEY/user1/ksk-3/ID-CERT >> publish root, site, user certificate in a repository or ndns system >> generate a data signing certificate and sign it by user certificate: /example/site1/user1/KEY/dsk-4/ID-CERT >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From yingdi at CS.UCLA.EDU Wed Nov 19 11:49:27 2014 From: yingdi at CS.UCLA.EDU (Yingdi Yu) Date: Wed, 19 Nov 2014 11:49:27 -0800 Subject: [Nfd-dev] How to start a certificate chain from scratch In-Reply-To: References: <024D7A01-E5BB-4204-9DAD-72372C17992D@cs.ucla.edu> Message-ID: <014A7FB5-FEC7-4AFC-BE6E-FACC53E00A94@cs.ucla.edu> Hi Junxiao, > On Nov 19, 2014, at 11:23 AM, Junxiao Shi wrote: > > Hi Yingdi > > Suppose one wants to mirror the same trust model as testbed and ndncert website, how can he do that? What are the commands? > I list the commands for the example below: > >> Specifically, what are the commands to: > > >> generate a root certificate: /example/KEY/ksk-1/ID-CERT > $ ndnsec-keygen /example | ndnsec-cert-install - > >> generate a site certificate and sign it by root certificate: /example/KEY/site1/ksk-2/ID-CERT > $ ndnsec-keygen /example/site1 > site1-cert.req $ ndnsec-certgen -N /example/site1 -s /example site1-cert.req | ndnsec-cert-install - > >> generate a user certificate and sign it by site certificate: /example/site1/KEY/user1/ksk-3/ID-CERT > $ ndnsec-keygen /example/site1/user1 > user1-cert.req $ ndnsec-certgen -N /example/site1/user1 -s /example/site1 user1-cert.req | ndnsec-cert-install - > >> publish root, site, user certificate in a repository or ndns system > This depends on the tools. I usually write a simple cert publishing tool or use PIB to publish certificates > >> generate a data signing certificate and sign it by user certificate: /example/site1/user1/KEY/dsk-4/ID-CERT > For now, the command line tool disables dsk generation, but we could enable that if necessary. Yingdi -------------- next part -------------- An HTML attachment was scrubbed... URL: From lixia at CS.UCLA.EDU Wed Nov 19 13:17:50 2014 From: lixia at CS.UCLA.EDU (Lixia Zhang) Date: Wed, 19 Nov 2014 13:17:50 -0800 Subject: [Nfd-dev] How to start a certificate chain from scratch In-Reply-To: References: Message-ID: <5F013D6D-73C0-4C66-9279-A8297AC83C34@cs.ucla.edu> folks, security related topic should copy ndn-sec On Nov 19, 2014, at 10:13 AM, Junxiao Shi wrote: > Dear folks > > While we are able to request testbed certificates from ndncert website, when doing experiments, it's undesirable to request testbed certificates for all nodes. > Suppose someone wants to start a certificate chain from scratch, how could this be done? > > Specifically, what are the commands to: > generate a root certificate: /example/KEY/ksk-1/ID-CERT > generate a site certificate and sign it by root certificate: /example/KEY/site1/ksk-2/ID-CERT > generate a user certificate and sign it by site certificate: /example/site1/KEY/user1/ksk-3/ID-CERT > publish root, site, user certificate in a repository or ndns system > generate a data signing certificate and sign it by user certificate: /example/site1/user1/KEY/dsk-4/ID-CERT > > Another question is: why is testbed root certificate named /ndn/KEY/ksk-xxxx/ID-CERT, instead of /KEY/ndn/ksk-xxxx/ID-CERT > > Yours, Junxiao > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Thu Nov 20 21:43:59 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Thu, 20 Nov 2014 22:43:59 -0700 Subject: [Nfd-dev] ndn-cxx potentially breaking change: declare DEFAULT_INTEREST_LIFETIME as milliseconds Message-ID: Dear folks A potentially breaking change is coming to ndn-cxx soon: declaration type of DEFAULT_INTEREST_LIFETIME is changing from time::seconds to time::milliseconds. If your code assigns this constant to a time::seconds variable, or relies on .count() of this constant, it will be broken after this change. To fix your code: - assign to time::milliseconds: time::seconds is implicitly convertible to time::milliseconds, but not the other way around - use duration_cast before obaining .count() Please do so reply no later than Nov 26 12:00 UTC. We'll proceed with the change after that time. You can compile your projects with ndn-cxx Change http://gerrit.named-data.net/1461 and verify it works. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.ARIZONA.EDU Sat Nov 22 21:46:48 2014 From: shijunxiao at email.ARIZONA.EDU (Junxiao Shi) Date: Sat, 22 Nov 2014 22:46:48 -0700 Subject: [Nfd-dev] Jenkins OSX 10.10 slaves Message-ID: Hi Alex It seems that both Jenkins OSX 10.10 slaves have been offline for the past hour. Is there a scheduled maintenance? Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Sat Nov 22 21:52:07 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Sat, 22 Nov 2014 22:52:07 -0700 Subject: [Nfd-dev] Fwd: Re: Jenkins OSX 10.10 slaves In-Reply-To: <86CD7E5A-51CC-4327-9664-56775CA212D8@cs.ucla.edu> References: <86CD7E5A-51CC-4327-9664-56775CA212D8@cs.ucla.edu> Message-ID: ---------- Forwarded message ---------- From: "Alex Afanasyev" Date: Nov 22, 2014 10:51 PM Subject: Re: Jenkins OSX 10.10 slaves To: "Junxiao Shi" Cc: No maintainance, some failure. Trying to figure out what?s wrong with them. On Nov 22, 2014, at 9:46 PM, Junxiao Shi wrote: Hi Alex It seems that both Jenkins OSX 10.10 slaves have been offline for the past hour. Is there a scheduled maintenance? Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Sat Nov 22 21:59:39 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Sat, 22 Nov 2014 22:59:39 -0700 Subject: [Nfd-dev] Fwd: Re: Jenkins OSX 10.10 slaves In-Reply-To: <589AFA59-9C24-42F0-8ECF-261130D6DDC6@cs.ucla.edu> References: <589AFA59-9C24-42F0-8ECF-261130D6DDC6@cs.ucla.edu> Message-ID: ---------- Forwarded message ---------- From: "Alex Afanasyev" Date: Nov 22, 2014 10:58 PM Subject: Re: Jenkins OSX 10.10 slaves To: "Junxiao Shi" Cc: Some critical problem with hard drive on the host machine. Doubt I will recover it any time soon, we will need to disable 10.10 compilation (I will do it). On Nov 22, 2014, at 9:46 PM, Junxiao Shi wrote: Hi Alex It seems that both Jenkins OSX 10.10 slaves have been offline for the past hour. Is there a scheduled maintenance? Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Sun Nov 23 05:16:56 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Sun, 23 Nov 2014 06:16:56 -0700 Subject: [Nfd-dev] Jenkins OSX 10.10 slaves In-Reply-To: References: <589AFA59-9C24-42F0-8ECF-261130D6DDC6@cs.ucla.edu> Message-ID: Dear folks 10.10 slaves are temporary taken off due to hardware issues. They'll be restored in Task 2210. Yours, Junxiao On Nov 22, 2014 10:59 PM, "Junxiao Shi" wrote: > ---------- Forwarded message ---------- > From: "Alex Afanasyev" > Date: Nov 22, 2014 10:58 PM > Subject: Re: Jenkins OSX 10.10 slaves > To: "Junxiao Shi" > Cc: > > Some critical problem with hard drive on the host machine. Doubt I will > recover it any time soon, we will need to disable 10.10 compilation (I will > do it). > > On Nov 22, 2014, at 9:46 PM, Junxiao Shi > wrote: > > Hi Alex > > It seems that both Jenkins OSX 10.10 slaves have been offline for the past > hour. > Is there a scheduled maintenance? > > Yours, Junxiao > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Sun Nov 23 05:20:41 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Sun, 23 Nov 2014 06:20:41 -0700 Subject: [Nfd-dev] Import ndn-cxx unit-test-time-fixture.hpp Message-ID: Hi Alex I want to import ndn-cxx/tests/unit-tests/unit-test-time-fixture.hpp to NFD. Please grant permission. Use REPLY-ALL to ensure this permission is logged by mailing list. Please also recommend an appropriate license boilerplate for imported code. Yours, Junxiao On Oct 20, 2014 10:30 PM, "Alex Afanasyev" wrote: > > You should always read the license / contact the original copyright holders whenever you're borrowing any code. For some popular licenses, such as GPL/LPGL, there are a numerous explanations on the Internet describing how properly use that code in the project. > > --- > Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From davide.pesavento at lip6.fr Sun Nov 23 07:27:31 2014 From: davide.pesavento at lip6.fr (Davide Pesavento) Date: Sun, 23 Nov 2014 16:27:31 +0100 Subject: [Nfd-dev] Jenkins OSX 10.10 slaves In-Reply-To: References: <589AFA59-9C24-42F0-8ECF-261130D6DDC6@cs.ucla.edu>

Message-ID: Will this impact merging of pending changes? Thanks, Davide On Sun, Nov 23, 2014 at 2:16 PM, Junxiao Shi wrote: > Dear folks > > 10.10 slaves are temporary taken off due to hardware issues. > They'll be restored in Task 2210. > > Yours, Junxiao > On Nov 22, 2014 10:59 PM, "Junxiao Shi" > wrote: > >> ---------- Forwarded message ---------- >> From: "Alex Afanasyev" >> Date: Nov 22, 2014 10:58 PM >> Subject: Re: Jenkins OSX 10.10 slaves >> To: "Junxiao Shi" >> Cc: >> >> Some critical problem with hard drive on the host machine. Doubt I will >> recover it any time soon, we will need to disable 10.10 compilation (I will >> do it). >> >> On Nov 22, 2014, at 9:46 PM, Junxiao Shi >> wrote: >> >> Hi Alex >> >> It seems that both Jenkins OSX 10.10 slaves have been offline for the >> past hour. >> Is there a scheduled maintenance? >> >> Yours, Junxiao >> >> >> > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Sun Nov 23 07:31:50 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Sun, 23 Nov 2014 08:31:50 -0700 Subject: [Nfd-dev] Jenkins OSX 10.10 slaves In-Reply-To: References: <589AFA59-9C24-42F0-8ECF-261130D6DDC6@cs.ucla.edu>

Message-ID: Pending commits will be verified without OSX 10.10. If build is failing after OSX 10.10 is re-enabled, I'll run git blame and assign bugs to whoever committed them. On Nov 23, 2014 8:28 AM, "Davide Pesavento" wrote: > Will this impact merging of pending changes? > > Thanks, > Davide > > On Sun, Nov 23, 2014 at 2:16 PM, Junxiao Shi > wrote: > >> Dear folks >> >> 10.10 slaves are temporary taken off due to hardware issues. >> They'll be restored in Task 2210. >> >> Yours, Junxiao >> On Nov 22, 2014 10:59 PM, "Junxiao Shi" >> wrote: >> >>> ---------- Forwarded message ---------- >>> From: "Alex Afanasyev" >>> Date: Nov 22, 2014 10:58 PM >>> Subject: Re: Jenkins OSX 10.10 slaves >>> To: "Junxiao Shi" >>> Cc: >>> >>> Some critical problem with hard drive on the host machine. Doubt I will >>> recover it any time soon, we will need to disable 10.10 compilation (I will >>> do it). >>> >>> On Nov 22, 2014, at 9:46 PM, Junxiao Shi >>> wrote: >>> >>> Hi Alex >>> >>> It seems that both Jenkins OSX 10.10 slaves have been offline for the >>> past hour. >>> Is there a scheduled maintenance? >>> >>> Yours, Junxiao >>> >>> >>> >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.afanasyev at ucla.edu Sun Nov 23 10:47:32 2014 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Sun, 23 Nov 2014 10:47:32 -0800 Subject: [Nfd-dev] Import ndn-cxx unit-test-time-fixture.hpp In-Reply-To: References: Message-ID: <5B87035C-15F8-4706-A4E3-D12EBC03BEFC@ucla.edu> Hi Junxiao, Of course you can import the code. In general, moving code from lgpl to gpl license is allowed by the license. In the moved code I would replace the copyright notice with NFD's one, given the simplicity of that particular file and the fact that code was based on your code. --- Alex > On Nov 23, 2014, at 5:20 AM, Junxiao Shi wrote: > > Hi Alex > > I want to import ndn-cxx/tests/unit-tests/unit-test-time-fixture.hpp to NFD. > Please grant permission. Use REPLY-ALL to ensure this permission is logged by mailing list. > > Please also recommend an appropriate license boilerplate for imported code. > > Yours, Junxiao > > On Oct 20, 2014 10:30 PM, "Alex Afanasyev" wrote: > > > > You should always read the license / contact the original copyright holders whenever you're borrowing any code. For some popular licenses, such as GPL/LPGL, there are a numerous explanations on the Internet describing how properly use that code in the project. > > > > --- > > Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From obaidasyed at gmail.com Mon Nov 24 08:50:06 2014 From: obaidasyed at gmail.com (Syed Obaid Amin) Date: Mon, 24 Nov 2014 10:50:06 -0600 Subject: [Nfd-dev] What is the desired behavior of Faces to dead nodes? Message-ID: Hello all, I've two machines, say A and B. When I start nfd at A only (not on B) and create a udp tunnel to B, I can see that entry in the FIB and RIB. But as soon as I start ndnping from A to B the FIB and RIB entries to B goes away from A. If I don't do any ndnping that entry remains in the RIB and FIB. Is this a desired behavior or a bug? Thanks, Obaid -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Mon Nov 24 08:59:58 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Mon, 24 Nov 2014 09:59:58 -0700 Subject: [Nfd-dev] What is the desired behavior of Faces to dead nodes? In-Reply-To: References: Message-ID: Hi Obaid This behavior is by design. The face created is a persistent face, which would not expire on idle, but would be closed if it fails. When something is sent out of the face to a non-existent port, ICMP error comes back, which causes the face to fail and be closed. When a face is closed, Routes and FibNextHop records associated with that face are removed. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From obaidasyed at gmail.com Mon Nov 24 09:21:19 2014 From: obaidasyed at gmail.com (Syed Obaid Amin) Date: Mon, 24 Nov 2014 11:21:19 -0600 Subject: [Nfd-dev] What is the desired behavior of Faces to dead nodes? In-Reply-To: References: Message-ID: Hi Junxiao, Thanks for the clarification. But may I know the rationale behind this design? Like can't we ignore the ICMP error for UDP tunnels? Closing a face makes sense for stateful connections, but I think for stateless connections like UDP, if the remote end goes down the local end should not be affected? Regards, Obaid On Mon, Nov 24, 2014 at 10:59 AM, Junxiao Shi wrote: > Hi Obaid > > This behavior is by design. > > The face created is a persistent face, which would not expire on idle, but > would be closed if it fails. > When something is sent out of the face to a non-existent port, ICMP error > comes back, which causes the face to fail and be closed. > When a face is closed, Routes and FibNextHop records associated with that > face are removed. > > Yours, Junxiao > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Mon Nov 24 09:30:02 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Mon, 24 Nov 2014 10:30:02 -0700 Subject: [Nfd-dev] What is the desired behavior of Faces to dead nodes? In-Reply-To: References:

Message-ID: Hi Obaid See Bug 1720 note-17: Our intention is not making UDP tunnels like physical links A "permanent face" that does not close upon failure is in the plan. It's intended for connections between routers. It's defined in Face Management protocol, but no face currently support that. Its implementation depends on tunnel authentication protocol . Yours, Junxiao On Mon, Nov 24, 2014 at 10:21 AM, Syed Obaid Amin wrote: > Hi Junxiao, > > Thanks for the clarification. > > But may I know the rationale behind this design? Like can't we ignore the > ICMP error for UDP tunnels? Closing a face makes sense for stateful > connections, but I think for stateless connections like UDP, if the remote > end goes down the local end should not be affected? > > Regards, > Obaid > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Mon Nov 24 13:34:03 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Mon, 24 Nov 2014 14:34:03 -0700 Subject: [Nfd-dev] ndn-cxx potentially breaking change: declare DEFAULT_INTEREST_LIFETIME as milliseconds In-Reply-To: References: Message-ID: Dear folks Unfortunately our other reviewer merged the commit earlier than promised, and refuses to revert it unless someone complains. If your code is broken by this commit and you need a bit more time to fix it, please REPLY-ALL and we'll revert the commit and merge it again after Nov 26 12:00 UTC. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Mon Nov 24 13:38:02 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Mon, 24 Nov 2014 14:38:02 -0700 Subject: [Nfd-dev] ndn-cxx potentially breaking change: declare DEFAULT_INTEREST_LIFETIME as milliseconds In-Reply-To: References:

Message-ID: Dear folks This commit has been manually unmerged (it is available in a separate "coming-api-change" branch). Yours, Junxiao ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Tue Nov 25 22:29:16 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Tue, 25 Nov 2014 23:29:16 -0700 Subject: [Nfd-dev] need volunteer to test EthernetFace on OSX and Boost 1.57 Message-ID: Dear folks Is anyone on this mailing list running OSX (any of 10.8 10.9 10.10) with Boost 1.57 installed? We need a volunteer to test some code on this specific platform. Please reply-all if you have a machine with this setup. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Thu Nov 27 12:21:45 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Thu, 27 Nov 2014 13:21:45 -0700 Subject: [Nfd-dev] ndn-cxx deprecated feature removal Message-ID: Dear folks The following deprecated feature will be removed from ndn-cxx soon: constructor: Selectors(int minSuffixComponents, int maxSuffixComponents, const Exclude& exclude, int childSelector, bool mustBeFresh); constructor: Interest(const Name& name, int minSuffixComponents, int maxSuffixComponents, const Exclude& exclude, int childSelector, bool mustBeFresh, int scope, const time::milliseconds& interestLifetime, uint32_t nonce); If you have code that depend on this feature and cannot be fixed now, please reply no later than Dec 02 12:00 UTC. Otherwise, we'll proceed with the removal after that time. You can compile your projects with ndn-cxx Change http://gerrit.named-data.net/1479 and verify it works. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Thu Nov 27 12:22:26 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Thu, 27 Nov 2014 13:22:26 -0700 Subject: [Nfd-dev] ndn-cxx deprecated feature removal: Selectors constructor Message-ID: Dear folks The following deprecated feature will be removed from ndn-cxx soon: constructor: Selectors(int minSuffixComponents, int maxSuffixComponents, const Exclude& exclude, int childSelector, bool mustBeFresh); constructor: Interest(const Name& name, int minSuffixComponents, int maxSuffixComponents, const Exclude& exclude, int childSelector, bool mustBeFresh, int scope, const time::milliseconds& interestLifetime, uint32_t nonce); If you have code that depend on this feature and cannot be fixed now, please reply no later than Dec 02 12:00 UTC. Otherwise, we'll proceed with the removal after that time. You can compile your projects with ndn-cxx Change http://gerrit.named-data.net/1479 and verify it works. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Thu Nov 27 19:59:27 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Thu, 27 Nov 2014 20:59:27 -0700 Subject: [Nfd-dev] NFD faces/create: requires canonical FaceUri Message-ID: Dear folks Please be aware of an upcoming NFD Management API change: *faces/create command requires canonical FaceUri*. This change will happen no sooner than Dec 04 12:00 UTC. A canonical FaceUri for UDP and TCP tunnels should specify either IPv4 or IPv6, have IP address instead of hostname, and contain port number. Examples of canonical FaceUri: udp4://192.0.2.1:6363 udp6://[2001:db8::1]:6363 tcp4://192.0.2.1:6363 tcp6://[2001:db8::1]:6363 Examples of non-canonical FaceUri that will be rejected by faces/create command after the change: udp://192.0.2.1 udp://example.net:6363 udp4://example.net:6363 udp6://example.net:6363 tcp://192.0.2.1 tcp://example.net:6363 tcp4://example.net:6363 tcp6://example.net:6363 *If you have a library / application that utilizes NFD faces/create command, please canonize the FaceUri before sending the command*. Scripts calling nfdc command line tool are unaffected by this change. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From jburke at remap.ucla.edu Fri Nov 28 11:45:04 2014 From: jburke at remap.ucla.edu (Burke, Jeff) Date: Fri, 28 Nov 2014 19:45:04 +0000 Subject: [Nfd-dev] [Ndn-app] NFD faces/create: requires canonical FaceUri In-Reply-To: Message-ID: Hi Junxiao, Thanks. What's the design rationale for the changes? (In general, I'd suggest that API updates should include at least a brief statement on why they're being made.) The removal of support for DNS names seems odd from a usability standpoint, and I don't understand why udp and udp4 can't just be considered equivalent. Thanks, Jeff From: Junxiao Shi > Date: Thu, 27 Nov 2014 20:59:27 -0700 To: "ndn-app at lists.cs.ucla.edu" >, "ndn-lib at lists.cs.ucla.edu" >, ">" > Subject: [Ndn-app] NFD faces/create: requires canonical FaceUri Dear folks Please be aware of an upcoming NFD Management API change: faces/create command requires canonical FaceUri. This change will happen no sooner than Dec 04 12:00 UTC. A canonical FaceUri for UDP and TCP tunnels should specify either IPv4 or IPv6, have IP address instead of hostname, and contain port number. Examples of canonical FaceUri: udp4://192.0.2.1:6363 udp6://[2001:db8::1]:6363 tcp4://192.0.2.1:6363 tcp6://[2001:db8::1]:6363 Examples of non-canonical FaceUri that will be rejected by faces/create command after the change: udp://192.0.2.1 udp://example.net:6363 udp4://example.net:6363 udp6://example.net:6363 tcp://192.0.2.1 tcp://example.net:6363 tcp4://example.net:6363 tcp6://example.net:6363 If you have a library / application that utilizes NFD faces/create command, please canonize the FaceUri before sending the command. Scripts calling nfdc command line tool are unaffected by this change. Yours, Junxiao _______________________________________________ Ndn-app mailing list Ndn-app at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-app -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Fri Nov 28 12:13:06 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Fri, 28 Nov 2014 13:13:06 -0700 Subject: [Nfd-dev] [Ndn-app] NFD faces/create: requires canonical FaceUri In-Reply-To: References: Message-ID: Hi Jeff DNS is a complex affair that has many details to take care of. NFD isn't the right place to perform DNS resolution, so we have decided to off-load this operation to the client library. ndn-cxx provides FaceUri::isCanonical method that determines whether a FaceUri is canonical. ndn-cxx provides FaceUri::canonize method to perform DNS resolution, and obtain a canonical FaceUri. Most users shouldn't be affected, because nfdc command line tool will canonize FaceUri before creating face. NLSR is the only known app that uses faces/create command through ndn-cxx Controller API, and NLSR has been updated. Apps based on ndn-ccl shouldn't be affected because ndn-ccl API doesn't have a face creation method. udp and udp4 are not equivalent. udp can be resolved to either udp4 or udp6. udp://192.0.2.1 will be canonized as udp4://192.0.2.1:6363 Yours, Junxiao On Nov 28, 2014 12:45 PM, "Burke, Jeff" wrote: > > Hi Junxiao, > > Thanks. What's the design rationale for the changes? (In general, I'd > suggest that API updates should include at least a brief statement on > *why* they're being made.) > > The removal of support for DNS names seems odd from a usability > standpoint, and I don't understand why udp and udp4 can't just be > considered equivalent. > > Thanks, > Jeff > > From: Junxiao Shi > Date: Thu, 27 Nov 2014 20:59:27 -0700 > To: "ndn-app at lists.cs.ucla.edu" , " > ndn-lib at lists.cs.ucla.edu" , "< > nfd-dev at lists.cs.ucla.edu>" > Subject: [Ndn-app] NFD faces/create: requires canonical FaceUri > > Dear folks > > Please be aware of an upcoming NFD Management API change: *faces/create > command requires canonical FaceUri*. > This change will happen no sooner than Dec 04 12:00 UTC. > > A canonical FaceUri for UDP and TCP tunnels should specify either IPv4 > or IPv6, have IP address instead of hostname, and contain port number. > > Examples of canonical FaceUri: > udp4://192.0.2.1:6363 > udp6://[2001:db8::1]:6363 > tcp4://192.0.2.1:6363 > tcp6://[2001:db8::1]:6363 > > Examples of non-canonical FaceUri that will be rejected by faces/create > command after the change: > udp://192.0.2.1 > udp://example.net:6363 > udp4://example.net:6363 > udp6://example.net:6363 > tcp://192.0.2.1 > tcp://example.net:6363 > tcp4://example.net:6363 > tcp6://example.net:6363 > > *If you have a library / application that utilizes NFD faces/create > command, please canonize the FaceUri before sending the command*. > Scripts calling nfdc command line tool are unaffected by this change. > > Yours, Junxiao > _______________________________________________ Ndn-app mailing list > Ndn-app at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-app > > -------------- next part -------------- An HTML attachment was scrubbed... URL: