Results of Ballot on Draft Standard D3.0
Comments on clauses 7 and 8

	7.1.2	ge	e		shading must be added to the figure 
			
	7.1.2	ge	e		section references should be to 7.1.2 and 7.2			
	7.1.2	mif	e	N	Figure 12 is stated to have shading, but does not (as printed from the machine readable copies I received).  Also, Figure 12 goes well beyond the right margin.	fix print formatting for Figure 12		
	7.1.2	BO	T	Y	Due to the request of the IEEE editor, the shading was removed from the figure.  The following change needs to be made.	Some fields are only present in certain frame types.		
	7.1.2	jz	t	Y	There are no shaded fields in my printout. Please enumerate the fields.	The fields (Address 2, Address 3, Sequence Control and Address 4) are only present in certain frame types.		
	7.1.3.1	ch	E		field left out of list but present everywhere else	The Frame Control field shall consist of the following sub-fields: Protocol Version, Type, Subtype, To DS, From DS, More Fragments, Retry, Power Management, More Data and WEP		
	7.1.3.1	ge	e		first sentence must include “More Data” as a subfield	“... Retry, Power Management, More Data, and WEP”.		
	7.1.3.1	ge	T		need to add that reserved bits and fields should be set to 0 upon transmission, in addition to being ignored on reception.  This is necessary for forward compatibility if we are to make use of these bits in a future version of the specification.	Change sentence to “Reserved bits and fields shall be set to 0 upon transmission and shall be ignored upon reception”.		
	7.1.3.1	mif	E	N	Reference in the text to the ÒMore DataÓ bit (bit 13) is missing.	The Frame Control field shall consist of the following sub-fields: Protocol Version, Type, Subtype, To DS, From DS, More Fragments, Retry, Power Management, More Data and WEP.		
	7.1.3.1	BO	T	Y		The remaining subfields in the Frame Control field shall be reserved.		
	7.1.3.1.1	db	T	Y	w/o the requested change the Draft is technically incorrect - since approved “standard” language was not used the draft does not corectly convey operational requirements.	fundamental incompatibility exists between a new revision and this revision of the standard. A device that receives a frame with a higher revision level than it understands shall discard the frame without indication to LLC.
		
	7.1.3.1.7	mif	E	N	section reference is incorrect	The Power Management field shall be one bit in length and shall be used to indicate the power management mode of a STA.  The value of this field shall remain constant in each frame from a particular STA within a frame sequence defined in clause 9.7. The value shall indicate the mode in which the station will be after the completion of the frame sequence.
		
	7.1.3.1.7 
A.4.4	db	T	Y	w/o the requested change the Draft is technically incorrect - since approved “standard” language was not used the draft does not corectly convey operational requirements.	particular STA within a frame sequence defined in clause 4.4. The value shall indicate the mode in which the station shall be after the completion of the frame sequence.
A value of ‘1’ shall indicate that the STA shall be in Power Save Mode. A value of ‘0’ shall indicate that the STA shall be in Active Mode. This field shall always be set to ‘0’ in frames transmitted by an AP. 
		
	7.1.3.1.8	jz	t	Y	The second sentence is nonsensical. The bit darn well is always valid, it just isn’t used in some frames. Also, the notion of buffered frame is unclear, since the frame that is being transmitted could be considered to be buffered.	The More Data field shall be one bit in length and shall be used to indicate to a STA in Power Save mode that more MSDUs are buffered for that STA at the AP. A value of ‘1’ shall indicate to a STA in Power Save Mode that at least one buffered MSDU  will remain in the AP after the MSDU being transmitted has been received. The More Data field shall be set to ‘0’ in all other frames. 
		
	7.1.3.1.8	mif	t	Y	The edit to the first paragraph is editorial Ñ the change is necessary to avoid conflict with the (unchanged) second paragraph.

The insertion of a statement regarding the More Data field in frames transmitted by STA is appropriate for clarity, as well as function.  The functional issue is that there is no reason to prohibit the use of the More bit to indicate buffered toDS frames by CF-Aware STA responding to a CF-Poll.  This does not have to be a mandatory action by CF-Aware STA, nor is a point coordinator constrained to take specific action if a CF-Poll response is received with More Data =1.  However, there are cases where a point coordinator can take advantage of information about the presence of additional buffered MSDUs to avoid wasting polls and/or to more effectively utilize time during the contention free period. Permitting this use of the More Data bit (then called the More bit) by STA was adopted (in MAC and Plenary) at the November, 1994 meeting (based on motion from submission 94/283), and none of the changes to MAC mechanisms since that time have invalidated the basis for that submission nor for the potential benefits of this use for the More Data bit.  I am unaware of when and why this allowed use of the More Data bit was removed, and believe the removal was either inadvertent or unnecessary.  Those wanting further justification should refer to document 94/283.	The More Data field shall be one bit in length and shall be used to indicate to a STA in Power Save mode that more MSDUs are buffered for that STA at the AP. The More Data field shall be valid only in Data Type frames transmitted by an AP to an STA in Power Save Mode. A value of ‘1’ shall indicate that at least one buffered MSDU is present. The More Data field shall be set to ‘0’ in all other directed frames transmitted by an AP. 
The More Data field shall be set to “1” in broadcast/multicast frames transmitted by the AP, when additional broadcast/multicast frames remain to be transmitted by the AP during this beacon interval.  The More Data field shall be set to “0” in broadcast/multicast frames transmitted by the AP when no more broadcast/multicast frames remain to be transmitted by the AP during this beacon interval.
The More Data field shall be set to Ò0Ó in all frames transmitted by an STA, except that the More Data field may be set to Ò1Ó in frames transmitted by an STA in response to a CF-Poll in cases where there is at least one MSDU buffered at that STA.
		
	7.1.3.2	mif	e	N	There appears to be an inconsistency in section numbering:  The bits of the frame control field up through the ÒMore DataÓ bit are numbered as Ò7.1.3.1.xÓ whereas the WEP field is Ò7.1.3.2Ó	renumber WEP field (which decrements Duration/ID to 7.1.3.2, and has similar effect on subsequent 7.1.3.x.y sub-clauses.		
	7.1.3.2 
A.4.4	db	T	Y	w/o the requested change the Draft is technically incorrect - since approved “standard” language was not used the draft does not corectly convey operational requirements.	that has been processed by the WEP algorithm. The WEP field shall only be set to '1' within frames of Type Data and frames of Type Management, Subtype Authentication. The WEP field shall be set to '0' in		
	7.1.3.3	mif	e	N	incorrect section references	change Òclause 4.2Ó to Òclause 7.2Ó
change Òclause 6Ó to Òclause 9Ó		
	7.1.3.3	BO	T	Y	The maximum value a 15-bit field may take is 32767.  It is not possible to set this field to 32768.  The following changes must be made to maintain the desired functionality.	The Duration/ID field shall be 16 bits in length. The contents of the this field shall be as follows:
a)	In Control Type frames of subtype PS-Poll, the Duration/ID field shall carry the station identity (SID) of the station that transmitted the frame in the 14 least-significant bits, with the 2 most-significant bits set to '11'. The value of the SID shall be in the range 1 - 16383.
b) 	In all other frames the Duration/ID field shall contain a duration value as defined for each frame type in clause Error! Reference source not found.. 
c) 	For frames transmitted during the contention free period the duration value shall be set to 0 and the most significant bit shall be set to ‘1’.
		
	7.1.3.3	TT	t	Y	The range of SID values as per the definition of the TIM and the Virtual Bit Map allows for only the range (0²N²2008) therefore this section and Table 3 should reflect this.	In subpart a) change the number 16383 to 2008.

In table 3 change the last line to indicate SID Bits 13-0 are from 1-2008.

Add lines to table 3 indicating that:

Bit 15    Bit 14    Bit 13-0
   1            1            0         Reserved
   1            1      2009-16383 Reserved		
	7.1.3.3	jz	t	Y	The text for (a) and (b) disagrees with Table 3	a)	In Control Type frames of subtype PS-Poll, the Duration/ID field shall carry the station identity (SID) of the station that transmitted the frame in the 14 least-significant bits, with the 2 most-significant bits set to '11'. The value of the SID shall be in the range 1 - 16383. The bit-pattern 1100000000000000 shall be illegal.
