当前位置:首页 >> 英语学习 >>

11-11-0406-00-00ae-tgae-lb172-mf-qmf-resolutions-for-clause-8-4


CID

Commenter

LB

1005 Aboul-Magd, Osama

Draft Clause Page(C) Line(C Type of Number( ) Comment C) 172 2 8.2.4.4. 17-18 startin T 2 g a

Part of No Vote Y

Page

1004 Aboul-Magd, Osama

172

2 8.2.4.4. 17 2

20-23

T

Y

17.00

1217 Lambert, Paul

172

2 8.2.4.4. 17 2

22-23

T

Y

17.00

1345 Shukla, Ashish

172

2 8.2.4.4. 17 2

22-23

T

Y

17.00

1255 Montemurro, Michael 1144 Hunter, David

172 172

2 8.2.4.1. 17 5 2 8.2.4.1. 17 5

8 8

T T

Y Y

17.08 17.08

1221 Malinen, Jouni

172

2 8.2.4.1. 17 5

8

T

Y

17.08

1304 Ptasinski, Henry

172

2 8.2.4.4. 17 2

14

E

N

17.14

1370 Stephens, Adrian

172

2 8.2.4.4. 17 2

15

E

Y

17.15

1145 Hunter, David

172

2 8.2.4.4. 17 2

16

T

Y

17.16

1146 Hunter, David

172

2 8.2.4.4. 17 2

17

T

Y

17.17

1198 Kenney, John

172

2 8.2.4.4. 17 2

17

T

Y

17.17

1003 Aboul-Magd, Osama

172

2 8.2.4.4. 17 2

17

E

Y

17.17

1147 Hunter, David

172

2 8.2.4.4. 17 2 2 8.2.4.4. 17 2 2 8.2.4.4. 17 2

18

E

Y

17.18

1302 Ptasinski, Henry 1148 Hunter, David

172

20

E

N

17.20

172

22

T

Y

17.22

1106 Hamilton, Mark

172

2 8.2.4.4. 17 2

22

T

Y

17.22

1105 Hamilton, Mark

172

2 8.2.4.4. 17 2

22

T

Y

17.22

1303 Ptasinski, Henry

172

2 8.2.4.4. 17 2

22

T

Y

17.22

1369 Stephens, Adrian

172

2 8.2.4.4. 17 2

22

T

Y

17.22

1256 Montemurro, Michael

172

2 8.2.4.4. 17 2

22

T

N

17.22

1199 Kenney, John

172

2 8.2.4.4. 17 2

23

T

Y

17.23

1044 Fischer, Matthew

172

2 8.2.4.4. 17 2

24

T

N

17.24

1043 Fischer, Matthew

172

2 8.2.4.4. 17 2

24

T

N

17.24

1149 Hunter, David

172

2 8.2.4.4. 17 2

24

T

Y

17.24

1305 Ptasinski, Henry

172

2 8.2.4.4. 17 2

24

E

N

17.24

1150 Hunter, David

172

2 8.2.4.4. 17 2

25

T

Y

17.25

1240 Malinen, Jouni

172

2 8.2.4.4. 18 2

1

E

Y

18.01

1275 Pandey, Santosh

172

2 8.2.4.4. 18 2

1

E

N

18.01

1045 Fischer, Matthew

172

2 8.2.4.4. 18 2

4

T

N

18.04

1006 Aboul-Magd, Osama 1107 Hamilton, Mark

172 172

2 8.2.4.4. 18 2 2 8.2.4.4. 18 3

4 13

T T

Y Y

18.04 18.13

1376 Stephens, Adrian

172

2 8.2.4.4. 18 3

13

T

Y

18.13

1007 Aboul-Magd, Osama

172

2 8.2.4.4. 18 3

13

E

Y

18.13

1371 Stephens, Adrian

172

2 8.2.4.4. 18 3

13

T

Y

18.13

Line

