July 2009doc.: IEEE 802.11-09/0714r2

IEEE P802.11
Wireless LANs

802.11 TGmb Discussion on Big Editorial Issues
Date: 2009-07-15
Author(s):
Name / Company / Address / Phone / email
Adrian Stephens / Intel Corporation /

Goals of this session

The goal of the REVmb editorial discussion session is to discuss each of the big issues and see if a consensus position of the editors as a whole can be identified.

The issues

Document Structure

CID / Page / Clause / Comment / Proposed Change
1116 / General / It seems kind of silly to have the DSSS and HR/DSSS clauses separated, or the OFDM and ERP clauses separated, and the MLME/PLME clauses are not widely needed by implementers. / Reorder clauses as 1-2-3-4-5-7-9-8-11-11A-14-16-15-18-17-19-6-12-10-13.
1240 / 981 / Annexes / Spot the commentor who started his review with the annexes ! 1) The annexes have built up over time to be many and varied. They also fall into 4 classes: normative, informative, and useless(Annex C). Please can the annexes be re-arranged into some sort of order - see column to right for a suggestion. 2) Annex 0A appears to be a bit lost and needs a name change - see column to right for a suggestion / 1) I suggest that the annexes should be all clearly marked normative/informative (and useless if you really have to). Then order them with normative first and informative last, e.g. A, I, J, D, Q and then the informative ones. 2) Annex 0A should be re-named annex R (or annex S to avoid the R=Bibliography, as opposed to R=Reference confusion) and put at the end.

Discussion:

  1. We can reorder clauses if we want
  2. Constraint: (IEEE-SA style): Bibliography should be first or last Annex.
  3. Non-live references create problems if we restructure the standard. REVmb editor has attempted to seek out and modify these, but there is no guarantee that all have been found.
  4. People are comfortable with concept of a “Clause 19” device.
  5. Existence of Clause 11A will already force some kind of renumbing.

Proposal:

  1. Reorder Annexes, starting with Bibliography, then all normative Annexes, then all informative.
  2. TBD renumbering of Clauses

Notes from meeting:

  • OK with annex renumbering
  • 1-2-3-3A-4-5-6-10-12-13-7-9-11-8-11A-14-16-15-18-17-19

Frame Conventions

1368 / 7, 9, 11, etc. / The conventions described in 7.1.1 are not clear and complete enough. E.g.: - Does "data frame" mean "frame of type Data" or "frame of subtype Data (+ whatever)", and if the latter (i.e. excludes the CF-only ones) does it or does it not include QoS? Note a distinction between "data frame" and "Data frame" is poor, because the distinction vanishes at the start of a sentence. - Does "QoS data frame" (note lowercase d) include e.g. "QoS Null"? Some of this may be helped by saying "MSDU" instead of "frame", but not all. / Extend section 7.1.1 to describe conventions pertaining to the term "data frame" and related terms. Ensure that text in other sections conforms to these conventions.

Discussion:

This author finds these conventions confusing too. On the other hand, I’ve always found a way to interpret what the text means.

Perhaps the commenter is trying to read too much into distinctions such as case, because I’m not aware of any semantic significance.

Notes: write rejection inviting more detail.

1707 / 134.31 / 7.3.2.21 / Consistency in describing Reserved bits. There are three variations: (i) All other bits are reserved. (ii) All other bits are reserved and are set to 0. (iii) All other bits are reserved; and are set to 0 upon transmission and ignored upon reception. In most cases, (i) is what should be used. Cl. 7.1.1 clearly describes what reserved means. / Limit description of reserved fields/ bits to "is/are reserved".

Discussion:

I’ve always found the repeated “shall be set to 0 on transmission and ignored on reception” annoying.

Proposal:

Scan Clause 7 for reserved and remove any spurious specification of behaviour in Clause 7.

Notes: OK

1358 / 7, 11, etc. / The word "frame" is used too loosely. Sometimes it refers to a MSDU or MMPDU, rather than an MPDU forming part of a fragmented MSDU or MMPDU. This affects, for example, whether the PM mode can change during a fragmented MSDU or MMPDU. / Add "Also known as a frame." to the definition of MPDU in section 3. Throughout the spec, change uses of "[data/management] frame" to "MSDU or MMPDU"/"MMPDU"/"MSDU" where appropriate. Simplify "Management frame of subtype Foo" to "Foo MMPDU".

