Results of Ballot on Draft Standard D3.0
Comments on clauses 1 through 6

	1.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.	Defines several physical layer (PHY) signaling techniques and interface functions that shall be controlled by the 802.11 MAC.
		
	2	vz	E		In the references clause, some references aren't quite correct. Here are the correct versions:	ISO/IEC 7498-1:1994, Information technology -- Open Systems Interconnection -- Basic Reference Model: The Basic Model

Delete the reference to IEEE Std 802.2 and use the following:

ISO/IEC 8802-2:1994, Information technology -- Telecommunications and information exchange between systems -- Local and metropolitan area networks -- Specific requirements -- Part 2: Logical link control
		
	2	vz	E		Wrong order of reference documents	Please put the references in alphanumeric order: IEEE Std 802 first, followed by ISO 7498, and then ISO/IEC 8802-2, 8824, 8825, and 10039.
		
	3	vh	E		The style of the definitions are not in style with IEEE requirements 	see doc 96/46
Definitions should be numbered to the second level, should be boldfaced, all lowercased, and followed by a colon. Definitions should not include the term itself. An example is provided below:

3.1 access point (AP): Any entity that ...
3.2 ad hoc network: A network comprised solely...
3.3 access control: The prevention...

	3	ch	E		a search of each of the section file sindicates that the word ‘Masquerade’ is not used anywhere. Its definition should be removed.	remove the definition of Masquerade		
	3	ge	e		ESS Basic Rate Set should be on its own line			
	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.	Basic Service Area (BSA). The conceptual area within which members of a Basic Service Set may communicate.
		
	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.	Channel. An instance of medium use for the purpose of passing protocol data units that may be used simultaneously, in the same volume of space, with other instances of medium use (on other channels) by		
	3 
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.	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. 
		
	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.	Extended Service Area (ESA). The conceptual area within which members of an Extended Service Set may communicate. An Extended Service Area is larger or equal to a Basic Service Area and may involve BSSs in overlapping, disjoint or both configurations.
		
	3 
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.	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.
		
	3
ÒCF-AwareÓ	mif	E	N	There are two features that constitue ÒCF-awarenessÓ both of which should be reflected in the definition of CFÐAware.	CF-Aware. A station able to respond to a CF Poll with a data frame, if such a frame is queuedand able to generate, and interpret piggybacked acknowledgements on frames sent to or from the point coordinator.
		
	3.	jz	e		Need paragraph before def’n of “ESS Basic Rate Set”			
	4	ch	e		acronym used in 7.1 but not listed	CRC = Cyclic Redundancy Check		
	4
ÒPDUÓ	mif	e	N	formatting	delete blank line below ÒPDUÓ entry		
	4.1.3.3	maf	T	Y		specify a tolerance that is allowable for duration field to allow for simple calculation of Duration field in the case of bit stuffing on an FH PHY: -0/+10%		
	4.3.2.5	maf	T	Y	Maximum is confusing, but since there is always the possibility that the AP may decide to cancel remaining CFP time, the substitution of “maximum” with NULL is also misleading, therefore, “scheduled” is the best term to use.	replace the word “maximum” with “scheduled” in the first sentence of the description of the CFP_Dur_Remaining field of the CF Parameter Set Element.		
	4.4	maf	e			some of the special abbreviations used in the table and described beneath don’t quite match each other - fix them to match (e.g. table has bc/mc, description uses BC/Mac)		
	5.1.1.2	ge	e		“Media” should be “Medium” to match the singular “impacts”	The Medium Impacts the Design		
	5.1.1.2	jz	E		It should be in English	The Medium Impacts the Design		
	5.1.1.2	mif	e	N	grammar
(I prefer alternative [1])	Chnge to either [1]:
The Media Impact the Design
or [2]:
The Medium Impacts the Design		
	5.1.1.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.	Because of limitations on  wireless PHY ranges, wireless LANs intended to cover reasonable geographic distances may be built from basic coverage building blocks. 
		
	5.1.1.3 
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.	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		
	5.1.2.	maf	T	Y	If shared key is ever to change, then Shared Key MIB must be writeable by someone. When it states here that Shared Key MIB is read-only, is there an implication that this means read-only for the MAC, but writeable by the system?	Shared Key MIB must be write-able to allow shared-key changes.		
	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.	It is useful to think of the ovals used to depict a BSS as the coverage area within which the member stations of  the BSS may remain in communication. (The concept of area, while not precise, is often good enough.) If a station moves out of it's BSS, it can no longer directly communicate with other		
	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 independent BSS is the most basic type of 802.11 LAN. A minimum 802.11 LAN may consist of only two stations.
		
	5.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 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”.		
	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.	PHY limitations determine the direct station to station distance which may be supported. For some		
	5.2.2.1	db			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. 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 key concept is that the ESS network appears the same to an LLC layer as an independent BSS network. Stations within an ESS may communicate and mobile stations may move from one BSS to another (within the same ESS) transparently to LLC. 