b)	In all other frames the Duration/ID field shall contain a duration value as defined for each frame type in clause 4.2. For frames transmitted during the contention free period the Duration/ID field shall have the most significant bit set to ‘1’ and all other bits set to ‘0’.		
	7.1.3.3	TT	t	Y	The range of SID values as per the definition of the TIM and the Virtual Bit Map allows for only the range (0²N²2008) therefore this section and Table 3 should reflect this.	In subpart a) change the number 16383 to 2008.

In table 3 change the last line to indicate SID Bits 13-0 are from 1-2008.

Add lines to table 3 indicating that:

Bit 15    Bit 14    Bit 13-0
   1            1            0         Reserved
   1            1      2009-16383 Reserved		
	7.1.3.4 
A.4.4	db	T	Y	w/o the requested change the Draft is technically incorrect - since approved “standard” language was not used the draft does not corectly convey operational requirements.	source address, destination address, transmitting station address and receiving station address.  The usage of the four address fields in each frame type is indicated by the abbreviations BSSID, DA, SA, RA, TA indicating BSS Identifier, Destination Address, Source Address, Receiver Address and Transmitter Address, respectively.  Some frames may not contain some of the address fields.
		
	7.1.3.4.3	BO	E		Expunge archaic usage.	The value of this field in an IBSS shall be a locally administered IEEE MAC address formed from the least significant 46 bits of the TSF Timer at the creation time of the IBSS.		
	7.1.3.4.3
11.1.3
	sb	t	n	For D3 we changed the IBSS BSSID to be the least significant 46 bits of the TSF timer. The idea here was to overcome the problem of a STA starting and IBSS, other stations joining, then the original station going away, coming back into range and wanting to start another IBSS. The new proposal doesn’t fix this problem. Suppose a station starts an IBSS, it decides to do this after a set time scanning and all the rest. It then initialises its TSF timer and starts transmitting Beacons. The question arises as to at what TSF point you choose to set your BSSID. If it is after initialising you always come up with a BSSID close to 0. This therefore makes the original problem more likely. You need something unique to both station and time here. I propose that we use some of the original idea with a random element to cure the original problem. The proposal is then to use the least significant 30 bits of the IEEE address of the STA starting the IBSS with a 16 bit random number. 	The value of this field in an ad-hoc network (IBSS), shall be a locally administered IEEE MAC address. The least significant 16 bits of the address shall be set to a random number between 0 and 65535. The upper 30 bits shall be set equal to the least significant 30 bits of the universal IEEE address of the STA initiating the BSS. The Individual/Group bit of the address shall be set to ‘0’. The Universal/Local bit of the address shall be set to ‘1’. This mechanism is used to ensure a high probability of selecting an unique BSSID.		
	7.1.3.4.3
11.1.3
	sb	t	n	For D3 we changed the IBSS BSSID to be the least significant 46 bits of the TSF timer. The idea here was to overcome the problem of a STA starting and IBSS, other stations joining, then the original station going away, coming back into range and wanting to start another IBSS. The new proposal doesn’t fix this problem. Suppose a station starts an IBSS, it decides to do this after a set time scanning and all the rest. It then initialises its TSF timer and starts transmitting Beacons. The question arises as to at what TSF point you choose to set your BSSID. If it is after initialising you always come up with a BSSID close to 0. This therefore makes the original problem more likely. You need something unique to both station and time here. I propose that we use some of the original idea with a random element to cure the original problem. The proposal is then to use the least significant 30 bits of the IEEE address of the STA starting the IBSS with a 16 bit random number. 	The value of this field in an ad-hoc network (IBSS), shall be a locally administered IEEE MAC address. The least significant 16 bits of the address shall be set to a random number between 0 and 65535. The upper 30 bits shall be set equal to the least significant 30 bits of the universal IEEE address of the STA initiating the BSS. The Individual/Group bit of the address shall be set to ‘0’. The Universal/Local bit of the address shall be set to ‘1’. This mechanism is used to ensure a high probability of selecting an unique BSSID.		
	7.1.3.5	jz	e		“B1” should be “B15” in Figure 14			
	7.1.3.5	TT	t	Y	Since management frame also have a sequence number and are interleaved with MSDUs the wording must change to indicate that MSDU sequence numbers will not necessarilty be sequential.	Change second sentence:

MSDUs and Management frames transmitted by each station.......		
	7.1.3.5	TT	t	Y	Since management frame also have a sequence number and are interleaved with MSDUs the wording must change to indicate that MSDU sequence numbers will not necessarilty be sequential.	Change second sentence:

MSDUs and Management frames transmitted by each station.......		
	7.1.3.5.1	AS	t	y	Management frames are not MSDUs, yet they must have sequence numbers to allow duplicates to be detected	The Sequence Number shall be a 12 bit field indicating the sequence number of the MSDU or the Management frame.		
	7.1.3.5.1	AS	T	y	MSDUs and mangement frames transmitted by the AP cannot be numbered seuentially.

Senario:
The AP is transmitting a fragmented burst and defers due to a dwell boundary. Before being able to complete the transmission of the burst, TBTT happens. What sequence number does the beacon have, and when does the remaining burst get transmitted. In addition, if the beacon happens to be a DTIM, does the AP transmit the broadcast traffic before completing the previous burst. This further complicates the sequence number issue.	Original text:
The Sequence Number shall be a 12 bit field indicating the sequence number of the MSDU. MSDUs transmitted by each station shall be numbered sequentially starting at zero. Each transmission of an MSDU or fragment thereof shall contain the sequence number of that MSDU. The sequence number shall remain constant in all retransmissions of an MSDU or fragment. The sequence number series repeats every 4096 MSDUs, with 0 following 4095.
Replacement text:
The Sequence Number is a 12 bit field indicating the sequence number of an MSDU or a management frame. Directed MSDUs and management frames transmitted by each station shall be numbered sequentially starting at zero. Broadcast/Multicast MSDUs and management frames shall be numbered zero. Each MPDU shall contain the sequence number of the associated MSDU or mangement frame. The sequence number shall remain constant in all retransmissions of an MPDU. The sequence number series repeats every 4096 directed MSDUs, or management frames, with 0 following 4095.
		
	7.1.3.5.2	ch	e		missing digit on the bit number to the far right	change “1” to “15”		
	7.1.3.5.2	ch	e		missed capitalization, second sentance	The Fragment Number shall		
	7.1.3.7
14.3.2.2.2
14.3.2.3
15.2.3.6
15.2.4
16.2.4.6	RM	e		Use consistent descriptions for Polynomials in these section	some use xn+xn-1+xn-2....
Others use z transform notation
zn+zn-1+zn-2....
		
	7.2.1	jz	T	Y	Treating SIFS as a constant value in the MAC is wrong. Implementations must be allowed a certain amount of “slop” for interframe timings. They must ensure that their frames don’t start too soon after a previous frame (or else the intended recipient may not yet be ready to receive), nor too long (or someone else may grab the medium). We need three SIFS values: min-SIFS, nominal-SIFS and max-SIFS. The duration field should be encoded based on the maximum length of time we allow to elapse between frames (max-SIFS). But the MAC should only wait min-SIFS before telling the PHY to transmit. Basically, the standard has an idealized notion of a MAC that instantaneously commands the PHY to do something, and the PHY instantaneously responds. Real implementations may not be able to ensure sub-microsecond repeatability in timings. There needs to be a (small) window within which frame transmission can commence.
Therefore, we need to add text to clarify how to do the Duration calculations. So add a paragraph between the first and second ones in 7.2.1.	For the purposes of calculating the value in the Duration field, the term “SIFS interval” shall refer to the largest amount of time (as specified in the PHY MIB) that may elapse between the end of receipt of a frame and the initiation of transmission of an immediate response.		
	7.2.1.3	AS	E	y	The More Framgents bit is no more.	If the Last Fragment bit was set to '1' in the Frame Control field of the immediately previous directed Data or Management frame, the Duration value shall be set to 0. If the Last Fragment bit was set to '0' in the Frame Control field of the immediately previous directed Data or Management frame, the Duration value shall be the value obtained from the Duration field of the immediately previous Data or Management frame, minus the time, in microseconds, required to transmit the ACK frame and its SIFS interval. If the calculated duration includes a fractional microsecond, that value shall be rounded up to the next higher integer.
		
	7.2.2
