Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[STDS-802-11-TGM] https://mentor.ieee.org/802.11/dcn/13/11-13-0233-29-000m-revmc-wg-ballot-comments.xls uploaded and current status



--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---

Some updates from the last telecon applied.

 

Current status is:

Ballot/Draft

Assigned

Discuss

Ready for Motion

Approved

Grand Total

199

33

1

21

442

497

EDITOR

1

442

443

201311 approved

189

189

201401 approved

105

105

201403 approved

148

148

Editor Motion May 2014

1

1

GEN

12

1

4

17

Gen Review

1

1

Submission requested

4

4

(blank)

2

1

3

Deprecation

3

3

Assigned to Adrian

2

2

Gen Motion Telecon April-May

4

4

MAC

21

16

37

(blank)

21

21

Motion MAC-X

16

16

Grand Total

33

1

21

442

497

 

 

And the assigned comments:

show assigned comments

Assignee

CID

LB

Commenter

Type of Comment

Part of No Vote

Page

Clause

Comment

Proposed Change

Owning Ad-hoc

Ad-hoc Status

Ad-hoc Notes

state

Adrian Stephens

2051

199

Adrian Stephens

G

Y

1133.38

9.4.4.3

Desire considered dangerous. We have 136 instances of desire(d|s). But STAs don't have desire. Worse, when used in the passive voice (e.g. "the desired UP", "unless extra protection against PCF collisions is desired.") the identity of the entity suffering these pangs of desire is discretely hidden.I claim that this word is harmful and should be eliminated. "unless extra protection against PCF collisions is desired" could become "unless a STA determined that extra protection against PCF collisions is needed. How a STA makes this determination is implementation defined."

Review all uses of "desire" and replace with non-emotive language based on observables.e.g. "desired" BSSIS can become a target BSSID.

MAC

Needs submission

Propose: Agree in priniciple. Needs a submission.

Assigned

Adrian Stephens

2060

199

Adrian Stephens

G

N

3050.34

O.2

The changes indicated in the resolution of comment 234 on figure O-3 made no sense to me as editor.

Please review Figure O-3 versus the resolution of comment 234 and determine if any additional changes are necessary.

GEN

Discuss

See CID 2463

Assigned

Adrian Stephens

2094

199

Adrian Stephens

T

Y

1294.21

9.35.2.2

"may ignore DMG Beacon frames" -- what is the normative effect of "ignoring" something? Is this actually an exception to behaviour described elsewhere?

Add the exception to the material it is an exception to.

MAC

Assigned

Adrian Stephens

2157

199

Adrian Stephens

G

Y

1437.35

10.4.10

Generally there's a lot of unnecessary qualification introduced by .11ad. For example in " PCP shall send a DELTS frame to the non-PCP DMG STA", it is unnecessary to include DMG in "non-PCP DMG STA" because the PCP cannot send a DELTS to a non-DMG STA. We went through a process in REVmb days of removing unnecessary "QoS" qualifications. Looks like we might need to do the same for DMG.

Review this subclause and remove any unnecessary qualification.

MAC

Assigned

Adrian Stephens

2183

199

Adrian Stephens

G

Y

2383

B.4.24.1

Invalid or bogus references at:2386.10 (8.4.2.111.2), 2386.11 (11.3), 2386.15 (8.4.2.145),2386.23 (9.13a9.14),2387.31 (9.4.2.138), 2387.35 (8.4.2.140),2387.44 & 2387.57 (8.4.2.138),2392.55 (8.4.2.138), 2392.59 (8.4.2.140),2393.07 (8.4.2.138), 2393.11 (8.4.2.140)

GEN

Needs submission

GEN: 2014-02-21 16:00:18Z change assignment to Adrian

Assigned

Adrian Stephens

2185

199

Adrian Stephens

G

Y

There are ~30 "shall ignore" statements.The danger with these, is that they are used to create exceptions to rules, without recording the exception in the rule itself.Or they are clarifications that no such requirement exists.For example: "If A then do B. If A and C, Ignore A."This should instead be "If A and not C, do B."

Review all "shall ignore" statements and replace them either:1. With an informative note " ... ignores ..."2. By adding an exception to a separate rule tha the "shall ignore" attempts to "override".

GEN

Needs submission

Assigned

Adrian Stephens

2463

199

Mark Hamilton

T

Y

3050.27

O.2

The Editor was right to be unsure about the resolution to CID 234, there is an error in Figure O-3. The AID 0 arrow should not be there to the second row. Also the O-5 changes are not complete.

Delete the second (lower) arrow for AID 0 in Figure O-3. On Figure O-5, add an indication of AID 0, with a split arrow to both the left cells (first and second row). Change the title of Figure O-7 to "Partial Virtual Bitmap example #5" (including lower-case 'e').

GEN

Discuss

GEN: 2014-03-18 09:59:43Z - See CID 234 as well

Proposed Accept - See CID 2060

Assigned

Dorothy Stanley

2411

199

Graham Smith

T

Y

1949.01

16

As noted in CID 32,"11b is Poison". Clause 16 devices have the capability of bringing 2.4GHz networks to their knees. 13/0416 (latest is r5 at time of writing comment) shows that there is no technical reason to maintain Clause 16 devices. It is suggested that a note be added to this Clause to indicate that it is now 'out of favor' and that it is likely to be dropped in the (near) future.

Add text under heading "Devices supporting the DSSS system are no longer encouraged and likely to be deprecated from this Specification in subsequent revisions"

GEN

Needs submission

Assigned

Dorothy Stanley

2412

199

Graham Smith

T

Y

1974.01

17

As noted in CID 32,"11b is Poison". Clause 17 devices are coupled to Clause 16 DSSS and as such have the capability of bringing 2.4GHz networks to their knees. 13/0416 (latest is r5 at time of writing comment) shows that there is no technical reason to maintain Clause 16 or 17 devices. It is suggested that a note be added to this Clause to indicate that it is now 'out of favor' and that it is likely to be dropped in the (near) future.

Add text under heading "Devices supporting the high rate extention to the DSSS system are no longer encouraged and likely to be deprecated from this Specification in subsequent revisions"

GEN

Needs submission

Assigned

Dorothy Stanley

2423

199

John Coffey

T

Y

2048.25

9.1.2

