NFD

This will prevent ndncon users from discovering each other until #3513 is resolved. I'd wait till it's implemented and tested and then turn off autoreg.

Peter Gusev wrote:

This will prevent ndncon users from discovering each other until #3513 is resolved. I'd wait till it's implemented and tested and then turn off autoreg.

nfd-autoreg will still run and configure /ndn/multicast and /ndn/broadcast.
Won't that take care of the discovery needed?

That and Alex's work-around for the prefix for a user of ndncon

This change does not affect NdnCon.

• #3513-19 workaround allows the user prefix to fall under an identity compatible with automatic prefix propagation.
• Multicast prefixes are still registered with nfd-autoreg.

Can we still have a flag day announced to ndn lists and instructions for mitigating impact on old apps? (With plenty of time...?)

My plan was to wait for agreement from the NdnCon folks that this would not affect their application and
then make an announcement to the mailing list with a date for the change to be put in place.

Are Peter and Jeff convinced that there will be no impact on their efforts?

Notice is sent to ndn operators ndn-app.

@Junxiao, can you please give me a link on how users should "enable automatic prefix propagation on end hosts before publishing anything.". If we proceed with this change before #3513 resolution, I have to provide information on how to ensure discoverability for users.

Answer to note-7:

Default NFD configuration file has auto_prefix_propagate section already enabled.

User needs to request a testbed certificate, and import this certificate into NFD's KeyChain so it's accessible by automatic prefix propagator.
See the announcement under "to migrate your application" step 1 and 2 for procedure if NFD is installed from Ubuntu package.
For NFD installed from source code, NFD's KeyChain is same as user's KeyChain, so only step 1 is needed.

This procedure is needed with or without #3513.

Before #2766, only certificates directly requested from ndncert can be used with automatic prefix propagation.

An implication from this specific point is:
If a user installs the same certificate on multiple end hosts, in case those end hosts send prefix registration requests at the same time, some prefix registrations might fail.

SignedInterestProcessing suggests not to share the key/certificate across end hosts, but request one ndncert certificate for each end host; the same person having multiple certificates is permitted under testbed policy.

I plan to update the Testbed nodes' configurations on June 1st.