NFD

https://www.lists.cs.ucla.edu/pipermail/ndn-interest/2019-April/002418.html has some background on how I got this idea.

Can typed components be used for these strategy parameter? So that we can have something like /<...>/retx-initial-supression=20ms

Do we reserve it in https://redmine.named-data.net/projects/ndn-tlv/wiki/NameComponentType? Or these typed components are for something more widely used such as version, segment, timestamp?

[In Asf we are using parameters like: /<...>/n-silent-timeouts~5.
I think we are supposed to use typed components in the long run: https://redmine.named-data.net/issues/4193#note-5]

This is not an appropriate use of typed component because it is specific to one application and not at all universal.

In the wire format (the name), you can continue using the URI query string format (use = instead of ~, and use & separator) or switch to JSON. It does not need to be human readable.

Then, engineer the nfdc tool to allow operator entering each parameter as a separate key-value pair:

nfdc strategy set / /localhost/nfd/strategy/best-route strategy-version 7 strategy-flag retx-initial-suppression=20 strategy-flag retx-max-suppression=500

Initially, nfdc does not need to validate the key-value pairs, but merely encodes them into either URI query string or JSON format.
Available flags and validation rules can be exposed via #3887.

Why bother with this and not simply go with same scheme as current ASF?

Ashlesh Gawande wrote in #note-4:

Why bother with this and not simply go with same scheme as current ASF?

If we are to add suppression config to ASF, how to pack multiple parameters in the same name component?

The same way it does now:
https://named-data.net/doc/NFD/current/manpages/nfd-asf-strategy.html

nfdc strategy set prefix /ndn strategy /localhost/nfd/strategy/asf/%FD%03/probing-interval~30000/n-silent-timeouts~5

Could provide shortened args optionally.
Can have something like:

nfdc strategy set prefix /ndn strategy /localhost/nfd/strategy/asf/%FD%03/pi~30000/nst~5/ris=20ms

I didn't realize that strategy parameters can have multiple components.

Remember to increment strategy version number every time you change the syntax or semantics of a parameter.

Don't introduce shortened aliases. Every strategy should have only one name.