7.2.2.1	sb	e	n	Duplicate section numbering	-		
	7.2.2.1	mif	E	N	Consistence, correct use of terminology	Data frames sent during the contention period shall use the Data Subtypes:  Data, or Null Function.  Data frames sent by, or in response to polling by, the point coordinator during the contention free period shall use the appropriate ones of the Data Subtypes based upon the usage rules:
	Data+CF-ACK, Data+CF-ACK+CF-Poll, CF-Poll, and CF-ACK+CF-Poll shall only be sent by a point coordinator.
	Data, Data+CF-ACK, Null Function, and CF-ACK may be sent by the point coordinator or by any CF-aware station.
Stations receiving Data frames shall only process the Data frame body, and shall only consider the frame body as the basis of a possible indication to LLC, if the Data Subtype is of the form Data* (subtype value 00xx).  CF-Aware stations shall interpret all Subtype bits of received Data frames for CF purposes, but shall only inspect the frame body if the Subtype is of the form Data* (subtype value 00xx).
If the More Fragments bit is set to '0' in the Frame Control field of this frame and the Address 1 field contains an individual address, the Duration value shall be set to the time, in microseconds, required to transmit one ACK frame, plus one SIFS interval, unless the frame is being transmitted during a contention free period, in which case the duration field shall be set to 32768. If the More Fragments bit is set to '0' in the Frame Control field of this frame and the Address 1 field contains a group address, the Duration value shall be set to 0, unless the frame is being transmitted during a contention free period, in which case the duration field shall be set to 32768. If the More Fragments bit is set to '1' in the Frame Control field of this frame, and the Address 1 field contains an individual  address, the Duration value shall be the time, in microseconds, required to transmit the next fragment of this Data frame, plus two ACK frames, plus three SIFS intervals, unless the frame is being transmitted during a contention free period, in which case the duration field shall be set ot 32768. If the More Fragments bit is set to '1' in the Frame Control field of the frame, and the Address 1 field contains a group address, the Duration value shall be the time, in microseconds, required to transmit the next fragment of this Data frame, plus one SIFS interval, unless the frame is being transmitted during a contention free period, in which case the duration field shall be set to 32768. If the calculated duration includes a fractional microsecond, that value shall be rounded up to the next higher integer. All stations shall process the duration field values less than or equal to 32767 from valid data frames to update their NAV settings as appropriate under the coordination function rules.		
	7.2.2.1	AS	E	y	The More Fragments bit is no more.	If the Last Fragments bit is set to '1' in the Frame Control field of this frame and the Address 1 field contains a unicast address, the Duration value shall be set to the time, in microseconds, required to transmit one ACK frame, plus one SIFS interval. If the Last Fragments bit is set to '1' in the Frame Control field of this frame and the Address 1 field contains a multicast address, the Duration value shall be set to 0. If the Last Fragments bit is set to '0' in the Frame Control field of this frame, and the Address 1 field contains a unicast address, the Duration value shall be the time, in microseconds, required to transmit the next fragment of this Data frame, plus two ACK frames, plus three SIFS intervals. If the Last Fragments bit is set to '0' in the Frame Control field of the frame, and the Address 1 field contains a multicast address, the Duration value shall be the time, in microseconds, required to transmit the next fragment of this Data frame, plus one SIFS interval. If the calculated duration includes a fractional microsecond, that value shall be rounded up to the next higher integer. All stations shall process the duration field contents of valid data frames to update their NAV settings as appropriate under the coordination function rules.		
	7.2.2.1 
A.4.4	db	T	Y	w/o the requested change the Draft is technically incorrect - since approved “standard” language was not used the draft does not corectly convey operational requirements.	A station shall use the contents of Address 1 field to perform address matching for receive decisions. In cases where the Address 1 field contains a group address, the BSSID shall also be validated to ensure that the broadcast, or multicast originated in the same BSS.
		
	7.2.2.1	jz	t	Y	Change every occurrence of “PCF” to “Point Coordinator” or “Station performing the Point Coordination Function”. The PCF is not a station, it is a function, and thus it cannot send frames.			
	7.2.2.1	jz	T	Y	The second-to-last paragraph makes no sense, and “Data*” is evidently using some weird convention that nobody bothered to explain.	Stations receiving Data frames shall only consider the frame body as the basis of a possible indication to LLC if the frame has a Type field value of Data.  Stations capable of transmitting in response to polling by a Point Coordinator shall interpret all Subtype bits of received Data frames for CF purposes, but shall only inspect the frame body if the frame type is Data.		
	7.2.2.1,
7.2.3	ch	e		to increase the consistancy and clarity of point (b)	b)	If the station is a member of an IBSS, the IBSS Identifier shall be the BSS ID of the IBSS.		
	7.2.3	mif	e	N	consistency	If the More Fragments bit is set to '0' in the Frame Control field of this frame and the DA contains an individual address, the Duration value shall be set to the time, in microseconds, required to transmit one ACK frame, plus one SIFS interval, unless the frame is being transmitted during a contention free period, in which case the duration field shall be set to 32768. If the More Fragments bit is set to '0' in the Frame Control field of this frame and the DA contains a group address, the Duration value shall be set to 0, unless the frame is being transmitted during a contention free period, in which case the duration field shall be set to 32768. If the More Fragments bit is set to '1' in the Frame Control field of this frame, and the DA contains an individual address, the Duration value shall be the time, in microseconds, required to transmit the next fragment of this Management frame, plus two ACK frames, plus three SIFS intervals, unless the frame is being transmitted during a contention free period, in which case the duration field shall be set to 32768. If the More Fragments bit is set to '1' in the Frame Control field of the frame, and the DA  field contains a group address, the Duration value shall be the time, in microseconds, required to transmit the next fragment of this Management frame, plus one SIFS interval, unless the frame is being transmitted during a contention free period, in which case the duration field shall be set to 32768. If the calculated duration includes a fractional microsecond, that value shall be rounded up to the next higher integer.		
	7.2.3.1
7.2.3.9
7.3.1
11.1.2.1
11.1.3.3
11.1.5	WD	T	Y	Currently the synchronization between stations in an IBSS and between stations and AP is determined by the adoption of the TSF timer according to a defined update mechanism.
However the most essential information for the MAC is to determine when the next and subsequent TBTT synchronization points are located. Similar for Fhopping stations they need to know when the next Dwell boundary is to occur.
The TBTT is currently defined as the instance in time when TSF timer MOD Beacon Interval = 0
Sinse the TSF timer is defined as a 64 bit value, it is a complex modulo operation to calculate the next TBTT, which needs to be performed after every Association and Reassociation.
It is important for stations to know pretty accurate, when that next TBTT occurs, because that will usually determine when that station is to wake-up, to be ready to receive the next Beacon. In addition it determines when in a PCF, stations are supposed to set their NAV, to prevent contention with the PCF.
The Modulo operation can be quite complex, if the Beacon Interval is not a power of two value in usec.

It is therefore suggested to include an extra “Next TBTT” parameter in the Beacon and Probe response frames, that does allow a station to simply derive the next TBTT.
This 16 bit parameter should be the least 16 bit Kusec value of the TSF timer, when the next TBTT occurs.

A similar provision can be made in the FH Parameter Set field, by specifying a “Next Dwell” field in exactly the same way.	Modify section 7.2.3.1, and 7.2.3.9:
Insert the “Next TBTT” paremeter at position 2 in the Beacon and Probe response frame formats.

Add a section 7.3.1.11 Next TBTT
This field represents when the next TBTT will occur. The length of the Next TBTT field is two octets, and defines the Kusec boundary at which this field equals the bits 11 till 26 of the TSF Timer.

