mentor.ieee.org€¦ · XLS file · Web view · 2016-04-29Times New Roman,Bold" 4Month Year Times New Roman,Bold" 4 Times New Roman,Bold" 4doc.: IEEE 802.11-yy/xxxxr0 Times New

Month Year Title doc.: IEEE 802.11-yy/xxxxr0

Submission 1 Name, Company

IEEE P802.11 Wireless LANsSubmission

Designator: doc.: IEEE 802.11-16/0538r1Venue Date: April 2016First Author:Yongho Seok (NEWRACOM)

Subject: TGah SB1 comments on D7.0Full Date: 2016-04-28Author(s): Yongho Seok (NEWRACOM)

Address: 9008 Research Drive, Irvine, CA 92618Phone: Fax: email:

Abstract:[email protected]

This document contains working updates for comments submitted on TGah D7.0 SB2 (second sponsor recirculation ballot).

mailto:[email protected]

CID Commenter LB Draft Page(C) Line(C) Page

10001 1002 7 B4.4.2 537 1 T Yes 537.00

10002 Wang, Xiaofei 1002 7 63 33 T No 63.00

10003 Wang, Xiaofei 1002 7 10.6 353 50 T No 353.00

Clause Number(C)

Type of Comment

Part of No Vote

Aboulmagd, Osama

6.3.115.2.2

10004 Wang, Xiaofei 1002 7 10.44.2 302 46 T No 302.00

10005 Wang, Xiaofei 1002 7 10.44.8 305 6 T No 305.00

10006 Wang, Xiaofei 1002 7 10.52.2 340 11 T No 340.00

10007 Wang, Xiaofei 1002 7 10.52.2 339 37 T No 339.00

10008 Seok, Yongho 1002 7 9.9.2.1.1 223 21 E No 223.00

10009 Seok, Yongho 1002 7 10.52.6 347 14 T No 347.00

10010 Malinen, Jouni 1002 7 12.5.3.3.3 386 2 T Yes 386.00

10011 Malinen, Jouni 1002 7 9.6.25.12 201 25 T Yes 201.00

10012 Malinen, Jouni 1002 7 10.56 350 6 T Yes 350.00

10013 Malinen, Jouni 1002 7 J.6.4 619 19 T Yes 619.00

10014 Malinen, Jouni 1002 7 B.4.4.2 539 47 T Yes 539.00

10015 Malinen, Jouni 1002 7 B.4.28.1 555 4 T No 555.00

10016 Malinen, Jouni 1002 7 9.2.4.1.1 76 50 T No 76.00

10017 Malinen, Jouni 1002 7 12.5.3.3.3 385 33 T Yes 385.00

10018 Hamilton, Mark 1002 7 10.52.2 341 12 T Yes 341.00

10019 Hamilton, Mark 1002 7 9.4.2.202 175 20 T Yes 175.00


10021 Hamilton, Mark 1002 7 9.3.1.1 91 1 T Yes 91.00

10022 Hamilton, Mark 1002 7 G 611 0 T Yes 611.00

10023 Hamilton, Mark 1002 7 444 49 T Yes 444.0023.3.8.2.1.4


Line Clause Assignee Submission

1 B4.4.2 V Yongho Seok 11-16/0559r0

33 V Yongho Seok 11-16/0558r0

50 10.6 V Yongho Seok 11-16/0558r0

Duplicate of CID

Resn Status

Motion Number

6.3.115.2.2

46 10.44.2 J Yongho Seok 11-16/0558r0

6 10.44.8 V Yongho Seok 11-16/0558r0

11 10.52.2 V Yongho Seok 11-16/0558r0

37 10.52.2 A Yongho Seok 11-16/0558r0

21 9.9.2.1.1 A Yongho Seok 11-16/0558r0

14 10.52.6 A Yongho Seok 11-16/0558r0

2 12.5.3.3.3 A 11-16/0539r0Alfred Asterjadhi

25 9.6.25.12 V 11-16/0539r0Alfred Asterjadhi

6 10.56 V 11-16/0539r0

19 J.6.4 V 11-16/0539r0

Alfred Asterjadhi

Alfred Asterjadhi

47 B.4.4.2 A 11-16/0539r0Alfred Asterjadhi

