From shijunxiao at email.arizona.edu  Tue Apr  1 12:10:55 2014
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Tue, 1 Apr 2014 12:10:55 -0700
Subject: [Nfd-dev] Jenkins down
In-Reply-To: <CAOFH+ObnsZvqFXosr7SgGp5iHtRZ1TMgX+F-Vhr-4n_NWLHgyw@mail.gmail.com>
References: <CAOFH+OZg2bN=00wK6J_Obko1FJ1UvUH2YzH62Xf5v-bdw2seMA@mail.gmail.com>
	<CAOFH+ObnsZvqFXosr7SgGp5iHtRZ1TMgX+F-Vhr-4n_NWLHgyw@mail.gmail.com>
Message-ID: <CAOFH+OZ=aWb_C1KjPYu51zv=1QTrGEWaozaCHfHZt-jUw9THiw@mail.gmail.com>

Hi NFD developers

Jenkins system is down due to unplanned network outage in Arizona campus.
http://uits.arizona.edu/alertitem?id=765

There's no ETA on when this could be fixed.

Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140401/0193c954/attachment.html>

From shijunxiao at email.arizona.edu  Tue Apr  1 13:26:25 2014
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Tue, 1 Apr 2014 13:26:25 -0700
Subject: [Nfd-dev] Jenkins up
Message-ID: <CAOFH+OZpRd9gjWZpYxGLUzuOSdKSMEz1JfrNDdj7Rm0nemP3Jw@mail.gmail.com>

Hi NFD developers

Jenkins system is reconnected.
Pending jobs will take a while to complete.

Yours, Junxiao
On Apr 1, 2014 12:10 PM, "Junxiao Shi" <shijunxiao at email.arizona.edu> wrote:

> Hi NFD developers
>
> Jenkins system is down due to unplanned network outage in Arizona campus.
> http://uits.arizona.edu/alertitem?id=765
>
> There's no ETA on when this could be fixed.
>
> Yours, Junxiao
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140401/3937c5e4/attachment.html>

From afanasev at cs.ucla.edu  Tue Apr  1 13:58:12 2014
From: afanasev at cs.ucla.edu (Alex Afanasyev)
Date: Tue, 1 Apr 2014 13:58:12 -0700
Subject: [Nfd-dev] NFD CodeStyle rule 76
In-Reply-To: <CAOFH+OYPQyhx3brOs7z-PUiQ1gFxvZx0aryBBTqr0nYnNN1mCA@mail.gmail.com>
References: <CAOFH+OYPQyhx3brOs7z-PUiQ1gFxvZx0aryBBTqr0nYnNN1mCA@mail.gmail.com>
Message-ID: <2B3692E5-A074-432C-A5CC-E831AE090CA2@cs.ucla.edu>

Hi guys,

I have updated rule 76 to be more consistent with other style changes:

(changed 76) switch statement should have one of the two of following forms:

switch (condition) {
case ABC:
  statements;
  // Fallthrough

case DEF:
  statements;
  break;

case XYZ:
  statements;
  break;

default:
  statements;
  break;
}
or

switch (condition)
  {
  case ABC:
    statements;
    // Fallthrough

  case DEF:
    statements;
    break;

  case XYZ:
    statements;
    break;

  default:
    statements;
    break;
  }

These two variants is what emacs will do when our gnu style is selected.  Previous variant was directly copied from the base rules and I don't think I ever followed that one.

---
Alex

On Mar 30, 2014, at 7:18 PM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:

> Hi Alex
> 
> Amended rule 76 gives an example of a switch statement:
> switch (condition) { 
>   case ABC:
>     statements; 
>     // Fallthrough 
> 
>   case DEF: 
>     statements; 
>     break;
> 
>   case XYZ: 
>     statements; 
>     break; 
> 
>   default: 
>     statements; 
>     break;
> }
> 
> Rule 76 also states: Note that each case keyword is indented relative to the switch statement as a whole.
> This note is not eliminated by the amendment.
> 
> 
> Amended rule 68 permits an additional block layout:
> while (!done)
>   {
>     doSomething();
>     done = moreToDo();
>   }
> 
> 
> There is a conflict when two amendments are applied together.
> 
> The note in rule 76 causes case keywords to indent relative to the switch keyword.
> The example given indicates that the relative offset is 2 spaces.
> 
> However, when the additional block layout permitted by amended rule 68 is used, case keywords would end up at the same column with { } brackets.
> switch (condition)
>   {
>   case ABC:
>     statements;
>     break;
>   default:
>     statements;
>     break;
>   }
> 
> Is this the intended layout, or should case keywords be indented 4 spaces after switch keyword (2 spaces after { } brackets)?
> switch (condition)
>   {
>     case ABC:
>       statements;
>       break;
>     default:
>       statements;
>       break;
>   }
> 
> Yours, Junxiao

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140401/d666809a/attachment.html>

From shijunxiao at email.arizona.edu  Wed Apr  2 20:19:29 2014
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Wed, 2 Apr 2014 20:19:29 -0700
Subject: [Nfd-dev] Jenkins down
Message-ID: <CAOFH+OYRq5ymWZj1z2G36LMqo0ge7Z6EjL54eBEUqpr8+Ep2mw@mail.gmail.com>

Hi NFD developers

Jenkins system is inaccessible again due to network outage.

Yours, Junxiao

---------- Forwarded message ----------
From: Tom Lowry <tlowry at cs.arizona.edu>
Date: Wed, Apr 2, 2014 at 7:58 PM
Subject: [compsciphd] network outage
To: dept at cs.arizona.edu
Cc: Section Leader Coordinators <slcoord at cs.arizona.edu>


There has been another network outage in Gould-Simpson which affects all
the CS computers.  UITS is aware of the problem and should have it up and
running early tomorrow morning.

--
Lab Staff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140402/faf26535/attachment.html>

From shijunxiao at email.arizona.edu  Thu Apr  3 07:49:11 2014
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Thu, 03 Apr 2014 07:49:11 -0700
Subject: [Nfd-dev] Jenkins up
In-Reply-To: <CAOFH+OYRq5ymWZj1z2G36LMqo0ge7Z6EjL54eBEUqpr8+Ep2mw@mail.gmail.com>
References: <CAOFH+OYRq5ymWZj1z2G36LMqo0ge7Z6EjL54eBEUqpr8+Ep2mw@mail.gmail.com>
Message-ID: <0edd3e7e-26be-44b6-8250-93175093b0fa@email.android.com>

Hi NFD developers

Jenkins system is reconnected.
Pending jobs will take a while to complete.

I hope there?s no more network outages.

Yours, Junxiao

On April 2, 2014 8:19:29 PM MST, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:
>Hi NFD developers
>
>Jenkins system is inaccessible again due to network outage.
>
>Yours, Junxiao
>
>---------- Forwarded message ----------
>From: Tom Lowry <tlowry at cs.arizona.edu>
>Date: Wed, Apr 2, 2014 at 7:58 PM
>Subject: [compsciphd] network outage
>To: dept at cs.arizona.edu
>Cc: Section Leader Coordinators <slcoord at cs.arizona.edu>
>
>
>There has been another network outage in Gould-Simpson which affects
>all
>the CS computers.  UITS is aware of the problem and should have it up
>and
>running early tomorrow morning.
>
>--
>Lab Staff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140403/b95b23e7/attachment.html>

From alexander.afanasyev at ucla.edu  Thu Apr  3 11:01:11 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Thu, 3 Apr 2014 11:01:11 -0700
Subject: [Nfd-dev] Updated copyright notice in all files
Message-ID: <19308C8B-AB3A-405D-91DB-29ED9075CC61@ucla.edu>

Hi guys,

Here is an updated version of the copyright notice that is proposed to be put in each file.
I'll wait till tomorrow and if no objections, I will proceed with NFD source code modifications.


/* -*- Mode:C++; c-file-style:"gnu"; indent-tabs-mode:nil; -*- */
/**
 * Copyright (c) 2014  Regents of the University of California,
 *                     Arizona Board of Regents,
 *                     Colorado State University,
 *                     Universit? Pierre et Marie Curie, Sorbonne Universities,
 *                     Washington University in St. Louis,
 *                     Beijing Institute of Technology
 *
 * This file is part of NFD (Named Data Networking Forwarding Daemon).
 * See AUTHORS.md for complete list of NFD authors and contributors.
 *
 * NFD is free software: you can redistribute it and/or modify it under the terms
 * of the GNU General Public License as published by the Free Software Foundation,
 * either version 3 of the License, or (at your option) any later version.
 *
 * NFD is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY;
 * without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
 * PURPOSE.  See the GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License along with
 * NFD, e.g., in COPYING.md file.  If not, see <http://www.gnu.org/licenses/>.
 *
 * \license GPL-3.0+ <http://spdx.org/licenses/GPL-3.0+>
 ////// [optional part] //////
 *
 * \author Author's Name <email at domain>
 * \author Other Author's Name <another.email at domain>
 ////// [end of optional part] //////
 */


---
Alex





From gpau at cs.ucla.edu  Thu Apr  3 22:37:49 2014
From: gpau at cs.ucla.edu (Giovanni Pau)
Date: Thu, 3 Apr 2014 22:37:49 -0700
Subject: [Nfd-dev] Updated copyright notice in all files
In-Reply-To: <19308C8B-AB3A-405D-91DB-29ED9075CC61@ucla.edu>
References: <19308C8B-AB3A-405D-91DB-29ED9075CC61@ucla.edu>
Message-ID: <5B5E5FD9-D0EC-4C59-8E6D-DD8D029BB729@cs.ucla.edu>

Hi Alex,

give me today (my friday) to get a final ok from our side, I would say is good but i prefer to run it to University VP.
g. 
==========================
It had long since come to my attention that people of accomplishment rarely sat back and let things happen to them. They went out and happened to things. 

- Leonardo da Vinci 
==========================




On Apr 3, 2014, at 11:01 AM, Alex Afanasyev <alexander.afanasyev at ucla.edu> wrote:

> Hi guys,
> 
> Here is an updated version of the copyright notice that is proposed to be put in each file.
> I'll wait till tomorrow and if no objections, I will proceed with NFD source code modifications.
> 
> 
> /* -*- Mode:C++; c-file-style:"gnu"; indent-tabs-mode:nil; -*- */
> /**
> * Copyright (c) 2014  Regents of the University of California,
> *                     Arizona Board of Regents,
> *                     Colorado State University,
> *                     Universit? Pierre et Marie Curie, Sorbonne Universities,
> *                     Washington University in St. Louis,
> *                     Beijing Institute of Technology
> *
> * This file is part of NFD (Named Data Networking Forwarding Daemon).
> * See AUTHORS.md for complete list of NFD authors and contributors.
> *
> * NFD is free software: you can redistribute it and/or modify it under the terms
> * of the GNU General Public License as published by the Free Software Foundation,
> * either version 3 of the License, or (at your option) any later version.
> *
> * NFD is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY;
> * without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
> * PURPOSE.  See the GNU General Public License for more details.
> *
> * You should have received a copy of the GNU General Public License along with
> * NFD, e.g., in COPYING.md file.  If not, see <http://www.gnu.org/licenses/>.
> *
> * \license GPL-3.0+ <http://spdx.org/licenses/GPL-3.0+>
> ////// [optional part] //////
> *
> * \author Author's Name <email at domain>
> * \author Other Author's Name <another.email at domain>
> ////// [end of optional part] //////
> */
> 
> 
> ---
> Alex
> 
> 
> 
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev




From gpau at cs.ucla.edu  Thu Apr  3 23:47:58 2014
From: gpau at cs.ucla.edu (Giovanni Pau)
Date: Thu, 3 Apr 2014 23:47:58 -0700
Subject: [Nfd-dev] Updated copyright notice in all files
In-Reply-To: <5B5E5FD9-D0EC-4C59-8E6D-DD8D029BB729@cs.ucla.edu>
References: <19308C8B-AB3A-405D-91DB-29ED9075CC61@ucla.edu>
	<5B5E5FD9-D0EC-4C59-8E6D-DD8D029BB729@cs.ucla.edu>
Message-ID: <44246284-826E-4CDF-BDDC-B18B444B822B@cs.ucla.edu>

Hi Alex,

I double checked and the Copyright for us shall be in english as well:

University Pierre & Marie Curie, Sorbonne University


Thanks in advance
g. 

==========================
It had long since come to my attention that people of accomplishment rarely sat back and let things happen to them. They went out and happened to things. 

- Leonardo da Vinci 
==========================




On Apr 3, 2014, at 10:37 PM, Giovanni Pau <gpau at CS.UCLA.EDU> wrote:

