Thomas Watteyne writes: > [returning from vacation this week, catching up on e-mail] > > Tero, > > About > > The text "set its own PAN ID to 0xffff" is old text that should not be > here in minimal anymore. The 802.15.4-2011 section 5.1.2.1.2 did that > to get past the receive filters, but this had some other issues, and > this text was removed in 802.15.4-2015 and the issue was solved > properly. > In 802.15.4-2015 the issue was fixed so that the section 6.7.2 > Reception and rejection has special text saying that filtering is not > done based on normal filtering rules if we are doing scanning, but > instead the MAC layer will process frames are described in the > relevant subclause of 6.3.1... > > Good catch. I propose the following change: > > OLD: > While listening for EBs, setting its own PAN ID to 0xFFFF allows a node to > join any PAN. > Otherwise it will only join a network matching its PAN ID <xref target= > "IEEE802154-2015"/>. > As per this specification, the selection of the PAN ID is out of scope. > NEW: > Nodes follow the reception and rejection rules as per Section 6.7.2 of <xref > target="IEEE802154-2015"/>.
Thats ok. > About synchronization, the mechanism is very well understood, also > by the authors of minimal. YOU have pointed out that, since EB are > not secured with K2, using them for time sync is not recommended > after K2 is learnt. I do NOT want to restart that whole discussion > and suggest to keep the text currently in -17. I was not proposing the initial change, that was somebody else saying that we should not use EBs after we have K2, and Xavi agreed. Then I pointed out that whether we have K2 or not is irrelevant. We should only use EB if we do not have any other timekeeping sources, and if we have any other timekeeping source, we should not use EB... -- [email protected] _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