4 B.4.28.1 A 11-16/0539r0

50 9.2.4.1.1 V 11-16/0539r0

Alfred Asterjadhi

Alfred Asterjadhi

33 12.5.3.3.3 V 11-16/0539r0

12 10.52.2 V 11-16/0540r0

Alfred Asterjadhi

Alfred Asterjadhi

20 9.4.2.202 J 11-16/0540r0

6 10.52.2 A 11-16/0540r0

1 9.3.1.1 V 11-16/0540r0

Alfred Asterjadhi

Alfred Asterjadhi

Alfred Asterjadhi

0 G V Yongho Seok 11-16/0559r0

49 V 11-16/0540r023.3.8.2.1.4

Alfred Asterjadhi

10 23.3.19 V 11-16/0540r0Alfred Asterjadhi

Comment Proposed Change Resolution

EDITOR

EDITOR

EDITOR

Owning Ad-hoc

I disagree with the resolution of CID 9004. The comment was rejected with the note, the commenter doesn't indicate specific changes to satisfy the comment. This is not true. The specific change is to create Annex G and define the main exchange sequences to be added to the annex. For example the draft identified all types of NDP frames, ACK, RTS, CTS, etc. At least the related seuqnces should be identified and added to the Annex.

Missing a normative Annex doesn't help. As in the comment, please create Annex G and identify the main exchange sequences to be added.

REVISED (EDITOR: 2016-04-28 20:54:50Z) - A current Annex G in the 802.11 spec does not cover all frame exchange sequences. But, as per request from the commenter, TGah BRC accepts to create Annex G for the main exchange sequences based on the NDP frames.