Discussion:

As far as this author is concerned, frame and MPDU are synonyms. Packet and PPDU are synonyms.

If there are any occurances of “frame” that refer to all or part of an MSDU or MMPDU, this is an error. Clause 11.2 is ripe with these errors. I have separately reported them in my own comments.

Looking at the changes proposed:

  1. Add "Also known as a frame." to the definition of MPDU in section 3.
  2. Adrian: No harm would be done, no objection
  3. Throughout the spec, change uses of "[data/management] frame" to "MSDU or MMPDU"/"MMPDU"/"MSDU" where appropriate.
  4. Adrian: While there may be individual error in a number of places (e.g. 11.2), the proposed change generally is an error. While a frame may contain all or part of an MMPDU or MSDU, it is not an MMPDU or MSDU.
  5. Adrian: The commenter should be solicited to discover which of the 275 instances of data frame or 198 instances of management frame are in error.
  6. Simplify "Management frame of subtype Foo" to "Foo MMPDU".
  7. Adrian: This embodies an error, IMHO. An MMPDU is not a frame. A management frame (and sometimes a data frame) may carry all or part of an MMPDU. Certainly we could replace a Management frame of subtype Foo to a Foo frame/MPDU, where it is defined in those terms (e.g. an Action frame). There are 15 such instances in REVmb

Proposal:

  1. Add frame as a synonym for MPDU in Clause 3.

Note from meeting: no convergence. write a rejection.

1248 / 184 / 7.3.2.27 / Figures 7-76 and 7-77 have inconsistent styles on the Octets row, one using arrows, the other not. / Determine which style is consistent and change all figures accordingly.

Discussion:

We have numerous different figure styles representing structures:

Type / Describes / What goes above / What goes in the boxed area / What goes below / Example / Number of instances in Clause 7
1 / Octet aligned structure / Octets size / Field names / Sub-Structure arrows and legends / Figure 7-1 / 11
2 / Bitfield structure / Bit locations per field / Field names / Bit sizes / Figure 7-2 / 14
3 / Bitfield structure / Bit locations per field. Field names / Field names / Bit sizes with arrows / 3
4 / Bitfield structure / Bit locations whole structure / Field names and values / Bit sizes / Figure 7-5 / 1
5 / Field with octet divisions / Bit locations whole structure / Field name and octet boundaries / Octet size with arrows / Figure 7-20 / 9
6 / Bitfield structure / Bit locations per field / Field names / Nothing / Figure 7-22 / 2
7 / Octet aligned structure / Nothing / Field names / Octet sizes / Figure 7-29 / 69
8 / Bitfield structure / Bit locations per field / Field names / Octet size with arrows whole structure / Figure 7-30 / 6
9 / Field / Bit locations / Field name / Octet size whole structure / Figure 7-36a / 3
10 / Structure with octet divisions / Nothing / Field names and octet boundaries / Octet sizes per field with arrows / Figure 7-37 / 4
11 / Octet aligned structure / Nothing / Field names / Octet sizes per field with arrows / Figure 7-38 / 21
12 / Read-down the page structure / Nothing / Field names / Nothing / Figure 7-48 / 2
13 / Structure with octet and subfield divisions / Nothing / Field names / Octet sizes per octet-aligned field with arrows / Figure 7-50 / 1
14 / Bitfield structure / Nothing / Field names / Bit sizes per field / Figure 7-59 / 3

Type 1: Octets size above, structure arrows below

Type 2

Type 3

Type 4

Type 5

Type 6

Type 7

Type 8

Type 9

Type 10

Type 12

Type 13

Type 14

The most popular octet-aligned structure style is without arrows. However there are 21 such figures with arrows.