The standard requires 11n and 11g (i.e., HT and ERP) PHYs to support transmit and receive of all 11b modes. Given the enormous disparity in efficiency between 11b and the OFDM modes, this no longer makes sense as a universal requirement for all products, and any such requirements should be removed, if not necessary to support coexistence. A straightforward way of accomplishing at least some of this is to remove the requirement that ERP PHYs support the 5.5 and 11 Mbps CCK data rates. Since Clause 20 (HT) references Clause 19 (ERP), this would remove 5.5 and 11 Mbps as requirements for HT also. This would not affect the requirment to be able to detect the long or short preamble (1 Mbps and 2 Mbps) and to take appropriate action based on such a detection, thus preserving the current level of coexistence.

Delete 5.5 and 11 from list of mandatory data rates for ERP PHY. Also make corresponding changes throughout, including section 9.1.3 (P2048 LL30-37) (add 5.5 and 11 to list of exceptions); section 19.3.5 (P2054 LL39-40) (delete 5.5 and 11 from list); and Annex B.4.9 (P2307 LL33-37) (remove 5.5 and 11; add new entry ERP1a for 5.5 and 11, optional)

GEN

Needs submission

Assigned

Graham Smith

2413

199

Graham Smith

T

Y

2027.12

18.3.10.6

We know where -82dBm comes from (min sensitivity). Is it OK to assume the 'common' -72dBm was chosen simply on 10dB above this level (i.e. about 50% of the range - not really as on practice -92dBm is minimum sensitivity)? Similarly the common -62dBm as 20dB above minimum (i.e. about 25% of the extreme range)? Is there any regulatory basis for this or, most likely, is it based on letting a Wi-Fi STA at the furthest range get in? This is based upon maximum range concerns not so much a 'managed' range/cell. There is a real case to consider allowing higher CCA such that the overall traffic can be increased as explained in presentation 13/1012

Change CCA levels from mandatory. Consider allowing new CCA text which could be proposed by commenter. This also applies to Clauses 19.4.5 and 20.3.20.5.2

GEN

Needs submission

Assigned

Mark Hamilton

2005

199

Adrian Stephens

T

Y

29.44

3.2

The "See EAPOL-Key frame" is bogus, because the two terms are no longer synonyms.

Add a definition, or delete cited entry

MAC

Review

MAC: 2014-03-09 20:16:47Z: Revised. Change the definition of EAPOL-Start to be "A Data MPDU that carries all or part of an 802.1X EAPOL PDU of type EAPOL-Start."

Assigned

Mark Hamilton

2009

199

Adrian Stephens

G

Y

140.01

6.3.4.2.2

The JOIN.request primitive is of dubious use. In a non-FHSS (remember, we just got that to hop out of the standard), this has no effect on behavior. No frames are transmitted based on this primitive. No state machines are affected.Why then does this primitive still exist?And if we want to keep the primitive, why does it need things like HT Operational Rate Set?

Remove the MLME-Join primitives and all references to them.Or failing that, delete all but the Selected BSS parameter.

MAC

Discuss

MAC: 2014-03-10 03:46:14Z: Propose: Reject.

MLME-JOIN serves an explicit purpose, as described in 10.1.4.5. In particular, the non-AP STA will synchronize its TSF to the AP (allowing it to follow Beacon timing from this point in time). This primitive is also used to set a number of operating parameters which are otherwise not in any MLME primitive issued by a non-AP STA (for example, the rate set parameters, including HTOperationalMCSSet). In this way, the MLME-JOIN is parallel to the MLME-START in terms of initializing the MAC to specific (perhaps non-default) operating parameters.

It is agreed that there is some redundancy between MLME-JOIN and later primitives (especially MLME-ASSOCIATE). A submission is needed to address this, specifically.

Assigned

Mark Hamilton

2054

199

Adrian Stephens

G

Y

1152.11

9.11

What is a "non-DMG network"? Surely better to related to transmission by a non-DMG STA, in which case why not insert "non-DMG" twice, as is done elsewhere?

Replace "in a non-DMG" network by inserting "non-DMG" betfore STA at the start of these two statements. Remove the introductory sentence and promote to body text.

MAC

Review

MAC: 2014-03-10 04:25:34Z - Revised. Accept proposed changes. Also, at 1116L18, delete "in a non-DMG network"; at 1158L7, replace "non-DMG network" with "non-DMG BSS"; at 1167L60, replace "non-DMG network" with "non-DMG BSS"; at 1227L21, replace "non-DMG network" with "non-DMG BSS"; at 1227L25, replace "DMG network" with "DMG BSS".

Assigned

Mark Hamilton

2119

199

Adrian Stephens

T

N

97.39

4.9.3

"Since multiple STAs coordinated by the same MM-SME share the PHY, the STAs do not directly exchange frames with each other."I am not sure exactly what this is saying. Is it saying that the STAs do not need to exchange frames, or are not capabile of exchaning frames?If it is saying they cannot, then we have changed the meaning of the MAC service to one that can neither transmit nor receive from certain MAC addresses. For example, a broadcast does not reach all the MACs in the BSS (ignoring packet errors) because of this.

Add these constraints to the description of the MAC data service.

MAC

Review

MAC: 2014-03-09 20:45:11Z: Revised. Change, "STAs do not directly exchange frames with each other" to "STAs can not directly exchange frames with each other."

This addresses the ambiguity of the statement.

As for the MAC Service, nowhere does the MAC Service say or imply that all STAs can exchange frames directly with each other - consider hidden nodes, for example. Thus, no further change is needed.

Assigned

Mark Hamilton

2154

199

Adrian Stephens

G

Y

1432.23

10.4.4.4

"All MSDUs corresponding to a TID that was successfully negotiated through the ADDTS exchange with a U-PID element with the No-LLC field equal to 1(M34) shall have their LLC header stripped before transmission and the agreed LLC header added before delivery at the peer MAC-SAP. (11ad)"Passive voice considered dangerous. The following statement "shall have ... stripped" hides who does this. Also this is not an MLME activity, but a MAC data-plane activity, and may be above the MAC data SAP.

Determine where the stripping takes place. If it is in the MAC data plane, move this statement into clause 9. If it is above the MAC data plane, this is out of scope, and move it to an informative annex.Reword so that it cites the entity responsible for this action.

MAC

Review

MAC: 2014-03-18 09:25:28Z: Revised. Change to, "Before transmission, the MAC shall strip the LLC header from all MSDUs corresponding to a TID that was successfully negotiated through the ADDTS exchange with a U-PID element with the No-LLC field equal to 1, and the negotiated header shall by added by the peer MAC before delivery at the peer MAC-SAP."