Nothing is assumed by 802.11 about the relative physical locations of the BSSs in Error! Reference source not found.. 
All of the following are possible:
a)	The BSSs may partially overlap. This is commonly used to arrange contiguous coverage within a physical volume.
b)	The BSSs could be physically disjoint. Logically there is no limit to the distance between BSSs.
c)	The BSSs may be physically collocated. This may be done to provide redundancy. 
d)	One (or more) independent BSS, or ESS networks may be physically present in the same space as one (or more) ESS networks. This may arise for a number of reasons. Two of the most common are; an Ad hoc network is operating in a location which also has an ESS network and when physically overlapping   802.11 networks have been set up by different organizations.  
		
	5.2.3	ch	e		dangling participle, sentance immediately preceding Figure 5	Consider Error! Reference source not found., to which BSS do stations 6 and 7 belong?		
	5.2.3	RM	E		This text and figure are not necessary to understand concepts or implement the standard.	Error! Reference source not found.Error! Reference source not found.Error! Reference source not found.Delete Figure 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.	For wireless PHYs, well defined coverage areas simply do not exist. Propagation characteristics are dynamic and unpredictable. Small changes in position or direction may result in drastic differences in		
	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.	Basic Service Area (BSA): The conceptual area within which members of a BSS may communicate.
Extended Service Area (ESA): The conceptual area within which members of an ESS may		
	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.	LAN. A DS may be created from many different technologies including current 802.x wired LANs.		
	5.3 
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.	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		
	5.4.1.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.	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. 
		
	5.4.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.	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".  
		
	5.4.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.	Extended Service Set to a Basic Service Set in an independent Extended Service Set.  This case is supported only in the sense that the Station may move.  Maintenance of upper		
	5.4.2.2	ge	e		section reference near bottom should be 11.1.3	“... see clause 11.1.3 on scanning”.		
	5.4.2.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.	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

	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.	At any given instant, a  STA may be associated with no more than one AP. This ensures that the DS may determine a unique answer to the question "which AP is serving STA X?" Once an association is		
	5.4.2.2,
5.4.2.3	ch	E		last sentance - the associating STA is not necessarily ‘mobile’ by the definition of ‘mobile station’ in the definitions section, it could be portable or stationary. All we know is that it is on the WM.	Association is always initiated by the STA, not the AP.		
	5.4.2.3	BO	T	Y	This is outside the scope of 802.11.  Delete it.			
	5.4.2.4	RM	E		This  contains one or more  anthropromorism	STAs expected  to Disassociate whenever they leave a network. However, the MAC protocol does not depend on STAs invoking the Disassociation service (MAC management is designed to accomodate  loss of an associated station).
		
	5.4.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 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. 
		
	5.4.2.5	BO	T	Y	This is untrue as written.	Attempts to send messages through the DS to a disassociated STA will be unsuccessful.		
	5.4.3	BO	E			Two services are required for 802.11 to provide functionality equivalent to that which is inherent to Wired LANs.		
	5.4.3.1	BO	E			This service is used by all stations to establish their identity to stations with which they wish to communicate.		
	5.4.3.1	BO	E			(This use of authentication is independent of any authentication process that may be used in higher levels of a network stack.)		
 	5.4.3.1	ch	t		STA do not associate with each other, only STA to AP - the sentance as is, is misleading.	If a mutually acceptable level of authentication has not been established between STA and AP, an Association shall not be established		
	5.4.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.	If desired, an 802.11 network may be run without authentication. This  may violate implicit		
	5.4.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 STA may be authenticated with many other STAs (and hence APs) at any given instant. 
		
	5.4.3.1.1	BO	E			Pre-authentication is typically done by a STA while it is already associated with an AP (with which it previously authenticated).		
	5.4.3.1.1	ch	e		dangling participle, 1st sentance, second para.	(with which it previously authenticated)		
	5.4.3.1.1	ch	t		authentication exists seperately from association because one is a SS and the other is a DSS, not for the reason given in the first paragragh. Since STA authenticate with each other, but do not associate with each other, the services must be independent. The reason given there is the reason for the existance of pre-authentication, nothing more.	Because the authentication process could be time consuming (depending on the authentication protocol in use), a STA may pre-authenticate with an AP. 		
	5.4.3.1.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.	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		
	5.4.3.2	BO	E		Add further explanatory text	The Deauthentication Service can be invoked by either authenticated party (mobile STA or AP). Deauthentication is not a request, it is a notification. Deauthentication can not be refused by either party.  If an AP sends a Deauthentication notice to an associated station, the association must also be terminated.		
	5.4.3.2	ch	E		second last sentance - the adeauthenticating STA is not necessarily ‘mobile’ by the definition of ‘mobile station’ in the definitions section, it could be portable or stationary.	(non-AP STA or AP)		
	5.4.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.	The Deauthentication Service is invoked whenever an existing Authentication is to be terminated.		
	5.4.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.	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.  
		
	5.4.3.3	BO	T	Y	This is not required.  All of the necessary keys and other attributes can be initialized such that nothing need ever be sent “in the clear”.			
	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.	In a wired LAN, only those stations physically connected to the wire may hear LAN traffic. With a wireless shared medium, this is not the case. Any 802.11 compliant adapter may hear all like PHY 802.11 traffic that is within range. Thus the connection of a single wireless link (without privacy) to an		
	5.4.3.3 
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 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		
	5.5	ch	t		frames missing from class 1		Management Frames: 
