Results of Ballot on Draft Standard D3.0
General comments, comments on first clauses and on Annexes

	?	maf	t	Y		Need an explicit statement that CF-POLL and other CF frame types shall not be used outside of the CF-period.		
	0	RM	T	Y	At least  one   company has  indicated that it   holds specific patent claims for which licensing will be necessary to implement the standard.  The revised  IEEE patent policy detailed in document 96/14 requires that there be Compelling Technical Justification to include a patented feature. The  required analysis to determine technical justification has not been performed for the patent claims indicated in document 96/5 the patents generally cited in 96/5a.

Furthermore,  the commitee has an obligation to make a reasonable effort to determine what additional patents may be applicable to the draft standard, and make conscious decisions  when to  include patented technology or  employ public domain,  i.e., royalty free, alternatives. Otherwise we may burden the standard with commercially unacceptable royalties or limit the international acceptance  of this  standard.

It appears that the  intent, if not the letter, of the revised patent policy was correctly considered in the process used to include the WEP algorithm  in the standard (a licensable trade secret rather than a patent). This same model must be used for other relevant intellectual property as well.
			
	A.1	db	E	Y	missing paren	a) 	By the user, or potential user, of the implementation, as a basis for initially checking the possibility of interworking with another implementation (note that, while interworking can never be guaranteed, failure to interwork can often be predicted from incompatible PICS proformas).
		
	A.2.1	db	E	Y	missing reference = A.xxxxx	Correct or remove reference.		
	A.3.1	db	T	Y	The sentence was incorrect.
Clause A.4.4 is the MAC and must always be present.
Only only PHY is required, and also only one PHY may be present in a single instance of an implemenetation. The MAC does not handle multiple PHYs simultaniously within a single implementation instance.	The PICS proforma for a station consists of clauses A.4.1, thru A.4.4 inclusive, and  one of A.4.5, A.4.6, or A.4.7 corresponding to the  PHY implemented.
		
	A.3.4	db	T	Y	The text in this section says “...where “<pred>“ is a predicate as described below,...”, but no def of <pred> is given that I can find. The missing definition must be provided or the annex can not be interpreted correctly.	provide missing information re <pred>		
	A.4	sb	T	n	PCF conformance statement incomplete (section 6.8), wrong numbering and reflects D2.1 protocol.	See paper on reformated, corrected and completed PICS (SAB)		
	A.4.3
A.4.4
A.4.5
A.4.6
A.4.7	db	T	Y	The clause references are all incorrect. They need to be corrected.	Correct all section refs to make annex consitant with the Draft clauses.		
	A.4.3	db	T	Y	This section needs major work - it is simply more incorrect than correct.

Item 2: All implementions are STAs. All APs are STAs (See definition clauses). Therefore this capability is a mandatory requirement not an option. Change it’s status to M.

Item 3: This is dependant on item 1, the PCF is required to reside in an AP, so if impl can’t do AP it can’t do PCF - item is not shown as conditional.

Item 4: this is not an option. No text in the draft makes it an option, all stations must be Cf aware I believe. Make status = M

Item 5: this is propoerly an option, if wep is implemented then I believe shared key auth shall also be implemented, thus this is part of a set, but it is represetned as an independant item.

Item 6: This is not an option - if a STA can be an AP and it supports the frame formats then it supprot WDS from the 802.11 point of view. Note that something more than 802.11 may be required to create a WDS, but that is not relevant to the 802.11 PICs.

Item 7: throw this item away and start over. The correct question is:
    Does the impl support exactly one of the specified PHYs? If so, which one?
	Correct the section to repair at least the errors noted at left.		
	A.4.4
1.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.	Defines several physical layer (PHY) signaling techniques and interface functions that shall be controlled by the 802.11 MAC.
		
	A.4.4
3 
	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.	ESS Basic Rate Set. The set of data transfer rates which all the stations in an ESS shall be capable of using to receive frames from the WM. 
		
	A.4.4
3	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.	Net Allocation Vector (NAV). An indicator, maintained by each station, of time periods when transmission onto the WM shall not be initiated by the station whether or not the Station’s CCA function senses the WM as being busy.
		
	A.4.4
5.1.1.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.	Because of limitations on  wireless PHY ranges, wireless LANs intended to cover reasonable geographic distances may be built from basic coverage building blocks. 
		
	A.4.4