TGah Editor makes changes as shown in the as specified in 11-16/0559r0 (https://mentor.ieee.org/802.11/dcn/16/11-16-0559-00-00ah-sb2-comment-resolution-annex-g.docx).

The reachable address primitive has nothing to do with ELOPERATION

change to MLME-REACHABLEADDRESSUPDATE

REVISED (EDITOR: 2016-04-28 20:40:14Z) - Agree in principal.

TGah editor change “MLME-ELOPERATION.request” to “MLME-REACHABLEADDRESSUPDATE.request” at Page 63 Line 33.

The description of this condition contradicts with the condition at the start of TWT SP in the figure 10-104

reword the condition to match the figure

REVISED (EDITOR: 2016-04-28 20:45:37Z) - Agree in principal. TGah editor change “ the ELMaxAwakeTimer is 0” to “both ELMaxAwakeTimer and ELRecoveryTimer are 0” at Page 353 Line 46.

EDITOR

EDITOR

EDITOR

EDITOR

Why should the condition be restricted to STAs that are associated with the AP? Such a procedure will benefit STAs that previously are associated with the AP but had an outdated version of the system information by reducing overhead of the association/probe procedure.

Remove "associated with the S1G AP" from the referred sentence

REJECTED (EDITOR: 2016-04-28 20:42:50Z) - The restriction to an associated STA is because the purpose of 10.44.2 is for updating the system information.

Regarding the scanning enhancement by the commenter, the proposed mechanism is already defined in 11.1.4.3.7 (Enhanced FILS active scanning to preferred AP) of 802.11ai draft.

There is no reason to define two redundant features in our base specification.

Though S1G is defined as Sub 1 GHz, using the term S1G in this paragraph for systems such as 802.15.4 systems is confusing. In the majority part of the admendament, S1G means 802.11ah,such as S1G PPDU, S1G STA, etc., while that is not the case in 10.44.8.

Suggest to change "other S1G systems" into "other systems operating in the Sub 1 GHz band".

REVISED (EDITOR: 2016-04-28 20:44:47Z) - Agree with the commenter.

TGah editor: Replace "other S1G systems" with “ other systems operating in bands below 1 GHz".

The symbol Nmax is used in P340L55, however, this symbol is not clearly indicated here in L11, it would be more clear to include Nmax here so that readers of the spec can easily understand the context.

Add ", Nmax, " after "of STAs" in L11.

REVISED (EDITOR: 2016-04-28 20:45:17Z) - Agree in principle.

TGah editor: Insert ", N_max, " after "of STAs" in L11.

It states that "Relay Activation Element" may be included in Probe Request frames, however, Relay Activation Element has been removed from Probe Request frames. This is obviously a mistake that should be addressed. Similarly for Probe Request frames in L42.

Remove "and Probe Request frames" from the referred sentence. And remove ", Probe Request frames" from L42.

ACCEPTED (EDITOR: 2016-04-28 20:45:06Z)

EDITOR

EDITOR

EDITOR

In CID 8478 of an initial sponsor ballot,Comment:"The Bandwidth Indication field description is missing."Resolution:"REVISED (EDITOR: 2016-01-21 17:27:25Z)Insert "The Bandwidth Indication field is described in 8.2.4.1.11 (Bandwidth Indication and Dynamic Indication fields)." as the last paragraph of the subclause."

But, as a mistake of an TGah editor, the corresponding sentence is located in 9.9.2.1.1.

Move the last paragraph of 9.9.2.1.1 to the end of 9.9.2.1.2.


"A relay link is a two-hop link between a non-AP STA performing an active scan for S1G relays, and the S1Groot AP through the S1G relay."

An S1G Relay is not limited to a two-hop link any more.

In a second paragraph of sub-clause 10.52.6, change "two-hop" to "multi-hop".


The CCMP AAD description seems to claim that the Type subfield is only two bits (bits 3 and 4) in a PV1 frame. That does not match the definition of the Frame Control field (Figure 9-742) for a PV1 frame (9.8.3).In addition, there does not seem to be any need for masking the Type subfield bits in case of PV1. The AAD design is stronger if unnecessary masking is removed.Note: Approving this comment will result in a change needed to the CCMP test vector for PV1. I can provide such an update once the group has decided how to address all my comments that are applicable for CCMP.

On page 386 line 2, delete"1) Type subfield (bits 3, 4) in a Data MPDU masked to 0"and renumber the following items in the list.


EDITORThe Header Compression frame is defined as an S1G Action frame. Table 9-47 indicates that this Action frame category (22) is not Robust. As such, the Header Compression frame cannot be protected and a STA receiving such a frame would need to accept it without being able to verify that it is from an authorized station. Since this frame can be used to update header compression state, an attacker could use this frame to replace A3 and A4 information in frames with arbitrary values. Since the current CCMP AAD construction for PV1 frames does not protect A3/A4 fields in header compressed frames, this would be a critical security flaw in the design.There does not seem to be any technical constraint that should prevent making the Header Compression frame a Robust Action frame. That would allow the frame to be protected by negotiating use of management frame protection.

Replace the Category of the Header Compression frame to a value that is defined as a Robust Action frame (either use an existing Category with Robust=Yes in Table 9-47 or defined a new category for this).

REVISED (EDITOR: 2016-04-28 20:52:49Z) - Agree in principle with the comment. Proposed resolution is to move the Header Compression frame to a Robust Action frame and use a similar terminology that is used by DMG to differentiate between S1G and Unprotected S1G.

TGah editor to make the changes shown in 11-16/0539r0 under all headings that include CID 10011.

EDITOR

EDITOR

(Re)Association Request frames are not protected even if management frame protection is negotiated for the association. This makes it problematic to allow the Header Compression element to be included in (Re)Association Request/Response frame when using management frame protection. An attacker could use those unprotected frames to inject arbitrary A3/A4 values into header compression state and the current CCMP AAD construction for PV1 frames would not notice this.It would be good to disallow use of unprotected Header Compression element when management frame protection is being negotiated for the association to avoid such an attack.

On page 350 line 5, replace"An S1G STA with dot11PV1MACHeaderOptionImplemented equal to true may include a Header Compression element in (Re) Association Request frames, (Re) Association Response frames and in Header Compression frames."with"An S1G STA with dot11PV1MACHeaderOptionImplemented equal to true may include a Header Compression element in Header Compression frames and when management frame protection is not negotiated for the association, in (Re) Association Request frames and (Re) Association Response frames."

REVISED (EDITOR: 2016-04-28 20:53:06Z) - Agree in principle with the commenter. The proposed resolution accounts for the suggested change.

TGah editor to make the changes shown in https://mentor.ieee.org/802.11/dcn/16/11-16-0539-00-00ah-sb2-cids-miscellaneous-part-1.docx under all headings that include CID 10012.

I have number of comments that request changes to the CCMP AAD construction. If those changes (or other changes to the way AAD is constructed) are accepted, the CCMP PV1 test vector becomes invalid. I can provide an updated version of the test vector once the group has decided how to address the CCMP related comments.

Update the CCMP PV1 test vector, if needed. A submission with the updated values will be provided as soon as the exact CCMP changes are determined.

REVISED (EDITOR: 2016-04-28 20:53:51Z) - Agree in principle with the commenter. The proposed resolution accounts for the suggested changes.


EDITORThe PICS entries FT47.11 (Header Compression Request frame) and FT47.12 (Header Compression Response frame) use a frame name that is not defined anywhere in P802.11ah/D7.0. Only the "Header Compression frame" is defined and it looks like that same frame is used both as a request and response. Since FT47.11 and FT47.12 have different Status values, it is not immediately clear to me how these should be combined, i.e., it may not be fine to merge them into a single entry if the different Status column value is needed.Similarly, FR48.11 is for the undefined Header Compression Request frame, but in that case, there is no corresponding Response frame mentioned.

On page 539 line 47, replace the MAC frame column value for FT47.11"Header Compression Request frame"with"Header Compression frame as a request".

On page 539 line 49, replace the MAC frame column value for FT47.12"Header Compression Response frame"with"Header Compression frame as a response".

On page 543 line 47, replace the MAC frame column value for FR48.11"Header Compression Request frame"with"Header Compression frame".


EDITOR

EDITOR

Using capital Request/Response with "Header Compression" seems to imply that there is a frame or at least a term "Header Compression Request" and "Header Compression Response" defined somewhere in P802.11ah. No such definition exists, though. Maybe these should be referring to use of Header Compression frame as a request and as a response.

On page 555 line 4 (S1GM16.4), replace"Store the optional fields indicated in the Header Compression Request"with"Store the optional fields indicated in the Header Compression frame request".

On page 555 line 6 (S1GM16.6), replace"Send back the Header Compression Response"with"Send back the Header Compression frame response".

On page 574 line 44, replace"This attribute indicates the amount of time, in units of milliseconds, the STA waits before timing out a Header Compression Request."with"This attribute indicates the amount of time, in units of milliseconds, the STA waits before timing out a Header Compression frame request."


The description of a Frame Control field in S1G PPDU (Figure 9-3a) is quite confusing when this is in a generic clause called 9.2.4.1 Frame Control field). This is not really generic anymore since this applies only for PV0 frames. The text in 9.2.3 seems to try to make it clear that 9.2.4 covers PV0, but that was not exactly obvious.. Having something more explicit within 9.2.4 would hopefully make this clearer.

