NFD

Why is it 'related' to #1311 and not 'blocked' by #1311?

#1312 is the consumer, #1311 is the producer.
Development for both can start when protocol (#1310) is completed.

In 1970s, it's common to write programs for a machine that is not yet manufactured.
Both machine and programs follow the documentation, so they will work once the machine is released.

Similarly, both producer and consumer follow StrategyChoice protocol, and they will work.

For task #1312 and #1311, end-to-end testing is possible only when both tasks have some code.

Individually testing #1312 is still possible: don't run NFD, but use netcat to listen on the NFD's socket.
netcat would capture what nfdc writes into the socket, and the written octets can be inspected to determine whether consumer conforms to the protocol.

Ehm... I thought we agreed to unify "options" data structure? At least in here we could just reuse the existing FibMangementOptions...

Alex Afanasyev wrote:

Ehm... I thought we agreed to unify "options" data structure? At least in here we could just reuse the existing FibMangementOptions...

I plan not only to unify Options, but also combine all management protocols into one. I'll send the proposal sometime.

Got it. But what should we do for this one? Reuse FibManagementOptions, create new options as per-spec, or wait till spec update?

We should create new one for now. FibManagementOptions and StrategyChoiceOptions have different TLV-TYPE numbers, so FibManagementOptions cannot be reused.

Spec update will not happen very soon.

Ok. Hila, go ahead with the push. I would not modify anything with FibManagementOptions, since we are going to change it in the future anyways.