5.2.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.	The association between a STA and a BSS is dynamic (STAs turn on, turn off, come within range and go out of range). To become a member of an infrastructure BSS a station shall become “Associated”.		
	A.4.4
5.3 
	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.	802.11 has chosen to use the IEEE 802 48 bit address space (see clause 4). Thus 802.11 addresses shall be compatible with, and unique within, the address space used by the 802 LAN family. 
The 802.11 choice of address space implies that for many instantiations of the 802.11 architecture, the wired LAN MAC address space and the 802.11 MAC address space may be the same. In those		
	A.4.4
5.4.1.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.	Messages received from an integrated LAN (via a Portal) by the DS for an 802.11 STA shall invoke the Integration Service before the message is distributed by the Distribution Service. 
		
	A.4.4
5.4.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.	required for the Distribution Service to operate is provided by the Association services. Before a data message may be handled by the Distribution service, a STA shall be "Associated".  
		
	A.4.4
5.4.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.	Before a STA is allowed to send a data message via an AP, it shall first become associated with the AP.  The act of becoming associated invokes the Association service which provides the STA to AP

	A.4.4
5.4.2.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 Disassociation Service is invoked whenever an existing Association is to be terminated. Disassociation is a Distribution System Service. 
In an ESS this tells the DS to void existing association information. Attempts to send messages to a disassociated STA shall be unsuccessful.
The Disassociation Service may be invoked by either party to an Association (STA or AP). Disassociation is a notification, not a request. Disassociation cannot be refused by either party to the association. 
APs may need to disassociate STAs to enable the AP to be removed from a network for service or for other reasons. 
		
	A.4.4
5.4.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.	use), the Authentication service may be invoked independently of the Association service. 
Pre-authentication is typically done by a STA while it is already associated with an AP (which it previously authenticated with). 802.11 does not require that STAs pre-authenticate with APs. However, Authentication shall be required before an Association may be established. 
If the Authentication is left until Reassociation time, this may impact the speed with which a STA may Reassociate between APs, limiting BSS-transition mobility performance. The use of Pre-authentication		
	A.4.4
5.4.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 Deauthentication Service is invoked whenever an existing Authentication is to be terminated.		
	A.4.4
5.4.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 Deauthentication Service may be invoked by either authenticated party (mobile STA or AP). Deauthentication is not a request, it is a notification. Deauthentication shall not be refused by either party.  
		
	A.4.4
5.4.3.3 
	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 default privacy state for all 802.11 Stations is "in the clear". If the Privacy Service is not invoked, all messages shall be sent unencrypted. If this default is not acceptable to one party or the other, Data frames shall not be successfully communicated between the LLC entities.  Unencrypted Data frames		
	A.4.4
5.5 
	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.	As noted previously some services shall be completed successfully before others may be invoked.		
	A.4.4
5.5 
	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.	•	Deauthentication
Deauthentication notification when in state 2 changes the Station’s state from 2 to 1. The Station shall become Authenticated again prior to sending class 2 frames.
		
	A.4.4
5.5 
	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.	•	Disassociation
Disassociation notification changes a Stations state from 3 to 2. This  Station shall become Associated again if it wishes to utilize the DS. 
•	Deauthentication
Deauthentication notification when in state 3 implies Disassociation as well, changing the Station’s state from 3 to 1. The station shall become Authenticated again prior to another Association.
		
	A.4.4
5.6
	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.	An independent BSS consists of STAs which are directly connected. Thus there is (by definition) only be one BSS. Further, since there is no physical DS, there cannot be a Portal, an integrated wired LAN, or		
	A.4.4
5.7
	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.	Each Service is supported by one or more 802.11 messages. This clause specifies the information items which shall be minimally present in the messages to support the service. 
		
	A.4.4
5.7.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.	When a Station wishes to send data to another Station it sends a Data message. In an ESS the message shall be handled by the Distribution Service. In an ad hoc case, the Data message is sent directly. The		
	A.4.4
5.7.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.	Information Items:
IEEE address of the station which is being disassociated. This shall be a broadcast address in the case of an AP disassociating with all Associated Stations.
		
	A.4.4
