--- This message came from the IEEE 802.11 Working Group Reflector ---
All, Please be aware that on the ARC SC call yesterday, there was discussion about the value of clause 6 (we believe there is some) and the format/style of clause 6 (which we believe is not very useful or efficient for conveying what is of value. For reference/background, I’d refer you to document: https://mentor.ieee.org/802.11/dcn/21/11-21-1822-01-0arc-clause-6-discussion.docx, which is a useful start, but I’ll add some of the comments that seemed important: - Part of clause 6, for example subclause 6.2, uses a “template” style to introduce a lot of SAP primitives without pages of text for each one that are largely duplicated boilerplate. Perhaps this style can be applied to much of subclause 6.3, somehow.
- There are some (many?) service primitives in 6.3 where the parameters to the primitive and the fields in the resulting frames do not exactly match. This is an important point, and helps clarify what is within 802.11’s scope to completely define (behavior that is entirely within the MAC and MLME), versus items that are provided from an “external” entity such as the SME or upper layer. Association is a good example of this, where many aspects of the Association frames are clearly provided by the MAC/MLME themselves, and not from any external source.
- Some service primitives do not map directly to frames at all, and the explanation of how the external interaction across the MLME-SAP results in protocol (or not), is important to understanding the difference between what we specify within 802.11 and what we leave to external entities. For example, MLME-SCAN, MLME-JOIN, the use of MLME-SETKEYs, etc.
Based on the points above, ARC has decided to pursue a better way to express what it meaningful/useful from clause 6, without all the duplicated boilerplate – saving not only hundreds of pages in the spec, but also a lot of (usually problematic) new material being created with every amendment that adds protocol. This email is to: - Alert the WG members to this activity, so anyone with interest (or concern!) can get involved.
- Check with the WG members whether anyone thinks heading in this direction is bad/wrong/not allowed for some reason. And, if so, please let us know!
Thanks for your consideration. Mark Hamilton Chair, 802.11 ARC SC
To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1 |