Michael,
I agree on putting the rank to the maximum value
to code that the network is not interested in accepting more members,
thus, keeping their internal data private.
Regards,
Diego
Le dim. 23 sept. 2018 à 17:38, Michael Richardson <mcr+i...@sandelman.ca> a
écrit :
>
> Georgios Z. Papadopoulos <georgios.papadopou...@imt-atlantique.fr> wrote:
> > Many thanks for this work. Going through the draft, I have a
> > comment/question :
>
> > Considering that “The containing Enhanced Beacon is not encrypted.”
> > (Section 3), is it necessary to include “rank priority” at L2 and,
> > thus, revealing this information?
>
> I consider it a concern as well.
>
> When returning from a deep sleep, where there may be multiple
> LLNs on different PANIDs (and in 6tisch, with different schedules, even
> using
> different sets of channels), there is a desire to know which network will
> "closer".
>
> I think that we need to understand the tradeoffs, so let's discuss
> (also in the ROLL WG!). Perhaps a compromise is that the rank priority can
> be forced to maximum value on networks that want to keep the information
> private.
>
> --
> Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-
>
>
>
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
--
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - Universidad Diego Portales - Chile
www.ingenieria.udp.cl
(56 2) 676 8125
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