6.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.	This service provides peer LLC entities with the ability to exchange MAC Service Data Units.  To support this service, the local MAC shall use the underlying PHY-level services to transport an MSDU to a peer MAC entity, where it may be delivered to the peer LLC.  Such asynchronous MSDU transport is performed on a best-effort connectionless basis.  There are no guarantees that the submitted MSDU shall be delivered successfully.  Broadcast and multicast transport is part of the asynchronous data		
	A.4.4
6.1.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.	intentionally reorder MSDUs. However, since MSDUs may transit a DS, and a DS may reorder MSDUs, it is not possible for the MAC to guarantee MSDU ordering.
		
	A.4.4
6.2.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.	When Generated
This primitive is generated by the LLC sublayer entity whenever a MSDU is to be transferred to a peer LLC sublayer entity or entities.
		
	A.4.4
6.2.1.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 source_address parameter shall be an individual address as specified by the SA field of the incoming frame.  
		
	A.4.4
7.1.3.1.7 
	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. 
		
	A.4.4
7.1.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.	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		
	A.4.4
7.1.3.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.
		
	A.4.4
7.2.2.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.	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.
		
	A.4.4
7.3.1.6 
	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		
	A.4.4
7.3.2.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.	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		
	A.4.4
7.3.2.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.	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).
		
	A.4.4
7.3.2.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).
		
	A.4.4
7.3.2.5 
	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		
	A.4.4
8.1.2.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		
	A.4.4
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.	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.
		
	A.4.4
9.1.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.	of the distributed coordination function.  This access method uses a point coordinator, which shall operate at the access point of the BSS, to determine which station currently has the right to transmit.  The		
	A.4.4
9.1.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.	When a frame is received from the LLC with a MSDU size greater than aFragmentation_Threshold, the frame shall be fragmented. The MSDU is divided into MPDUs. Each MPDU is a fragment with a		
	A.4.4
9.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.	frame and the returning ACK frame. All stations within the reception range of either the originating station (which transmits the RTS) or the destination station (which transmits the CTS) shall learn of the medium reservation. Thus a station may be "hidden" from the originating station and still know about the impending use of the medium to transmit a data frame.
		
	A.4.4
9.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 RTS/CTS mechanism shall not be used for broadcast and multicast frames because there are multiple destinations. This mechanism need not be used for every data frame transmission. Because the		
	A.4.4
9.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.	A STA configured not to initiate the RTS/CTS mechanism shall still update its Virtual Carrier Sense mechanism with the duration information contained in an RTS or CTS frame, and shall always respond to an RTS addressed to it with a CTS.
		
	A.4.4
9.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 medium access protocol allows for stations to support different sets of data rates. All STAs shall receive all the Basic Rate Set and transmit at one or more of the Basic Rate Set data rates. To support the proper operation of the RTS/CTS and the Virtual Carrier Sense mechanism, all STAs shall be able to detect the RTS and CTS frames. For this reason the RTS and CTS frames shall be transmitted at one of these mandatory rates.
		
	A.4.4
9.2.3.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.	The SIFS timing shall be achieved when the transmission of the subsequent frame is started at the Tx_SIFS Slot boundary as specified in clause Error! Reference source not found..
		
	A.4.4
9.2.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.	deliver an MPDU. The CW shall remain at a value of aCWmax for the remaining retries.  This		
	A.4.4
9.2.5.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.	A STA in backoff shall monitor the medium for carrier activity during backoff slots. If no carrier		
	A.4.4
9.2.5.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 backoff timer shall not be decrement for that slot; The medium shall be sensed as idle for the duration of a DIFS period before the backoff procedure is allowed to resume. Transmission shall		
	A.4.4
9.2.5.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 effect of this procedure is that when multiple stations are deferring and go into random backoff, then the station selecting the lowest delay through the random function shall win the contention.  The advantage of this approach is that stations that lost contention shall defer again until after the next medium busy event, and will then likely have a shorter backoff delay than new stations entering the		
	A.4.4
9.2.5.3 
	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.	required to transmit the ACK frame plus a SIFS .  Since this pending transmission is a retransmission attempt the CW shall be increased (per the backoff rules).  This process shall continue until the		
	A.4.4