Modify section 7.3.2.3
Add one subfield in figure 27, between Dwell Time and Hop Set, called “Next Dwell”.
Add subsequent text to define the “Next Dwell” subfield as follows:
The Next Dwell field represents when the next Dwell boundary will occur. The length of the Next Dwell subfield is two octets, and defines the Kusec boundary at which this field equals the bits 11 till 26 of the TSF Timer.

Add to section 11.1.2.1, below the Figure 54.
Beacons and Probe Response frames will also include a field that specify when the “Next TBTT” does occur.  Stations should not rely on the “Next TBTT field alone, because it is possible that Beacons will be missed by that station.

Add at end of  section 11.1.3.3 :
At every synchronization event stations can use the next TBTT field in the Beacon or Probe response frames to synchronize its TBTT predictions to the BSS.

Add at end of section 11.1.5:
The Next dwell subfield in the FH Parameter Set field present in each Beacon or Probe response frame, will help stations to synchronize to the next dwell boundary. They will however need to maintain their own “Next Dwell” boundary, by subsequently adding acurrent_Dwell_Time each time the Dwell boundary is reached to prevent that all Beacons need to be successfully received to maintain synchronization.
		
	7.2.3.1	AS	t	y	When is the AP allowed to change values that appear in this field, e.g. Beacon Interval, Dwell interval. 

The TSF mod these values determine other MAC parameters, such as hop index, and time to CF start, which would be impossible to maintain if the AP is free to change these at any time.			
	7.2.3.1	AS	t	y	The TIM field should have a note also indicating it is only requred by APs.	4. The TIM information shall be mandatory only within Beacon Frames generated by APs.		
	7.2.3.1	TT	t	Y	See 7.3.1.11 for detatils.	Add the following element to the table:

CW (Contention Window)		
	7.2.3.1
7.2.3.9
7.3.1.(new)
11.1.3.3	mif	T	Y	The timestamp and beacon interval fields in the Beacon and Probe Response frames providea timebase reference point and interval which is minimally sufficient to allow a station to synchronize with the beacon interval of a BSS.  However, these fields do not provide enough information to permit power efficient synchronization, because there is nothing which says how long until the next TBTT.  If power consumption were not an issue, the STA could simply remain active until the next Beacon frame from the BSS is received.  However, the inclusion of one additional field in certain management frames completely solves this problem, allowing the STA to know the time remaining until the next TBTT.

This new field is a 2-octet field with the number of Kmicroseconds (rounded down) until the Next TBTT.  This value is readily calculated, since it is equal to bits 10 through 25 of the value the TSF timer will have at the next TBTT.  As a minimum, the new Next TBTT field should be added to Beacon and Probe Response frames	Add a 2-octet field, ÒNext TBTTÓ  to the frame body of Beacon and Probe Response frames.  The recommended location is as field 2 or 3 (either just before or just after the Beacon Interval field, my preference is just after Beacon Interval & before Capability Information).
7.3.1.(new)	Next TBTT
This field shall contain the number of Kmicroseconds (rounded down) between the time represented in the Timestamp field of this frame and the next Target Beacon Transmission Time (TBTT).  The value of this field shall be equal to, or shall be one less than, the value that  bits 10Ð25 of the timestamp (TSF timer) will hold at the next TBTT.  The length of the Next TBTT field is two octets.
It may also be worth mentioning the Next TBTT field in clause 11.  The most important place is sub-clause 11.1.3.3:
b) If a BSS of the appropriate type with the specific ESSID is found, adopt the BSSID, channel synchronization information, TSF timer value of the BSS.  The Next TBTT field permits synchronization with the beacon timing of the BSS without waiting for as much as a full beacon interval.
		
	7.2.3.1	TT	t	Y	See 7.3.1.11 for detatils.	Add the following element to the table:

CW (Contention Window)		
	7.2.3.5
7.2.3.7	WD	E	n	There is no real difference in an Association and Re-Association response frames. they can be collapsed into a single Association Response frame.	The Re-Association response frame can be deleted.		
	7.2.3.5	TT	t	Y	See 7.3.1.11 for detatils.	Add the following element to the table:

CW (Contention Window)		
	7.2.3.5	TT	t	Y	See 7.3.1.11 for detatils.	Add the following element to the table:

CW (Contention Window)		
	7.2.3.6
7.3.1.5	WD	T	y	The current specification of the Reassociation request format, does have a fixed field (Current AP Address) that follows variable length fields. The convention was that  fixed fields would preceed all variable length fields.
It is recognised that this is done to make the reassociation frame as identical as possible to the association frame. To achieve the same goal, while maintaining the fixed field, variable field format ordering, it is recommended to make the “Current AP Address” an element field.	Delete current section 7.3.1.5, and effectively move the text to section 7.3.2.8

Add one Information element called “Currect AP Address” to the table 18, with Element ID code 7.

Add a section 7.3.2.8 Current AP Address
The Current AP Address field shall be the MAC address of the access point with which the station is currently associated. The length of the Current AP Address field is six octets.
Copy figure 30, change ATIM window into Current AP address with length 6,  and give it the title: Figure 31: Current AP address element format.		
	7.2.3.6	TT	t	Y	For ease of processing it was decided a while ago that all fixed fields are at the beginning of the Management Frame Body and the Elements are at the end.  Current AP Address is not an Element!

See paper 96/19 for further comments.	Move Current AP Address field from end of Reassociation Request Frame Format to after Listen Interval field.		
	7.2.3.6	mif	t	Y	The current layout of the frame body of Reassociation Request violates the general rule that fixed fields come before variable fields (elements).  If the uniformity of the reassociation request frame body with the association request frame body is felt to be sufficiently important, I would recommend adding a 6-octet reserved field to the association request frame between ESSID and supported rates to keep the format consistency without requiring that the AP handling a reassociation request parse a variable length element in order to determine the curent AP address.	Exchange the order of fields 4 and 5, to place current AP address before supported rates.		
	7.2.3.6	TT	t	Y	For ease of processing it was decided a while ago that all fixed fields are at the beginning of the Management Frame Body and the Elements are at the end.  Current AP Address is not an Element!

See paper 96/19 for further comments.	Move Current AP Address field from end of Reassociation Request Frame Format to after Listen Interval field.		
	7.2.3.8	ch	e		wrong subtype	The Frame Body of a Management frame of Subtype Probe Request shall contain the following information:		
	7.3.1.1	jz	t	Y	The Authentication Algorithm Number and Transaction Sequence number need not be 16 bits long. A single octet for each is more than adequate, and it is wasteful to throw away bandwidth for nothing. Change “two octets” to “one octet”.			
	7.3.1.10	mif	e	N	obsolete wording	This field shall represent the value of the TSFTIMER (see clause 11.1) of a frame's source.  The length of the timestamp field is eight octets.
		
	7.3.1.11

9.2.4	TT	t	Y	There is a need to be able to control the aCWmin and aCWmax values on a per BSS basis.  In addition, this control must be fair to all nodes in the BSS.  

The Current CWmin default of 7 will work fine for a few nodes in a BSS but when the number gets large (>50) then the number of collisions would increase dramatically.  Simply making aCWmin = 31 as Wim has asked may times will improve this situation, however it is very inefficient for an STA who is the only associated STA in a BSS to have to wait an average of 15 slot times to transmit each frame.

The tradeoff between the individual STAÕs response time vs BSS throughput will change depending on the application, therefore CW should be a dynamic variable.

The current standard does not have any way for  aCWmin to be adjusted by any management entity.  Putting the fields in the Assocation Response and Beacon frame would allow a management entity to set these on a per BSS basis in a fair manner.  The MIB variables are already GET-REPLACE.

The default setting should be defined in the MIB and used unless the AP has the capability (and the user has a need) to alter the numbers.  From the MAC point of view it does not care what the algorithm is that sets the CWÕs, but how and where it gets the values to use, as long as everyone in the BSS uses the same numbers.

Simple algorithms, which are outside the scope of this standard, could base CW on the number of associated STAs, the current traffic statistics, the number of retry attempts, etc.  All of these are, or can be, known by the AP which is the one who should set the CW for its BSS.

	Add the fixed field:  CW (Contention Window) which contains:

CWmin
CWmax