Assigned

Mark Hamilton

2155

199

Adrian Stephens

T

Y

1434.4

10.4.7

The changes from CID 1412 removed the ADDTS failure timeout. The changes to the figures 10-16 should be more radical than described in that comment resolution, because now a .confirm is not provided in the case of timeout. Errors are handled above the MLME by the SME, which might choose to send an MLME-DELTS.request to cover case 2.

Remove the timeout from the two cases in Figure 10-16. Consider adding mandatory SME behavior on timout to send a DELTS.request in the case of timeout.Remove the text: "shall send a DELTS to the HC specifying the TSID and direction of the failed request"

MAC

Assigned

Mark Hamilton

2168

199

Adrian Stephens

G

Y

1623.4

10.33.2.2

Embedded "magic numbers"

Replace with name of status code throughout table.

MAC

Needs submission

MAC: 2014-01-17 05:44:40Z: Agree completely, and the text just before, and a few pages after the table has the same problem.

However, the root cause of this problem is that table 8-42 doesn't have a name for very many of the values, so there is no agreed name to reference in other locations like the cited location.

See CID 91 which was intended to address the root cause. Then, the cited location (and nearby text) could be modified to align. But, CID 91 died of loneliness.

Assigned

Mark Hamilton

2360

199

David Hunter

E

Y

1470.19

10.11.4

Confused writing makes the requirements unclear. What exactly does "shall not be set to 0 except for Beacon request with Measurement Mode set to Beacon Table Mode, Statistics request and request for triggered autonomous measurements." mean? Also: "Beacon Table Mode" does not appear to be the name of a frame, field, element, etc, so should be in lower case. Is it clear what type of frame constitutes the last type of request? Where is that specified?

Delete the comma after "frames" and replace the quoted sentence fragment with "shall not be set to 0 except when the request frame is a Beacon request in which the Measurement Mode field value is beacon table mode, or is a Statistics request frame, or is a request for triggered autonomous measurements." And specify exactly what frames make up the "request for triggered autonomous measurements". Also specify explictly somewhere (MIB?) the value of "beacon table mode".

MAC

Discuss

MAC: 2014-01-19 16:50:09Z - Is the terminology (for example), "Statistics request frame" what we want to use for a Measurement Request frame that has a Measurement Report element which has the Measurement Type field set to STA statistics report? The full description is way too wordy, and we need shorthand phrase. What is the right/best shorthand?

A nit: there is also a Directional statistics report, so we cannot shorthand to just "statistics", we need to say "STA statistics"

EDITOR: 2013-10-25 13:49:11Z
The proposed resolution does not address 'And specify exactly what frames make up the "request for triggered autonomous measurements"', which requires technical interpretation.

Transferring to MAC to continue the resolution. The resolution as of this date will be present in D2.1, and will be adjusted to track any subsequent changes in MAC.

Assigned

Mark Hamilton

2410

199

Graham Smith

T

Y

2745.02

dot11HRCCAModeImplemented only appears in Annex C.3 I can find no reference to it outside of Annex C.3. Suggest it is deleted.

Delete dot11HRCCAModeImplemented at P2745L2, P2753L57, P2754L8-27, P2819L37

GEN

Needs submission

GEN: assigned to Mark HAMILTON - Dec 20, 2013

Assigned

Mark Hamilton

2434

199

Mark Hamilton

T

Y

116.01

5.2.1

Figure 5-1 is confusing. It looks a lot like 802.1Q's bridge diagram, but this is not at all the same thing. It also has several unlabeled blocks which are confusing. And, it implies that 802.1X port control is above LLC which is incorrect.

Replace Figure 5-1 with that contained in a submission from the ARC SC.

GEN

Needs submission

Assigned

Mark Hamilton

2454

199

Mark Hamilton

T

Y

1093.19

9.2.2

Figure 9-1 still has FH, IR, etc.

Delete "FHSS, IR" from this figure

MAC

Review

MAC: 2014-03-18 09:00:02Z: Changes already made by the Editor.

Assigned

Mark Hamilton

2455

199

Mark Hamilton

T

Y

1093.02

9.2.2

Figure 9-1 line to DCF is confusing