9.2.5.5 
	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.	MSDU have been sent, an acknowledgment is not received, or the station is restricted from  sending any additional fragments due to a dwell time boundary. Should the sending of the fragments be		
	A.4.4
9.2.5.5 
	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.	When the source station releases the channel following its fragment, it shall immediately monitor the		
	A.4.4
9.2.5.5 
	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.	fragment and receive an acknowledgment due to an impending dwell boundary, it shall contend for		
	A.4.4
9.2.5.5 
	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.	If the source station does not receive an acknowledgment frame, it shall attempt to retransmit according to the backoff algorithm. When the time arrives to retransmit the fragment, the source station shall contend for access in the contention window.
		
	A.4.4
9.2.5.5 
	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.	After a station contends for the channel to retransmit a fragment of a MSDU, it shall start with the last fragment that was not acknowledged. The destination station receives the fragments in order (since the source sends them one at a time, in order). It is possible however, that the destination station may receive duplicate fragments. It shall be the responsibility of the receiving station to discard duplicate fragments. This may occur if the destination station sends an acknowledgment and the source does not receive it. The source shall retransmit the same fragment after executing the backoff algorithm and contending for the channel.
A station shall transmit after the SIFS only under the following conditions during a fragment burst: 
		
	A.4.4
9.2.5.5 
	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.	If a multiple fragment MSDU does not require an acknowledgment (for example, a broadcast/multicast packet transmitted by the Access Point), the source station shall transmit all fragments of the MSDU without releasing the channel, as long as there is enough time left in the dwell time. If there is not, the station shall transmit as many fragments as possible and recontend for the channel during the next dwell time. The spacing between fragments of a broadcast/multicast frame shall be equal to the SIFS		
	A.4.4
9.2.5.6 
	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 following is a description of using RTS/CTS for the first fragment of a fragmented MSDU. RTS/CTS may also be used for retransmitted fragments if their size warrants it. The RTS/CTS frames define the		
	A.4.4
9.2.5.6 
	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.	Each frame contains information that defines the duration of the next transmission. The RTS shall update the NAV to indicate busy until the end of ACK 1. The CTS shall also update the NAV to indicate busy until the end of ACK 1. Both Fragment 1 and ACK 1 shall update the NAV to indicate busy until the end of ACK 2. This is done by using the duration field in the DATA and ACK frames. This shall continue until the last Fragment which has a duration of one ACK time plus one SIFS time and its ACK which shall have the duration set to zero. Each Fragment and ACK acts as a virtual RTS and CTS, therefore no RTS/CTS frame needs to be generated even though subsequent fragments are larger the aRTS_Threshold.
In the case where an acknowledgment is not received by the source station, the NAV shall be marked busy for next frame exchange. This is the worst case situation. This is shown in Error! Reference source not found.. If the acknowledgment is not sent by the destination station, stations that may only hear the destination station shall not update their NAV and be free to access the channel. All stations that hear the source shall be free to access the channel after the NAV from Frame 1 has expired.
		
	A.4.4
9.2.7 
	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 MPDU is directed to the AP. The Broadcast/Multicast message shall be distributed into the BSS. The station originating the message shall receive the message as a Broadcast/Multicast message. Therefore all stations shall filter out Broadcast/Multicast messages which contain their address as the source address.
		
	A.4.4
9.2.9 
	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.	sequence number and fragment number) field within Data and Management frames.  MPDUs which are part of the same MSDU shall have the same sequence number, and different MSDUs shall (with a high probability) have a different sequence number.
		
	A.4.4
9.2.9 
	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.	There is the small possibility that a frame may be improperly rejected due to such a match; however, this occurrence would be rare and simply results in a lost frame (similar to an FCS error in Ethernet).
		
	A.4.4
9.2.10 
	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.	and the different MAC Slot Boundaries Tx_SIFS, Tx_PIFS and Tx_DIFS. These Slot Boundaries define when the transmitter shall be turned on by the MAC to meet the different IFS timings on the medium,		
	A.4.4
9.2.10 
	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 tolerances are specified in the MIB, and shall only apply to the SIFS specification, so that tolerances shall not accumulate.
		
	A.4.4
9.3.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.	delay.  In the case of a busy medium due to DCF traffic, the beacon shall be delayed for the time required to complete the current DCF frame exchange. The longest delay occurs when the current frame exchange is an MSDU which is larger than both aRTS_Threshold and aFragment_Threshold.  In		
	A.4.4
