On February 21, 2020 at 3:21:29 PM, Michael Richardson wrote: > Alvaro Retana wrote: > > The text you propose helps a little, but it makes me uneasy that a > > significant part of the (1!) structure defined in a Standards Track > > document is experimental. Also, the fact that the WG does not in > > general have a clear prescription and that there's work to be done in > > RPL, makes the text sound speculative. > > > It would be more appropriate (again, for a Standards Track document) to > > simply declare the specific use and determination of the different > > priorities as out of scope (vs the subject of future research). You > > might still want to include a separate non-normative section (or an > > appendix) to deal with "future work", but having that discussion while > > the fields are being specified does not seem right to me. > > I understand your point. > I think that it's not much different than BGP4's MED attribute. > I think that 80% of operators still have no idea how to set it :-)
Very different! Setting policies in BGP is not straight forward for some, specially when some of the attributes interact with someone else's policy, which is unknown. Operators may have a hard time setting the MED, but its behavior is clearly specified. > We don't know how to *set* the value, but we *do* know how to interpret > different values. Interpreting and acting on the values is exactly the piece I have a problem with. The rank priority is an "indication of how willing this 6LR is to serve as an RPL [RFC6550] parent". How is the receiver expected to that the value into account for parent selection? That part is not specified. The same for the pan priority; the text says that a receiver "MAY consider this value when looking for an eligible parent device", ok...how? Alvaro. _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