Questions for discussion:

  • Should we attempt to retrospectively apply consistency to the draft (requiring the REVmb editor to redraw at least 21 figures in this case), or are we not bothered?
  • Should we deprecate certain figure forms and recommend others for new material (i.e. current drafts)?
  • Another (separate) issue is the poor quality of some figures. Many figures are drawn using tables. Others (particularly those with arrows) are graphics objects only available as .tif files. Is this a concern? Should there be a background task of redrawing these to improve the graphic quality?

Notes:

Bill grants me permission to do more work.

Francois says arrows only necessary where spanning structure. Best international standard likeness

Jon – some of the types identify particular information.

Action: accept comment.

Terminology

1535 / General / There are ~1000 instances of "true" of which, 3/4 use the lower-case form and 1/4 use the upper case form. There appears to be no rhyme or reason as to which to use for any particular purpose. / Research rules for capitalization of true and false, and then apply them consistently throughout the standard.
1217 / 93.58 / 7.2.3.1 / "is set to TRUE" appears many places, and "is true" appears many others. / make the upper/lower case "true" vs "TRUE" vs "True" consistent throughout the document. Make the "is set to" vs "is" consistent throughout the document.
1103 / 92.01 / 7.2.3.1 / Table 7-8 mixes up all sorts of MIB references. Sometimes variables "are true," sometimes they are "set to TRUE". Use one consistent method of reference. / I believe the TG has decided on "set to TRUE"?

Discussion:

There are two issues here:

  1. Capitalization
  2. “set to” language

While this author would prefer TURE and FLASE throughout, preferably with random additional permutations, the syntax for TruthValue defined in SNMPv2-TC uses the lower-case form. ASN.1 is case-sensitive, so using any other form when referring to the value of a MIB variable is an error.

Likewise, the SDL syntax uses the lower-case forms, and the lower-case forms are used whenever the words “true” and “false” are used in natural language (i.e., it is true to say the sun rises in the east).

Regarding “is set to”: this author has no strong opinion. There are multiple possible equivalent forms:

  • is set to
  • is
  • has the value
  • is set to the value

I’m guessing that these and more will exist in the standard, which means that automating the process of enforcing any particular convention will be expensive.

Proposal:

  1. Make all “true” and “false” lower case, except where they are part of pseudo-code or code.
  2. Do not attempt to enforce any particular convention for “is set to”.

Notes:

Action: Adrian ask IEEE-SA staff if there is any IEEE-SA style/convention concerning this.

No objection to proposal 1.

Straw poll 1: Do you care about the exact form of “is set to” language? 4,10

Bill has volunteered to work on this with the Author.

Action: Adrian will work with Bill to enable him to do this work in the frame sources.

1524 / General / The word "bit" is used, wrongly, as a synonym for "field" in a 1-bit sized field. This confuses purpose (a field) with representation (a single bit). / Replace all uses of the word "bit" that are not dependent in that context on the field being precisely 1 bit in size and that are not calling out individual bits from a bitfield.

Discussion:

As this author is also the commenter, he has nothing more to add.

Proposal:

Accept the comment

Note: no consensus at the meeting. Therefore reject the comment.

1086 / 1.01 / general / The terms broadcast/multicast, unicast/directed have been deprecated for use within IEEE 802. The appropriate terms are "group addressed" and "individually addressed". There are (rare) cases where it is valid to use the terms multicast and broadcast. Those cases are the instances where reference is being made to a non-IEEE protocol, for example an IETF protocol, where the the protocol is defined in terms of a broadcast or multicast construct. For example, the 802.11u and 802.11v amendments are known to introduce a few such instances into the 802.11 standard where a specific protocol is referenced or where the handling of group addressed MSDUs/frames is specified differently for broadcasts than it is for specific multicast group(s). When reference is made to IEEE 802 entities, mechanisms, procedures and constructs the terms "group addressed" and "individually addressed" are preferrable. / Throughout the draft, change "broadcast", "multicast", "broadcast or multicast", "broadcast and multicast" to "group addressed". Throughout the draft, change "unicast" to "individually addressed". The changes required for "directed" are more complex since this word is often used in other contexts. When "directed" in used in the context of "directed frame", "directed MPDU", or "directed MSDU" it should be changed to "individually addressed {identifier}".
1082 / 64.05 / 6.1.3 / The terms broadcast/multicast, unicast/directed have been deprecated for use within IEEE 802. The appropriate terms are "group addressed" and "individually addressed". / Change "broadcast and multicast MSDUs, relative to directed MSDUs" to "group addressed MSDUs, relative to individually addressed MSDUs"
1083 / 64.22 / 6.1.3 / The terms broadcast/multicast, unicast/directed have been deprecated for use within IEEE 802. The appropriate terms are "group addressed" and "individually addressed". / Change "broadcast and multicast MSDUs, relative to unicast MSDUs" to "group addressed MSDUs, relative to individually addressed MSDUs"
1084 / 64.25 / 6.1.3 / The terms broadcast/multicast, unicast/directed have been deprecated for use within IEEE 802. The appropriate terms are "group addressed" and "individually addressed". / Change "broadcast and multicast MSDUs" to "group addressed MSDUs"
1085 / 64.27 / 6.1.3 / The terms broadcast/multicast, unicast/directed have been deprecated for use within IEEE 802. The appropriate terms are "group addressed" and "individually addressed". / Change "unicast MSDUs" to "individually addressed MSDUs"