9.3.3.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.	A CF-Poll bit in the Subtype field of these frames shall allow the stations to send their data frames if any. Stations shall respond to the CF-Poll immediately when a frame is queued, by sending this frame		
	A.4.4
9.3.3.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.	addressed to a different station than the one being acknowledged.  This shall only occur if the acknowledged frame/fragment was marked as last fragment in the frame control.  CF-Aware stations that		
	A.4.4
9.3.3.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.	A CF-Aware station shall respond to a CF-Poll.  If the station has no frame to send when polled, the response shall be a Null frame.  If the station has no frame to send when polled, but an acknowledgment is		
	A.4.4
9.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.	is invoked for the MPDU.. . If WEP is active for the MPDU, then the MPDU shall be expanded by IV and ICV (see clause Error! Reference source not found.), this may result in a fragment larger than aFragmentation_Threshold.
		
	A.4.4
9.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.	Since the control of the channel is lost at a dwell time boundary and the station shall have to contend for the channel after the dwell boundary, it is required that the acknowledgment of a fragment be		
	A.4.4
9.5 
	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.	MSDU. Only the last or sole fragment of the MSDU shall have this bit set to zero. All other fragments of the MSDU shall have this bit set to one.
		
	A.4.4
9.5 
	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 destination station shall reconstruct the MSDU by combining the fragments in order of Fragment Number portion of the Sequence Control Field. If WEP has been applied to the fragment it shall be		
	A.4.4
9.5 
	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.	not yet complete. As soon as the station receives the fragment with the More Fragments bit set to zero, the station knows that no more fragments may be received for the MSDU. 
		
	A.4.4
9.5 
	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.	To properly reassemble MPDUs into an MSDU, a destination station shall discard any duplicated fragments received. If a station receives a fragment with the same Source, Destination, and Sequence Control Field as a previous fragment, then the station shall discard the duplicate fragment. However an acknowledge shall be sent in response to a duplicate fragment of a directed MSDU.
		
	A.4.4
9.6 
	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 following set of rules shall be followed by all the stations to ensure coexistence and interoperability on Multirate Capable PHYs.
All Control Frames are transmitted at the aBSS_Basic_Rate_Set (which as specified before belongs to the ESS_BASIC_RATE) so they shall be understood by all the stations in the ESS.
		
	A.4.4
10.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.	This shall be used to initialize the management entities, the MIBs and the datapath entities.  It may include a list of parameters for items to be initialized to non-default values.  The .confirm shall indicate success or failure of the request.  
		
	A.4.4
11.1.1.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.	Beacons and Probe Responses carry a TSF time element.  A station receiving such a frame from another station in an IBSS with the same ESS ID shall compare the TSF time with its own TSF time.   If the		
	A.4.4
11.1.2.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.	Beacons shall be scheduled at the nominal beacon interval. This is shown in Error! Reference source not found.  
		
	A.4.4
11.1.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.	The Beacon transmission shall always occur during the Awake Period of stations that are operating in a low power mode. This is described in more detail in  ??.
		
	A.4.4
11.1.5 
	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.	Stations shall use their TSF timer to time the aCurrent_Dwell_Time. The aCurrent_Dwell_Time is the length of time that stations shall stay on each frequency in their hopping sequence. Once stations are synchronized, they have the same TSF timer value.
		
	A.4.4
11.2.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.	(PS) shall transmit a short PS-Poll frame to the AP, which shall respond with the corresponding		
	A.4.4
11.2.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.	Power Save or PS
Station listens to selected Beacons (based upon its aListen_Interval) and sends PS-Poll frames to the AP if the TIM element in the most recent Beacon indicates a directed MSDU buffered for that station.  The AP shall transmit buffered directed MSDUs to a PS station only in response to a PS-Poll from that station, or during the contention free period in the case of a CF-Aware PS station.  In PS Mode, a station shall be in the Doze state and shall enter the Awake state to receive selected Beacons, to received broadcast and multicast transmissions...		
	A.4.4
11.2.1.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 TIM shall identify the stations for which traffic is pending and buffered in the AP.  This		
	A.4.4