Duplicate Resn Comment Statu of CID s 8.2.4.4. In a BSS where there 2 exist MFQ and non-MFQ STA, how the non-MFQ STA should interpret the sequnce number field? Wouldn't the value of the ACI sub-field makes the received frame out of sequence? 8.2.4.4. According to the MMFQ 2 frame conditions, it seems that MMFQ is only possible when all stations in the BSS are MFQ stations. I think it is important to state this fact upfront in section 4.5.6 when the service is described. 8.2.4.4. Algorithm for 2 determination of MMFQnot clear - needs more description of evan new mechanism.

Clause

Proposed Change

Explain

Add appropraite language to section 4.5.6.

Perhaps add new element.

8.2.4.4. 2

8 8

8.2.4.1. 5 8.2.4.1. 5

"No member of the BSS of which the STA is a member has dot11MFQ Activated false and no member of the BSS of which the STA is a member has dot11MFQ Activated not present" It's not easy to determine if all the STAs in BSS (infrastructure, IBSS, or MBSS) have MFQ activated, supported or not. Analogous to HT protection, ERP protection, a mechanism can be added to allow STA to determine whether it can use MMFQ or not? I believe the "and" should be an "or" It is unclear to what "and in IMFQ and MMFQ frames" applies.

Introduce an element such as MFQ Operation having member NonMFQ Present, NonMFQ transmission. This element would be updated by the AP or STA in IBSS, MBSS when it establish connection with peer and can be used by STAs to decide whether to use MMFQ or not. Commenter is willing to submit a proposal to address this.

Change the text to "or in IMFQ and MMFQ frames" Remove ", and in IMFQ and MMFQ frames" and on line 7 replace "data or management type frames" with "data, management, IMFQ and MMFQ frames".

8

8.2.4.1. 5

14

8.2.4.4. 2

