NFD

Does it mean face should have another event emitter, which will be used for clean up or we will rename/abuse onFail?

Problem in current spec: FaceManager may request to create the same face when an existing face is closing.

This problem mainly affects unicast UDP face:

1. FaceManager create face udp4://192.0.2.1:6363/ as face X
2. FaceManager destroy face X
3. during the period [ face(X).close() has been invoked, but some packets scheduled for transmission are not sent yet ], face X exists in the channel;
   FaceManager create face udp4://192.0.2.1:6363/ would return face X, but it will be destroyed shortly

Further discussion is required before implementation.

Problem in current spec: FaceManager may request to create the same face when an existing face is closing.

20140216 conference call decides that the second creation request should fail.

This is similar to TCP CLOSE_WAIT state.

I suppose this is just a matter of setting a timeout event for the deletion of the Face from Channel's map (can be deleted from all other places immediately).

Just in case. The problem is not only what you mentioned, but also with the fact that neighbor is unaware of the fact of "closing" of the UDP face. It really annoys me in ndnx, making it basically impossible to delete UDP face... Should we have an explicit closing notification for UDP face? Something like "FIN" interest?

Problem mentioned in note-4 says that nfdc or another tool may use FaceMgmt to create the same face.

During closing period, packets from that remote end are ignored.
After Face is closed, a packet from the same remote end creates a new Face.

Telling remote end to destroy face is part of Face Authentication protocol.