Re: [Roll] [roll] #3: Need Clarification on Candidate Neighbor

["Pascal Thubert (pthubert)" <pthubert at cisco.com>]

Hi Jonathan and Mathilde

>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.

Pascal