A STA receiving a management frame with a valid BSSID and with this fixed field shall set its MIB variables aCWmin and aCWmax to these values. 		
	7.3.1.11
9.2.4 

	TT	t	Y	See 7.3.1.11 for detail comment.

Immediately after Figure 39 which shows the Exponential increase of CW there is the statement:

ÔaCWmin and aCWmax are MAC constants that should be fixed for all MAC implementations, beacuse they effect the access fairness between stations.Õ

This statement is totally true however aCWmin and aCWmax are GET-REPLACE MIB variables.  The optimum setting for these, especially aCWmin, is different depending on:

  -  the number of active STAs in a BSS
  -  the percentage of these STAs that on average have
     data to send.

Since each collision wastes bandwidth, reducing the number of collisions should improve the overall BSS throughput, therefore aCWmin and aCWmax should be controlled by the AP of a BSS by including these parameters in each Beacon frame.	Change last sentence of 9.2.4 to say:

ÒaCWmin and aCWmax are settable MAC constants that should shall be fixed for common to all MAC implementations, beacause they effect the access fairness between stations.  STAs within a given BSS.  Each STA will update its aCWmin and aCWmax variables from the CW field contained in each Beacon frame received from its AP.Ó		
	7.3.1.11

9.2.4	TT	t	Y	There is a need to be able to control the aCWmin and aCWmax values on a per BSS basis.  In addition, this control must be fair to all nodes in the BSS.  

The Current CWmin default of 7 will work fine for a few nodes in a BSS but when the number gets large (>50) then the number of collisions would increase dramatically.  Simply making aCWmin = 31 as Wim has asked may times will improve this situation, however it is very inefficient for an STA who is the only associated STA in a BSS to have to wait an average of 15 slot times to transmit each frame.

The tradeoff between the individual STAÕs response time vs BSS throughput will change depending on the application, therefore CW should be a dynamic variable.

The current standard does not have any way for  aCWmin to be adjusted by any management entity.  Putting the fields in the Assocation Response and Beacon frame would allow a management entity to set these on a per BSS basis in a fair manner.  The MIB variables are already GET-REPLACE.

The default setting should be defined in the MIB and used unless the AP has the capability (and the user has a need) to alter the numbers.  From the MAC point of view it does not care what the algorithm is that sets the CWÕs, but how and where it gets the values to use, as long as everyone in the BSS uses the same numbers.

Simple algorithms, which are outside the scope of this standard, could base CW on the number of associated STAs, the current traffic statistics, the number of retry attempts, etc.  All of these are, or can be, known by the AP which is the one who should set the CW for its BSS.

	Add the fixed field:  CW (Contention Window) which contains:

CWmin
CWmax

A STA receiving a management frame with a valid BSSID and with this fixed field shall set its MIB variables aCWmin and aCWmax to these values. 		
	7.3.1.11
9.2.4	TT	t	Y	See 7.3.1.11 for detail comment.

Immediately after Figure 39 which shows the Exponential increase of CW there is the statement:

ÔaCWmin and aCWmax are MAC constants that should be fixed for all MAC implementations, beacuse they effect the access fairness between stations.Õ

This statement is totally true however aCWmin and aCWmax are GET-REPLACE MIB variables.  The optimum setting for these, especially aCWmin, is different depending on:

  -  the number of active STAs in a BSS
  -  the percentage of these STAs that on average have
     data to send.

Since each collision wastes bandwidth, reducing the number of collisions should improve the overall BSS throughput, therefore aCWmin and aCWmax should be controlled by the AP of a BSS by including these parameters in each Beacon frame.	Change last sentence of 9.2.4 to say:

ÒaCWmin and aCWmax are settable MAC constants that should shall be fixed for common to all MAC implementations, beacause they effect the access fairness between stations.  STAs within a given BSS.  Each STA will update its aCWmin and aCWmax variables from the CW field contained in each Beacon frame received from its AP.Ó		
	7.3.1.2	jz	t	Y	Change “two octets” to “one octet” (see my comment on 7.3.1.1)			
	7.3.1.4	ch	e		inconsistant subfield name, first sentance after subfield list	APs within an Infrastructure BSS shall set the Infrastructure BSS subfield to '1'		
1	7.3.1.4	jjk	e		paragraph 2 has incorrect term compared to immediatly prior list	ESS should be Infrastructure BSS		
	7.3.1.4	ch	t		A STA which is CF-Aware should set the CF-Aware capabilities bit, period. Why sometimes and not others? 	An STA that is CF-Aware shall set the CF-Aware subfield to '1'.		
	7.3.1.4	WD	T	n	Suggest to add the following Capability bits, which are valid in Beacon and Probe response Frames:
- DS Connected: This bit indicates that a DS is connected to the AP. This indicates to the station whether or not it is usefull to scan for other AP’s in case the quality of the link with the AP reduces below a threshold that normally causes a scanning process for a better AP to be started. this prevents that such stations will consume a lot of (battery) power to do so.

- Via WDS: This bit indicates to the station that this AP is using a Wireless DS link.
Stations can then make a choice which AP to use in case multiple AP’s are available. This allows for transfer delay and medium load optimization in the station.	Add the following bits to the subfield list:
- Bit 7:  DS Connected
- Bit 8:  Via WDS 
Bits 9-15: reserved
Add text:
The DS Connected and Via WDS subfields are valid in Beacon and Probe Response frames that originate from a Station in an AP, and will be zero in all other management frames that contain the Capability Information field.
A “1” in the DS Connected subfield indicates that there is a DS available at the AP.
A “1” in the Via WDS subfield indicates that the AP is connected to a Wireless DS.		
	7.3.1.4	WD	T	Y	A “Polling_PCF” bit is needed in Beacons and (Re)Association response frames as generated by AP’s. This is to signal to a CF-Aware station that the PCF does implement Polling capability, so that it can depend on the CF-Polling mechanism. Currently a CF-Aware station can not recognise whether such a polling mechanism is available, because a PCF (recognised by the presence of a CF Parameter Set Information Element)  that does only use the Contention free period for down traffic, and which does not support a polling mechanism is valid under this standard.	Add bit 4: Polling PCF, and make Bits 5-15: Reserved.
Add text:
The Pollingf PCF field is set to “1” in Beacon and (Re)Association response frames generated by an AP, if that AP supports a PCF that includes a polling mechanism that the station can rely on.
This field shall be “0” for all other Management frames that contain the Capabilities information field.		
	7.3.1.4	WD	T	Y	Currently there is no way for a station to know whether the other side supports WEP. Furthermore if WEP is required, then the “Clear text” frame will be acked, but will not be send to LLC or DS.
Define a “WEP supported”, and a “WEP mandatory” bit (only setable in AP) in the capability information field, which is set accordingly in the Beacon, Probe response, (Re)-Association Request and Response frames	Add bit 5: WEP supported
Add bit 6: WEP mandatory
Bits 7-15: reserved.
Add text:

The WEP supported subfield shall be set in all Beacon, Probe response and (Re)-Association Request and response frames, to indicate that the sending station (or AP) does support the WEP mechanism, and has a encryption key loaded.
Add text:
The WEP mandatory subfield shall be set in all Beacon, Probe response and (Re)-Association response frames, to indicate that the AP does require the WEP mechanism to be active for any transmission with the to-DS bit set.		
	7.3.1.4	TT	t	Y	See paper 96/19 for comments on new bits for Capability Information field.	see paper 96/19.		
2	7.3.1.4	jjk	t	y	section 9.3.4 refers to this list as indicating also the possibility that a PCF would use CFP for sending data only and not polling. Need to add another bit ot capabitlity information	Change
Bit 0:	Infrastructure BSS
Bit 1:	Independent BSS
Bit 2:	CF-Aware
Bit 3:	CF Polling Request
Bit 4:     CF Non Polling
Bits5- 15: Reserved
Add paragraph at end:
An AP that contains a  PC,  but will not poll shall set the CF Non Polling subfield to ‘1’.  The CF Non Polling field shall be set to ‘0’ in all other management frames that contain the Capabilities Information Field.
		
	7.3.1.4	jz	T	Y	The CIF needs to tell a STA everything it needs to know to decide whether it wants to associate with an AP. It should have a bit indicating whether WEP is supported, a bit indicating whether Open System Authentication is allowed, and a bit indicating whether the AP is able to accept more associations (in a congested environment, APs need to be able to tell STA to go away and associate with a different AP).	Bit 4: WEP Supported