11.2.1.5 
	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.	SID of CF-Aware stations.  A CF-Aware station for which the TIM element of the most recent Beacon indicated buffered MSDUs or management frames shall be in the Awake state at least until the receipt of a directed frame from the AP in which the Frame		
	A.4.4
11.2.2.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.	stations are awake. The announcement is done via an Ad Hoc Traffic Indication Message (ATIM). A power conserving station listens for these announcements to determine if its receiver shall be left on.
When a MSDU is to be transmitted to a destination station that is in a Power Save (PS) mode, the transmitting station first transmits an ATIM frame during the ATIM Window, in which all the stations including those operating in a Power Save (PS) mode are awake. The ATIM Window is defined as a specific period of time following a beacon during which only ATIM frames may be transmitted. ATIMs are randomized after the beacon using the backoff procedure. ATIMs are acknowledged. If a station receives an ATIM frame during the ATIM Window, it shall acknowledge the ATIM and stay awake for the entire Beacon Interval waiting for the announced MSDU(s) to be received. If a Station does not receive an ATIM, it may go back to PS Mode after the end of the ATIM Window. MSDUs announced by ATIMs are randomized after the ATIM Window using the backoff procedure. If a station transmitting the ATIM does not receive an acknowledgment, the station shall execute the backoff procedure for retransmission of the ATIM. 
It is possible that an ATIM may be received from more that one station and that a station that receives an ATIM may receive more than a single MSDU from the transmitting station. ATIM frames are only		
	A.4.4
11.2.2.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.	An ATIM shall have a destination address of broadcast/multicast for broadcast/multicast MSDUs. All stations shall remain awake if they receive an ATIM with a broadcast/multicast destination address.
		
	A.4.4
11.4.4.1.20 
	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 attribute defines the maximum time, in kmicroseconds, that a station shall remain on a single channel during a passive scan of that channel.  The default value of this attribute shall be		
	A.4.4
11.4.4.1.27 
	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 attribute defines the period of time, in microseconds, after a target beacon transmission time in an IBSS during which stations buffering frames for Power Save mode stations shall attempt to notify those stations by transmitting an ATIM frame. The ATIM window begins at the		
	A.4.4
11.4.4.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.	"A set of MAC_Addresses identifying the multicast addresses for which this station may receive frames.  The default value of this attribute shall be null."
		
	A.4.4
11.4.4.2.24 
	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 attribute indicates the number of bytes in an MPDU, below which an RTS/CTS handshake shall not be performed.  An RTS/CTS handshake shall be performed for all frames where the length of the MPDU is equal to or larger than this threshold.  Setting this attribute to be larger than the maximum MSDU size shall have the effect of turning off the RTS/CTS handshake for frames transmitted by this station. Setting this attribute to zero shall have the effect of turning on the RTS/CTS handshake for all MPDUs for frames transmitted by this station.  The default value of this		
	A.4.4
11.4.4.2.30 
	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 attribute specifies the length of time, in microseconds, in which an ACK frame may be received in response to transmission of a frame which requires acknowledgment, timed from receipt		
	A.4.4
11.4.4.2.31 
	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 attribute indicates the maximum number of transmission attempts of a frame, the length of which is less than or equal to aFragmentation_Threshold, that shall be made before a failure condition is indicated.  The default value of this attribute shall be 5.";
		
	A.4.4
11.4.4.2.32 
	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 attribute indicates the maximum number of transmission attempts of a frame, the length of which is greater than aFragmentation_Threshold, that shall be made before a failure condition is indicated.  The default value of this attribute shall be 7.";
		
	A.4.4
11.4.4.2.33 
	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 attribute specifies the maximum MSDU length that shall be accepted for transmission.  The value of this attribute shall be 2304 octets.";
		
	A.4.4
11.4.4.2.34 
	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 attribute specifies the current maximum size, in octets, of the MPDU that may be delivered to the PHY.  An MSDU shall be broken into fragments if its size exceeds the value of this attribute after adding MAC headers and trailers.  The default value for this attribute shall be equal to		
	A.4.4
11.4.5.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.	"The Add_Group_Address action shall add the specified group address to the list of group addresses that shall be accepted by the station.";
		
	A.4.4