Replace "Frame Control field" with "Frame Control field in PV0 frames" as the title of 9.2.4.1. Number of other clarifications within 9.2.4 would also be acceptable way of addressing this comment.

REVISED (EDITOR: 2016-04-28 20:52:28Z) - Agree in principle with the commenter. The proposed resolution accounts for the suggested change targeting clarifications in 9.2.4.1.1.


EDITOR

EDITOR

The CCMP AAD construction for PV1 MPDUs (Figure 12-18a) is designed to protect what is included in the header compressed version (i.e., what is sent over air) of PV1 frames, not the actual fields this frame and header caching state maps to. This is problematic especially with the design that does not protect the frames used to update the header compression state. In fact, this seems to result in critical security flaws that would allow an attacker to replace at least A3 and A4 field values with arbitrary information in MPDUs that get accepted by the receiver even when using RSN with management frame protection. This is obviously not desirable functionality.It could be more robust to modify the CCMP AAD construction to protect the fields in the uncompressed version of the frame (i.e., full A1, A2, A3, A4) instead of the compressed version sent over air. This would allow the recipient to detect if something unexpected has been injected into the header compression state and only MPDUs with the address field values meant by the authorized transmitted

Modify CCMP AAD construction (page 385 lines 30 through page 386 line 32) by replacing the inclusion of SID field in A1/A2 with the 6-octet A1/A2 that this maps to. Clarify meaning of "MPDU Address 3 field, if present" and "MPDU Address 4 field, if present" to apply to the uncompressed (post-header decompression process on the receiver) version of the frame, not on the frame that is sent over air where these A3/A4 fields may not be present even though they exist in the uncompressed version that gets actually processed by higher layers in the stack.