•	Probe Request/Response
•	Beacon
•	Authentication
•	Successful Authentication enables a station to exchange Class 2 frames. Unsuccessful Authentication leaves the Station in State 1.
•	ATIM
		
	5.5	ch	t		frames missing from class 3	c)	Control frames: 
•	CF-END+ACK
•	PS-Poll
•	CF-End
		
	5.5	mif	e	N	misc. editorial fixes	Data frames: 
•	Data 
Directed data frames only (FC control bits "To DS” and “From DS" both false).
also:
remove Òc)Ó preceding control frames in next-to-last paragraph of section
also:
fix indentation under ÒReassociation Request/ResponseÓ , ÒDisassociationÓ and ÒDeauthenticationÓ		
	5.5
7.3.1.7
7.3.1.9

	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.		
	5.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.	As noted previously some services shall be completed successfully before others may be invoked.		
	5.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.	•	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.
		
	5.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.	•	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.
		
	5.5	WD	T	Y	There is a problem with authentication in an IBSS.
Authentication is a bottleneck in an IBSS, sinse it requires stations to maintain Authentication State variables for all stations that are communicated with.
There are further no provisions that allows stations to signal to each other that a Authentication state mismatch exists between two stations. The result is that one side is not ready to cimmunicate, while the other side is sending messages that are acknowledged by the receiving station, but not forwarded. There is no means specified by the standard to notify the other station that a mismatch exists.
It is further felt that the authentication function is not needed in an IBSS. If WEP is used there is an implicit authentication, because all stations do have the same secret key, in order for them to communicate.
It is therefore suggested to delete the requirement for authentication in an IBSS.	Add the following to the bottom of the Class 1  frames list:
- Data Frames 
Direct Data Frames only (“To  DS” and “From DS” bits oth false)

Add “ATIM” to the class 1 Management Frame list.

	
	5.5	mif	t	Y	Just as receipt of a class 3 frame from a non-associated station causes a disassociation notification (see last paragraph of section), the receipt of a class 2 frame from a non-authenticated station should cause a DeAuthentication notification.  This is also consistent with Figure 8.	Add just above ÒClass 3 frames ...Ó
If STA A receives a class 2 frame from STA B which is not authenticated with STA A, STA A shall send a DeAuthentication frame to STA B.
Modify last paragraph of section:
If STA A receives a class 3 frame from STA B which is not associated with STA A, STA A shall send a Disassociation frame to STA B. If STA A receives a class 2 frame from STA B which is not authenticated with STA A, STA A shall send a DeAuthentication frame to STA B.
		
	5.6	ge	t		The second paragraph should be eliminated, as it makes no sense.	Eliminate “The independent BSS LAN is a logical subset of an ESS LAN.”		
	5.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.	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		
	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.	Only the minimum two stations are shown in Error! Reference source not found.. An IBSS may have an arbitrary number of members.  In an IBSS, only class 1 and class 2 frames are allowed since there is no DS in an IBSS.
		
	5.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.	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. 
		
	5.7.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.	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		
	5.7.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.	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.
		
	6	msu	t	Y	The current draft specifies that the 1 Mbps modulation shall be 2GFSK with BT = 0.5.  The current level of -60 dBc for N >= M+/-3 is not achievable using a filtering method that addresses size and implementation restraints and takes into consideration production variations.	Change the formulas to read:

