I think the criteria for choosing as well as the maintenance of
neighbors and candidate neighbors should be left out of scope of the
core RPL specification. While we could say that candidate neighbors
are based on the set of REACHABLE neighbors, I don't think that
really
clarifies much since it doesn't define what a REACHABLE neighbor is
and/or implies that it is defined by RFC 4861 which may not be the
definition we want.
REACHABLE is a good starting point as long as we base our neighbor
loss
detection on NUD.
At least it is consistent. But we do want to be able to use other
neighboring mechanisms,
in that case the goal would be to have the equivalent of REACHABLE
with
that mechanism
as opposed to stick to 4861's REACHABLE, of course.
That being said, it might be appropriate to provide some suggestions
or implementation guidelines within the appendix to identify
important
parameters to consider. For example, some versions of the draft had
words saying that both the link quality metric *and* confidence in
the
link quality metric should be considered when choosing candidate
neighbors. Confidence is important since link qualities are
statistical values based on discrete samples over time.
We started discussing a companion Informational spec with
recommendation
such as FSM.
We figure a number of things today that might be wrong. We made the
draft pretty
Elastic to enable a large capability of tuning and adaptations to the
needs.
The risk of being too elastic and not enough specific being a lack of
interoperability
and the possibility to make an implementation that plain does not
work.
We are trying
to avoid that of course and I expect that the next rounds of review
like
IESG will be
sensitive to that aspect.
