NFD » ndn-tools

At 20150706 conference call, Yingdi agrees that PIB service should be placed in ndn-tools.

There has been a proposal to put PIB service into NFD.
However, this is wrong, because NFD is the forwarding daemon package, and it shouldn't contain other packages.

Placing PIB service in ndn-tools does not cause extra deployment difficulties.
ndn-tools is a collection of essential tools that should be deployed on every device, including mobile devices.
In case a platform lacks support of one of the tools (eg. no libpcap), that tool can be individually disabled.

At 20150713 conference call, @Yingdi Yu mentions one reason @Alex wants PIB service to be placed in NFD repository:
PIB service can be packaged into the same Android application as NFD.

My opinion is:

• The Android project can pull C++ code from both NFD and ndn-tools repositories, and package them into one Android application. Where the code comes from is orthogonal to whether they can be in the same Android application.
• PIB service won't work if it's in the same Android application as NFD. It needs to be in the user-facing application.
  • PIB service needs access to the same TPM used by application.
  • Android applications use file-based TPM.
  • The TPM cannot be placed on the sdcard, because sdcard is exposed to every process on the device. So the TPM has to be placed on the private storage area of the application.
  • If PIB service is running in the NFD application, it cannot get access to the private storage area of user-facing applications.

From @Alex on 20150713 email:

I still prefer PIB service be a part of NFD. PIB service do not access TPM, it is a public information base for all applications, so it can be (and I'm planning on doing it on android) a single process/thread associated with NFD: there is no reason to run PIB without NFD, and when NFD is running, you need PIB so others can fetch certificates.
Making it part of tools makes my life (and people who will be installing from source) harder, though I can live if pib is part of tools.

I disagree with putting PIB service into NFD repository due to reason stated in note-1.

Also:

• PIB service, as currently implemented, requires access to the TPM for signing command replies.
• The logic "there is no reason to run PIB without NFD, and when NFD is running, you need PIB so others can fetch certificates" is applicable to many other daemons:
  • "there is no reason to run ndnpingserver without NFD, and when NFD is running, you need ndnpingserver so others can test reachability" (reachability testing is more essential than certificate fetching, as ICMP echo replies are built into linux kernel and Windows network stack)
  • "there is no reason to run repo-ng without NFD, and when NFD is running, you need repo-ng so applications can use managed storage"

@Yingdi Yu has agreed to place PIB service into ndn-tools during 20150706 conference call.

@Alex "can live" if PIB service is placed into ndn-tools.

Therefore, this issue can proceed as described.

One choice we need to make is: how to arrange the commits?

• One commit to import everything, with minimal changes (mainly in build scripts) to allow compilation within ndn-tools. And then a second commit to improve code: license boilerplate, namespace, test suite naming, etc.
• Make separate commits for each feature, like building a tool from scratch.

I think the first approach is better, because there aren't much "history" to preserve.

https://gerrit.named-data.net/3156 corrects filename and test suite names in PIB tests.