NFD

RibMgmt rev11 defines the request and response format of rib/register command, but does not define the semantics of a successful response.

Unlike most other ControlCommands used in NFD Management, rib/register involves multiple steps on the server side,
including but not limited to: (1) update RIB; (2) update FIB; (3) perform remote prefix registration.
Some of those steps are asynchronous, and may take a long time.

This issue is to agree on the semantics of a successful response from rib/register command.
Specifically, the protocol should define what guarantee, if any, is provided to the calling application when rib/register command returns with a successful response.

The guarantee provided to producer application on a laptop could be one of these levels:

1. best effort, no guarantee
2. A consumer app on laptop can express Interest toward the prefix now, which will be delivered to the producer. (assuming strategy follows FIB)
3. A consumer app on directly connected gateway router can express Interest toward the prefix now, which will be delivered to the producer. (assuming strategy follows FIB; laptop can remote register the prefix on gateway)
4. A consumer app anywhere can express Interest toward the prefix now, which will be delivered to the producer. (assuming strategy follows FIB; laptop can remote register the prefix on gateway; gateway either announces the prefix to global routing table, or can recursively remote register the prefix on its uplink router)

To achieve these levels, server (RIB daemon) should finish the following before sending a successful response:

1. laptop: command authorization
2. level 1 + laptop: local RIB and FIB update
3. level 2 + laptop: remote prefix registration + gateway: RIB and FIB update
4. level 3 + gateway: recursive remote prefix registration

Different calling applications may desire different guarantees:

• Most user applications may need level 2 or level 3.
• Routing daemon may need level 1.
• Some user applications may need level 4.

Instead of defining choosing a single guarantee, this Task could also opt to add a new field in rib/register request to allow calling application to choose the desired guarantee.