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

Seq. #	Section number	your initials	Cmnt type
E, e, T, t	Part of NO vote	Comment/Rationale	Corrected Text	Disposition/Rebuttal	
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.	Defines several physical layer (PHY) signaling techniques and interface functions that shall be controlled by the 802.11 MAC.
	Adopted - pelenary motion 8	
2.		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
	corrected	
3.		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.
	corrected	
4.		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...

	referred to editors	
5.		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	corrected	
6.		3	ge	e		ESS Basic Rate Set should be on its own line		corrected	
7.		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.
	adopted - plenary motion 8	
8.		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	adopted - plenary motion 8	
9.		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. 
	adopted - plenary motion 8	
10.		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.
	adopted - plenary motion 8	
11.		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.
	adopted - plenary motion 8	
12.		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.
	adopted.	
13.		3.	jz	e		Need paragraph before def’n of “ESS Basic Rate Set”		corrected	
14.		4	ch	e		acronym used in 7.1 but not listed	CRC = Cyclic Redundancy Check	added	
15.		4
ÒPDUÓ	mif	e	N	formatting	delete blank line below ÒPDUÓ entry	corrected	
16.		5.1.1.2	ge	e		“Media” should be “Medium” to match the singular “impacts”	The Medium Impacts the Design	english corected	
17.		5.1.1.2	jz	E		It should be in English	The Medium Impacts the Design	english corrected	
18.		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	suggestion 1 adopted	
19.		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. 
	adopted by plenary motion 8	
20.		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	adopted by plenary motion 8	
21.		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	adopted by plenary motion 8	
22.		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.
	adopted by plenary motion 8	
23.		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”.	adopted by plenary motion 8	
24.		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	adopted by plenary motion 8	
25.		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.  
	adopted by plenary motion 8	
26.		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?	corrected	
27.		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	editorial change declined as it was felt that this might result in additonal technical no votes.	
28.		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	adopted by plenary motion 8	
29.		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	adopted by plenary motion 8	
30.		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.	adopted by plenary motion 8	
31.		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	adopted by plenary motion 8	
32.		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. 
	adopted by plenary motion 8	
33.		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".  
	adopted by plenary motion 8	
34.		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	adopted by plenary motion 8	
35.		5.4.2.2	ge	e		section reference near bottom should be 11.1.3	“... see clause 11.1.3 on scanning”.	corrected	
36.		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

	adopted by plenary motion 8	
37.		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	adopted by plenary motion 8	
38.		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.	90% adopted, a mobile station does not in fact have to be in motion - stationary is motion of a low magnitude. The additional clause re “not the AP” was added.	
39.		5.4.2.3	BO	T	Y	This is outside the scope of 802.11.  Delete it.		correction adopted	
40.		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).
	adopted.	
41.		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. 
	adopted by plenary motion 8	
42.		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.	corrected	
43.		5.4.3	BO	E			Two services are required for 802.11 to provide functionality equivalent to that which is inherent to Wired LANs.	corrected	
44.		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.	corrected	
45.		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.)	corrected	
46.		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	language improved	
47.		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	adopted by plenary motion 8	
48.		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. 
	adopted by plenary motion 8	
49.		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).	corrected	
50.		5.4.3.1.1	ch	e		dangling participle, 1st sentance, second para.	(with which it previously authenticated)	corrected	
51.		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. 	language improved	
52.		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	adopted by plenary motion 8	
53.		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.	adopted	
54.		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)	adopted	
55.		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.	corrected	
56.		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.  
	adopted by plenary motion 8	
57.		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”.		The assertion given may be true wrt to Data frames, but for auth frames, the auth transaction sequences are carefully specified as to which frames are in the clear and which are not - this is not controlled by MIB variables as the attrributes only control data frames,not the mgt frames for Authentication. Therefore this change is declined because it is based on an invalid assumption re mgt frames.	
58.		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	adopted by plenary motion 8	
59.		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	adopted by plenary motion 8	
60.		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
	corrected - but, atim is class 2 as auth is required in IBSS so can not be class 1.	
61.		5.5	ch	t		frames missing from class 3	c)	Control frames: 
•	CF-END+ACK
•	PS-Poll
•	CF-End
	corrected	
62.		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Ó	correct4ed	
63.		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.	adopted - see also comment 68
Deauth and dissassoc have been changed to class 1 frames as they can always be recieved.
Language similar to disassoc in class 3 was added to class 2 for deauth.

The reason code  needs to be handled in clause 7 work - to be consistent. don’t move 11 from status to reason, dup 11 in reason list also.	
64.		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.	adopted by plenary motion 8	
65.		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.
	adopted by plenary motion 8	
66.		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.
	adopted by plenary motion 8	
67.		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.
	problem with deauthentication corrected - see resolution to comment 63, 68.
	
68.		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.
	adopted - see also resolution to commnet 63	
69.		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.”	adopted.	
70.		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	adopted by plenary motion 8	
71.		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.
	adopted by plenary motion 8	
72.		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. 
	adopted by plenary motion 8	
73.		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	adopted by plenary motion 8	
74.		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.
	adopted by plenary motion 8	
75.		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	adopted by plenary motion 8	
76.		6.1.2	ch	e		grammer	support for time bounded services is also optional	corrected	
77.		6.1.2	mif	e	N	grammar	change ÒareÓ to ÒisÓ in last sentence	corrected	
78.		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.	moot - section deleted by adoption of folling two comments (79, 80)	
79.		6.1.2	BO	T	Y	Time-bounded services and “connections” are leftovers, delete.		adopted	
80.		6.1.2	jz	t	Y	There is no such thing as Time-Bounded Services. Delete this section.		adopted	
81.		6.1.3	mif	e	N	formatting	indentation appears to be incorrect on last paragraph of this section.	corrected	
82.		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.
	adopted by plenary motion 8	
83.		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.
	adopted as editorial clairification -the requested text does not change operation of D3.	
84.		6.2.1	ge	e		paragraph 3 has extraneous words “of the” - delete them	“.. an individual MAC sublayer address.”	corrected	
85.		6.2.1.1	ch	e		extra words need deleting	The source_address parameter  (SA) shall specify an individual MAC sublayer address.	corrected	
86.		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.	Accepted - clauses made consistent, but wording was removed as it should not have been present in D3.0 due to previous 802.11 decisions.
See comments 96, 97	
87.		6.2.1.1	WD	e	n	Correct end of first sentence below the MA-UNITDATA request specification.		corrected
	
88.		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	corrected	
89.		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.
	corrected	
90.		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.
	adopted by plenary motion 8	
91.		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.	corrected	
92.		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.	Corrected	
93.		6.2.1.2	ge	e		paragraph 8 (on priority parameter) should read “contention or contention free”	contention or contention free	corrected	
94.		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.
	mostly adopted - some text already corrected, alternate wording adopted - author accepts resolution of comment.	
95.		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.  
		
96.		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).
	corrected
This is a editorial catch up to reflect previous 802.11  decisions.	
97.		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).
	corrected
This is a editorial catch up to reflect previous 802.11  decisions.	

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