REVISED (EDITOR: 2016-04-28 20:53:17Z) - Agree in principle with the commenter. The proposed resolution accounts for the suggested changes.


CID 8296 requested a change to language that included "Reachable Address Update frame". That CID was accepted in principle, but the language was chaged to "Reachable Address Update element". There is no such element. There are only a "Reachable Address Update frame" and a "Reachable Address element". In this context (a change of reachable address list after (Re)Association), the frame is the appropriate construct to reference, and no more complicated phrasing about a frame that contains the element is needed.

Change "An S1G relay STA shall send a frame that contains a Reachable Address Update element ..." to "An S1G relay STA shall send a Reachable Address Update frame ..."

REVISED (EDITOR: 2016-04-28 20:50:11Z) - Agree in principle with the comment. Proposed resolution accounts for the suggested changes.


EDITOR

EDITOR

EDITOR

CID 8297 suggested deleting the Relay Capable subfield from the Reachable Address field format, and associated text. This was rejected, with the comment, "Whether a address is relay capable provides useful information when forming the address tree." However, without any other information (such as which of the Reachable Addresses is associated/reachable from which of the Relay Capable STA's sub-trees), it really isn't possible to construct the address tree. It's not clear what value such a tree would provide, either, for that matter.

Delete the Relay Capable subfield from the Reachable Address field format, and associated text (P175L8, P175L20 and P341L31).

REJECTED (EDITOR: 2016-04-28 20:48:49Z)-- Within a relay tree there can be one or more STAs that are external nodes of the tree which may not be relay capable, while internal nodes are relay capable. The Relay Capable subfield helps identify which STA from those in the reachable address list is relay capable or not.

In 10.52.2, "An S1G relay STA shall send a Reachable Address Update element that contains the current list of reachable addresses, in the (Re)Association Request frame": the element is called "Reachable Address element" (no "Update").

Change, "Reachable Address Update element" to "Reachable Address element"


Current text says, "when the Subtype subfield is not equal to 3 or not equal to 10". This means either option satisfies the condition. It should be when _both_ options are true (the subfield is not equal to 3 and the subfield is also not equal to 6, leaving the other 14 possibilities only).

Change "or" to "and". Alternatively, change to "when the Subtype subfield is not equal to 3 or 6", which is a little ambiguous but likely understood by native speakers. Similarly in 9.2.4.1.1 at P76L1 and P76L41.

REVISED (EDITOR: 2016-04-28 20:48:40Z) - Agree with the commenter. Proposed resolution accounts for the suggested changes to P91.01, and P76L1, however the cited text in P76L41 is present in the baseline so please submit the comment to REVmc.


EDITOR

EDITOR

The new frame types created by this amendment are not described in any allowable frame exchange sequence in Annex G. While previous amendments may have failed to modify Annex G, it is a normative Annex and has normative references in the main body text that are necessary for interoperability, so amendments that add frame types must modify Annex G appropriately. (REVmc is likely going to have to clean-up from those amendments that did not do this in the past.)

Add new frame types from this amendment to appropriately modified/new sequences in Annex G.

REVISED (EDITOR: 2016-04-28 20:55:25Z) - A current Annex G in the 802.11 spec does not cover all frame exchange sequences. But, as per request from the commenter, TGah BRC accepts to create Annex G for the main exchange sequences based on the NDP frames.

TGah Editor makes changes as shown in the as specified in 11-16/0559r0 (https://mentor.ieee.org/802.11/dcn/16/11-16-0559-00-00ah-sb2-comment-resolution-annex-g.docx).

"If Coding field is 0, this field is reserved and set to 1." Why is a reserved field set to 1, differently from all other reserved fields and set conventions?

Change to "... set to 0." Similarly for the other uses of "LDPC Extra" field.

REVISED (EDITOR: 2016-04-28 20:50:25Z) - There are multiple occurrences of this setting of a field of a SIG field to 1 in the baseline. Please refer to P2538L58 (“The bit is reserved and set to 1 in VHT PPDUs transmitted by a non-AP VHT STA.”), P2539L19 (“If the MU[0] NSTS field is 0, then this field is reserved and set to 1.”, etc.

In order to keep consistency of the terminologies used in the draft (there are portions of the text in TGah D7.0 which state: “If Coding field is 0, this field is set to 1” see P452L42 and P467L22 the proposed resolution is to use the same statement avoiding the “reserved” terminology.

TGah editor: Replace “If Coding field is 0, this field is reserved and set to 1” with “If Coding field is 0, this field is set to 1.”

EDITOR"code type" is not well-defined. It appears to be the "Coding" subfield of the SIG* fields.

Add a sentence, or even a paranthetical phrase, to clarify that "code type" is referencing this subfield of the preamable.

REVISED (EDITOR: 2016-04-28 20:50:35Z) -- Agree in principle with the commenter. Proposed resolution accounts for the suggested change.

TGah editor to make the changes shown in https://mentor.ieee.org/802.11/dcn/16/11-16-0540-00-00ah-sb2-cids-miscellaneous-part-2.docx under all headings that include CID 10024

Ad-hoc Notes Edit Notes

I 8

I 8

I 8

Comment Group

Ad-hoc Status

Edit Status

Edited in Draft

EDITOR: 2016-04-28 20:54:52Z

EDITOR: 2016-04-28 20:40:29Z

EDITOR: 2016-04-28 20:45:38Z

N 8

I 8

I 8

I 8

The resolution resulted in no changes to the document.

EDITOR: 2016-04-28 20:44:56Z

EDITOR: 2016-04-28 20:45:18Z

EDITOR: 2016-04-28 20:45:08Z

I 8

I 8

I 8

EDITOR: 2016-04-28 20:42:28Z

EDITOR: 2016-04-28 20:45:26Z

EDITOR: 2016-04-28 20:53:26Z

I 8EDITOR: 2016-04-28 20:52:57Z

I 8

I 8

EDITOR: 2016-04-28 20:53:08Z

EDITOR: 2016-04-28 20:53:52Z

I 8EDITOR: 2016-04-28 20:53:33Z

I 8

I 8

EDITOR: 2016-04-28 20:53:38Z

EDITOR: 2016-04-28 20:52:32Z

I 8

I 8

EDITOR: 2016-04-28 20:53:18Z

EDITOR: 2016-04-28 20:50:12Z

N 8

I 8

I 8

The resolution resulted in no changes to the document.

EDITOR: 2016-04-28 20:50:02Z

EDITOR: 2016-04-28 20:48:46Z-

I 8

I 8

EDITOR: 2016-04-28 20:55:38Z

EDITOR: 2016-04-28 20:50:28Z

I 8EDITOR: 2016-04-28 20:50:45Z-

Last Updated

2016/4/28 20:55 EDITOR

2016/4/28 20:40 EDITOR

2016/4/28 20:45 EDITOR

Last Updated By

2016/4/28 20:44 EDITOR

2016/4/28 20:44 EDITOR

2016/4/28 20:45 EDITOR

2016/4/28 20:45 EDITOR

2016/4/28 20:42 EDITOR

2016/4/28 20:45 EDITOR

2016/4/28 20:53 EDITOR

2016/4/28 20:52 EDITOR

2016/4/28 20:56 EDITOR

2016/4/28 20:57 EDITOR

2016/4/28 20:53 EDITOR

2016/4/28 20:53 EDITOR

2016/4/28 20:56 EDITOR

2016/4/28 20:56 EDITOR

2016/4/28 20:51 EDITOR

2016/4/28 20:49 EDITOR

2016/4/28 20:50 EDITOR

2016/4/28 20:48 EDITOR

2016/4/28 20:55 EDITOR

2016/4/28 20:50 EDITOR

2016/4/28 20:51 EDITOR

Documents

mentor.ieee.org€¦ · XLS file · Web view · 2016-04-29Times New Roman,Bold" 4Month Year Times New Roman,Bold" 4 Times New Roman,Bold" 4doc.: IEEE 802.11-yy/xxxxr0 Times New