11.4.5.2.3 
	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 Delete_Group_Address action shall remove the specified group address from the list of group addresses that shall be accepted by the station.";
		
	A.4.4	db	T	Y	The MAC pics section is missing huge pieces, in particular it has no references to any of clauses 5 or 6.	Fill out MAC pics section to include contents of clauses 5 and 6.		
	A4.4
5.1.1.3 
	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.	Another aspect of mobile stations is that they may often be battery powered and hence power management is an important consideration. For example, it cannot be presumed that a station’s receiver		
	A4.4	db	T	Y	The MAC Pics is not consistant with the rest of the draft. Many of my LB comments are the result of cross checking and correcting the use of “must”, “will” etc to “shall” - this means that the pics annex is missing required information.	Correct A.4.4 to include all examples of missing “shall” and “shall not” noted in my other LB comments.
Cross check all clauses for use of “shall” against the pics section - every shall in a draft clause must be reflected in a line of the pics.		
	All	vh	E		The document is not consistent in the unit of the data rate.  Although IEEE still uses the unit Mbps, ISO and the ITU consistently use Mbit/s (and I agree with this unit).  As we want to have the ISO adopt our standard, IEEE agrees with the use of the unit Mbit/s	Use thriughout the document the unit Mbit/s instead of Mbps (clause 14.3.3.1.1). Mb/s (clause 14.7.2) , Mbit/sec (table 40)		
	All	vz	E		Use the x for multiplication rather than an asterisk. See page 250.			
	Annex	vz	E		Please add an informative annex titled "Bibliography" and include all items such as the book by Bruce Schneier mentioned in the footnote on page 62. Also include any other documents mentioned in the text that do not appear in the references clause, such as Document FCC 15.247, ETS 300-328 (from page 217), ANSI C95.1-1991 (from page 202), IEC 825-1 and ANSI Z136.1 on page 252, etc.			
	Annex	vz	E		Tables and figures that appear in annexes use their own numbering scheme, for example, figure B.1, figure B.2, figure C.1, etc.			
	Annex A	vz	E		Add the following footnote to the PICS proforma in annex A:

Copyright release for PICS proformas: Users of this standard may freely reproduce the PICS proforma in this annex so that it can be used for its intended purpose and may further publish the completed PICS.			
	Annex A	mif	t	Y	The MAC PICS Proforma has inadequate coverage of the point coordination function, and certain other aspects of the MAC frame exchange sequences.  This needs to be corrected to reduce the probability of non-interoperable, but allegedly conformat implementations.	A list of items needing coverage will be brought to the March meeting.  In keeping with the Email from Simon Black which acknowledged some of the shortcomings of the D3.0 MAC PICS Proforma, and the statement that he would bring an updated version to the meeting, specific text changes are not included here.  I will be available to participate in the update of the MAC PICS Proforma to improve PCF and frame sequence coverage during the March meeting.		
	Annex C	mif	t	Y	The MAC State Machines are inconsistent with the recent updates to the MAC, and had some errors and omissions at the time of their insertion.  Document 96/002 contains an update that the author believes is consistent with the D3.0 text and takes D2.1 LB comments on the state machines into account to the extent they are still relevant with other changes leading to D3.0.	Replace Annex C with the material from document 96/002.		
	Artwork	vz	E		Attempt to use the same font size in your artwork. The preferred font and size is Helvetica 8 pt. Smaller font sizes may become illegible when copied. For example, figure 66 on page 182 is unacceptable. Also, figure 68 on page 185, and figure 71 on page 188. Figure 74 on page 201 is much too large and bold. Use shading carefully--figure 85 has an illegible block of text due to the shading (see page 232). Figure 90 on page 249 is too large and bold. Font size on figure 92, page 260, is too small.			
	Foreword	RM	e		The list of present and past voting members seems short.  At one time, voting membership exceeded 100?			
	Foreword	BO	T	Y	No credit is given to subgroup chairs.  These folks did a tremendous amount of work and deserve credit.	Add Dave Bagby, Dean Kawaguchi, Larry Van Der Jaqt		
	Foreword	BO	T	Y	If the editors of the individual PHY clauses desrve an “*”, each of the clause editors for the remainder of the document deserve credit.	Add “*” to Tom Baumgartner, Dave Bagby, Carolyn Heide, Simon Black, Tom Siep or remove “*” from Dean Kawaguchi, Ed Geiger, Jim Renfro, Mike Trompower		
	Forword	vh	E		The title of the voters-list does not match, the title explains that old voters were in the list, which was not true, further details of activities is needed	Keep the list as of the time the draft is aproved for submission to Sponsor ballot and announce that in the title.
