Bug #2814
closed
Error: Expect prefix-update-validator section
100%
Description
Steps to reproduce:
- start NLSR 0.2.0 with the following configuration
general {
network /net
site site
router h0x0
log-level DEBUG
log-dir /var/log/ndn/
seq-dir /var/log/ndn/
}
neighbors {
neighbor {
name /net/site/h0x1
face-uri udp4://10.0.0.2:6363
}
neighbor {
name /net/site/h1x0
face-uri udp4://10.0.0.6:6363
}
}
fib {
max-faces-per-prefix 1
}
advertising {
prefix /h0x0
}
security {
validator {
trust-anchor {
type any
}
}
}
Expected: NLSR starts successfully
Actual:
Error: Expect prefix-update-validator section
Error in configuration file processing! Exiting from NLSR
docs/SECURITY-CONFIG.rst does not say prefix-update-validator section is required, so it should be optional.
Updated by Lan Wang almost 9 years ago
Looks like you are still using old configuration files?
Updated by Junxiao Shi almost 9 years ago
Looks like you are still using old configuration files?
Yes, I am.
My point is: if this section is required, documentation should reflect so.
Updated by Vince Lehman almost 9 years ago
- Status changed from New to Code review
- % Done changed from 0 to 90
Updated by Junxiao Shi almost 9 years ago
Design question:
In commit:da84e02c6882718b111e447b3bcf5f7666235909, if prefix-update-validator section is missing in configuration file, NLSR will respond code 503 to advertise/withdraw commands.
In contract, if localhop_security section is missing in nfd.conf, NFD RIB does not listen on ndn:/localhop/nfd/rib prefix, and will not respond to commands.
Please explain the rationale of choosing a different behavior than NFD RIB.
Updated by Vince Lehman almost 9 years ago
Junxiao Shi wrote:
Design question:
In commit:da84e02c6882718b111e447b3bcf5f7666235909, if
prefix-update-validatorsection is missing in configuration file, NLSR will respond code 503 to advertise/withdraw commands.
In contract, iflocalhop_securitysection is missing in nfd.conf, NFD RIB does not listen onndn:/localhop/nfd/ribprefix, and will not respond to commands.Please explain the rationale of choosing a different behavior than NFD RIB.
Responding with an error code is a design decision for better usability with NLSRC.
If the PrefixUpdateProcessor does not listen and respond with an error code, NLSRC will hang until the Interest times out. The error code also allows the user to better diagnose the issue as opposed to just a timeout; the feature is disabled vs. a connectivity problem. Also, if an error code is returned telling them that the feature is disabled, the user knows they may still use other features available in NLSRC.
In contrast, NFD's RIB responds to ControlCommands immediately. Even if the remote registration times out, nfdc will receive a prompt response.
Updated by Junxiao Shi almost 9 years ago
Reply to note-7:
It's semantically wrong to return a regular Data.
When a prefix is not being served by a producer, a network NACK will be returned.
Alternately, the producer (disabled PrefixUpdateProcessor) may return a producer generated NACK.
Either one shall be sufficient for nlsrc to detect the feature is disabled.
Updated by Vince Lehman almost 9 years ago
Junxiao Shi wrote:
Reply to note-7:
It's semantically wrong to return a regular Data.
When a prefix is not being served by a producer, a network NACK will be returned.
Alternately, the producer (disabledPrefixUpdateProcessor) may return a producer generated NACK.
Either one shall be sufficient fornlsrcto detect the feature is disabled.
Can you confirm that patch set 4 (commit: d33e5bc4750765d59ae7c1b7084bf5ef4fc28946) implements a producer generated NACK correctly?
Updated by Vince Lehman almost 9 years ago
- Status changed from Code review to Closed
- % Done changed from 90 to 100