Bit 5: Open System Authentication Allowed
Bit 6: Association Impossible

A STA shall set the WEP Supported subfield to ‘1’ if it is capable of using WEP to encrypt traffic. A STA that requires the use of WEP shall not attempt to associate with an AP that does not support WEP.
A STA shall set the Open System Authentication Allows subfield to ‘1’ if it allows authentication using the Open System algorithm. A STA that requires the use of the Open System authentication algorithm shall not attempt to associate with an AP that does not allow it.
An AP shall set the Association Impossible subfield to ‘1’ if it is not capable of allowing additional associations. A STA shall not attempt to associate with an AP that has set the Association Impossible flag to ‘1’.		
	7.3.1.4	mif	T	Y	The definitions of CF-Aware and CF-Polling Request bits are incomplete in this section.  These bits are intended to be used to indicate CF-Awareness and request CF-Polling when used by STA in requests, and to be used to indicate the presence of a point coordinator and whether that point coordinator generates CF-Polls (vs. being Òdelivery onlyÓ) when used by APs in Beacons and responses.  However, only the STA usage is defined in this section.

The adoption of the motion from submission 95-150 (July, 1995 Plenary meeting) included both the STA and AP definitions for these bits, but placed that text into clause 6 (now clause 9).  The information on the usage of these capability bits was moved to clause 4 (now clause 7), but only part of the information was retained in that move. Text changes to the right designated [1] correct this omission.

The text addition to the right designated [2] is an additional, desirable function which can be served by these same bits.  This was not part of the draft changes adopted from 95-1550, but is recommended for inclusion now.  The principal change needed to change by Òdo not approveÓ vote regarding this item is [1].  Were it not for the deletion of the material restored by [1], the recommendation [2] would be a minor technical comment.	[1]
An STA that is CF-Aware shall set the CF-Aware subfield to '1' in Association and Reassociation Request Management frames. An AP at which a point coordinator is operating shall set the CF-Aware subfeld to Ô1Õ in Beacon, Association Response, Reassociation Response, and Probe Response Management frames. The CF-Aware subfield shall be set to '0' in all other Management frames that contain the Capability Information field.
An STA that is CF-Aware shall request polling by the Point Coordinator by setting the CF-Polling Request subfield to '1' in Association and Reassociation Request Management frames. An AP at which a point coordinator that maintains a polling list (generates CF-Polls) is operating shall set the CF-Polling Request subfield to Ô1Õ in Beacon, Association Response, Reassociation Response, and Probe Response Management frames. The CF-Polling Request subfield shall be set to '0' in all other Management frames that contain the Capability Information field.
[2]
Change the inserted sentence in the second paragraph, above to read:
ÒAn AP at which a point coordintor that maintins a polling list (generates CF-Polls) is operating shall set the CF-Polling Request subfield to Ô1Õ in Beacon and Probe Response Management Frames; and shall set the CF-Polling Request subfield to Ô1Õ in Association Response and Reassociation Response Management frames when responding to n Association Request or Ressociation Request which had the CF-Polling Request field set to Ô1Õ and for which the requesting station is being placed onto the CF-polling list.
		
	7.3.1.4
8.3.2	mif	t	Y	There is no current way to tell, in advance of attempting to transfer MSDUs, whether a station is using WEP, nor whether that station excludes or allows unencrypted franes to reach its LLC (or DSM in the case of an AP).  Since the management frames by which an STA finds the AP and associates with the BSS are not encrypted even if WEP is mandatory for the subsequent data frames, and MPDUs received with valid format and CRC are ACKed whether decryption is successful or not, as well as for unencrypted frames when excluding unencrypted frames from the DSM, a station which does not use WEP could successfully associate with an AP that requires WEP, and proceed to consume bandwidth on the WM, but never get any MSDUs to their intended destinations.  This is an undesirable situation and an unjustifiable waste of time on the wireless medium, which is easily preventable by allocating two of the reserved capability information bits for this purpose.	Add the following to the definition of capability information field bits, add the explanatory paragraph at an appropriate point later in this sub-clause.
Bit 0:	Infrastructure BSS
Bit 1:	Independent BSS
Bit 2:	CF-Aware
Bit 3:	CF Polling Request
Bit 4:	WEP In Use
Bit 5:	WEP Mandatory
Bits 6 - 15: Reserved
An STA that has aPrivacy_Invoke set to true shall set the WEP In Use subfield to Ô1Õ in Association Request, Association Response, Reassociation Request, Reassociation Response, Beacon and Probe Response Management frames. The WEP In Use subfield shall be set to '0' in all other Management frames that contain the Capability Information field.
An STA that has aExclude_Unencrypted set to true shall set the WEP Mandatory subfield to Ô1Õ in Association Request, Association Response, Reassociation Request, Reassociation Response, Beacon and Probe Response Management frames. The WEP Mandatory subfield shall be set to '0' in all other Management frames that contain the Capability Information field.
Add to 8.3.2:
The values of aPrivacy_Invoke and aExclude_Unencrypted are also used to determine the values to transmit in the WEP In Use and WEP Mandatory subfields of the Capability Information fields in certain Management frames.
		
	7.3.1.4	TT	t	Y	See paper 96/19 for comments on new bits for Capability Information field.	see paper 96/19.		
	7.3.1.4,
9.3.4	ch	T	Y	Section 9.3.4 refers to a use for fields in the Capability Information Field which are not described. Both section need to fix this.	9.3.4:
The form of contention free support provided by the PC is identified in the CF-Polling Request field of the Capability Information field of Beacon, Association Response, Reassociation Response, and Probe Response management frames, which are sent from APs.
7.3.1.4:
An non-AP STA that is CF-Aware shall request polling by the Point Coordinator by setting the CF-Polling Request subfield to '1' in Association and Reassociation Request Management frames. The CF-Polling Request subfield shall be set to '0' in all other Management frames originating from a non-AP STA that contain the Capabilities Information field.
A Point Coordinator (PC) AP shall indicatate use of a polling list by setting the CF-Polling Request subfield to ‘1’ in Beacon, Association Response, Reassociation response and Probe Response Management frames. A PC AP that does not use a polling list shall indicate this by resetting the CF-Polling Request subfield to ‘0’ in Beacon, Association Response, Reassociation response and Probe Response Management frames. The CF-Polling Request subfield shall be set to '0' in all other Management frames originating from a PC AP that contain the Capabilities Information field.		
	7.3.1.6	jz	t		I suggest adding a note that indicates what the Listen Interval field is for.	The Listen Interval field shall be used to indicate to the AP how often an STA will wake to listen to Beacon Management Frames. The AP may use this information in determining the lifetime of frames it buffers for that STA.		
	7.3.1.6 
A.4.4	db	T	Y	w/o the requested change the Draft is technically incorrect - since approved “standard” language was not used the draft does not corectly convey operational requirements.	The Listen Interval field shall be used to indicate to the AP how often an STA shall wake to listen to Beacon Management Frames. The value of this parameter shall be the STA's aListen_Interval MIB		
	7.3.1.7	WD	E	n	Although Table 16 shows that the Reason Code is 16 bit wide, the text says that the code field is only one Octet. A length of two octets is required to assure that fields are at word boundaries.	Change one octet into “two octets.” at the end of the second sentence.		
	7.3.1.7	AS	e	y	Reason code is an octet	8-255		
	7.3.1.7	db	T	Y	Reasons given seem incomplete to me.
Why is 0 reserved? I don’t care for sparse encoding of values here.
	improve table of reasons. (this reviewer is willing to work with others to flesh this out).		
	7.3.1.7	mif	t	Y	The reason code field should be two octets.  Table 16 reserves values through 65535, which cannot be represented in one octet.  Also, there was a decision to align all fields in the management frames, other than in cases of odd-length fields that were always paired when used at all.  While the reason code is an unsual case because of being the only field in the bodies of the notification frames, there may be additional management frame types in the future which need a reason codealong with other fields, resulting in those other fields being misaligned if the reason field is one octet.	Change ÒoneÓ to ÒtwoÓ in the first paragraph of 7.3.1.7.		
	7.3.1.7