> Hi Alex,
> 
> give me today (my friday) to get a final ok from our side, I would say is good but i prefer to run it to University VP.
> g. 
> ==========================
> It had long since come to my attention that people of accomplishment rarely sat back and let things happen to them. They went out and happened to things. 
> 
> - Leonardo da Vinci 
> ==========================
> 
> 
> 
> 
> On Apr 3, 2014, at 11:01 AM, Alex Afanasyev <alexander.afanasyev at ucla.edu> wrote:
> 
>> Hi guys,
>> 
>> Here is an updated version of the copyright notice that is proposed to be put in each file.
>> I'll wait till tomorrow and if no objections, I will proceed with NFD source code modifications.
>> 
>> 
>> /* -*- Mode:C++; c-file-style:"gnu"; indent-tabs-mode:nil; -*- */
>> /**
>> * Copyright (c) 2014  Regents of the University of California,
>> *                     Arizona Board of Regents,
>> *                     Colorado State University,
>> *                     Universit? Pierre et Marie Curie, Sorbonne Universities,
>> *                     Washington University in St. Louis,
>> *                     Beijing Institute of Technology
>> *
>> * This file is part of NFD (Named Data Networking Forwarding Daemon).
>> * See AUTHORS.md for complete list of NFD authors and contributors.
>> *
>> * NFD is free software: you can redistribute it and/or modify it under the terms
>> * of the GNU General Public License as published by the Free Software Foundation,
>> * either version 3 of the License, or (at your option) any later version.
>> *
>> * NFD is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY;
>> * without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
>> * PURPOSE.  See the GNU General Public License for more details.
>> *
>> * You should have received a copy of the GNU General Public License along with
>> * NFD, e.g., in COPYING.md file.  If not, see <http://www.gnu.org/licenses/>.
>> *
>> * \license GPL-3.0+ <http://spdx.org/licenses/GPL-3.0+>
>> ////// [optional part] //////
>> *
>> * \author Author's Name <email at domain>
>> * \author Other Author's Name <another.email at domain>
>> ////// [end of optional part] //////
>> */
>> 
>> 
>> ---
>> Alex
>> 
>> 
>> 
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
> 
> 
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev




From jefft0 at remap.ucla.edu  Mon Apr  7 10:24:56 2014
From: jefft0 at remap.ucla.edu (Thompson, Jeff)
Date: Mon, 7 Apr 2014 17:24:56 +0000
Subject: [Nfd-dev] Private key for applications to sign a registration
	request
Message-ID: <CF682D9E.621F%jefft0@remap.ucla.edu>

Hello,

For an application to receive interests and produce content, it needs to send a signed interest to NRD to register the prefix. How does NRD trust the application's public key?  Is there a document that explains the trust procedure for an application to register a prefix to receive interests?

I see "" on the wiki, but don't see how NRD will trust the public key of the signed interest.
http://redmine.named-data.net/projects/nrd/wiki/NRD_Prefix_Registration_protocol

Thank you,
- Jeff T
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140407/2ffd5e1d/attachment.html>

From alexander.afanasyev at ucla.edu  Mon Apr  7 10:28:31 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Mon, 7 Apr 2014 10:28:31 -0700
Subject: [Nfd-dev] Plan for git repository management for the releases
Message-ID: <950CA245-DC6F-4AFF-975A-0436B50DE991@ucla.edu>

Hi guys,

Since we are getting closer for the first release (yeeee! congrats and thanks to everybody), here is the plan for git repository management:

- As soon as we fix the release commit, I will tag it as "nfd-0.1.0" tag.
- I will also create "v0.1" branch to track any urgent bugfixes for the first release.
- All development for the next version will continue in the master branch.

However, before we actually fix the release commit, there is a transition period that just started.  I have created "v0.2" branch in gerrit, and all v0.2-related code should be submitted there.  That is, use

    git push gerrit HEAD:refs/for/v0.2

instead of old command (HEAD:refs/for/master).
 
- After the release, I will merge v0.2 with master and it will become a new master branch.

---
Alex




From lanwang at memphis.edu  Mon Apr  7 11:53:51 2014
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Mon, 7 Apr 2014 18:53:51 +0000
Subject: [Nfd-dev] Private key for applications to sign a
	registration	request
In-Reply-To: <CF682D9E.621F%jefft0@remap.ucla.edu>
References: <CF682D9E.621F%jefft0@remap.ucla.edu>
Message-ID: <52D9B3DE-2461-417B-B46A-B563D48D67FC@memphis.edu>


On Apr 7, 2014, at 12:24 PM, "Thompson, Jeff" <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>> wrote:

Hello,

For an application to receive interests and produce content, it needs to send a signed interest to NRD to register the prefix. How does NRD trust the application's public key?  Is there a document that explains the trust procedure for an application to register a prefix to receive interests?

I see "" on the wiki, but don't see how NRD will trust the public key of the signed interest.
http://redmine.named-data.net/projects/nrd/wiki/NRD_Prefix_Registration_protocol

Yingdi implemented this part.  I think the default policy is to use a trust anchor and as long as the signing key can be verified through a hierarchy rooted at the trust anchor (using hierarchical checking) , then it will be trusted.  Of course, the policy may change in the future based on experience.

Here's the validator's configuration file for NRD:


rule
{
  id "NRD Prefix Registration Command Rule"
  for interest
  filter
  {
    type name
    regex ^<localhost><nrd>[<register><unregister><advertise><withdraw>]
  }
  checker
  {
    type customized
    sig-type rsa-sha256
    key-locator
    {
      type name
      regex ^[^<KEY>]*<KEY><>*<ksk-.*><ID-CERT>$
    }
  }
}
rule
{
  id "Testbed Hierarchy Rule"
  for data
  filter
  {
    type name
    regex ^[^<KEY>]*<KEY><>*<ksk-.*><ID-CERT><>$
  }
  checker
  {
    type hierarchical
    sig-type rsa-sha256
  }
}
trust-anchor
{
  type file
  file-name "testbed-trust-anchor.cert"
}


Lan

Thank you,
- Jeff T
_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto: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: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140407/7a5dfd7e/attachment.html>

From alexander.afanasyev at ucla.edu  Thu Apr 10 10:40:13 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Thu, 10 Apr 2014 10:40:13 -0700
Subject: [Nfd-dev] small change with NFD build
Message-ID: <E2CDF497-B83E-4325-AF43-F4113BC82AF9@ucla.edu>

Hi guys,

Just want to let you know that we changed a little bit default build flags (and build flags on jenkins build bots) to produce even more warnings.  In particular, we have enabled -std=c++03 and -pedantic flags which ensures that our code doesn't use any specific GCC extensions (and we have used them a little bit).

In any case.  All future NFD code should be at least based on http://gerrit.named-data.net/#/c/636/.  This commit fixes small issues we had with the code, otherwise jenkins builds will fail.

---
Alex




From jefft0 at remap.ucla.edu  Thu Apr 10 17:40:54 2014
From: jefft0 at remap.ucla.edu (Thompson, Jeff)
Date: Fri, 11 Apr 2014 00:40:54 +0000
Subject: [Nfd-dev] small change with NFD build
In-Reply-To: <E2CDF497-B83E-4325-AF43-F4113BC82AF9@ucla.edu>
References: <E2CDF497-B83E-4325-AF43-F4113BC82AF9@ucla.edu>
Message-ID: <CF6C8807.636D%jefft0@remap.ucla.edu>

In OS X 10.9, when I do "./waf configure" it says "library rt not found".
But NFD seems to compile and run OK.  Is library rt required?

On 4/10/14 10:40 AM, "Alex Afanasyev" <alexander.afanasyev at ucla.edu> wrote:

>Hi guys,
>
>Just want to let you know that we changed a little bit default build
>flags (and build flags on jenkins build bots) to produce even more
>warnings.  In particular, we have enabled -std=c++03 and -pedantic flags
>which ensures that our code doesn't use any specific GCC extensions (and
>we have used them a little bit).
>
>In any case.  All future NFD code should be at least based on
>http://gerrit.named-data.net/#/c/636/.  This commit fixes small issues we
>had with the code, otherwise jenkins builds will fail.
>
>---
>Alex
>
>
>_______________________________________________
>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  Thu Apr 10 17:43:01 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Thu, 10 Apr 2014 17:43:01 -0700
Subject: [Nfd-dev] small change with NFD build
In-Reply-To: <CF6C8807.636D%jefft0@remap.ucla.edu>
References: <E2CDF497-B83E-4325-AF43-F4113BC82AF9@ucla.edu>
	<CF6C8807.636D%jefft0@remap.ucla.edu>
Message-ID: <A02EFB2A-8179-4B91-BC33-5F17A7741F8C@ucla.edu>

It is required on some platforms (e.g., Linux).  The configure just telling that it is not found, but everything has succeeded.

---
Alex

On Apr 10, 2014, at 5:40 PM, Thompson, Jeff <jefft0 at remap.ucla.edu> wrote:

> In OS X 10.9, when I do "./waf configure" it says "library rt not found".
> But NFD seems to compile and run OK.  Is library rt required?
> 
> On 4/10/14 10:40 AM, "Alex Afanasyev" <alexander.afanasyev at ucla.edu> wrote:
> 
>> Hi guys,
>> 
>> Just want to let you know that we changed a little bit default build
>> flags (and build flags on jenkins build bots) to produce even more
>> warnings.  In particular, we have enabled -std=c++03 and -pedantic flags
>> which ensures that our code doesn't use any specific GCC extensions (and
>> we have used them a little bit).
>> 
>> In any case.  All future NFD code should be at least based on
>> http://gerrit.named-data.net/#/c/636/.  This commit fixes small issues we
>> had with the code, otherwise jenkins builds will fail.
>> 
>> ---
>> Alex
>> 
>> 
>> _______________________________________________
>> 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  Fri Apr 11 14:45:00 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Fri, 11 Apr 2014 14:45:00 -0700
Subject: [Nfd-dev] Opinion needed about logging in the  library
Message-ID: <22871845-F37C-4D22-887F-385B4B0B9F37@ucla.edu>

The ndn-cpp-dev library right now contains some semi-broken logging support (for internal library purposes).

The question I'm having is whether there is any value of fixing this logging or it would be better to just completely remove it?

---
Alex




From shijunxiao at email.arizona.edu  Fri Apr 11 14:49:58 2014
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Fri, 11 Apr 2014 14:49:58 -0700
Subject: [Nfd-dev] Opinion needed about logging in the library
In-Reply-To: <22871845-F37C-4D22-887F-385B4B0B9F37@ucla.edu>
References: <22871845-F37C-4D22-887F-385B4B0B9F37@ucla.edu>
Message-ID: <CAOFH+OY+reG01CM-H4LkLnmESvFEN3jQJxNc-ndSAfDREbmd_A@mail.gmail.com>

Dear folks

There is some value to have some logging in library. Logging is only needed
for library modules that act as client (eg. Face, nrd::Controller), and is
unnecessary in packet format operations and data structures.

Logs can be written to stderr. Whether to write logs can be configured in
client.conf.

Yours, Junxiao
On Apr 11, 2014 2:45 PM, "Alex Afanasyev" <alexander.afanasyev at ucla.edu>
wrote:

> The ndn-cpp-dev library right now contains some semi-broken logging
> support (for internal library purposes).
>
> The question I'm having is whether there is any value of fixing this
> logging or it would be better to just completely remove it?
>
> ---
> Alex
>
>
> _______________________________________________
> 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: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140411/cb43b0b2/attachment.html>

From alexander.afanasyev at ucla.edu  Fri Apr 11 14:58:00 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Fri, 11 Apr 2014 14:58:00 -0700
Subject: [Nfd-dev] Opinion needed about logging in the library
In-Reply-To: <CAOFH+OY+reG01CM-H4LkLnmESvFEN3jQJxNc-ndSAfDREbmd_A@mail.gmail.com>
References: <22871845-F37C-4D22-887F-385B4B0B9F37@ucla.edu>
	<CAOFH+OY+reG01CM-H4LkLnmESvFEN3jQJxNc-ndSAfDREbmd_A@mail.gmail.com>
Message-ID: <BFEC97EC-D2C2-45F6-989B-70D68C609A5C@ucla.edu>

Should it then be something similar to what we have in NFD?  Or more?

I thought of providing several options for logging frameworks (simple like in NFD, boost.log, log4cxx).  Since it is a library, the actual application may have a better idea what logging framework it needs...   Or is it too complex?

---
Alex

On Apr 11, 2014, at 2:49 PM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:

> Dear folks
> 
> There is some value to have some logging in library. Logging is only needed for library modules that act as client (eg. Face, nrd::Controller), and is unnecessary in packet format operations and data structures.
> 
> Logs can be written to stderr. Whether to write logs can be configured in client.conf.
> 
> Yours, Junxiao
> 
> On Apr 11, 2014 2:45 PM, "Alex Afanasyev" <alexander.afanasyev at ucla.edu> wrote:
> The ndn-cpp-dev library right now contains some semi-broken logging support (for internal library purposes).
> 
> The question I'm having is whether there is any value of fixing this logging or it would be better to just completely remove it?
> 
> ---
> Alex

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140411/83656599/attachment.html>

From jburke at remap.ucla.edu  Fri Apr 11 15:01:57 2014
From: jburke at remap.ucla.edu (Burke, Jeff)
Date: Fri, 11 Apr 2014 22:01:57 +0000
Subject: [Nfd-dev] Opinion needed about logging in the library
In-Reply-To: <BFEC97EC-D2C2-45F6-989B-70D68C609A5C@ucla.edu>
Message-ID: <CF6DB3B4.1357D1%jburke@remap.ucla.edu>