Channel
N = M +/-2             -20 dBm or -40 dBc, whichever is the lowest power

N = M +/- 3,4,5      -30 dBm or -50 dBc,
whichever is the lowest power

N >= M +/- 6          -40 dBm or -60 dBc,
whichever is the lowest power		
	6	msu	T	Y	The current draft does not specify an algorithm for switching between available rates.  An algorithm is required to accommodate the large number of users who require a combination of speed and range.	Delete the following sentence:
“The algorithm for selecting this rate is implementation dependent and is beyond the scope of this standard.”

	6.1.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.	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		
	6.1.2	ch	e		grammer	support for time bounded services is also optional		
	6.1.2	mif	e	N	grammar	change ÒareÓ to ÒisÓ in last sentence		
	6.1.2	WD	T	n	This section specifies that TBS are implemented as connection based data transfers. All mechanisms to establish a connection and maintain it are however deleted from the standard.
The only thing that 802.11 can specify is that PCF implementations can provide provisions for reduced transfer delay variations that are benificial for TBS traffic.	Change the text to read as follows:
Time-Bounded services can be implemented within the Point Coordination Function (PCF). Implementations can make use of the ability of a PCF to minimise transfer delay variations, as is benificial for Time-Bounded services.
Time-Bounded services are optional, and therefore the PCF is optional.		
	6.1.2	BO	T	Y	Time-bounded services and “connections” are leftovers, delete.			
	6.1.2	jz	t	Y	There is no such thing as Time-Bounded Services. Delete this section.			
	6.1.3	mif	e	N	formatting	indentation appears to be incorrect on last paragraph of this section.		
	6.1.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.	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.
		
	6.1.4	mif	t	Y	The statement in D3.0 is incorrect.  Under certain circumstances, the MAC is required to reorder MSDUs, for particular, beneficial intent.  Most of the existing cases are to support power management.  If time-bounded services are ever re-introduced, they may also require MSDU reordering.
The most that can be said about Ònot intentionally reoderingÓ is that the MAC does not intentionally reorder MSDUs other than as may be appropriate to improve the deliverability of the MSDUs based on thepower managemnet mode of the station.	The services provided by the MAC Sublayer permit, and may, in certain cases require, the reordering of MSDUs. The MAC does not intentionally reorder MSDUs, except as may be necessary to improve the likelihood of successful delivery based on the current operational {or Òpower managmentÓ} mode of the designated recipient station(s). In addition, since MSDUs can transit a DS, and a DS might reorder MSDUs, it is not possible for the MAC to guarantee MSDU ordering, even when no reordering is performed by the MAC entities themselves.
		
	6.2.1	ge	e		paragraph 3 has extraneous words “of the” - delete them	“.. an individual MAC sublayer address.”		
	6.2.1.1	ch	e		extra words need deleting	The source_address parameter  (SA) shall specify an individual MAC sublayer address.		
	6.2.1.1	ch	t		must be changed to remain consistant with subclause 6.2.1.3	The service_class  parameter specifies the service_class  desired for the data unit transfer. 802.11 allows the following values: asynchronous, or asynchronous_with_encapsulated_information.		
	6.2.1.1	WD	e	n	Correct end of first sentence below the MA-UNITDATA request specification.		
	
	6.2.1.1	mif	e	N	misc. typos	in paragraph beginning ÒThe priority parameter...Ó there is no space after the period ending the first sentence
in last paragraph there are two periods at the end of the last sentence		
	6.2.1.1	mif	E	N	part of the sentence is missing	The source_address parameter  (SA) shall specify an individual MAC sublayer address. of the MAC sublayer entity to which the MSDU is being transferred.
		
	6.2.1.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.	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.
		
	6.2.1.2	ch	e		spelling	The routing_information parameter specifies the route desired for the data transfer. 802.11 shall always set this field to null.		
	6.2.1.2	ch	E		sentances copied from previous sectin without having their sense changed from request to indication, plus a couple of typos	The priority parameter specifies the priority at which the data unit was received : contention or contention free.