Draw the figure so that label connectors don't have to pass "behind" boxes (making it look like they are connecting to that box). Push the label off to one side so that it's connector can be drawn without disappearing behind boxes. (If it has to disappear behind other labels, that's not ideal, but better.) Do this for the DCF label and the SP Access label.

MAC

Review

MAC: 2014-03-18 07:59:37Z: Revised. Redraw with the two referenced labels moved to the side and down, as shown in 14-0422r0.

Assigned

Mark Hamilton

2458

199

Mark Hamilton

T

Y

1160.6

9.20.2.3

EDCAF operation needs help to improve understanding - it has not evolved well. For example, 9.19.2.3 has become a convoluted machine built from 4 separate bullet lists. 9.19.2.3 and 9.19.2.5 both discuss backoff counter decrements, and when they occur. 9.2 shows EDCA as "on top of" DCF, but EDCA TXOPs violate 9.3.4.3 (6th paragraph). Etc.

This needs off-line work, and a thought-out proposal.

MAC

Needs submission

Assigned

Mark Hamilton

2459

199

Mark Hamilton

T

Y

217.32

6.3.26.6.2

Get rid of all TIMEOUT and UNSPECIFIED_FAILURE ReasonCode values, unless there is discussion of them explicit in the protocol/behavior (and then give them a descriptive name)

Get rid of all TIMEOUT and UNSPECIFIED_FAILURE ReasonCode values, unless there is discussion of them explicit in the protocol/behavior (and then give them a descriptive name)

GEN

Needs submission

Assigned

Mark Hamilton

2460

199

Mark Hamilton

T

Y

588.01

8.4.1.9

All StatusCodes and ResultCodes should have a name

It's just easier to talk about these, if they have a name.

MAC

Needs submission

Assigned

Mark Hamilton

2462

199

Mark Hamilton

T

Y

1417.42

10.3.5.4

Reassociation to the same AP behaviour is not clearly defined (e.g. effect on TSes, whether failure leaves you unassociated, whether you need to re-do 4WH, meaning of PM bit in Reassociation Request, etc.)

Clarify that reassociation to the same AP transitions the non-AP STA to not be in power save mode. No other behaviors are affected.

MAC

Needs submission

MAC: 2013-11-13 22:37:13Z: Yes, you shall do the 4WH again (or FT) - well, you will lose your PTK.

Did the group that shall not be named agree with the above?

Check on TSes, too. And, testing of the above.

It might be wishful thinking to think anything will be retained. (Could put in text warning of this.)

Assigned

Mark Hamilton

2464

199

Mark Hamilton

T

Y

510.51

8.2.4.1.7

The rules in 8.2.4.1.7 are not consistent with 10.2.2.2.The concepts "MMDU is bufferable" and "PM bit is reserved" need to be separated. It makes no sense to say that an Action MMDU sent by a non-AP STA is bufferable, for example, just because you want to be able to say that the PM is valid in the MPDUs used to send it.The exception for the PM bit in Probe Responses sent in response to unicast Probe Requests in an IBSS makes no senseIt's not clear enough which Control MPDUs have non-reserved PM bits and when. Note for example that 8.2.4.1.7 implies the PM bit in ACKs sent by a non-AP STA are not reserved.

Consider documents 11-12/1199 and 11-13/0131

MAC

Needs submission

Assigned

Mark Rison

2425

199

Jon Rosdahl

G

Y

2233.01

CID 269: Scrub PICS: was was assigned to Mark RISON -- who created 11-12/1345r0, the submission was overreaching, and corrected more than was requested/thought by the comments.

Document 11-12/1345r0 contains many changes to the PICS that would be a positive change. A new Document will be prepared to identify those changes and submitted to the REVmc Task Group

GEN

Needs submission

Assigned

Matthew Fischer

2471

199

Matthew Fischer

T

Y

1155.55

9.19

Several elements and frames use the operating class. Additions were made to the operating class for 11n and 11ac. These additions were for wider BW modes - older STA do not understand those operating classes, but the STA operating in the new operating classes generally include backwards compatible operating modes.e.g. 11ac includes 80 mhz BW operation and there is an operating class to support thislegacy 11a STA do not understand the new operating class, but they can probably still associate as 20 mhz only STA, and therefore, would benefit by knowing that the 20 mhz operating class is supported by the target BSS/APTherefore, whenever operating class is transmitted, it should be transmitted with the highest possible mutual understood operating class between the sender and the receiver, limited by the highest supported operating class of the third party being described

MAC

Needs submission

Assigned

Matthew Fischer

2473

199

Matthew Fischer

T

Y

629.62

8.4.2.3

Add a BSS membership selector for "private network" with the membership requirement to join the private network found in a specific location, e.g. include a new IE which contains an OUI field and a type field which together are a reference to a VSIE that matches that OUI value and with the type octet matching the octet that immediately follows the OUI value in the VSIE. The VSIE provides further details of what is required for membership, expressed in a vendor-specific manner.

As suggested.

MAC

Needs submission

Assigned

Matthew Fischer

2479

199

Matthew Fischer

T

Y

539.08

8.3.1.9.1

The highest indicated modulation and stream combinations for some PHYs result in phy rates that will reduce throughput efficiency to exceedingly low levels if the maximum block ack window size is not allowed to increase beyond the existing 64.

Increase the maximum allowed MPDUs in the Block Ack frame to 256 by creating a new form of Block Ack that supports a longer BA window and a longer BA bitmap

MAC

Needs submission

Assigned

Matthew Fischer

2481

199

Matthew Fischer

T

Y

1142.14

9.7.6.5

ACK (and other control response frames) are supposed to be sent at rates as specified in this subclause. Generally speaking, this subclause prescribes ACK transmission at a Basic Rate, which is, for eliciting frames that are transmitted at higher rate or MCS values, typically a rate that is lower than the rate or MCS of the eliciting frame by at least two increments. When the eliciting frame is at one of the lower rates/MCS, then the ACK will often be at the same rate/MCS. Normally, this is ok - reliability of the ACK transmission is good or better than the eliciting frame because the eliciting frame usually has significantly more bits than the ACK. But if the eliciting STA has a higher TX power, then the rate for the ACK can be too high and is very likely to fail. It would be nice if the eliciting STA can signal to the responder that a lower rate/MCS will be needed. This ensures a receiveable ACK and it allows the eliciting STA to correctly compute the ACK duration for DUR field use.

Allow a control response frame to be sent at a rate/MCS lower than otherwise allowed when there is a power difference or for other reasons. Create a mechanism that allows the eliciting STA to indicate the preferred response rate/MCS. E.g. signal in the eliciting frame, a value of step down in rate/MCS from the normally computed value for the response frame.

MAC

Needs submission

Assigned

 

 

Best Regards,

 

Adrian P STEPHENS

 

Tel: +44 (1793) 404825 (office)
Tel: +44 (7920) 084 900 (mobile,  UK)

Tel: +1 (408) 2397485 (mobile, USA)

 

----------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

 

From: Stephens, Adrian P
Sent: 09 April 2014 13:32
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: https://mentor.ieee.org/802.11/dcn/13/11-13-0233-28-000m-revmc-wg-ballot-comments.xls uploaded and current status

 

Dear TGmc members,

 

Following last week’s telecon,  I have updated

https://mentor.ieee.org/802.11/dcn/13/11-13-0233-28-000m-revmc-wg-ballot-comments.xls

to show the current state of play.

 

Here is our current status:

Ballot/Draft

Assigned

Discuss

Ready for Motion

Approved

Grand Total

199

37

1

17

442

497

EDITOR

1

442

443

201311 approved

189

189

201401 approved

105

105

201403 approved

148

148

Editor Motion May 2014

1

1

GEN

16

1

17

Gen Review

1

1

Submission requested

4

4

(blank)

2

1

3

Deprecation

4

4

Assigned to Adrian

4

4

Assigned to Dorothy

1

1

MAC

21

16

37

(blank)

21

21

Motion MAC-X

16

16

Grand Total

37

1

17

442

497

 

 

The following have assignments:

Assignee

GEN

MAC

Grand Total

Adrian Stephens

6

3

9

Dorothy Stanley

5

5

Graham Smith

1

1

Mark Hamilton

3

14

17

Mark RISON

1

1

Matthew Fischer

4

4

Grand Total

16

21

37

 

show assigned comments

Assignee

CID

LB

Commenter

Type of Comment

Part of No Vote

Page

Clause

Comment

Proposed Change

Owning Ad-hoc

Ad-hoc Status

Ad-hoc Notes

state

Adrian Stephens

2051

199

Adrian Stephens

G

Y

1133.38

9.4.4.3

Desire considered dangerous. We have 136 instances of desire(d|s). But STAs don't have desire. Worse, when used in the passive voice (e.g. "the desired UP", "unless extra protection against PCF collisions is desired.") the identity of the entity suffering these pangs of desire is discretely hidden.I claim that this word is harmful and should be eliminated. "unless extra protection against PCF collisions is desired" could become "unless a STA determined that extra protection against PCF collisions is needed. How a STA makes this determination is implementation defined."

Review all uses of "desire" and replace with non-emotive language based on observables.e.g. "desired" BSSIS can become a target BSSID.

MAC

Needs submission

Propose: Agree in priniciple. Needs a submission.

Assigned

Adrian Stephens

2060

199

Adrian Stephens

G

N

3050.34

O.2

The changes indicated in the resolution of comment 234 on figure O-3 made no sense to me as editor.

Please review Figure O-3 versus the resolution of comment 234 and determine if any additional changes are necessary.

GEN

Discuss

See CID 2463

Assigned

Adrian Stephens

2094

199

Adrian Stephens

T

Y

1294.21

9.35.2.2

"may ignore DMG Beacon frames" -- what is the normative effect of "ignoring" something? Is this actually an exception to behaviour described elsewhere?

Add the exception to the material it is an exception to.

MAC

Assigned

Adrian Stephens

2157

199

Adrian Stephens

G

Y

1437.35

10.4.10

Generally there's a lot of unnecessary qualification introduced by .11ad. For example in " PCP shall send a DELTS frame to the non-PCP DMG STA", it is unnecessary to include DMG in "non-PCP DMG STA" because the PCP cannot send a DELTS to a non-DMG STA. We went through a process in REVmb days of removing unnecessary "QoS" qualifications. Looks like we might need to do the same for DMG.

Review this subclause and remove any unnecessary qualification.

MAC

Assigned

Adrian Stephens

2177

199

Adrian Stephens

T

Y

2184.15

21.3.10

Either the changes made for Motion 34 (less than becomes less than or equal) are incorrect, in which case they should be unmade. Or they are correct, in which case matching changes need to be made in the other PHY clauses, and on the equation line below.Changes at lines 15 and 22.

Either unmake changes or propagate to other PHYs.

GEN

Needs submission

Assigned

Adrian Stephens

2182

199

Adrian Stephens

T

Y

2219.58

21.9

"the PHY shall maintain (#1601)PHY-CCA.indication(BUSY) primitive for any signal 20 dB higher" -- Indications are discrete events, not continuous signals. "shall maintain" is incorrect.

Propagate changes for the same reason from the HT PHY.

GEN

Needs submission

Assigned

Adrian Stephens

2183

199

Adrian Stephens

G

Y

2383

B.4.24.1

Invalid or bogus references at:2386.10 (8.4.2.111.2), 2386.11 (11.3), 2386.15 (8.4.2.145),2386.23 (9.13a9.14),2387.31 (9.4.2.138), 2387.35 (8.4.2.140),2387.44 & 2387.57 (8.4.2.138),2392.55 (8.4.2.138), 2392.59 (8.4.2.140),2393.07 (8.4.2.138), 2393.11 (8.4.2.140)

GEN

Needs submission

GEN: 2014-02-21 16:00:18Z change assignment to Adrian

Assigned

Adrian Stephens

2185

199

Adrian Stephens

G

Y

There are ~30 "shall ignore" statements.The danger with these, is that they are used to create exceptions to rules, without recording the exception in the rule itself.Or they are clarifications that no such requirement exists.For example: "If A then do B. If A and C, Ignore A."This should instead be "If A and not C, do B."

Review all "shall ignore" statements and replace them either:1. With an informative note " ... ignores ..."2. By adding an exception to a separate rule tha the "shall ignore" attempts to "override".

GEN

Needs submission

Assigned

Adrian Stephens

2463

199

Mark Hamilton

T

Y

3050.27

O.2

The Editor was right to be unsure about the resolution to CID 234, there is an error in Figure O-3. The AID 0 arrow should not be there to the second row. Also the O-5 changes are not complete.

Delete the second (lower) arrow for AID 0 in Figure O-3. On Figure O-5, add an indication of AID 0, with a split arrow to both the left cells (first and second row). Change the title of Figure O-7 to "Partial Virtual Bitmap example #5" (including lower-case 'e').

GEN

Discuss

GEN: 2014-03-18 09:59:43Z - See CID 234 as well

Proposed Accept - See CID 2060

Assigned

Dorothy Stanley

2401

199

David Hunter

T

Y

3036.17

Recommended practices ("should" statements) do not belong in an informative clause (Annex N).

Do one of:-- Replace "Recommended practices: in the title of N.2 with "Current practices" and rewrite all of the "It is recommended" statements as statements of fact about current practices-- Delete N.2.-- List Annex N (on page 3038) as normative.

GEN

Discuss

GEN: 2014-03-12 initially started to review, more discussion needed.

Assigned

Dorothy Stanley

2411

199

Graham Smith

T

Y

1949.01

16

As noted in CID 32,"11b is Poison". Clause 16 devices have the capability of bringing 2.4GHz networks to their knees. 13/0416 (latest is r5 at time of writing comment) shows that there is no technical reason to maintain Clause 16 devices. It is suggested that a note be added to this Clause to indicate that it is now 'out of favor' and that it is likely to be dropped in the (near) future.

Add text under heading "Devices supporting the DSSS system are no longer encouraged and likely to be deprecated from this Specification in subsequent revisions"

GEN

Needs submission

Assigned

Dorothy Stanley

2412

199

Graham Smith

T

Y

1974.01

17

As noted in CID 32,"11b is Poison". Clause 17 devices are coupled to Clause 16 DSSS and as such have the capability of bringing 2.4GHz networks to their knees. 13/0416 (latest is r5 at time of writing comment) shows that there is no technical reason to maintain Clause 16 or 17 devices. It is suggested that a note be added to this Clause to indicate that it is now 'out of favor' and that it is likely to be dropped in the (near) future.

Add text under heading "Devices supporting the high rate extention to the DSSS system are no longer encouraged and likely to be deprecated from this Specification in subsequent revisions"

GEN

Needs submission

Assigned

Dorothy Stanley

2423

199

John Coffey

T

Y

2048.25

9.1.2

The standard requires 11n and 11g (i.e., HT and ERP) PHYs to support transmit and receive of all 11b modes. Given the enormous disparity in efficiency between 11b and the OFDM modes, this no longer makes sense as a universal requirement for all products, and any such requirements should be removed, if not necessary to support coexistence. A straightforward way of accomplishing at least some of this is to remove the requirement that ERP PHYs support the 5.5 and 11 Mbps CCK data rates. Since Clause 20 (HT) references Clause 19 (ERP), this would remove 5.5 and 11 Mbps as requirements for HT also. This would not affect the requirment to be able to detect the long or short preamble (1 Mbps and 2 Mbps) and to take appropriate action based on such a detection, thus preserving the current level of coexistence.

Delete 5.5 and 11 from list of mandatory data rates for ERP PHY. Also make corresponding changes throughout, including section 9.1.3 (P2048 LL30-37) (add 5.5 and 11 to list of exceptions); section 19.3.5 (P2054 LL39-40) (delete 5.5 and 11 from list); and Annex B.4.9 (P2307 LL33-37) (remove 5.5 and 11; add new entry ERP1a for 5.5 and 11, optional)

GEN

Needs submission

Assigned

Dorothy Stanley

2424

199

John Coffey

T

N

2048.37

9.1.3

The standard requires 11n and 11g (i.e., HT and ERP) PHYs to support transmit and receive of the 11b Short Preamble. This is optional for 11b. This requirement no longer makes sense (if it ever did), as there are legacy deployed devices that do not recognize the short preamble or defer for it, and it seems that most deployed devices do not transmit the short preamble.

Remove the sentence beginning "In addition, it is mandatory ...". Also make corresponding changes throughout, including section 19.3.2.1 (P2052 LL32-41) (change "three" to "two" and delete short preamble from list; add extra line saying that an ERP STA may support the short preamble); section 19.3.2.3 (P2053 L16) (delete sentence begiining "For the ERP..."); section 19.3.5 (P2054 L40) (delete "or short"), and (P2054 L46) (delete "short preamble").

GEN

Needs submission

Assigned

Graham Smith

2413

199

Graham Smith

T

Y

2027.12

18.3.10.6

We know where -82dBm comes from (min sensitivity). Is it OK to assume the 'common' -72dBm was chosen simply on 10dB above this level (i.e. about 50% of the range - not really as on practice -92dBm is minimum sensitivity)? Similarly the common -62dBm as 20dB above minimum (i.e. about 25% of the extreme range)? Is there any regulatory basis for this or, most likely, is it based on letting a Wi-Fi STA at the furthest range get in? This is based upon maximum range concerns not so much a 'managed' range/cell. There is a real case to consider allowing higher CCA such that the overall traffic can be increased as explained in presentation 13/1012

Change CCA levels from mandatory. Consider allowing new CCA text which could be proposed by commenter. This also applies to Clauses 19.4.5 and 20.3.20.5.2

GEN

Needs submission

Assigned

Mark Hamilton

2005

199

Adrian Stephens

T

Y

29.44

3.2

The "See EAPOL-Key frame" is bogus, because the two terms are no longer synonyms.

Add a definition, or delete cited entry

MAC

Review

MAC: 2014-03-09 20:16:47Z: Revised. Change the definition of EAPOL-Start to be "A Data MPDU that carries all or part of an 802.1X EAPOL PDU of type EAPOL-Start."

Assigned

Mark Hamilton

2009

199

Adrian Stephens

G

Y

140.01

6.3.4.2.2

The JOIN.request primitive is of dubious use. In a non-FHSS (remember, we just got that to hop out of the standard), this has no effect on behavior. No frames are transmitted based on this primitive. No state machines are affected.Why then does this primitive still exist?And if we want to keep the primitive, why does it need things like HT Operational Rate Set?

Remove the MLME-Join primitives and all references to them.Or failing that, delete all but the Selected BSS parameter.

MAC

Discuss

MAC: 2014-03-10 03:46:14Z: Propose: Reject.

MLME-JOIN serves an explicit purpose, as described in 10.1.4.5. In particular, the non-AP STA will synchronize its TSF to the AP (allowing it to follow Beacon timing from this point in time). This primitive is also used to set a number of operating parameters which are otherwise not in any MLME primitive issued by a non-AP STA (for example, the rate set parameters, including HTOperationalMCSSet). In this way, the MLME-JOIN is parallel to the MLME-START in terms of initializing the MAC to specific (perhaps non-default) operating parameters.

It is agreed that there is some redundancy between MLME-JOIN and later primitives (especially MLME-ASSOCIATE). A submission is needed to address this, specifically.

Assigned

Mark Hamilton

2054

199

Adrian Stephens

G

Y

1152.11

9.11

What is a "non-DMG network"? Surely better to related to transmission by a non-DMG STA, in which case why not insert "non-DMG" twice, as is done elsewhere?

Replace "in a non-DMG" network by inserting "non-DMG" betfore STA at the start of these two statements. Remove the introductory sentence and promote to body text.

MAC

Review

MAC: 2014-03-10 04:25:34Z - Revised. Accept proposed changes. Also, at 1116L18, delete "in a non-DMG network"; at 1158L7, replace "non-DMG network" with "non-DMG BSS"; at 1167L60, replace "non-DMG network" with "non-DMG BSS"; at 1227L21, replace "non-DMG network" with "non-DMG BSS"; at 1227L25, replace "DMG network" with "DMG BSS".

Assigned

Mark Hamilton

2119

199

Adrian Stephens

T

N

97.39

4.9.3

"Since multiple STAs coordinated by the same MM-SME share the PHY, the STAs do not directly exchange frames with each other."I am not sure exactly what this is saying. Is it saying that the STAs do not need to exchange frames, or are not capabile of exchaning frames?If it is saying they cannot, then we have changed the meaning of the MAC service to one that can neither transmit nor receive from certain MAC addresses. For example, a broadcast does not reach all the MACs in the BSS (ignoring packet errors) because of this.

Add these constraints to the description of the MAC data service.

MAC

Review

MAC: 2014-03-09 20:45:11Z: Revised. Change, "STAs do not directly exchange frames with each other" to "STAs can not directly exchange frames with each other."

This addresses the ambiguity of the statement.

As for the MAC Service, nowhere does the MAC Service say or imply that all STAs can exchange frames directly with each other - consider hidden nodes, for example. Thus, no further change is needed.

Assigned

Mark Hamilton

2154

199

Adrian Stephens

G

Y

1432.23

10.4.4.4

"All MSDUs corresponding to a TID that was successfully negotiated through the ADDTS exchange with a U-PID element with the No-LLC field equal to 1(M34) shall have their LLC header stripped before transmission and the agreed LLC header added before delivery at the peer MAC-SAP. (11ad)"Passive voice considered dangerous. The following statement "shall have ... stripped" hides who does this. Also this is not an MLME activity, but a MAC data-plane activity, and may be above the MAC data SAP.

Determine where the stripping takes place. If it is in the MAC data plane, move this statement into clause 9. If it is above the MAC data plane, this is out of scope, and move it to an informative annex.Reword so that it cites the entity responsible for this action.

MAC

Review

MAC: 2014-03-18 09:25:28Z: Revised. Change to, "Before transmission, the MAC shall strip the LLC header from all MSDUs corresponding to a TID that was successfully negotiated through the ADDTS exchange with a U-PID element with the No-LLC field equal to 1, and the negotiated header shall by added by the peer MAC before delivery at the peer MAC-SAP."

Assigned

Mark Hamilton

2155

199

Adrian Stephens

T

Y

1434.4

10.4.7

The changes from CID 1412 removed the ADDTS failure timeout. The changes to the figures 10-16 should be more radical than described in that comment resolution, because now a .confirm is not provided in the case of timeout. Errors are handled above the MLME by the SME, which might choose to send an MLME-DELTS.request to cover case 2.

Remove the timeout from the two cases in Figure 10-16. Consider adding mandatory SME behavior on timout to send a DELTS.request in the case of timeout.Remove the text: "shall send a DELTS to the HC specifying the TSID and direction of the failed request"

MAC

Assigned

Mark Hamilton

2168

199

Adrian Stephens

G

Y

1623.4

10.33.2.2

Embedded "magic numbers"

Replace with name of status code throughout table.

MAC

Needs submission

MAC: 2014-01-17 05:44:40Z: Agree completely, and the text just before, and a few pages after the table has the same problem.

However, the root cause of this problem is that table 8-42 doesn't have a name for very many of the values, so there is no agreed name to reference in other locations like the cited location.

See CID 91 which was intended to address the root cause. Then, the cited location (and nearby text) could be modified to align. But, CID 91 died of loneliness.

Assigned

Mark Hamilton

2360

199

David Hunter

E

Y

1470.19

10.11.4

Confused writing makes the requirements unclear. What exactly does "shall not be set to 0 except for Beacon request with Measurement Mode set to Beacon Table Mode, Statistics request and request for triggered autonomous measurements." mean? Also: "Beacon Table Mode" does not appear to be the name of a frame, field, element, etc, so should be in lower case. Is it clear what type of frame constitutes the last type of request? Where is that specified?

Delete the comma after "frames" and replace the quoted sentence fragment with "shall not be set to 0 except when the request frame is a Beacon request in which the Measurement Mode field value is beacon table mode, or is a Statistics request frame, or is a request for triggered autonomous measurements." And specify exactly what frames make up the "request for triggered autonomous measurements". Also specify explictly somewhere (MIB?) the value of "beacon table mode".

MAC

Discuss

MAC: 2014-01-19 16:50:09Z - Is the terminology (for example), "Statistics request frame" what we want to use for a Measurement Request frame that has a Measurement Report element which has the Measurement Type field set to STA statistics report? The full description is way too wordy, and we need shorthand phrase. What is the right/best shorthand?

A nit: there is also a Directional statistics report, so we cannot shorthand to just "statistics", we need to say "STA statistics"

EDITOR: 2013-10-25 13:49:11Z
The proposed resolution does not address 'And specify exactly what frames make up the "request for triggered autonomous measurements"', which requires technical interpretation.

Transferring to MAC to continue the resolution. The resolution as of this date will be present in D2.1, and will be adjusted to track any subsequent changes in MAC.

Assigned

Mark Hamilton

2410

199

Graham Smith

T

Y

2745.02

dot11HRCCAModeImplemented only appears in Annex C.3 I can find no reference to it outside of Annex C.3. Suggest it is deleted.

Delete dot11HRCCAModeImplemented at P2745L2, P2753L57, P2754L8-27, P2819L37

GEN

Needs submission

GEN: assigned to Mark HAMILTON - Dec 20, 2013

Assigned

Mark Hamilton

2434

199

Mark Hamilton

T

Y

116.01

5.2.1

Figure 5-1 is confusing. It looks a lot like 802.1Q's bridge diagram, but this is not at all the same thing. It also has several unlabeled blocks which are confusing. And, it implies that 802.1X port control is above LLC which is incorrect.

Replace Figure 5-1 with that contained in a submission from the ARC SC.

GEN

Needs submission

Assigned

Mark Hamilton

2454

199

Mark Hamilton

T

Y

1093.19

9.2.2

Figure 9-1 still has FH, IR, etc.

Delete "FHSS, IR" from this figure

MAC

Review

MAC: 2014-03-18 09:00:02Z: Changes already made by the Editor.

Assigned

Mark Hamilton

2455

199

Mark Hamilton

T

Y

1093.02

9.2.2

Figure 9-1 line to DCF is confusing

Draw the figure so that label connectors don't have to pass "behind" boxes (making it look like they are connecting to that box). Push the label off to one side so that it's connector can be drawn without disappearing behind boxes. (If it has to disappear behind other labels, that's not ideal, but better.) Do this for the DCF label and the SP Access label.

MAC

Review

MAC: 2014-03-18 07:59:37Z: Revised. Redraw with the two referenced labels moved to the side and down, as shown in 14-0422r0.

Assigned

Mark Hamilton

2458

199

Mark Hamilton

T

Y

1160.6

9.20.2.3

EDCAF operation needs help to improve understanding - it has not evolved well. For example, 9.19.2.3 has become a convoluted machine built from 4 separate bullet lists. 9.19.2.3 and 9.19.2.5 both discuss backoff counter decrements, and when they occur. 9.2 shows EDCA as "on top of" DCF, but EDCA TXOPs violate 9.3.4.3 (6th paragraph). Etc.

This needs off-line work, and a thought-out proposal.

MAC

Needs submission

Assigned

Mark Hamilton

2459

199

Mark Hamilton

T

Y

217.32

6.3.26.6.2

Get rid of all TIMEOUT and UNSPECIFIED_FAILURE ReasonCode values, unless there is discussion of them explicit in the protocol/behavior (and then give them a descriptive name)

Get rid of all TIMEOUT and UNSPECIFIED_FAILURE ReasonCode values, unless there is discussion of them explicit in the protocol/behavior (and then give them a descriptive name)

GEN

Needs submission

Assigned

Mark Hamilton

2460

199

Mark Hamilton

T

Y

588.01

8.4.1.9

All StatusCodes and ResultCodes should have a name

It's just easier to talk about these, if they have a name.

MAC

Needs submission

Assigned

Mark Hamilton

2462

199

Mark Hamilton

T

Y

1417.42

10.3.5.4

Reassociation to the same AP behaviour is not clearly defined (e.g. effect on TSes, whether failure leaves you unassociated, whether you need to re-do 4WH, meaning of PM bit in Reassociation Request, etc.)

Clarify that reassociation to the same AP transitions the non-AP STA to not be in power save mode. No other behaviors are affected.

MAC

Needs submission

MAC: 2013-11-13 22:37:13Z: Yes, you shall do the 4WH again (or FT) - well, you will lose your PTK.

Did the group that shall not be named agree with the above?

Check on TSes, too. And, testing of the above.

It might be wishful thinking to think anything will be retained. (Could put in text warning of this.)

Assigned

Mark Hamilton

2464

199

Mark Hamilton

T

Y

510.51

8.2.4.1.7

The rules in 8.2.4.1.7 are not consistent with 10.2.2.2.The concepts "MMDU is bufferable" and "PM bit is reserved" need to be separated. It makes no sense to say that an Action MMDU sent by a non-AP STA is bufferable, for example, just because you want to be able to say that the PM is valid in the MPDUs used to send it.The exception for the PM bit in Probe Responses sent in response to unicast Probe Requests in an IBSS makes no senseIt's not clear enough which Control MPDUs have non-reserved PM bits and when. Note for example that 8.2.4.1.7 implies the PM bit in ACKs sent by a non-AP STA are not reserved.

Consider documents 11-12/1199 and 11-13/0131

MAC

Needs submission

Assigned

Mark Rison

2425

199

Jon Rosdahl

G

Y

2233.01

CID 269: Scrub PICS: was was assigned to Mark RISON -- who created 11-12/1345r0, the submission was overreaching, and corrected more than was requested/thought by the comments.

Document 11-12/1345r0 contains many changes to the PICS that would be a positive change. A new Document will be prepared to identify those changes and submitted to the REVmc Task Group

GEN

Needs submission

Assigned

Matthew Fischer

2471

199

Matthew Fischer

T

Y

1155.55

9.19

Several elements and frames use the operating class. Additions were made to the operating class for 11n and 11ac. These additions were for wider BW modes - older STA do not understand those operating classes, but the STA operating in the new operating classes generally include backwards compatible operating modes.e.g. 11ac includes 80 mhz BW operation and there is an operating class to support thislegacy 11a STA do not understand the new operating class, but they can probably still associate as 20 mhz only STA, and therefore, would benefit by knowing that the 20 mhz operating class is supported by the target BSS/APTherefore, whenever operating class is transmitted, it should be transmitted with the highest possible mutual understood operating class between the sender and the receiver, limited by the highest supported operating class of the third party being described

MAC

Needs submission

Assigned

Matthew Fischer

2473

199

Matthew Fischer

T

Y

629.62

8.4.2.3

Add a BSS membership selector for "private network" with the membership requirement to join the private network found in a specific location, e.g. include a new IE which contains an OUI field and a type field which together are a reference to a VSIE that matches that OUI value and with the type octet matching the octet that immediately follows the OUI value in the VSIE. The VSIE provides further details of what is required for membership, expressed in a vendor-specific manner.

As suggested.

MAC

Needs submission

Assigned

Matthew Fischer

2479

199

Matthew Fischer

T

Y

539.08

8.3.1.9.1

The highest indicated modulation and stream combinations for some PHYs result in phy rates that will reduce throughput efficiency to exceedingly low levels if the maximum block ack window size is not allowed to increase beyond the existing 64.

Increase the maximum allowed MPDUs in the Block Ack frame to 256 by creating a new form of Block Ack that supports a longer BA window and a longer BA bitmap

MAC

Needs submission

Assigned

Matthew Fischer

2481

199

Matthew Fischer

T

Y

1142.14

9.7.6.5

ACK (and other control response frames) are supposed to be sent at rates as specified in this subclause. Generally speaking, this subclause prescribes ACK transmission at a Basic Rate, which is, for eliciting frames that are transmitted at higher rate or MCS values, typically a rate that is lower than the rate or MCS of the eliciting frame by at least two increments. When the eliciting frame is at one of the lower rates/MCS, then the ACK will often be at the same rate/MCS. Normally, this is ok - reliability of the ACK transmission is good or better than the eliciting frame because the eliciting frame usually has significantly more bits than the ACK. But if the eliciting STA has a higher TX power, then the rate for the ACK can be too high and is very likely to fail. It would be nice if the eliciting STA can signal to the responder that a lower rate/MCS will be needed. This ensures a receiveable ACK and it allows the eliciting STA to correctly compute the ACK duration for DUR field use.

Allow a control response frame to be sent at a rate/MCS lower than otherwise allowed when there is a power difference or for other reasons. Create a mechanism that allows the eliciting STA to indicate the preferred response rate/MCS. E.g. signal in the eliciting frame, a value of step down in rate/MCS from the normally computed value for the response frame.

MAC

Needs submission

Assigned

 

 

 

Best Regards,

 

Adrian P STEPHENS

 

Tel: +44 (1793) 404825 (office)
Tel: +44 (7920) 084 900 (mobile,  UK)

Tel: +1 (408) 2397485 (mobile, USA)

 

----------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

 

_______________________________________________________________________________

IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this CLOSED reflector. We use this valuable tool to communicate on the issues at hand.

SELF SERVICE OPTION: Point your Browser to - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM and then amend your subscription on the form provided. If you require removal from the reflector press the LEAVE button.

Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________