3233 1587.04 10.3.7 (1) Missing word "transmit" (2) It is not specified by what time the Information Response frame is supposed to be transmitted to each STA. This can be left or assigned a timing budget such as 5 seconds. Commenter's preference is to leave this but highlight that unsolicited Information Response transmission may not be "instantaneous" (suggested text does not adress this, a NOTE will be useful). (3) Commenter believes we normally use "association with a PCP" or "Association with an AP" than "association with PBSS". Suggest the following text for the first paragraph: "Following the association or security association of a STA with a PCP, the PCP shall transmit an unsolicited Information Response frame (8.6.20.5 (Information Response frame format(11ad)) to the broadcast address or individually to each to all the STAs associated with the PBSSPCP. The PCP shall set the Subject Address field of the Information Response frame to the broadcast address and shall include in the Information Response frame the DMG Capabilities element for the PCP and each STA associated with the PCPPBSS. This process is referred to as PBSS information distribution."
3675 1480.44 9.38.3.2 The acronyms I-TXSS and R-TXSS are specified in the definitions, but no text specifies what they are. They simply seem to be very infrequently used shorthand terms for "TXSS done by an initiator" and 'TXSS done by a repsonder". If that is all they are, then replace these acronyms in the figures and text with the descriptive names. On page.line 54.60 delete the I-TXSS line; On 58.53 delete the R-TXSS line. In figures and replace "I-TXSS" with "Initiator TXSS" and "R-TXSS" with "Responder TXSS". On 1491.15 replace with "Initiator TXSS". In figure replace "I-TXSS" with "initiator TXSS" Proposed resolution: Accept 3239 634.49 8.3.4 Are all Extension frames expected to have a common header? If yes, there should be a Section 8.3.4.1 ("Format of Extension frames") describing the common format. If no, it is still a good idea to have
that section (to be consistent with other frame types) and state in there that Extension frames are not expected to have a common header format Proposed Resolution: Revised Discussion: the original purpose for this frame type was to enable different frame structures following the Duration field. Therefore, the MAC header could potentially be different for different Extension frames. Proposed changes: Insert the following subclause 8.3.4.0 Format of Extension frames The format of Extension frames is defined in Figure 8-YY. The MAC Header of an Extension starts with the Frame Control field followed by the Duration field. The MAC Header of different Extension frames can have different number and types of fields following the Duration field. Octets: 2 2 variable variable … variable variable 4 Frame Control Duration <Field 0> <Field 1> … N> Frame Body FCS Figure 8-YY—Extension frame format 3668 1452.44 9.36.10 The only mentions of NAV_RTSCANCELABLE and NAV_DTSCANCELABLE in the standard are in 9.36.10. The only mentions of NAVSRC and NAVDST are on page 1446 and in 9.36.10. In 9.36.10 it is hinted that these identifiers and variables are somehow associated with some STAs, but Either provide technical specifications of identifiers and variables, including which STAs they apply to and how the information about them is exchanged between
3232 1009.01 8.4.2.136 It is not stated anywhere frame(s) are used to carry the Awake Window element. Add AwakeWindow to DMG Beacon and Announce frame body (Table 8-49 and Table or state in 8.4.2.136 that the element can be carried in DMG Beacon and Announce frames, or other solution. Proposed resolution: Revised Discussion: specify the change in 8.4.2.136. Proposed changes: 8.4.2.136 Awake Window element Change the first paragraph as follows The Awake Window element is defined as shown in Figure 8-520 (Awake Window element format(11ad)). 3392 1272.11 9.6 "A STA shall support the concurrent reception of fragments of at least three MSDUs or MMPDUs. [...] The destination STA shall maintain a Receive Timer for each MSDU or MMPDU being received, for a minimum of three MSDUs or MMPDUs." -- does this always apply (e.g. DMG STAs -- see end of 9.5 and 9.22.2.1; also what about the risk of MSDU/MMPDU reordering caused by concurrent If it doesn't apply to all STAs, add suitable caveats