The service_class parameter specifies the service_class at which  the data unit was received.		
	6.2.1.2	ge	e		paragraph 8 (on priority parameter) should read “contention or contention free”	contention or contention free		
	6.2.1.2	mif	E	N	presentation inconsistent with the same items in section 6.2.1.1 and with the contents of the ÒWhen GeneratedÓ paragraph of  this section	The routing_information parameter specifies the route desired for the data transfer. 802.11 shall always set this field to null.  
The data parameter specifies the MAC service data unit as received by the local MAC entity.   
The reception_status parameter indicates the success or failure of the incoming frame. 802.11 shall always set this field to successful.
The priority parameter specifies the priority used for the data unit transfer. 802.11 allows this parameter to have two values: contention or contention-free.
The service_class parameter specifies the service_class used for the data unit transfer. 802.11 allows one value: asynchronous.
		
	6.2.1.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.	The source_address parameter shall be an individual address as specified by the SA field of the incoming frame.  
		
	6.2.1.3	mif	E	N	consistency with 6.2.1.1 and 6.2.1.2	The transmission_statusparameter shall be used to pass status information back to the local requesting LLC sublayer entity. 
802.11 specifies the following values for transmission_status:  
a)	successful,
b)	undeliverable (for unacknowledged directed MSDUs when the aRetry_Max is reached),
c)	excessive_data_length,
d)	non_null_source_routing,
e)	unsupported_priority (for priorities other than contention or contention_free),
f)	unsupported_service_class (for service classes other than asynchronous),
g)	unavailable_priority (for contention_free when no point coordinator is available, in which case the MSDU is transmitted with a provided_priority of contention),

The provided_priority parameter specifies the priority that was used for the associated data unit transfer (contention or contention_free).  
The provided_service_class  parameter specifies the class of service used for the associated data unit transfer (asynchronous).
		
	6.2.1.3	BO	T	Y	These outdated bits must be deleted.	802.11 specifies the following values for transmission_status:  
a)	successful,
b)	undeliverable (for unacknowledged directed MSDUs when the aRetry_Max is reached),
c)	excessive_data_length,
d)	non_null_source_routing,
e)	unsupported_priority (for priorities other than contention or contention_free),
f)	unsupported_service_class (for service classes other than asynchronous),
g)	unavailable_priority (for contention_free when no point coordinator is available, in which case the MSDU is transmitted with a provided_priority of contention),
h)	unavailable_service_class (for service class other than asynchrounous).
		
	6.2.5	maf	t	Y		allow backoff values greater than those specified		
	6.2.5.2	maf	t	Y		This section does not mention that backoff is also used when a collision is interrepted to have occurred. Clause 6.2.5.3 alludes to collisions, so perhaps a reference to clause 6.2.5.3. would suffice.		
	6.2.5.2	maf	T	Y	If a TX is queued just a bit time after the end of a successful TX, then the newly queued transmission will follow the first one WITHOUT A BACKOFF HAVING BEEN EXECUTED!	In the 5th paragraph, strike the words: “and has another MSDU ready to transmit (queued)”
Add text:
A backoff should be performed immediately after the end of every transmission, even if the transmission was successful, and even if no additional transmissions are currently queued. If the transmission was successful, the CW value reverts to CWmin before the random backoff iterval is chosen. This assures that TX frames are always separated by a backoff.		
	6.2.5.3	maf	t	Y	Just being a stickler for details, I guess.	No reference is made to CRC error being interpreted as a collision. I.e. clause mentions “CTS may not be returned.” Returned with CRC error is “returned” in my book. Let’s be explicit and include a mention of CRC error as another reason for backing off.		
	6.2.6.3	maf	T	Y	The slop in various carrier detection mechanisms will cause a problem unless the CTS_TIMEout (and ACK_timeout) are either increased, or are specifically called out to be interpreted as frame reception must have STARTED by the timeout expiration.	CTS_Timeout - value should include enough time to allow for slop in my start of timer vs actual possible end of reception of CTS frame, otherwise, if the last bit of CRC32 is even one bit time late, then the timer will beat the frame, and I’ll pretend that I never heard it and go into backoff and waste bandwidth
