NFD

• We reached consensus on removing the current persistent semantics from all faces and keep only on-demand and permanent.
  • We did not discuss whether to (a) redefine persistent with permanent semantics and remove FACE_PERSISTENCY_PERMANENT, or (b) remove FACE_PERSISTENCY_PERSISTENT and use permanent in its place.
• Alex pointed out that current persistent semantics can be useful when an end host moves from one testbed site to another.
  • We decided that ndn-autoconfig can take care of this by re-running the autoconfig procedure periodically (and/or when connectivity changes) and creating any new faces needed to connect to the new testbed router; the face connected to the previous testbed router can either be closed or set to DOWN state (note: NFD mgmt protocol doesn't currently support setting the face state).
• On the question of how to handle local IP address changes in permanent faces (i.e. TCP and UDP unicast), we decided to adopt the new local IP address when the face "reconnects".
  • Rationale: currently these face types are created with local IP == ANY (0.0.0.0 or [::]), so it's expected that they'll take whatever address is configured on the interface used by the OS to send out packets (according to the IP routing table).
  • If needed, a future extension may allow users to specify a local FaceUri when creating a TCP or UDP face, in a fully backward-compatible way. When a local FaceUri is specified in this way, the face remains tied to that IP address even if it disappears from the system.

Eric correctly points out that Unix faces are always created with on-demand persistency but don't have the close-on-idle behavior described in FaceMgmt.

The current behavior is correct but classifying Unix faces as on-demand is inconsistent with the definition. Their behavior is actually closer to that of persistent faces, although the plan described above would remove that persistency level.