Bug #2814
closed
Error: Expect prefix-update-validator section
Added by Junxiao Shi over 9 years ago.
Updated over 9 years ago.
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.
Looks like you are still using old configuration files?
Looks like you are still using old configuration files?
Yes, I am.
My point is: if this section is required, documentation should reflect so.
- Target version set to v0.2.1
- Assignee set to Vince Lehman
- Status changed from New to Code review
- % Done changed from 0 to 90
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.
Junxiao Shi wrote:
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.
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.
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.
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 (disabled PrefixUpdateProcessor
) may return a producer generated NACK.
Either one shall be sufficient for nlsrc
to detect the feature is disabled.
Can you confirm that patch set 4 (commit: d33e5bc4750765d59ae7c1b7084bf5ef4fc28946) implements a producer generated NACK correctly?
- Status changed from Code review to Closed
- % Done changed from 90 to 100
Also available in: Atom
PDF