zilongwang/ReadingBank huggingface dataset:
CID Page Line Type Comment Proposed Change 178 8 4 T "As defined in frame format" is not a valid Type, especially as a specific cross reference to the definition of frame format is not given Insert the correct cross reference or provide a complete stand-alone type definition 187, 188, 203, 213, 225, 228, 230, 237, 241, 244 , 254, 255, 256, 261, 266, 273, 274, 279, 290 See clause/page/line number in comment database respectively T As the same as CID178 T Proposed resolution: Revised. In the of the type of DMG Capabilities in the corresponding table in REVmc4.0 (P179L34) is “DMG Capabilities element”. So change the table at P8L4 in 11aj D1.0 accordingly and make cross-reference for the referred subclause number as follows: Name Type Valid range Description CDMG Capabilities CDMG Capabilities element As defined in frame format As defined in 8.4.2.172 (CDMG Capabilities element) … QMG Capabilities QMG Capabilities element As defined in frame format As defined in 8.4.2.182 (QMG Capabilities element). … Do the same in the tables at P8L1~15, P8L41~57, P9L15~31, P10L1~15, P10L32~47, P11L7~22, P11L50~65 and P12L32~52.
CDMG Capabilities … As defined in 8.4.2.172 (CDMG Capabilities element) The values from the CDMG Capabilities element if such an element was present in the Probe Response or DMG Beacon frame, else null. The parameter is optionally present only if is true; otherwise not present. Do not adopt QMG Capabilities … As defined in 8.4.2.182 (QMG Capabilities element). The values from the QMG Capabilities element if such an element was present in the Probe Response or DMG Beacon frame, else null. The parameter is optionally present only if is true; otherwise not present. Do not adopt QMG Operation … As defined in 8.4.2.183 (QMG Operation element). The values from the QMG Operation element if such an element was present in the Probe Response or DMG Beacon frame, else null. The parameter is optionally present only if is true; otherwise not present. Do not adopt Do the same in the tables at P8L41~57, P9L15~31, P10L32~47, P11L7~22, P11L50~65 and P12L32~52. CID Clause Page Line Type Comment Proposed Change Remark
204, 232, 238, 248, 275, 284, … … … T As the same as CID189 As the same as CID189 Proposed resolution: Revised. Insert corresponding clause number and cross reference where applicable. See resolution to CID185 above. CID Clause Page Line Type Comment Proposed Change Remark 272 8.3.1.10 26 51 T Insert the following figure and paragraphs at the end of 8.3.10: Wrong ref. Should be 8.3.1.10 per comment Proposed resolution: Accept. Change the editing instruction as follows: “Insert the following figure and paragraphs at the end of 8.3.1.10:” CID Clause Page Line Type Comment Proposed Change Remark
Identifiers Comment Proposed change CID 7529 Mark RISON 9.3.3.15 647.8 There is no reason Action No Acks can't have MICEs. While at the moment it may be the case that such frames carry "information [...] that is of time critical but transient value" (resolution of CID 6343), this is not a property of Action No Acks per se Add MICEs to Table 9-39 as in Table 9-38 Discussion: There are ~70 instances of “Action No Ack”. None of them indicate that Action No Acks are only for “information [...] that is of time critical but transient value”. Indeed, to the contrary, 9.6.20.5 Information Response frame format indicates that an Information Response frame (which has a category of DMG, which per Table 9-47 does not receive privacy) may be broadcast in an Action No Ack. Proposed changes: Change Table 9-39—Action No Ack frame body to: Order Information 1 Action Last – 1 One or more vendor-specific elements are optionally present. Last The Management MIC element (MME) is present when management frame protection is enabled at the AP, the frame is a group addressed robust Action No Ack frame, and the category of the Action No Ack frame does not receive privacy as indicated by Table 9-47 (Category values). Proposed resolution: REVISED Make the changes shown under “Proposed changes” for CID 7529 in <this document>, which effect the requested change. Note to the commenter: the information in Information Response frames is not “information [...] that is of time critical but transient value”. Identifiers Comment Proposed change CID 7349 Mark It was stated during D4.0 comment resolution (*cough*Adrian*cough*) that "transmission of the Beacon at TBTT is a famously individual and unnamed channel access function" Add a subclause on this CAF Discussion:
IEEE P802.11 Wireless LANs (LB200) TGah D1.0 PHY Comment Resolutions on Annex E Date: 2014-03-17 Author(s): Name Affiliation Address Phone Email Eugene Baik Qualcomm Technologies, Inc 5775 Morehouse Dr. San Diego, CA 92121 eugeneb@qti.qualcomm.com Minho Cheong ETRI This document provides PHY resolutions for CIDs on Annex E, including: 2634 2635 2795 1785. CID Page Clause Comment Proposed Change Resolution 2634 Peter 371.50 E.1 Minho In sub-1 GHz bands, global classes are only needed for bandwidths and bands. Table E-4 uses several classes for 1 MHz bandwidth when only one per country/band combination is necessary. Reduce the redundant classes to just unique combinations of channel spacing and band (ANA+7 and ANA+8; ANA+9 and ANA+10 are same channel spacing in different bands, so they require two operating classes). Replace values with the minimum set globally for bandwidth and band. Commenter will propose a comment resolution. REVISED. See revised text in doc
Make the changes shown under “Proposed changes” for CID 7500 in <this document>, which effect the requested change, allowing specification of coverage classes up to 900 m in 10 m increments. Identifiers Comment Proposed change CID 7572 Mark RISON 6.3.19.1 222.31 "If the Direction element of the SetKeyDescriptor indicates Transmit or Both then the MAC uses the key information for the transmission of all subsequent frames to which the key applies." -- it should be clearer this applies to the Key ID also, i.e. all subsequent frames transmitted for that type and peer specify the Key ID given As it says in the comment CID 7604 Mark RISON 6.3.20.1.2 224.15 Why is "Valid range" N/A for the Key ID in MLME-DELETEKEYS.request? Copy the corresponding cell in MLME-SETKEYS.request Discussion: Something needs to specify the Key ID to be used for transmission of encrypted frames. I originally thought this had to be the MLME-SETKEYS.request primitive, since no other request primitive, other than seems to carry a Key ID. However, Jouni MALINEN thinks that actually it’s the MAC that picks the Key ID (in an implementation-defined manner). MLME-PN-EXHAUSTION.indication and MLME-PN-WARNING.indication have N/A for the Key ID, needs to be addressed too. Proposed changes: Change 223.44 as follows: — If the Direction element of athe SetKeyDescriptor indicates Transmit or Both then the MAC uses the key information (as defined by the Key and Length elements) for the transmission of all subsequent frames to which the key applies (as defined by the Key Type, Key ID and Address elements). Change 224.34 as follows: Receipt of this primitive causes the MAC to delete all the temporal keys identified by eachthe DeleteKeyDescriptors in the Keylist (as defined by the Key Type, Key ID and Address elements), and to cease using them. At 224.15, 484.5 and 484.46 change “N/A” to “0–3 shall be used with WEP, TKIP, CCMP, and GCMP; 4–5 with BIP; and 6–4095 are reserved”. Change 12.9.2.2 onwards as follows:
Font size error at 1766.42 (after “NOTE”), 163.36 and 165.11 (in “SAE”), 2052.41 (in “else if”), 159.17 (in “SelectedBSS”). References: 802.11mc/D5.0
IEEE P802.11 Wireless LANs Feb 2016 TGmc Fort Lauderdale BRC Agenda Date: 2016-02-24 Author(s): Name Affiliation Address Phone email Dorothy Stanley Hewlett Packard Enterprise 1322 Crossman Ave Sunnyvale, CA 94089 +1 630-363-1389 The agenda for this week is: 1. Call to order, attendance, and patent policy 2. Editor report, see 3. Comment resolution (see 4. AOB 5. Adjourn 22 Feb Monday AM1 9-noon - Graham Smith (90 mins) (7278, 7280, 7281, 7282, 7287, 7382, 7397, 7292) 7087, 7088 Mark Rison (90 mins) PM1 1-3pm - Adrian Stephens CIDs (120 mins) Editor owned discuss/review: 7144, 7230, 7265, 7266, 7268, 7392, 7685, 7744, 7804 includes discuss needed on 7162, 7630, 7605 11-16-273 to be posted Editorial Discuss CID 7686 (resolution to reflector, discuss resolution with any like CIDs) PM2 3:30-5:30pm - Emily Qi
IEEE P802.11 Wireless LANs Feb 2016 TGmc Fort Lauderdale BRC Agenda Date: 2016-02-25 Author(s): Name Affiliation Address Phone email Dorothy Stanley Hewlett Packard Enterprise 1322 Crossman Ave Sunnyvale, CA 94089 +1 630-363-1389 The agenda for this week is: 1. Call to order, attendance, and patent policy 2. Editor report, see 3. Comment resolution (see below) 4. AOB 5. Adjourn 22 Feb Monday AM1 9-noon - Graham Smith (90 mins) (7278, 7280, 7281, 7282, 7287, 7382, 7397, 7292) 7087, 7088 Mark Rison (90 mins) PM1 1-3pm - Adrian Stephens CIDs (120 mins) Editor owned discuss/review: 7144, 7230, 7265, 7266, 7268, 7392, 7685, 7744, 7804 includes discuss needed on 7162, 7630, 7605 11-16-273 to be posted Editorial Discuss CID 7686 (resolution to reflector, discuss resolution with any like CIDs) PM2 3:30-5:30pm - Emily Qi
S1G STA does not set the More Data field to 1 if it does not have any MSDUs or buffered for transmission to the frame's recipient during the current SP or TXOP. 33 20 how to set more data field when MMPDUs buffered for transmission? change 'MSDUs or A-MSDUs' to 'individually addressed data or management type frames' Revised. Editorial Instruction: make changes as shown in 11-14/361r0 33 21 The term " receipient" is not specific enough. It is better to the frame address, e.g. "...to the STA whose address appear in the RA field" as in comment Reject. “frame receipient” is broadly used in 802.11 baseline specification. 33 24 the term SP or TXOP implies EDCA. Since S1G devices may use DCF as well, make the sentence more generic. As stated in comment. Reject. As defined in 11ah draft, A S1G STA that support one access category act as if the access category is AC_BE. It is still QoS STA. 8.2.4.1.8 More Data field TGah Editor: Insert the following after 6th paragraph of sub-clause 8.2.4.1.8: S1G STA, the More Data to 1 to indicate that the S1G STA has MSDUs or A-MSDUs buffered for transmission to the frame's recipient during the current SP or TXOP. An S1G STA does not set the More Data to 1 if it does not have any MSDUs or A-MSDUs buffered for transmission to the frame's recipient during the current SP or TXOP.
CID Clause Page Line Comment Proposed Change 7127 17.3.10.3 2295 23 "The power difference between the interfering and the desired channel is the corresponding adjacent channel rejection." -- channels don't have powers. Relate to powers of objects that have a power attribute. Make same changes in other phys and non-adjacent test if this text occurs there too. Discussion: Line 2295.23: Referring to line 2295.23, the term “adjacent channel rejection” refers to the measure of signal power from the desired and the interfering channels. A proposed resolution is to change “The power difference between the interfering channel and the desired channel” to “The difference in signal power between the interfering and the desired channel”. Throughout the draft, there are TBD additional appearances as follows. Line 2296.6: A proposed resolution is to change “The power difference between the interfering channel and the desired channel” to “The difference in signal power between the interfering and the desired channel”. Line 2315.59: A proposed resolution is to change “The power difference between the interfering channel and the desired channel” to “The difference in signal power between the interfering and the desired channel”. Line 2400.26: A proposed resolution is to change “The power” to “The difference in signal power”. Line 2400.36: A proposed resolution is to change “The power” to “The difference in signal power”.
IEEE P802.11 Wireless LANs Resolution for some GEN comments in SB1 – Part II Date: 2016-02-22 Author: Name Affiliation Address Phone Edward Au Huawei Technologies 303 Terry Fox Drive, Suite 400, Ottawa, Ontario K2K 3J1 This submission presents proposed resolution to CIDs 7574, 7575, 7127, 7406, 7407, 7401 and 7402. Changes indicated by instructions. Revision history: R0 – initial version R1 – remove CIDs 7701 and 7702 from the document. R2 – remove CID 7403 from the document. R3 – update as per the changes made in the BRC meeting on February 24. CID Clause Page Line Comment Proposed Change 7574 C.3 3074 14 "is a 77 bit subfield" -- what is this doing in the MIB? Call it a bitmap instead Discussion: Referring to line 3074.14, and Figure 9-333, Rx MCS Bitmasks subfield is of length 77 bits, but the commenter is correct that it is not necessary to describe the subfield and its corresponding length in MIB. Resolution:
A proposed resolution is to change “The difference between the interfering channel and the desired channel” to “The difference in power between the signals in the interfering channel and the desired channel”. Line 2400.57: A proposed resolution is to change “The difference between the interfering channel and the desired channel” to “The difference in power between the signals in the interfering channel and the desired channel”. Line 2400.65: A proposed resolution is to change “The power difference between the interfering channel and the desired channel” to “The difference in power between the signals in the interfering channel and the desired channel”. Line 2586.55: A proposed resolution is to change “The power difference between the interfering channel and the desired channel” to “The difference in power between the signals in the interfering channel and the desired channel”. Line 2587.59: A proposed resolution is to change “The power difference between the interfering channel and the desired channel” to “The difference in power between the signals in the interfering channel and the desired channel”. Line 2588.16:
Context: It seems reasonable that an A-MSDU could be used in this context. Certainly, if the A-MSDU contains only one MSDU (the A-MSDU ‘wrapper’ being used for other purposes), then this seems perfectly fine. It is less clear if the polling non-AP STA was expecting and can handle getting multiple MSDUs contained in an A-MSDU. However, since such a STA has negotiated the use of A-MSDU for transmission to it, and the limits on such use, it seems reasonable that those same limits would be workable for the STA while in power save. Thus, the proposal is to accept this change. Proposed Resolution: ACCEPTED. Can we just use “BU” instead? No proposed resolution, yet: CID Page Clause Comment Proposed Change 7146 Stephens, Adrian 134.10 5.1.5.1 A role-specific behaviour is not shown for a DMG relay. If security on a DMG relay is established for each leg of the relay, then the data-flow must pass through the controlled port, and therefore be shown in the role-specific behaviour. Determine whether to show a role-specific behaviour for a DMG relay, which would be similar to a mesh STA. 7150 Stephens, Adrian 3581.01 Annex N Annex N contains terminology that is unique to itself, such as WLAN system and ACM_STA. The understanding of what a DS is has developed and change in the ARC standing committee, resulting in changes to Clause 5. Annex N has been ignored. Review Annex N and change terminology and architecture to conform to the normative portions of the draft. 7069 Stephens, Adrian 854.62 9.4.2.31 " An incoming MSDU that is not classified to a particular TS may be classified to another active TS based on the frame classifier for that TS." - normative verb in clause 9 Move normative behaviour to clause 10/11.
CID Page Clause Comment Proposed Change Resolution 9004 The IEEE 802.11ah amendment defines more than 30 new frames and a bunch of those NDP frames. It is hard for me to believe that no new frame exchange sequences were introduced. Yet the amendment doesn't have an Annex G. Identify the new frame sequences introduced by 11ah and add an Annex G. Rejected- The commenter does not indicate specific changes that would satisfy the comment. The detailed discussion for CID 9004 can be found from the below URL. Discussion: Regarding the Annex G Please refer the following discussion of REVmc. 188 Annex G does not cover all HT sequences Extend Annex G to cover all HT sequences. Otherwise deprecate it, but make sure it's not the only place where some rule or other is expressed Discussion: The 802.11n sequence are largely complete. AFAIK, it is only the aspect of Beamforming training that is not fully covered. And it may be that this is indeed covered, although I haven’t done the work to show this. We have normative references to G. In REVmb days, Annex G was for a time informative. Then we discovered the normative references, and so we made it normative. Any change to deprecate Annex G would necessarily require that it be made informative and any normative references removed. Proposed Resolution: Rejected. The commenter does not indicate specific changes that would satisfy the comment. The same concern arisen by the BRC is that the Annex G is not a requirement of any amendment. The 802.11ad and 802.11af amendments did not amend Annex G to add its frame exchanges either.
9.44.1 Overview TGah Editor: Insert the following text at the end of clause 9.44.1: An S1G STA with dot11SFExchangeCapable set to true shall set the SF Exchange Capable field in the S1G Capabilities element to 1. An S1G STA with dot11SFExchangeCapable set to false shall set the SF Exchange Capable field in the S1G Capabilities element to 0. A S1G STA shall not use the speed frame exchange procedure to transmit frames to another S1G STA whose SF Exchange Capable field is equal to 0.
“HT Operation” is in MLME-SCAN.confirm (Probe Response and Beacons), AND MLME- START.request “Valid Range: as defined in 9.4.2.57 (HT Operation Element)” “A bitmap size 128 bits” RESOLUTION: REVISE At P159.33 and P202.5 Add the following to the “Valid Range” entry of “OperationalRateSet”: “Only data rates in dot11SupportedDataRatesRxTable may be present” Mark R suggests At 159.30 (JOIN.req): Set of integers A value in or in Table 9-77 and corresponding to a supported feature (for each integer in the set) Non-DMG BSS: The set of data rates and features that the STA is able to use for communication within the BSS. The STA is able to receive at each of the data rates listed in the set and with each of the features listed in the set. This set is a superset of the rates contained in the parameter in the SelectedBSS parameter. DMG BSS: The set of MCS indexes that the STA uses for communication within the BSS. At P201.54 BSSBasicRateSet Add the following to the “Valid Range” entry of “BSSBasicRateSet”: “Only data rates present in dot11SupportedDataRatesRxTable and dot11SupportedDataRatesTxTable may be present” Mark R Suggests At 201.52 (START.req): MembershipSelector
Comment Proposed change CID 7278 Mark RISON 6 144.01 In Clause 6, when an OperationalRateSet is passed down in MLME-JOIN/START.request, it can't include rates not in dot11SupportedDataRatesRxTable Add this caveat to the "Valid range" cell (where it currently says 1-127). Make a similar statement about HT-MCS and VHT-MCSes CID 7280 Mark 201.52 The BSSBasicRateSet can't include rates not in both dot11SupportedDataRatesRxTable and dot11SupportedDataRatesTxTable Add this caveat to the "Valid range" cell (where it currently says 1-127). Make a similar statement about HT-MCS and VHT-MCSes CID 7281 Mark RISON 150.51 126 and 127 are not valid "rate"s (they're BSS membership selectors) Change "1-127" to "1-125" here and at the top of the next page CID 7282 Mark RISON 159.30 126 and 127 are not valid "rate"s (they're BSS membership selectors) Change "1-127" to "1-125" CID 7283 Mark RISON 173.47 126 and 127 are not valid "rate"s (they're BSS membership selectors) Change "1-127" to "1-125" and add a row for BSSMembershipSelectorSet CID 7284 Mark 177.36 126 and 127 are not valid "rate"s (they're BSS membership selectors) Change "1-127" to "1-125" CID 7285 Mark RISON 187.29 126 and 127 are not valid "rate"s (they're BSS membership selectors) Change "1-127" to "1-125" and add a row for BSSMembershipSelectorSet CID 7286 Mark RISON 190.50 126 and 127 are not valid "rate"s (they're BSS membership selectors) Change "1-127" to "1-125"
221 19 23 T "On receipt of this primitive, the MLME constructs and attempts to transmit a DCT Request The STA in general constructs the frame, unlikely the MLME alone Replace: "On receipt of this primitive, the MLME constructs and attempts to transmit a DCT Request frame" with "On receipt of this primitive, the STA constructs and attempts to transmit a DCT Request frame" 297 19 65 T "On receipt of this primitive, the MLME constructs and attempts to transmit a DCT Request The STA in general constructs the frame, unlikely the MLME alone Replace: "On receipt of this primitive, the MLME constructs and attempts to transmit a DCT Request frame" with "On receipt of this primitive, the STA constructs and attempts to transmit a DCT Request frame" 226 17 28 T "On receipt of this primitive, the SME operates according to the procedure in 10.47 (DCT Procedure)." Is it only the SME that operates in the procedure in 10.47, or is it rather the STA in total? Replace "On receipt of this primitive, the SME operates according to the procedure in 10.47 (DCT Procedure)." With "On receipt of this primitive, the STA operates according to the procedure in 10.47 (DCT Procedure)." 260 20 44 T "On receipt of this primitive, the MLME constructs and attempts to transmit a DCT Response frame" The STA in general constructs the frame, unlikely the MLME alone Replace: "On receipt of this primitive, the MLME constructs and attempts to transmit a DCT Response frame" with "On receipt of this primitive, the STA constructs and attempts to transmit a DCT Response frame" 4
179 18 4 T "On receipt of this primitive, the MLME constructs and attempts to transmit a DCT Measurement Report frame." the MLME does not construct nor transmit the frame Replace "On receipt of this primitive, the MLME constructs and attempts to transmit a DCT Measurement Report frame." with "On receipt of this primitive, the STA constructs and attempts to transmit a DCT Measurement Report frame." 202 16 1651 T "On receipt of this primitive, the MLME constructs and attempts to transmit a DCT Measurement Request frame." The MLME does not construct nor transmits a frame. Replace: "On receipt of this primitive, the MLME constructs and attempts to transmit a DCT Measurement Request frame." with "On receipt of this primitive, a DCT Measurement Request frame is constructed and transmitted by the STA." 219 21 22 T "On receipt of this primitive, the MLME constructs and attempts to transmit a DCT Response frame" The STA in general constructs the frame, unlikely the MLME alone Replace: "On receipt of this primitive, the MLME constructs and attempts to transmit a DCT Response with "On receipt of this primitive, the STA constructs and attempts to transmit a DCT Response frame" 34
“6.3.116.6.4 Effect on receipt this primitive, the the MAC sublayer construct and attempt to transmit a DCT Request frame.” Similarly, change the sentence in P20L45 as follows: “6.3.116.8.4 Effect on receipt this primitive, the MLME the MAC sublayer construct and attempt to transmit a DCT Response frame.” CID297: “6.3.116.7.4 Effect on receipt Once the SME receives receipt of this primitive, the SMESTA operates according to the procedure defined in 10.47 (DCT Procedure).” CID226: “6.3.116.3.4 Effect on receipt Once the SME receives receipt of this primitive, the SMESTA operates according to the procedure defined in 10.47 (DCT Procedure).” CID264: “6.3.116.5.4 Effect on receipt Once the SME receives receipt of this primitive, the SMESTA operates according to the procedure defined in 10.47 (DCT Procedure).” CID Comment Proposed Change Remark
Extended Cluster Report (see ) 255 <ANA> Yes No Cluster Switch Announcement (see ) 255 <ANA> Yes No Enhanced Beam Tracking (see ) 255 <ANA> Yes No SPSH Report (see ) 255 <ANA> Yes Yes Clustering Interference Assessment (see ) 255 <ANA> Yes No QMG Capabilities (see ) 255 <ANA> Yes No QMG Operation (see ) 255 <ANA> Yes No Operating Mode Notification (see ) 255 <ANA> Yes No QMG Link Margin (see ) 255 <ANA> Yes No QMG Link Adaptation Acknowledgment (see ) 255 <ANA> Yes No Insert Element ID Extension subfield into the format of the elements defined in 8.4.2.172 through 8.4.2.186. See the revised CDMG Capabilities element format as an example: Figure 8-581a (CDMG Capabilities element format) Element ID Length Element ID Extension STA Address AID1 CDMG STA Capability Information CDMG AP or PCP Capability Information Octets: 1 1 1 6 1 4 1 CDMG Capabilities element format
CID Page Clause Comment Proposed Change Resolution 9061 The reason given for rejecting i-437 asserts that the BRC has no idea what is MAC functionality and what is MAC service interface. This reinforces the commenters assertion that there is inappropriate text in the and that the change is inconsistent with the base standard. Remove all changes to the 802.11 MAC contained in this amendment. Delete clauses 5, 6, 9, 10, 11, and 12 from this draft amendment. Rejected- TGah BRC reviewed the sub-clause 11.50 (S1G BSS operation) to find inappropriate texts in MLME clause. But, the BRC can not identify which operation is considered as the MAC functionality. 11.50 (S1G BSS operation) is describing the BSS operation and almost texts are well aligned with the reference sections, 10.40 (VHT BSS operation) and 10.43 (Basic TVHT BSS functionality) of 802.11 base specification. It fails to identify changes in sufficient detail so that the specific wording of the changes that will satisfy the commenter can be determined. CID Page Clause Comment Proposed Change Resolution 9062 The reason given for rejecting i-436 asserts that the BRC has no idea what is MAC functionality and what is MAC service interface. This reinforces the commenters assertion that there is inappropriate text in the clause and that the change is inconsistent with the base standard. Remove all changes to the 802.11 MAC contained in this amendment. Delete clauses 5, 6, 9, 10, 11, and 12 from this amendment. Rejected- TGah BRC reviewed the sub-clause 11.49 (System information update procedure) to find inappropriate texts in MLME clause. But, the BRC can not identify operation is considered as the MAC functionality. 10.49 (System information update procedure) is describing the system information update mechanism and almost texts are well aligned with the reference section, 10.2.2.17 (TIM
BSS type and STA type) and its content to a new subclause 10.59a (S1G BSS type and STA type). CID Page Clause Comment Proposed Change Resolution 9063 The reason given for rejecting i-432 asserts that the BRC has no idea what is MAC functionality and what is MAC service interface. This reinforces the commenters assertion that there is inappropriate text in the clause and that the change is inconsistent with the base standard. Remove all changes to the 802.11 MAC contained in this amendment. Delete clauses 5, 6, 9, 10, 11, and 12 from this draft amendment. Revised – The following BRC’s response to comment was incorrect “The BRC can not identify which operation is considered as the MAC functionality.” The BRC has agreed to move the text to the MAC subclause, inline with the general comment. TGah Editor: Move "11.48 (Dynamic AID assignment operation)" to a location between 10.20 and 10.21 (so this subclause becomes the new 10.21). Also rename it to "S1G dynamic AID assignment". . CID Page Clause Comment Proposed Change Resolution 9061 The reason given for rejecting i-437 asserts that the BRC has no idea what is MAC functionality and what is MAC service interface. This reinforces the commenters assertion that there is inappropriate text in the clause and that the change is inconsistent with the base standard. Remove all changes to the 802.11 MAC contained in this amendment. Delete clauses 5, 6, 9, 10, 11, and 12 from this draft amendment. Revised – The following BRC’s response to comment was incorrect “The BRC can not identify which operation is considered as the MAC functionality.” The BRC has agreed to move the text to the MAC subclause, inline with the general comment. TGah Editor: Move the full subclause "11.50 S1G BSS operation", except for 11.50.7, to a new subclause 10.42.”
9035 Alfred 91.26 9.3.1.1 The "Next TWT Info Present field" is using the location that was signaling "Power Management" for a non-AP STA. Since this is overloaded then non-AP STA transmitting this frame cannot indicate a PM switch. Instead of having this PM limitation suggest using B15 for Next TWT Info Present and leave B12 as PM. Replace "Next TWT Info Present" with Management" and "Reserved" with Next TWT Info Present". Same consideration for STACK/BAT in 9.8.4.1. Revised – the TGah editor shall replace "Next TWT Info Present" with "Power Management" and "Reserved" with Next TWT Info Present". Same consideration for STACK/BAT in 9.8.4.1. 9038 Alfred 154.52 Two issues, one obvious and the other one as well. Issue 1: "shall" cannot be used in this subclause so maybe replace by will. Issue 2 that can supercede the first one. This sentence was added because of a comment stating that AP cannot send as such it cannot ask for an announced TWT, limiting its behavior. instead of that why not simply say that an AP simply sends trigger frames, and not PS-Polls? Revised – in subclause 9.4.2.196 TWT element, TGah editor shall delete the sentence “A TWT requesting STA, which is an AP shall set the value of the Flow Type subfield to 1.” and after the second to last paragraph of 10.44.1 TWT overview, the TGah editor shall add a note with the following text: “NOTE - A TWT requesting STA that is an AP does not send PS-Poll frames, but it can send APSD trigger frames.” Discussion: None. Proposed changes
IEEE P802.11 Wireless LANs CID 7452 Date: 2016-04-01 Author: Name Affiliation Address Phone Edward Au Huawei Technologies 303 Terry Fox Drive, Suite 400, Ottawa, Ontario K2K 3J1 This submission discusses on the accepted resolution of CID 7452 that need additional inputs to editors. Revision history: R0 – initial version CID Clause Page Line Comment Proposed Change Resolution 7452 8.3.5.1.4.2 559 40 "The RXVECTOR represents a list of parameters that the PHY provides the MAC entity upon receipt of a valid PHY header or upon receipt of the last PSDU data bit in the received frame." -- can't be sent before the end, by definition. I'm not sure why the values in the PHY-RXSTART.ind can't be used, either Delete this sentence REVISED (MAC: 2016-02-25 15:06:47Z): Delete "upon receipt of a valid PHY header or" Discussion: In this comment, the author refers to 559.40 and clause 8.3.5.14.2. However, 559.40 is actually in clause 8.3.5.13.2, rather than 8.3.5.14.2. To make things worse, the sentence quoted by the commenter exists in both clauses!
CID Clause Page Line Comment Proposed Change 7355 C.3 2925 16 "When this attribute is false, the STA may accept MSDUs that have the Protected Frame subfield of the Frame Control field equal to 0." -- so it might not? What does "accept" mean here, exactly? Delete this sentence Discussion: At line 2997.27 in D5.2: Referring to clause 12.9.1 (WEP frame pseudo-code) at line 2091.36 (D5.2), when the dot11ExcludeUnencryted is false, the STA receives the MSDUs without WEP decapsulation: Resolution: Revised (page and line numbers from D5.2) At line 2997.39, replace “may accept” with “receive”. CID Clause Page Line Comment Proposed Change 7437 C.3 2875 55 There are 5 instances of "fixed-point Part". However, the whole thing is fixed-point; what is being referred to is actually the integer part Change "fixed-point Part" to "integer part" in all 5 instances Discussion: There are only three instances of “fixed-point part” in D5.2 as follows. At line 3128.40 in D5.2: At line 3256.17 in D5.2: At line 3370.39 in D5.2:
IEEE P802.11 Wireless LANs Resolution for some PICS and MIB comments Date: 2016-04-01 Author: Name Affiliation Address Phone Email Edward Au Huawei Technologies 303 Terry Fox Drive, Suite 400, Ottawa, Ontario K2K 3J1 This submission presents proposed resolution to CIDs 7556, 7767, 7355, 7437 and 7438. Changes indicated by instructions. Revision history: R0 – initial version R1 – updated as per the discussion in April-1st call. CID Clause Page Line Comment Proposed Change 7556 B.4 2681 1 CFDMG and CFDMGSTA are the same thing Change all CFDMGSTAs to CFDMGs and delete the CFDMGSTA row Discussion: CFDMG and CFDMGSTA are the same thing and majority of the contents in clause B.4 reference CFDMG. Resolution: Revised (page and line numbers from D5.2) [1] Delete CFDMGSTA row at lines 2732.23 – 2732.26 [2] Change all CFDMASTAS to CFDMGs throughout the draft except the following 2 instances: (a) At line 2731.49, is the CFDMG row, delete “CFDMGSTA:M” (b) At line 2821.30, which is the QoS frame format row, change “CFDMGSTA and CFDMG:M” to “CFDMG:M”. CID Clause Page Line Comment Proposed Change
Wu, Tianyu MediaTek Inc. Yes Wu, Zhanji Beijing University of Posts and Telecommunications (BUPT) No Xin, Yan Huawei Technologies Co. Ltd Yes Xing, Weimin ZTE Corporation Yes YAGHOOBI, HASSAN Intel Corporation No Yamada, Akira NTT DoCoMo, Inc. Yes Yang, Ou Intel Corporation Yes YANG, RUI InterDigital, Inc. Yes Yang, Xun Huawei Technologies Co. Ltd Yes Yang, Yunsong Huawei Technologies Co. Ltd Yes YAO, KE ZTE Corporation Yes Yee, Peter NSA/IAD Yes Yokota, Hidetoshi Landis Gyr Group Worldwide No Yoshii, Isamu Panasonic Corporation No Yu, Jian Huawei Technologies Co. Ltd Yes Yunoki, Katsuo KDDI R&D Laboratories Yes Zeng, Kun Huawei Technologies Co., Ltd Yes Zhang, Hongyuan Marvell Semiconductor, Inc. Yes ZHANG, JIAYIN Huawei Technologies Co. Ltd Yes Zhang, Xingxin Huawei Technologies Co. Ltd Yes Zhang, Yan Marvell Semiconductor, Inc. Yes Zhu, Chunhui Huawei Technologies Co. Ltd Yes Annex B : Working Group Officers Working group Name (Affiliation) Position Contact Details Adrian Stephens (Intel Corporation UK Ltd.) IEEE 802.11 Working Chair Co-Technical Editor 802.11 Assigned Numbers Authority +44 1793 404825 (office) Jon Rosdahl (Qualcomm) 1st Vice Chair (Policies and Procedures) Treasurer +1 (801) 492-4023 Dorothy V. Stanley (HPE) 2nd Vice Chair (Rules and reflectors) IEEE 802 (LMSC) EC delegate +1 (630) 363-1389 Stephen McCann (BlackBerry Ltd.) Secretary Publicity ad-hoc Chair +44 1753 667099
Peter Ecclesine (Cisco Systems, Inc.) Co-Technical Editor +1 (408) 527-0815 Standing Committees Name (Affiliation) Position Contact Details Jim Lansford (CSR Technologies Inc. a Qualcomm Company) Wireless Next Generation (WNG) Chair +1-719-286-8660 Mark Hamilton (Ruckus Wireless) Architecture (ARC) Chair +1 (303) 441-7553 Andrew Myles (Cisco Systems, Inc.) ISO/IEC/JTC1/SC6 shadow committee (JTC1) Chair +61 2 84461010 Rich Kennedy (Unlicensed Spectrum Advocates) Regulatory Chair +1 (832) 298-1114 Jon Rosdahl (Qualcomm ) Project Authorization Request (PAR) review Chair +1 (801) 492-4023 Task Groups Name (Affiliation) Position Contact Details Dorothy V. Stanley (HPE) TGmc Chair (Revision mc) +1( 630) 363-1389 Yongho Seok (Self) TGah Chair (Sub 1 GHz Operation) +82-10-7581-0828 Hiroshi Mano Techno Info K.K.) TGai Chair (Fast Initial Link Setup) +81-3-5436-8350 Xiaoming Peng (Institute for Infocomm Research) TGaj Chair (China Millimeter Wave) +65-64082429 Donald Eastlake, 3rd (Huawei Technologies) TGak (General Link) +1 508-333-2270 Stephen McCann (BlackBerry Ltd.) TGaq (Pre-association Discovery) +44 1753 667099 Osama Aboul-Magd (Huawei) TGax Chair (pro-tem) (High Efficiency WLAN) +1 (613) 287-1405 Edward Au (Huawei) TGay Chair (Next Generation 60 GHz) +1 773 782 6875 Jonathan Segev (Intel Corporation) TGaz Chair (Next Generation Positioning) +972-54-2403587 Study Groups Name (Affiliation) Position Contact Details Topic Interest Groups
B17-B18 Coding 2 B17 set to 0 for BCC and 1 for LDPC If B17 is 1, B18 is set to 1 if the LDPC PPDU encoding process (of an SU PPDU), results in an extra OFDM symbol (or symbols) as described in 22.3.10.5.4 (LDPC coding), otherwise set to 0. If B17 is 0, B18 is reserved and set to 1. B19-B22 MCS 4 MCS Index B23 Smoothing 1 A value of 1 indicates that channel smoothing is recommended. A of 0 indicates that channel smoothing is not recommended. SIG-2 B0 Aggregation 1 Set to 1 when aggregation is ON (A-MPDU), and 0 otherwise. Note: S1G PPDUs shall be transmitted with aggregation ON whenever PHY payload size is greater than 511 octets B1-B9 Length 9 Denotes the length of PPDU in number of symbols when aggregation bit is set to 1, and in number of octets when aggregation bit is set to 0. B10-B11 Response Indication 2 This field indicates the presence and type of frame a SIFS after the current frame transmission. Set to 0 if No Response. Set to 1 if NDP Response. Set to 2 if Normal Response. Set to 3 if Long Response. B12 Doppler 1 Set to 1 to indicate traveling pilots usage in packet. Otherwise 0 to indicate regular pilot tone locations. B13 NDP Indication 1 Used to indicate that frame is a Control NDP frame. If set to 1, then the SIG field contents follow the description in 8.3.5 (NDP MAC frames) B14-B17 CRC 4 CRC calculated as in 24.3.8.2.1.5 (CRC calculation for S1G SIGA fields). B18-B23 Tail 6 Used to terminate the trellis of the convolutional decoder. Set to 0. .
Code Meaning See subclause Robust addressed privacy 22 S1G 9.6.25 (S1G Action frame details) No No 23 S1G 9.6.26 (S1G Action frame details) Yes No 24 Flow control 9.6.27 (Flow Control Action frame details) Yes No Control Response MCS Negotiation 9.6.28 (Control Response MCS Negotiation frame details) Yes No TGah Editor: Change the subclauses below (including headers) as follows (#10011): S1G Action frame details Action field The Action field values are specified in Table 9-417o (Action field values). Action field values Action field value Description 0 Reachable Address Update 1 Relay Activation Request 2 Activation Response -255 Reserved
and NSS Set field, indicates the channel widths and maximum NSS values per width supported by the STA. See 1.40 (VHT BSS operation). Set subfield and Extended NSS BW Support subfield at a STA transmitting the VHT Capabilities Information field). In a TVHT STA, the field is reserved. In a STA with , this is set to 0. Replace Table 9-246 (Setting of the Supported Channel Width Set and Extended NSS BW Support subfield at a STA transmitting the VHT Capabilities Information field) as shown: MCS
11.40.8 Extended NSS BW Support Signaling Modify subclause 11.40.8 (Extended NSS BW Support Signaling) as shown: If dot11VHTExtendedNSSBWCapable is false, a STA shall set the Extended NSS BW Support subfield of the VHT Capabilities Information field to 0 in VHT Capability elements that it transmits, otherwise, the subfield may be set to 1, 2 or 3 as indicated in 9.4.2.158.2 (VHT Capabilities Information field). If dot11VHTExtendedNSSBWCapable is false, a STA shall set the VHT Extended NSS BW Capable subfield of the Supported VHT-MCS and NSS Set field to 0 in VHT Capability elements that it transmits, otherwise, the subfield shall be set to 1.
00-0F-AC 12 Authentication negotiated over IEEE Std 802.1X or using PMKSA caching as defined in 12.6.10.3 (Cached PMKSAs and RSNA key management) using a Suite B compliant EAP method supporting RSNA key management as defined in 12.7 (Keys and key distribution) or using PMKSA caching as defined in 12.6.10.3 (Cached PMKSAs and RSNA key management) Defined in 12.7.1.7.2 (Key derivation function (KDF)) using SHA-384 References:
group of S1G STAs using Multicast ID, S1G AP may indicate the group of STAs in segment count element (8.4.2.170c) of DTIM beacon and transmit their multicast data at assigned TIM interval or time slots sequentially for their reception." “When S1G AP has data buffered for a of S1G STAs that belong to a Multicast AID, it indicates this condition in the page slice element (8.4.2.170c) transmitted in a DTIM beacon. The S1G STAs that detect this indication will wake up at the assigned beacon interval to determine the TIM and extract the assigned time slots that carry the buffered multicast data. The S1G AP transmits the buffered multicast data within the assigned time slots for the S1G STAs’ reception.” 2604 212 6 9.51 The word "13 bits" is not necessary. Delete "13 bits" Accepted 2770 211 51 9.51 Segment count element is used only for TIM segmentation that can be used to indicate Page Segment i.e. a group of AIDs but not an individual AID. It is not clear why STA can check whether S1G AP may have their buffered multicast data to deliver within the current DTIM interval by checkinig the DTIM beacon. It is not clear why "If S1G AP has multicast data to deliver to the group of S1G STAs, the group of S1G STAs will receive the multicast data at the assigned time slots" unless a RAW is used for such Please clarify Revised – The text is changed to “When S1G AP has data buffered for a group of S1G STAs that belong to a Multicast AID, it indicates this condition in the page slice element (8.4.2.170c) transmitted in a DTIM beacon. The S1G STAs that detect this indication will wake up at the assigned beacon interval to determine the TIM and extract the assigned time slots that carry the buffered multicast data. The S1G AP transmits the buffered multicast data within the assigned time slots for the S1G STAs’ reception.” Hope it’s clear.
CID 1870 Shunsaku Shimada CID 1875 Shunsaku Shimada CID 2186 Tomo Adachi CID 2750 Yujin Noh Comment Assignment Robert assigned people for the comments currently Next Call The next call is scheduled on Thursday, April 28th, 2016 from 10:00 (ET). AOB No other business to conduct. Adjourn Meeting adjourned at 21:57 (ET). List of Attendees Name Affiliation 1 Osama Aboul-Magd Huawei Technologies 2 Tomo Adachi Toshiba 3 Jinsoo Ahn Yonsei Univ. 4 Alfred Asterjadhi Qualcomm 5 David Bagby Calypso Ventures 6 Stéphane Baron Canon 7 Rui Cao Marvell 8 Xiaogang Chen 9 Chitrakar Panasonic 10 Jinsoo Choi LG Electronics 11 Chu Marvell 12 Sean Coffey RealTek 13 Yonggang Fang ZTE 14 Matt Fischer Broadcom 15 Chittabrata Ghosh 16 Brian Hart Cisco Systems 17 Reza Hedayat Newracom 18 Po-Kai Huang Intel 19 Yasuhiko Inoue NTT 20 Junichi Iwatani NTT 21 Kaushik Josiam Samsung 22 Jeongki Kim LG Electronics 23 Geonjung Ko Institute 24 Young Hoon Kwon Newracom 25 Zhou Lan Broadcom 26 Daewon Lee Newracom 27 Jae Lee ETRI 28 Yanchun Li Huawei 29 Meilu Lin Huawei Technologies 30 Jing Ma NICT 31 Narenda Madhavan Toshiba 32 Yuichi Morioka Sony 33 Kome Oteri InterDigital 34 Jayh Park LG Electronics 35 Dengyu Qiao Huawei Technologies 36 Kiseon Ryu LG Electronics 37 38 Sigurd Schelstraete Quantenna Communications 39 Yongho Seok Newracom 40 Shoko Shinohara NTT 41 Robert Stacy 42 Bo Sun ZTE 43 Yusuke Tanaka Sony 44 Sriram Venkateswaran Broadcom 45 Lochan Verma Qualcomm 46 Sameer Vermani Qualcomm 47 Lei Wang Marvell 48 Xiaofei Wang InterDigital 49 Tianyu Wu MediaTek 50 Weimin Xing ZTE 51 Ross Jian Yu Huawei Technologies 52 53 54 55
IEEE P802.11 Wireless LANs TGmc May 2016 Teleconference Agendas Date: 2016-05-09 Author(s): Name Affiliation Address Phone email Dorothy Stanley Hewlett Packard Enterprise 1322 Crossman Ave Sunnyvale, CA 94089 +1 630-363-1389 Note that BRC meetings and teleconferences are subject to IEEE policies and procedures, see: – – – – – – – – Teleconference meeting May 6th, 2016 We will use the webex dial-in bridge listed below: Fri, May 6, 7:00 am | 3 hr San Francisco (Pacific Daylight Time, GMT-07:00) When it's time, start the meeting from here: Audio Connection US TOLL Access code: 195 473 794 The draft agenda is: 1. Call to order, attendance, and patent policy 2. Editor report – 8 CIDs in “Editor Review” state 3. Comment resolution (see below) 11-16-276- CIDs 7278 et al – Mark Rison – 20 mins CID 7772 – Graham Smith (reassociation list) – 20 mins 11-16-228 – Graham Smith – 20 mins Mark Rison CIDs – 30 mins Solomon Trainin -11-16-0566-00-000m NAV setting fixes in DMG network (fix for recently found error) – 15 mins 11-16-0567-00-000m BSS intention in DMG discovery beacon (resolve issue introduced in document 406) – 15 mins Motions (20 mins): MAC (11-16-565r41) 4. AOB
May 2016 – Waikoloa (6 timeslots) Tuesday PM1 – 11-16-554 Menzo, CID 7698, 7658, 7674 11-15-0292 - Peter E – CID 7170, 7103, 7220 Adrian CIDs – including CID 7111 Tuesday PM2 – CIDs 7074, 7077, 7075 (Ganesh) 30 mins CID 7396 – Mark Rison –delayed block ack impact question Wednesday PM1 Wednesday PM2 – Motions 11-15-1184 – Dan (Opportunistic Wireless Encryption) Thursday AM1 Thursday PM1 Thursday PM2 Motions Last motion number on May 6th teleconference was 218; continue with 219: Motion 219 on CID 7532 (OMN extenstion to non-VHT): Move to approve the comment resolution to CID 7532 in the “Motion CID 7532” tab in Moved: Seconded: Result: Motion on CID 7553 (Clause 4 mesh PMKSA): Move to approve the comment resolution to CID 7553 in the “CID 7553” tab in Moved: Seconded: Result: Motion on CID 7177 (Support indicating preference for not receiving LDPC): Move to approve the comment resolution to CID 7177 in the “Motion CID 7177” tab in Moved: Seconded: Result: Motion: Approve the comment resolutions in the following document and tabs indicated and incorporate the indicated text changes into the TGmc draft: “Motion MAC-BT” Tab in document TBD “GEN-“ in document TBD “Editor – name: in document TBD
IEEE P802.11 Wireless LANs Resolutions for CIDs 20082, 20160, 20169 and 20080 on 11ai/D7.0 Date: 2016-05-13 Author(s): Name Company Address Phone email Mark Hamilton Ruckus Wireless 350 W. Java Dr Sunnyvale, CA +1.303.818.8472 Jae Seung Lee ETRI 161 Gajeong-dong, Yuseong-gu, Daejeon, Korea +82 42 860 1326 Stuart Ruckus Wireless 350 W. Java Dr Sunnyvale, CA +1.408.348.3171 Peat Khoury Ruckus Wireless 350 W. Java Dr Sunnyvale, CA +1.415.517.8715 peat@curious-peter-george.com CIDs 20160, 20082, 20080: CID Page Clause Comment Proposed Change 20169 98.39 11.1.4.3.2 FILS provides mechanisms to prevent wasting bandwidth with unnecessary Probe Requests, and Probe Responses that won't be useful to the client STA due to varying criteria. Large bandwidth savings can also be achieved by eliminating useless Probe Responses that come too late to be useful. Change "may" to "shall". Throughout the rest of the document, make it mandatory to include Max Channel Time field in Probe Requests for FILS STAs. The onerous implementation costs for Max Channel Time are on the AP, and that has been resolved by making the AP response to Max Channel Time a "should" requirement in the last ballot cycle. 20160 98.39 11.1.4.3.2 Max Channel Time: Comment: FILS provides mechanisms to prevent wasting bandwidth with unnecessary Requests, and Probe Responses that won't be useful to the client STA due to varying criteria. Large bandwidth savings can also be achieved by eliminating useless Probe Responses that come too late to be useful. Change FILS Stay from MAY to SHALL: Make it mandatory to include Max Channel Time field in Probe Requests for FILS STAs. The onerous implementation costs for Max Channel Time are on the AP, and that has been resolved by making the AP response to Max Channel Time a "should" requirement in the last ballot cycle. Align this position throughout the rest of the document.