Dear Tero, Yes we are refering to the 2nd last line of table 2.a.
Most of us know that you are right and what you are indicting makes sense. However vendors have already implemented or are implementing what an standard document says (w.r.t table 2.a). At this point and understanding that we had some consensus on only citing work that is already published as standard we need to refer to table 2.a as it is now (in the 2012 version). This is strange but if we adopt the changes proposed in some of this mentor documents, how do we ensure that everybody that has implemented or is implementing 15.4e (2012) will follow this amendments which are not part of any standard yet. What others think, does anybody have experience on such situations? regards, X 2015-07-06 11:10 GMT+02:00 Tero Kivinen <[email protected]>: > Xavier Vilajosana writes: > > The PANID Compression bit in the Frame Control Field of the MAC > > Header MUST be clear (0b0) and source and destination addresses > > and the destination PANID MUST be present in the header according > > to the Table 2.A in [IEEE802154-2012]. This requires that the > > Source and Destination Addressing Modes bits of the Frame Control > > Field of the MAC Header MUST be both set to 0b11 (0x3). > > If I read that right, you are saying that we use 2nd last entry in the > table 2a, where both source and destination addreses are present, > frame version is 0b10, but where we do NOT have source PAN ID, but do > have destination PAN ID, and PAN ID compression is set to 0. > > Looking at the 15-15-0130-03 document, at least Ben Rolfe tought that > entry in the table 2a is incorrect. I.e. the second last entry in the > table 2a should still have BOTH source and destination PAN IDs. > > > https://mentor.ieee.org/802.15/dcn/15/15-15-0130-03-0mag-proposed-pan-id-compression-table.docx > > If the 2nd last line in table 2a is correct, there is no way to send > frame version 0b10 frames which has both source and destination PAN > IDs in it, and I have understood that this feature is something that > is actually used. > > -- > [email protected] >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