Discussion:

The terms “broadcast, multicast and unicast” were deprecated during REVma days. Why and who deprecated them is unknown. However it is clear that REVma only did a partial job of replacing such uses with individual/group.

Note, group addressed and “broadcast” are not synonyms. Replacing “broadcast” with “group addressed” would be making a technical change.

Proposal:

Review all uses of broadcast, multicast and unicast and replace as follows:

  • Unicast -> “individual” or “individually addressed” according to context
  • “multicast”, “broadcast / multicast”or “broadcast or multicast” -> “group” or “group addressed”according to context
  • “broadcast” remains the term to use when specifically referring to the broadcast address

Notes from meeting:

  • Some opposition to proposal.
  • Some lack of agreement as to meaning of “multicast” – i.e. whether it includes the broadcast address.
  • Action: Adrian to transfer comment to MAC ad-hoc.

1682 / 409.12 / 9.9.3.1.1 / (Submitted on behalf of Carlos Cordeiro) "local matter" is a weird term. / Replace "a local matter" by "implementation dependent"

Discussion:

We have lots of different ways of saying “it’s up to the manufacturer to sort this out”.

Should we prefer any particular way?

Is this particular form any more or less objectionable than any other?

This author has no strong opinion. He also has to confess to being author of the cited text.

Notes from meeting:

Accept comment

CID / Page / Clause / Resn Status / Comment / Proposed Change
1684 / 209.59 / 7.3.2.47 / MDIE should be refered to as the Mobility Domain element. / Delete the word "information" as appropriate throughout this clause for consistency with clause 7.3.2.

Discussion:

The word “information” carries little information. I suppose it distinguishes information from dis-information. However, it should be safe to assume that any 802.11 frame structure carries information.

When we had an abbreviation IE, “information” served one vanishingly small useful function of allowing this acronym to exist. That acronym was banished from REVmb, so even this marginal advantage has gone.

I believe we could replace all “information element” with “element” and not loose any information.

This does create a minor issue in that certain abbreviations such as the one cited by the commenter (MDIE) embed the phrase “information element”. If we were to banish this term, these abbreviations would also need consistent replacement.

Another issue is that 3 elements include “information” in the name of the element itself in table 7-26. I suppose that this means the ERP Information information element should be called just that if we wanted to :0).

Of the 54 elements in 7.3.2:

  • only 1 does not include “element” in the title (TIM)
  • only 13 include “information” in the title

And in table 7-26:

  • 3 include “information” in the name of the element (ERP, Antenna, Measurement Pilot Transmission)
  • none include “element” in the name of the element

Question:

  • Does anybody see any harm in banishing “information element”?
  • Does anybody see any value in it?

Proposal:

  • Replace all “information element” with “element” – except in the heading of 7.3.2.
  • Remove redundant “information” from name of elements in table 7-26
  • Globally replace any abbreviations that expand to <something> information element with new names (e.g. MDIE->MDE). There are 5 such occurances.

Notes: agreed in meeting.

Submissionpage 1Adrian Stephens, Intel Corporation