I am ok with the suggested mod on broadcast and suggestion on not to mention mutli-purpose frames.
-Subir On Thu, Jul 23, 2015 at 4:40 AM, Tero Kivinen <[email protected]> wrote: > Xavier Vilajosana writes: > > what about this more explicit text: > > Looks better. > > > "The IEEE802.15.4 header of all frames MUST include the Sequence > > Number field, the Source Address field and the Destination Address > > field and only the Destination PANID. Frame Version field MUST be > > set to 0b10 (Frame Version 2). > > > > When using DATA, ACKNOWLEDGEMENT, MAC COMMAND frame types the > > source and destination address fields MUST be filled with an > > extended address (64 bit) and this be indicated in the corresponding > > Frame Control field. The Destination PANID MUST be present, the > > Source PANID MUST be elided and the PANID Compression bit MUST be > > clear (0). > > > > When using BEACON frame types, the destination address field MUST be > > filled by a short addresses (16bit), the source address field MUST > ^^^^^^^^^^^^^^^^^ > > I would change to be "a broadcast short address" to be clear why we > use short address there. > > Note, that there is also cases where beacons are not send to broadcast > address (i.e. when beacon request commands are used) but I think that > case is not for minimal. > > > be filled with an extended address (64 bit) and this be indicated in > > the corresponding Frame Control field. The Destination PANID MUST be > > present, the Source PANID MUST be elided and the PANID Compression > > bit MUST be set (1)." > > > > Question: Do we cover with this a) people sticking to current 2012 > > amendment as published today, b) people sticking to new version > > coming soon? > > For a) I cannot say, as it depends how the implementors resolved > internal conflicts in the standard. For b) answer is yes. > > > Question: Should we say something about Multipurpose frames? > > This is one of the problems with 802.15.4e-2012. Multipurpose frames > DO NOT USE this format at all. There is no PAN ID Compression field, > and there is only one PAN ID field in the header at all... So table 2a > should not have mentioned multipurpose frame at all. > > The multipurpose frames have only one "Destination PAN Identifier" > which is optional, and no "Source PAN Identifier" at all. Whether the > "Destination PAN Identifier" is present depends on the "PAN ID > Present" field in the "MP Frame Control", so the rules for them are > completely different. > > That means I do not think we need to mention them here, especially as > I do not think they are required for any minimal use cases. > -- > [email protected] > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