Junxiao,

We rely on the quite granular logs of ccnd/ndnd for debugging.  Could you clarify where logging will not be included and whether it is any different in concept than the behavior of ccnd/ndnd?   I am worried about unlogged errors in what you are calling "packet format operations" in particular..

Thanks,

Jeff


On Apr 11, 2014, at 2:49 PM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:


Dear folks

There is some value to have some logging in library. Logging is only needed for library modules that act as client (eg. Face, nrd::Controller), and is unnecessary in packet format operations and data structures.

Logs can be written to stderr. Whether to write logs can be configured in client.conf.

Yours, Junxiao

On Apr 11, 2014 2:45 PM, "Alex Afanasyev" <alexander.afanasyev at ucla.edu<mailto:alexander.afanasyev at ucla.edu>> wrote:
The ndn-cpp-dev library right now contains some semi-broken logging support (for internal library purposes).

The question I'm having is whether there is any value of fixing this logging or it would be better to just completely remove it?

---
Alex

_______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu<mailto: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: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140411/705b9d0f/attachment.html>

From alexander.afanasyev at ucla.edu  Fri Apr 11 15:04:07 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Fri, 11 Apr 2014 15:04:07 -0700
Subject: [Nfd-dev] Opinion needed about logging in the library
In-Reply-To: <CF6DB3B4.1357D1%jburke@remap.ucla.edu>
References: <CF6DB3B4.1357D1%jburke@remap.ucla.edu>
Message-ID: <86CB35B7-8E4C-4D16-A940-0F5FCBA7251E@ucla.edu>

We have a lot of high-granular loggings in NFD.  My question was just for the library.

---
Alex

On Apr 11, 2014, at 3:01 PM, Burke, Jeff <jburke at remap.ucla.edu> wrote:

> 
> Junxiao,
> 
> We rely on the quite granular logs of ccnd/ndnd for debugging.  Could you clarify where logging will not be included and whether it is any different in concept than the behavior of ccnd/ndnd?   I am worried about unlogged errors in what you are calling "packet format operations" in particular.. 
> 
> Thanks,
> 
> Jeff
> 
> 
> On Apr 11, 2014, at 2:49 PM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:
> 
>> Dear folks
>> There is some value to have some logging in library. Logging is only needed for library modules that act as client (eg. Face, nrd::Controller), and is unnecessary in packet format operations and data structures.
>> Logs can be written to stderr. Whether to write logs can be configured in client.conf.
>> Yours, Junxiao
>> On Apr 11, 2014 2:45 PM, "Alex Afanasyev" <alexander.afanasyev at ucla.edu> wrote:
>>> The ndn-cpp-dev library right now contains some semi-broken logging support (for internal library purposes).
>>> 
>>> The question I'm having is whether there is any value of fixing this logging or it would be better to just completely remove it?
>>> 
>>> ---
>>> Alex
> 
> _______________________________________________ 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: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140411/18440f07/attachment.html>

From yingdi at cs.ucla.edu  Fri Apr 11 15:13:01 2014
From: yingdi at cs.ucla.edu (Yingdi Yu)
Date: Fri, 11 Apr 2014 15:13:01 -0700
Subject: [Nfd-dev] Opinion needed about logging in the library
In-Reply-To: <CAOFH+OY+reG01CM-H4LkLnmESvFEN3jQJxNc-ndSAfDREbmd_A@mail.gmail.com>
References: <22871845-F37C-4D22-887F-385B4B0B9F37@ucla.edu>
	<CAOFH+OY+reG01CM-H4LkLnmESvFEN3jQJxNc-ndSAfDREbmd_A@mail.gmail.com>
Message-ID: <D24B0D65-F4FB-492D-A5E6-8C9CE0CF7EFD@cs.ucla.edu>

Just a quick question: What do we want to log for these 'client' modules? given we have logs at the other side (NFD or NRD)

Yingdi

On Apr 11, 2014, at 2:49 PM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:

> Dear folks
> 
> There is some value to have some logging in library. Logging is only needed for library modules that act as client (eg. Face, nrd::Controller), and is unnecessary in packet format operations and data structures.
> 
> Logs can be written to stderr. Whether to write logs can be configured in client.conf.
> 
> Yours, Junxiao
> 
> On Apr 11, 2014 2:45 PM, "Alex Afanasyev" <alexander.afanasyev at ucla.edu> wrote:
> The ndn-cpp-dev library right now contains some semi-broken logging support (for internal library purposes).
> 
> The question I'm having is whether there is any value of fixing this logging or it would be better to just completely remove it?
> 
> ---
> Alex
> 
> 
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

Best Regards,

Yingdi Yu
Ph.D. Student
Computer Science Department, UCLA
yingdi at cs.ucla.edu
irl.cs.ucla.edu/~yingdi/




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140411/3c27e2a2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140411/3c27e2a2/attachment.bin>

From davidepesa at gmail.com  Sun Apr 13 09:02:31 2014
From: davidepesa at gmail.com (Davide Pesavento)
Date: Sun, 13 Apr 2014 18:02:31 +0200
Subject: [Nfd-dev] Opinion needed about logging in the library
In-Reply-To: <22871845-F37C-4D22-887F-385B4B0B9F37@ucla.edu>
References: <22871845-F37C-4D22-887F-385B4B0B9F37@ucla.edu>
Message-ID: <CADfzvvZ0WgQc9K1K0cB1pMi7zb2HeyHY6WH6-ur7JD8We5NS3g@mail.gmail.com>

In my opinion, it could be useful to provide some log *sources* in the
library, i.e. statements that "emit" log messages, especially WARNs or
INFOs for exceptional cases that are part of the normal processing paths.

On the other hand the logging infrastructure should be kept simple and not
be over-engineered. Therefore the library should provide only a minimal set
of log *sinks*, possibly only a *null* logger (that swallows everything)
and a *stderr* logger (that writes everything to std::cerr or clog). All
log messages must eventually go through a message handler function. Then
the library users, i.e. other applications, can modify the logging behavior
by installing a custom handler. For example:

typedef void (*NdnMessageHandler)(enum LogLevel level, const std::string&
context, const std::string& msg);

static NdnMessageHandler g_msgHandler = stderrHandler; // default handler

NdnMessageHandler
installMessageHandler(NdnMessageHandler newHandler)
{
    NdnMessageHandler old = g_msgHandler;
    g_msgHandler = newHandler;
    return old;
}

This provides great flexibility while being very simple and lightweight.

Thanks,
Davide

On Fri, Apr 11, 2014 at 11:45 PM, Alex Afanasyev <
alexander.afanasyev at ucla.edu> wrote:
> The ndn-cpp-dev library right now contains some semi-broken logging
support (for internal library purposes).
>
> The question I'm having is whether there is any value of fixing this
logging or it would be better to just completely remove it?
>
> ---
> Alex
>
>
> _______________________________________________
> 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: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140413/ba565f1d/attachment.html>

From jefft0 at remap.ucla.edu  Fri Apr 18 11:51:38 2014
From: jefft0 at remap.ucla.edu (Thompson, Jeff)
Date: Fri, 18 Apr 2014 18:51:38 +0000
Subject: [Nfd-dev] Interest lifetime for NFD command interests
Message-ID: <CF76C28D.6543%jefft0@remap.ucla.edu>

For a command interest to NFD/NRD, is there a recommended InterestLifetime (used as a timeout)?  Since it goes to the local host, can it safely be shorter than 4000 milliseconds?

Thank you,
- Jeff T
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140418/35553d64/attachment.html>

From alexander.afanasyev at ucla.edu  Fri Apr 18 13:28:45 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Fri, 18 Apr 2014 13:28:45 -0700
Subject: [Nfd-dev] Notice about library renaming
Message-ID: <0CA306F9-9768-417D-8089-CE97D2E7E15F@ucla.edu>

Hi everybody,

Some of you already aware that we are planning to rename ndn-cpp-dev library.  If there are no objections within 24hours, I will proceed with the renaming.   Here is the plan:

* new name: "OpenNDN" 
* folder name for include files: open-ndn
* static library name: libOpenNDN.a
* dynamic library name (when it will be enabled): libOpenNDN.so|dylib
* pkg-config name: libOpenNDN.pc
* no namespace change: we will still use "ndn" as a basic namespace for the library
* official github repository will change to: https://github.com/named-data/OpenNDN
* redmine will change to http://redmine.named-data.net/projects/openndn
* gerrit project name will be changed to OpenNDN (http://gerrit.named-data.net/#/admin/projects/OpenNDN)

We will try to do the change with a transition period, when existing application will still be able to compile against OpenNDN (there will be additional symlinks created for include, lib, and pkg-config files), but all known applications needs to be updated ASAP after the renaming is complete in the following way:

* all includes should be changed from <ndn-cpp-dev/...> to <open-ndn/...>
* documentation files/comments referring to ndn-cpp-dev should be updated and refer to OpenNDN and (if any) new links
* if the app uses pkg-config for dependency detection, 'libndn-cpp-dev' should be replaced with 'libOpenNDN'.  For waf users:

    conf.check_cfg(package = 'libOpenNDN', args = ['--cflags', '--libs'],
                   uselib_store = 'OPEN_NDN', mandatory = True)

(If updating `uselib_store` variable, don't forget to update all uses of it in bld() blocks.)


I will put this note into the library documentation after the rename.

---
Alex


From jburke at remap.ucla.edu  Fri Apr 18 13:34:36 2014
From: jburke at remap.ucla.edu (Burke, Jeff)
Date: Fri, 18 Apr 2014 20:34:36 +0000
Subject: [Nfd-dev] Notice about library renaming
In-Reply-To: <0CA306F9-9768-417D-8089-CE97D2E7E15F@ucla.edu>
Message-ID: <CF76D946.138753%jburke@remap.ucla.edu>


Alex,

As I've previously mentioned "OpenNDN" isn't particularly descriptive of
the library, and I think is going to lead to a lot of confusion outside.
(It doesn't fix the confusion that arose from calling it ndn-cpp-dev.)

It also seems to set up two parallel library efforts without
distinguishing between the goals.  What are the goals of OpenNDN?  What
makes it Open?  Is the other library Closed?  etc. etc.

I'm really sorry that I haven't been able to make another constructive
suggestion over the course of this week but I would really like to advise
against rushing this change.

One thought: 

This library was forked originally to support NFD.  Why not rename it to
libnfd, which is descriptive of what it actually does right now?  This
will need to stay somewhat stable in support of NFD/NRD development,
security library work, etc.

Then, create a separate fork of libnfd with a more general name that
relates to the approach/intent of the library.  If the approach / intent
is not clear, then perhaps a little time should be dedicated to deciding
what the purpose / vision for this particular codebase is?

cheers,
Jeff



On 4/18/14, 1:28 PM, "Alex Afanasyev" <alexander.afanasyev at ucla.edu> wrote:

>Hi everybody,
>
>Some of you already aware that we are planning to rename ndn-cpp-dev
>library.  If there are no objections within 24hours, I will proceed with
>the renaming.   Here is the plan:
>
>* new name: "OpenNDN"
>* folder name for include files: open-ndn
>* static library name: libOpenNDN.a
>* dynamic library name (when it will be enabled): libOpenNDN.so|dylib
>* pkg-config name: libOpenNDN.pc
>* no namespace change: we will still use "ndn" as a basic namespace for
>the library
>* official github repository will change to:
>https://github.com/named-data/OpenNDN
>* redmine will change to http://redmine.named-data.net/projects/openndn
>* gerrit project name will be changed to OpenNDN
>(http://gerrit.named-data.net/#/admin/projects/OpenNDN)
>
>We will try to do the change with a transition period, when existing
>application will still be able to compile against OpenNDN (there will be
>additional symlinks created for include, lib, and pkg-config files), but
>all known applications needs to be updated ASAP after the renaming is
>complete in the following way:
>
>* all includes should be changed from <ndn-cpp-dev/...> to <open-ndn/...>
>* documentation files/comments referring to ndn-cpp-dev should be updated
>and refer to OpenNDN and (if any) new links
>* if the app uses pkg-config for dependency detection, 'libndn-cpp-dev'
>should be replaced with 'libOpenNDN'.  For waf users:
>
>    conf.check_cfg(package = 'libOpenNDN', args = ['--cflags', '--libs'],
>                   uselib_store = 'OPEN_NDN', mandatory = True)
>
>(If updating `uselib_store` variable, don't forget to update all uses of
>it in bld() blocks.)
>
>
>I will put this note into the library documentation after the rename.
>
>---
>Alex
>_______________________________________________
>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  Fri Apr 18 13:39:05 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Fri, 18 Apr 2014 13:39:05 -0700
Subject: [Nfd-dev] Notice about library renaming
In-Reply-To: <CF76D946.138753%jburke@remap.ucla.edu>
References: <CF76D946.138753%jburke@remap.ucla.edu>
Message-ID: <85AD5FEA-7035-4A17-935F-78AF9331C4E2@ucla.edu>


On Apr 18, 2014, at 1:34 PM, Burke, Jeff <jburke at remap.ucla.edu> wrote:

> 
> Alex,
> 
> As I've previously mentioned "OpenNDN" isn't particularly descriptive of
> the library, and I think is going to lead to a lot of confusion outside.
> (It doesn't fix the confusion that arose from calling it ndn-cpp-dev.)
> 
> It also seems to set up two parallel library efforts without
> distinguishing between the goals.  What are the goals of OpenNDN?  What
> makes it Open?  Is the other library Closed?  etc. etc.
> 
> I'm really sorry that I haven't been able to make another constructive
> suggestion over the course of this week but I would really like to advise
> against rushing this change.
> 
> One thought: 
> 
> This library was forked originally to support NFD.  Why not rename it to
> libnfd, which is descriptive of what it actually does right now?  This
> will need to stay somewhat stable in support of NFD/NRD development,
> security library work, etc.

Just a quick comment before others comment.

I have never thought of this fork to be of specifically to support NFD.  I will not agree on having nfd in the name, as it is not the distinction or the difference.

---
Alex

> Then, create a separate fork of libnfd with a more general name that
> relates to the approach/intent of the library.  If the approach / intent
> is not clear, then perhaps a little time should be dedicated to deciding
> what the purpose / vision for this particular codebase is?
> 
> cheers,
> Jeff
> 
> 
> 
> On 4/18/14, 1:28 PM, "Alex Afanasyev" <alexander.afanasyev at ucla.edu> wrote:
> 
>> Hi everybody,
>> 
>> Some of you already aware that we are planning to rename ndn-cpp-dev
>> library.  If there are no objections within 24hours, I will proceed with
>> the renaming.   Here is the plan:
>> 
>> * new name: "OpenNDN"
>> * folder name for include files: open-ndn
>> * static library name: libOpenNDN.a
>> * dynamic library name (when it will be enabled): libOpenNDN.so|dylib
>> * pkg-config name: libOpenNDN.pc
>> * no namespace change: we will still use "ndn" as a basic namespace for
>> the library
>> * official github repository will change to:
>> https://github.com/named-data/OpenNDN
>> * redmine will change to http://redmine.named-data.net/projects/openndn
>> * gerrit project name will be changed to OpenNDN
>> (http://gerrit.named-data.net/#/admin/projects/OpenNDN)
>> 
>> We will try to do the change with a transition period, when existing
>> application will still be able to compile against OpenNDN (there will be
>> additional symlinks created for include, lib, and pkg-config files), but
>> all known applications needs to be updated ASAP after the renaming is
>> complete in the following way:
>> 
>> * all includes should be changed from <ndn-cpp-dev/...> to <open-ndn/...>
>> * documentation files/comments referring to ndn-cpp-dev should be updated
>> and refer to OpenNDN and (if any) new links
>> * if the app uses pkg-config for dependency detection, 'libndn-cpp-dev'
>> should be replaced with 'libOpenNDN'.  For waf users:
>> 
>>   conf.check_cfg(package = 'libOpenNDN', args = ['--cflags', '--libs'],
>>                  uselib_store = 'OPEN_NDN', mandatory = True)
>> 
>> (If updating `uselib_store` variable, don't forget to update all uses of
>> it in bld() blocks.)
>> 
>> 
>> I will put this note into the library documentation after the rename.
>> 
>> ---
>> Alex
>> _______________________________________________
>> 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  Fri Apr 18 13:40:02 2014
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Fri, 18 Apr 2014 13:40:02 -0700
Subject: [Nfd-dev] Notice about library renaming
In-Reply-To: <0CA306F9-9768-417D-8089-CE97D2E7E15F@ucla.edu>
References: <0CA306F9-9768-417D-8089-CE97D2E7E15F@ucla.edu>
Message-ID: <CAOFH+OZsWLLJrO+e09kRPaj127BYf50XnqCP5RJncTCx068xSg@mail.gmail.com>

Hi Alex

I suggest using lower case "openndn" without hyphen for file names. This is
more common among other libraries (eg openssh).

#include <openndn/face.hpp>
libopenndn.a
libopenndn.so
libopenndn.pc

Yours, Junxiao
On Apr 18, 2014 1:29 PM, "Alex Afanasyev" <alexander.afanasyev at ucla.edu>
wrote:

> Hi everybody,
>
> Some of you already aware that we are planning to rename ndn-cpp-dev
> library.  If there are no objections within 24hours, I will proceed with
> the renaming.   Here is the plan:
>
> * new name: "OpenNDN"
> * folder name for include files: open-ndn
> * static library name: libOpenNDN.a
> * dynamic library name (when it will be enabled): libOpenNDN.so|dylib
> * pkg-config name: libOpenNDN.pc
> * no namespace change: we will still use "ndn" as a basic namespace for
> the library
> * official github repository will change to:
> https://github.com/named-data/OpenNDN
> * redmine will change to http://redmine.named-data.net/projects/openndn
> * gerrit project name will be changed to OpenNDN (
> http://gerrit.named-data.net/#/admin/projects/OpenNDN)
>
> We will try to do the change with a transition period, when existing
> application will still be able to compile against OpenNDN (there will be
> additional symlinks created for include, lib, and pkg-config files), but
> all known applications needs to be updated ASAP after the renaming is
> complete in the following way:
>
> * all includes should be changed from <ndn-cpp-dev/...> to <open-ndn/...>
> * documentation files/comments referring to ndn-cpp-dev should be updated
> and refer to OpenNDN and (if any) new links
> * if the app uses pkg-config for dependency detection, 'libndn-cpp-dev'
> should be replaced with 'libOpenNDN'.  For waf users:
>
>     conf.check_cfg(package = 'libOpenNDN', args = ['--cflags', '--libs'],
>                    uselib_store = 'OPEN_NDN', mandatory = True)
>
> (If updating `uselib_store` variable, don't forget to update all uses of
> it in bld() blocks.)
>
>
> I will put this note into the library documentation after the rename.
>
> ---
> Alex
> _______________________________________________
> 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: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140418/87a0464e/attachment.html>

From jburke at remap.ucla.edu  Fri Apr 18 13:40:18 2014
From: jburke at remap.ucla.edu (Burke, Jeff)
Date: Fri, 18 Apr 2014 20:40:18 +0000
Subject: [Nfd-dev] Notice about library renaming
In-Reply-To: <CF76D946.138753%jburke@remap.ucla.edu>
Message-ID: <CF76DB4C.138788%jburke@remap.ucla.edu>


What I meant by the last paragraph was to have a more quickly changing,
less nfd related library, that IRL works with for applications that you
feel aren't a good fit for NDN-CCL and also don't need to be bound to
something that needs to evolve more slowly for nfd.


But the most important question in picking the name seems to be what also
is the goal for the library...

Jeff

On 4/18/14, 1:34 PM, "Burke, Jeff" <jburke at remap.ucla.edu> wrote:

>
>Alex,
>
>As I've previously mentioned "OpenNDN" isn't particularly descriptive of
>the library, and I think is going to lead to a lot of confusion outside.
>(It doesn't fix the confusion that arose from calling it ndn-cpp-dev.)
>
>It also seems to set up two parallel library efforts without
>distinguishing between the goals.  What are the goals of OpenNDN?  What
>makes it Open?  Is the other library Closed?  etc. etc.
>
>I'm really sorry that I haven't been able to make another constructive
>suggestion over the course of this week but I would really like to advise
>against rushing this change.
>
>One thought: 
>
>This library was forked originally to support NFD.  Why not rename it to
>libnfd, which is descriptive of what it actually does right now?  This
>will need to stay somewhat stable in support of NFD/NRD development,
>security library work, etc.
>
>Then, create a separate fork of libnfd with a more general name that
>relates to the approach/intent of the library.  If the approach / intent
>is not clear, then perhaps a little time should be dedicated to deciding
>what the purpose / vision for this particular codebase is?
>
>cheers,
>Jeff
>
>
>
>On 4/18/14, 1:28 PM, "Alex Afanasyev" <alexander.afanasyev at ucla.edu>
>wrote:
>
>>Hi everybody,
>>
>>Some of you already aware that we are planning to rename ndn-cpp-dev
>>library.  If there are no objections within 24hours, I will proceed with
>>the renaming.   Here is the plan:
>>
>>* new name: "OpenNDN"
>>* folder name for include files: open-ndn
>>* static library name: libOpenNDN.a
>>* dynamic library name (when it will be enabled): libOpenNDN.so|dylib
>>* pkg-config name: libOpenNDN.pc
>>* no namespace change: we will still use "ndn" as a basic namespace for
>>the library
>>* official github repository will change to:
>>https://github.com/named-data/OpenNDN
>>* redmine will change to http://redmine.named-data.net/projects/openndn
>>* gerrit project name will be changed to OpenNDN
>>(http://gerrit.named-data.net/#/admin/projects/OpenNDN)
>>
>>We will try to do the change with a transition period, when existing
>>application will still be able to compile against OpenNDN (there will be
>>additional symlinks created for include, lib, and pkg-config files), but
>>all known applications needs to be updated ASAP after the renaming is
>>complete in the following way:
>>
>>* all includes should be changed from <ndn-cpp-dev/...> to <open-ndn/...>
>>* documentation files/comments referring to ndn-cpp-dev should be updated
>>and refer to OpenNDN and (if any) new links
>>* if the app uses pkg-config for dependency detection, 'libndn-cpp-dev'
>>should be replaced with 'libOpenNDN'.  For waf users:
>>
>>    conf.check_cfg(package = 'libOpenNDN', args = ['--cflags', '--libs'],
>>                   uselib_store = 'OPEN_NDN', mandatory = True)
>>
>>(If updating `uselib_store` variable, don't forget to update all uses of
>>it in bld() blocks.)
>>
>>
>>I will put this note into the library documentation after the rename.
>>
>>---
>>Alex
>>_______________________________________________
>>Nfd-dev mailing list
>>Nfd-dev at lists.cs.ucla.edu
>>http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>
>_______________________________________________
>Nfd-dev mailing list
>Nfd-dev at lists.cs.ucla.edu
>http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev




From jburke at remap.ucla.edu  Fri Apr 18 13:51:02 2014
From: jburke at remap.ucla.edu (Burke, Jeff)
Date: Fri, 18 Apr 2014 20:51:02 +0000
Subject: [Nfd-dev] Notice about library renaming
In-Reply-To: <85AD5FEA-7035-4A17-935F-78AF9331C4E2@ucla.edu>
Message-ID: <CF76DDE3.1387C5%jburke@remap.ucla.edu>


>
>I have never thought of this fork to be of specifically to support NFD.
>I will not agree on having nfd in the name, as it is not the distinction
>or the difference.


That makes sense to me - but what is the distinction/difference?

This is where I am getting stuck right now; I'm not sure that I know the
codebase well enough to answer that.

Jeff
 




From alexander.afanasyev at ucla.edu  Fri Apr 18 14:10:16 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Fri, 18 Apr 2014 14:10:16 -0700
Subject: [Nfd-dev] Interest lifetime for NFD command interests
In-Reply-To: <CF76C28D.6543%jefft0@remap.ucla.edu>
References: <CF76C28D.6543%jefft0@remap.ucla.edu>
Message-ID: <6B97D471-432E-4FC8-81A5-FD07CB739866@ucla.edu>

Hi Jeff,

I agree completely with this for prefix registration commands.  I would say, there is no much value/reason to make the lifetime longer than, say, a second.  Could be shorter, but on some extremely busy systems (like our Jenkins slave), even a simple registration may take some time.

For face creation, lifetime should be longer that 4 seconds since it can take some time to create some tunnels (e.g., TCP).  We even have a redmine issue for that (http://redmine.named-data.net/issues/1455)

---
Alex

On Apr 18, 2014, at 11:51 AM, Thompson, Jeff <jefft0 at remap.ucla.edu> wrote:

> For a command interest to NFD/NRD, is there a recommended InterestLifetime (used as a timeout)?  Since it goes to the local host, can it safely be shorter than 4000 milliseconds?
> 
> Thank you,
> - Jeff T
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140418/2f697b98/attachment.html>

From alexander.afanasyev at ucla.edu  Fri Apr 18 16:05:47 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Fri, 18 Apr 2014 16:05:47 -0700
Subject: [Nfd-dev] New ubuntu release
Message-ID: <79510E52-EDDA-498B-9EDF-3AA22BBAEE7F@ucla.edu>

Just to let you know that Ubuntu has made a new release yesterday, 14.04 LTS (Trusty Tahr) https://wiki.ubuntu.com/Releases

I'm guessing that we will have to add it to our supported platforms (I'm hoping there will be no problems, but who knows).

---
Alex




From davidepesa at gmail.com  Fri Apr 18 16:38:09 2014
From: davidepesa at gmail.com (Davide Pesavento)
Date: Sat, 19 Apr 2014 01:38:09 +0200
Subject: [Nfd-dev] Notice about library renaming
In-Reply-To: <CAOFH+OZsWLLJrO+e09kRPaj127BYf50XnqCP5RJncTCx068xSg@mail.gmail.com>
References: <0CA306F9-9768-417D-8089-CE97D2E7E15F@ucla.edu>
	<CAOFH+OZsWLLJrO+e09kRPaj127BYf50XnqCP5RJncTCx068xSg@mail.gmail.com>
Message-ID: <CADfzvvbU=nP8sDKgG9EoZkZ+PPWYUsrHqPAKjO+tbmz_p-rZ_w@mail.gmail.com>

On Fri, Apr 18, 2014 at 10:40 PM, Junxiao Shi
<shijunxiao at email.arizona.edu> wrote:
> Hi Alex
>
> I suggest using lower case "openndn" without hyphen for file names. This is
> more common among other libraries (eg openssh).
>

Except that openssh isn't a library...


From davidepesa at gmail.com  Fri Apr 18 16:44:53 2014
From: davidepesa at gmail.com (Davide Pesavento)
Date: Sat, 19 Apr 2014 01:44:53 +0200
Subject: [Nfd-dev] Notice about library renaming
In-Reply-To: <CF76DDE3.1387C5%jburke@remap.ucla.edu>
References: <85AD5FEA-7035-4A17-935F-78AF9331C4E2@ucla.edu>
	<CF76DDE3.1387C5%jburke@remap.ucla.edu>
Message-ID: <CADfzvvauSyTWL7MAhMxTWczTPP_L49WzrKxb0o8QNFSvTpzYiQ@mail.gmail.com>

On Fri, Apr 18, 2014 at 10:51 PM, Burke, Jeff <jburke at remap.ucla.edu> wrote:
>
>>
>>I have never thought of this fork to be of specifically to support NFD.
>>I will not agree on having nfd in the name, as it is not the distinction
>>or the difference.
>
>
> That makes sense to me - but what is the distinction/difference?
>
> This is where I am getting stuck right now; I'm not sure that I know the
> codebase well enough to answer that.
>

I have the same question. What's the difference? What was/were the
reason(s) for the fork? I'm confused.


From shijunxiao at email.arizona.edu  Fri Apr 18 17:38:45 2014
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Fri, 18 Apr 2014 17:38:45 -0700
Subject: [Nfd-dev] New ubuntu release
In-Reply-To: <79510E52-EDDA-498B-9EDF-3AA22BBAEE7F@ucla.edu>
References: <79510E52-EDDA-498B-9EDF-3AA22BBAEE7F@ucla.edu>
Message-ID: <CAOFH+OZ9cfsTomTdC4DpFi0124cLCzLEWAwTka-PPQCOZuPm3w@mail.gmail.com>

Dear folks

I will create a UbuntuTrusty VMAPI image in the next 2 days.
We can have Jenkins slave after that.

NDN Platform is required to support Ubuntu 12.04 and "latest Ubuntu" only.
http://named-data.net/codebase/platform/documentation/ndn-platform-development-guidelines/#Build_support
This means support for Ubuntu 13.10 can be dropped at any time.

Yours, Junxiao


On Fri, Apr 18, 2014 at 4:05 PM, Alex Afanasyev <
alexander.afanasyev at ucla.edu> wrote:

> Just to let you know that Ubuntu has made a new release yesterday, 14.04
> LTS (Trusty Tahr) https://wiki.ubuntu.com/Releases
>
> I'm guessing that we will have to add it to our supported platforms (I'm
> hoping there will be no problems, but who knows).
>
> ---
> Alex
>
>
> _______________________________________________
> 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: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140418/c61054fa/attachment.html>

From alexander.afanasyev at ucla.edu  Mon Apr 21 13:32:25 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Mon, 21 Apr 2014 13:32:25 -0700
Subject: [Nfd-dev] v0.2 branch rebased
Message-ID: <E8C371FC-2804-48CD-BDD3-3F011B1F6DDF@ucla.edu>

Just a quick note that I did a forced update of v0.2 branch.  I have rebased the current code (privilege dropping) on top of the current gerrit/master and resolved few conflicts.

I will go ahead in submitting other v0.2 code to this branch (first one will be "nfd-status --xml" commit).

---
Alex


From alexander.afanasyev at ucla.edu  Wed Apr 23 16:02:50 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Wed, 23 Apr 2014 16:02:50 -0700
Subject: [Nfd-dev] Revised plan for library renaming
In-Reply-To: <CAOFH+OZsWLLJrO+e09kRPaj127BYf50XnqCP5RJncTCx068xSg@mail.gmail.com>
References: <0CA306F9-9768-417D-8089-CE97D2E7E15F@ucla.edu>
	<CAOFH+OZsWLLJrO+e09kRPaj127BYf50XnqCP5RJncTCx068xSg@mail.gmail.com>
Message-ID: <1618E4E5-CCC0-4632-A695-8034EACDF397@ucla.edu>

Hi guys,

Here is the revised plan for the library renaming.  Similar to the last time, I will wait for comments 24 hours before starting work on the renaming.

* new name: "ndn-cxx"
* full name: "NDN C++ library with eXperimental eXtensions"
* version: reset to 0.1 for the initial release
* folder name for include files: ndn-cxx
* static library name: libndn-cxx.a
* dynamic library name (when it will be enabled): libndn-cxx.so|dylib
* pkg-config name: libndn-cxx.pc
* no namespace change: we will still use "ndn" as a basic namespace for the library
* official github repository will change to: https://github.com/named-data/ndn-cxx  (the old one will be redirecting to a new location)
* redmine will change to http://redmine.named-data.net/projects/ndn-cxx (the old one will not work)
* gerrit project name will be changed to ndn-cxx: http://gerrit.named-data.net/#/admin/projects/ndn-cxx (the old one will not work)
* official documentation page: http://www.named-data.net/doc/ndn-cxx/<version>

We will try to do the change with a transition period, when existing application will still be able to compile against ndn-cxx (there will be additional symlinks created for include, lib, and pkg-config files), but all known applications needs to be updated ASAP after the renaming is complete in the following way:

* all includes should be changed from <ndn-cpp-dev/...> to <ndn-cxx/...>
* documentation files/comments referring to ndn-cpp-dev should be updated and refer to ndn-cxx and (if any) to new links
* if the app uses pkg-config for dependency detection, 'libndn-cpp-dev' should be replaced with 'libndn-cxx'.  For waf users:

   conf.check_cfg(package = 'libndn-cxx', args = ['--cflags', '--libs'],
                  uselib_store = 'NDN_CXX', mandatory = True)

(If updating `uselib_store` variable, don't forget to update all uses of it in bld() blocks.)

---
Alex




From davidepesa at gmail.com  Wed Apr 23 16:53:28 2014
From: davidepesa at gmail.com (Davide Pesavento)
Date: Thu, 24 Apr 2014 01:53:28 +0200
Subject: [Nfd-dev] Revised plan for library renaming
In-Reply-To: <1618E4E5-CCC0-4632-A695-8034EACDF397@ucla.edu>
References: <0CA306F9-9768-417D-8089-CE97D2E7E15F@ucla.edu>
	<CAOFH+OZsWLLJrO+e09kRPaj127BYf50XnqCP5RJncTCx068xSg@mail.gmail.com>
	<1618E4E5-CCC0-4632-A695-8034EACDF397@ucla.edu>
Message-ID: <CADfzvvZ5HRKYiAYFzp8-4G=Z9w_Ef-FMigEQypWra1wH4fgjpA@mail.gmail.com>

On Thu, Apr 24, 2014 at 1:02 AM, Alex Afanasyev
<alexander.afanasyev at ucla.edu> wrote:
> We will try to do the change with a transition period, when existing application will still be able to compile against ndn-cxx (there will be additional symlinks created for include, lib, and pkg-config files), but all known applications needs to be updated ASAP after the renaming is complete in the following way:
>

Are you going to release the first version with the compatibility symlinks?



From alexander.afanasyev at ucla.edu  Wed Apr 23 16:55:53 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Wed, 23 Apr 2014 16:55:53 -0700
Subject: [Nfd-dev] Revised plan for library renaming
In-Reply-To: <CADfzvvZ5HRKYiAYFzp8-4G=Z9w_Ef-FMigEQypWra1wH4fgjpA@mail.gmail.com>
References: <0CA306F9-9768-417D-8089-CE97D2E7E15F@ucla.edu>
	<CAOFH+OZsWLLJrO+e09kRPaj127BYf50XnqCP5RJncTCx068xSg@mail.gmail.com>
	<1618E4E5-CCC0-4632-A695-8034EACDF397@ucla.edu>
	<CADfzvvZ5HRKYiAYFzp8-4G=Z9w_Ef-FMigEQypWra1wH4fgjpA@mail.gmail.com>
Message-ID: <CADF3FB1-FFF7-4229-9115-917F336C5D5B@ucla.edu>


On Apr 23, 2014, at 4:53 PM, Davide Pesavento <davidepesa at gmail.com> wrote:

> On Thu, Apr 24, 2014 at 1:02 AM, Alex Afanasyev
> <alexander.afanasyev at ucla.edu> wrote:
>> We will try to do the change with a transition period, when existing application will still be able to compile against ndn-cxx (there will be additional symlinks created for include, lib, and pkg-config files), but all known applications needs to be updated ASAP after the renaming is complete in the following way:
>> 
> 
> Are you going to release the first version with the compatibility symlinks?

Honestly, not sure about this and we shall make a decision.  If we can quickly update all applications (NFD, repo, NLSR, ping, others?), then this will not go into the release.  Personally, I prefer not to add symlinks in the initial release.

---
Alex




From davidepesa at gmail.com  Wed Apr 23 17:04:43 2014
From: davidepesa at gmail.com (Davide Pesavento)
Date: Thu, 24 Apr 2014 02:04:43 +0200
Subject: [Nfd-dev] Revised plan for library renaming
In-Reply-To: <CADF3FB1-FFF7-4229-9115-917F336C5D5B@ucla.edu>
References: <0CA306F9-9768-417D-8089-CE97D2E7E15F@ucla.edu>
	<CAOFH+OZsWLLJrO+e09kRPaj127BYf50XnqCP5RJncTCx068xSg@mail.gmail.com>
	<1618E4E5-CCC0-4632-A695-8034EACDF397@ucla.edu>
	<CADfzvvZ5HRKYiAYFzp8-4G=Z9w_Ef-FMigEQypWra1wH4fgjpA@mail.gmail.com>
	<CADF3FB1-FFF7-4229-9115-917F336C5D5B@ucla.edu>
Message-ID: <CADfzvvZs5FdrQJSpdkqOmWmE8zh0O6N_7gHVVFZ1pcAF07186g@mail.gmail.com>

On Thu, Apr 24, 2014 at 1:55 AM, Alex Afanasyev
<alexander.afanasyev at ucla.edu> wrote:
>
> On Apr 23, 2014, at 4:53 PM, Davide Pesavento <davidepesa at gmail.com> wrote:
>
>> On Thu, Apr 24, 2014 at 1:02 AM, Alex Afanasyev
>> <alexander.afanasyev at ucla.edu> wrote:
>>> We will try to do the change with a transition period, when existing application will still be able to compile against ndn-cxx (there will be additional symlinks created for include, lib, and pkg-config files), but all known applications needs to be updated ASAP after the renaming is complete in the following way:
>>>
>>
>> Are you going to release the first version with the compatibility symlinks?
>
> Honestly, not sure about this and we shall make a decision.  If we can quickly update all applications (NFD, repo, NLSR, ping, others?), then this will not go into the release.  Personally, I prefer not to add symlinks in the initial release.
>

Agreed, but it also depends on the available timeframe. Aren't we
already late with the first release?

Instead of adding symlinks, we could freeze the current ndn-cpp-dev
codebase and keep the github repo and docs so that people can still
fetch and build the old library. After a while the docs are removed
and the ndn-cpp-dev repo is changed to redirect to ndn-cxx. How does
that sound?



From alexander.afanasyev at ucla.edu  Wed Apr 23 18:23:09 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Wed, 23 Apr 2014 18:23:09 -0700
Subject: [Nfd-dev] Revised plan for library renaming
In-Reply-To: <CADfzvvZs5FdrQJSpdkqOmWmE8zh0O6N_7gHVVFZ1pcAF07186g@mail.gmail.com>
References: <0CA306F9-9768-417D-8089-CE97D2E7E15F@ucla.edu>
	<CAOFH+OZsWLLJrO+e09kRPaj127BYf50XnqCP5RJncTCx068xSg@mail.gmail.com>
	<1618E4E5-CCC0-4632-A695-8034EACDF397@ucla.edu>
	<CADfzvvZ5HRKYiAYFzp8-4G=Z9w_Ef-FMigEQypWra1wH4fgjpA@mail.gmail.com>
	<CADF3FB1-FFF7-4229-9115-917F336C5D5B@ucla.edu>
	<CADfzvvZs5FdrQJSpdkqOmWmE8zh0O6N_7gHVVFZ1pcAF07186g@mail.gmail.com>
Message-ID: <BBB560B3-7F81-4BC4-8B89-6AF4307069E0@ucla.edu>


On Apr 23, 2014, at 5:04 PM, Davide Pesavento <davidepesa at gmail.com> wrote:

> On Thu, Apr 24, 2014 at 1:55 AM, Alex Afanasyev
> <alexander.afanasyev at ucla.edu> wrote:
>> 
>> On Apr 23, 2014, at 4:53 PM, Davide Pesavento <davidepesa at gmail.com> wrote:
>> 
>>> On Thu, Apr 24, 2014 at 1:02 AM, Alex Afanasyev
>>> <alexander.afanasyev at ucla.edu> wrote:
>>>> We will try to do the change with a transition period, when existing application will still be able to compile against ndn-cxx (there will be additional symlinks created for include, lib, and pkg-config files), but all known applications needs to be updated ASAP after the renaming is complete in the following way:
>>>> 
>>> 
>>> Are you going to release the first version with the compatibility symlinks?
>> 
>> Honestly, not sure about this and we shall make a decision.  If we can quickly update all applications (NFD, repo, NLSR, ping, others?), then this will not go into the release.  Personally, I prefer not to add symlinks in the initial release.
>> 
> 
> Agreed, but it also depends on the available timeframe. Aren't we
> already late with the first release?
> 
> Instead of adding symlinks, we could freeze the current ndn-cpp-dev
> codebase and keep the github repo and docs so that people can still
> fetch and build the old library. After a while the docs are removed
> and the ndn-cpp-dev repo is changed to redirect to ndn-cxx. How does
> that sound?

This sounds good to me.  I can also update README.md file for ndn-cpp-dev repo, stating that this library has been renamed and development continues under different name + add the link.  After a month or so, we can remove it completely.

---
Alex




From bzhang at cs.arizona.edu  Wed Apr 23 21:34:03 2014
From: bzhang at cs.arizona.edu (Beichuan Zhang)
Date: Wed, 23 Apr 2014 21:34:03 -0700
Subject: [Nfd-dev] Revised plan for library renaming
In-Reply-To: <BBB560B3-7F81-4BC4-8B89-6AF4307069E0@ucla.edu>
References: <0CA306F9-9768-417D-8089-CE97D2E7E15F@ucla.edu>
	<CAOFH+OZsWLLJrO+e09kRPaj127BYf50XnqCP5RJncTCx068xSg@mail.gmail.com>
	<1618E4E5-CCC0-4632-A695-8034EACDF397@ucla.edu>
	<CADfzvvZ5HRKYiAYFzp8-4G=Z9w_Ef-FMigEQypWra1wH4fgjpA@mail.gmail.com>
	<CADF3FB1-FFF7-4229-9115-917F336C5D5B@ucla.edu>
	<CADfzvvZs5FdrQJSpdkqOmWmE8zh0O6N_7gHVVFZ1pcAF07186g@mail.gmail.com>
	<BBB560B3-7F81-4BC4-8B89-6AF4307069E0@ucla.edu>
Message-ID: <4519109C-6873-4230-9DF3-6F3030F22BB9@cs.arizona.edu>


On Apr 23, 2014, at 6:23 PM, Alex Afanasyev <alexander.afanasyev at ucla.edu> wrote:

> 
> On Apr 23, 2014, at 5:04 PM, Davide Pesavento <davidepesa at gmail.com> wrote:
> 
>> On Thu, Apr 24, 2014 at 1:55 AM, Alex Afanasyev
>> <alexander.afanasyev at ucla.edu> wrote:
>>> 
>>> On Apr 23, 2014, at 4:53 PM, Davide Pesavento <davidepesa at gmail.com> wrote:
>>> 
>>>> On Thu, Apr 24, 2014 at 1:02 AM, Alex Afanasyev
>>>> <alexander.afanasyev at ucla.edu> wrote:
>>>>> We will try to do the change with a transition period, when existing application will still be able to compile against ndn-cxx (there will be additional symlinks created for include, lib, and pkg-config files), but all known applications needs to be updated ASAP after the renaming is complete in the following way:
>>>>> 
>>>> 
>>>> Are you going to release the first version with the compatibility symlinks?
>>> 
>>> Honestly, not sure about this and we shall make a decision.  If we can quickly update all applications (NFD, repo, NLSR, ping, others?), then this will not go into the release.  Personally, I prefer not to add symlinks in the initial release.
>>> 
>> 
>> Agreed, but it also depends on the available timeframe. Aren't we
>> already late with the first release?
>> 
>> Instead of adding symlinks, we could freeze the current ndn-cpp-dev
>> codebase and keep the github repo and docs so that people can still
>> fetch and build the old library. After a while the docs are removed
>> and the ndn-cpp-dev repo is changed to redirect to ndn-cxx. How does
>> that sound?
> 
> This sounds good to me.  I can also update README.md file for ndn-cpp-dev repo, stating that this library has been renamed and development continues under different name + add the link.  After a month or so, we can remove it completely.


The changes needed seem easy to make. Since all developers are on this list, why not set a deadline, say the end of this Friday, and every app has to finish the changes by then? 

Beichuan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140423/8902992d/attachment.html>

From jefft0 at remap.ucla.edu  Mon Apr 28 17:58:44 2014
From: jefft0 at remap.ucla.edu (Thompson, Jeff)
Date: Tue, 29 Apr 2014 00:58:44 +0000
Subject: [Nfd-dev] Interest lifetime for NFD command interests
In-Reply-To: <6B97D471-432E-4FC8-81A5-FD07CB739866@ucla.edu>
References: <CF76C28D.6543%jefft0@remap.ucla.edu>
	<6B97D471-432E-4FC8-81A5-FD07CB739866@ucla.edu>
Message-ID: <CF844736.B85A%jefft0@remap.ucla.edu>

Hi Alex,

Fair enough.  But I just tested on the Raspberry Pi, and it takes NFD 1200 seconds to answer a prefix registration.  For use on the Pi, we increased the command interest lifetime to 2000 milliseconds.

- Jeff T

From: Alex Afansyev <alexander.afanasyev at ucla.edu<mailto:alexander.afanasyev at ucla.edu>>
Date: Friday, April 18, 2014 2:10 PM
To: Jeff Thompson <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>>
Cc: nfd-dev <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] Interest lifetime for NFD command interests

Hi Jeff,

I agree completely with this for prefix registration commands.  I would say, there is no much value/reason to make the lifetime longer than, say, a second.  Could be shorter, but on some extremely busy systems (like our Jenkins slave), even a simple registration may take some time.

For face creation, lifetime should be longer that 4 seconds since it can take some time to create some tunnels (e.g., TCP).  We even have a redmine issue for that (http://redmine.named-data.net/issues/1455)

---
Alex

On Apr 18, 2014, at 11:51 AM, Thompson, Jeff <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>> wrote:

For a command interest to NFD/NRD, is there a recommended InterestLifetime (used as a timeout)?  Since it goes to the local host, can it safely be shorter than 4000 milliseconds?

Thank you,
- Jeff T
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140429/f8c09d84/attachment.html>

From jburke at remap.ucla.edu  Mon Apr 28 18:07:48 2014
From: jburke at remap.ucla.edu (Burke, Jeff)
Date: Tue, 29 Apr 2014 01:07:48 +0000
Subject: [Nfd-dev] Interest lifetime for NFD command interests
In-Reply-To: <CF844736.B85A%jefft0@remap.ucla.edu>
Message-ID: <CF8448D1.13CAEB%jburke@remap.ucla.edu>


Most of the redmine issue referenced by Alex deals with timeouts in the case of an unavailable remote node, failed dns lookup, etc., but in a successful registration?such as the one taking 1200ms on the PI? what are the dominant time components?

Jeff

From: "Thompson, Jeff" <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>>
Date: Tue, 29 Apr 2014 00:58:44 +0000
To: Alex Afanasyev <alexander.afanasyev at ucla.edu<mailto:alexander.afanasyev at ucla.edu>>
Cc: nfd-dev <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] Interest lifetime for NFD command interests

Hi Alex,

Fair enough.  But I just tested on the Raspberry Pi, and it takes NFD 1200 seconds to answer a prefix registration.  For use on the Pi, we increased the command interest lifetime to 2000 milliseconds.

- Jeff T

From: Alex Afansyev <alexander.afanasyev at ucla.edu<mailto:alexander.afanasyev at ucla.edu>>
Date: Friday, April 18, 2014 2:10 PM
To: Jeff Thompson <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>>
Cc: nfd-dev <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] Interest lifetime for NFD command interests

Hi Jeff,

I agree completely with this for prefix registration commands.  I would say, there is no much value/reason to make the lifetime longer than, say, a second.  Could be shorter, but on some extremely busy systems (like our Jenkins slave), even a simple registration may take some time.

For face creation, lifetime should be longer that 4 seconds since it can take some time to create some tunnels (e.g., TCP).  We even have a redmine issue for that (http://redmine.named-data.net/issues/1455)

---
Alex

On Apr 18, 2014, at 11:51 AM, Thompson, Jeff <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>> wrote:

For a command interest to NFD/NRD, is there a recommended InterestLifetime (used as a timeout)?  Since it goes to the local host, can it safely be shorter than 4000 milliseconds?

Thank you,
- Jeff T
_______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu<mailto: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: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140429/e829c9e2/attachment.html>

From jefft0 at remap.ucla.edu  Mon Apr 28 18:16:49 2014
From: jefft0 at remap.ucla.edu (Thompson, Jeff)
Date: Tue, 29 Apr 2014 01:16:49 +0000
Subject: [Nfd-dev] Interest lifetime for NFD command interests
In-Reply-To: <CF8448D1.13CAEB%jburke@remap.ucla.edu>
References: <CF844736.B85A%jefft0@remap.ucla.edu>
	<CF8448D1.13CAEB%jburke@remap.ucla.edu>
Message-ID: <CF844B8D.B8BA%jefft0@remap.ucla.edu>

Does anyone know what is the command to increase the debug log level in NFD, so I can get a trace?  (nfd --help doesn't seem to say.)

- Jeff T

From: <Burke>, Jeff Burke <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>>
Date: Monday, April 28, 2014 6:07 PM
To: Jeff Thompson <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>>, Alex Afansyev <alexander.afanasyev at ucla.edu<mailto:alexander.afanasyev at ucla.edu>>
Cc: nfd-dev <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] Interest lifetime for NFD command interests


Most of the redmine issue referenced by Alex deals with timeouts in the case of an unavailable remote node, failed dns lookup, etc., but in a successful registration?such as the one taking 1200ms on the PI? what are the dominant time components?

Jeff

From: "Thompson, Jeff" <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>>
Date: Tue, 29 Apr 2014 00:58:44 +0000
To: Alex Afanasyev <alexander.afanasyev at ucla.edu<mailto:alexander.afanasyev at ucla.edu>>
Cc: nfd-dev <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] Interest lifetime for NFD command interests

Hi Alex,

Fair enough.  But I just tested on the Raspberry Pi, and it takes NFD 1200 seconds to answer a prefix registration.  For use on the Pi, we increased the command interest lifetime to 2000 milliseconds.

- Jeff T

From: Alex Afansyev <alexander.afanasyev at ucla.edu<mailto:alexander.afanasyev at ucla.edu>>
Date: Friday, April 18, 2014 2:10 PM
To: Jeff Thompson <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>>
Cc: nfd-dev <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] Interest lifetime for NFD command interests

Hi Jeff,

I agree completely with this for prefix registration commands.  I would say, there is no much value/reason to make the lifetime longer than, say, a second.  Could be shorter, but on some extremely busy systems (like our Jenkins slave), even a simple registration may take some time.

For face creation, lifetime should be longer that 4 seconds since it can take some time to create some tunnels (e.g., TCP).  We even have a redmine issue for that (http://redmine.named-data.net/issues/1455)

---
Alex

On Apr 18, 2014, at 11:51 AM, Thompson, Jeff <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>> wrote:

For a command interest to NFD/NRD, is there a recommended InterestLifetime (used as a timeout)?  Since it goes to the local host, can it safely be shorter than 4000 milliseconds?

Thank you,
- Jeff T
_______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu<mailto: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: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140429/f4776751/attachment.html>

From alexander.afanasyev at ucla.edu  Mon Apr 28 18:18:26 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Mon, 28 Apr 2014 18:18:26 -0700
Subject: [Nfd-dev] Interest lifetime for NFD command interests
In-Reply-To: <CF844B8D.B8BA%jefft0@remap.ucla.edu>
References: <CF844736.B85A%jefft0@remap.ucla.edu>
	<CF8448D1.13CAEB%jburke@remap.ucla.edu>
	<CF844B8D.B8BA%jefft0@remap.ucla.edu>
Message-ID: <0018BE79-F60F-4D41-8058-D51126060BBF@ucla.edu>

it's in the config file.  You can either change log level globally (the most verbose is TRACE) or do it per-module

---
Alex

On Apr 28, 2014, at 6:16 PM, Thompson, Jeff <jefft0 at remap.ucla.edu> wrote:

> Does anyone know what is the command to increase the debug log level in NFD, so I can get a trace?  (nfd --help doesn't seem to say.) 
> 
> - Jeff T
> 
> From: <Burke>, Jeff Burke <jburke at remap.ucla.edu>
> Date: Monday, April 28, 2014 6:07 PM
> To: Jeff Thompson <jefft0 at remap.ucla.edu>, Alex Afansyev <alexander.afanasyev at ucla.edu>
> Cc: nfd-dev <nfd-dev at lists.cs.ucla.edu>
> Subject: Re: [Nfd-dev] Interest lifetime for NFD command interests
> 
> 
> Most of the redmine issue referenced by Alex deals with timeouts in the case of an unavailable remote node, failed dns lookup, etc., but in a successful registration?such as the one taking 1200ms on the PI? what are the dominant time components?  
> 
> Jeff
> 
> From: "Thompson, Jeff" <jefft0 at remap.ucla.edu>
> Date: Tue, 29 Apr 2014 00:58:44 +0000
> To: Alex Afanasyev <alexander.afanasyev at ucla.edu>
> Cc: nfd-dev <nfd-dev at lists.cs.ucla.edu>
> Subject: Re: [Nfd-dev] Interest lifetime for NFD command interests
> 
> Hi Alex,
> 
> Fair enough.  But I just tested on the Raspberry Pi, and it takes NFD 1200 seconds to answer a prefix registration.  For use on the Pi, we increased the command interest lifetime to 2000 milliseconds.
> 
> - Jeff T
> 
> From: Alex Afansyev <alexander.afanasyev at ucla.edu>
> Date: Friday, April 18, 2014 2:10 PM
> To: Jeff Thompson <jefft0 at remap.ucla.edu>
> Cc: nfd-dev <nfd-dev at lists.cs.ucla.edu>
> Subject: Re: [Nfd-dev] Interest lifetime for NFD command interests
> 
> Hi Jeff,
> 
> I agree completely with this for prefix registration commands.  I would say, there is no much value/reason to make the lifetime longer than, say, a second.  Could be shorter, but on some extremely busy systems (like our Jenkins slave), even a simple registration may take some time.
> 
> For face creation, lifetime should be longer that 4 seconds since it can take some time to create some tunnels (e.g., TCP).  We even have a redmine issue for that (http://redmine.named-data.net/issues/1455)
> 
> ---
> Alex
> 
> On Apr 18, 2014, at 11:51 AM, Thompson, Jeff <jefft0 at remap.ucla.edu> wrote:
> 
>> For a command interest to NFD/NRD, is there a recommended InterestLifetime (used as a timeout)?  Since it goes to the local host, can it safely be shorter than 4000 milliseconds?
>> 
>> Thank you,
>> - Jeff T
> _______________________________________________ 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: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140428/c1857dec/attachment.html>

From jefft0 at remap.ucla.edu  Mon Apr 28 18:45:54 2014
From: jefft0 at remap.ucla.edu (Thompson, Jeff)
Date: Tue, 29 Apr 2014 01:45:54 +0000
Subject: [Nfd-dev] Interest lifetime for NFD command interests
In-Reply-To: <0018BE79-F60F-4D41-8058-D51126060BBF@ucla.edu>
References: <CF844736.B85A%jefft0@remap.ucla.edu>
	<CF8448D1.13CAEB%jburke@remap.ucla.edu>
	<CF844B8D.B8BA%jefft0@remap.ucla.edu>
	<0018BE79-F60F-4D41-8058-D51126060BBF@ucla.edu>
Message-ID: <CF8450F7.B91F%jefft0@remap.ucla.edu>

Below is the DEBUG trace of prefix registration on the Pi. I changed the timestamps to elapsed time from receiving the request (and trucated the interests). Of course with the terminal I/O, it now takes 2.7 seconds, but hopefully it is representative.

- Jeff T

0.000   DEBUG: [TcpChannel] [0.0.0.0:6363] << Connection from 127.0.0.1:45549
0.001   INFO: [FaceTable] Added face id=5 remote=tcp4://127.0.0.1:45549 local=tcp4://127.0.0.1:6363
0.324   DEBUG: [Forwarder] onIncomingData face=1 data=/localhost/nfd/faces/events/%04
0.335   DEBUG: [Forwarder] onIncomingData matching=/localhost/nfd/faces/events
0.340   DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/localhost/nfd/faces/events inFace=1 data=/localhost/nfd/faces/events/%04
0.350   DEBUG: [Forwarder] onOutgoingData face=4 data=/localhost/nfd/faces/events/%04
0.355   DEBUG: [FaceMonitor] onNotification: Interest sent: /localhost/nfd/faces/events/%05?ndn.InterestLifetime=60000 milliseconds&ndn.Nonce=2975392766
0.363   DEBUG: [Forwarder] onIncomingInterest face=5 interest=/localhost/nfd/rib/register/h%0C%07%0A%08%08testecho
0.451   DEBUG: [Forwarder] onOutgoingInterest face=4 interest=/localhost/nfd/rib/register/h%0C%07%0A%08%08testecho
0.544   DEBUG: [Forwarder] onIncomingInterest face=4 interest=/localhost/nfd/faces/events/%05
0.555   DEBUG: [Forwarder] onOutgoingInterest face=1 interest=/localhost/nfd/faces/events/%05
0.568   DEBUG: [InternalFace] 1398735087.459180 DEBUG: [RibManager] Parameters parsed OK
0.570   DEBUG: [RibManager] command result: processing verb: register: /localhost/nfd/faces/events/%05
0.581   DEBUG: [InternalFace] found Interest filter for /localhost/nfd/faces (previous match)
0.597   DEBUG: [FaceManager] command result: processing verb: events
0.908   DEBUG: [Forwarder] onIncomingInterest face=4 interest=/localhost/nfd/fib/add-nexthop/h%12%07%0A%08%08testechoi%01%05j%01%00/%00%00%01E%AB%1B%A7r
1.004   DEBUG: [Forwarder] onOutgoingInterest face=1 interest=/localhost/nfd/fib/add-nexthop/h%12%07%0A%08%08testechoi%01%05j%01%00/%00%00%01E%AB%1B%A7r
1.095   DEBUG: [InternalFace] received Interest: /localhost/nfd/fib/add-nexthop/h%12%07%0A%08%08testecho
1.944   DEBUG: [Forwarder] onOutgoingData face=4 data=/localhost/nfd/fib/add-nexthop/h%12%07%0A%08%08testechoi%01%05j%01%00/%00%00%01E%AB%1B%A7r
2.356   DEBUG: [Forwarder] onIncomingData face=4 data=/localhost/nfd/rib/register/h%0C%07%0A%08%08testecho/%01E%AB%1B%A2%93
2.443   DEBUG: [Forwarder] onIncomingData matching=/localhost/nfd/rib/register/h%0C%07%0A%08%08testecho/%01E%AB%1B%A2%93/%BF%15%EE%EE%FC%CDw%C5
2.528   DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/localhost/nfd/rib/register/h%0C%07%0A%08%08testecho/%01E%AB%1B%A2%93/%BF%15%EE%EE%FC%CDw%C5
2.691   DEBUG: [Forwarder] onOutgoingData face=5 data=/localhost/nfd/rib/register/h%0C%07%0A%08%08testecho/%01E%AB%1B%A2%93

From: Alex Afansyev <alexander.afanasyev at ucla.edu<mailto:alexander.afanasyev at ucla.edu>>
Date: Monday, April 28, 2014 6:18 PM
To: Jeff Thompson <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>>
Cc: Jeff Burke <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>>, nfd-dev <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] Interest lifetime for NFD command interests

it's in the config file.  You can either change log level globally (the most verbose is TRACE) or do it per-module

---
Alex

On Apr 28, 2014, at 6:16 PM, Thompson, Jeff <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>> wrote:

Does anyone know what is the command to increase the debug log level in NFD, so I can get a trace?  (nfd --help doesn't seem to say.)

- Jeff T

From: <Burke>, Jeff Burke <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>>
Date: Monday, April 28, 2014 6:07 PM
To: Jeff Thompson <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>>, Alex Afansyev <alexander.afanasyev at ucla.edu<mailto:alexander.afanasyev at ucla.edu>>
Cc: nfd-dev <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] Interest lifetime for NFD command interests


Most of the redmine issue referenced by Alex deals with timeouts in the case of an unavailable remote node, failed dns lookup, etc., but in a successful registration?such as the one taking 1200ms on the PI? what are the dominant time components?

Jeff

From: "Thompson, Jeff" <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>>
Date: Tue, 29 Apr 2014 00:58:44 +0000
To: Alex Afanasyev <alexander.afanasyev at ucla.edu<mailto:alexander.afanasyev at ucla.edu>>
Cc: nfd-dev <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] Interest lifetime for NFD command interests

Hi Alex,

Fair enough.  But I just tested on the Raspberry Pi, and it takes NFD 1200 seconds to answer a prefix registration.  For use on the Pi, we increased the command interest lifetime to 2000 milliseconds.

- Jeff T

From: Alex Afansyev <alexander.afanasyev at ucla.edu<mailto:alexander.afanasyev at ucla.edu>>
Date: Friday, April 18, 2014 2:10 PM
To: Jeff Thompson <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>>
Cc: nfd-dev <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] Interest lifetime for NFD command interests

Hi Jeff,

I agree completely with this for prefix registration commands.  I would say, there is no much value/reason to make the lifetime longer than, say, a second.  Could be shorter, but on some extremely busy systems (like our Jenkins slave), even a simple registration may take some time.

For face creation, lifetime should be longer that 4 seconds since it can take some time to create some tunnels (e.g., TCP).  We even have a redmine issue for that (http://redmine.named-data.net/issues/1455)

---
Alex

On Apr 18, 2014, at 11:51 AM, Thompson, Jeff <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>> wrote:

For a command interest to NFD/NRD, is there a recommended InterestLifetime (used as a timeout)?  Since it goes to the local host, can it safely be shorter than 4000 milliseconds?

Thank you,
- Jeff T
_______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu<mailto: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: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140429/937281de/attachment.html>

From alexander.afanasyev at ucla.edu  Mon Apr 28 19:01:15 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Mon, 28 Apr 2014 19:01:15 -0700
Subject: [Nfd-dev] Interest lifetime for NFD command interests
In-Reply-To: <CF8450F7.B91F%jefft0@remap.ucla.edu>
References: <CF844736.B85A%jefft0@remap.ucla.edu>
	<CF8448D1.13CAEB%jburke@remap.ucla.edu>
	<CF844B8D.B8BA%jefft0@remap.ucla.edu>
	<0018BE79-F60F-4D41-8058-D51126060BBF@ucla.edu>
	<CF8450F7.B91F%jefft0@remap.ucla.edu>
Message-ID: <0B360789-98B3-4138-84DD-C9BF60090638@ucla.edu>

From what I can see, the most time was spent on verifying of the command interest and signing the response.

---
Alex

> On Apr 28, 2014, at 6:45 PM, "Thompson, Jeff" <jefft0 at remap.ucla.edu> wrote:
> 
> Below is the DEBUG trace of prefix registration on the Pi. I changed the timestamps to elapsed time from receiving the request (and trucated the interests). Of course with the terminal I/O, it now takes 2.7 seconds, but hopefully it is representative.
> 
> - Jeff T
> 
> 0.000   DEBUG: [TcpChannel] [0.0.0.0:6363] << Connection from 127.0.0.1:45549
> 0.001   INFO: [FaceTable] Added face id=5 remote=tcp4://127.0.0.1:45549 local=tcp4://127.0.0.1:6363
> 0.324   DEBUG: [Forwarder] onIncomingData face=1 data=/localhost/nfd/faces/events/%04
> 0.335   DEBUG: [Forwarder] onIncomingData matching=/localhost/nfd/faces/events
> 0.340   DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/localhost/nfd/faces/events inFace=1 data=/localhost/nfd/faces/events/%04
> 0.350   DEBUG: [Forwarder] onOutgoingData face=4 data=/localhost/nfd/faces/events/%04
> 0.355   DEBUG: [FaceMonitor] onNotification: Interest sent: /localhost/nfd/faces/events/%05?ndn.InterestLifetime=60000 milliseconds&ndn.Nonce=2975392766
> 0.363   DEBUG: [Forwarder] onIncomingInterest face=5 interest=/localhost/nfd/rib/register/h%0C%07%0A%08%08testecho
> 0.451   DEBUG: [Forwarder] onOutgoingInterest face=4 interest=/localhost/nfd/rib/register/h%0C%07%0A%08%08testecho
> 0.544   DEBUG: [Forwarder] onIncomingInterest face=4 interest=/localhost/nfd/faces/events/%05
> 0.555   DEBUG: [Forwarder] onOutgoingInterest face=1 interest=/localhost/nfd/faces/events/%05
> 0.568   DEBUG: [InternalFace] 1398735087.459180 DEBUG: [RibManager] Parameters parsed OK
> 0.570   DEBUG: [RibManager] command result: processing verb: register: /localhost/nfd/faces/events/%05
> 0.581   DEBUG: [InternalFace] found Interest filter for /localhost/nfd/faces (previous match)
> 0.597   DEBUG: [FaceManager] command result: processing verb: events
> 0.908   DEBUG: [Forwarder] onIncomingInterest face=4 interest=/localhost/nfd/fib/add-nexthop/h%12%07%0A%08%08testechoi%01%05j%01%00/%00%00%01E%AB%1B%A7r
> 1.004   DEBUG: [Forwarder] onOutgoingInterest face=1 interest=/localhost/nfd/fib/add-nexthop/h%12%07%0A%08%08testechoi%01%05j%01%00/%00%00%01E%AB%1B%A7r
> 1.095   DEBUG: [InternalFace] received Interest: /localhost/nfd/fib/add-nexthop/h%12%07%0A%08%08testecho
> 1.944   DEBUG: [Forwarder] onOutgoingData face=4 data=/localhost/nfd/fib/add-nexthop/h%12%07%0A%08%08testechoi%01%05j%01%00/%00%00%01E%AB%1B%A7r
> 2.356   DEBUG: [Forwarder] onIncomingData face=4 data=/localhost/nfd/rib/register/h%0C%07%0A%08%08testecho/%01E%AB%1B%A2%93
> 2.443   DEBUG: [Forwarder] onIncomingData matching=/localhost/nfd/rib/register/h%0C%07%0A%08%08testecho/%01E%AB%1B%A2%93/%BF%15%EE%EE%FC%CDw%C5
> 2.528   DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/localhost/nfd/rib/register/h%0C%07%0A%08%08testecho/%01E%AB%1B%A2%93/%BF%15%EE%EE%FC%CDw%C5
> 2.691   DEBUG: [Forwarder] onOutgoingData face=5 data=/localhost/nfd/rib/register/h%0C%07%0A%08%08testecho/%01E%AB%1B%A2%93
> 
> From: Alex Afansyev <alexander.afanasyev at ucla.edu>
> Date: Monday, April 28, 2014 6:18 PM
> To: Jeff Thompson <jefft0 at remap.ucla.edu>
> Cc: Jeff Burke <jburke at remap.ucla.edu>, nfd-dev <nfd-dev at lists.cs.ucla.edu>
> Subject: Re: [Nfd-dev] Interest lifetime for NFD command interests
> 
> it's in the config file.  You can either change log level globally (the most verbose is TRACE) or do it per-module
> 
> ---
> Alex
> 
>> On Apr 28, 2014, at 6:16 PM, Thompson, Jeff <jefft0 at remap.ucla.edu> wrote:
>> 
>> Does anyone know what is the command to increase the debug log level in NFD, so I can get a trace?  (nfd --help doesn't seem to say.) 
>> 
>> - Jeff T
>> 
>> From: <Burke>, Jeff Burke <jburke at remap.ucla.edu>
>> Date: Monday, April 28, 2014 6:07 PM
>> To: Jeff Thompson <jefft0 at remap.ucla.edu>, Alex Afansyev <alexander.afanasyev at ucla.edu>
>> Cc: nfd-dev <nfd-dev at lists.cs.ucla.edu>
>> Subject: Re: [Nfd-dev] Interest lifetime for NFD command interests
>> 
>> 
>> Most of the redmine issue referenced by Alex deals with timeouts in the case of an unavailable remote node, failed dns lookup, etc., but in a successful registration?such as the one taking 1200ms on the PI? what are the dominant time components?  
>> 
>> Jeff
>> 
>> From: "Thompson, Jeff" <jefft0 at remap.ucla.edu>
>> Date: Tue, 29 Apr 2014 00:58:44 +0000
>> To: Alex Afanasyev <alexander.afanasyev at ucla.edu>
>> Cc: nfd-dev <nfd-dev at lists.cs.ucla.edu>
>> Subject: Re: [Nfd-dev] Interest lifetime for NFD command interests
>> 
>> Hi Alex,
>> 
>> Fair enough.  But I just tested on the Raspberry Pi, and it takes NFD 1200 seconds to answer a prefix registration.  For use on the Pi, we increased the command interest lifetime to 2000 milliseconds.
>> 
>> - Jeff T
>> 
>> From: Alex Afansyev <alexander.afanasyev at ucla.edu>
>> Date: Friday, April 18, 2014 2:10 PM
>> To: Jeff Thompson <jefft0 at remap.ucla.edu>
>> Cc: nfd-dev <nfd-dev at lists.cs.ucla.edu>
>> Subject: Re: [Nfd-dev] Interest lifetime for NFD command interests
>> 
>> Hi Jeff,
>> 
>> I agree completely with this for prefix registration commands.  I would say, there is no much value/reason to make the lifetime longer than, say, a second.  Could be shorter, but on some extremely busy systems (like our Jenkins slave), even a simple registration may take some time.
>> 
>> For face creation, lifetime should be longer that 4 seconds since it can take some time to create some tunnels (e.g., TCP).  We even have a redmine issue for that (http://redmine.named-data.net/issues/1455)
>> 
>> ---
>> Alex
>> 
>>> On Apr 18, 2014, at 11:51 AM, Thompson, Jeff <jefft0 at remap.ucla.edu> wrote:
>>> 
>>> For a command interest to NFD/NRD, is there a recommended InterestLifetime (used as a timeout)?  Since it goes to the local host, can it safely be shorter than 4000 milliseconds?
>>> 
>>> Thank you,
>>> - Jeff T
>> _______________________________________________ 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: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140428/7572cf11/attachment.html>

From shijunxiao at email.arizona.edu  Tue Apr 29 12:51:17 2014
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Tue, 29 Apr 2014 12:51:17 -0700
Subject: [Nfd-dev] Updating FIB
In-Reply-To: <CCF7B76B-224B-4A33-A559-F46525E09A32@memphis.edu>
References: <CCF7B76B-224B-4A33-A559-F46525E09A32@memphis.edu>
Message-ID: <CAOFH+OZBpQQuh7mt=BMf1i9o9ncGBSR9-wbo2OmfFj1aD7e4HA@mail.gmail.com>

Hi Hoque

Apps and routing daemons SHOULD update FIB indirectly by updating RIB.

To update RIB using ndn-cxx:

1. create ndn::nfd::Controller instance
2. populate a ndn::nfd::ControlParameters object with necessary fields
http://redmine.named-data.net/projects/nfd/wiki/RibMgmt
3. invoke controller.start<RibRegisterCommand> or
controller.start<RibUnregisterCommand>

Note: FibAddNextHopCommand SHOULD NOT be used by apps or routing daemons.
It's for internal use by NFD RIB daemon.

Yours, Junxiao
On Apr 29, 2014 12:43 PM, "A K M Mahmudul Hoque (ahoque1)" <
ahoque1 at memphis.edu> wrote:

> Hi Junxiao,
>
> Can you tell how can one application(NLSR) can update nfd's FIB?
> Is there library function available to do that?
>
> Given that NLSR knows the faceId how can NLSR
> 1. Register name prefixes with faceId(s) ?
> 2. Unregister name prefixes with faceId(s)?
>
> Any pointer in the code of NFD/NDN-CXX would be very helpful.
>
> Regards
> Hoque
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140429/3898e835/attachment.html>

From alexander.afanasyev at ucla.edu  Wed Apr 30 20:56:50 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Wed, 30 Apr 2014 20:56:50 -0700
Subject: [Nfd-dev] NFD-0.1.0 release candidate 1 is released (initial
	release)
Message-ID: <A2BECAE2-49E8-4517-84B3-BE12EFD9879A@ucla.edu>

Hello everybody,

We are extremely pleased to announce that our new NDN Forwarding Daemon (NFD) finally got
to the stage of the initial release (version 0.1.0, release candidate 1).

Currently, it is a source package only release and the code can be downloaded from
GitHub:

- Direct download: https://github.com/named-data/NFD/archive/NFD-0.1.0-rc1.tar.gz
- Cloning using git:

    git clone https://github.com/named-data/NFD
    cd NFD && git checkout -b v0.1.0-rc1 NFD-0.1.0-rc1

- General NFD introduction (NFD homepage): http://named-data.net/doc/NFD/0.1.0/
- HTML version of release notes: http://named-data.net/doc/NFD/0.1.0/RELEASE_NOTES.html

Other NFD resources:

- Installation instructions: http://named-data.net/doc/NFD/0.1.0/INSTALL.html
- Getting started Wiki: http://redmine.named-data.net/projects/nfd/wiki/Getting_Started

Feature requests and bug reports are welcome on our NDN Redmine: http://redmine.named-data.net/projects/nfd

=========================================================================================
=========================================================================================

Major Modules of NFD
--------------------

NFD has the following major modules:

- Core
    Provides various common services shared between different NFD modules. These include
    hash computation routines, DNS resolver, config file, face monitoring, and
    several other modules.

- Faces
    Implements the NDN face abstraction on top of different lower level transport
    mechanisms.

- Tables
    Implements the Content Store (CS), the Pending Interest Table (PIT), the Forwarding
    Information Base (FIB), and other data structures to support forwarding of NDN Data
    and Interest packets.

- Forwarding
    Implements basic packet processing pathways, which interact with Faces, Tables,
    and Strategies.

  + **Strategy Support**, a major part of the forwarding module
      Implements a framework to support different forwarding strategies. It includes
      StrategyChoice, Measurements, Strategies, and hooks in the forwarding pipelines. The
      StrategyChoice records the choice of the strategy for a namespace, and Measurement
      records are used by strategies to store past performance results for namespaces.

- Management
    Implements the `NFD Management Protocol
    <http://redmine.named-data.net/projects/nfd/wiki/Management>`_, which allows
    applications to configure NFD and set/query NFD's internal states.  Protocol interaction
    is done via NDN's Interest/Data exchange between applications and NFD.

- RIB Management
    Manages the routing information base (RIB).  The RIB may be updated by different parties
    in different ways, including various routing protocols, application's prefix
    registrations, and command-line manipulation by sysadmins.  The RIB management module
    processes all these requests to generate a consistent forwarding table, and then syncs
    it up with the NFD's FIB, which contains only the minimal information needed for
    forwarding decisions. Strictly speaking RIB management is part of the NFD management
    module. However, due to its importance to the overall operations and its more complex
    processing, we make it a separate module.

Features in Version 0.1.0
-------------------------

This is an incomplete list of features that are implemented in NFD version 0.1.0.

- Packet Format

  + `NDN-TLV <http://named-data.net/doc/ndn-tlv/>`_
  + LocalControlHeader, to allow apps to set outgoing face and learn incoming face.

- Faces

  + Unix stream socket
  + UDP unicast
  + UDP multicast
  + TCP
  + Ethernet, currently without fragmentation.

    .. note::
         Ethernet support will not work properly on Linux kernels with TPACKET_V3 flexible
         buffer implementation (>= 3.2.0) and libpcap >= 1.5.0 (e.g., Ubuntu Linux 14.04).
         Refer to `Issue 1551 <http://redmine.named-data.net/issues/1511>`_ for more
         detail and implementation progress.

- Management

  + Use of signed Interests as commands, with authentication and authorization.
  + Face management
  + FIB management
  + Per-namespace strategy selection
  + NFD status publishing
  + Notification to authorized apps of internal events, including Face creation and destruction.

- Tables and forwarding pipelines support most Interest/Data processing, including
  selectors.

- RIB Management that runs as a separate process, ``nrd``.  It supports basic prefix
  registration by applications, but no flags yet.

- Strategies

  + ``broadcast``
  + ``best-route``
  + ``ncc``: based on ccnx 0.7 for experimentation
  + ``client-control``: authorized application can directly control Interest forwarding

- Name-based scoping

  + ``/localhost``: communication only within localhost using "local" Faces
    (UnixStreamFace, LocalTcpFace).  NFD will strictly enforce this scope for Interests
    and Data packets
  + ``/localhop``: one-hop communication (e.g., if at least one incoming or outgoing Face
    in PIT entry is non-local, the Interest cannot be forwarded to any non-local Face)

- Support configuration file, which is in the Boost INFO format.

- Applications

  + Tools to discover hubs on NDN testbed.
  + peek/poke and traffic generators for testing and debugging.
  + ``nfdc``, a command-line tool to configure NFD.
  + ``nfd-status``, a command-line tool to query NFD status.
  + ``nfd-status-http-server``, which reads the NFD status and publishes over HTTP.


Planned Functions and Features for Next Releases
------------------------------------------------

- NACK
    A packet sent back by a producer or a router to signal the unavailability of a requested
    Data packet. The protocol specification for NACK is in progress.

- New strategies
    Additional strategies, including self-learning that populates the FIB by observing
    Interest and Data exchange.

- Hop-by-hop Interest limit mechanism for congestion control.

- Face enhancements
    Add fragmentation support for Ethernet face, may add support for new types such as
    WiFi direct and WebSockets.

- Tables
    Experiment and evaluate different data structures and algorithms.

- RIB management
    Move to more scalable data structures and support all flags in prefix registrations.

- Tunnel management
    For hub nodes to authenticate incoming tunnel requests and maintain the tunnels.

- Extensible name-based scoping

  + configurable organization-based scoping

---
NFD Team