While the CID418 for D1.0 seems to identify an area that could be improved, the solution adopted for this in D2.0 does not look acceptable. Forcing the More Fragments subfield to use value 1 and Fragment Number to value 15 for all IMFQ and MFFQ frames has number of conflicts with the base standard. This design would break fragmentation of IMFQ frames and require large number of special cases in lowlevel functionality like defragmentation and PS state updates. The following page/line number references are to REVmb/D7.0 and identify some of the conflicts: - 8.3.3.1 (page 314 line 30): rules for setting Duration field in ACK frames following a frame with More Fragments bit set to 1 - 9.3.4.3 (page 563 line Conditions defining IMFQ and MMFQ frames seem to be out of place in the sequence number field description. These definitions relate to behaviour, not the interpretation of frame formats. 10.ae1.1 requires that all MFQ STAs shall always set their dot11MFQActivated MIB variables to true. Consequently, there is no need to keep repeating "STA for which dot11MFQActivated is true" for each MFQ STA.

Revert all changes that were adopted to address CID418 for D1.0: Remove all modifications to 8.2.4.1.5 and 8.2.4.4.3.

Move to a more appropriate clause.

15

8.2.4.4. 2

Move lines 15-23 to behavioural clause.

16

8.2.4.4. 2

Replace "a QoS STA for whiich dot11MFQActivted is true" with "an MFQ STA".

17

8.2.4.4. 2

17

8.2.4.4. 2

Literally this specification for IMFQ frames requires that a management frame transmitted by a STA cannot be an IMFQ frame until that STA transmits a frame containing an Extended Capability element. If the STA never transmits a frame that contains an Extended Capability element, then it never issues an IMFQ frame. Worse, if the STA never transmits a frame with an Ext Cap element to this current STA, then it never issues an IMFQ frame. And, even worser, the subject STA therefore can issue IMFQ frames to some other STAs (the ones to which it has previously transmitted a frame with an Ext Cap element) and cannot issue IMFQ frames to all other STAs. The third condition for IMFQ assumes that an EC element has been received. That leads to ambiguity. One reader might infer that if no such EC element has been received then the frame is not an IMFQ frame. Another reader might infer that if no such EC element has been received then the MFQActivated status is "don't care" for determining if the 3rd condition is met.

Surely there must be a better way to delimit the identity of an IMFQ frame -- its existence doesn’t really depend on which STA receives it, does it? How about dropping item 3 from this list?

17

8.2.4.4. 2

Extended Capability Element

Resolve the ambiguity by breaking the 3rd condition into two conditions (and altering text appropriately to refer to 4 conditions) as follows: new 3rd condition: The sending STA has previously received an Extended Capability element from the STA corresponding to the RA of the frame to be transmitted. new 4th condition: The most recently received such Extended Capability element indicated that the STA is a QoS STA and has the value of 1 in the MFQActivated subfield" Should be "Extended Capabilities Element".

18

8.2.4.4. 2 8.2.4.4. 2 8.2.4.4. 2

20

22

22

8.2.4.4. 2

22

8.2.4.4. 2

22

8.2.4.4. 2

The last item in a list that ends a sentence takes a period. Wording is inconsistent between IMFQ and MMFQ definitions. Even though this specification doesn't have the "has the STA declared its fidelity" problem (see the comment above on page 17 line 17), it has even more problems than that for IMFQ frames. In this case the frame doesn't exist if any STA at all in the BSS hasn't declared its loyalty to quality. "Multicast" includes cases that are not broadcast, so why does it matter that every last one of the associated STAs have MFQ activated? Can't a subset be working fine on its own? How can a STA possibly know if every other member of the BSS has MFQActivated present and true? So, the STA must be associated with a BSS for the frame to be an MMFQ frame? Otherwise, this test makes no sense. Requirement needs to be written in terms of externally observable criteria.

Add periods to the ends of lines 18 and 23. Change “to a group address” to “to a group MAC address” Similarly to line 17, the simplest solution seems to be to drop item 3. But more important is that someone describes exactly what an MMFQ frame is supposed to be. "MMFQ" is defined to be "multicast management frame QoS". So "MMFQ frame" is "multicast management frame QoS frame". What the heck is that?

Describe the signaling or state knowledge that makes this test possible, instead of the theoretical state. Assuming this is true, add a new third condition: "The STA is currently a member of a BSS." Change condition 3 to rely on the extended capability elements received from other STAs.

22

8.2.4.4. 2

"3. No member of the BSS Reword into something of which the STA is a related to defined onmember has dot11MFQ the-air signalling. Activated false and no member of the BSS of which the STA is a member has dot11MFQ Activated not present" - this condition is not evaluatable. 802.11 does not provide a means for determining the value of MIB variables in other STAs. (A managment agent may or may not be present that exposes this information to the SME). A STA may or may not be able to directly observe transmissions by other STA, so even if this condition were related to observing other STA's transmissions, it could not guarantee the "no member" condition. This is more of a question, but does this mean that MMFQ frames are only sent by STA's operating in a BSS? If so, would we restrict this to frames with the BSSID set to the BSSID of the AP? The third condition for MMFQ assumes that the STA is a member of a BSS. That leads to ambiguity. One reader might infer that if the STA is not a member of a BSS (e.g. if dot11OCBActivated is true) then the frame cannot be a MMFQ frame. Another reader might infer that if the STA is not a member of a BSS only the first two conditions need to be met.

22

8.2.4.4. 2

Consider making a statement of the BSSID field.

23

8.2.4.4. 2

Resolve the ambiguity by inserting a new 3rd condition and making the current 3rd condition the 4th condition (and altering text appropriately to refer to 4 conditions) as follows: new 3rd condition: The sending STA is a member of a BSS.

24

8.2.4.4. 2

Confusing language. It sounds like there are four fields. The modifiers to the field names in the sentence could be interpreted as additional fields.

24

8.2.4.4. 2

24

8.2.4.4. 2

24

8.2.4.4. 2

25

8.2.4.4. 2

Change "The Sequence Number field in IMFQ and MMFQ frames comprises the IMFQ Frame Sequence Number, a 10-bit subfield indicating the sequence number of the frame, and the ACI subfield, a 2-bit subfield indicating the AC I of the frame, as shown in figure 8-2ae1." to "The Sequence Number field in IMFQ and MMFQ frames comprises the MFQ Frame Sequence Number subfield and the ACI subfield. The MFQ Frame Sequence Number subfield is a 10-bit subfield indicating the sequence number of the frame. The ACI subfield is a 2-bit subfield indicating the ACI of the frame. The format of the Sequence Number field in IMFQ and MMFQ frames is shown in figure 8-2ae1." The subfield named "IMFQ Change the name of the frame sequence number" IMFQ Frame Sequence should be changed because Number field to "MFQ it is also used in MMFQ Frame Sequence Number frames. field" throughout the document The Seq Num field in an Why is there no MMFQ MMFQ frame comprises the Frame Sequence Number? IMFQ Frame Sequence Number? For which individual address in the multicast group does this sequence number apply? Change “IMFQ Frame “IMFQ Frame Sequence Number” is misleading, Sequence Number” to “ MFQ Frame Sequence Number as it applies to bot I ” throughout the draft. and M frames. Replace "comprises" with "Comprises" seems to indicate the opposite of "is comprised of". what is intended.

1

8.2.4.4. 2

Figure 8-2ae1 title and subfield name were not updated to match the change to include ACI subfield in the Sequence Number field for MMFQ frames.

1

8.2.4.4. 2

4

8.2.4.4. 2

4 13

8.2.4.4. 2 8.2.4.4. 3

13

8.2.4.4. 3

13

8.2.4.4. 3

Replace “IMFQ Frame Sequence Number” with “ MFQ Frame Sequence Number ” and “Sequence Number field in IMFQ frames” with “Sequence Number field in IMFQ and MMFQ frames”. On page 17 line 24, replace “IMFQ Frame Sequence Number” with “ MFQ Frame Sequence Number ”. Figure 8-2ae1 (caption). Add "and MMFQ frames" at The 10 bit sequence the end of the figure number is for MMFQ frames caption too - this is not indicated in the figure caption Ordering problem Swap the order of the paragraphs that begin with "The value of the ACI subfield" and "The Sequence Number field in management frames" Couldn't find section Add 8.4.2.31 There is an implication Add a NOTE after this of this signalling, that paragraph: "NOTE - MFQ an MFQ frame can never be frames cannot be fragmented. That would fragmented due the good to mention overloading of the Fragment Number field." Either reverse the change The change to fragment number for IMFQ and MMFQ at 18.13, or indicate frames will result in non how to prioritize Public action frames while MFQ devices not being permitting non-MFQ STA to able to receive these frames (thinking they are receive them. odd fragments). How does that work with Public Action frames? Your knowledge of whether you can use MMFQ frames is based on STA in your BSS (and that known only inexactly in IBSS), but the purpose of Public action is to communicate beyond your BSS. "the fragment number is Explain set to 1111b", what is tmeaning of the "b" at the end of the bit pattern

13

8.2.4.4. 3

"The fragment number is Describe how to fragment set to 1111b in IMFQ". and reassemble an IMFQ - but directed management frame. frames can be fragmented, and this breaks fragmentation and reassembly.

Resolution

Owning Ad-hoc

Comment Group Clause 8

Ad-hoc Ad-hoc Notes Status

Edit Statu s

Reject - as described in EDITOR the Tgae-draft amended behavioral language of subclause 9.3.2.11, MCAST MFQ frames are not to be transmitted under this condition so the problem cited does not arise. Accept - editor to add to EDITOR the end of the paragraph in 4.5.6.ae1, the following sentence: "A QMF STA does not transmit GQMFs in a BSS that has a mixture of QMF STAs and non-QMF STAs."

Clause 8

Discussion - AP can EDITOR determine QMFness based on association exchange, non-AP STAs are not supposed to send GQMF modify item 3) at L22 to read as follows: "the transmitting STA has received from every member of the group address that is also a member of the BSS with which it is associated, an Extended Capabilities element that has the MFQActivated subfield equal to one."