Start list with current 802.11 chair, MAC group chair and Phy group chair, followed by the names of the two main editors.
Mark in the list with voters, the subgroup chairs and subgroup editors at the time of submission to Sponsor Ballot.		
	General	jyc			There many mistakes and ommissions in this draft as it stands.  Without going through all, but to cite a few examples:-
1.	Simon Black indicated 3 items in the MAC PICs
2.	Naftali Chayat indicated Hop sequence formula errors
3.	Bob Ohara has submitted a number of editorial changes.
			
	General
14.6.13, 14.6.14.5	vh	E		Scrutinize the whole document on units.  In 14.6.13, I found usec in stead of ms and in 14.5.14.5 Khz in stead of kHz			
	General	cr	?	y	See comment on previous ballot	see comment previous ballot		
	General	vh	T	y	The PAR requires:
A minimally conformant IEEE P802.11 network will meet all of the P802 requirements except that 5.6.1 will be met at least 99.9 % of the time on a daily basis, in 99.9 % of the total geography of the service area.
IEEE P802.11 will define approaches to allow a minimally conformant network to achieve full conformance over the total geography of the service area.

I have not found anywhere in the standard a place where the minimally conformant network has been defined.
	1.	A minimally conformant network consist of a set of two stations, separated by 20 m(eter) in an environment that shows a delay spread of (@@ to be defined) and having interference from another station, using the same PHY and the same frequency/sequence, placed 25 m from both stations (this station to transmit with the same power as the other two stations) and an interferer that generates a 1 kHz signal in the middle of the band with an equivalent distance/power density so that the receiving station receives a signal of (@@ to be defined).

2.	To achieve full conformance, an implementation needs to add additional antennas at @@ cm or a dual station implementation with the antennas separated by @@ cm.		
	General	vh	T	y	The Wireless MAC shall support both connectionless service as defined in the MAC Service definition at rates between 1 and 20 Mbit/s as well as a service supporting packetized voice.			
	General
3.x
4.x
5.x
7.x
9.x
11.x
prob
others.

	db	T	Y	In my D1 LB comments I wrote up the history and politics that lead to the current broken multi-rate mechanism. Those comments are hereby included in these D3 letter ballot comments by explicit reference.

In my D2 LB comments I wrote up more of the problems associated with the multi-rate mechanism. I hereby include those comments in these D3 letter ballot comments by explicit reference.

During the January 1996 802.11 meeting it was acknowleedged by the 802.11 plenary session that there are known problems with the multi-rate mechanism: only two people voted in a straw poll that there were no problems (reference official minuites of the mtg), further a motion was placed in front of the group asking them to either correct the problems or remove the deficient mechanism from the draft (motion #1) - the 802.11 group has declined to do either on a vote of 5 approving, 16 opposing, 2 abstaining. 

This is clearly a vote to leave the mecahanism broken.

This is unacceptable, unprofessional behavior in the opinion of this 802.11 voting member. 

Until the group resolves this issue in a manner satisfactory to this reviewer, my vote on forwarding the Draft to sponser ballot shall remain “NO”.  Unless some resolution is reached, I anticipate carrying this issue to both the executive cmtee and to the sponser ballot group (as part of the NO votes that must be presented along with the sponser ballot if the draft is forwarded with any unresolved No votes).	Either correct ALL known and/or acknowledged deficiencies associated with the D3 multirate mechanism or remove the flawed multi-rate “feature” from the draft entirely.		
	Global	vz	E		Do not use boldface for emphasis within the text. Use quotation marks or italics, as necessary, but do not overuse.			
	global	maf	E	Y		CFP-Rate should be changed to CFP-interval		
	global	maf	t	Y	k = x 1000
K = x 1024	all references that use “k” for meaning multiply by 1024 should be changed to “K” (case is VERY important here)		
	title	vz	E		On the title page and on the header that appears on each page, header is incorrect	Put the full title, "IEEE P802.11, Draft Standard for Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specification"		

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