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