Add text to indicate exactly how to interpret CTS_Timeout - if a CTS frame type is detected before the end of the timeout, but the entire frame, including a CRC has not yet been detected, then do I cancel the timeout, or this CTS reception doomed to failure, because there is no hope that the last bit CRC will make it to the receiver before the timeout, because the transmission started just one teensy itsy bit time too late?		
	6.2.6.3	maf	T	Y		ACK_Timeout - see previous comment on CTS_Timeout		
	6.2.7.	maf	t	Y		Broadcast/multicast are almost guaranteed to be NOT delivered, since the time following a beacon is likely to be flooded with asynch upbound traffic (in the absence of a CF period). A possible solution to make broadcast go from almost guaranteed failed delivery (assuming a few STA with traffic to send) to “pretty good” delivery is to require the use of the PIFS to send broadcast/multicast (i.e. force an “unannounced” CF period after every beacon that has broadcast/multicast to be sent) - this would make PIFS capability a requirement of APs.
An alternative is that a portion of the PCF could be required - i.e. AP would set a PCF period, and would use it for multicast traffic. If there was no multicast, then it would send CF-end. Note that this CF period may be used for actual CF traffic, but with the restriction that multicast traffic must be transmitted first. Broadcast/multicast are now only lost by adjacent interfering BSS’s, other ISM devices and noise sources.
Another option is to turn off all other TIM bits when SID=0 is set. This prevents most  PS-POLL traffic from interfering with the multicasts, but does not prevent asynchronous up-traffic from interfering.
Another option is for the AP to choose at random, the address of an associated STA and send the RTS for a multicast frame to that STA. The DATA frame would then contain the multicast address and would be received by all appropriate STA - no ACK would be sent, but at least the NAVs of STA would prevent the majority of collisions. Alternatively, an ACK could be generated by the lucky STA that was randomly selected - although this doesn’t really prove that all STA got the frame.		
	6.4	maf	T	Y		allow reception of a minimum of 3 MSDUs instead of 6		
	6.4	maf	T	Y	Last paragraph implies that multiple MSDUs may be oustanding in Transmission. This means multiple MACs residing in a single antenna.
The word “each” implies that there could be more than one MSDU outstanding. How is it possible that a STA is allowed to have multiple MSDUs outstanding? How do I intersperse the transmission attempts for each MSDU? Do I have spearate backoff functions for each MSDU that is pending? This would be tantamount to having multiple MACs residing within a single antenna - I would end up with one MSDU being transmitted during the backoff of another, which would be very unfair. This is just wrong.	Last paragraph should be replaced with the following text (note that the only actual change to this paragraph is changing the word “each” to the word “the”):

The source station shall maintain a Transmit MSDU Timer  for the MSDU being transmitted. The attribute aMax_Transmit_MSDU_Lifetime specifies the maximum amount of time allowed to transmit a MSDU. The timer starts on the attempt to transmit the first fragment of the MSDU. If the timer exceeds aMax_Transmit_MSDU_Lifetime then all remaining fragments are discarded by the source station and no attempt is made to complete transmission of the MSDU.		
	6.5	maf	t	Y	This is an implementation issue and should not be specified here.	Strike the sentence: All stations shall support the simultaneous reception of a minimum of 6 MSDU’s.		
	6.5	maf	T	Y	Text as written implies that STA must maintain as many timers as there are incoming MSDU’s, and this could be a very large number in the worst case, and if the worst case happens, then everyone is non-compliant.
Also, the text does not currently state what a STA shall do with a new MSDU when it runs out of timer hardware to monitor yet another simultaneous reception.	second from last paragraph, add text after the first sentence, as shown: “The destination station will maintain a aReceive_MSDU_Timer attribute for each MSDU being received, for a minimum of 3 MSDUs. The STA may implement additional timers to be able to receive additional simultaneous MSDUs. The receiving station shall discard all fragments that are part of an MSDU for which a timer is not maintained.”		
	6.7	maf	T	Y	The MAC state machines provide a mechanism for creating a concise, logical, self-consistent description of the standard.
Textual descriptions elsewhere in the document are so spread out that it is difficult to maintain consistency across all descriptions of a partcular subfunction - e.g. NAV operation is not fully described anywhere, but instead, bits and pieces are spread around multiple locations.
Information as to which frame responses use SIFS, or DIFS, or PIFS is spread around.
802.3 is cited as a precedent in establishing state machine pseudo-code as the golden mean for possible inconsistency in the standard.	The MAC state machine diagrams with the accompanying text should be the golden standard for this specification and not the textual descriptions of functionality as found in the sections outside of section 6.7. The following text should be added:

The state machine representations and the accompanying text that describes the state machines is the correct embodiement of the standard; Where inconsistencies between other text in the document and the state machine diagrams or their accompanying text arise, then the state machines shall be considered the correct emodiement.		

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