7.3.1.9
5.5
	sb	t	n	It is not clear what happens if a STA sends an Association Request to an STA that it is not authenticated with. The correct action I suspect is an Association Response with Status code 11 (STA requesting is not authnticated). Problem is Section 5.5 specifies that an STA can’t send an Association Response since it would seem to be in state 1 wrt the originating STA. I think the solution to this is for the response to the association request to be a deauthentication (which gets the sending STA back to state 1). However, deathentication can only have a reason code - so status code 11 needs to be moved to the reason codes.	Move status code 11 to a reason code.		
	7.3.1.8	mif	e	N	incorrect reference	Change 4.1.2.3 to 7.1.3.3		
	7.3.1.9	ch	t		Two bytes allows for a lot of status values - isn’t one byte enough?	The length of the status code field is one octet.

Table:  202-255 - Reserved		
	7.3.1.9	ch	t		Why leave the values between 19 and 202 for anyone to use for whatever they want?	Table: 20 - 65535 - Reserved		
	7.3.1.9	WD	e	n	Table 17 last entry	Change 202 into 20		
	7.3.1.9	mif	e	N	typo	change 202 to 20 in last line, Table 17		
	7.3.1.9	WD	T	n	What is the meaning of Status Code 13. What is defined as the “Validity “ of the requesting station.
Suggest to delete this Status code.	Delete Status Code 13, or define the meaning of “Validity” of a station.		
	7.3.1.9	WD	T	Y	There need to be a status code added that allows an AP to signal that Association is denied, because the station is not authorised to use the Infrastructure network.
This allows similar constructs as is popular  in current  Network access management implementations, where the station SA (Source Address) can be verified against a list of authorised users of the network.	Add Status Code 20 with meaning:
Association is denied because the station is not authorised to use the network.		
	7.3.1.9	BO	T	Y	This code should be generalized to support future expansion of authentication algorithms	Requested authentication algorithm not acceptable to the responding station		
	7.3.1.9	db	T	Y	This is all wrong. The status code is supposed to be only “go/no go”, the reason for failure is supposed to be in the reason code. This section is not constent with 7.3.1.7	reconcile 7.3.1.7 and 7.3.1.9		
	7.3.2	jz	t		Redraw the figures to include the Element ID for each element. For example:			
	7.3.2	WD	T	Y	All fields are specified such that they are alligned at word boundaries, except for the Information elements. To simplify the Information Element processing, a padding byte should be added where needed at the end of each Information Element, to assure word allignment.	Modify section 7.3.2:
- Add a 1 Byte pad field at end of Figure 24, with text “If length is odd”.		
	7.3.2	db	T	Y	The length field of an info element is limited to 1 octet this is not suffcient - auth challenge text which will be needed in the future to use hooks included for public key auth, will likely be larger than 256, hence if we don’t want to have to redo all the parsing of later we should use a 2 octect len field now.	change len filed to 2 octets.		
	7.3.2
7.3.2.2
7.3.2.3
7.3.2.4
7.3.2.6	mif	t	Y	Each element should have an even number of octets in order to keep the Element ID field of the next element at an even octet boundary in the frame body, and to keep the Element ID/Length pair in a 16-bit word.  This simplifies parsing sequential elements on most types of processors likely to be used to implement a protocol of this type, and facilitates bypassing unnecessary elements or processing elements out of the order in which they appear in the Management d frame body.	Elements are defined to have a common general format consisting of a one-octet Element ID field, a one octet length field and a variable-length element-specific information field.  Each element is assigned a unique Element ID as defined in this specification.   The length field shall be even, and specifies the number of octets in the information field.  
For 7.3.2.2 , 7.3.2.4, and 7.3.2.4, specify that if the length is odd, one pad octet is added at the end of the element.
For 7.3.2.3, add one reserved octet and document the length as 6 octets.		
	7.3.2.1	ch	t		It should be specified whether, for DTIM Period, is 0 invalid or equal to 256.	The DTIM Period field shall indicate the number of Beacon intervals between successive DTIMs.  If all TIMs are DTIMs, the DTIM Period field shall have value 1. DTIM Period of 0 is invalid. The DTIM period field shall be a single octet.		
	7.3.2.1	jz	t		The bit number should be (0 <= N <= 2007), and the word “unicast” should be “directed”.			
	7.3.2.1	jz	t		The last paragraph should begin “In the event that all bits other than bit 0 are 0, the Partial Virtual Bitmap...”			
	7.3.2.1	mif	E	N	Clarify the use for the low-order bit of the Bitmap Control field.	The Bitmap Control field shall be a single octet whose low-order bit contains the Traffic Indicator bit associated with Station ID 0 (set to Ô1Õ in TIM elements of DTIMs when one or more  broadcast or multicast frames are buffered at the AP), and whose high-order seven bits form the Bitmap Offset subfield. The Bitmap Offset subfield is a number between 0 and 250, formed by using the Bitmap Control field with the low-order bit set to 0, and is further described below.
		
	7.3.2.1	ch	T	Y	Subclause 11.2.1.2 says that ID 0 is reserved to indicate broadcast/multicast, and so the correspondign bit in the TIM represetn buffered broadcast/multicast frames at the AP.

This subclause says that the TIM bits indicate specifically the presence of unicast data for the STA associated with the SID.	If bit number N is 0, there are no unicast frames buffered for the station whose Station ID is N. If any unicast frames for that station are buffered, bit number N in the traffic-indication virtual bitmap is 1. 
SID 0 is a reserved value of N, which is an indication of buffered broadcast/multicast frames at the AP. If bit number 0 is 0, there are no broadcast or multicast frames buffered at the AP. If bit number 0 is 1, there are broadcast and/or multicast frames buffered at the AP.		
	7.3.2.1 
A.4.4	db	T	Y	w/o the requested change the Draft is technically incorrect - since approved “standard” language was not used the draft does not corectly convey operational requirements.	The DTIM Count field shall indicate how many Beacons (including the current frame) shall appear before the next DTIM.  A DTIM Count of 0 shall indicate that the current TIM is a DTIM. The DTIM		
	7.3.2.1 
A.4.4	db	T	Y	w/o the requested change the Draft is technically incorrect - since approved “standard” language was not used the draft does not corectly convey operational requirements.	in the bitmap are all 0. In this case, the Bitmap Offset subfield value shall contain the number N1, and the Length field shall be set to (N2  N1 + 4).
		
	7.3.2.3	BO	T	Y	This information has nothing to do with the operation of the MAC.  Its presence here is only a convenient mechanism for the exchange of PHY specific data.  It should be deleted here as well as other references to its use.	
Delete remainder of clause, as well.  This information should be transmitted as part of the PLCP header of every frame.		
	7.3.2.4	BO	T	Y	This clause and all references to supported rates should be deleted.  The use of the described information is not defined anywhere within the draft, there is no service interface to cause the MAC to “change rates” if such a concept can be applied to a MAC, and providing a “hook” of this nature without describing a mechanism for the use of the “hook” in the standard is a road straight to the hell of non-interoperability.  This section should be deleted along with any and all references to multiple rate switching support.			
	7.3.2.4 
A.4.4	db	T	Y	w/o the requested change the Draft is technically incorrect - since approved “standard” language was not used the draft does not corectly convey operational requirements.	The Supported Rates element shall specify all the rates which this station is capable of receiving. The information field is encoded as 1 to 8 octets where each octet describes a single supported rate in units of 100 kbit/s (e.g. a 1 Mbps rate shall be encoded as 0x0A).
		
	7.3.2.4	jz	T	Y	Multirate is broken. We should adopt the text suggested in document 96/8 to fix it. Each PHY should define a Basic_Rate_Set at which all implementations must be able to send/receive. Individual APs can be configured for a primary rate that is different (higher or lower).