Clause 8

Reject - within an EDITOR infrastructure BSS, a STA is generally not allowed to send Group Addressed Management Frames, so there is no need for nonAP STA in that case to know of BSS QMFness. In the IBSS and MBSS cases, it is impossible for any STA in the SS to make the determination of the complete membership, and so, GQMF transmissions are impossible.

Clause 8

Counter - text is deleted, see CID 1221 Counter - text is deleted, see CID 1221

EDITOR EDITOR

Clause 8 Clause 8

counter - change explicit EDITOR QMF siganlling from frag bits to ToDS=1, FromDS=don't care - see submission 11-11-0

Clause 8

EDITOR

Clause 8

EDITOR

Clause 8

Accept

EDITOR

Clause 8

Discussion - the text has EDITOR been misinterpreted originally, it was proposed that the third item have an additional qualifier to avoid exactly this mistake in interpretation but the sentence becomes very long, so this was not done - propose to either change nothing, because the text is correct, or change the second occurrence of " the STA" to " the STA corresponding to the RA of the frame to be transmitted"

Clause 8

accept in princple EDITOR agree with proposed change, but also need to change "three" to "four" in the sentence that precedes the bullets.

Clause 8

EDITOR

Clause 8

EDITOR

Clause 8

EDITOR

Clause 8

