Replicate routers.json to multiple routers

[yoursunny]

Currently, the status page retrieves routers.json from UCLA only:

testbed/framework/ndn-testbed-status/src/App.vue

Line 102 in f4f2c40

const ROUTERS_JSON = '/ndn/edu/ucla/file-server/routers.json';

Consequently, if the UCLA router is offline, the status page will not work.
The solution is deploying this page in multiple locations.

[Pesa]

As a follow-up to our discussion during the call yesterday... I just noticed that this spec says:

The name prefix of a metadata packet before the above three name components SHOULD be the same as the name of the versioned data up to (and not including) its version number component.

What's the reason for the "SHOULD"? What was the rationale for this recommendation?

Also, could someone summarize the pros and cons of using forwarding hint vs. the metadata approach?

[yoursunny]

What's the reason for the "SHOULD"? What was the rationale for this recommendation?

Placing metadata and segments under the same base prefix is the most common use case hence it's the general recommendation.

Remember the recommendation at the top:

it is RECOMMENDED that each application defines its own instance of the RDR protocol based on this document

ndn6-file-server has its own RDR dialect in which I can do whatever have a discovery prefix that differs from the serve prefix.

[Pesa]

What's the reason for the "SHOULD"? What was the rationale for this recommendation?

Placing metadata and segments under the same base prefix is the most common use case hence it's the general recommendation.

Sure, that may be the most common usage in applications today, but I doubt we can claim to have so much experience in NDN app design to make it a "SHOULD", which is a fairly strong recommendation. Absent any intrinsic reason to prefer that naming scheme, I don't think the mere fact that it's commonly used is a good justification for a "SHOULD".