For 7.3.2.4, we also need an explanatory note about Supported Rates. Add this text:	For Beacons, Probe Responses, Association Responses and Reassocation Responses, the first rate listed in the Supported Rates element shall be the Primary Rate for that BSS. See subclauses 9.6 and 11.3 for further information on supported rate negotiation.		
	7.3.2.5	ch	t		Remove CF_Period from the CF Parameter set - as long as CF_Count tells the STA when the next CFP is going to be, why does it care how frequent they are?

The STA needs to be prepared to set its NAV at TBTT, based upon when the Beacon_Interval times CFP_Count. This needs to be recalculated with every Beacon received, just in case something changed. So CFP_Period is irrelevant to anyone but the PC.	
		
	7.3.2.5	AS	t	y	There is no indication as to the reference point for CFP_Dur_Remaining.	Original Text:
CFP_Dur_Remaining shall indicate the maximum time, in kmicroseconds, remaining in the present CFP, and is set to zero in CFP Parameter elements of beacons transmitted during the contention period. This value is used by all STAs to update their NAVs during CFPs.
Replacement Text:
CFP_Dur_Remaining shall indicate the maximum time, in kmicroseconds, remaining in the present CFP, and is set to zero in CFP Parameter elements of beacons transmitted during the contention period. The remaining time is referenced to the TBTT immediately prior to this beacon transmission. This value is used by all STAs to update their NAVs during CFPs.		
	7.3.2.5 
A.4.4	db	T	Y	w/o the requested change the Draft is technically incorrect - since approved “standard” language was not used the draft does not corectly convey operational requirements.	CFP_Count shall indicate how many DTIMs (including the current frame) shall appear before the next CFP start.  A CFP_Count of 0 shall indicate that the current DTIM marks the		
	7.3.2.6	jz	E		Please draw a picture, with Element ID =5 shown, to harmonize this with the other 7.3.2 subclauses.			
	7.3.2.6	db	T	Y	Challenge text fileds are not defined.
The refernce is to clause 5, which should prob be clause 8 in D3 - alas neither clause has text to define the field. This appears to have beenlost since D2.	Provide field def for challenge text.		
	7.3.2.7	AS	t	y	Why is the ATIM window size 4 octets.  It seems to me that 2 octets (65 ms) should be more than enough.			
	8.1.1	jz	T	Y	The text (mistakenly) gives the impression that OSA is always allowed, defeating the purpose of having SKA. Add text thus:	Open system authentication is the simplest of the available authentication algorithms. Essentially it is a null authentication algorithm. Anyone who requests authentication with this algorithm becomes authenticated, unless another algorithm is being used.
Open system authentication involves a two step authentication transaction sequence. The first step in the sequence is Identity assertion and request for authentication. The second frame in the sequence is the authentication result. If the STA receiving an Open System Authentication request is using a different algorithm, the result shall be unsuccessul, and the requesting station shall not be authenticated.		
	8.1.2	jz	t		I think “read-only” should be “write-only”. Maybe we should rephrase it thus:	This shared key is contained in a read-only MIB variable, so that it cannot be read via the MAC management path.		
	8.1.2.2	jz	t		Add clarification that a STA should really use some kind of PRNG to cook up a brand new string each time. Add this text after “single static value”.	The minimum number of different challenge text strings a STA shall use for SKA shall be 232.		
	8.1.2.4	jz	e	Y	“open system” should be “shared key” in the Information Items section. I assume this is a typo.			
	8.1.2.4 
A.4.4	db	T	Y	w/o the requested change the Draft is technically incorrect - since approved “standard” language was not used the draft does not corectly convey operational requirements.	what it believes to be the shared WEP key.  It shall then compare the challenge text recovered to that sent in frame 2 of the sequence. If they are the same then the two stations have the same shared key. This		
	8.1.2.4	jz	t	Y	It appears as though you have to go through the sequence even if you aren’t using SKA. Add new paragraph for clarification after “WEP OFF”:	Stations that are not using SKA shall respond to frame 1 of the SKA sequence with an unsuccessful frame 4 of the sequence.		
	8.2.2	db	T	Y	w/o the requested change the Draft is technically incorrect - since approved “standard” language was not used the draft does not corectly convey operational requirements.	Self Synchronizing:
WEP is self-synchronizing for each message. This property is critical for a data-link level encryption algorithm, where "best effort" delivery is assumed and packet loss rates may be high.
Efficient:
The WEP algorithm is efficient and may be implemented in either hardware or software.
		
	8.2.5	jz	t		The sentence “The WEP mechanism is invisible...” is not, in fact, true. Management entities have to twiddle the keys and all of that. I suggest deleting the sentence.			
	8.2.5	WD	E	n	Delete the Top of the figure showing DSAP, SSAP, CONTROL and DATA subfields, sinse 802.11 is transparent to this.			
	8.2.5	mif	e	N	Figure 34 still shows WEP per MSDU, rather than per MPDU	Correct figure 34 to show an MPDU as a possible fragment of an MSDU rather than showing the MSDU expanding by IV and ICV attachment to an LPDU.		
	8.2.5	jz	E	Y	Need a diagram of precisely which bits mean what, replete with bit-numbers.			
	8.3.2	WD	E	n	Replace “Read-only” by “Write-only”, as is indicated by the rest of the text.			
	8.3.2
11.4.4.1.15	WD	e	n	Update Clause 8 reference
And Clause 5.3.2 reference			
	8.3.2 
A.4.4	db	T	Y	w/o the requested change the Draft is technically incorrect - since approved “standard” language was not used the draft does not corectly convey operational requirements.	this section.  All MIB variables that hold WEP keys are externally read-only - the contents shall not be read via MAC management SAPs. See Clause 8 for the formal MIB variable definitions.
		
	8.3.2	db	T	Y	w/o the requested change the Draft is technically incorrect - since approved “standard” language was not used the draft does not corectly convey operational requirements.	The maximum length of aWEP_Key_Mapping shall be implementation dependent and the actual length of the array may be inquired from the read only MIB variable “aWEP_Key_Mapping_Length”.
		
	8.3.2,
7.3.1.4
	mif	t	Y	There is no current way to tell, in advance of attempting to transfer MSDUs, whether a station is using WEP, nor whether that station excludes or allows unencrypted franes to reach its LLC (or DSM in the case of an AP).  Since the management frames by which an STA finds the AP and associates with the BSS are not encrypted even if WEP is mandatory for the subsequent data frames, and MPDUs received with valid format and CRC are ACKed whether decryption is successful or not, as well as for unencrypted frames when excluding unencrypted frames from the DSM, a station which does not use WEP could successfully associate with an AP that requires WEP, and proceed to consume bandwidth on the WM, but never get any MSDUs to their intended destinations.  This is an undesirable situation and an unjustifiable waste of time on the wireless medium, which is easily preventable by allocating two of the reserved capability information bits for this purpose.	Add the following to the definition of capability information field bits, add the explanatory paragraph at an appropriate point later in this sub-clause.
Bit 0:	Infrastructure BSS
Bit 1:	Independent BSS
Bit 2:	CF-Aware
Bit 3:	CF Polling Request
Bit 4:	WEP In Use
Bit 5:	WEP Mandatory
Bits 6 - 15: Reserved
An STA that has aPrivacy_Invoke set to true shall set the WEP In Use subfield to Ô1Õ in Association Request, Association Response, Reassociation Request, Reassociation Response, Beacon and Probe Response Management frames. The WEP In Use subfield shall be set to '0' in all other Management frames that contain the Capability Information field.
An STA that has aExclude_Unencrypted set to true shall set the WEP Mandatory subfield to Ô1Õ in Association Request, Association Response, Reassociation Request, Reassociation Response, Beacon and Probe Response Management frames. The WEP Mandatory subfield shall be set to '0' in all other Management frames that contain the Capability Information field.
Add to 8.3.2:
The values of aPrivacy_Invoke and aExclude_Unencrypted are also used to determine the values to transmit in the WEP In Use and WEP Mandatory subfields of the Capability Information fields in certain Management frames.

Seq. #	Section number	your initials	Cmnt type
E, e, T, t	Part of NO vote	Comment/Rationale	Corrected Text	Disposition/Rebuttal