counter - see definitions EDITOR subclause, where MMFQ is fully defined - change "No member of the BSS" to "No member of the group address that is a member of the BSS"

Clause 8

Discussion - see CID 1217 EDITOR - should non-AP STA within infrastructure BSS be allowed to send GQMF? Counter - add the EDITOR condition between current 2 and 3

Clause 8

Clause 8

counter - discussion see CID 1217

EDITOR

Clause 8

counter - discussion see CID 1217

EDITOR

Clause 8

counter - yes - note that EDITOR MCAST frames are only accepted if they match yoru BSSID - see CID 1105

Clause 8

counter - see CID 1105

EDITOR

Clause 8

accept

EDITOR

Clause 8

counter - as per suggestion, except use QMF instead of MFQ

EDITOR

Clause 8

counter - see CID 1043

EDITOR

Clause 8

counter - see CID 1043

EDITOR

Clause 8

EDITOR reject - actually, comprises is correctly used here - see http://en.wiktionary.org/ wiki/comprise

Clause 8

accept

EDITOR

Clause 8

accept

EDITOR

Clause 8

accept

EDITOR

Clause 8

reject - 8.4.2.31 is in the baseline counter - see cid 1221

EDITOR EDITOR

Clause 8 Clause 8

counter - see cid 1221

EDITOR

Clause 8

EDITOR

Clause 8

counter - see cid 1221

EDITOR

Clause 8

Edit Notes

Edited Last Updated in Draft

Last Updated By 2011-3-7 21:19 EDITOR

2011-3-7 21:19 EDITOR

2011-3-7 21:19 EDITOR

2011-3-7 21:19 EDITOR

2011-3-7 21:19 EDITOR 2011-3-7 21:19 EDITOR

2011-3-7 21:19 EDITOR

2011-3-7 21:19 EDITOR

2011-3-7 21:19 EDITOR

2011-3-7 21:19 EDITOR

2011-3-7 21:19 EDITOR

2011-3-7 21:19 EDITOR

2011-3-7 21:19 EDITOR

2011-3-7 21:19 EDITOR

2011-3-7 21:19 EDITOR

2011-3-7 21:19 EDITOR

2011-3-7 21:19 EDITOR

2011-3-7 21:19 EDITOR

2011-3-7 21:19 EDITOR

2011-3-7 21:19 EDITOR

2011-3-7 21:19 EDITOR

2011-3-7 21:19 EDITOR

2011-3-7 21:19 EDITOR

2011-3-7 21:19 EDITOR

2011-3-7 21:19 EDITOR

2011-3-7 21:19 EDITOR

2011-3-7 21:19 EDITOR

2011-3-7 21:19 EDITOR

2011-3-7 21:19 EDITOR

2011-3-7 21:19 EDITOR

2011-3-7 21:19 EDITOR 2011-3-7 21:19 EDITOR

2011-3-7 21:19 EDITOR

2011-3-7 21:19 EDITOR

2011-3-7 21:19 EDITOR


相关文章:
更多相关标签: