# Main

Comment:
Type of ReasonCode is octet (should be Enumeration for consistency's sake).

SuggestedRemedy:
Change type of ReasonCode to Enumeration


Comment:
ReasonCode undefined (for corresponding MLME primitives)


Response:
PROPOSED ACCEPT IN PRINCIPLE. Resolved as in 1744


Response:
PROPOSED ACCEPT. Resolved by comment 294.


Comment:
The backward compatibilty or relationship with 802.15.1 devices is not addressed

SuggestedRemedy:
Please address the compatibility/relationship issue clearly.

Response:
PROPOSED ACCEPT. Backwards compatibility is explained in the draft text to be added to the draft found in 00000r0P802-15-3-Annex_Coexistence.pdf. Interoperability is not mandated, and not prohibited.


SuggestedRemedy:
EPSSet (Consistency with previous acros)


Comment:
Coexistence features of 15.3 are not clearly stated, in a single location.

SuggestedRemedy:
I suggest that a subclause be added to Clause 5, explicitly describing how paragraph 6 of the PAR ("A goal of the WPAN-HR Task Group will be to achieve a level of interoperability or coexistence with other 802.15 Task Groups . . . it is also the intent of this project to work toward a level of coexistence with other wireless devices . . .") is satisfied.


Comment:
5 GHz and UWB are assumed to be future spectral bands to be used without any justification or mention given a prior. This is confusing.

SuggestedRemedy:
The 5 GHz and UWB should not be mentioned in this table to avoid confusion.


Comment:
PHYPIB_CCA_Threshold is programmable but not enough guidance as to what values it should assume has been given in the standard.

SuggestedRemedy:
I suggest that CCA threshold values should be defined depending on TX power levels similar to 802.11b standard.


Comment:
Both "m" and "cm" portion of the range have been given an octet. Since the range is less than 10 m, I think the "cm" portion should be given more bits.

SuggestedRemedy:
Allocate more bits for the fraction part of the range.


Comment:
20 (typo, Stream QoS parameters should be 23 octets long, cf. Fig. 77 in page 134)


Comment:
b0-b5, b6-b9 (supported data rates should be 5 bits, not 6 bits)


SuggestedRemedy:
Otherwise the PSAVE bit ... (Consistency with previous row)


Comment:
The power management method is overly complex and vague.

SuggestedRemedy:
Refer to the remedy indicated by Bill Shvodian


Comment:
QoS is very important for the applications intended for this standard, however is very lacking in details. Clause 9 needs to be beefed up in terms of details.

SuggestedRemedy:
Additional work to provide the details needed to support QoS.

Response:
PROPOSED REJECT. Clause 9 has been deleted. SSCS's will be added as a follow on to the draft  to clarify how 802.15.3 capabilities can be used to provide QoS.


Comment:
QoS section is far from complete for implementation.

SuggestedRemedy:
Provide necessary detail to implement the QoS policy


Comment:
The QoS policy is not clearly defined in this section.


Comment:
The security clause lacks encryption detail for the default cipher algorithm.

SuggestedRemedy:
Refer to the remedy indicated by Rick Roberts


Comment:
There is neither security/authentication details nor a cipher suite defined for the sake of interoperability among devices built by different vendors.

SuggestedRemedy:
Please provide the details and the cipher suite clearly.


Comment:
The coexistence mechanisms for the TG3 2.4 GHz are lacking.

Response:
PROPOSED ACCEPT. See 00000r0P802-15-3-Annex_Coexistence.pdf and 02041r2P802-15_TG3-Coexistence-capabilities.ppt. Also see resolution of 1254.


Comment:
Tail symbols are not used for all modulation types

SuggestedRemedy:
Finish the first paragraph by saying "if necessary".


Comment:
Repetition of the PHY and MAC header is not explained in the text. Also it is not clear that 22 Mbps DQPSK modulation applies to the second repetition of the PHY and MAC header in figure 108.


Comment:
The modes CCA detection should be clearly enumerated. It is not clear what constitutes CCA.

SuggestedRemedy:
Use the 802.11b CCA detection template in the standard.

Response:
PROPOSED REJECT.  There is only one CCA mode.


Comment:
The 2.4 GHz coexistence issue is not fully and clearly addresse

SuggestedRemedy:
Please address the coexistence issue/mechanism clearly.

Response:
PROPOSED ACCEPT. See 00000r0P802-15-3-Annex_Coexistence.pdf and 02041r2P802-15_TG3-Coexistence-capabilities.ppt


Comment:
Annex C Specification and Description Language (SDL) was not provided for voter comment and review.

SuggestedRemedy:
Povide Annex C content, SDL for voter comment and review


Comment:
Annex D Protocol Implementation Conformance Statement (PICS) was not provided for voter comment and review.

SuggestedRemedy:
Povide Annex D content, PICS for voter comment and review


Comment:
Missing xref to Dissaociation subclause in Clause 8.


Comment:
DeviceID is incorrect parameter name and its data type is incorrect as well.

SuggestedRemedy:
Please change DeviceID to DeviceAID and change the data type from MAC address to Integer with range 1-255.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Please change DeviceID to DevID and change the data type from MAC address to Integer with range 1-255. Also see comment 571.


SuggestedRemedy:
Please remove ReasonCode as a parameter.


Response:
PROPOSED REJECT.  Recognize that most of the reason codes may be removed, but there are still at least two different reasons required.


Comment:
Missing xref to DISASSOCIATION-REQUEST command frame subclause in clause 7.


Comment:
Missing xref to DISASSOCIATION-REQUEST command sub clause in clause 7.


Response:
PROPOSED ACCEPT IN PRINCIPLE.  Resolution as in comment 565.


SuggestedRemedy:
Please remove ReasonCode as a parameter for this primitive.


Comment:
DeviceID parameter name, data type, Valid range and description fields are incorrect.

SuggestedRemedy:
Please change DeviceID to DeviceAID; data type to: Integer; valid range to: 1-255; description to: " Specifies the DEVAID of the peer device with which the association relationship is terminated.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Please change DeviceID to DevID; data type to: Integer; valid range to: 1-255; description to: " Specifies the DevID of the peer device with which the association relationship is terminated.


Comment:
Clauses 6.3.5.3, 6.3.5.3.1 and 2 along with Table 12 are not needed to satisfy the requirments of the disassociation protocol.

SuggestedRemedy:
Please remove MLME-Disassociate.confirm and its subclauses.

Response:
PROPOSED REJECT. There is a chance that this command may be used in some situations.


Comment:
DeviceID is an unnecessary parameter left over from 802.11.


Comment:
DeviceID is an unnecessary entry in the parameter table.


Comment:
Text describing when the MLME-RESET.request is generated is partially incorrect.

SuggestedRemedy:
Please change the text to: The primitive is sent by the DME to its MLME to reset the MAC to its initial conditions.


Comment:
Text describing the effect reception of the MLME-RESET.request primitive has on the local MAC entity is incomplete.

SuggestedRemedy:
Please change the first sentence in this clause to:  "The DEV MLME, upon receiving this primitive, sends a DISASSOCIATION-REQUEST command frame to the PNC, sets the MAC to its initial conditions and clears all of its internal variables to their default values."


Comment:
Abstract lacks mention that the standard is extensible to include alternate physical layers

SuggestedRemedy:
add after data types. "and is designed to support addtional physical layers as might be specified at a later time."


Comment:
The type of equipment 802.15.3 supports is more than "voice and data".

SuggestedRemedy:
Replace "voice and data" in Absract with "multi-media and data" or just "multimedia".


Comment:
The repeater service implements an overly complex scheme to increase the number of devices that are allowed to communicate in a piconet. This service does not seem to be necessary nor desired for personal operating space devices that can be repositioned to provide communication capability. In addition, the inclusion of the 11Mbps data rate ensures that any DEV that can communicate with the PNC using the default 22Mbps data rate should also be able to communicate with any other devices that can also communicate with the PNC. The ability to communicate between all devices in a piconet with the POS of the PNC can be provided without the complex repeater service.

SuggestedRemedy:
Remove all references to repeater service: 7.2.1.10 Repeater field section on page 96 lines 12-16. Remove repeater field in Figure 12 on page 94. In section 7.2.1, change "...SECurity and repeater." to "...and SECurity." on page 94 line 26. Remove Repeater lines from Tables 61 and 62 on page 99. Remove three repeater service commands from Table 65 on page 110. Change "... SEC and Repeater ..." to "... and SEC ..." in line 50 on page 111. Remove Repeater memory from Figure 37 on page 112. Remove lines 22-23 on page 112 describing repeater memory. Change "...SEC and Repeater ..." to "...SEC ..." in line 42 on page 113. Change "...SEC and Repeater ..." to "...SEC ..." in line 38 on page 114. Change "...SEC and Repeater ..." to "...SEC ..." in lines 1-2 on page 116. Remove all of section 7.5.6, 7.5.6.1, 7.5.6.2, 7.5.6.3, Figure 55 and Figure 56 on pages 122 and 123. Remove first two sentences of the fourth paragraph of section 8.1 on page 137, lines 27-28 describing when repeater service can be used. Remove Repeater Memory line from Table 68 on page 139. Remove "including those additional streams needed to support the repeater service" from lines 2-3 on page 153 in section 8.6. Remove last two sentences in section 8.8.6 on page 159, lines 10-12. Remove all of section 8.11 and Figure 92. Remove section 8.13.3.12 on page 171 lines 20-28.


Comment:
Clause heading do not follow IEEE Standards Sytle Manual.  Only the first word is to be capitalized.


Comment:
Multiple clause headings with the same name.  For example Overview, Scope, Child piconet, and Neighbor piconet.

SuggestedRemedy:
Modify the clause heading with adjectives that are more appropiate or merge the clauses together, if they are the same.


Comment:
Where are the requirements for coexistence with 802.15.1, 802.15.4, and 802.11 a/b?  I have not seen any discussion on solutions for this issue.bb

SuggestedRemedy:
Requirements needed to meet the intent of the PAR.

Response:
PROPOSED ACCEPT IN PRINCIPLE. The requirements are as stated in the 802.15.3 PAR. The proposed informative Annex (00000r0P802-15-3-Annex_Coexistence.pdf) has a description of the coexistence methods that are available in the draft. Also see 02/041r2 for a presentation and additional text on this issue. For 802.15.4 compatibility see subclause 6.9 in 00000D13P802-15-4__Draft_Standard.pdf.


Comment:
The editor comment "ED Note: The standard description of the 802 family of networking protocols will go here." brings up the question how will the 802.15 WG depict the 802 Family as they introduce a 2nd (and 3rd) MAC sublayer to the traditional figure (see 802.15.1/D1.0.1 Figure 1)?  It is important that the WG communicate their Projects and their distinct identities, one solution per problem, etc.  This frontmatter subclause should be short but concise such that the 802.15.xx designations are clear to the public.  The titles are clear now the figure 1 and resultant description of Fig 1 should be modified to communicate our mutiplicity of projects.

SuggestedRemedy:
I suggest that the Editor add the 'standard description' and submit a modified Figure 1 so that the WG can review and comment.  If the Project 802.15.3 Editors need help e.g., Fig1.eps, etc. please advise.


Comment:
The Table of Contents and Bookmark Annex Titles are incorrectly used.  E.g., "(normative)Service Specific Convergence Sub layer." should read "Annex A (normative) Service Specific Convergence Sub layer."

SuggestedRemedy:
The Editor needs to review the PDF creation function while in FrameMaker.


Comment:
The terms "sub-layer" and/or "sub-clause", used throughout 802.15.3//D09, are spelled wrong.

SuggestedRemedy:
Change to "sublayer" and/or "subclause" throughout 802.15.3/D09, dropping the hyphen.


Comment:
The 802.15.3 D09 does not uses uniformity of structure or of style when it comes to lists.  For example subclause 5.1.1. has a dashed list, 6.1 uses a alpabetical listing, and 7.2.8 uses a numeric listing, etc.

SuggestedRemedy:
I suggest the Editor-in-Chief review the IEEE Standards Style Manual and then entire document should be edited for uniformity.  Also, note that a colon is used to introduce a list only when the words "following" or "follows" are used in the introductory sentence, or if the sentence is complete grammatically.  If the introduction is an incomplete sentence, then a colon is not used.


Comment:
Add the current date to the runningheads by the draft number for additional clarity.

SuggestedRemedy:
Please produce D10 with the current date.  Note that this commenter can provide a frontmatter and body template to TG3 that uses the PC System Clock automatically date stampiong the draft when the PDF is produced.


Comment:
It was very hard to determine exactly what text changed from D08 to D09 based on the Editor-in-Chief's usage of the FrameMaker change bar feature inside the draft i.e., Format/Document/Change Bars.

SuggestedRemedy:
When the D10 is produced I require that when all edits are applied and the *.book file is open the FM File/Utilities/Compare Books feature be used to compare the D09 Book to the D10 Book (all the *.fm files should be open too).  The D10 should be released in a clean and compared version; a change bar version can also be released too but again it is hard for this Balloter, and maybe others, to determine exactly what text changes were made. The default for the FM compare utility is that editing marks are shown in color and with a change bar on the left side of the page. The color editing marks are used to indicate delete and insert actions to the draft. The editing marks specifies the location of the change and describes what is being changed either by using red strikethrough (to remove old material) or green underscore (to add new material)." More info: http://ieee802.org/15/pub/SB2/SB2-info.html


Comment:
The the term "IEEE" is reserved for approved standards only.

SuggestedRemedy:
Remove "IEEE" from the designation "IEEE Draft P802.15.3/D09" in the runningheads.


Comment:
Are the use of shall/should/may/can/will/must throughout the document in accordance with IEEE's style?

SuggestedRemedy:
Review the use of shall/should/may/can/will/must throughout the document to be sure they are used in accordance with IEEE's style.


Comment:
R_ALFVIN-NOTE: THIS COMMENT WAS SUBMITTED INCOMPLETE/BLANK AS SHOWN. 
R_ALFVIN-NOTE: THE COMMENT TYPE WAS NOT SELECTED BY THE SUBMITTER.

SuggestedRemedy:
R_ALFVIN-NOTE: NO REMEDY WAS SUBMITTED WITH THIS COMMENT.


Comment:
The use of term "contention access period": There is already a term "contention period" for the same concept that is well known in 802-wireless community term.

SuggestedRemedy:
Replace all occurrences of "contention access period" with "contention period"


Comment:
use of "what" and "how many" in colloquial sense

SuggestedRemedy:
this draft has about 6 use of "what" and a couple of "how many" used in colloquial sense. Please change those sentences appropriately. an example is line 16, page 151.


Comment:
The text between lines 36 and 41 is an incorrect description  of the PNC information broadcasting function.


Comment:
It is not clear that <= 1 second connect time is achievable (especially with existing security clauses).

SuggestedRemedy:
Clarify in Clause 5 all connection time issues.  Review impact of security to see if connect time is attainable.


Comment:
Many points in the MAC sections refer to 2.4 GHz.  These would need to be changed if another PHY is implemented


Comment:
What language is this in?  "The current beacon number when that primitive is received by the SME is used to calculate the beacon number for the next EPSTime event and inserts that beacon number as EPSNext when building the EPS action request command."

SuggestedRemedy:
First of all, the referred to primitive, MLME-POWERMANGEMENT.request, is sent by the SME, it is not received by the SME. Next, Please translate  this to English.  It is unreadable.

Response:
PROPOSED ACCEPT IN PRINCIPLE.  Separate all of the MLME's for power management using the new compromise proposal with the reduced number of commands.


Comment:
"Only the DEV that is receiving a unicast stream addressed to it shall send a delayed-ACK command." This should specify that the stream must be on with ACK Policy of Delayed ACK.

SuggestedRemedy:
Change sentence to: "Only the DEV that is receiving a unicast stream addressed to it swith ACK Policy set to delayed ACK shall send a delayed-ACK command."


Comment:
The standard does not address the issue of wireless coexistence sufficiently.

SuggestedRemedy:
A clause on coexistence needs to be added to the 802.15.3 standard.  The clause should include, at a minimum, the following sub-clauses: 1. A sub-clause listing which wireless 802 networks are approved for operation in the same location as an 802.15.3 WPAN, and which are not approved for operation in the same location as an 802.15.3 WPAN. 2. A sub-clause quantifying the performance of an 802.15.3 WPAN that a user can expect, in the presence of the various approved wireless 802 networks. 3. A sub-clause quantifying the performance of the various approved wireless 802 networks that a user can expect, in the presence of an 802.15.3 network.


Comment:
The terms piconet and WPAN both seem to mean the same thing.  The term piconet is not defined in clause 3 and wireless personal area network is also not defined, so it is difficult to be sure if this is the case.

SuggestedRemedy:
If the two terms mean the same thing then use only one throughout the standard.  I would recommend WPAN since it is the one most often used within the IEEE.  Drop the term piconet with the standard and use only WPAN.

Response:
PROPOSED ACCEPT IN PRINCIPLE. The committee has decided to use piconet in the 802.15.3 draft since it was also commonly used in the 802.15.1 draft as well. WPAN use will be limited or eliminated as much as possible.

Definition of piconet: A collection of one or more logically associated devices that share a single identifier with a common coordinator.


Comment:
48 bit and 8 bit address names are confusing and inconsistent.  AD-AD sounds like something that kids take Ritalin for.  Address is usually reserved in 802 standards for 48 bit MAC address.

SuggestedRemedy:
Change AD-AD to AID - Association ID. Use "MAC Address" or "Address" for 48 bit 802 address.   Get rid of DEVAddress, AssociDEVAddress, DevID Use AID for all 8 bit addresses - Source AID, Destination AID, etc. Also, SA8, and DA8 would be the AIDs, and SA48 or DA48 would be the 48 bit MAC addresses.   Make this change throughout the doc

Response:
PROPOSED ACCEPT IN PRINCIPLE.  Use resolution as found in comments 565 and 571.


Comment:
Source Addreess and Destination Address order is inconsistent.  6.8.1 MAC_DATA.request( DA, SA ) 7.2 Header: [... DA, SA ] 7.4.10 CTA [ SA, DA ]

SuggestedRemedy:
Always use Destination Address followed by Source Address Change CTA to Destination Address followed by Source Address


Comment:
Half the time we use "an MLME..."  and half the time we use "a MLME..."  Should be "an MLME."  This comment applies to ALL acronyms in the draft.

SuggestedRemedy:
Change to "an MLME."  Also, change all other uses of "an" and "a" before acronyms to follow the rules based on the first sound, not whether the first letter is a vowel or a consonant.  From  http://webster.commnet.edu/grammar/abbreviations.htm   Using articles with abbreviations and acronyms:         One of the most often asked questions about grammar         has to do with the choice of articles — a, an, the —         to precede an abbreviation or acronym. Do we say an         FBI agent or a FBI agent? Although "F" is obviously         a consonant and we would precede any word that         begins with "F" with "a," we precede FBI with "an"         because the first sound we make when we say FBI is         not an "f-sound," it is an "eff-sound." Thus we say         we're going to a PTO meeting where an NCO will         address us. We say we saw a UFO because, although         the abbreviation begins with a 'U," we pronounce the         "U" as if it were spelled "yoo." Whether we say a         URL or an URL depends on whether we pronounce it         as "earl" or as "u*r*l."


Comment:
We agreed to change Kus to ms throughout the document.  Looks like only half of the instances got update.  Half still have Kus.


Comment:
Slots have both fixed start time and duration

SuggestedRemedy:
Change to "During the CFP, the PNC controls the channel access by assigning time slots to individual DEVs with each time slot having a fixed start time and duration."


Comment:
"The method for choosing the random integer should be unique for each DEV and use the random number generator resident on the DEV."  What does this mean?  We need to choose a unique random number generator for each DEEV?  Or do we just need to choose an unique seed.

SuggestedRemedy:
Specify that a uniqueue seed is required, not a unique random number algorithm.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Replace "The method for choosing the random integer should be unique for each DEV and use the random number generator resident on the DEV." with
"The random number generated for a DEV should be statistically uncorrelated with random numbers generated by other DEVs."


Comment:
"group addressed frame" should be changed globally to "broadcast or multicast frame" since we never define group addressed frame.

SuggestedRemedy:
Do a global change from "group addressed frame" to "broadcast or multicast frame"


Comment:
I have concentrated on tech issues in clauses 6, 7, 8, and 11, plus general "typo patrol" throughout the document.


Comment:
"TM" is not needed in "WPAN(TM)s" as the first use in the title.


Comment:
No mechanism to deal with the possible overlap of two or more piconets on the same physical channel. This would cause self interference among WPAN devices.  Following scenario should be considered: 1. Two piconet initially established on the same channel when they are far away from each other. 2. How will devices detect presence of other piconet if piconets come within proximity of each other. 3. If it's possible to detect another piconet, there are several options: a. One piconet switches to another channel if available. b. Two piconets merge and become one c. Both piconet want to keep operating independently, however device in one piconet is able to communncate with device in another piconet

SuggestedRemedy:
MAC clauses add functions for piconets becoming overlap, considering piconets will be moving

Response:
PROPOSED ACCEPT IN PRINCIPLE.
Reference Document 02/041r2 for proposed approach.


Comment:
The Scope section of the Draft should reflect essentially the same wording as the Scope section of the PAR.

SuggestedRemedy:
Change the Scope section of the Draft to reflect the wording of the Scope section of the PAR.


SuggestedRemedy:
Change "for a low complexity" to for low complexity"


Comment:
The list of example devices do not include some of the key devices targeted for 802.15.3 applications: TVs, imaging kiosks, and set top boxes.

SuggestedRemedy:
Add the following in place of "and printers" "printers, kiosks, set top boxes, TVs and other stationary items that mobile devices may wish to use."


Comment:
The term interoperability is defined, yet it is not the one defined in IEEE 100, nor is this definition include in clause 3 (definitions). Clause 1.1 is not an appropriate place to define terms.

SuggestedRemedy:
Remove this statement from the document.


Comment:
The term coexistence is defined, yet is is not listed in clause 3. Clause 1.1 is not an appropriate place to define terms, nor is this an appropiate document to define the term coexistence.


Comment:
The scope does not match the one listed in the PAR

SuggestedRemedy:
Match the scope text with the text of the original PAR


Comment:
The Purpose does not match the purpose in the PAR

SuggestedRemedy:
Replace the current purpose with the text from the original PAR


Comment:
"Devices included in the definition are those that are carried, worn or located near the body."  This description is not consistent with the definition on page 7, which states that objects within 10 m of device or person.

SuggestedRemedy:
This current description would exclude stationary objects that are not located on a person, such as a projector.  Make this definition the same as the previous definition.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Replace text with the wording from the definition 3.39.


Comment:
The Editor used the wrong FrameMaker Template i.e., framemaker6_frontmatter.fm vs. framemaker6_body.fm therefore causing the running title to be omitted.

SuggestedRemedy:
Please use the framemaker6_body.fm template and force the running title to be used.


Comment:
I recommend not using "&" in the standard.


Comment:
The 802.15.1 D09 uses words inconsistently e.g., here "10 meters" and subclause 3.39, page 7, line 4 "10 m", etc.  Also, TX, transmit or transmitter, (RX receive or receiver too) are used inconsistently too.

SuggestedRemedy:
The later is found in Clause 4 but I suggest the Editor-in-Chief use words consistently.  Also, the find and replace feature in FrameMaker makes it easy to do and more importantly it will be easier for the reader in the end.


Comment:
The Scope sub-clause is required to be essentially the wording that is found in the PAR.  The wording in this clause was carried over from 802.15.1 and never updated.

SuggestedRemedy:
Change the wording to be essentially the same as what is found in the PAR.


Comment:
In this text, co-existance is a stated goal of 802.15.3.  However, further text can not be found to guide designers in anyway.

SuggestedRemedy:
Co-existance has, in recent years, moved from a nice to have item to a must have item.  Co-existance is even more important in unlicensed bands, as consumer electronics manufacturers have learned through the years, any defect in performance (for what ever reason) will result in a returned product.  A returned product is worse than 'no sale' becuase there are cost involved plus a negative product image established in the consumer's mind.

Response:
PROPOSED ACCEPT IN PRINCIPLE. See 00000r0P802-15-3-Annex_Coexistence.pdf and 02041r2P802-15_TG3-Coexistence-capabilities.ppt


Comment:
Missing the word "as" at the end of line 10


Comment:
POS has bad connotations and should be avoided.

SuggestedRemedy:
Find an new acronym.  Maybe Personal Access Space (PAS) Do a global change.


Comment:
The ASN.1 references are not relevant to this standard.

SuggestedRemedy:
Delete the references beginning with ISO/IEC 8824-1:1995(E) on line 16 through ISO/IEC 8825-2:1996(E) on line 37.  Also delete ITU-T Recommendation Z.105 on page 4, line 1.


Comment:
since active is used in power managment, there should be additional text to mention this connection.

SuggestedRemedy:
after "an enhanced power save" device joints the piconet.


Comment:
It might be a bit confusing using the term "alternate coordinator." Although it is perhaps technically an AC, we should avoid confusion on naming

SuggestedRemedy:
change from "alternate" to "child piconet"


Comment:
use of the term units is not consistent with terminology for the standard


Comment:
the term "alternate coordinator" might be confusing

SuggestedRemedy:
change "alternate" to "neighbor piconet"


Comment:
the wording that mentions "excluding the beacon" should be changed as noted below since in reduced power save, most elements (beacon, CAP, MTS) shall be listened to.

SuggestedRemedy:
change "excluding the beacon" to "when contention free period slots are not allocated to the device"


Comment:
an eps dev will only look past the beacon on a wake superframe if there is indication in the beacon that it transmit or receive operations are to be performed.

SuggestedRemedy:
also be available for sending or receiving operations "based on beacon information."

Response:
PROPOSED ACCEPT IN PRINCIPLE. Change "and also" to be "and based on beacon information also"


Comment:
"other services" - this description does not provide any information about how the piconet coordinator is different from other devices in the piconet.

SuggestedRemedy:
Need to provide categories of services that are provided by the coordinator.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Change the word services to "services, e.g. quality of service, synchronization, association, "


Comment:
"in a wireless personal area network" - does this definition of quality of service strictness apply to all WPAN systems or just 802.15.3.

SuggestedRemedy:
Clarify that this is true for only .15.3 systems


Comment:
The definition sentence does not end in a period: additional information through the creation of a public-key certificate


Comment:
The definition sentence does not end in a period: in order to provide data integrity and source authentication


Comment:
The definition sentence does not end in a period: is known only by the participating entities


Comment:
The definition sentence does not end in a period: 3.29 key transport: a process by which an entity sends a key to another entity


Comment:
The definition sentence does not end in a period: 3.36 mutual entity authentication: a process by which two entities authenticate each other


Comment:
The definition sentence does not end in a period: decryption or key establishment procedures depending on the type of key pair


Comment:
The definition sentence does not end in a period: given seed that has the statistical properties of a random sequence of bits when the seed is not known


Comment:
The definition sentence does not end in a period: encryption or key establishment procedures depending on the type of key pair


Comment:
The definition sentence does not end in a period: 3.45 public-key pair: a related pair of data elements including a public key and a private key


Comment:
The definition sentence does not end in a period: the integrity of the data being associated


Comment:
The definition sentence does not end in a period: 3.49 random number generator: a device that provides a sequence of bits that is unpredictable


Comment:
The definition sentence does not end in a period: and key distribution


Comment:
The definition sentence does not end in a period: been modified and that the owner of the private key signed the data


Comment:
The definition sentence does not end in a period: and the source of the signer


Comment:
The definition sentence does not end in a period: 3.55 source authentication: authentication of the sender of the data


Comment:
The definition sentence does not end in a period: tion/decryption and/or integrity protection/integrity verification depending on its intended use


Comment:
The acronym "MLME MAC layer management entity" uses incorrect definition.  The Medium Access Control refers to a sublayer of the Data Link Layer and is not a layer.

SuggestedRemedy:
I suggest the term "sublayer" be used or "MLME MAC sublayer management entity".


Comment:
The sentence "For the purposes of this standard, the following terms and definitions apply. IEEE 100, The Authoritative Dictionary of Standards Terms should be referenced for terms not defined in this clause." needs to be italicized.

SuggestedRemedy:
I suggest you apply italics as indicated: "For the purposes of this standard, the following terms and definitions apply. <italicize>IEEE 100, The Authoritative Dictionary of Standards Terms should be referenced for terms</italicize> not defined in this clause."


Comment:
Not clear when referening mto a radio transmitter.

SuggestedRemedy:
Change the word 'level' to consumption'.  Change from 'reduces its power level for part' to 'reduces its power consumption for part'.


Comment:
unclear sentence structure ... not sure what is the correct definition

SuggestedRemedy:
have power management sub-group rewrite this sentence


SuggestedRemedy:
add definition for device-ID: Specifies the MAC address of the DEV under consideration.

Response:
PROPOSED ACCEPT. Device ID: The MAC address of a device in an 802.15.3 piconet.


Comment:
definition for enhanced power save seems incomplete.  Does differentiate EPS from RPS.

SuggestedRemedy:
have power management sub-group clarify the definition.


SuggestedRemedy:
remove all text in the definition except the following:  the nominal time value for the inter-wake periods for enhanced power save devices.


SuggestedRemedy:
Remove sentence that starts with "A single enhanced ..."


Comment:
"device" should not be used in the definition of "device"

SuggestedRemedy:
change definition to "Any entity that..."


Comment:
Q in Quality of sevvice is capitalized, but not S


Comment:
Didn't we change random number generator to pseudorandom number generator?

SuggestedRemedy:
change random number generator to pseudorandom number generator


Comment:
reduced power save - sounds like it saves less power

SuggestedRemedy:
eliminate all references to rps because it is normal operation and not a special mode


Comment:
The first version of SDL was issued in 1976.  Anything 25 years old should not be called modern.

SuggestedRemedy:
Remove "modern" from the definition of SDL


SuggestedRemedy:
I suggest making it AD-ADDR to indicate more clearly that this is a type of address.


Comment:
Del-ACK - 802.11e had used DlyAck for this term.  To allow new readers to easily determine functionality similarities between different standards, like terms should be the same.


Comment:
Imm-ACK - to provide a short term try using ImAck.  This would make it consistent with my suggestion in comment 7 (DlyAck).


Comment:
PCS - common term used in the wireless telecom arena.


Comment:
RPS - too similar to revolutions per sec.


Comment:
The "ACTIVE CTA" entry is to long (10char) for the standard tab setting for the acronym list clause entry.

SuggestedRemedy:
Change tab setting so that "ACTIVE CTA" become the new tab (plus some spaces for readability of "active mode channel time allocation") setting for the clause.


Comment:
The term "sub-layer", used in CPS common part sub-layer, is spelled wrong.

SuggestedRemedy:
Change to "sublayer", dropping the hyphen.


Comment:
The term "sub-layer", used in PCS packet convergence sub-layer, is spelled wrong.


Comment:
The term "sub-layer", used in SSCS service specific convergence sub-layer, is spelled wrong.


Comment:
Remove 'EPS CTA', because 'EPS' and 'CTA' are already there. Otherwise you need to include also other combinations like 'EPS CTR' that can be found in the document.


Comment:
There are acroynyms for both FER and PER.  I do not see a distiction between a frame and a packet, so FER and PER seem to be the same.

SuggestedRemedy:
Use either the term Frame or the term Packet.  Then drop the other term throughout the standard. Also, drop either FER or PER from this clause.

Response:
PROPOSED ACCEPT IN PRINCIPLE.  Delete PER from acronyms, and change occurrence of PER in 11.6.1 to FER and at all other locaitons in the draft.


Comment:
Why do we have RNG specified?  Should be PRNG.


Comment:
Figure 1 starting on line 38 includes MTS1 and MTS2 elements but the text does not reflect this

SuggestedRemedy:
add after CAP - "or an alternate management time slot (MTS) method"


SuggestedRemedy:
omit the second instance of "using" on this line. Perhaps drop "either" as well.


Comment:
multiple comments 1. suggest changing "private" GTS to better convey the idea. 2. need to add "for the child" in line 43 3. missing word in sentence.

SuggestedRemedy:
1. change "private" to "reserved" 2. after acknowledgments, insert "for the child"  3. at beginning of line 47, add "to"


Comment:
1. use reserved or another term rather than private 2. add clarification as to what assoc, auth, sec and acks are related to

SuggestedRemedy:
1. change "private" to "reserved" 2. after acknowledgments, insert "for the neighbor"

Response:
PROPOSED ACCEPT IN PRINCIPLE. Change "private GTS" to "time slot". Accept second part as written.


Comment:
There is no mention of MTS at this level and at least a brief mention should be present in the overview of operation.

SuggestedRemedy:
add 5.4.3 MTS operation The stanard provides an alternative to CAP through the use of management time slots (MTS). Management time slots are located within the CFP.


Comment:
It is noted that WPAN and piconet may be used with the same meaning in clause 5. Should we consistent with one or the other? Suggested is piconet although no strong preference except that piconet seems to be general term thoughout the document.

SuggestedRemedy:
change multiple instances of "WPAN" to "piconet"


Comment:
power management status is not part of join. power management is negotiated between peers so is not part of join between DEV and PNC. The text is in error. We could replace this with the ability of a DEV to support power management.

SuggestedRemedy:
change the text to "its ability to support power management " and remove "it power management status (whether it needs to power management or not"


Comment:
a covering comment should be located at the first instance of CAP to cover MTS operation

SuggestedRemedy:
Don't know exactly where but add "Throughout this clause, when CAP is referenced, the capabilities that CAP would provide may be alternatively provided by Management Time slots (MTS)


Comment:
I thought that we dropped the "data window." If we did, we should change the text in this subclause.


Comment:
PNC management does not include security nor extended power save.

SuggestedRemedy:
Change "quality of service (Q0S)" to "quality of service (QoS), security, and power save"


Comment:
The data transport does not explicitly support multiple quality of service levels with optional priority. There is an SSCS that could be used to map prioritized QoS service traffic to specific GTS allocations, but this is not done in the MAC.

SuggestedRemedy:
Remove sentence on line 23. If desired to include a statement about QoS, include as an additional bullet the following: A proceedure to allocate bandwidth and fixed time slots to support establishment of data streams that can guarantee repetitive allocation of bandwidth required for isochronous connections.


Comment:
The use of the CAP and the CFP are optional based on how the PNC allocated time in the superframe. In section 8.4.3.3, page 151, line 4-5 it is noted that "the PNC is responsible for choosing the CAP size if a CAP is used." In section 7.4.2, page 102, line 47-48 states: "The CFP duration is the time allocated to the CFP ... has a range of [0-524280] uS." This makes use of the CAP and the CFP optional as defined by the PNC.

SuggestedRemedy:
Change the two lines to: - Connection Access Period (CAP) when allocated. - Connection Free Period (CFP) when allocated.  followed by: The superframe will always have a Beacon and at least one CAP or CFP, and may have a Beacon, CAP, and CFP in that order.


Comment:
DEVs are not required to authenticate with any other DEV with which communication is required. Instead, once a DEV is authenticated with the PNC, it belongs to the authenticated devices in the piconet and may utilized the resources of the piconet to allocated time slots and communicate with other DEVs in the piconet.

SuggestedRemedy:
Change "... with the PNC and then with any other DEV with which communication is required." to "... with the PNC."


SuggestedRemedy:
Change "is sent using either by" to "is sent either by".


Comment:
The PNC does not allocate 'bandwidth'. It does allocate time slots in which a pair of DEVs can use any of the supported bit rates in order to obtain an effective throughput rate from the available raw bandwidth and the amount of error recovery required by the effective BER of the channel.

SuggestedRemedy:
Replace this section with: "Asyncrhonous or synchronous data streams are established for use in the CFP by the allocation of GTSs. The PNC manages allocation of GTSs based on the DEVs requirements and the DEVs then use the GTSs as needed. These streams are established by a connection process."


SuggestedRemedy:
Change "... removed removing power ..." to "... removed by removing power ..."


Comment:
This paragraph does not add anything to the text.

SuggestedRemedy:
Delete the paragraph or add some content.


Comment:
This paragraph describes a potential implementation.  Unless this point drives a specific requirement to come, it should be excluded.


Comment:
"For technical reasons, ..." - what technical reasons?

SuggestedRemedy:
Please explain what the point being driven in this paragraph.


Comment:
"Propogation effects ..." - The message of this sentence is unclear.


Comment:
Bullets should be in same order as they are listed in the subsections.


Comment:
Why is this sentence not a bullet?  It does not have enough information to stand alone as a paragraph.


Comment:
A WPAN only requires 1 device?  or is the WPAN formed when a complete response if received from another device interested in joining a piconet?

Response:
PROPOSED ACCEPT IN PRINCIPLE. . After "superframe." Add "Thus even if there are no associated DEVs, the PNC beaconing is considered to be a piconet."


Comment:
Are GTS and MTS packets randomly intertwined?  Figure is unclear?  If this level of detail exists in the figure, it should be explained in the section.

SuggestedRemedy:
Clarify figure and explain in the section.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Delete MTS and GTS representations from Figure 1. Add text following "service provision" "This period  includes both MTS and GTS allocaitons."


Comment:
"authenticate with the PNC and then with any other DEV ..." - the listed models only authenticate with the PNC, not with other DEVs.


Comment:
Does this paragraph indicate that the defined method could be over written by a higher level protocol?

Response:
PROPOSED ACCEPT IN PRINCIPLE. Delete that sentence. "Higher level . . . this standard."


SuggestedRemedy:
If this term is going to be used, define it in the acronyms.


Comment:
"streamless asynchronous exchange"  and "asynchronous connection" - how do these terms differ?  It is not obvious at this point in the document.  Also, define what is meant by "small amount of data".  Different people would have a different tolerance for data size.


Comment:
"connection process" - this is not a descriptive discussion.  Is it special?  Are there any key features?


Comment:
How does a device know when to expect to transmit or receive?  Need more intro information to understand this feature.


Comment:
What if none of the remaining devices have the capability to be a PNC?  Does the piconet disappear?

Response:
PROPOSED ACCEPT. Add the sentence: "If the PNC stops sending a beacon for any reason, after a certain period of time,  the piconet ceases to exist."


Comment:
A figure showing how a child piconet relates to the original piconet is needed here.


Comment:
A figure showing how a neighbor piconet relates to the original piconet is needed here.


Comment:
Description here is the same as a child piconet.  It makes it hard to understand why a neighbor piconet is needed and why it is technically beneficial.  If the complexity is to be added to provide this functionality, there should be a strong explanation of it's benefit.

SuggestedRemedy:
More explanation needed here to determine benefit of this functionality.


Comment:
Figure needed to communicate quickly the available operation modes.


Comment:
What is the last statement saying?  The point is not clear.


Comment:
"... stopping a piconet." - based on 5.6.1, this should be ending a piconet.


Comment:
How does 5.4.1 and 5.4.2 relate to this paragraph.


Comment:
The last sentence is awkward.  Is it trying to say that sync streams have different acknowledgement modes?


Comment:
How do the states relate?  Is there a state flow diagram?

Response:
PROPOSED ACCEPT IN PRINCIPLE. State diagrams will be added to the appropriate clauses with a cross reference in clause 5.


Comment:
"... (whether it needs to power management or not) ..."  - the "to" is not needed in sentence.


Comment:
"... a PNC handover could occur." - change the to state "... a PNC handover is possible."


Comment:
"... a new DEVs joins." - add the following:  "... a new DEVs joins with more capability."


Comment:
"via the disassociation command ..." - this mode of operation should be included in section 5.4.


Comment:
Why would the PNC of the former child piconet immediately form a new piconet if it did not choose to continue operation after the parent piconet disappears?  Isn't this the same as removing the parent device ID element and continuing the piconet?

SuggestedRemedy:
Explain why this possible operation?  Explain why it is necessary.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Delete sentence on line 38 "However . . . The new piconet.".


Comment:
The flow of this section needs to be revisited.  It does not read easily.


Comment:
The following sentence does not end in a period: conformant PHY transceivers are known to be unable to receive network frames


Comment:
The following sentence does not end in a period: The WPAN has a dynamic topology


Comment:
The following sentences do not end in a period: — Allow DEVs to form and terminate PANs — Transport data between DEVs — Authenticate DEVs with each other


Comment:
The following sentences do not end in a period: — Beacon — Contention Free Period (CFP). This is composed of data streams, either synchronous or isochronous, with quality of service provisions


Comment:
The term "GTS2" in Figure 1 is inconsistently used.

SuggestedRemedy:
Change the term to "GTS 2" (adding a space) to match GTS 1, GTS N, etc.


Comment:
The following sentences do not end in a period: a) Open - no authentication is required and data is not encrypted by the MAC b) Authentication - DEVs authenticate with the PNC before they have access to the piconet’s resources. Data is not encrypted by the MAC  and why are the Clause 5 lists different i.e., subclause 5.3.1 unordered and 5.3.2 ordered.  Refer to IEEE Standards Style Manual, 12. Homogeneity, pg. 14.

SuggestedRemedy:
Add the period and change the lists to be consistent i.e., all ordered or all unordered.


Comment:
The following sentence does not end in a period: — Power is removed removing power from all the DEVs


Comment:
The word "wireless" in the sentence "Additionally, WPANs have the expected wireless differences as found in the following paragraphs." should be clarified by adding "medium".

SuggestedRemedy:
I suggest the sentence be changed to "Additionally, WPANs have the expected wireless medium differences as found in the following paragraphs."


Comment:
The text that describes the components of the IEEE 802.15.3 WPAN is clear but I was expecting a figure that depicted the components of the WPAN being described.

SuggestedRemedy:
I suggest a figure be created and added that depicts the components of the IEEE 802.15.3 WPAN.


Comment:
The term metropolitan area network (MAN) is used but it is not defined in Clause 4, however, the WAN, LAN, and PAN are.

SuggestedRemedy:
Add "MAN metropolitan area network" to Clause 4.


Comment:
use of "multiple levels" is confusing and for some converning


Comment:
command and Data in CAP is confusing: makes the reader think all the commands are tx first and then the data

SuggestedRemedy:
merge the two blocks in CAP to one with the content "Command/Data"


Comment:
'ssh' is not defined either here or in clause 4.


Comment:
Some of the list of states (association, authentication, stream connection, etc.) are more device actions than WPAN states. Thus 'disassociation' should be included.


Comment:
This refers to a parent piconet ending a subsidary piconet, however it is the parent PNC that can end the subsidary piconet.

SuggestedRemedy:
Change 'parent piconet' to 'parent PNC'.


Comment:
A node needs to be authenticated, then authorized before it can join a network.  The following statement: "If the beacon indicates a piconet of interest to the DEV, it will attempt to authenticate with the PNC. Upon success, it is considered to be in the WPAN." does not refer to authorization.

SuggestedRemedy:
add verbage or mechanism to include authorization from a higher layer?

Response:
PROPOSED ACCEPT IN PRINCIPLE.  Change "to athenticate with the PNC." to "to associate with the PNC. If authentication is required, the DEV is also required to authenticate with the PNC."

Authentication process implicitly includes authorization in our draft.


Comment:
Don't understand what the text is trying to say  "The PHY is unprotected from outside signals."

Response:
PROPOSED ACCEPT IN PRINCIPLE. Delete the itemization point. "the PHY . . . signals."


SuggestedRemedy:
Contention Free Period (CFP), which is composed of ...


SuggestedRemedy:
add "ssh" to clause 4 ... off-hand I do not know what ssh means.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Sentence was deleted.


SuggestedRemedy:
change to ...  Data is sent using either by a streamless asynchronous exchange, or by ...


Response:
PROPOSED ACCEPT. Change "CAP" to "CAP or MTS".


SuggestedRemedy:
It is possible, for many reasons, that the PNC function will be transferred.


SuggestedRemedy:
5.6 Coexistence with other IEEE802 devices - Overview  PHY subcommittee members need to add "overview" text that indicates how 802.15.3 2.4 GHz PHY is going to coexist with 802.11, 802.11b and 802.15.1 devices.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Document 02/041r2 covers proposed coexistence methods.


Comment:
The complexity of supporting the child and neighboring piconet capability seems high.  There does not seem to be any significant value in either since it does not increase the overall capacity.

SuggestedRemedy:
Eliminate the child and neighboring piconet concept or alternativly include a short statement of the utility of these capabilities.

Response:
PROPOSED ACCEPT.  Add text that identifies possible uses of child and neighbor piconets. Bob Huang to provide by Monday evening.


Comment:
First use of DEV shouls say "device (DEV)"

SuggestedRemedy:
change DEV to device (DEV) Is there some to to automatically check the first use of acronyms?


Comment:
CAP is devided into Command and Data - inconsistent with text

SuggestedRemedy:
Remove reference to command and data from the cap in Figure 1


Comment:
GTS N and MTS N make it look like there are an equal number of MTS and GTSs


Comment:
authenticate "and then with any other DEV with which communication is required" is inconsistent with security clause.

SuggestedRemedy:
Remove reference to authenticating with other DEVs.


Comment:
"asynchronous connection" and "isochronous connection"  should be stream


Comment:
WPAN operation states and DEV operations have been mixed.

SuggestedRemedy:
...WPAN has sevaral states of operation: An 802.15.3 WPAN has several states of operation: establishment, optional coordination function transfer, and stopping a piconet. DEVs have several states of operration: association, authentication, stream connection establishment, data exchange.  These WPAN and DEV states operate around the structure of the superframe.


Comment:
Data in asynchronous streams does not have to be acknowledged.  Broadcast streams are not acknowledged.

SuggestedRemedy:
Change to: Data in asynchronous streams can be acknowledged, and synchronous streams are able to request acknowledgement as well.


Comment:
"whether it needs to power mangement or not" is not proper grammar

SuggestedRemedy:
probably need to drop the "to" or change to "to use"


Comment:
synchronous stream should be asynchronous stream

SuggestedRemedy:
change synchronous to asynchronous.  Actually, do a global search on "synchronous" and either change to asynchronous or isochronous as appropriate.  In 5.3.4 synchronous is used instead of isochronous.  in 5.3.3 synchronous is used instead of isochronous.


Comment:
"during the CAP" should be "during the CAP or MTS"


Comment:
asynch data is only allowed in the CAP if the PNC allows it.

SuggestedRemedy:
add "if allowed by the PNC." to the end of the sentence.


Comment:
"Power is removed removing power from all DEVs" does not make sense

SuggestedRemedy:
Change to "Power is removed from the DEV before the DEV can perform a PNC handover."


SuggestedRemedy:
Add MTS description:  Management Time Slots are a type of GTS that can be used to allow communications between the DEVs and the PNC.  MTS slots can either be assigned or they can be shared slots that are accessed using SLotted Aloha.


Comment:
Should say "Additionally the PNC manages the quality of service (QoS) requirements and authentication requirements of the WPAN."


Comment:
Saying that the data is "encrypted" is not really what one might want.  Entities may want to know that the transmission came from the appropriate person and wasn't tampered with (data integrity) and/or have the data encrypted.  We should allow for these different combinations of integrity and privacy.

SuggestedRemedy:
Change second sentence in paragraph to: "All data sent in the piconet uses payload protection (data integrity and/or data encryption) with the piconet payload protection key(s)."  Comment via Ari Singer.


Comment:
Again, privacy should be payload protection.

SuggestedRemedy:
Change sentence to "If payload protection is enabled for the piconet, then the DEV receives the symmetric piconet payload protection key(s) during authentication."   Comment via Ari Singer.

Response:
PROPOSED ACCEPT. Replacing sentence "If privacy . . . encrypt data." Change "during" to "after" the the suggested remedy.


Comment:
Does this suggest any 802-compliant wireless devices can operate as a 15.3 neighbor piconet and solve co-existing issue?

SuggestedRemedy:
This statement should be removed or clarified.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Other wireless devices could utilize the neighbor piconet capability to allocate time within an existing 802.15.3 piconet so that that wireless device could utilize the allocated time to coexist in the same spectrum as the existing 802.15.3 piconet. The other wireless device would need to use the 802.15.3 commands to associate as a neighbor piconet.

Delete "802-compliant" and also change "for supporting . . . Neighbor" to be "of using this coexistence method".


Comment:
Operation of draft HR WPAN requires presence of a PNC. If a person owns two WPAN devices but neither of them are AC capable, then his/her products will be useful only when someone else's PNC shows up and is generous enough to provide the functions/services.

SuggestedRemedy:
Make basic PNC function (beacon) mandatory so two devices can at least discover each other and exchange capability.

Response:
PROPOSED REJECT. The group feels that certains devices for cost consideration will always required a separate PNC for operation. E.g., remote speaker. Resolve as in comment 37


Comment:
It would seem that the reference model should include something like a convergence layer for QoS.

SuggestedRemedy:
Update the figure to include QoS sublayer if appropriate

Response:
PROPOSED ACCEPT IN PRINCIPLE. Copy Figure A.1 to Figure 2 with any appropriate changes. Make sure suppporting text is adequate.


Comment:
Text mentions that information is available prior to association. In fact, the power management information is a post-assocation process.

SuggestedRemedy:
change "prior to association" to "after association"


Comment:
It is not clear, how a PHY may be returned to the powered state. This primitive is specified for placing the PHY in one of several available power states. It is recommended that the primitive also serve to restore full power. As an alternative, an additional primitive may meet the requirement.

SuggestedRemedy:
in 6.9.4.19 table 57 note that this includes the state for a fully powered PHY in 6.6.10 table 50, make the same note  some text touch up may be desired so it is clear that powering up is also via the same mechanism.

Response:
PROPOSED ACCEPT. Jay Bain to provide exact text updates.


Comment:
the text of both when generated and effect of receipt seems to have been pasted from elsewhere and does not match the power managment of this sub-clause.

SuggestedRemedy:
change the when generated to : This primitive will be issued by the MAC sub-layer to the PHY entity whenever the MAC sub-layer needs to change the power state of the PHY  change the effect of receipt to : The effect of receipt is to transistion the PHY to the desired state if possible, and then generate the PHY-PWRMGT.confirm primitive


SuggestedRemedy:
Replace "format as device" with "format as defined"


Comment:
The MLME-CHALLENGE primitive parameters does not include the ReasonCode parameter

SuggestedRemedy:
Add ReasonCode to Table 14 as an Enumeration, Valid Range of SUCCESS or TIMEOUT, and Description as "The result of the challenge command." Note that success here is defined to be reception of a valid Challenge.confirm frame from the peer DEV and not whether the PublicKeyProof is correct.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Add ReasonCode to Table 14 as an Enumeration, Valid Range of SUCCESS, FAILURE, or TIMEOUT, and Description as "The result of the challenge command." Note that success here is defined to be reception of a valid Challenge.confirm frame from the peer DEV and not whether the PublicKeyProof is correct. Also closes 455.


Comment:
The 802.15.3 MAC does not support any prioritization of MSDUs delivered to it nor does it directly handle parameterized QoS requests. This section seems to be left over from earlier drafts that had an as yet undefined model for QoS that was not accepted.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Move the paragraph to Annex A.3.1


SuggestedRemedy:
Include this term and how it relates in figure 2


Comment:
Is MaxTXDelayVariation the same thing as Jitter?  802.11e has both a jitter and a delay bound.  Which is being specified here?

SuggestedRemedy:
I would like to see both jitter and delay defined.

Response:
ACCEPT IN PRINCIPLE. MaxTXDelayVariation is jitter within the MAC layer. 802.11e is CSMA and 802.15.3 is TDMA in the GTS. This command only deals with TDMA allocation in GTS.


Comment:
Which way is the communication flowing?  DEV1 to DEV2 or vice versa?

SuggestedRemedy:
Make a clear statement to the reader of communication flow.


Comment:
Is Maximum allocation delay the same thing as Jitter?  802.11e has both a jitter and a delay bound.  Which is being specified here?

Response:
ACCEPT IN PRINCIPLE. Maximum Allocation Delay should be Maximum Allocation Delay Variation. It represents the amount of variation in the delay which is jitter. Change as indicated in the draft.


Comment:
"... by the LME ..." - should this be "PLME"?


Comment:
Need to list the PHY PIB groups in this section to make it easier to for the reader to know what to expect in this section.


Comment:
PHYPIB_Type includes definitions for currently undefined PHYs (5 GHz and UWB).  It is good to put a place holder, but do not presume a solution before the SG3a group has a chance to determine future possibilities.

SuggestedRemedy:
Indicate the values are reserved for future PHYs


Comment:
It is indicate that two services classes exist.  This is an introduction paragraph, the classes should be listed.


Comment:
MAC CPS SAP is not shown in Figure 2.  It is hard to understand how it fits in without seeing the relationships pictorially.


Comment:
"A set of parameters" - not very descriptive


Comment:
"PHY has begun the CCA process." - shouldn't this be "ended the CCA process"?  Possible cut and paste oversight.


Comment:
The term "sub-layer", used in the sentence "Both MAC and PHY layers may conceptually include management entities, called the MAC sub-layer...", is spelled wrong.


Comment:
In Figure 6-2 the term "MAC sub-layer" and "PHY sub-layer" are incorrectly used; it should be MAC sublayer and PHY layer, respectively.

SuggestedRemedy:
Change Figure 6-2 to read "MAC sublayer" and "PHY layer".


Comment:
The ordered list starts at "d)" which is incorrect it should be a).

SuggestedRemedy:
Modify the ordered list to span "a)-c)".


Comment:
The term "sub-layer", used in the subclause title "6.1.1 MAC common part sub-layer (MAC CPS)", is spelled wrong.


Comment:
The term "sub-layer", used in the subclause title "...personality of the sub-layer, hence the acronym PIB.", is spelled wrong.


Comment:
The following sentence does not end in a period: The parameters used for these commands are defined in Table 2


Comment:
The following sentence does not end in a period: The parameters for this command are defined in Table 2


Comment:
The following sentence does not end in a semicolon: primitive are as follows


Comment:
The following sentence does not end in a period: primitive parameters are defined in Table 28


Comment:
In Table 41 the terms "UWB and ETSI, FCC, IC, ARIB" are introduced for the first time and are not defined in this clause and/or Clause 4.

SuggestedRemedy:
Please add "UWB ultra-wideband and ETSI European Telecommunications Standards Institute, FCC Federal Communications Commission, IC Industry Canada, ARIB Association of Radio Industries and Businesses" to Clause 4.


Comment:
The following sentences do not end in a period: "device and the intended recipient devices" and "However, it does not maintain ordering among MSDUs belonging to different streams"


Comment:
The term "sub-layer", used in the subclause title "...This sub-clause provides an overview of the PHY services."


Comment:
The following sentence does not end in a period: The effect of receipt of this primitive by the MAC is unspecified


Comment:
The following sentence does not end in a period: — NoError. This value is used to indicate that no error occurred during the receive process in the PHY


Comment:
The parameter CapabilityInformation field is listed in the primitive but is not defined.


Comment:
The assignment of 5 GHz and UWB PHY layers presumes too much.  It is not clear if there will be another PHY layer, if so what format it will be or what it will be called.  If a new PHY layer is added, the new draft can add its definition to the PIB.  It is not required at this time.

SuggestedRemedy:
Delete the assignments for 5 GHz and UWB.


SuggestedRemedy:
In table 55, in the value column for parameter Length, it is stated the max number of octets is determined by PHYPIB_LengthMax.  Should this be PHYPIB_MPDU_LengthMax.  If not, then where is PHYPIB_LengthMax defined?


Comment:
Add text to explain why the TX and RX MAC headers are passed in the TX and RX vectors.

SuggestedRemedy:
Text that can be added to clause 6.9.4  "The MAC headers TxMacHead and RxMacHead are passed in the TX vector and RX vector respectively to facilitate calculation of the HCS as illustrated in Figure 107."


Comment:
In line 6 and also in line 10, the parameter STATE is incorrect.  The parameter name is actually STATUS.  This is needed to be consistent with table 54.

SuggestedRemedy:
Replace STATE with STATUS in two places as discussed above.


Comment:
The second entry in this table is "privacy".  Are we going to call this privacy or security.

SuggestedRemedy:
Remove all reference to "privacy and private" and replace with "security or secure".  (The other way around is ok to, but we need to be consistent.)


Comment:
"may" does not belong in "Both MAC and PHY may conceptually"


Comment:
How does MAC-CPS fit in to Figure 2?  Is the MAC-SAP in figure 2 the MAC-CPS SAP or the SSCS SAP?

SuggestedRemedy:
Make clear whether what is called the MAC in Figure 2 is the MAC-CPS, or both the MAC-CPS and the SSCS.  It is not clear how Figure 2 and Figure A.1 are related.


Comment:
"The MAC CPS provides stream-oriented service to the SSCS."  What about non-stream?

SuggestedRemedy:
add "and non-stream-oriented" and modify the paragraph to address non-stream flows.


Comment:
Need to specify which commands are associated with the generation of the MLME-POWERMANAGEMENT .request.

SuggestedRemedy:
Add description of which commands are generated in response to MLME-POWERMANAGEMENT .request.  If there is a one to one mapping of request type and Action type that needs to be spelled out.

Response:
PROPOSED ACCEPT. Jay and WMS will do this while adding new MLME text.


Comment:
I don't see RequestType in 7.5.7.1.  Is this the same as EPS Action request command entries?


Comment:
Poor sentence - to implement the power-saving strategy of an implementation.


Response:
PROPOSED ACCEPT IN PRINCIPLE.  Clarification will be made in 7.5.7.1.


Comment:
Why is EPSTime in ms and not superframes?

SuggestedRemedy:
Change EPS time to superframes.  Only 8 bits needed.

Response:
PROPOSED REJECT. This is just to wake up the dev host. Not required who did it and could be multiple.


Comment:
What does this mean "The operating superframe length adjusts this value."


Comment:
"This element has no meaning if the EPS DEV is not in power management mode."  In WHAT power mangement mode.

SuggestedRemedy:
Please clarify should probably be EPS mode.


Comment:
What happens to repeater treaffic when a handover takes place?  Is it all dropped?

SuggestedRemedy:
All repeater traffic should be dropped and renegotiated whan a PNC handover takes place.


Comment:
What happens if the PNC wants to shut down, but there is no other alternate PNC available.  Does the PNC just go away?

SuggestedRemedy:
Add a PNC shutdown command or IE in the beacon to inform the piconet the at the PNC is shutting down.


Comment:
What happens when two piconets wander withing range of each other?  They will not know that the other PNC is there.

SuggestedRemedy:
Need to have the PNCs do a periodic scann to look for traffic from other piconets including beacons in their channel.


Comment:
The last arrow should say "Neighbor Beacon"  not "Child Beacon"


Comment:
In a neighbor piconet, hwo does the parent decide how much time to allocate to the neighbor?  Does it have to allocat any?

SuggestedRemedy:
Need to figure out a policy for allocation bandwidth to neighbor piconets and how to enforce the rules.


Comment:
Authentication clause should follow association (and probably disassociation).

SuggestedRemedy:
Move authentication claust to after association and disassociation.


Comment:
Association can be sent in an association MTS.

SuggestedRemedy:
Change sentence to "An unassociated DEV initiates the association process by sending an association request command, defined in 7.5.2.1, during the CAP or association MTS of an existing piconet. "


Comment:
Figure 83 shows a SIFS between Association reauest and ACK.  Is this a time that is at least 1 SIFS, Less than 1 SIFS or equal to 1 SIFS /- some delta (like .11 does).  In clause 11, SIFS may actually a range (aTXRXTurnAroundTime = between 10 and 11 us)??? This same comment applies to Figure 84

SuggestedRemedy:
Decided exactly what 1 SIFS means and document it. I think it will be =1 SIFs +/- some delta.


Comment:
"The addresses (AD-ADs)" should be "The allocated addresses (AD-ADs)"

SuggestedRemedy:
Change "The addresses (AD-ADs)" to "The allocated addresses (AD-ADs)"


SuggestedRemedy:
Specifiy that association requests are retried 3 times.

Response:
PROPOSED REJECT. The retransmission policy already indicates that frames may be retried up to aMaxRetransmissionLimit times.


SuggestedRemedy:
Change sentence to say "The superframe is composed of three major parts: the beacon, the optional CAP and the CFP,"


Comment:
Change "CAP is used for non-QoS frames." to "CAP can be used for non-QoS frames as regulated by the PNC."

SuggestedRemedy:
Change "CAP is used for" to "CAP can be used for"


Comment:
I provided 3 pages of text on Guard Times in document 01/439 that I thought we included in the draft. I don't know how it fell through the cracks.  I think it was becasuse we decided to put slot duration back into the CTAs on a Con Call and no one ever updated the text.

SuggestedRemedy:
Add Guard Time Text from 01/439 after I update it to add slot durations back into the channel time request.


Comment:
Figure 84 says AKC at the END of a SIFS, but line 22 says "Both in the CAP and the CFP, a response frame (ACK) transmission over the medium shall start within a SIFS duration after the end of the transmission of the previous frame for which the response is intended."  Which is it?  Does the ACK come before a SIFS or after a SIFS?

SuggestedRemedy:
Need to decide on the exact timing of a SIFS and document it carefully.


Comment:
In claause 11 it says SIFS =aRXTXTurnAourndTime.  Yet, aRXTXTurnAroundTime is a range of between 10 and 11 us.  SIFS is never talked of as being a range in clasue 8.  Should it be?

SuggestedRemedy:
Clarify if SIFS is a range or a single value.


SuggestedRemedy:
change "an RIFS" to "a RIFS" in line 27 and 28


Comment:
The CCA threshold should depend on the transmitter power, which can be changed.


Comment:
The figure does not include the SSCS layer.

SuggestedRemedy:
Replace the figure with the one from A.1 or modify it to include the SSCS layer.


Comment:
Should list all of the SAPs in this enumeration.

SuggestedRemedy:
Add SSCS SAP, MAC SAP and PHY SAP as items a and b (and fix numbering).


Comment:
Add a table with definitions of the parameters for these commands.

SuggestedRemedy:
Add the following defintions:  Name           Type        Valid range                 Description PIBattribute  octet string  Any PIB attribute as       The name of the PIB                             defined in 6.5 and 6.6     attribute  PIBvalue      variable      as defined in 6.5 and 6.6  The PIB value  status        enumeration   SUCCESS, INVALID_PIB_      The result of the                             ATTRIBUTE, READ_ONLY_PIB_  command.                             ATTRIBUTE, WRITE_ONLY_PIB_                             ATTRIBUTE

Response:
PROPOSED ACCEPT. 

Name
Type
Valid range
Description 

PIBattribute
octet string
 Any PIB attribute as  defined in 6.5 and 6.6 
The name of the PIB  attribute 
 
PIBvalue
 variable
as defined in 6.5 and 6.6
The PIB value

status
enumeration
SUCCESS, INVALID_PIB_ ATTRIBUTE, READ_ONLY_PIB_ATTRIBUTE, WRITE_ONLY_PIB_ATTRIBUTE
The result of the command.


Comment:
Change MLME-DEV-INFO to be MLME-PROBE-DEV since that more closely reflects the command name.


Comment:
Power managment commands are relevant only in the context of an associated device.

SuggestedRemedy:
Change "to the DEV prior to association" to be "to the DEV after association"


Comment:
The power managment changes come about as a result of changes in the beacon, not from direct communications with other DEVs.

SuggestedRemedy:
Change "from a specific peer MAC entity" to be "from the PNC"  Also change "result of acommand ... in the piconet." to be "result of a change in the beacon."


Comment:
No such thing as a generic PNID.  This is handled by the OpenScan parameter.


Comment:
The paragraph defines the functional description of the scan process that is already adequately defined in clause 8.  The redundant description is an abomination to the technical editor and will cause woe, wailing and gnashing of the teeth.

SuggestedRemedy:
Delete the sentences "The time spent by ... and aggregated into a PiconetDescriptionSet.

Response:
PROPOSED ACCEPT. Note that multiple paragraphs are being deleted.


Comment:
This command is unecessary.  When an new DEV associates, the PNC sends out the new DEV info table anyway.  A DEV may not even be listening for association response frames since it has already been associated.

SuggestedRemedy:
Delete the entire command.  If not, delete the ReasonCode, since by definition it is set to SUCCESS for this command to be generated.  Also, change the description of AssocDEVAddress to be "The allocated device address of the DEV that has been associated." since the association was successful for this command to have been issued.

Response:
PROPOSED ACCEPT. Delete the command. 6.3.4.5 up to but not including 6.3.4.6 and including table 9.


SuggestedRemedy:
Add the following row to the table:  Reason code     enumeration     SUCCESS, FAIL,    Indicates the result of                                 TIMEOUT           the challenge command


SuggestedRemedy:
Change "with which ... process" to "that is requesting the key"


SuggestedRemedy:
Add acronyms for KEK, DEK, DIK and SEED to the acronym clause.


Comment:
The reason code for request key is missing.

SuggestedRemedy:
Add a row to the end of the table which is:  ReasonCode   Enumeration  SUCCESS, NOT_AUTHORIZED,  Indicates the result of                           TIME_OUT                  the key request command


SuggestedRemedy:
Change "which which ... process" to "to which the key will be sent"


Comment:
The ReasonCode for distribute key is not defined.

SuggestedRemedy:
Add the following to the end of table 16:  ReasonCode   Enumeration  SUCCESS, TIME_OUT   Indicates the result of the                                               distribute key command.


Comment:
The MLME-DISTRIBUTE-KEY.response command does not exist.

SuggestedRemedy:
Delete the sentence "The DME shall ... command."


Comment:
The DeviceID parameter description is inaccurate.

SuggestedRemedy:
Change "de-authentication process" to be "de-authentication process or the MAC entity which is requesting de-authentication"


Comment:
The valid rane of the ReasonCode for de-authenticate is incorrect.


Comment:
The de-authenticate command does not use a reason code.

SuggestedRemedy:
Delete ReasonCode from the semantics of the primitive in two places, page 44, line 49 and page 45, line 39 (in the .indication primitive).


Comment:
The DeviceID of a DEV is set through the PIB commands and should not be set here.

SuggestedRemedy:
Delete the DeviceID primitive parameter from the semantics and table 18.


Comment:
The primitive parameters for MLME-STREAM-CTA.indication are not defined.

SuggestedRemedy:
Copy the definitions from table 25 for StreamIndex and SlotStartTimeSet into a table in 6.3.13.5


Comment:
The definition of the ReasonCode for terminate stream is incorrect.

SuggestedRemedy:
Change the 3 entries as follows:  Type          Valid range         Description Enumeration   SUCCESS, TIMEOUT    Indicates the result of the stream                                         termination command.


Comment:
The RequestorDEVAddress is not defined and the ReasonCode is missing an enumeration.

SuggestedRemedy:
Add the following as the first row:  RequestorDEVAddress  MAC address  Any valid MAC address   The MAC address of the DEV which is requesting the channel status.  Add "TIMEOUT" to the valid range for ReasonCode.


Comment:
DestinationDEVAddress does not match other usage.

SuggestedRemedy:
Change "DestinationDEVAddress" to be "RemoteDEVAddress"


Comment:
ChannelIndex is an invalid parameter for a status report since all DEVs in the piconet use the same channel.

SuggestedRemedy:
Delete ChannelIndex from the semantics of the primitive and delete "on the indicated ChannelIndex" from line 21.


Comment:
The ReasonCode needs "TIMEOUT" added as part of its valid range.


Comment:
The use of the probe request does not require that a DEV be authenticated.

SuggestedRemedy:
Delete the word "authenticated" from line 19, 20, 36 and 37 all on page 66 (i.e. every occurance in 6.3.18.1).


Comment:
The definition of the ReasonCode is incorrect.

SuggestedRemedy:
Change the two entries to be:  Type          Valid range Enumeration  SUCCESS, TIMEOUT


Comment:
The sentence "The ReasonCode ... for failure." does not belong here since it has been put into the table.


Comment:
Multicast is not supported in this standard.

SuggestedRemedy:
Delete the words "and multicast" from three places, line 4 in 6.7.1.1, line 15 in 6.7.1.2 and line 33 in 6.7.3.  Also, change "reorderable multicast service" to be "reorderable broadcast service"

Response:
PROPOSED REJECT. Add a paragraph in clause 8 that defines the scope and intention of multicast in this draft. 8.6.1 is the target clause. WMS to write text.


Comment:
There is only one type of primitive defined in the PHY service specification now.

SuggestedRemedy:
Delete "The primitives associated ...  sub-layer to sub-layer interactions." and connect the following paragraph to the previous one.


Comment:
This sub-clause is redundant and therefore really irritates the technical editor while simultaneously promoting bad habits.

SuggestedRemedy:
Delete sub-clause 6.9.3.1 in its entirety and wipe it from our minds.


Comment:
The definition of the DATA parameter is redundant and annoying.

SuggestedRemedy:
Delete the sentence "The DATA parameters is an octet value." in 6.9.4.1 and 6.9.4.2.


SuggestedRemedy:
Change "contains both the PLCP and PHY" to be "contains the PHY"


Comment:
The criteria given are not applicable to this standard.

SuggestedRemedy:
Change "the period indicated ... has expired." to be "the chnannel has been quiet for an aCCADetectTime period."


Comment:
The AntSelect parameter is already defined and we don't need any more ants at our picnic.

SuggestedRemedy:
Replace the sentence "AntSelect is an ... shall be used." with "The primitive parameter is defined in Table 55"


Comment:
The descriptions of When generated and Effect of receipt are copied from another sub-clause and are incorrect for this one.

SuggestedRemedy:
Change "sub-layer needs to ... of an MPDU." to be "sub-layer wants to change the PHY power management state." in 6.9.4.19.1, line 22  Change "will be to start the ... state machine." to be "will be to enter the indicated power management level." in 6.9.4.19.2, line 26


Comment:
5 GHz and UWB are assumed to be future spectral bands to be used without any justification or mention given apriori. How can a current standard have mention of specifics of future standard


SuggestedRemedy:
CCA threshold values should be defined depending on TX power levels similar to 802.11b standard.


Comment:
The MLME-POWERMGT  primitive in Table 1 is in the wrong location.

SuggestedRemedy:
Move MLME-PowerMgt primitive at the beginning of Table 1 to the position just before the MLME-CREATE-STREAM primitive.


Comment:
The MLME-RESET primitive in Table 1 is in the wrong table location.

SuggestedRemedy:
Please move the MLME-RESET primitive from its current position in Table 1 to the first position in Table 1.


Comment:
The MLME-START primitive is in the wrong table position in Table 1.

SuggestedRemedy:
Please move the MLME-START primitive from its current position in Table 1 to the second position in Table 1 just after MLME-RESET.


Comment:
MLME-Tx-POWER-CHANGE primitive is missing from Table 1.

SuggestedRemedy:
Please add MLME-Tx-POWER-CHANGE primitive to Table 1 just before the MLME-CHANNEL-STATUS primitive in Table 1.


Comment:
The MLME-CREATE-REPEATER primitive is missing from Table 1.

SuggestedRemedy:
Please add MLME-CREATE-REPEATER primitive to Table 1 just after the MLME-CHANNEL-STATUS primitive in Table 1.


Comment:
The MLME-REMOTE-SCAN primitive is missing from Table 1.

SuggestedRemedy:
Please add the MLME-REMOTE-SCAN primitive to Table 1 just after the MLME-CREATE-REPEATER primitive and just before the MLME-CHANGE-CHANNEL primitive in Table 1.


Comment:
The MLME-DEV-INFO primitive is in the wrong location in Table 1.

SuggestedRemedy:
Please move the MLME-DEV-INFO primitive from its current location to just after the MLME-CHANGE-CHANNEL table location.


Comment:
The MLME-PNC-HANDOVER primitive is missing from Table 1.

SuggestedRemedy:
Please add the MLME-PNC-HANDOVER primitive to Table 1 just before the MLME-PROBE-PNC primitive in Table 1.


Comment:
The MLME-NEW-PNC primitive is missing from Table 1.

SuggestedRemedy:
Please add the MLME-NEW-PNC primitive to Table 1 just after the MLME-PROBE-PNC primitive.


SuggestedRemedy:
Please remove the OpenScan parameter from the paramter list for the MLME-SCAN-REQUEST primitive.

Response:
PROPOSED REJECT. Openscan needed since there is no reserved PNID.


SuggestedRemedy:
Please remove the OpenScan parameter from Table 3.


Comment:
The definition for PNID is partially correct.

SuggestedRemedy:
Please change the definition from its current text to: PNID "indicates to the MLME to either search for a specific PNID when the PNID is set to 0x0000 through 0xFFFE, or search for all PNIDs when the PNID is set to 0xFFFF."

Response:
PROPOSED REJECT. Openscan is used rather than a reserved PNID.


Comment:
The last sentence of the ChannelScanDuration description is not needed.

SuggestedRemedy:
Please remove the last sentence of the ChannelScanDuration description.


Comment:
DeviceID is inconsistently used through out the document.

SuggestedRemedy:
Please change DeviceID to DeviceAddress when referring to a parameter of data type address(48bit).  It is a more accurate description of the data type.  The association between DeviceID and MAC address is not intuitively obvious.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Use DEV Address and DEVAddress instead of DeviceID and Device ID as appropriate when referring to a 48-bit MAC address.


Comment:
The Beacon  Period data type is incorrect.

SuggestedRemedy:
Please change the  Beacon Period data type to duration.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Change all time durations to be type duration, change most octets to be integer, byte string to octet string, only in type columns of tables in clause 6.


SuggestedRemedy:
Please change the parameter Channel to ChannelIndex and its data type to integer.


Comment:
The parameter name " Parent Device ID" is inconsistent.

SuggestedRemedy:
Please change the parameter name from Parent Device ID to ParentDevAddress which is more consistent with its data type of MAC address(48bit)


Comment:
The functional description of the MLME-SYNCH.request primitive is incomplete.

SuggestedRemedy:
Please change the first sentence to this:  This primitive is used to initiate a local synchronization with a specific piconet beacon only when the PNID is set to 0xFFFF.


Comment:
DeviceID is inconsistent with its data type.

SuggestedRemedy:
Please change DeviceID to DeviceAddress since its data type is MAC address(48bit)

Response:
PROPOSED ACCEPT IN PRINCIPLE. DEVAddress


Comment:
AssocDevAddress is inconsistent with its data type.

SuggestedRemedy:
Please change AssocDevAddress to DeviceAid which is short for Device Assoiciation ID.  Also change the data type from octet to integer.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Change AssocDevAddress to DevID.

Note: Change AD-AD to DevID as well in draft.


Comment:
AssociationTimeOutPeriod has an incorrect data type.

SuggestedRemedy:
The AssociationTimeOutPeriod data type should be changed from Integer to Duration.


Comment:
No xref to ASSOCIATION-REQUEST command frame type.

SuggestedRemedy:
Please add the required xref to the appropriate subclause in clause 7.0


Comment:
xref to ASSOCIATE-RESPONSE command frame type is missing.

SuggestedRemedy:
Please provide appropriate xref to ASSOCIATE-RESPONSE command frame type in Clause 7.


Comment:
AssocDEVAddress parameter name is incorrect.

SuggestedRemedy:
Please change AssocDEVAddress to DeviceAID

Response:
PROPOSED ACCEPT IN PRINCIPLE. DevID instead of DeviceAID


Comment:
The sentence fragment "...and a directed frame with null payload..."

SuggestedRemedy:
Please change the indicated phrase to: "...and a beacon containing the NewAssociatedDEV Information element..."


Comment:
xref to ASSOCIATION-RESPONSE command frame subclause of clause 7 is missing.


Comment:
AssocDEVAddress is an incorrect parameter name.

SuggestedRemedy:
Please change both instances of AssocDEVAddress to DeviceAID.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Use DevID instead of DeviceAID.


Comment:
The title of clause 6.3.4.5 MLME-ASOCIATION-RESPONSE.indication is incorrect.

SuggestedRemedy:
Please change the indicated clause title to: MLME-NEW-ASSOCIATED-DEV.indication.

Response:
PROPOSED ACCEPT IN PRINCIPLE.  The clause is being deleted so it doesn't matter any longer.


Comment:
Missing Association message sequence chart.

SuggestedRemedy:
Please provide missing message sequence chart.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Al Heberling wil proivde MSC.


Comment:
The last sentence of this clause is unnecessary.

SuggestedRemedy:
Please remove the last sentence from this clause since the MLME-RESET.confirm is unneeded.


Comment:
Text describing the effect this primitive has upon the PNC MLME is missing.

SuggestedRemedy:
Please add this paragraph to this clause:  "The PNC MLME, upon receiving this primitive, behaves the same as the DEV MLME with the exception that it transmits a beacon containing a PICONET-SHUTDOWN information element. "


Comment:
Clauses 6.3.11, 6.3.11.1, 6.3.11.1.1, 6.3.11.1.2 and Table 18 should be where clause 6.3.1 is located on page 23.

SuggestedRemedy:
Please move the requested clauses to the indicated location.


Comment:
Clauses 6.3.12, 6.3.12.1, 6.3.12.1.1, 6.3.12.1.2, 6.3.12.2, 6.3.12.2.1, 6.3.12.2.2 should be moved to where clause 6.3.2 is located so that the MLME-START primitives follow the MLME-RESET primitive at the beginning of MLME-SAP interface section.

SuggestedRemedy:
Please move the indicated clauses.  It makes more sense to have these clauses located near the MLME-SCAN clauses.


Comment:
The PiconetDescriptionSet parameter is missing from the MLME-START.confirm primitive.

SuggestedRemedy:
Please add the PiconetDescriptionSet parameter to the MLME-START.confirm primitive.


Comment:
The MLME-CHANNEL-TIME.request, indication,response and confirm are missing.

SuggestedRemedy:
Please insert clauses 6.xxxx from 01/410r1 into the space just before clause 6.3.13 Stream creation.


Comment:
The Power Management clauses 6.3.1, 6.3.1.1, 6.3.1.1.1, 6.3.1.1.2, 6.3.1.2, 6.3.1.2.1, 6.3.1.2.2 should be moved to the space just after clause 6.3.15.4 Terminate Stream Message  Sequence Chart.

SuggestedRemedy:
Please move the indicated Power Management clauses to the location just after the Terminate Stream Message Sequence Chart.  This new location makes more sense from a functional perspective.


Comment:
The MLME-Tx-POWER-CHANGE.request, indication, and confirm  primitives are missing from Clause 6.3 MLME-SAP interface.

SuggestedRemedy:
Please insert clauses 6.3.1 through 6.3.1.3.2 of 01/410r1 into the D09 just before the Channel Status subclause and just after the Power Management subclauses.


Comment:
The RemoteDEVAddress is an inconsistent parameter name.  Also its data type is incorrect.

SuggestedRemedy:
Please change RemoteDevAddress to RemoteDevAID and its data type to an integer with a range of 0-255

Response:
PROPOSED ACCEPT IN PRINCIPLE. Please change RemoteDevAddress to RemoteDevID and its data type to an integer with a range of 0-255


Comment:
DestinationDEVAddress is an incorrect parameter name.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Please change to RemoteDevID.


Comment:
ChannelIndex is an unnecessary parameter. Since the current Channel-Status command frame is only valid in the current piconet channel.

SuggestedRemedy:
Please remove the ChannelIndex parameter from this primitive.


Comment:
DestinationDEVAddress is the wrong parameter name.

SuggestedRemedy:
Please change from DestinationDEVAddress to RemoteDEVAID.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Please change from DestinationDEVAddress to RemoteDevID.


Comment:
Missing xref to the CHANNEL-STATUS-REQUEST command frame described in Clause 7.


Comment:
the sentence fragment ...on the indicated ChannelIndex... is not needed.

SuggestedRemedy:
Please remove the indicated sentence fragment.


Comment:
The RequestorDEVAddress in an incorrect parameter name.

SuggestedRemedy:
Please change from RequestorDEVAddress to RequestorDEVAID.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Please change from RequestorDEVAddress to RequestorDevID.


Comment:
QueriedDEVIDSet is an incorrect parameter name, data type and valid range.

SuggestedRemedy:
Please change the QueriedDEVIDSet parameter name to QueriedDEVAID; its data type to Integer, and its valid range to 0-255.  Also change the description to: " The QueriedDEVAID when set to an integer value less than 255 will return information from the PNC regarding a CTA for a specific DEV.  It the QueriedDEVAID is set to a broadcast AID value of 255 then the PNC will return CTA information for all the associated DEVs.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Please change the QueriedDEVIDSet parameter name to QueriedDevID; its data type to Integer, and its valid range to 0-255.  Also change the description to: " The QueriedDevID when set to an integer value less than 255 will return information from the PNC regarding a CTA for a specific DEV.  It the QueriedDevID is set to a broadcast ID value of 255 then the PNC will return CTA information for all the associated DEVs.


Comment:
The RequestorDEVAddress parameter name, its data type, valid range and description are incorrrect.

SuggestedRemedy:
Please change the RequestorDEVAddress to RequestorDEVAID, its data type to Integer, its valid range to 0-255 and its description to:"The DEVAID of the DEV that is requesting the information from the PNC.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Please change the RequestorDEVAddress to RequestorDevID, its data type to Integer, its valid range to 0-255 and its description to:"The DevID of the DEV that is requesting the information from the PNC.


Comment:
DEVInfoSet is an incorrect parameter name.

SuggestedRemedy:
Please change the DEVInfoSet parameter name to: PNCInfoSet.


Comment:
The QueriedDEVIDSet parameter name is incorrect

SuggestedRemedy:
Please change the QueriedDEVIDSet parameter name to QueriedDEVAID.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Please change the QueriedDEVIDSet parameter name to QueriedDevID.


Comment:
Missing xref to the PROBE-PNC-REQUEST command previously known as the DEVICE-INFO-REQUEST command.


Comment:
QueriedDEVIDSet parameter name is incorrect.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Please change to: QueriedDevID.


Comment:
RequestorDEVAddress parameter name is incorrect.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Please change to: RequestorDevID.


Comment:
RequestorDEVAddress parameter name is incorrect

Response:
PROPOSED ACCEPT IN PRINCIPLE. Please change to RequestorDevID


Comment:
Missing xref to PROBE-PNC-RESPONSE command frame clause previously known as DEVICE-INFORMATION-RESPONSE clause in clause 7.0


Comment:
Missing xref to PROBE-PNC-RESPONSE command.


Comment:
This sentence fragment " ...and may initiate another MLME-PROBE-PNC.request...

SuggestedRemedy:
Change the sentence fragment above to this:  In the case where this MLME-PROBE-PNC primitives have been used by a device as part of the PNC-HANDOVER process, the initiating DME shall initiate an MLME-NEW-PNC.request.  In the case where the MLME-PROBE-PNC primitives have been used by a device to simply request DEV information held by the PNC, the initiating DME may initiate another MLME-PROBE-PNC.request for a differenct remote device, or it may initiate an MLME-DEV-INFO.request.


Comment:
DestinationDEVAddress parameter name is incorrect, data type is incorrect, valid range is incorrect, and description are incorrect.

SuggestedRemedy:
Please change parameter name to RemoteDEVAID, data type to Integer, Valid range to 0-255, and description to: "The RemoteDEVAID of the DEV from ..."

Response:
PROPOSED ACCEPT IN PRINCIPLE. Please change parameter name to RemoteDevID, data type to Integer, Valid range to 0-255, and description to: "The RemoteDevID of the DEV from ..."


Comment:
RequestorDEVAddress parameter name is incorrect, the data type is incorrect, valid range is incorrect, and the description is incorrect.

SuggestedRemedy:
Please change parameter name to: RequestorDEVAID, the data type to: Integer, the valid range to: 0-255, and the description to: " The DEVAID of the DEV requesting the information."

Response:
PROPOSED ACCEPT IN PRINCIPLE. Please change parameter name to: RequestorDevID, the data type to: Integer, the valid range to: 0-255, and the description to: " The DevID of the DEV requesting the information."


Comment:
The ReasonCode data type field is incorrect and its valid range is incorrect.

SuggestedRemedy:
Please change ReasonCode data type field to: Enumeration, and the valid range to: "SUCCESS, RESPONSE_TIMEOUT


Comment:
Current Location of clauses 6.3.19-6.3.19.5 is incorrect.

SuggestedRemedy:
Please move the MLME-DEV-INFO clauses and MSC to just after the MLME-CHANNEL-STATUS, MLME-REMOTE-SCAN, and MLME-CHANGE-CHANNEL message sequence chart and just before the MLME-PNC-HANDOVER.request clause.


Comment:
Missing xref to the DEVICE-INFORMATION-REQUEST command frame previously known as PROBE-REQUEST.


Comment:
Missing xref to DEVICE-INFORMATION-REQUEST command frame previously known as PROBE-REQUEST.


Comment:
DestinationDEVAddress parameter name is incorrect

Response:
PROPOSED ACCEPT IN PRINCIPLE. Please change to RemoteDevID


Response:
PROPOSED ACCEPT IN PRINCIPLE. Please change to RequestorDevID.


Comment:
Missing xref to DEVICE-INFORMATION-RESPONSE previously known as PROBE-RESPONSE.


Comment:
The MLME-NEW-PNC.request, indication and confirm primitives are missing from the MLME-SAP interface clause.

SuggestedRemedy:
Please insert clauses 6.3.1.31 through 6.3.1.33.2 from doc 01/410r1 into the space just after Clause 6.3.18.5 MLME-PROBE-PNC message sequence chart.


Comment:
The MLME-PNC-HANDOVER message sequence chart is missing.

SuggestedRemedy:
Please insert Clause 6.3.1.34 MLME-DEV-INFO, MLME-PNC-HANDOVER, MLME-PROBE-PNC, and MLME-NEW-PNC message sequence chart from doc 01/410r1


Comment:
the sentence fragment "...specified by the the DeviceID parameter." is unnecessary.


Comment:
The DeviceAddress parameter is missing from the parameter list.

SuggestedRemedy:
Please insert the DeviceAddress parameter into the MLME-ASSOCIATE.request parameter list just before the CapabilityInformation parameter.

Response:
PROPOSED REJECT. The MAC will insert the DEVAddress of itself.


Comment:
The DeviceID parameter name is incorrect.

Response:
PROPOSED ACCEPT IN PRINCIPLE.  DEVAddress instead of DeviceAddress.


Comment:
The DeviceID parameter name is incorrect

Response:
PROPOSED ACCEPT IN PRINCIPLE. DEVAddress instead of DeviceAddress.


Comment:
The AssocDEVAddress parameter name is incorrect.

Response:
PROPOSED ACCEPT IN PRINCIPLE. DevID instead of DeviceAID.


Comment:
The sentence fragment : "...reception of a broadcast ASSOCIATION-RESPONSE command." is incorrect.

SuggestedRemedy:
Please change the indicated sentence fragment to: " ...reception of a beacon containing a NEW-ASSOCIATED-DEV information element.

Response:
PROPOSED ACCEPT IN PRINCIPLE. This section has been deleted.


Comment:
The ReasonCode parameter name is unneeded.

SuggestedRemedy:
Please remove the ReasonCode parameter from the MLME-NEW-ASSOCIATED-DEV.indication parameter list.


Comment:
The MLME-ASSOCIATION-RESPONSE.indication primitive no longer needed.

SuggestedRemedy:
Please change the indicated primitive to: MLME-NEW-ASSOCIATED-DEV.indication.


Comment:
The ReasonCode parameter, data type, valid range, and Description are unnecessary given the new name of this primitive.

SuggestedRemedy:
Please remove the indicated fields from the table.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Table 9 has been deleted.


Comment:
The DeviceID parameter name, and description are incorrect.

SuggestedRemedy:
Please change the DeviceID parm name to DeviceAddress.  Also change the Description to: The deviceAddress of the DEV that has been associated.


Comment:
The AssocDEVAddress parm name, data type, and description are incorrect.

SuggestedRemedy:
Please change the parm name to DeviceAID; the data type to Integer; and the description to: " The association ID of a new device that has become associated with the piconet."


Comment:
The sentence fragment "... a broadcast ASSOCIATION-RESPONSE command with a ReasonCode of SUCCESS."

SuggestedRemedy:
Please change the indicated fragment to: "... a beacon containing a NEW-ASSOCIATED-DEV information element."


Comment:
The text describing  the Effect of receipt is incorrect

SuggestedRemedy:
Please change the indicated text to: " The non-initiating DME, when it receives the MLME-NEW-ASSOCIATED-DEV.indication primitive, is provided with the DeviceAddress and DeviceAID of a successfully associated DEV."


Comment:
DeviceID parm name, data type, valid range, and description are incorrect

SuggestedRemedy:
Change parm name to: DeviceAID; data type to: Integer; valid range to:0-255; and description to: "Specifies the DEVAID of the peer device with which to perform the disassociation process."

Response:
PROPOSED ACCEPT IN PRINCIPLE. DevID, type Integer, range any valid DevID (xref 7.2.3) Specifies the DevID of the peer MAC entity . . .


Comment:
Include the possibility for authentication of the PNC.

SuggestedRemedy:
Include the 'PublicKeyChallenge' as an optional parameter in the MLME-AUTHENTICATE.request and MLME-AUTHENTICATE.indication.


SuggestedRemedy:
Include the 'PublicKeyProofe' as a conditional parameter in the MLME-AUTHENTICATE.response and MLME-AUTHENTICATE.confirm.


Comment:
missing definite article, add as shown below

SuggestedRemedy:
... functions on behalf of the general system ...


Comment:
missing definitive article, modify as shown below


Comment:
The RequestorDEVAddress is an incorrect parameter name


Comment:
The DestinationDEVAddress parameter at the end of the indicated sentence is incorrect.


Comment:
Missing xref to the CHANNEL-STATUS-RESPONSE command clause in Clause 7


Comment:
the ReasonCode message "ACK_TIMEOUT" at the end of the indicated sentence is incorrect.

SuggestedRemedy:
Please change from ACK_TIMEOUT to RESPONSE_TIMEOUT.


Comment:
The MLME-CHANNEL-STATUS message sequence chart is missing the ChnlStatusRspTO timer.

SuggestedRemedy:
Please provide the appropriate timer symbol for the message sequence chart.


Comment:
The MLME-CREATE-REPEATER.request, indication, response, and confirm primitives are missing from the MLME-SAP interface clause.

SuggestedRemedy:
Please insert clauses 6.3.1.8 through 6.3.1.11.2  just after the 6.3.16.5 MLME-CHANNEL-STATUS message sequence chart.


Comment:
The MLME-CHANNEL-STATUS and MLME-CREATE-REPEATER message sequence chart is missing.

SuggestedRemedy:
Please insert the MLME-CHANNEL-STATUS and MLME-CREATE-REPEATER message sequence chart clause and diagram just after the last clause of the MLME-CREATE-REPEATER.confirm primitive.  Text and diagram are in clause 6.3.1.12 of doc 01/410r1


Comment:
The MLME-REMOTE-SCAN.request, indication, response and confirm primitives are missing from the MLME-SAP interface clause.

SuggestedRemedy:
Please insert clauses 6.3.1.13 through 6.3.1.16.2 from 01/410r1 into the space just after the MLME-CHANNEL-STATUS and MLME-CREATE-REPEATER message sequence chart clause.


Comment:
The NewChannelIndex data type is incorrect.


Comment:
The ChannelChangeTimeout data type is incorrect.

SuggestedRemedy:
Please change the data type from octet to Duration with valid range of 0 to 255 ms?


Comment:
The  MLME-CHANNEL-STATUS-, MLME-REMOTE-SCAN, and MLME-CHANGE-CHANNEL message sequence chart is missing from the MLME-SAP interface clause.

SuggestedRemedy:
Please insert Clause 6.3.1.19 from doc 01/410r1


Comment:
The MLME-PNC-HANDOVER.request is missing from the MLME-SAP interface clause.

SuggestedRemedy:
Please insert clauses 6.3.1.24  through 6.3.26.2 of the MLME-PNC-HANDOVER.request, indication, response and confirm clauses into the space just before current D09 clause 6.3.18.


Comment:
The clause title "Peer attribute discovery" is incorrect

SuggestedRemedy:
Change the clause title to: "Retrieving PNC Info"


Comment:
Missing xref to Peer Discovery sub clause in Clause 8.


Comment:
EncryptedKeyObjectLength should have values greater than or equal to 0, not 1.  It may be that this field is intentionally left blank.


Comment:
An MLME-DISTRIBUTE-KEY.response should be created so that the DEV that decided to distribute the key can know whether the key was successfully decrypted or not.

Response:
PROPOSED REJECT. If DEV does not properly decode message, it will make another request.


Comment:
When does DE-AUTHENTICATE actually get used?  What purpose does it serve?  I don't think it really makes sense to have a command that says that your key has been compromised if that is what this is for.

SuggestedRemedy:
Recommend removing these commands.  Comment via Ari Singer.


Comment:
Why does the PROBE-PNC command only get information about authenticated DEVs?  Can this only be done in a secure piconet?  What is the purpose of this command?

SuggestedRemedy:
Recommend explaining the purpose of this command (if it isn't in there already).  Comment via Ari Singer.


Comment:
Why does the device care about the last device to authenticate and deauthenticate?  Where does it get this information?

SuggestedRemedy:
Remove AuthenticateFailDevice (why is it called "Fail" anyway?) and DeauthenticateDevice.  Comment via Ari Singer.


Comment:
6.6.9 PHY PIB ranging support: The PHYPIB_Range object calls for two octets, range in meters in the first octet, and fractional part of a meter in cm for the second octet.  At the moment nothing supports this in clause 11. It is too early to understand if this is the correct format to carry us into the future.  Since we don't know how "location awareness," which might include ranging and other attributes, will be addressed in 3a. It is better to remove the object now rather than be faced with a work-around in the future.


Comment:
No MLME-STREAM-CONNECT primitive in Table 1


SuggestedRemedy:
Add time out parameters to the MLME-CREATE-STREME & MLME-MODIFY-STREME primitives

Response:
PROPOSED ACCEPT. Add value called timeout as type duration, valid range >1, Description of "Time in ms that the MAC allows for completion of this command."


Comment:
A DEV requesting switch to ACTIVE CTA expects the PNC to grant previously requested QoS upon receipt of the switch command. This is a "should" and not a "shall" as is appropriate. However, the expectation is that the PNC shall do the switch in the very next superframe beacon even if the requested bandwidth is not immediately available. This lets the EPS DEV make the switch to ACTIVE in anticipation of bandwidth becoming available in the next few superframes as the PNC is able to juggle requirments. The comment is located here because of adjacent text that might lead the implementer to error.

SuggestedRemedy:
Add - The PNC shall provide the switch to ACTIVE operation even if it is unable to return the full CTR allocation.


Comment:
Momentary should have had two additional fields in the d0.9 that didn't make it into the draft. The destination DEV address and stream index are required.

SuggestedRemedy:
make the change to figure 61 - Momentary EPS CTA command format. Add the stream index and destination DEV address.  The text is correct already.

Response:
PROPOSED ACCEPT IN PRINCIPLE. The command that is going to be used to wake up a DEV should contain the stream index and  DevID parameters.


Comment:
There is a possible authentication question with EPS and switch to ACTIVE mode or EPS mode commands. The use of these commands requires agreements between peers (after association and authentication). There may be an opportunity for an unauthorized DEV to control another DEVs power use. Sending DEVs are normally responsible for the mode shift to have the destination DEV react to changes in data transmission flow that the destination is not directly aware of. I am not clear on the security mechanisms to understand if this is an issue or not.

SuggestedRemedy:
This may be as simple as adding a note in this subclause that the destination DEV may reject the operation if not setup in a stream managment command sequence. The offended DEV would then send a switch command to the PNC to let the PNC and other network DEVs know its correct state.  The intent is to not burden the PNC with filtering unless this is a simple fit into existing PNC filtering operations (e.g., CTRs are not processed unless they match to an existing stream setup). If this is simple then the PNC should reject the operation.


Comment:
The task group has indicated before that 8 supported rates will be sufficient for PHYs other than the current one described in clause 11. However, it would seem that the limit be somewhat higher. 16 seems too high but perhaps that would be a good ceiling.

SuggestedRemedy:
change Figure 25 in clause 7.4.6 to allow up to 16 supported rates.


Comment:
A left over in that EPS is called sleep state. Also, this bit should be to indicate possiblility of operating in EPS mode. Other information carried elsewhere

SuggestedRemedy:
Change text: The PSAVE bit shall be set to 1 if the DEV is capable of using EPS mode as part of power management.


Comment:
There is no mention here of what the setting should be when MTS is used rather than CAP. Also, the xref to 8.4.2 would indicate that more would be found there, and 8.4.2 is fairly short in description.


Comment:
reference is made to a "traffic category".  This term is used just once in the whole docuement (i.e. used only in this sentence).

SuggestedRemedy:
Question for MAC subcommittee ... resolve if this is the correct name.  Is there another more common name used in the document?


Comment:
poor sentence structure ... suggest rewrite as shown in sentence fragment below

SuggestedRemedy:
... sequence number information, and optional traffic category ...


SuggestedRemedy:
... fields are numbered from 0 to k, ....


SuggestedRemedy:
Please add the definition of a "natural number" to clause 3


SuggestedRemedy:
Couldn't the fragmentation process be signified by setting a single bit?  0=not fragmentating and 1=fragmentating


Comment:
Lack reference to information on encryption key

SuggestedRemedy:
Please provide reference for the following sentence fragment  "currently assigned data encryption key"  where in clause 10 is this data contained?  If not present it needs to be added.


Comment:
There are only 3 addresses available for neighor piconets.

SuggestedRemedy:
Please increase the addresses available from 3 to 6 ... 4 on each side, 1 above and 1 below.


Comment:
This clause states there is security information in the frame body.

SuggestedRemedy:
Provide reference to the specific clause 10 subclause that describes this security information.


SuggestedRemedy:
The length field of the frame shall count the number of octets, including the stuffed octet.


SuggestedRemedy:
PNC and the DEV (during a MTS) or during ...


Comment:
missing definitive article, add as shown below


SuggestedRemedy:
... 2-octet boundary within the frame body.


Comment:
Field resolution is 8 uS ... this may be inefficient for 100+ Mbps data rates.  Changing this to something less (like 1 uS) impacts a number of issues in the standard.

SuggestedRemedy:
Bill Shvodian of XtremeSpectrum to provide text on a recommended solution.


Comment:
Reference is made to the "current data encyrption key (DEK)"

SuggestedRemedy:
Provide reference to the DEK details.  If the subclause is missing in clause 10 then provide the details.


Comment:
Figure 25 indicates that the supported data rates is represented by up to 8 octets, one octet for each data rate.  Reference is provided in the tesxt to clause 11.7.  In clause 11.7, Table 94 is a 5 bit mapping to a given data rate.  How does the 5 bits map to the octet?

SuggestedRemedy:
Suggest the 5 bits of table 94 represent the 5 LSBs and that the upper 3 bits of the octet be zeros.


SuggestedRemedy:
... DEVs shall expect a beacon from the PNC in ...


SuggestedRemedy:
Clause 10 does not make reference to IEEE P1363 and it appears that it should.  How does P1363 enter into the security algorithms?


SuggestedRemedy:
The current TX power is the DEVs estimate ...


Comment:
In figure 30 do two things:  1. name the last column as "slot location field" 2. Add SFNext to acronym list in clause 4


Comment:
This paragraph references a field that contains "the least significant two octets of a beacon number".

SuggestedRemedy:
This paragraph is confusing.  Power management subcomittee needs to clarify and provide addditional references to other clauses.


SuggestedRemedy:
... and shall be set to 1 if they are in EPS mode.


SuggestedRemedy:
Security subcommittee needs to resolve this TBD in this line.


SuggestedRemedy:
... offset from the start of the superframe and hence the start of the transmission of the beacon frame ...


Comment:
Modifications to Figure 32 as shown below

SuggestedRemedy:
element ID = 0x0B use full name "MACPIBMaxAssignedCTAs" use full name "MACPIBMaxProcessedCTAs"

Response:
PROPOSED REJECT. Use of generic name preferred by technical editor.


SuggestedRemedy:
... DEV to know if any GTSs, where it is either the SA or DA, have changed ...


SuggestedRemedy:
I see no need for the application specific information information element.  Unless someone can justify it, please delete the entire clause.


SuggestedRemedy:
MAC subcommittee needs to justify 16 bit commands ... prefer to replace with 8 bit commands


Comment:
grammatical ... add a colon as shown below

SuggestedRemedy:
... PNC selection commands: the alternate PNC ...


SuggestedRemedy:
0x000B "Alternate PNC announcement command" 0x000C "Alternate PNC pullout command" 0x000D "PNC handover command"


SuggestedRemedy:
At the end of a PNC handover, the new PNC of the piconet uses the PNC selection frame with this action type to signal the end of the PNC handover.


SuggestedRemedy:
... association address; hence, this command ...


SuggestedRemedy:
Add text to clause 10 the details of the Piconet Security Manager - security subcommittee.


SuggestedRemedy:
In clause 10, provide technical details for the DEVPublicKeyObject


SuggestedRemedy:
In clause 10, please provide details of the AuthenticationInfo - security subcommittee.


SuggestedRemedy:
security subcommittee to provide detail of PublicKeyChallenge


SuggestedRemedy:
Security subcommittee needs to provide technical detail in clause 10 on the PublicKeyProof


SuggestedRemedy:
Security subcommittee to provide technical detail in clause 10 about the KeyPurpose


SuggestedRemedy:
Security subcommittee to provide detailed text in clause 10 about the EncryptedKeyObject


Response:
PROPOSED ACCEPT IN PRINCIPLE. Change PAN Information Base to Personal Information Base in this section and in clause 1. Change 'personality' to 'characteristics' in this paragraph. Delete ", hence the acronym PIB".


SuggestedRemedy:
PIB-related --> PIB related user-entity --> user entity


SuggestedRemedy:
add commas after the following parameters: RequestType EPSSet EPSStatus


SuggestedRemedy:
from errors rather than waiting for the next


Comment:
Reason code definitions ... there are no reason codes in clause 7.5.7.2

SuggestedRemedy:
have management subgroup provide proper reference to reason codes

Response:
PROPOSED ACCEPT IN PRINCIPLE. Change xref from 7.5.7.2. To Table 67. Change ResonCode to ActionType.


SuggestedRemedy:
Put a comma after the parameter "OpenScan"


SuggestedRemedy:
range is listed as 100-65535 ... should this be 0-65535?


SuggestedRemedy:
remove comma after parameter "SyncFailureTimeout"


SuggestedRemedy:
Should this be one octet?  Is there an upper limit?

Response:
PROPOSED ACCEPT IN PRINCIPLE. Resolved as in 566. Upper limit not specified.


Response:
PROPOSED ACCEPT IN PRINCIPLE. Duration. See 566 for direction.Change valid range to be Xref to 7.5.2.1. Add in 7.5.2.1, this implies a range of 0-65535 ms.


SuggestedRemedy:
Add a comma after DeviceID Remove the comma after AssocDEVAddress


SuggestedRemedy:
Should be  MLME-DISASSOCIATE.indication primitive parameters


SuggestedRemedy:
Should be  MLME-DISASSOCIATE.confirm primitive parameters


Comment:
Under the Type column ... should the integer type be defined as to the number of octets?    Also, what is the nature of the byte string ... shouldn't the number of bytes be specified?

SuggestedRemedy:
Refer to MAC/security subcommittee to supply number of octets.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Will use integer and octet strings in tables.


SuggestedRemedy:
The following are listed as parameters for a primitive ... but no primitives use these.  Where are they used?  SecurityManagerPublicKeyObjectLength SecurityManagerPublicKeyObject


SuggestedRemedy:
Delete the following parameters from table 13.  They are used in table 14 and are redundant.  PublicKeyChallengeLength PublicKeyChallenge PublicKeyProofLength PublicKeyProof


SuggestedRemedy:
The description for the parameter DEVPublicKeyObject refers to a cipher suite.  The cipher suite details are not present in draft 9 text.  Needs to be added.


SuggestedRemedy:
second line of description for AuthenticationInfoLength parameter ...  change the word "device" to "defined"


Comment:
The text says ...  "The DME may use the MLME-CHALLENGE.request command to obtain additional security information from the associated DEV.

SuggestedRemedy:
Security subgroup needs to provide reference in text where this procedure is described.


Comment:
The text at the end of line 32 describes an authentication sequence.

SuggestedRemedy:
Security subcommittee needs to provide text reference to this authentication sequence.


Comment:
Description of public key authentication challenge

SuggestedRemedy:
What and where are the public key authentication challenge described?


SuggestedRemedy:
Table 14 does not define the ReasonCode.  The security subcommittee needs to provide the reason codes.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Copy ReasonCode from Table 13 to Table 14. Also close 455.


SuggestedRemedy:
... of the results, via the reason code, of a previously ...


SuggestedRemedy:
security subcommittee needs to define and explain usage of the following items from table 15  KEK DEK DIK SEED


Comment:
Need octets associated with Types integer and  byte string in table 15


SuggestedRemedy:
In table 15, the parameter DistributeKeyFailureTimeout is defined but not used by any primitives.  Security committee needs to clarify.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Remove DistributeKeyFailureTimeout from Table 15.


Comment:
PNC requirement to be the security manager

SuggestedRemedy:
In line 41 it is required that the PNC be the security manager, yet no place in the text is this function detailed.  The security subcommittee needs to provide the details.


Comment:
Line 19 indicates that "the PNC shall encrypt and return the designated key"

SuggestedRemedy:
Security committee needs to provide the encryption algorithm.  What is the algorithm?


Comment:
In line 22, reference is made to a null key and the appropriate result code.

SuggestedRemedy:
Security committee to provide definition of a null key and what are the associated (and appropriate) result codes.


SuggestedRemedy:
Referenced table 15 does not provide the reason code definitions.  Security committee needs to provide these reason codes.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Add ReasonCode to Table 15 with values of SUCCESS or FAILURE.


SuggestedRemedy:
change the last word in line 43 from "message" to "response".


Comment:
in line 4, reference is made to an "encrypted format".

SuggestedRemedy:
Security subcommittee to provide the details as to what is this encrypted format.


Comment:
In type column of table 16, how many octets are required?

Response:
PROPOSED ACCEPT IN PRINCIPLE. Will use integer and octet strings in Tables.


SuggestedRemedy:
The commands are misspelt ... replace "distibute" with "distribute"


SuggestedRemedy:
Question for security committee ... in line 45 the command is given as "MLME.DISTRIBUTE-KEY.response".  Should this be "MLME.DISTRIBUTE-KEY.indication"?

Response:
PROPOSED ACCEPT IN PRINCIPLE. Delete second sentence in this paragraph "Then DME shall . . . Command." Also closes 461


SuggestedRemedy:
Table 16 does not provide the reason code ... security committee needs to define the reason code.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Resolve as in 460.


Comment:
Reference to "directed distribute key request command" and a "broadcast distributed key request command".  These seem like two different commands.

SuggestedRemedy:
Security commmittee needs to clarify what primitives handle these two commands.  Are they differentiated by parameters?  If so, which parameters?

Response:
PROPOSED ACCEPT IN PRINCIPLE. They are differentiated by the DevID used to send the .request command.


SuggestedRemedy:
add commas to the following parameters  PiconetType ChannelList ChannelScanDuration MACParameterSet


SuggestedRemedy:
Add a figure to show the MACParameterSet vector

Response:
PROPOSED ACCEPT. Turn the text at the bottom of the page into a table. Add types as appropriate.


SuggestedRemedy:
CAP Mode is not defined in clause 7.4.2.  MAC subcommittee needs to clarify the reference here.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Change CAP Mode to be Piconet mode which is acutally defined in section 7.4.2.


Comment:
Provide a figure that shows the vector representation of "ServiceFlowList" and "ARQList" as reflected in tables 23 and 24 respectively.


Comment:
Modify the sentence of line 33 as shown below.

SuggestedRemedy:
... command (ActionType=request) (7.5.10.3), which is ...


Comment:
Add a figure to show the ChannelTimeList vector as referenced in table 26


Comment:
How is EPS impacted by a stream modification.  Does the "SlotStartTimeSet" parameter shown in table 25 also apply to SFNext?

SuggestedRemedy:
Refer this question to the power management subcommittee.


SuggestedRemedy:
... command (7.5.10.1), which it will send ...


SuggestedRemedy:
... CHANNEL-TIME-GRANT command (7.5.10.2) with a ....


Comment:
ACK_TIMEOUT is referenced several times in clause 6.3.XX, but I can't find the definition of ACK_TIMEOUT.

SuggestedRemedy:
MAC subcommittee to provide a clause reference to ACK_TIMEOUT.


SuggestedRemedy:
Line 52, replace "with out" with "without"


SuggestedRemedy:
add a comma at the end of the parameter Streamindex


Comment:
Opening sentence is missing the opening clause.  Modify as shown below.

SuggestedRemedy:
Figure 10 illustrates the sequence of ...


Comment:
Modify first line of clause 6.4 as shown below.

SuggestedRemedy:
... PLME-SET primitives operating on the PHY PIB ...


SuggestedRemedy:
... shall be a request by the PLME to reset ...


SuggestedRemedy:
Remove the comma after the parameter "DataRate".


SuggestedRemedy:
This optional primitive shall be a request by the PLME to ...


SuggestedRemedy:
The PIB characteristics group, Table 38, ...


SuggestedRemedy:
... association group, Table 40, contains ...


SuggestedRemedy:
... PHY PIB values that are unique to ...


SuggestedRemedy:
... on the regulatory domains for the 2.4 GHz PHY is given in 11.1.


Comment:
The text in line 4 claims there is a mapping between the data rate vector and the actual data rate that is PHY dependent.  Where is this mapping in clause 11.  How does this map to the PHYPIB_DataRateVector and the PHYPIB_CurrentDataRate?


Comment:
The Managed objects are PHY dependent but are not defined in clause 11.

SuggestedRemedy:
The PHY subcommittee needs to add the following items to clause 11  PHYPIB_TxMaxPower PHYPIB_TxPowerStepSize PHYPIB_CurrentPowerLevel


SuggestedRemedy:
Correct spelling ... it should be  PHYPIB_MPDULengthMax


Comment:
Clause 11 does not list the managed object

SuggestedRemedy:
Define PHYPIB_MPDULengthMax in clause 11 ... refer to PHY subcommittee


Comment:
Need to add a statement to clause 6.6.9 that the PHY of clause 11 does not support ranging.

SuggestedRemedy:
Add the following statement at the end of line 12   (Note: the IEEE802.15.3 PHY of clause 11 does not currently support ranging).


Comment:
Clause 11 does not address the managed objects of table 50

SuggestedRemedy:
The PHY committee needs to add reference to the values used for PHYPIB_NumPSLevels and PHYPIB_PSLevelReturn.


SuggestedRemedy:
change the sentence at the end of line 41 and the beginning of line 42 as:  ... identified logical connection; however, it does not ...


SuggestedRemedy:
... to understand the parameters which need ...  (remove the comma after the word parameters)


SuggestedRemedy:
remove comma after the parameter  ReceptionStatus


SuggestedRemedy:
add a comma as shown below  ... characteristics of, and methods of, transmitting and ...


Comment:
Add figures to illustrate the vectors TXVECTOR and RXVECTOR


Comment:
There is no request type for Peer Wakeup, wakeup, DEV to PNC PS Information Command

Response:
PROPOSED ACCEPT IN PRINCIPLE. Split MLME PowerMgmt command into separate MLMEs for each command. Jay and WMS are providing.


Comment:
It is not clear why the PNC needs to know that the device is RPS vs. PM_OFF.

SuggestedRemedy:
Remove RPS as a state altogether.  Any device can do what is described here ase RPS.  There is no need to differetiate between active and EPS.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Delete RPS as a separate state, the PNC is informed via the capability field if the DEV is going to use power save methods.


Comment:
Why is PowerManagementPriority here and not in the capability field where it belongs.

SuggestedRemedy:
Remove PowerManagement Priority from the MLME.  Add it to the PIB if it is really needed, or better yet eliminate it.  What is to keep manufactureres from setting this to the  High for all their devices so that they appear to get better battery life than the competitors.  Our hardware team says that slot positions will not save any significant amount of power.

Response:
PROPOSED ACCEPT IN PRINCIPLE.  Remove from the MLME. Add to the PIB capability information element. Put in bits 8-9 in Figure 22. Ensure that it can be set from the Dev host. Delete PowerMgmtPriority from Figure 58 page 125 section 7.5.7.3.


Comment:
I see no mention of ReasonCode in 7.5.7.2

SuggestedRemedy:
Should Reason Code really be Action Type in Table 67?


Comment:
This request better do more than "sets the DEV power management parameters."  Doesn't it also determine which power management commands are sent to the PNC or the other DEV?

SuggestedRemedy:
Put together a table that shows explicitly which PM commands are sent as a result of which PM primatives in the MLME

Response:
PROPOSED ACCEPT IN PRINCIPLE. Split MLME into separate primitives. Jay and WMS to provide.


Comment:
MLME-POWERMGT.indication only has one parameter, but it really needs to have almost all of the parameters as the request.  The PNC will receive an indication as the result of recieving a power managemnt command.

SuggestedRemedy:
Add appropriate parameters to the indication.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Splite MLME into separate commands. Jay and WMS to provide. Ensure that parameters in a .request match the parameters in a .indication.


Comment:
If you have peer wakeup, you need to have a peer address


Comment:
Why is there no MLME-POWERMGT.response.  The PNC should send a response in response to an indication.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Split MLME into separate commands. Jay and WMS to provide. Ensure there are responses when appropriate.e.g., EPSAction command.


Comment:
Where does the DEV get the PNID from to scan for?   Are PNIDs random at startup, or does PNC always use same PNID?   What if different PNC?

SuggestedRemedy:
Need to address where PNID to scan for comes from.

Response:
PROPOSED ACCEPT IN PRINCIPLE. DME has option of remembering PNID to allow DEV to join a specific piconet.


Comment:
The scan is done once PNID is found, but there is a small but non-zero probablity that the same PNID may be heard on separate chanels

SuggestedRemedy:
Continue scan until all channels are scanned regardless if desired PNID is found.

Response:
PROPOSED ACCEPT IN PRINCIPLE. In 8.2.1, page 138, line 4, change "available in the PHY" to "indicated in the MLME command that initiated the scan." Replace the text "If the beacon . . Openscan, then" with "If the DEV finds only a frame and no beacon it shall report it as a part of the MLMEScan/Start.confirm commands. The".

Note: The original comment references text that was deleted due to another accepted comment.


Comment:
There is no way to indicate that a frame with the PNID was found, but not a beacon

SuggestedRemedy:
Add a "PiconetStatus" where 0 indicates no frames were found, 1 indicates frames were found but not the beacon, and 2 indicates the beacon was found.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Type will be integer. Valid range 0-2. 

Note: This will improve ability to detect other piconets and reduce likelyhood of starting another piconet in an occuppied channel.


Comment:
Move Start MLME to be adjacent to Scan, Synchronization and Associate.

SuggestedRemedy:
Move Start MLME to be adjacent to Scan, Synchronization and Associate.


Comment:
No indication of power level if no beacon found.

SuggestedRemedy:
Provide a signal strength field for avoidance of 802.11 or other users

Response:
PROPOSED ACCEPT IN PRINCIPLE.

Add to MLME-SCAN a parameter, Channel Rating, type integer, valid range 0-255, that rates channels, 1 through N from "best" to "worst", 1 is the best channel (i.e. least interference) while N is the worst channel, (i.e. the most interference.)

Add to scan procedure:
"If a DEV is looking to start a new piconet, then it should also look for potential interference in the channels that it scans and rate the channels, from best (lowest interference) to worst (highest interference) and return this information in the MLME-SCAN.confirm command via the ChannelRating.  The DEV should choose to start the piconet in the channel with the least amount of interference in the channel."


Comment:
Need a MLME-SyncLost.indicate to tell the DME that the DEV can no longer hear the Beacon.

Response:
PROPOSED ACCEPT IN PRINCIPLE. WMS to provide text. Has no parameters. Sent when the ATP expires with no beacon heard.


Comment:
All the parameters in this table need maximum values in the valid range column so that implementers can choose the proper number of bits to use in their implements.

SuggestedRemedy:
Add maximum values into the Valid Range column for all fields.


Comment:
Table 14 needs maximum valuse in the range so that implementers can size their design.

SuggestedRemedy:
Add maximum values into the range column in Table 14

Response:
PROPOSED ACCEPT IN PRINCIPLE.  Put an upper limit of 256 in the valid range for the three key lengths in Table 14.


Comment:
Reason Code needs to be defined in Table 14

Response:
PROPOSED ACCEPT IN PRINCIPLE.  Reason code to be added.


Comment:
Table 15 needs maximum values in the range column

Response:
PROPOSED ACCEPT IN PRINCIPLE.  Put maximum value of 256 in the valid range for the EncryptedKeyObjectLength.


Comment:
Need to define KEK, DEK, DIK, and SEED for us non-cryptographers, besides just the acronyms.

SuggestedRemedy:
Define KEK, DEK, KIK, and SEED, besides just the acronym.


Comment:
Reason code needs to be defined in Tsable 15.


Comment:
Reason Code needs to be added to table 16


Comment:
Break MLME-POWERMGT command up into separate MLMEs, like security/authentication did.

SuggestedRemedy:
Break up into Peer Wakup, wakeup, DEV to PNC PS Information, query, join...

Response:
PROPOSED ACCEPT.  Jay and WMS will draft the new MLMEs.


Comment:
Putting clause 6 before clause 7 and 8 will confuse new readers.


Comment:
MLME-START.confirm should have the channel number that the piconet was started in.

SuggestedRemedy:
Add Channel Number to the MLME-START.confirm  parameters.


Comment:
Source Address and destination address should be the 48 bit MAC address, not the 8 bid AD-AD.  This is for 2 reasons:  1) to be consistent with the other MLMEs.  Wo does the address translation, the DME or the MLME?  We need to be consistent.  Second, the stream request command should contain MAC addresses, not AD-ADs to safeguard against discrepancies.

SuggestedRemedy:
Replace these 8 bit AD-ADs with 48 bit MAC Address


Comment:
2 octet SequenceNumber is inconsistent with the 1 octet stream requeest identifier in the stream request command.  Also, we have a Sequence Number field in the MAC header - 2 words, but still too close.

SuggestedRemedy:
Change 2 octet Sequence Number field to 1 octet StreamRequestIdentifier.  Change all instances of SequenceNumber to StreamRequestIdentifier in all of clause 6.


Comment:
Direction bit needed for the MLME-CREATE-STREAM parameters.


Comment:
Add direction parameter to MLME-CREATE-STREAM.request


Comment:
Remove Peak Rate, Min rate and Max Burst Size from from service flow and stream mangement.  The PNC cannot guarantee any of these.  It can only guarantee channel time.  If RSVP or other reservation protocol is used, the will negotiate at a higher layer, not at the MAC.

SuggestedRemedy:
Remove Peak Rate, Min rate and Max Burst Size from from service flow  and stream management.


Comment:
Source and destination addresses should be initiator and target for consistency with stream management command.

SuggestedRemedy:
Change source and destination addresses to initiator and target


Comment:
Slot Start Time set is defined in Table 25 - reference needed


Comment:
Move the PNC to in between Dev A and Dev B since A and B only talk to the PNC.  This will simplify the drawing.

SuggestedRemedy:
Move the PNC to in between Dev A and Dev B since A and B only talk to the PNC.


Comment:
If we are going to have a figure showing bipartate MSC from DEV to PNC, we should show bipartate negotiaon from PNC to DEV.

SuggestedRemedy:
Add figure showing bipartate negotiaon from PNC to DEV.


SuggestedRemedy:
bipartate negotiaon between the PNC and DEV is all that is needed.


Comment:
Stream 0 is used regardless of destination address.  Need to specify a destination DEV to start a channel time request for non stream data.

SuggestedRemedy:
Add destination address to the MLME-MODIFY-STREAM.request


Comment:
Table is missing a vertical line between Valid Range and Description


Comment:
RemoteDEVAddress does not match the parameters in the MLMEs

SuggestedRemedy:
remove RemoteDEVAddress and add DestinationevAddress (or replacement) and RequestorDEVAddress (or replacement)


Comment:
The requesting DEV choose the window size, not the responding DEV.

SuggestedRemedy:
Add window size to the request, and also to the Channel Status Request command in clause 7.5.4.3 and the indication in 6.3.16.2


Comment:
Why is the PNC on of the MLMEs in a channel status request?


SuggestedRemedy:
Remove this and keep only DEVICE-INFORMATION-REQUEST command.  Do this globally for 6.3.18.1-4


Comment:
Subclause is called Peer attribute discover, but the MLMEs are MLME-PROBE-PNC, and they cause device information request commands to be sent, not probe commands.

SuggestedRemedy:
Get ride of the word "probe" in the MLMEs.  change to MLME-PNC-Information.


Comment:
MLME-DEV-INFO MLMEs don't send Device Information commands, they send probe rewquest commands.

SuggestedRemedy:
Change the names to MLME-DEV-Probe for consistency and readability.


Comment:
This MLME should send the probe command, not the device informmation request (which goes to the PNC).

SuggestedRemedy:
Remove "DEVICE-INFORMATION_REQUEST" and just keep PROBE-REQUEST.  Do a global change for 6.3.19.1-4


Comment:
MLME-DEV-INFO.confirm needs a DestinationDeviceID so the DME knows who is responding.

SuggestedRemedy:
Add DestinationDeviceID (or new name) to the MLME confirm.


Comment:
PHYPIB_CurrentDataRate shouldn't be a PHY PIB.  It is passed at the PHY SAP on a packet by packet basis.

SuggestedRemedy:
Remove PHYPIB_CurrentDataRate from the PIB


Comment:
Curfrent Rx and TX antenna are passed at the PHY SAP and should not be PIB  values becasue they are set on a packet by packet basis.

SuggestedRemedy:
Remove current Rx and Current Tx antenna from PIB


Comment:
Current Power Level doesn't belong in the PIB.  It is sent with each packet at the PHY SAP

SuggestedRemedy:
Remove PHYPIB_CurrentPowerLevel from the PIB


Comment:
The sentence "Broadcast and Multicast transport are part of the asynchronous data service provided by the MAC." provides no information.  Unicast is part of the data service, too.


Comment:
"All DEVs shall support the asynchronous data service."  This is a LAN mentality, not WPAN.  Devs can may be simplified by eliminating asynchronous data service.

SuggestedRemedy:
Make asynchronous data service optional.


Comment:
Remove reference to strictly ordered service class.  This is an 802.11 holdover.

SuggestedRemedy:
Remove references about strictly ordered service class.


Comment:
Need a MAC_DATA.confirm to indicate status in the event of a failure.


Comment:
Data Rate and Power Level should not be PIB parameters.  Rename the value.

SuggestedRemedy:
change data rate and power lavel from being PIB valuse


Comment:
Remove PHYPIB_DataRates from the Rx vector.  It should be Rxtate, not PIB.


Comment:
Need to specify that the preamble starts when this command is received.

SuggestedRemedy:
Specify that the Preamble starts when PHY-TX-START.request is received.


Comment:
Having EPS be both a mode and an EPSSatus is very confusing.

SuggestedRemedy:
Rename either the EPSStatus values to EPS_Active and EPS_Inactive


Comment:
MLME-DISTRIBUTE-KEY does not have a response.  Without a response, the PNC (or security manager) will not know if the associated DEV actually received the key or not.

SuggestedRemedy:
Add a response message.  Comment via Ari Singer.


Comment:
DEVPublicKeyObjectLength, AuthenticationInfoLength, SecurityManagerPublicKeyLength, PublicKeyChallengeLength and PublicKeyProofLength should all have values greater than or equal to 0, not 1.  It may be that these fields are intentionally left blank.


Comment:
PublicKeyChallengeLength and PublicKeyProofLength should have values greater than or equal to 0, not 1.  It may be that these fields are intentionally left blank.


Comment:
the text mentions EPS slots. Clearer wording would be wake superframes.

SuggestedRemedy:
change "EPS slots" to "wake superframes"


Comment:
we should be talking about microseconds and not milliseconds. If we stay consistent, the resolution should be 8 us and range is 0 to 524280


Comment:
in the second field, the range of bits should be b16 to b19


Comment:
I don't understand the use of the grant status field format. Isn't the SFNext a short form of the next beacon that an EPS DEV will wake on? It would seem that what we want in Figure 74 is the start time of the adjacent GTS as the text in line 31 states.

SuggestedRemedy:
change from SFNext to adjacent GTS start time in Figure 74 and then use adjacent GTS start time instead of SFNext on line 31.


SuggestedRemedy:
Remove "The security field is a 2 bit field defined in 7.2.1.2.


SuggestedRemedy:
Remove Security field from the control information field and shift other fields left increasing size of reserved field by 2 bits.


Comment:
AuthenticateFailureTimeout is not sent with the Challenge command. It is used within the MAC to limit the amount of time the MAC will wait for an Authentication response.

SuggestedRemedy:
Remove the last field (AuthenticationFailureTimeout) from Figure 44 on page 117. Remove lines 20-22 on page 117.


Comment:
Figure desired to outline the MAC frame format


Comment:
"Each field is defined in 7.2.1."  - Shouldn't this be 7.2?


Comment:
Where is the PHY preamble and PHY header in this figure?


Comment:
"repeater service" - why is this service needed?  Wouldn't the devices just talk in a peer to peer mode?  What benefit is there to having a go between (the PNC)?

SuggestedRemedy:
Need understanding of this feature.  Not explained well.


Comment:
This information is already stated on page 96, line 52.  This paragraph is not needed.


Comment:
"... four defined frame types."  - What are they?  Please list them, otherwise the sentence is useless.


Comment:
"The information elements in the beacon frame may appear in any order in the beacon ..."  - How do you know what you are looking at if they can appear in any order?

SuggestedRemedy:
Clarify meaning or method of information determination.


Comment:
"... DEVs may ignore any elements in the beacon that are not listed in Table 60."  - then what are the optional elements that can be ignored.  Please state them explicitly.

SuggestedRemedy:
Need a clear understanding of what is optional and what is mandatory.


Comment:
Title should read: "Frame and stream control field settings ..."


Comment:
"in Kus" (with u meaning micro here) - is this to mean that units are 1024 usecs?

SuggestedRemedy:
Unclear about actual meaning.  State clearly.


Comment:
"The bit shall be set to 0 if they are in ACTIVE mode and shall be set to 0 if they are in EPS mode."  Which one should be set to 1?


Comment:
This paragraph is very vague and does not say anything.  Given the TBD, I assume this is a place holder for data to come.

SuggestedRemedy:
Looks like agreement is needed here to determine the requirement for this place holder.  Finish discussion and complete requirement.

Response:
PROPOSED ACCEPT IN PRINCIPLE. This sentence has been deleted. See comment 296.


Comment:
This paragraph is a repeat of one on page 107, line 23.


Comment:
Where is SFNext defined?  Did not find reference to it in the following text.  Is it a specific value?  Or based on system design and is specified in the  PIB?


Comment:
What is a "EPS set"?  Where is it defined?  For that matter, where is RPS defined?  Is it a parameter set by the design and communicated through the PIB?


Comment:
"... same response rules a the device ..."  - should be "as".


Comment:
What does "ReTX" mean?  It also appears on page 135, line 18.


Comment:
"in Koctets/s" (with u meaning micro here) - is this to mean that units are 1024 octets/sec increments?


Comment:
Diagram hard to read.  How does this diagram relate to the previous paragraph?  Where are the terms aCSFrameRepeat and aCSFrameBroadcast in this diagram?  I would like to see their timing relationships.


Comment:
The following sentences do not end in a period: — The address value 0 is reserved for the PNC, for coordinator related transmissions and receptions — The address value of all-ones (0xFF) is reserved for broadcast frames ... — The address value of 0xFD is reserved for multicast frames — The address values of 0xFA, 0xFB or 0xFC are reserved for neighbor piconets


Comment:
The following sentence has an error in punctuation: PNC and the DEV or during the CAP,.


Comment:
The following sentence does not end in a period: The format of the piconet synchronization parameter element shall be formatted as illustrated in Figure 19


Comment:
The following sentence does not end in a period: — 0b11: both authentication and data encryption are required


Comment:
The following sentence does not end in a period: and not all bits in the bitmap


Comment:
The following sentence does not end in a period: The EPS info field shall be formatted as illustrated in Figure 35


Comment:
The following sentence does not end in a period: command shall be formatted as illustrated in Figure 41


Comment:
The following sentence does not end in a period: The authentication request command frame structure shall be formatted as illustrated in Figure 42


Comment:
The following sentence does not end in a period: The authentication response command frame structure shall be formatted as illustrated in Figure 50


Comment:
The following sentence does not end in a period: The challenge response command frame structure shall be formatted as illustrated in Figure 50


Comment:
The following sentence does not end in a period: The request key request command frame structure shall be formatted as illustrated in Figure 50


Comment:
The following sentence does not end in a period: The request key response command frame structure shall be formatted as illustrated in Figure 50


Comment:
The following sentence does not end in a period: The distribute key request command frame structure shall be formatted as illustrated in Figure 50


Comment:
The following sentence does not end in a period: The deauthenticate request command frame structure shall be formatted as illustrated in Figure 50


Comment:
The following sentence does not end in a period: frame structure shall be formatted as illustrated in Figure 50


Comment:
The following sentence does not end in a period: The probe response command frame structure shall be formatted as illustrated in Figure 51


Comment:
The following sentence does not end in a period: The information request field is defined in 7.5.4.1


Comment:
The following sentence does not end in a period: The use of this field for EPS CTRs is described in 8.13.3.4


Comment:
The following sentences do not end in a period: — A value of “4” indicates that the frame is sent by one of the DEVs to the PNC to reject or disconnect the stream — A value of “5” indicates that the frame is sent by the PNC to one of the DEVs to reject or disconnect the stream


Comment:
The security field is a 3-bit field that <TBD>

SuggestedRemedy:
Security is applicable on a piconet basis, not a stream-by-stream basis.  Delete the sentence and the associated bits in figure 76 (b4-b6).  Reassign the bits as reserved and move the other bits foward so that the reserved bits are contiguous.


Comment:
Some of the commands have the settings specified for the MAC header fields, while other commands do not.

SuggestedRemedy:
Add a sentence that says that the MAC header fields are set as appropriate unless otherwise specified.


Comment:
TBD in "The key change bit is reserved for possible security implementation with TBD meaning"

SuggestedRemedy:
This function has been taken over by the key field in the piconet synchronization parameters information element.  Delete the sentence and the key bit (b2) from Figure 31.  Add the bit to the reserved bits.


Comment:
Enumeration items are inclomplete in their description.

SuggestedRemedy:
In a) change "frame control, address " to "frame control, network identification, source address, destination adress "  In d) change "(FCS) which" to "(FCS), if the frame body is non-zero length, which"


Comment:
Requirements are not strong enough for bit ordering.

SuggestedRemedy:
Change "left-most bit is transmitted" to "left-most bit shall be transmitted" in line 26, change "a single octet are sent to" to be "longer than a single octet shall be sent to" in line 31, change "convention and is transmitted" to "convention and shall be transmitted" in line 34 and change "in decimal are coded" to be "in decimal shall be coded" in lin 37.


Comment:
Need a figure to show how the bit ordering is used in the figures that follow.

SuggestedRemedy:
Add the figure once it has been generated and reviewed.  Figure should have multiple fields with LSb and MSb indicated for each of the fields, an indication of the order in which they are sent over the air and an example of a simple command or information element with specific values.


Comment:
The description of the frame control field repeats what is in the figure and therefore is redundant and evil.

SuggestedRemedy:
Change "consists of the ... and repeater" with "is used to identify the type of frame and how it is to be handled."


SuggestedRemedy:
Change "supports will discard" to "supports may discard"


SuggestedRemedy:
Change "is set to" to be "shall be set to" in 2 places in each 7.2.1.5, 7.2.1.6, 7.2.1.7, 7.2.1.10 and one place in 7.2.1.9


Comment:
No multicast capabilities have been defined for this standard.  There is no way to create or join multicast groups.  Delete all references to multicast addresses (this is one of the first).

SuggestedRemedy:
Delete the itemization point "- the address value of 0xFD is reserved for multicast frames." and change the neighbor PNC addresses to be one more (i.e. 0xFB, 0xFC and 0xFD).


SuggestedRemedy:
Change "is set to zero, and ignored upon reception," to be "shall be set to zero on transmission and shall be ignored upon reception "


SuggestedRemedy:
Change "... and priority." to be "... and priority and shall be formatted as illustrated in Fig. 13."


Comment:
Security information is no longer included as separate data, delete this reference.

SuggestedRemedy:
Delete ", including the security information if any"


SuggestedRemedy:
Change "The FCS is calculated" to be "The FCS shall be calculated" on line 43 and "The FCS field is transmitted" to be "The FCS field shall be transmitted"


Comment:
Informal language.  Also, shouldn't all implementations initiallize the the HCS remainder to the same number?

SuggestedRemedy:
Delete "As a typical implementation, " and change "division is preset" to be "division shall be preset" in line 1 and change "remainder is preset" to be "remainder shall be preset" in line 5


Comment:
The channel time allocations are required in every beacon.  Also, the DEV GTS status is not indicated as an allowed element in the beacon.

SuggestedRemedy:
Change "As needed" to "In every beacon" for channel time allocation in table 60.  Also, add a row at the bottom of Table 60 that is "DEV GTS Status" "7.4.12" "Indicates if a DEV's GTSs have changed" "As needed"


Comment:
Not all commands are allowed to be chained together.  Some shall be sent individually

SuggestedRemedy:
Insert the following sentence after "... as shown in Figure 15."  The following commands shall be sent in a command frame that contains only the command: alternate PNC announcement, new PNC announcement, association request, disassociation request.


Comment:
The transmit power change is a command, not an information element and has already been moved to the appropriate location in the draft.

SuggestedRemedy:
Update tables 63 and 65 by moving the transmit power change command from 63 to 65.  Renumber the information element ID's and command ID's as necessary.


Comment:
The CAP duration is not the time offset from the start of the beacon to the start of the CFP.

SuggestedRemedy:
Change "The same value is used as the time offset" to "The same value is used to calculate the time offset"


Comment:
The piconet synchronization parameters element does not include the guard time.  The TG had agreed to use a constant guard time broadcast by the PNC to account for differences in the clocks of the DEVs participating in the piconet.  This addition was held off on the chance that the CTAs would have both start and stop times.  Since they do not, we need to add guard time back in.

SuggestedRemedy:
Add a 2 octet element to the end of the piconet synchronization parameters element that indicates the piconet guard time in microseconds, 0-65536 us.  Also need to add to clause 8 the use of the guard time with the CFP.


Comment:
The PNC Des-mode description is incorrect.

SuggestedRemedy:
Change the definition to match what is now in clause 8, the new definitions chould read:  The PNC Des-Mode is the designated mode of the DEV.  This bit shall be set to 1 if it is desired that the DEV be the PNC of the piconet and the AC bit is set to 1.  Otherwise this bit shall be set to 0.


Comment:
All occurances of Kus were to be changed to milliseconds, but some were missed.

SuggestedRemedy:
Change all occurances (there are 2 on 104 and more follow in clause 7) of Kus to milliseconds


Comment:
The description of piconet maximum transmit power is incorrect.

SuggestedRemedy:
Change "... communicate the transmit power control (TPC) capabilities of a DEV." to be "... communicate the maximum power allowed by the PNC as described in 8.14.1"


Comment:
Delete reserved field, elements can be defined as odd lengths, the protocol automatically pads them to even numbers of octets.

SuggestedRemedy:
Delete the field "Reserved" and change the length of the element to 1


Comment:
Change the label "Slot Start time or SFNext" to be "slot location" since that is how it is referenced in the definitions.


Comment:
Multicast capabilities are not defined for this protocol.

SuggestedRemedy:
Delete the sentence "The destination address may include group or multicast destinations."

Response:
PROPOSED REJECT.  Add a paragraph in clause 8 that defines the scope and intention of multicast in this draft. 8.6.1 is the target clause. WMS to write text. In this clause change 'group' to 'broadcast'.


Comment:
Informal language used to define characteristics.

SuggestedRemedy:
Change "this field is set to 2." to be "this field shall be set to 2." and change "the field is set to 1" to be "the field shall be set to 1" and change "the field will be set to 0" to be "the field shall be set to 0"


Comment:
Informal language to describe the characterisitcs of EPS status

SuggestedRemedy:
Change "A value of 1 is set" to be "The value shall be set to 1" and change "A value of 0 is set" to be "The value shall be set to 0"


Comment:
The restrictions on negotiating theuse of the ASIE is too restrictive.

SuggestedRemedy:
Delete " using a standard a GTS or CFP message exchange" since the negotiation is outside of the scope of the standard.


Comment:
The restriction on transmitting command frames is too restrictive.  It would not allow an unassociated DEV to associate.

SuggestedRemedy:
Change "No command ... within a piconet." to be "Other than the association request, association response, alternate PNC selection command and new PNC announcement command, no command frame shall be transmitted to or by and unassociated DEV within a piconet."


Comment:
There are no more directed frames in the PNC selection process, so the ACK policy shall always be No-ACK.  In addition, the stream control field should be set to 0 in these commands.

SuggestedRemedy:
Change "set to request ... zero." to be "set to No-ACK."  Change "frame control field of the MAC header" to be "frame control field and the stream control field of the MAC header"


Comment:
Directed frames are no longer used in the PNC selection process.

SuggestedRemedy:
Change the sentences "The DA is set to the ... upon reception." to read "The DA is set to the broadcast address." (i.e. change first sentence and delete the two that follow).


Comment:
Reserved fields are no longer used in the commands or information elements.

SuggestedRemedy:
Delete the reserved field and move the 3 1 byte fields to the end of the command so that the other fields end on 2 byte boundaries.


Comment:
The alternate PNC pullout command was deleted from the functional description a couple of revisions ago.  This command is no longer used.

SuggestedRemedy:
Delete the entire sub-clause 7.5.1.2 and all other references to the command in the draft, especially in Table 65, renumbering as necessary.


Comment:
The new PNC announcement command doesn't need to use all of the bytes in the other PNC commands.  It really only needs the new beacon timeout parameter.

SuggestedRemedy:
Add to the text, following "as PNC in the piconet." on line 52 with "This command is also used at the end of a PNC handover by the new PNC of the piconet to signal the end of PNC handover. The new PNC announcement command shall be formatted as illustrated in Figure 38."   Octets: 2      2               2  Type       Length (=2)  New beacon timeout Figure 38 -- New PNC announcement frame body  (delete old paragraph beginning "At the end of ... hand over." and change the paragraph "The CSTimeout ... in the channel." to read as follows:)  "The new beacon timeout field indicates the time offset in milliseconds before which the first beacon shall be sent by the winning AC, in the case of PNC selection, or by the new PNC, in the case of PNC handover."


Comment:
The PNC handover command has unnecessary items in the frame format and adds a redundant and therefore evil definition of how the frame will be used.

SuggestedRemedy:
Change "The PNC shall use this command" to be "The PNC uses this command" and delete the following fields from both the frame format and the definitions that follow:  superframe duration - every DEV associated with the piconet is required to know this anyway. PNC device ID - every DEV knows this from the beacon. AC device ID - The DEV already knows its own device ID  Change the command length from 18 to 4 octets.


Comment:
Need to add a definition of the stream control field (0x00).  Best place to put this is 7.5 since all commands are non-stream data.  Also need to delete the redundant and therefore evil definition of what goes in the PNID field (that is defined much earlier, 7.2.2)

SuggestedRemedy:
Add the sentence to 7.5 at the end of the first paragraph, "All commands shall have the stream index field in the MAC header set to 0x00 and shall be ignored upon reception."  Delete the sentence "The PNID values ... to associate."


Comment:
A DEV that fails ATP will not neccessarily re-associate and so the PNC should not expect that to happen.  The PNC does not need to expect anything.

SuggestedRemedy:
Change "the DEV and expect the DEV to associate again." to be "the DEV."


Comment:
The ACK policy for the association response command is defined in three places and therefore is evil.

SuggestedRemedy:
Delete the sentence "Hence this command shall not be ACKed"  Also delete "If there is a match, ... future communications." on line 48 since this is already defined in clause 8.


Comment:
The condition code "DEV wishes to disassociate" is not possible in the PNC's response.  However, we do not have a code for when the PNC does not wish to allow neighbor piconets.

SuggestedRemedy:
Change reason code 5 from "DEV wishes to disassociate" to "Neighbor piconet not allowed"


Comment:
Reason code 0 and 2 are not well defined.  There is no way for the PNC to know 2, unless it monitors all GTSs.  Compliant DEVs are not allowed to overshoot their allocated channel time.

SuggestedRemedy:
Change reason code 0 to read "ATP has expired, DEV needs to re-associate".  Delete reason code 2 and re-number the reason codes.  As an alternative, perhaps allow reason code 2 to be "PNC unable to service DEV" as a catch-all for any problems the PNC might encounter.


Comment:
The definition of the role of the PNC as PSM redundant and is therefore an abomination to the technical editor.

SuggestedRemedy:
Delete the two sentences "In all cases ...maager in a piconet."


Comment:
Move the Authentication timeout field to be prior to AuthenticationInfo in the command format so that the variable field is last.


Comment:
Move the AuthenticateFailueTimeout to be the first field so that the variable length field is last in the command format.


Comment:
Change the order of the fields so that the variable length field is last, in particular put the DistributeKeyFailureTimeout as the first field following the length field.


Comment:
The stream control field should be defined once for all commands in 7.5 (as indicated in an earlier comment).  Hence it should be deleted from this location.  Redundancy is evil.  This sentence also occurs in 7.5.4.2 and should be deleted from there as well.

SuggestedRemedy:
Delete the sentence "The stream control ... ignored upon reception." which ends on the top of the next page.  Also delete the sentence "The stream control .. ignored upon reception." on page 120, line 33, sub-clause 7.5.4.2.


Comment:
Clarify what is the purpose of the information elements field.

SuggestedRemedy:
Change "information elements, described in 7.4." to be "information elements, 7.4, about the source DEV that is being provided to the destination DEV."


Comment:
The information request field is not used in the probe response command.

SuggestedRemedy:
Delete the field from figure 51 and the sentence referencng it on line 44.


Comment:
The repeater services request command has incorrect fields and fields that are not needed.  The PNC will repeat all communications between the two DEVs and it knows all of the CTRB's that have been allowed between the two.  Also, the device ID should not be used, but rather the AD-AD.  Since this is used for the repeater service grant command, adopting this change will require changes in 7.5.6.2 as well.

SuggestedRemedy:
Change the destination device ID field to be the destination AD-AD field and change the definition from "The destination device ID is the 48 bit IEEE 802 address" to be "The destination AD-AD is the addresss".  Change the length of this field to 2 octets.  Delete all of the CTRBs from the figure.  Delete the sentences "The format of channel time ... destination device ID."  Change the command length to be 2  In 7.5.6.2, change "The destination device ID is that" to be "The destination AD-AD is that"  Delete the sentences "The format of channel time ... repeater service."


Comment:
The last sentence defines functional requirements that are already defined in clause 8.  The redundant definition is therefore evil and shall be exorcised.

SuggestedRemedy:
Move the sentence "If the DEV ... next becomes available" to clause 8.11 or delete the sentence.


Comment:
The AD-AD should be used instead of the destination device ID.

SuggestedRemedy:
Change "destination device ID" to be "destination AD-AD" in the table and in one place in each of the two paragraphs that follow the figure.  Change the field size to 2 octets and the command size to 3 octets.


Comment:
There is a redundant and therefore evil definition of functional requirements in this frame format section.

SuggestedRemedy:
Delete the sentence "When and EPS set is .. for that EPS set." since this requirement is already in clause 8.


Comment:
Again, there is a redundant and evil inclusion of functional description in the frame formats clause.

SuggestedRemedy:
Delete the sentence "When an EPS set is confirmed ... for that EPS set."


Comment:
The sentences "Each DEV in the piconet  using either EPS or RPS modes ... as is the priority information." adds no useful information about the frame format.  The first sentence is incomplete and is a functional definition that is already in clause 8. (redundancy = evil) The fact that mode and priority are provided is obvious from the frame format.


Comment:
The DEV to PNC PS command shall only be sent by associated devices and therefore shall not be sent during the association process.  Heck, it can't be sent before the DEV is associated since it doesn't know its AD-AD yet.

SuggestedRemedy:
Change the sentence "The command ... requirements change" to be "The command may be repeated while a DEV is associated in the piconet if the DEV requirements change."


Comment:
The structure of the command is not stated in formal language (missed in the last update).

SuggestedRemedy:
Change the sentences "The structure of the ... DEV.  The use is to instruct" to be "The switch to EPS CTA mode command shall be formatted as illustrated in Figure 60.  The command is used to instruct"


Comment:
A DEV should not be able to force other DEVs to sleep.  Thus, the swich to EPS CTA should only apply to the DEV that is sending the command.  The PNC already knows which CTAs to change from the information that was given when the CTAs were set up.

SuggestedRemedy:
Delete the sentences "Additional destination... for self sleep only."  Delete the field "Destination DEV addresses" from the figure and change the command length to 0.  Delete the sentence "The destination DEV ... to EPS mode." on line 30.


Comment:
The command format is specified in formal language (missed in the last round of updates).

SuggestedRemedy:
Change "The structure ... as illustrated in Figure 61." to "The momentary EPS CTA command shall be formatted as illustrated in Figure 61."


Comment:
The first sentence is a redundant (aka evil) definition of the functional use of the device information request command that already is in clause 8.  Also, the AD-AD should be used instead of the device ID

SuggestedRemedy:
Delete the sentence "Only a DEV shall send the device information request command."  Change "device ID" to be "AD-AD" in the figure, change the field length to 2 and the command length to 2.  Change "The queried device ID is the device ID" to be "The queried AD-AD is the address" on line 14.


Comment:
The command structure is not indicated in formal language.  In addition, the introductory paragraph gives a redundant and therefore evil functional description in the frame formats clause that belongs the functional description clause.

SuggestedRemedy:
Replace the sentences "Only the PNC ... all DEVs in the piconet." with "The device information response command shall be formatted as illustrated in Figure 63."


Comment:
This information response command is out of sync with the CTR and stream management commands.  However, there is only one piece of information that is not explicitly given in a regular device information response command, and that is the neighbor PNC device ID.  However, this is returned if a DEV requests the device information of a DEV with a neighbor PNC AD-AD.  DEVs know when there is a neighbor piconet because of the AD-AD in the CTA blocks in the beacon.  Likewise, a private GTS of an associated DEV indicates a child piconet.  All of the information in this command is already taken care of with the device information response command.  Thus this command is redundant and should be deleted.

SuggestedRemedy:
Delete sub-clause 7.5.8.3 and all references to the child or neighbor information response command.  If not, the sub-clause needs to be synchronized to use CTRBs like the DEV info response command.  Also needs a "shall be formatted".

Response:
PROPOSED ACCEPT IN PRINCIPLE. Delete sub-clause 7.5.8.3 and all references to the child or neighbor information response command. Also satisfies 696, 695, 694 and 693.


Comment:
Informal language defines the field settings.

SuggestedRemedy:
Change "bits set to 1 indicate" to be "bits shall be set to 1 to indicate" in line 38 and change "bits set to 0 indicate" to be "bits shall be set to 0 to indicate" in line 39.


Comment:
The frame format description contains a redundant (evil) functional description.

SuggestedRemedy:
Delete the sentence "The PNC shal create and retain this EPS CTR based on this request."


Comment:
Need to add clarification for the stream index setting when this command is used to allocate a non-stream CTA.

SuggestedRemedy:
After the paragraph that ends "This field is defined in 7.2.4." add the following:  "For a new channel time request, the stream index shall be 0x00 for this command.  All time requests that are for non-zero stream indices use the stream management command, 7.5.10.3, to initiate the request."


Comment:
Informal language defines the CTA elements.

SuggestedRemedy:
Change "element is defined" to be "element shall be formatted as illustrated in Figure 30 and is defined"


Comment:
The action type requires a 3 bit field, not a 2 bit field.

SuggestedRemedy:
Change the text from "a 2-bit" to "a 3-bit" and re-number the bits accordingly in figure 76


Comment:
Security is not defined on a stream by stream basis, but rather for the piconet as a whole.

SuggestedRemedy:
Delete the security bits in the control information field and delete the sentence "The security field is a 3 bit field that <TBD>.


Comment:
use of word can mean different thing to different people

SuggestedRemedy:
replace "maintain word aligned frames" to "maintain two-octet alignment of the frames"


Comment:
Retry bit: This bit is unnecessary since the MAC will have to check for seq-number in the rx-frame to detect duplicates anyway.

SuggestedRemedy:
Remove "retry bit" from frame control field and mark its current position as reserved for future use

Response:
PROPOSED ACCEPT IN PRINCIPLE.  Delete 7.2.1.7 and xrefs to it. Update table 61, 62, and other occurrances in the text. Delete the sentence "The frames received . . . Desitination DEV." on page 121, line 49, section 7.5.4.4.


Comment:
add a line describing the situation of SEC bit being set to '0'. otherwise it might be interpreted to be undefinde behavior.

SuggestedRemedy:
When SEC bit is set 0 the frame body shall not be encrypted.


Comment:
Reserve 0xF0 to 0xF9 for future use: We never know what else we'll need special addresses for.


Comment:
In clause 8, it is mandated that isoch data shall always be streams. But here it seems to say it is upto DEV.

SuggestedRemedy:
Remove "or isochronous" in line 8 and add "All isochronous data transfers shall be streams"

Response:
PROPOSED ACCEPT IN PRINCIPLE. Remove the sentence "The use of . . . Up to the DEV." in 7.2.4, page 97, line 7.


Comment:
Is Transmit power change an info-element or command? it is listed in Table-63 on page 101, but described as a command in 7.5.5.1. In addition 8.14.2 references this as a command

SuggestedRemedy:
Move Transmit power change from Table-63 to Table-65


Comment:
Is Transmit power change an info-element or command? it is listed in Table-63 on page 101, but described as a command in 7.5.5.1. In addition 8.14.2 references this as a command. the descrription in 7.5.5.1 describes this as an info-element

SuggestedRemedy:
Chnage the description in 7.5.5.1 from info-element to command


Comment:
Why should PNC increment and publish DEK? if the key is changed the key-distribution scheme should make sure all the relavant DEVs in the pcionet are informed before the change. Moreover, keys must be per-link and not global per piconet.

SuggestedRemedy:
Remove Key number from Figure-19 and all references to it from the draft


Comment:
Supported rates in 11.7 presents less than one octet encoding to indicate the support for multiple rates.

SuggestedRemedy:
Change "supported rates" field in figure-25 from (1-8) octet(s) to 1-octet.


Comment:
Use of OID is confusing as the same term is used for the first 3-octets of IEEE MAC addresses.

SuggestedRemedy:
Pick a new name for OID in this subclause and at all places referencing to it in the draft


Comment:
Given that there can be different guard-band between GTS and between CFP and CAP depending on PHY type and network conditions, it is a good idea to let the PNC account for it when allocating the channel time. To enable that degree of freedom at PNC we need "Slot-duration" in CTA-block in figure-30

SuggestedRemedy:
Add a two-octet long Slot-duration field in figure-30 (and text in clause 7.4.10) with the resolution of this field being 8-microsec.

Response:
PROPOSED ACCEPT IN PRINCIPLE. WMS will provide text that implements the slot duration and account for the possibility of fragmenting the beacon or why not to fragment. In accordance with any guard time impact. Due by February 12.


SuggestedRemedy:
remove "key change" field from figure-31 and mark b2 as reserved.

Response:
PROPOSED ACCEPT IN PRINCIPLE.  Change is indicated in 296.


Comment:
Definition of SFNext is better suited to be later in the sub-clause

SuggestedRemedy:
1. move lines 27:31 on page 107 to be starting right after the current line number 44 on the same page. 2. change "as the SFNext" on line 26, page 107 to "as the SFNext, which is defined later in this clause" 3. reference the place of definition for EPSNext at its first use (at current line #30, page 107) 4. change the second occurrence of "set to 0" on line 34, page 107 to "set to 1" 5. remove line 36 6. Use of "slot location field" in lines 37:43 on page 107, without its definition. Actually its name is different in figure-30.


Comment:
Use of "guard time" without defining it. Beacon does not contain it.

SuggestedRemedy:
Remove line-46 and all references to "guard time" in the draft. However state in clause 8.4.3.2, add a paragraph describing the need for guard time and how PNC is expected to take that into account while allocating the channel time.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Add slot duration to take care of guard time. Remove guard time at this point. Add section that defines guard time required for receivers to start listening in time to receive. WMS is providing text.


Comment:
Lack of examples to MaxAssignedCTAs and MaxProcessedCTAs make the readers think they are same.

SuggestedRemedy:
Add examples to clearly state the differences and relation between MaxAssignedCTAs and MaxProcessedCTAs.


Comment:
line-37 claims that the "element" itself is 256 bit bitmap where as figure-33 has 8-octets (64 bits) of bitmap as a field of the element. If DEV is required to look at CTAs in the worst case what savings is envisioned by this element that reduces the complexity of an implementation. At best this adds complexity to the implementation in checking these bits and then checking the GTS AND it adds to the overhead in the beacon. Beside that, having read EPS several times now, I am not convinced about the justification to add this complex mechanism in to the MAC. Later comments will detail more on this opinion.

SuggestedRemedy:
Remove DEV GTS status element and all references to it from the draft.

Response:
PROPOSED REJECT. The committee feels that there is potentially an advantage to preserving the DEV GTS functionality.


Comment:
1. Figure-34 is inconsistent in "length" field and the contents of the element 2. Nowhere in the draft I see the text describing how this is set at PNC and how it is used at DEVs. 3. on lines 35:36: If EPS device is asleep how does it make use of this info? if this is for other DEVs, how is it useful. 4. What is the guarantee that DEVs always get EPS status of another DEV through beacon? Why not use a simple mechanism wherein a DEV can tell the PNC that it is going to be asleep and hence not allocate GTS with the current DEV in question as the recipient? What is the justification for the complexity of this mechansism that is being thrusted upon implementors?

SuggestedRemedy:
Simplify "power management parameters" to have just the list of Device addresses of those DEVs that are currently asleep. no other field is needed as the receiving DEVs know that if an address is present in this list, that device is asleep.


SuggestedRemedy:
Figure 36: mark the length of variable field (app-specific data) as 'n' and note in the Length field that the length is equal to 'n+1'


Comment:
For ease of understanding and implementation (use of clean ifs and elses), there is a need to reorder the command-type value to a given command.

SuggestedRemedy:
Move the association related commands to the top to start from value 0x0000, followed by authentication commands.


Comment:
Ordering the subclauses for commands to be in the same order as the order of commands in Table-65 is very helpful

SuggestedRemedy:
Reorder the subclauses describing the individual commands to be in the same order as their appearence in Table-65


Comment:
Just the number of commands, fields/subfields in information elements makes one wonder why power management has to be this complex. Why not simple commands like (a) sleep-time-request from DEV to PNC (b) sleep-time-grant/reject from PNC to DEV? What is not being acheived in those simple commands that is being achieved by this complex mechanism? What is the justification to add this complex mechanism to a draft that is supposed to spec a low-cost, low-power PAN implementation?

SuggestedRemedy:
Remove all the power management commands and all the references to them from the draft. Simplify power management to the following - Request for sleep time by DEV - Accept/Reject by PNC - Broadcast the addresses of sleeping DEV in Beacon - Allocation/modification of GTS by PNC depending on who is awake


SuggestedRemedy:
1. 7.5.1.1, 7.5.1.2 and 7.5.1.3 describe them as "action types". change the description to "commands" 2. these subclause must refer to figure-37 for command structure 3. Change the caption of figure-37 to "PNC selection commands format"


Comment:
Use of "commands frame body chall be formatted ..."  is wrong. Command is not a frame by itself, but some command frames may have only one command in them (along with MAC header, FCS etc.)

SuggestedRemedy:
Change all occurrences of "command frame body shall be formatted .." to means the following 1. Command structure is shown in figure-xx (no change in reference) 2. A frame containing certain commands like association, disassocition, authenticatio, deauthentication shall not contain any other commands. It shall be the sole command present in a command frame.


Comment:
Use of redundant fields that increase the overhead and lead to inconsistencies in the implementation

SuggestedRemedy:
1. remove PublicKeyObjectLength in figure-42 2. remove AuthenticationInfoLength in figure-43 3. remove PublicKeyChallengeLength in figure-44 4. Remove PublicKeyProofLength in figure-45 5. remove EncryptedKeyObjectLength in figure-47 6. remove EncryptedKeyObjectLength in figure-48  7. for all the above add one line each as to the formula to derive those  fields at rx (or use those at tx) from the "Length" field present in the info-element structure.

Response:
PROPOSED ACCEPT. As long as we do not change to all information elements in commands.


Comment:
Probe request and response command types are redundant since their format is exactly same. Define one command with that format "Probe Information" and use it both as request and response

SuggestedRemedy:
Define one command with that format "Probe Information" with the format as in figure-50 and use it both as probe-request and probe-response in the behavior description

Response:
PROPOSED ACCEPT IN PRINCIPLE. Define one command with that format "Probe Information" with the format as in figure-50 and use it both as probe-request and probe-response in the behavior description. Clean up the description of MSB-set for binary coded information identifiers. Ensure that all zero Information Request is only valid for no information being requested. Clean up clause 8.9 that reference probe-request and probe-response.


SuggestedRemedy:
1. expand CTRB 2. replace "channel time" in lines 42 and 43 with CTRB


Comment:
There are 6 different commands for power management and two of them with a different set of multiple action types, totalling 13 different actions. In addition there are different states within EPS such as momentary EPS. Just the listings in Table-66 and Table-67 outpour the complexity involved in the specified power management mechanism. Why not simple commands like (a) sleep-time-request from DEV to PNC (b) sleep-time-grant/reject from PNC to DEV? What is not being acheived in those simple commands that is being achieved by this complex mechanism? What is the justification to add this complex mechanism to a draft that is supposed to spec a low-cost, low-power PAN implementation?


Comment:
This entire section is full of inconsistencies, use of terms never used anywhere in the draft, grammatical mistakes and language not suitable for an 802 standard. Some of them are: 1. what is "self sleep" as used in line 19 page 126 2. why is the sentence in line-19 needed? what is it conveying? 3. Language: one example is lines 16-20 on page-126.

SuggestedRemedy:
I request the editor to read this clause and correct them. I am givingup on listing them as there are just too many to list.


SuggestedRemedy:
Change "Number of TX slots" in the text of 7.5.8.2 and figure-64 to "number of GTS"


Comment:
Stream index is listed in figure-66 but there is no description of what it is?

SuggestedRemedy:
Relate the "Stream index" in figure-66 to the description in lines 36:37 on page 128


SuggestedRemedy:
Inconsistency in the content of length field "n*10". change it is "n*12"


Comment:
Again, the complexity of power management has crept into frame formats of CTRB also. And the PNC must strive to rx and set these values appropriately for all different combinations, while the DEVs strive to produce/consume those bits and act appropriately. Why? Why not a simple mechanism of one command exchange between DEV and PNC to tell whether a DEV is planning to go to sleep? I don;t see any justification for this complexity all around the spec for power management.

SuggestedRemedy:
Remove CTRB type, EPS set and allocation period from figure-72 and all references to those fields from the draft.


Comment:
Minimum GTS time can be reduce to one octet. If the other octet has to be left reserved, so be it since that creates room for future expansion.

SuggestedRemedy:
1. Reduce Minimum GTS time to one octet in figure-72 2.  Make the name of the field and the description uniform with that in figure-66. Better yet, describe at one place and reference it at another to avoid duplication

Response:
PROPOSED ACCEPT IN PRINCIPLE. Minimum GTS Slot time is a value requiring more than 8-bits. The other occurrence in Figure 66 will be removed. All occurrances of Minimum GTS Slot time will be the same size.


Comment:
The complexity of power management has crept into frame formats of channel time grant and stream management also. The PNC must strive to rx and set these values appropriately for all different combinations, while the DEVs strive to produce/consume those bits and act appropriately. Why? Why not a simple mechanism of one command exchange between DEV and PNC to tell whether a DEV is planning to go to sleep? I don't see any justification for this complexity all around the spec for power management.

SuggestedRemedy:
Remove Grant-status(s) from figure-73, remove figure 74 and all references to those fields from the draft. Remove GTS type from figure-76 and all references to that field from the draft.


SuggestedRemedy:
specify a value of '3' to be applicable for "Dest-DEV to PNC" case also.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Add sentence in section 7.5.10.3, page 133, line 29 following "In the response." add "This indicates that the target accepts the stream connection with the parameters indicated."


Comment:
Minimum requested channel time can be reduce to one octet. If the other octet has to be left reserved, so be it since that creates room for future expansion.

SuggestedRemedy:
1. Reduce Minimum requested channel time to one octet in figure-77 and remove the reserved field since the two-octet alignement is acheived by the reduction of size for Minimum requested channel time 2. Make the name of the field and the description uniform with that in figure-66. Better yet, describe at one place and reference it at another to avoid duplication

Response:
PROPOSED ACCEPT IN PRINCIPLE. Minimum Requested Channel time (Minimum GTS Slot) time is a value requiring more than 8-bits. The other occurrence in Figure 66 will be removed. All occurrances of Minimum GTS Slot time will be the same size.

Note that Minimum Requested Channel time changed to Minimum GTS Slot time per comment 529.


Comment:
MAx TX delay variation in figure-77 and MAximum allocation delay in figure-72 are same but have different name and description

SuggestedRemedy:
Make the name of the field and the description uniform between figure-77 and figure-72. Better yet, describe at one place and reference it at another to avoid duplication

Response:
PROPOSED ACCEPT IN PRINCIPLE.  Use the naming and text in Figure 72 and xref Figure 77 to Figure 72. In Figure 77 change:

Inter-time slot duration becomes Allocation period
Minimum … slot becomes Minimum GTS time
Requested … slot becomes Desired GTS time
Max TX delay variation becomes Maximum allocation delay

Text on page 134 and 135 use xref (defined 7.5.10.1) instead of redefining.


Response:
PROPOSED ACCEPT IN PRINCIPLE. Please change to DEVAddress.


Comment:
Alternate PNC announcement command unneeded.


Comment:
Alternate PNC pullout command unneeded given the change in Clause8.2.3 p139 line30-32.


SuggestedRemedy:
Please change to: " An AC uses this frame type to ..."


Comment:
PNC-device-id and AC-device-id parm names are incorrect.

SuggestedRemedy:
please change to PNC-device-address and AC-device-address.  Also rename the parameter names given in the text to describe the figure 38 parms .

Response:
PROPOSED ACCEPT IN PRINCIPLE. please change to PNC-DEVAddress and AC-DEVAddress.  Also rename the parameter names given in the text to describe the figure 38 parms .


SuggestedRemedy:
Please change to DeviceAddress and its related text describing the parm.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Please change to DEVAddress and its related text describing the parm.


Comment:
Device ID and AD-AD parm names are incorrect.

SuggestedRemedy:
Please change to DeviceAddress and DeviceAID.  Also make the necessary text changes in the text describing the parms in this figure.


Comment:
DeviceAID ( aka AD-AD) is mislocated in the figure.

SuggestedRemedy:
Please move DeviceAID to the ReasonCode location in the table and the ReasonCode to the former DeviceAID table location.


Comment:
The DeviceID, ReasonCode, and Reserved fields of the Disassociation request command are unnecessary.

SuggestedRemedy:
Please remove the indicated fields.  Also set the Length parm = 0.

Response:
PROPOSED ACCEPT IN PRINCIPLE.  Leave reason code in the frame.


Comment:
Text between lines 33 and 43 is not needed if the DeviceAddress, ReasonCode, and Reserved fields are deleted.


Comment:
The title of clause 7.5.4.1 Probe request command is incorrect.  This command requests and delivers  specific device information elements and is used to communicate DEV to DEV, DEV to PNC, or PNC to DEV.

SuggestedRemedy:
Please change the clause title to Device Information request command.


Comment:
Text between line 46 and 49 referencing the probe name command is incorrect.

SuggestedRemedy:
Please replace all instances of probe request with device information request.


Comment:
Text between line 1 and 27 referencing the probe name command is incorrect.


Comment:
The title of clause 7.5.4.2 Probe response command is incorrect. This command requests and delivers  specific device information elements and is used to communicate DEV to DEV, DEV to PNC, or PNC to DEV.

SuggestedRemedy:
Please replace all instances of probe response with device information response.


Comment:
The title of clause 7.5.8 Device Information is incorrect.  The commands described under this sub clause are commands requesting PNC information or responding with PNC information.

SuggestedRemedy:
Please change this clause title to: PNC information.


Comment:
The text between lines 50 and 51 is incorrect.

SuggestedRemedy:
Please change the text between lines 50 and 51 to: "This group of commands is used to request information from the PNC or to enable the PNC to respond with information it uses to manage the piconet."


Comment:
The title of clause 7.5.8.1 Device Information request command is incorrect. The purpose of this command is to query the PNC regarding the organized information it uses to manage the piconet.

SuggestedRemedy:
Please change the title of this clause to "Probe PNC request command"


Comment:
The Queried Device ID field is incorrectly named and reserves to many octets.

SuggestedRemedy:
Change the Queried Device ID to Queried Device AID and the length of the field to 1 octet. Since there is no need to pass the MAC address or addresses.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Change the Queried Device ID to Queried DevID and the length of the field to 1 octet. Since there is no need to pass the MAC address or addresses.


Comment:
The text between lines 14 and 15 is incorrect.

SuggestedRemedy:
Please change to: " The queried device AID is the DeviceAID of the DEV whose information is being requested from the PNC. ..."


Comment:
The title of clause 7.5.8.2 Device information response command is incorrect.

SuggestedRemedy:
Please change the title to PNC information response command.


Comment:
The text between lines 19 and 22 is incorrect.

SuggestedRemedy:
Please replace all instances of device information  with PNC information .


SuggestedRemedy:
Please change to PNC information response command format.


Comment:
The AD-AD and Device ID fields are incorrectly named

SuggestedRemedy:
Change the AD-AD field to DeviceAID and the Device ID field to Device Address.  Also change references to these fields at lines 44 and 49.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Change the AD-AD field to DevID and the Device ID field to DEV Address.  Also change references to these fields at lines 44 and 49.


SuggestedRemedy:
Please change the caption to: Format of a record in the PNC information response command.


Comment:
The sentence fragment "... the device information response command,..." is incorrect.

SuggestedRemedy:
Please change the indicated fragment to: "... the PNC information response command,..."

Response:
PROPOSED ACCEPT IN PRINCIPLE. Resolved as in comment 356.


Comment:
The Neighbor PNC Device ID field name is incorrect.

SuggestedRemedy:
Please change the indicated field to: PNC DeviceAddress

Response:
PROPOSED ACCEPT IN PRINCIPLE. Please change the indicated field to: PNC DEVAddress


Comment:
The Channel Time Request fields (Duration between..., Min.requested chnl time, Requested channel time)in figure 66 are not the same as the Channel Time Request fields( Allocation period, Min GTS time, Desired GTS time, Max Allocation delay) in Figure 72.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Resolve as in comment 356.


Comment:
Text between lines 30 and 39 is inconsistent with the text on page 131 between lines26 and 44.

Response:
PROPOSED ACCEPT IN PRINCIPLE. 7.5.8.3 has been deleted.


Comment:
Clauses 7.5.8 through 7.5.8.3 do not belong in the MAC command frame format section of this document. These clauses would be better served being defined as control plane frame formats for the convergence layer defined in the Annex.  The data to be requested is better served being passed as a unitdata payload than as part of a MAC command frame.

SuggestedRemedy:
See document 01469r3 for details regarding resolution to this comment.


Comment:
The Source DEV address and Destination DEV Address fields are incorrectly named and inconsistently located in the figure.

SuggestedRemedy:
Please change the indicated fields to Source DEV AID and Destination DEV AID. Move the Destination DEV AID to the first field and the Source DEV AID to the second field.

Response:
PROPOSED ACCEPT IN PRINCIPLE.   Please change the indicated fields to Source DevID and Destination DevID. Move the Destination DevID to the first field and the Source DevID to the second field.


Comment:
Figure 30 is missing a slot duration field.

SuggestedRemedy:
Please add the slot duration field to figure 30.


Comment:
Missing from the Information elements table are these new information elements:  PicoNet Shutdown and New Associated DEV

SuggestedRemedy:
Please add these information elements to Table 63:  Piconet Shutdown (see info element description in 02/037r0)  New Associated DEV (see info element description in 02/037r0)


Comment:
The Device Identifier info element is misnamed.

SuggestedRemedy:
Please change to Device Address info element

Response:
PROPOSED ACCEPT IN PRINCIPLE.  Please change to DEV Address info element


SuggestedRemedy:
Please change indicated field name to: Device Address and make the necessary change in parameter description following the figure.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Please change indicated field name to: DEV Address and make the necessary change in parameter description following the figure.


Comment:
Probe Request command and Probe response commands are incorrect.  Also the xref in the table are incorrect.

SuggestedRemedy:
Please Rename the indicated commands to Probe-PNC-Request command and Probe-PNC-Response command.


Comment:
Alternate PNC announcement command and Alternate PNC pull out command are not needed.

SuggestedRemedy:
Please remove the indicated commands and their xrefs.


Comment:
The Remote-Scan-Request and Remote-Scan-Response commands are missing from this table.  These commands are needed to fill in a notable missing capability in the Dynamic Channel Selection function.

SuggestedRemedy:
Place the Remote-Scan-Request and Remote-Scan-Response commands into the table entries previously occupied by the deleted Alternate PNC Anouncement and PNC pullout commands.


Comment:
The xrefs for the Device information request and response commands is incorrect.

SuggestedRemedy:
Please have the xref point to the clause previously known as Probe request and response respectively.


Comment:
The power managment frame commands introduce an inordinate amount of complexity into D09. Consequently, they are not needed.

SuggestedRemedy:
Remove from this table all references to EPS action request/response, Swith to Active, Switch to EPS, Momentary EPS


Comment:
The current Power managment commands add an inordinate level of complexity to this protocol to make it unreasonable to implement in a WPAN device. Consequently, they are inappropriate for this protocol.

SuggestedRemedy:
Please remove clauses 7.5.7 through 7.5.7.6.


Comment:
The Channel Time request command is inadequately defined for the functions required of it in this protocol.

SuggestedRemedy:
The Channel Time request command clause in doc 02/037r0 provides detailed resolution to this issue.


Comment:
The Stream managment command is an inordinately complicated frame command for the functions it is needed in this draft.

SuggestedRemedy:
Replace the Stream managment command with the upgraded Channel Time request command described in doc 02/037r0.


Comment:
Element ID should be provided for the IEEE ID of a parent PNC. This will appear (as correctly shown) in Table 60 (refer page 98).  Note: originally, the parent IEEE ID was to be identified by its position as last in the beacon.  However, the ASIE also requests the last position. Therefore, we should declare an element ID for the parent IEEE ID and allow the parent ID to take any position in the beacon.

SuggestedRemedy:
Add element ID 0x0F for Parent PNC IEEE ID and decrement to reserved element IDs by one.  Use the format in Figure 18 (page 102).

Response:
PROPOSED ACCEPT IN PRINCIPLE.  Name it Neighbor PNC DEV Address. Verify that this is the same as adopted for the MLME.


Comment:
'11' is used twice. '16' is not available from a 4 bit field.


Comment:
There was agreement by the meeting to remove this section.


Comment:
Text specifies a 2 bit field, yet there are 6 outcomes (6 values).


Comment:
Text says that GTS or CFP mesaage exchange sets up the application specific capability.  This means that higher protocol layers are involved.  However, I can not find how the DME tells the MAC what information to put in the ASIE element or when to remove the ASIE.


Comment:
Pointing Figure should be 43 insted of 50


Comment:
Pointing Figure should be 44 insted of 50


Comment:
Pointing Figure should be 45 insted of 50


Comment:
Pointing Figure should be 46 insted of 50


Comment:
Pointing Figure should be 47 insted of 50


Comment:
Pointing Figure should be 48 insted of 50


Comment:
Pointing Figure should be 49 insted of 50


SuggestedRemedy:
Add bit 10 in figure 12 and indicate 'reserved', possibly reorder the bits.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Move 11-12 to 10-11 and move bit 14 to bit 12 and make 13-15 reserved.


Comment:
clarify value of frag-start field for frames, which are not fragmented

SuggestedRemedy:
add additional text at the end of the first sentence e.g.: ...start of the current MSDU/MCDU, which consists of multiple fregments.


Comment:
clarify value of frag-end field for frames, which are not fragmented

SuggestedRemedy:
add additional text at the end of the first sentence e.g.: ...end of the current MSDU/MCDU, which consists of multiple fregments.


Comment:
There are address values for neighbor piconets, but not for child piconets.

SuggestedRemedy:
Add address values for child piconets, if required.


SuggestedRemedy:
replace 'within command frame' by 'within a command frame'


SuggestedRemedy:
replace 'shall the number' by 'shall indicate the number'


SuggestedRemedy:
replace 'sent in either in' by 'sent either in'


Comment:
there is a bit for 'Neighbor PNC', but not for 'Child PNC'


SuggestedRemedy:
replace 'if DEV is intends to be' by  'if DEV intends to be'


Comment:
wrong sentence above figure 28 (correct description below figure 28)

SuggestedRemedy:
Delete wrong sentence about TPC capabilities of a DEV.


Comment:
Align text in Figure 30 with text on next page.

SuggestedRemedy:
Last field should be called 'slot location field'


SuggestedRemedy:
correct text to: ... shall be set to 1 if they are in EPS mode.


Comment:
wrong octet number and length (256 bits = 32 octets)


Comment:
Add possibility for reject, without giving a detailed reason

Response:
PROPOSED ACCEPT IN PRINCIPLE. Add "request denied, no reason given" as a possible reason code.


SuggestedRemedy:
replace 'Channel is servere ..' by  'Channel is too servere ..'


Comment:
Include the possibility for authentication of the PNC in the authentication request.

SuggestedRemedy:
Include the 'Public Key Challenge' as optional information in the authentication request command.


SuggestedRemedy:
Move sentence in line 18 up to be directly below Figure 42.


SuggestedRemedy:
Include the 'Public Key Proof' as conditional information in the authentication response command.


Comment:
To avoid confusion the term 'cipher suite' should only be used for the privacy service (encryption, ciphering).

SuggestedRemedy:
replace 'cipher suite' by 'authentication algorithm'


Comment:
could not find the details of the cipher suite list


Comment:
'transmit power change' is an element and not a command


SuggestedRemedy:
replace 'action request command' by 'action response command'


SuggestedRemedy:
Delete 'To indicate to the PNC' or clarify what is indicated to the PNC.


SuggestedRemedy:
replace 'same response rules a the device' with 'same response rules as the device'


SuggestedRemedy:
replace at the end of line 23: '9' by '12' correct in Figure 71: Length(n*12)


SuggestedRemedy:
at the beginning of line 12 delete 'the PNC it'


SuggestedRemedy:
Correct number of octets for 'Stream QoS parameters' to '23' Correct: Length(=29) Use either 'stream request identifier' or 'stream request index' in the Figure 75 AND the text below (line 51)

Response:
PROPOSED ACCEPT IN PRINCIPLE. Change 23 to 22 in Figure 75. Move MaxReTXVariation up to below the MaxTXDelayVariation replacing the reserved field in Figure 77. Change the text to be "stream request identifier". Change 26 to 28 for Length.


Comment:
For Action Type more than 2 bits are required


Comment:
Immediate acknowledgement can be indicated in the ACK-policy field. Therefore the frame type 'Immediate acknowledgement' is redundant.

SuggestedRemedy:
If ACK-policy field is used to indicate 'immediate acknowledgement' than the frame type 'Immediate acknowledgement' may be removed.


Comment:
Each command has its own defined structure. This requires to store all the command structures.

SuggestedRemedy:
A command should only contain 'information elements', e.g. all the commands that now contain an 'Device ID'-field should instead contain the 'Device identifier' information element. This requires the definition of additional information elements, e.g. 'Key object', 'Authentication info', 'Key challenge', 'Key proof', 'Reason/Result', 'Timeout'.


Comment:
grammatical ... remove the comma after the word frame


Comment:
Incomplete specification for usage of distribute key request

SuggestedRemedy:
Clause 10 needs detail on usage and specs for distribute key request - security subcommittee.


SuggestedRemedy:
security subcommittee needs to provide details on DistributeKeyFailureTimeout in clause 10


SuggestedRemedy:
Security subcommittee to provide details on Deauthenticate Request command in clause 10


SuggestedRemedy:
Security subcommittee to review the command of figure 49 ... seems it is incomplete.  Is this all there is to this command?  Need reason codes?


SuggestedRemedy:
From Table 63, there are exactly 15 defined commands to date with 241 element IDs reserved for future use.  Yet, in the informatioin request field of the probe request commmand we only have room for 16 commands.  Increase to 3 octets to allow some growth or get rid of the extra 241 element IDs.  If this is done then in line 12, replace 15 bits with 23 bits.


SuggestedRemedy:
... request field corresponds to the information ...


Comment:
So how is the MSB of the information request filed mapped (ref. Figure 50)?  Suggestion below.


SuggestedRemedy:
... DEV in the piconet to any other DEV ...


Comment:
Question to PHY subcommittee about which directed frames should be counted.

SuggestedRemedy:
Is it that we should only count frames from the probe response source?


SuggestedRemedy:
0x08  By the way, why is this information element sitting in the middle of the commands.  Should it be moved over with the other information element types?


SuggestedRemedy:
0x0006 = Repeater service request command 0x0007 = Repeater service grant command


SuggestedRemedy:
This clause should be rewritten so that during the repeater operation the up/down channel being repeated by the PNC is symmetric (in terms of passed data frames) so that the PNC does not have to do any buffering when providing the repeater service.  This means the slowest PNC link (up or down) will determine the speed of the corresponding matching link.


SuggestedRemedy:
word should be "handover" and not "hand over"


SuggestedRemedy:
0x0015 = EPS action request 0x0016 = EPS action response


SuggestedRemedy:
Instead of saying "place in set" how about instead "add to set".  Make a universal replacement.


SuggestedRemedy:
... beacon number as defined in the piconet synchronization ...


SuggestedRemedy:
The current beacon number, as received by the DME, is used to calculate the beacon number for the next EPSTime event; that is, it is inserted into EPSNext field of the EPS action request command.


Comment:
grammatical ... rewrite sentence as shown below.

SuggestedRemedy:
The command shall be sent prior to the corresponding channel time request command.


SuggestedRemedy:
... DEV addresses operating with the same EPS ...


SuggestedRemedy:
Power management committee needs to supply definition of what a "self wake" is ... I don't understand what is being implied here.


SuggestedRemedy:
... DEV addresses operating with the same


SuggestedRemedy:
Ask power management guys what self sleep is ... I don't understand.


Comment:
The sentence says that the EPS CTR is contained within the EPS CTA.

SuggestedRemedy:
The EPS CTR is NOT contained within the EPS CTA.  Clarify what is intended here.  (power management subcommittee)


Comment:
The sentence beginning with "If the wave beacon ..." is poorly written and I don't understand.

SuggestedRemedy:
Please have power management subcommittee rewrite the sentence to clarify the text.


Comment:
Line 49 says, "The device ID is for the DEV whose allocations are given in the record".


Comment:
Line 54 says, "The number of TX slots is the number of allocated transmission lsots for the DEV within each superframe".


SuggestedRemedy:
Suggest in Figure 66 we make the "duration between time slots" a 2 octet field which whould give a resolution of 4 uS.


SuggestedRemedy:
... 1-octet field that identifies the stream of the ...


SuggestedRemedy:
... field that identifies the stream that is ...


SuggestedRemedy:
octets corresponds to a channel time ...


Comment:
grammatical ... at the end of the sentence strike out the words "format of a" as shown below

SuggestedRemedy:
... with the target DEV.  The channel time request block ...


SuggestedRemedy:
There is something wrong at the end of the sentence that lies between lines 8 and 12.  Since I'm having trouble understanding the EPS mode I don't want to guess at the fix.  Have the power management subgroup fix this sentence.


SuggestedRemedy:
... shall be a member of the EPS set before ...


Comment:
The line on 26 seems to indicate that the CTRB type field indicates a request for the EPS mode; however, in the paragraph starting at line 8 we saw that a device in EPS could have CTRB=0 or 1 ... so how can the CTRB field alone indicate the EPS mode?

SuggestedRemedy:
Have power management subcommittee clarify line 26.


Comment:
Restructure sentence assuming the technical comment is correct

SuggestedRemedy:
It appears thta CTRB=0 indicates the active mode ... is this correct?  If so then rewrite the sentence of line 31 as  If the CTRB type field is zero, the allocation period is for an ACTIVE ...  (i.e. delete the word "otherwise")


SuggestedRemedy:
Figure 75 shows this field as being 20 octets wide but adding up the octets in Figure 77 we get 23 octets.  Which width is correct?  Assign to MAC subcommittee.


Comment:
grammatical ... missing left bracket on Del-ACK


SuggestedRemedy:
replace the 4th word in line 51 (index) with the word "identifier"


Comment:
Figure 77 lists the QoS parameters but it doesn't implicitly show which order the parameters are sent.

SuggestedRemedy:
Add a figure that shows how to put the QoS VECTOR together and where are the MSBs.


Comment:
In line 18 ... in the middle of the sentence is the word "over" ... would a better word be "after"

SuggestedRemedy:
... the time, in Kus, after which the retransmission ...  Review by MAC people.


Comment:
When a DEV who wants to use EPS (the slave) asks the PNC to form an EPS set with a particular DEV who will be the "master", how does the "master" DEV get informed that he is now member of an EPS master/slave set?

SuggestedRemedy:
I'm having trouble following how all this works so I need the power management folks to help me on this one.  Refer to power management folks.


Comment:
The frame header structure is not described clearly, the CRC type of HCS should be specified, and a correction made to the specification of the FCS CRC designation.

SuggestedRemedy:
Rewrite as follows:  a) A frame header that includes the PHY header and the MAC header. The MAC header comprises frame control, ...,traffic category informantion. b) A fixed length header check sequence (HCS), which contains an IEEE 16-bit cyclic redundncy code CRC-16) for the frame header. c) ...  d) ... code(CRC-32).


Comment:
CTA type specified the same for ACTIVE and EPS modes

SuggestedRemedy:
Change to:  ... and shall be set to 1 if they are in EPS mode.


Comment:
Line in table says AWAKE rather than WAKE, and does not indicate that there is a GTS slot.

SuggestedRemedy:
Change entry to:  EPS CTA, WAKE superframe w/ GTS


Comment:
1. The stream QoS parameters field of the stream management command, connection request cause the generation of GTS slots specified by a subset of the QoS parameters.  The channel time request command specifies GTS slots using the CTRB shown in 7.7.5.10.1.  The corresponding parameters are named differently and defined differently, obfuscating their equivalency.   2. The CTA Type and EPS set parameter are missing in the QoS specification and are required to assign a stream to and EPS CTA.

SuggestedRemedy:
Change QoS parameters to match CTRB parameters as follows: inter slot duration --> allocation period Min. time per slot --> Min GTS time Max. time per slot --> Desired GTS time Max Tx delay variation  --> Maximum allocation delay  Add the following QoS parameters before the allocation period EPS Type, 1 octet EPS Set, 1 octet


SuggestedRemedy:
change "stream request index" to stream request identifier


Comment:
This will tie into a proposed change to the text in 8.6. The stream connection process involves communication between the PNC and each of the two peers (originaor of the stream connection request and the target) destined to use the stream.  The stream connection process involves the PNC to determine if it can provide the GTS slot allocation requested, and the two peers must agree on a set of QoS parameters.  As currently proposed the communication flow is Originator->PNC->Target->PNC->Originator. The originator will then reply to only to the PNC if it rejects the Targets modified QoS values. The trigger for PNC generation of time slots should be a response from the Target to the PNC confirming acceptance of the final QoS parameters relayed from the Target.

SuggestedRemedy:
At line 36 add the following text to create a final confirmation or acceptance of the stream connection which is the trigger to the PNC to begin creating GTS: -- A value of "6" indicates that the frame is sent by the originator DEV to the PNC as a final confirmation or acceptance of the steam connecton.


SuggestedRemedy:
must be removed or replaced with spec. I ask guidance from the security subcommittee members.


SuggestedRemedy:
Change to 3 bits, 0 - 2 in Figure 76 and change line 20 from "2-bit" to 3-bit


Comment:
The current text allows for changing an ACTIVE CTA to an EPS CTA or vice versa.  This should not be allowed to simplify the PNC.

SuggestedRemedy:
Add the following text after the end of the sentence:  A channel time request for an exitsting stream shall not change an ACTIVE CTA to an EPS CTA, nor vice versa. A channel time request for an existing stream may modify the persistence of an ACTIVE CTA.


SuggestedRemedy:
In the sentence at line 41, a statement is made "When an EPS set is confirmed as created ...".  Add in this sentence reference to the clause in the text which describes how EPS sets are created.  I need help from the power management folk on this one.


SuggestedRemedy:
In table 67, add 9th action type value ...  Power Saving Modes Not Supported ... 9


Comment:
Add to the exisiting sentence ending at line 23 the following:

SuggestedRemedy:
If the EPS action response type is #9 (power savings mode not supported) then the DEV to PNC PS information command shall not be sent by a DEV.


SuggestedRemedy:
How does a DEV desiring RPS mode operation notify the PNC of this desire?  Does it just send the DEV to PNC PS informaiton command?  Does it have to first send a EPS action request command?  I am confused.  Please clarify and then I can generate text to prevent future readers from being confused also.


Comment:
request key response command dosen't sound right.


Comment:
Since there is no Distribute Key Response command, this can just be distribute Key command.


Comment:
Not sure what the deauthenticate request command does.  It does not appear aywhere in the text except in clause 6 and 7.5.3.8.  If PNC is going to deauthenticate a DEV, why not just disassociate it.

SuggestedRemedy:
This command should be deleted unless someone can find a use for it.


Comment:
These two paragraphs are confusing.  The first paragraph says that the 15 LSBs are a bitmap.  Then, the second paragraph says "The most significant bit of information request field indicates that the rest of the bits in the field are not bit maps, instead they are binary coded to indicate the element ID of the information element that is being requested by the sender of this command from its intended recipient."  This is very confusing.  IF the MSB is a what?

SuggestedRemedy:
The MSB action should be first, followed by a description of what the LSBs are in either case.


Comment:
Why does the probe request command contain information elements?  This is requesting IEs not sending them.

SuggestedRemedy:
Remove Information Elements from the probe request command.


Comment:
The Channel Status request command should specify a window size, not leave it up to the responer

SuggestedRemedy:
Add channel status request window field and the appropriate descriptive text.


Comment:
Max window sizeshould be an integer number of superframes, not ms.

SuggestedRemedy:
Change max window size to be an integer number of superframes.


Comment:
Should specify that the frame counts was for frames feceived from the destination of the command.

SuggestedRemedy:
Modify the sentence as follows  "by the sender of this command from the destianation of this command."


Comment:
Specify that the frames received in error wer from the destination of this command.

SuggestedRemedy:
Modify the sentence as followe:  "The RX error frames count is the total number of frames, not including Imm-ACK frames, that were received in error by the sender of this command from the destination of this command."


Comment:
How do we know if a frame was received on its first attempt or a subsequent attempt?  Is this what the retyr bit is used for?

SuggestedRemedy:
Explain how it is determined gthat a frame was received correctly on its first attempt.


Comment:
This paragraph is inconsistent.  First it says the frame loss count is frames that were not successfully received on their first attempt.  Then it says that missing frames (a gap in sequence number) is the way that lost frames are determined.  However, successful retries will not show up as a gap in sequence number.  Then it says that frames with retry bit set are not included in the calculation.

SuggestedRemedy:
Redo this paragraph and remove inconsistencies so that we have a solid definition of what frame loss count means.


Comment:
"These numbers are accumulated for all streams at a DEV and sent as receive frame loss count."  It is not clear that these are only the streams from one particular DEV.

SuggestedRemedy:
Modify the sentence as follows:  "These numbers are accumulated for all streams from one DEV to the other DEV and sent as receive frame loss count."


Comment:
Channel status gives no more information to the transmitter than if acknowledgements are used.

SuggestedRemedy:
Eliminate channel status request and response altogether an just use ACKs if you want to determine channel status.


Comment:
The DEV requesting repeater service will not know the amount of channel time required for the PNC to the destination DEV.  Also, it does not make sense to have the transmitting DEV send to both the receiver and the PNC.  This will waste too much channel time by forcing the DEV to use the lowest TxRate.  Also, Immediate ACKs can not be not used.

SuggestedRemedy:
If we keep repeater service, the PNC will need to determine the channel time required itself.  I recommend eliminating the repeater service.  If repeater service is needed then it should be handled by the higher layers.


Comment:
The number of octets for EPSTIme and EPS next should be 0-2 and 0-4 because they are not always present

SuggestedRemedy:
Change the number of octets for EPSTime and EPS next should be 0-2 and 0-4.


Comment:
There is no text to describe what each of these action types mean. In fact, the words "release request", "new request", "place in set"  don't even appear in any text in the entire draft.  "information request"  does not appear in any power management text.

SuggestedRemedy:
Need to describe what each of these action types do and when they are used.


Comment:
How does a DEV know what EPS sets are out there and which to join?

SuggestedRemedy:
Proponets of this power management scheme need to specify how a device knows what ESP sets are out there, who the members are so it can decide which to join.


Comment:
"The EPS set value is a octet that is assigned by the PNC to a group of DEVs that share the same EPSTime and EPSNext."  Are all DEVs with the same EPSTime and EPSNext in a single EPS set?


Comment:
It is redundant to say "A value of zero indicates that the DEV is waking for each superframe." and to say "Depending on the value of superframe duration parameter, values of EPSTime that are less than the current value of superframe duration indicate that the DEV wakes for each superframe." Also, it is undlear why saying that "Depending on the value of the superframe duration parameter."  These words provide absolutely no value.

SuggestedRemedy:
It would suffice to replace both those sentences with the following: "Values of EPSTime that are less than the current value of superframe duration indicate that the DEV wakes for each superframe."


Comment:
This is all but unreadable:  "Since the wake time is bounded by superframe beacon location, the beacon start point immediately preceding the completion of EPSTime shall be the wake point."

SuggestedRemedy:
Replace with: "The wake point is the start of the beacon immediately preceding the completion of EPSTime."  I am putting this as a TR because I honestly don't know what was meant by the original sentence and I want to make sure I am not changing the meaning.


Comment:
"For this command, the value of EPSNext is taken from the EPSSync parameter in the MLME-POWERMGT.request primitive."  EPSSync is a boolean value.  How can the 2 Octet EPSNext be taken from a boolean parameter?


Comment:
Why should a device have to notify the PNC that it is going to be using RPS mode?  RPS just says that you can save power by not listening to GTS slots that are not assigned to you.  You will never send or receive frames in a slot that is not assigned to you, so why does the PNC need to know that you won't be listening.  Having RPS mode is an unnecessary complication of this protocol.


Comment:
I assume that "release confirm," "New Confirm," "place in set confirm and Return information on the EPS set response" are sent in response to the "release request", "new request", "place in set"  and "information request"  but that is not clear.

SuggestedRemedy:
Add text to clarify that these action types correspond to the corresponding request action types.


Comment:
Why is PowerManagementMode of 1 (rps) allowed but mode 0 (PM_Off) not allowed?    What will RPS do with EPS actions?

SuggestedRemedy:
Explain why an rps device would send an EPS action, but not a PM_OFF device.


Comment:
Use of PowerManagementPriority to specify power sensitivity is open to abuse by manufacturers and should be eliminated.


Comment:
The number of TX slots does not necessarily equal the number of channel time request slots.  One CTRB can request mulotiple slots per superframe.  Conversely, multiple CTRBs can be allocated a single slot.

SuggestedRemedy:
Change the name form "number of TX slots" to "Number of active CTRBs"


Comment:
It is not clear why a DEV would need to know the CTRBs for another DEV.

SuggestedRemedy:
Remove all CTRBs from the device information response command records.


Comment:
"rulses a the device"  should be "rules as the device"


Comment:
The figure should have "Record for child or neighbor PNC-1, Record for child or neighbor PNC-2, Record for child or neighbor PNC-n

SuggestedRemedy:
Change figure to say "Record for child or neighbor PNC-1, Record for child or neighbor PNC-2, Record for child or neighbor PNC-n


Comment:
Why is End sequence number needed?  The start sequence number and the RxStatus bitmap is all that is needed.


Comment:
The figure says Record for stream 1, 2, ...n, but you could have multiple records for the same stream.

SuggestedRemedy:
Add text that says that that there could be multiple records for the same stream.


Comment:
Sequence number provides no useful information.

SuggestedRemedy:
Remove this sentence about end sequence number.


Comment:
should say "unicast stream with ACK policy of Immediate ACK."

SuggestedRemedy:
Change to "unicast stream with ACK policy of Immediate ACK."


Comment:
2 fields had to be added to the CTREZB, plus 7 paragraphs to attempt to explain their usage.

SuggestedRemedy:
This type of complexity in the name of powermangement is unwarranted.  Revisit power management.


Comment:
Since the PNC clock and the application clocks on the DEV won't be perfectly synchronized, the superframe and the application clock will slip with respect to each other.  Therefore, the applications need to be able to handle at least a superframe worth of jitter.  By limiting the max superframe size to 65.535 ms, we put a 65.535 ms bound on delay variation.  This should be suitable for most applications.  If not, 65 ms of buffering can smooth out the jitter.

SuggestedRemedy:
Remove maximum allocation delay variaion from the CTRB.


Comment:
We never voted to include a grant status field. What if the grant is queued and either is sent or resent after the beacon number of the SFNext?  Then the DEV thins it doesn't have a slot for 2^16 superframes.

SuggestedRemedy:
Remove grant status from the channel time grant.


Comment:
What is the CTA element set to if it is not the same in every superframe?

SuggestedRemedy:
Need to define what the CTA is set to in the chanel time grant if it is not the same for every SF.


Comment:
"stream request index" is not consistent with Figure 75.


Comment:
(Del-ACK should be (Del-ACK) - missing )


Comment:
This sentence is unclear "The direction field value of ‘1’ means that the stream is being transmitted from the DEV that sent the command.  The value of ‘0’ means that the stream is being received."

SuggestedRemedy:
Modify the sentence as follows:  "The direction field value of ‘1’ means that the stream is being transmitted from the DEV that originated the stream requeest.  The value of ‘0’ means that the stream is being received by the oriiginator of the stream request."


Comment:
We should not be negotiation for all of these parameters in the stream management command.  The PNC cannot control the minimum,peak, rate, average rate, max burst size, average frame size.  The PNC can only guaranteee access to the channel

SuggestedRemedy:
Remove all of the stream parameters and only request channel time.  This will greatly simplify the protocol.


Comment:
Setting the resolution of the channel time to 8 us will result in inefficient CTAs.  This should be change to 1 us resolution.


Comment:
All of these parameters have use K which is 1024.  They should be small k, which according to the definitions is 1000.


Comment:
"A zero value is not allowed ... to be ignored by the recipient" is not correct. A requested edit did not make this draft.

SuggestedRemedy:
Delete the sentence and add the following replacement:  A zero value shall be treated as "never", which will have the effect that the only EPS CTA elements generated by the PNC will be the result of the EPS DEV sending a Momentary EPS CTA command.


SuggestedRemedy:
Change: "...start time of next GTS" to ... superframe of next GTS.


Comment:
This applies also to 7.5.7.4., p126, line 3.  The use of the Destination DEV address is not arbitrary and should be indicated.

SuggestedRemedy:
A DEV issuing a Switch to EPS (ACTIVE) mode command shall only use the Destination DEV Address if the Destination DEV and the issuing DEV agree amoung themselves that this is allowed.  The mechanism for this negotiation is beyond the scope of this standard.  Otherwise a DEV shall issue the command without any Destination DEV addresses indicating that only its own mode will change.


Comment:
The meaning of the key change bit is TBD.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Bit has been removed.


Comment:
The MAC Frame includes a retry bit and a sequence number field.  It seems that the sequence number makes the retry bit unnecessary.

SuggestedRemedy:
Eliminate the retry bit if it is in fact redundant


Comment:
The MAC header check sequence (HCS) should be calculated and implemented by the MAC and not the PHY.  The layers should not be mixed.

SuggestedRemedy:
Have the MAC, not the PHY, calculate and implement the MCS.

Response:
PROPOSED REJECT. Because the PHY header is short and because of the desire to reduce overhead, we decided very early on to use only one CRC to protect both headers.


Comment:
This clause does more than just specify the frame formats.

SuggestedRemedy:
Add the following sentence after the first:  An overview of the MAC frame is followed by a description of the general frame format, a description of the individual frame types, complete documentation of the information elements and then the command frames.


Comment:
FCS and HCS are checked to validate the received frames.

SuggestedRemedy:
modify the sentence as follows:  either error free or in error, using the header check sequesnce (HCS) and frame check sequesnce (FCS).


Comment:
"order in which they are passed to the PHY,"  is not technically correct, since the interface between the MAC and the PHY is likely not serial.

SuggestedRemedy:
replace with "order in which they are transmitted on the air,"


Comment:
Adding a bracket covering the frame body and FCS and saying <aMaxFameSize would be helpful.

SuggestedRemedy:
Add a bracket covering the frame body and FCS and saying <aMaxFameSize would be helpful.


Comment:
Get rid of Delayed ACK.  This will unnecessarily complicate the MAC to implement.  We should keep a WPAN as simple as possible.


Comment:
"... command frames that is the start of the current..."  is incorrect grammar - frames is.

SuggestedRemedy:
Replace with "... command frames that are the first frame in the current..."


Comment:
"The PNID remains constant during the current instantiation of the piconet and may be persistent for multiple sequential instantiations of the piconet by the same PNC."  "May be persistent"?  Hos is it determined if it is persistent?  Up to the implenter?  Do PNCs always use the same PNID?

SuggestedRemedy:
Need to describe the details of persistence of the PNID.


Comment:
Not sure why 3 addresses are reserved for neighbor piconets.  Why 3?  Is that enough?

SuggestedRemedy:
Describe the benefit of using a reserved address, or else just use the capability field for a DEV to indicate a neighbor piconet?


Comment:
Do we really need a 16 bit sequence number?  If we eliinate delayed ACK, we can probably get away with a 4 bit sequence number.

SuggestedRemedy:
Reduce sequence number to 4 bits if we eliminate delayed ACK.


Comment:
Is the same sequence number counter used for asynchronlous datea to all destinations?  If so, this will mess up the Rx frame loss counter in channel status response.  If a separate counter is needed it will complicate implementations.

SuggestedRemedy:
Specify that a single counter is used for all frames and that the Rx frame loss counter may not be accurate for asynchronous frames.


Comment:
Need to clarify that the MAC ignores the HCS.

SuggestedRemedy:
add the following sentence "The MAC always ignores the CS field upon reception."


Comment:
clarify that the pad octet field is in the header

SuggestedRemedy:
Modify the sentence as follows:  "...the pad octet field in the header..."


Comment:
Allowing inforamtion elements in any order in the beacon will complicate the design.  CTAs should be the last IEs in the beacon.

SuggestedRemedy:
Change the sentence as follows:  "The information elements in the beacon frame may appear in any order in the beacon, excetpt that chanel time alocations (CTAs) appear last.   DEVs may ignore any elements in the beacon which are not listed in Table 60."


Comment:
Need to add DEV GTS Status ie in table 60.  This  appears in every beacon.

SuggestedRemedy:
Add DEV GTS status to table 60.  It appears in every beacon.  It is described in 7.4.12


Comment:
Frage start and frag end should be set to 1, not zero in the beacon.  This should follow the rul so it CAN be ignored, rather than breaking the rull so that it MUST be ignored.

SuggestedRemedy:
Change frag-start and frag-end to 1 in the beacon in table 61


Comment:
Frag start and frag end should be set to 1, not zero in the ACK.  This should follow the rule so it CAN be ignored, rather than breaking the rull so that it MUST be ignored.

SuggestedRemedy:
Change frag-start and frag-end bits to "1" in the immediate ACK.


Comment:
Don't really need two octets for command type.  One is more than adequate.

SuggestedRemedy:
Change command type to 1 octet.  Update all relevant references to 2 octets.


Comment:
"A command data unit (MCDU) may also be transmitted in fragments, as described in 8.7."  This is inconstent with the fact that the sequence numbers from all command frames use a single counter.  Since all command frames do not go to the same destination, fragementation does not work.

SuggestedRemedy:
Change to : "Command data units (MCDUs) cannot be fragmented."


Comment:
"The duration of the CAP is computed as the difference between the superframe duration and the CFP duration." The beacon duration needs to be accounted for.

SuggestedRemedy:
The duration of the CAP is computed as the difference between the superframe duration and the CFP duration minus the Beacon time.


Comment:
What is the purpose of max burst duration?  Is this for a single frame, or for multiple frames?

SuggestedRemedy:
Clarify the use of max burst duration or eliminate it.


Comment:
Rather than wasting a value, change the ecoding so that in the future we can allow a key per SA/DA pair.

SuggestedRemedy:
— 0b00: neither authentication nor data encryption are required. — 0b01: authentication is required. — 0b10: both authentication and data encryption are required - single Key per piconet — 0b11: both authentication and data encryption are required - single key per SA/DA pair


Comment:
OID needs to be defined here and in the acronyms, not just in the appendix.


Comment:
Length field says "Length(=2)" but there are 3 octets.


SuggestedRemedy:
Change to "The current Tx Power is THE DEVs estimate..."


Comment:
Why is power at the antenna used, and not eirp?


Comment:
Why would we limit transmit power and not eirp?

SuggestedRemedy:
Change piconet maximum transmit power to limit eirp.  Antennal gain PIB may be needed.


SuggestedRemedy:
I give in!  Duration should be put back into the CTA.  Add a 2 octet field to the CTA called slot duration.  We agreed on this a while back, but the person who was supposed to provide the text never did.  This will alow guard time to be added on a slot by slot  basis.  I will provide the text since on one else has.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Adopt, verify if the beacon needs to be fragmented because of this change. Reference comments 502, 505.


Comment:
I disagree that directed frames should not be allowed in a broadcast GTS.  Allowing directed frames in a broadcast GTS should would help the efficiency of transmitting asychronous traffic.

SuggestedRemedy:
Change this to say that directed frames are allowed in a broadcast GTS.

Response:
PROPOSED ACCEPT IN PRINCIPLE.  Delete the sentence "If this is a … time slot."


Comment:
There is no reason for a key change bit to be in the CTA control block.  This will only cause problems when a station misses a beacon.  Since we have key number in the Piconet Synchronization parameters information element in the Beacon, this bit is not needed in the CTA.  It is a bad idea to reserve a bit for possible future use.

SuggestedRemedy:
Remove the Key change bit from the CTA control boock, and remove line 36 on page 107 about the key change bit.


Comment:
Since superframe duraqtion is limited to 100 ms, having the slot start time be 16 bits of 8 us resolution is not an effective use of bits.  Also, having 8 us of resolution is going to allow efficient allocation of GTS slots for high rate PHYs.

SuggestedRemedy:
Change resolution for CTAs to 1 us, with the max then 65.535 ms.  Change the sentence to say: "The resolution of this field is 1 µs and so the range is [0-65535] µs."


Comment:
This line will change when we add the duration field back in as we agreed to.

SuggestedRemedy:
Modify this sentenc to say"  The eand of each GTS slot is the start of the GTS slot plus the duration.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Modify sentence to say "The end of each time slot is the start time of the time slot plus the time slot duration."


Comment:
It needs to be made clear that the timing starts from the begining of the beacon preamble

SuggestedRemedy:
Modify the sentence as follows:  "The value of this field is always an offset from the start of superframe and hence the start of transmission of the preamble of the beacon frame from the PNC.


Comment:
Forcing the receiver to interpret a slot start time of zero as "no GTS"  is a complication.  This CTA will need to be the first CTA because the previous CTA will use this CTA start time as it's start time.

SuggestedRemedy:
Another reason to add the duration field back into the CTA.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Duration field has been added in comment 505.


Comment:
Mea Culpa:  I no longer feel think that the Max CTAs field is a good idea.  It is open to abuse by manufacturers who want to save power in their devices.  It will also be difficult to interoperate if all devices choose a small number.

SuggestedRemedy:
Remove the Max CTAs field and all references to it.  We would be better off limiting the number of CTAs in a piconet.

Response:
PROPOSED ACCEPT IN PRINCIPLE.  Add parameter aMinProcessedCTAs value 64 to Table 73. Insert sentence after "… destination." "MaxProcessedCTAs shall be no less than aMinProcessedCTAs."


Comment:
Need to clarify this sentence: "If either it’s DEV GTS status bit or the broadcast GTS status bit is set to one, then the DEV needs to process the CTAs in that beacon."

SuggestedRemedy:
Modify as follows: "If either it’s DEV GTS status bit or the broadcast GTS status bit is set to one or it did not correctly receive and process the preceeding beacon, then the DEV needs to process the CTAs in that beacon."


Comment:
It is not clear to me where thie Power management parameters infotmation element resides?  In the Beacon?  In a pwoer management frame?  I did a search and I didn't find "power management parameters element anywhere in the rest of the draft.

SuggestedRemedy:
Please clarify where this element is used or remove it.


Comment:
Having EPS be both a mode and a state is too confusing.

SuggestedRemedy:
Rename the EPS state to something other than EPS.


Comment:
If the device uses EPS power management at any time during a session, this field is set to 2.   Is this bit set anticipating EPS being used, or is it set after EPS is first used?  After an EPS set id joined?

Response:
PROPOSED ACCEPT IN PRINCIPLE. Change "uses" to "intends to use".


Comment:
"If the DEV will not use any power management, the field will be set to 0."  Why would any device listen to GTSs that are not assigned to it.  Any device should be able to do RPS.  There is no need to have an active state.

SuggestedRemedy:
Power management ACTIVE vs RPS is an implementer decidision.  There shoudl be no distindction in the standard between RPS and active devices.  Only one bit is needed for the PowerManagementMode.

Response:
PROPOSED ACCEPT IN PRINCIPLE. ChangePowerManagementMode to be one bit. Change "… is set to 2 ... will be set to 0 …" to be "…shall be set to 1. The bit shall be set to 0 otherwise."


Comment:
"EPS status indicates the current operation (EPS or ACTIVE) for an EPS DEV and has meaning for a DEV with PowerManagementMode set = 2."  should say "only has meaning"

SuggestedRemedy:
Change sentence to: "EPS status indicates the current operation (EPS or ACTIVE) for an EPS DEV and only has meaning for a DEV with PowerManagementMode set = 2."


Comment:
How is gteh application specific data put into the ASIE  There is no MLME to do this.

SuggestedRemedy:
Need to create and MLME to put application specific data into the ASIE.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Bob Huang will write the appropriate MLME.


Comment:
"No command frame shall be transmitted to or by an unassociated DEV within a piconet."  If no command frames are allowed by an unassociated DEV, you couldn't associate since association is a command frame!

SuggestedRemedy:
Change to:  "No command frame except association request and response shall be transmitted to or by an unassociated DEV within a piconet."  And Add:  Alternate PNC announcement and pullout are allowed during piconet initialization.


Comment:
6 commands were added just for power management.  Something is wrong when so many new commands are needed just for power management.


Comment:
We cannot understand the be3nefit of sending more than one command in a frame.  Are we going to queue commands until we get enough to send?  How long are they held?  Won't this create latency?

SuggestedRemedy:
For the good of the protocol, only allow one command per command frame.


Comment:
Why set the frag start and frag end bits to zero and ignore?  this creates an exceptionb at the receiver.  Why not set both to one, then the receiver has the OPTION of ignoring, rather than forcing the receivver to ignore.

SuggestedRemedy:
Change frag start and frag end to 1 for PNC selection and handover.


Comment:
Tx power level should be PHY dependant.  Some PHYs may be regulated as powerspectral density, not power.

SuggestedRemedy:
Makd Tx Poweer level PHY dependant and move the description of this field to Clause 11.


Comment:
"A late joining, new DEV may extend this time via its frame which shall be adopted by all the currently participating DEVs."  What if all teh other DEVs can't hear?  How does it get propagated?

SuggestedRemedy:
Explain how this change impacts the process.


Comment:
Ignoring the header fields should be optional and not mandatory.  Setting the bits should be mandatory, ignoring them on reception should be optional.

SuggestedRemedy:
change to "may be ignored upon reception"  This applies to all of the commands.


SuggestedRemedy:
Change frag start and frag end to 1 for Association Request Command.


SuggestedRemedy:
Change frag start and frag end to 1 for Association Response Command.  This applies to all commands.


Comment:
Why is "DEV wishes to disassociate" a reason code?


Comment:
Security required should be a reason code.

SuggestedRemedy:
Add "security requered" as a reason code.


Comment:
What does "DEV state has expired" mean?  Does this mean that ATP timeout?

SuggestedRemedy:
Describe what this means.  If this does not mean ATP, add ATP expired as a valid reason code.


Comment:
Public Key Object Length and Length are redundant.


Comment:
What is the maximum size of a public key object?  If it won't fit in a max frame size, the command frame would need to be fragmented.  Fragmenting command frames won't work becasue of single sequence counter.

SuggestedRemedy:
Need to sensure max key object size is less than the max frame size or figure out how to fragement commands.


Comment:
Need to specify the security parameters information element in the association response so that the DEV knows what cipher suite to use for association.

SuggestedRemedy:
Add security parameters IE into the association response command.


Comment:
AuthenticationInfoLength is redudant with Length


Comment:
PublicKeyChallengeLength is redundant with Length


Comment:
PublicKeyProofLength is redundant with Length


Comment:
Request key request command is redundant.


Comment:
Stream management command should use the 48 bit address instead of the 8 bit address.  Even though each DEV should have the latest table, it may get out of sync.  Using the 48 bit address will prevent problems.

SuggestedRemedy:
Have stream management command use the 48 bit address.


Comment:
The first time EPS Channel Time Request is used, it should say (EPS CTR)

SuggestedRemedy:
Change from "The CTRB type value of 2 is used to create an EPS channel time request." to "The CTRB type value of 2 is used to create an EPS channel time request (EPS CTR)."


Comment:
Need to define null CTA the first time it is used.  It is defined in 8.13.3.4, but it is used several times before that.

SuggestedRemedy:
Define null CTA the first time it is used.  Also, add it to the definitions.


Comment:
Should change the sentence to "When the SEC bit is set to 1, the frame body is protected by payload protection using the currently assigned payload protection key(s) for the piconet."


Comment:
The cipher suites are not defined according to any standard.  In particular, the IEEE P1363 standard, which is Std IEEE 1363-2000, does not contain any cipher suites in it.

SuggestedRemedy:
Recommend changing the sentence to "The OID field specifies a unique cipher suite."  Comment via Ari Singer.


Comment:
The key change bit is defined as TBD.  I actually don't see any reason for it at this point, but we can leave it in if we really want to.

SuggestedRemedy:
Change the line to "The key change bit is reserved for possible security implementations.  In the current version of the standard, this bit shall be set to 0."  Comment via Ari Singer.


Comment:
Each CTRB in Fig. 72 is 12 octets Also Length field in Fig.71 shows n*10

SuggestedRemedy:
Modify the text & Fig. 71 & 72 to be consistent


Comment:
Grant status field (Fig. 73) in Fig. 74 is 3 octets Reason code of Fig. 74 should be b16-b19

SuggestedRemedy:
Modify Length field (=n*9) and Grant status field (3 octets) to be consistent Modify Reason code (b16-b19) in Fig. 74


Comment:
DEV GTS status (7.4.12) information is not listed in Table 60

SuggestedRemedy:
Add DEV GTS status as an entry in Table 60


Comment:
No frame format for Beacon like that of Fig. 14 & 16


Comment:
SFNext field also used in CTA elemnet (Fig. 73 & 30), this is redundant.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Remove SFNext field from figure 74 and the sentence on line 30-31 "The SFNext … in 7.4.10."


Comment:
It is confusing that this command seems suggesting a DEV seeking to communicate with target DEV needs to use this command,even if after a stream connection has been established. While CTA for one stream is assigned at the end of stream conection (Fig.3).

SuggestedRemedy:
Clarify if this command is used in conjunction with streme management command for establishment of communication and required for allocating time slots for the stream


Comment:
What can a requesting DEV use for the pending CTRB information of each stream and Number of TX slots, since the channel time allocation is solely determined by PNC? The information should provide characteristcs about queried device and allow  the requesting DEV to make decision about whether to initiate communication with a particular DEV

SuggestedRemedy:
Remove CTRB and no. of TX slot or replace with something else

Response:
PROPOSED REJECT. This command is used to enable PNC handover, not request application specific device information. The name is being changed to better reflect the use.


Comment:
What is the streme index of child/neighbor piconet? Are these fields(Duration between time slots, Min. requested channel time, Requested channel time per time slot) appled to the private GTS for child piconet?

Response:
PROPOSED ACCEPT IN PRINCIPLE. That command has been deleted because the capabilities are handled by the device information response command (will be changed to PNC information response command). Text has been added in clause 8 to clarify use of these parameters.


Comment:
PNC should be able to broadcast Application specific information (Table 63, p101) as needed

SuggestedRemedy:
Add entry for Application specific information in Table 60


Comment:
No information regarding possible applications/services will provided by a devices (host) is included in capability field. Products should be classified based on application (PDA, Digital camera, camcorder, etc) and mapped to one field of capability. Therefore, a DEV can pre-filter device information sent by PNC(device information response command) for further actions.  Currently no information is provided to DME for a device to select peer devices in the piconet for communication after association.

SuggestedRemedy:
Add 'product category' field to capability information

Response:
PROPOSED REJECT. The Application Specific Information Element can be used for this purpose.


Comment:
A specific reference to tables 71 and 72 should be included. Although the text refers to tables below, table 72 has floated to a point after the next section (8.16) and the "tables below" could refer to table 73 as well.

SuggestedRemedy:
change "tables below" to "tables 71 and 72"


Comment:
The dynamic channel selection text does not mention the pseudo-static operation allows a DEV to continue to operate for up to 4 superframes without seeing a beacon. I don't think that this is a problem because the pseudo-static is limited to the peer-to-peer transfer in a CTR or stream setup and does not extend to commands to the PNC.

SuggestedRemedy:
Make mention that specific DEV to DEV operations are allowed during the quiet time but that no DEV to PNC traffic is allowed


Comment:
A clarification that the a new piconet should be started in a vacant channel rather than an occupied.  Although, it would seem that some tie in to child piconet should also be mentioned

SuggestedRemedy:
add the word "vacant" between "choose a" and "channel"


Comment:
The text that relates to staying on the channel of a desired PNID should be changed. The idea that a random number would be of interest is hard to grasp. The text should omit the PNID reference.  Also, and this is the TR reason, there is no clear guidance on how to "really" decide what channel is the correct one. Maybe I missed it!

SuggestedRemedy:
Change the text to read: ... received, the searching DEV ....  next: add text either at this point in clause 8 or elsewhere that provides some guidance on how a DEV might determine what piconet to join.

Response:
PROPOSED REJECT. Delete "with the desired PNID" line 7, page 138. Without a clear proposed solution, the committee cannot determine how to accept the full comment.


Comment:
Much of the EPS operation is predicated on CTR operation to establish EPS and ACTIVE channel times that are keep in "memory" by the PNC. What is lacking is a relationship to the stream operation in the standard. The stream command does not have the same parameters as the CTR.

SuggestedRemedy:
Update the stream command in clause 7 and clause 6 primitives to provide a match between the stream operations and CTR.


Comment:
We need to reference where the fields are defined. aCSFrameRepeat and aCSFrameBroadcast


Comment:
It is not clear as to the optionality of a DEV to not offer PNC services. It is not acceptable for the standard to effectively allow DEVs to not support PNC roles. There must be a provision to allow certain classes of DEVs the opportunity to be free of PNC burden base on their requirement for low complexity. However, specific language and a SHALL statement would require that a PNC-less character must be matched by having a partner in an application that SHALL provide PNC capability.

SuggestedRemedy:
Add in 8.2 as a distinct subclause: Responsibility to assure that a piconet may be formed. -- Classes of simple devices may be implemented without providing support for PNC role in a piconet. These classes are permitted if the device is required to be used in conjuntion with a device that shall support PNC opertion.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Add in 8.2 a distinct subclause. Non-PNC Capable Devices.  Simple devices may be implemented without providing support for PNC role in a piconet. The implication of this is that is possible for these devices to be unable to form a piconet by themselves. Therefore, these devices would be a type that are normally use in conjunction with a device that provides PNC capability. An example of this would be wireless speakers expected to be used with a receiver.


Comment:
At least one of the table 68 entries, designated mode bit, seems to require more than a two-state value. As I understand it, an AC with the Des-mode set is the winner, but more than a single device type may believe that it qualifies to be the Designated PNC. I clearly believe that a video distribution AC such as a settop box with the implication of great demands on the piconet should be the highest priority. Below that would be other important devices such as cablemodem/DSL internet distribution device.

SuggestedRemedy:
Make the Des-mode be a two-bit field and set guidelines on the classes of device for at least three of the values.

Response:
PROPOSED REJECT. The DesMode can be changed under user control to determine which one will be the PNC.


Comment:
"... and its AD-AD or that the request has been rejected ..." doesn't read well.

SuggestedRemedy:
not sure how it should read! perhaps that " its AD-AD has been assigned or that the ..."


Comment:
channel time allocation command rather than channel time request.


Comment:
Should provide clarification on recovery from incorrect beacon.

SuggestedRemedy:
Add: This may as simple as dealing with a PNC that is checking another channel for better rf conditions. It may also be that the PNC has changed the superframe duration while a DEV was not awake. Procedures outside of EPS power management process are used to recover.


Comment:
maybe not the correct location but it seems that there should be mention that for pseudo-static, that the PNC shall not change the superframe duration while devices are presuming a location for their slot don't get confused.

SuggestedRemedy:
Add wording: The PNC shall not vary any paramters, such as superframe length, that would invalidate the pseudo-static GTS assigned to one or more DEVs in the piconet.


Comment:
Considering that the aMTSAssocPeriod is 0.6 milliseconds, there is a question that the sub 1 second begin scan to payload ready interval may be attained. The unspecified authentication must be considered as well as the extensive number of message exchanges necessary for the typical DEV to get ready to deliver payload.

SuggestedRemedy:
Understand the numbers and then set the aMTSAssocPeriod accordingly.


Comment:
I will put the comment here but it may impact other clauses. If the CAP is reduced to zero length and MTS used in its place, some of the text that we still may have regarding use of the CAP for small amounts of data are not correct.

SuggestedRemedy:
correct the data in a non-existant CAP issue in this clause with a note that in this case, data must be handled in GTS only.


Comment:
Is there a case where an open MTS is less than one per superframe? If so, is there appropriate wording to change the responsivness of the PNC to requests for change. I believe that up to 4 superframes may pass from CTR till CTA reflecting the change. The 4 superframe lag is long already. It should not go beyond that.

SuggestedRemedy:
put the appropriate SHALL to keep the lag from CTR (or Stream) till CTA from getting higher than 4 superframes when MTS is used.


Comment:
In the absence of CAP, the first GTS is bumped against the end of the beacon. The development of real implementations of this standard may be hindered if the parsing of the beacon body must occur in the very few microseconds available.

SuggestedRemedy:
Provide guidance to implementers but also place a minimum time till the beginning of the first GTS in the absense of CAP. If a PNC to DEVs MTS is always present, then this would not be a problem.


Comment:
This sentence references values that are not defined in the frame commands used to establish stream connections.

SuggestedRemedy:
Change "The values for direction, security, stream type and priority ..." to "The values for direction, stream type, priority, and GTS type ...".


Comment:
'Bandwidth' is not specifically negotiated, channel time is negotiated.

SuggestedRemedy:
Change "All the bandwidth and latency ..." to "All the channel time and latency ...".


Comment:
PNC does not negotiate nor allocate bandwidth. Use of bandwidth in this paragraph does not match other parts of the specification.

SuggestedRemedy:
Replace 'bandwidth' with 'channel time' in this paragraph. Bandwidth occurs twice.


Comment:
"sub-clause 8.2.7."  - Shouldn't this be 8.2.4?


Comment:
Diagram hard to read.  Where are the terms aMinHandOvrTo, aMaxHandOvrTo, aCHFrameRepeat and aBroadcastDEVInfoDuration in this diagram?  I would like to see their timing relationships.


Comment:
I would like to see an example of the handover process in relationship to other traffic.  This should provide a system overview of the timing.


Comment:
What is a directed frame?  The allocated private GTS response?


Comment:
During the proposal selection process of the standard process, I remember discussions about the fact that devices operating in an ISM band could not be coordinated.  This neighbor piconet seems to be a method for coordinating between different types of devices (such as an 802.11b or g system with 802.15.3 awareness capability - i.e. minimal DEV capability).  I thought this was illegal within the FCC part 15 rules.  I see this a minimal attempt at coexistence, but will it met the current regulations.

SuggestedRemedy:
This issue needs to be discussed by the group.  If it does not met current FCC regulations, an assessment should be presented on current initiatives within the FCC to change rules that will enable this capability.

Response:
PROPOSED ACCEPT IN PRINCIPLE. This only applies to FH devices operating under 15.247. 802.15.3 will apply to 15.249 rule.


Comment:
"... a neighbor piconet within an existing piconet."  I thought the neighbor piconet was independent from an existing piconet.  How could it be within an existing piconet?

SuggestedRemedy:
This does not present a clear understanding of a neighbor piconet.  Clarification needed.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Replace "within an existing piconet" with "on the same channel as the existing piconet".


Comment:
Need to add a figure similar to Figure 80 to describe a neighbor piconet.  What is different?  Why are they not the same?

SuggestedRemedy:
Clarification needed on neighbor piconets.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Add an additional figure depicting a neighbor piconet as any wireless network that respects the time bounds associated with its relationship to the parent piconet. Bob Huang will provide the figure and any associated text.


SuggestedRemedy:
Should be referencing the neighbor beacon.


Comment:
"... it is neither authenticated nor associated) ..." - but figure 82 shows an association sequence.

SuggestedRemedy:
If diagram is not wrong, paragraph is wrong.  Make the two consistent.


Comment:
You define what an associated response is not ... "directed frame".  So what is an associated response?  A broadcast frame?


Comment:
The section words do not indicate a SIFS time before an ACK

SuggestedRemedy:
State what is intended consistently in words and figure.


Comment:
"... CAP is used for non-QoS frames."  - So what is it used for?  Control and asynchronous data frames?

SuggestedRemedy:
State what it is, not just what it is not.


Comment:
It is hard to know what this figure represents.  Is there a legend on the shade meanings?  Are TX and RX the same slots?  What is the difference in each frame?  Is it an advance of time?


Comment:
The grayed box seems to attempt to tell the reader to reference the previous figure (88).


Comment:
Reference to Figure 8.12 should be a reference to Figure 92.


Comment:
Where is RPS listed?  It seems to be missing.  Does this mean the definition of RPS is incomplete?


Comment:
The xref field in FrameMaker has the 'Figure n' in the field but the Editor has also typed "figure" i.e., "...shown in figure Figure 82."

SuggestedRemedy:
Either delete the first occurence or edit the FrameMaker field, thus requiring a Clause 8 global edit on the paragraph tag for figure cross-reference formats.


Comment:
The following sentences do not end in a period: — backoff_window(retry_count): A table which has values [7, 15, 31, 63] ... channel. For the 2.4 GHz PHY, this is defined in 11.2.6.1


Comment:
The following sentence does not end in a period: This is illustrated in Figure 89


Comment:
The following sentence in Figure 88 does not end in a period: suggested value for size of Retx window


Comment:
The following sentences in Figure 89 do not end in a period: Use all-zero stream index in the request ... Rest of the sequence follows as if the sender of the stream initiating the stream connection process  also I would drop the grey color in the box at the bottom of the figure.

SuggestedRemedy:
Add the period and delete the color from the box at the bottom of the figure.


Comment:
The sentence "The table information will be described in sub-clauses of the power management clause." and the text reference to a unique 'power management clause' seems incorrect.  I can not find a clause titled power management, however, I do note that this sentence is in subclause 8.13 Power management.

SuggestedRemedy:
Correct text reference and possibly add a cross-reference for the reader.


Comment:
The term "net" in the sentence "...searching for this net or attempting to locate an empty channel." is jargon.


Comment:
The following sentence does not end in a period: information command, it may select EPS mode as described in 8.13.3.6


Comment:
The Editor might want to consider Figure 94 and the sentence "Note: PNC will begin..." most of the notes up to this page in the D09 are "Note that..." vs. "Note: ...".  The issue is normative vs. informative; respectively.

SuggestedRemedy:
I defer to the Editor but it is likely that it should be changed to "Note that...".  If you choose to leave as-is then remember - Notes always start with the word "NOTE" in capital letters, followed by a dash, and are set in 9-point type.


Comment:
The following sentence does not end in a period: 1) The size of the EPS time slots used for data


Comment:
The Editor might want to consider Figure 95 and the sentence "Note: DEVs do not enter EPS operation at this point" most of the notes up to this page in the D09 are "Note that..." vs. "Note: ...".  The issue is normative vs. informative; respectively.  Also, adding a period completes the sentence.


Comment:
The PNC selection process does not define a channel access method for the ACs that are broadcasting their messages.

SuggestedRemedy:
Change the text in 8.2.3 to require the ACs to use the backoff procedure defined in 8.4.2.1 for channel access during the PNC selection process.


Comment:
Informal language use for required action.

SuggestedRemedy:
Change "selection command and wait for the piconet" to "selection conmmand and shall wait for the piconet"


Comment:
Need clarification of when the new PNC begins using the PNC address.

SuggestedRemedy:
Change "The new PNC shall begin using address of 0x00 for all" to be "Following its first beacon, the new PNC shall use the PNC address, 7.2.3, for all"


Comment:
The directed frame with Private GTS is optional and should be noted as such in Figure 81.

SuggestedRemedy:
Add the word "Optional" to "Directed frame with Private GTS".  Also, change the direction of the child beacon, it is not sent to the Parent PNC.  Add to the paragraph ending "its capabilities and security policy." the following:  "If the PNC allocates the private GTS, it may also send a directed channel time grant to the child PNC to confirm the allocation."  Make the same changes with Figure 82.  On page 142, 8.4.2, line 46, change "destination addresses.  After receiving" to be "destination addresss.  The PNC may also send a directed channel time grant to the neighbor PNC to confirm the allocation.  After receiving"


Comment:
Association may happen in the CAP or in an association MTS.

SuggestedRemedy:
Change "during the CAP of an existing piconet." to be "during the CAP or association MTS of an existing piconet."


Comment:
Need to clarify how the PNC acknowledges the association request commands.

SuggestedRemedy:
Change "an Imm-ACK frame." to be "an Imm-ACK frame with the DA set to the association address."


Comment:
There is no exit criteria for the PNC in doing an association response and directed rame.

SuggestedRemedy:
Limit it to an integer number of attempts, I suggest 10.  Change text from "the PNC shall repeat the sequence of association response and directed frame as illustrated in Figure 83." to be "the PNC shall repeat the sequence of association response and directed frame as illustrated in Figure 83 up to aMaxAssocRespRepeat times.  If the PNC does not receive an ACK after aMaxAssocRespRepeat attempts, it shall consider the association process for the DEV to have failed."  Add aMaxAssocRespRepeat to the table at the end of clause 8 with a value of 10.


SuggestedRemedy:
Delete "-- bw_random(retry_count): A pseudorandom integer ... [0,backoff_windo(retry_count)]."  Move the sentence "It is important that ... among DEVs." to the end of the previous paragraph.


Comment:
The sentence "In addition to this the PNC ... connection process." does not add any information to the present discussion.  In addition, the PNC is supposed to make use of this, but we don't say how.  For example, an implementation may use the information as an input to a PRNG to generate the slot assignments and still be considered conformant.


Comment:
The sentences "The slot assignments ... as described in 8.4.3.1" is a repeat of earlier requirements and so is an evil redundancy.

SuggestedRemedy:
Delete the sentences since this behavior has already been adequately defined.


Comment:
The channel time grant does not enable a DEV to access its GTS if it loses the beacon.  The previous paragraph clearly states that a DEV shall not access a dynamic GTS if it misses the beacon.  Likewise, a psuedostatic GTS does not need a channel time grant to access its slot.  All of the text in the draft makes the beacon the one authoritative indication of channel time allocation.

SuggestedRemedy:
Delete the entire paragraph.  If we want to keep the usefulness of the channel time grant supplementing the beacon, then the text in other places needs to be modified to allow this.  For example, this would require changes in the prior paragraph of the sort: "did not receive the beacon, it shall not" changed to "did not receive either the beacon or a directed channel time grant command, it shall not"


SuggestedRemedy:
Change "uplink MTS within" to "MTS with the new DEVs AD-AD as the SA within".  Else, define uplink and downlink MTSs where they are first referred to (i.e. around line 3 on page 151).


Comment:
Should clarify what sort of RNG is to be used.

SuggestedRemedy:
Re-use the text from the backoff algorithm.  Replace "While the random number generator is not specified, it is important" with   "The method for choosing the random integer should be unique for each DEV and use the random number generator resident on the DEV. If the DEV does not possess a random number source, the random integer should be generated using its unique 48-bit device ID (and any other information that the implementer wishes to use) and a pseudo-random number generator (PRNG) such as MGF1 as defined in IEEE Std 1363-2000. Note that the current state of the PRNG should be maintained and subsequent backoffs should use subsequent bits in the pseudo-random sequence. It is important"


Comment:
The variable r_a is overloaded.  It means both the random number that is to be counted up to as well as the current MTS count.

SuggestedRemedy:
Either use r for the count variable (i.e. r=1 rather than r_a=1 for the start and r=r_a for the access slot) or replace "r_a=1" with "1"


Comment:
All DEVs need to reset their clocks based on the best estimate of the beacon timing if they did not hear the beacon.

SuggestedRemedy:
Change "it should reset" to "it shall reset"


Comment:
There is no multicast capabilities in the current standard, so only broadcast should be referenced.  In addition, the implication of negotiating a broadcast slot is not indicated.

SuggestedRemedy:
Delete "or multicast"  Change "is precluded." to be "is precluded and so the negotiation is bipartite."


Comment:
Since the direction field is constant during the negotiation (since the target and originator addresses are now included), this sentence is incorrect.

SuggestedRemedy:
Delete the sentence "In all stream management ... as originally requested."


Comment:
The roles and terms for the stream negotiation are not clear.  They should be clarified here.

SuggestedRemedy:
Add the following text at the end of 8.6 prior to 8.6.1.  "In the negotiation of stream connection, the following entities and roles are used:  - PNC: the arbiter of channel time allocation  - originator/originating DEV: The DEV that initiates the stream negotiation process.  The originator may be either the source or the receiving DEV.  - target/target DEV: the DEV (or broadcast address) with which the originator wants to open communications.  The targe may be either the source or receiving DEV.  - sending DEV: The DEV that provides the source of the data in the stream.  - receiving DEV: The DEV that will receive the data in the stream."


Comment:
The use of the channel time request and channel time grant to get non-stream CTAs is not described.

SuggestedRemedy:
Add a short description of the frames that are exchanged to get a non-stream CTA via the channel time request and channel time grant commands.  Also, the commands that are exchanged to disconnect a non-stream CTA.


Comment:
aFragThreshold is not a constant and so should loose the a and the reference in the table at the end of Clause 8.  Also, we need to require that FragThreshold shall be less than the biggest allowed frame.

SuggestedRemedy:
Change aFragThreshold to FragThreshold.  Delete aFragThreshold from Table 73.  Change "and change them as desired." to be "and change them as desired provided that FragThreshold shall be less than aMaxFrameSize."


Comment:
The sentence "If the stream does not ... is No-ACK" is redundant.


Comment:
No group addressing is supported in this standard.


Comment:
The text "at the end of RIFS" only partially describe the timing for the re-transmission and neglects to mention the SIFS that is indicated further down.

SuggestedRemedy:
Delete the text "at the end of RIFS" since it is better described at the end of the paragraph.


Comment:
The retransmission for Imm-ACK is defined with in two incompatible methods.

SuggestedRemedy:
Either:  1) Delete "either Imm-ACK or the" from line 35.  Here, the Imm-ACK retransmission starts after the Imm-ACK would have been finished.  2) Delete the sentence "When and Imm-ACK is ... attempting another transmission."  Here, the Imm-ACK retransmission begins with the same timing as for implied-ACK, i.e. when the channel has been idle for the wait time.


SuggestedRemedy:
After "of the time slot." add the sentence "That is, the retransmission begins RIFS+SIFS following the last transmission."


Comment:
Redundant (and therefore evil) information on collision detection that is better defined in 8.4.2.

SuggestedRemedy:
Delete the sentence "A collision during the ... for that frame."


Comment:
This paragraph should list the commands that are used to wake and sleep DEVs.

SuggestedRemedy:
Change "into ACTIVE mode" to "into ACTIVE mode using the switch to ACTIVE CTA mode command, 7.5.7.4" and change "to EPS mode after" to be "to EPS mode using switch to EPS CTA mode command, 7.5.7.5, after"


Comment:
Should not require the DEV to check the channel status.

SuggestedRemedy:
Change "each DEV shall periodically" to "each DEV may periodically"


Comment:
The first sentence is redundant and therefore evil since the requirement is in the table.

SuggestedRemedy:
Delete the sentence "All group ... receive these frames."


Comment:
Group addressed frames are not supported in the standard.

SuggestedRemedy:
Change "group addressed" to "broadcast" in table 69.


Comment:
We should allow the lower rate modes to be used in the CAP for more reliable communications.

SuggestedRemedy:
Change in 2 places: "In a GTS or MTS: ... the base rate." to be "Any rate supported by both the source and destination."  Second location is at line 20.


Comment:
The current text does not give the PNC the option of rejecting the repeater service request.

SuggestedRemedy:
change "The PNC shall" to be "If the PNC wishes to grant the repeater service, it shall" and change "the DEVs.  The sequence" to be "If the PNC does not grant the service it shall send the repeater service reject command, 7.5.6.3, to the DEV with the appropriate result code set."


Comment:
It is not specified what the SA and DA of the repeated frames is.  To avoid confusion (e.g. the DEV and the PNC ACKing the same packet), the addressing should go throught the PNC (see resolution).

SuggestedRemedy:
Change "its frames as before." to be "its frames as before except that the DA of the frames is set to the PNC's address." and change "and repeat them in the time slot" with "and repeat them with the SA set to the PNC's address in the time slot"  Also need to check the impact on 7.5.6.x


Comment:
The current repeater service request commands do not support the establishment of streams.  The DEV needs to request the channel time first and then the repeater service.

SuggestedRemedy:
Change the MSC in Figure 92 to indicate that the channel time has already been negotiated prior to the repeater service setup.


Comment:
The PNC cannot keep the piconet quiet since psuedostatic timeslots still operate even without the beacon.

SuggestedRemedy:
Change "The PNC shall keep the piconet quiet by not" to "The PNC shall not" on line 40, change "The PNC may change" to "The PNC shall change" on line 41, change "beacon to cancel the quiet state of the piconet." to "beacon." on line 46, change "beacon following the cancellation of quiet state of the piconet." to "beacon."


SuggestedRemedy:
Change "Latency to change is" to "Latency to change channel time allocations is"


Comment:
Redundant and therefore icky description of slot positioning.

SuggestedRemedy:
Delete the text "Slot positioning ... used by RPS and EPS DEVs." (lines 20 through 23).


Comment:
The sentence "When DEVs exit EPS mode ... as dictated by the DEV-host." does not add any useful information and does not make sense.


Comment:
The formal definition here is redundant and therefore evil.

SuggestedRemedy:
Change "operation shall use the" to "operation uses the"


Comment:
The sentence "The EPS action command ... and EPSNext parameters." is redundant an therefore really annoying.


Comment:
DEVs should be able to enter EPS mode when they finish configuration and should not have to wait for a command.

SuggestedRemedy:
Delete the sentence "Once configuration ... further commands."


Comment:
The sentence "The PNC shall create ... their slot time." is redundant, evil and adds no new information.

SuggestedRemedy:
Delete the sentence, the PNC is already required to do this.


Comment:
DEV-A should not be able to switch DEV-B to sleep mode.  Instead the PNC should only switch DEV-A/DEV-B slots to EPS sleep, not all of DEV-B's slots.

SuggestedRemedy:
Change the text to indicate that only the DEV-A/DEV-B slots are put into EPS sleep mode.


Comment:
The PNC should not be required to create the EPS CTA if the piconet is too busy.

SuggestedRemedy:
Change "The PNC shall create" to be "If the channel time is available, the PNC shall create"


Comment:
The paragraph "The MLME-POWERMGT.request ... to its DEV-host." describes layer managment operation and does not belong here.  It is also redundant and nasty.


Comment:
Master and slave are not defined in this context and the sentence does not add useful information.

SuggestedRemedy:
Delete the sentence "Likely combinations ... and is an EPS DEV."


SuggestedRemedy:
Change "piconet wide multicast and broadcast to" to be "broadcast frames to"


Comment:
The sentence "The EPS DEV shall interpret ... directed to it." is redundant and annoying.  This is already required of all DEVs.


Comment:
A formal requirement is listed without listing all of the required activity.

SuggestedRemedy:
Change the sentence to read "if network wide ... from the PNC." to be "if the DEV receives a channel change indication or PNC handover command from the PNC."  List any more commands that would require this action.


Comment:
The sentence "It is the responsibility ... is to wake." is redundant, adds no new information or requirements and is evil.


SuggestedRemedy:
Delete the reference to the ACK and change the number of frames to be 1.


Comment:
Group addressed frames are not supported in this standard.

SuggestedRemedy:
Change "Group addressed" to be "Broadcast" in figures 71 and 72


Comment:
The aProbeResonseDelay is too short, a DEV should have at least 1 superframe to respond.

SuggestedRemedy:
Change 8 ms to be aMaxSuperframeDuration.


Comment:
aFragThreshold is not a constant and should be defined earlier in 8 as indicated in another comment.


Comment:
aBroadcastDEVInfoDuration is repeated twice, use first definition.

SuggestedRemedy:
Delete the definition on line 8, page 174.


Comment:
Allowing the use of Del-Ack Req bit set in a frame that has ack-policy set to implied-ack to obtian the del-acks is an efficient use of implied-ack policy.

SuggestedRemedy:
Remove the restriction of "only data" in 8.8.4 and add the following at the beginning. When directed frame has ack-policy bits set to implied-ack, the intended receiver can respond with a command frame or data frame that may or may need immediate-ack or no-ack.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Remove the restriction of "only data" in 8.8.4 and add the following at the beginning of the paragraph in 8.8.4 on line 2:. "When a directed frame has the ack-policy set to implied-ack, the intended receiver may respond with a command frame or data frame that may use either immediate-ack or no-ack."


Comment:
the restriction for forming child piconet is not clear, although it might have been the intent.

SuggestedRemedy:
Add "Only an AC that is associated to a PNC in an existing piconet shall form a child piconet"


Comment:
the restriction on transactions with neighboring piconet is not clear, although it might have been the intent.

SuggestedRemedy:
Clearly list all the commands that can be exchanged between the parent and neighbor piconets and state that other commands and frame types shall not be exchanged between them.


SuggestedRemedy:
chnage "no channels" to "no free channels"


Comment:
Clearly state the relation between SIFS and RIFS

SuggestedRemedy:
change "SIFS < RIFS" to "RIFS = SIFS + aBackoffSlot" change "actual values of IFSs are" to "actual value of aBackoffSlot is"


Comment:
Backoff or IFS for beacon transmission is not clear. Either Beacon tx should be after a small backoff or reasonably long IFS.

SuggestedRemedy:
At the end of line 39, add " instead the beacon is transmitted at the beginning of superframe by the PNC after waiting for the channel to be idle, as indicated by the CCA, for at least RIFS+aBackoffSlot time.


Comment:
If SA is broadcast and anybody could start tx, how's collision handled? What is the point in getting devices to collide here instead of making this MTS part of CAP and letting devices freely use CAP as already defined. This is useless and adds unnecessary complexity

SuggestedRemedy:
Remove lines 8:22 on page 151 and all references to "MTS/GTS with BC/MC-SA" from the draft


Comment:
What is the point in having slotted aloha access in addition to the backoff in CAP, TDMA in CFP? Why is this complexity being thrusted on the implementors of this "low cost", "low complexity" and "low power" standard? I don;t see any justification in having yet another access scheme with WPAN.

SuggestedRemedy:
Remove slotted aloha scheme in 8.4.3.4 and all references to it from the draft.


Comment:
Another "special case" as admitted in line 29. Why should power management create a special case for every corner of this standard? What justification is there to add this mega-complex scheme into the so called low-cost standard?

SuggestedRemedy:
Remove lines 29:38 on page 159 Simplify power management to the following - Request for sleep time by DEV - Accept/Reject by PNC - Broadcast the addresses of sleeping DEV in Beacon - Allocation/modification of GTS by PNC depending on who is awake


Comment:
This para referes to an "higher layer protocol" that takes the responsibility of tradeoff between multiple slots v/s power saving. Which higher layer protocol that is in existence has this feature? Where is it published? This entire section (8:13.1.1) is an illusion.  What happens when there are more than one device that is in EPS? doesn't all the devices except the first one have to wait for their GTS anyway no matter how PNC allocates GTSs?

SuggestedRemedy:
Remove 8.13.1.1 and Remove all references to "slot positioning" (example 8.13.2.2) from the draft Add a line in 8.4.3.1 as follows "PNC shall try its best to allocate the GTSs of all EPS power management devices first and then others. some of the exceptions to this are MTS for PNC commands, some Qos streams that need mulitple GTS within a superframe and requests from child/neighbor piconets"


Comment:
some more inconsistencies that can potentially lead to non-interoperable implementations

SuggestedRemedy:
1. line 48, page 163: change "assigned to it for reception." to "assigned to it for reception, and all the GTSs allocated for BC/MC reception"  2. line 49, page 163: change " within 25 percent of the slot time" to "within 25 percent of the slot time that does not show any channel activity as indicated by CCA"


Comment:
lines 11:12, page 164: tool? MTS or GTS is not a tool. it can be used effectively by devices to save power.


Comment:
This clause is a standing proof for the complexity of EPS. EPS is affecting control of network, quality of service for all DEVs, adding significant overhead through transactions related to EPS states and most importantly making PNC implementation very complex and an high-cost one. Transactions listed in figure-94, 95 and 96 provide this picture, although not completely.  Then there are combinations of EPS devices and additional traffic to EPS devs and exception conditions described in 8.13.3.8, 9 and 10 which further complicate the management of these EPS devices After all this complexity, 1. There is no mechanism described for BC/MC traffic from an RPS/EPS device to another EPS device is handled? 2. There is no mechanism described for isoch or asynch traffic flow from DEVs in one EPS set to DEV in another EPS set? 3. How does a DEV from one EPS set transmit to or receive from DEV from multiple EPS devices each being in different EPS set for other reasons?  Answer to this can be one of two things either (a) they use repeater service through PNC and/or (b) PNC, knowing who is asleep, avoids providing a GTS with that DEV as rx-DEV. In either of these case we do not need this highly complex mechanism. As the mechanisms get more complex and affect all the other aspects of the standard, there is an higher risk of creating corner cases which can not be visualized easily at the time of standard, but are certain to haunt us in the field. There are proven examples in this within 802-wireless standards. Let's learn from those examples and avoid any one mechanism to affect deeply all the other mechanism in the standard. OR for any mechanism to be too complex that the implementors do not implement it, but instead they are forced to find some other solution. In any case, I am absolutely convinced that the EPS mechanism asa defined in this draft does not belong in 802.15.3. It has to be absolutely, positively simplified before we move further with this draft.

SuggestedRemedy:
Simplify power management to the following - Request for sleep time by DEV - Accept/Reject by PNC - Broadcast the addresses of sleeping DEV in Beacon - Allocation/modification of GTS by PNC depending on who is awake


Comment:
Table 73 has some "ms". please make them Kus for ease of implementation

SuggestedRemedy:
Table 73 has some "ms". please make them Kus for ease of implementation

Response:
The committee has decided to change all Kus to ms as previously agreed. It was felt that there is liitle advantage to use Kus (1024) instead of ms (1000) for these values.


Comment:
The current power managment clauses 8.13 through8.13.3.12 introduce a level of complexity to make them unsuitable for implementation in a WPAN.


Comment:
The text between lines 41 and 47 describing how the PNC determines the availablity of a more suitable channel is incorrect.

SuggestedRemedy:
See text in doc 02/037 for details regarding a more reasonable approach to determining the suitability of another channel.


Comment:
The text in clause 8.11 between lines 28 and 41 leaves out essential functional information required to establish a repeater function among DEV-2, PNC/DEV-1, and DEV-3.

SuggestedRemedy:
See the repeater function clause in doc 02/037 for a detailed resolution.


Comment:
The message sequence chart in figure 92 is inadquately illustrates the Repeater function protocol.

SuggestedRemedy:
The Message sequence chart provided in the MLME_REPEATER MSC clause of doc 01/410r1 provides a much clearer illustration.


Comment:
The message sequence chart in figure 93 illustrates a Dynamic channel selection process that is broken.

SuggestedRemedy:
The MLME-CHANNEL-STATUS, MLME-REMOTE-SCAN, and MLME-CHANGE-CHANNEL msc clause in doc 01/410r1 provides a much better Dynamic channel selections process that does not require the PNC beacon to go silent while devices are transitioning to the new channel.


Comment:
The sentence fragment in line 47 is incorrect: "Each DEV in a piconet shall use probe request command,..."

SuggestedRemedy:
Please change the sentence fragment to: " Each DEV in a piconet shall use the Device-Information-request command,..." where Device-Information-Request was previously known as Probe-request.


Comment:
All references to Probe-request/response between lines 17 and 38 are incorrect.

SuggestedRemedy:
Please replace all references to Probe-request/response between lines 17 and 38 with DEVICE-INFORMATION-REQUEST/RESPONSE.


Comment:
The text between lines 42 and 45 contains these sentence fragments which are no longer needed "... with a reason code."

SuggestedRemedy:
Remove the indicated sentence fragments from clause 8.3.3.


Comment:
The message sequence chart in figure 83 illustrates a broken association protocol.

SuggestedRemedy:
The MLME-ASSOCIATION message sequence chart in clause 6.3 illustrates a validatable association protocol.


Comment:
The message sequence chart in figure 84 provides another perspective of the   broken association protocol.


Comment:
The text between lines 17 and 33 describe an broken Association process.

SuggestedRemedy:
Text in the Association clause of doc 02/037r0 provides a detailed resolution to this problem.


SuggestedRemedy:
Please change to Broadcasting PNC information.


Comment:
The PNC handover process illustrated in this figure  is poorly represented.

SuggestedRemedy:
The MLME-Handover message sequence chart in doc 01410r1 provides a much clearer representation of the handover function.


Comment:
The PNC selection process described between lines 32 and 38 on p138, lines 26 and 33 of page 139, and lines 1 and 11 of page 140 is inefficient and broken.

SuggestedRemedy:
the PNC challenge and handover clause in doc 02/037r0 contains detailed text describing a more efficient approach.


Comment:
Text between lines 50 and 54 of page 137 and lines 1 and 22 of page 138 describing the scanning and piconet startup process is broken.

SuggestedRemedy:
The scanning clause and the Start Piconet clause of doc 02/037 describes in detail the resolution to this problem.


Comment:
In the first column, the word 'alternate' is misspelled.


Comment:
As stream transmission need not be inturrpted during coordinator handover, it would be useful to add that the PNID remains the same.

SuggestedRemedy:
insert text ', using the original PNID,' between the words 'beacon at'.


SuggestedRemedy:
Insert 'new client' before 'association address...'.


SuggestedRemedy:
Change 'configuration' to 'configured' change 'process' to 'process,'


Comment:
This speaks of 'during the renegotation operation'.  I find the negotation in Annex B (informative).  The negotation should be in the main text..  Confusing.


Comment:
What is an EPS set?  How is it defined? When does it come into existance: when the Dev makes or send the PNC configuration operations or when the PMC established the basic timekeeping operations?


Comment:
Says that reassociation is not required (after successful PNC handover).  However, 10.3.3.3 (page 184) says that after PNC handover 'each device shall authenticate'. Authentication comes before association, therefore reassociation is required. Note: contridiction.


Comment:
General comment: I believe that the power management section is confusing and overly complicated.  While low power consumption is a key goal of 802.15.3, the ability to reliably interoperate using a power save mode is dependent on a clear and consice standard.

SuggestedRemedy:
Clarity needs to be brought to the text before technical merit can be adequately assessed.


Comment:
It is difficult to understand that the following sentence A is described after the sentense B. A: Indicated coordinator-announcement timeout B: First Beacon transmission time after the indicated timeout The figure seems correct but 3 kinds of "timeout" including "Indicated Timeout", "Indicated new TImeout" and "Indicated coordinator-announcement Timeout" confuse the situation.

SuggestedRemedy:
Clarify the description as well as replace "coordinator" to "PNC".


Comment:
There are 2 descriptions of "alternative coordinator". They should be AC.


Comment:
neighbor alternate coordinator should be neighbor AC.


Comment:
There is a possibility of duplicate network id's.  A device will check to see if there are any similar ids but this search cannot be 100% sure, additionally, a PAN may walk into another's coverage area.  I did not see any detection nor resolution of this event

SuggestedRemedy:
describe the techniques to detect network id duplication and the procedures to resolve it.


SuggestedRemedy:
replace 'If there are no alternate PNCs are available' to 'If there are no alternate PNCs available'


SuggestedRemedy:
replace 'PNC selection command' with 'PNC announcement command'


Comment:
There is no DEV information table in 7.5.1.4


SuggestedRemedy:
replace 'a association request' by 'an association request'


Comment:
bw_random(retry_count) is there two times

SuggestedRemedy:
combine the 2 descriptions or delete one


SuggestedRemedy:
reference to 8.6 but should be 8.4?  Have MAC people verify.


Comment:
add some words to exclude open scan mode ... as shown below

SuggestedRemedy:
While searching, and not in open scan mode, if the DEV receives ...  (the reason is we need to prevent our equipment from joining the neighbors piconet)


Comment:
Several editorial problems with Figure 78 ... see below

SuggestedRemedy:
1. In the first column, the word "alternate" is misspelt 2. in the 4th column, relace "New" with "new" 3. In last column, the arrows are too long, shorten the arrows


Comment:
line 17 (going into line 18) refers to a table in clause 7.5.8.  There is no table in clause 7.5.8.


Comment:
Both in the CAP and the CFP, a response frame (ACK) transmission over the medium shall start within a SIFS duration after the end of the transmission of the previous frame for which the response is intended.  From table 76, the SIFS is between 10 uS and 11 uS.

SuggestedRemedy:
The above sentence from line 22 is not clear.  Does it mean the ACK has to start between 10 uS to 11 uS after the previous frame - or - does it mean the ACK has to start <10 uS after the previous frame.  If the meaning is the latter than this becomes the RX-to-TX turnaround time that should be used in clause 11.2.6.2.  MAC & PHY committee to advise.


Comment:
This comment supplements as suggestion for adding stream management command in section 7.5.10.3, page 133 for final confirmation or acceptance of stream connection.  One of the primary purposes of the stream connection process is to determine if the originator and the target agree on a single set of QoS parameters.  As currently proposed the communication flow is: Originator->PNC->Target->PNC->Originator. The originator will then reply to only to the PNC only if it rejects the Targets modified QoS values. The trigger that starts PNC generation of time slots should be a response from the Originator to the PNC conThe stream connection process involves the PNC to determine if it can provide the GTS slot allocation requested, and the two peers must agree on a set of QoS parameters.  As currently proposed the communication flow is Originator->PNC->Target->PNC->Originator. The originator will then reply to only to the PNC if it rejects the Targets modified QoS values. The trigger for PNC generation of time slots should be a response from the Target to the PNC confirming acceptance of the final QoS parameters relayed from the Target, not the absence of any negative response.

SuggestedRemedy:
The following is a rewrite of lines 12-27 on page 153.  Either the sending DEV or the intended recipient DEV for the new stream may send a stream management command with the request for stream connection. The process of stream connection is illustrated in Figure 88. In this figure, DEV A is the originator of stream connection request and DEV B is the target, consistent with the stream management command section 7.5.10.3.  In all stream management communications from the PNC to the other involved DEV, the PNC appropriately changes the value of the direction field to imply the same direction of the stream as originally requested.  The values for direction, security, stream type and priority shall be non negotiable and are decided by the DEV A that is sending the stream connection request. These values shall not be changed anytime after the first transmission of the command frame containing the request for that stream.  The target DEV B responding to the forwarded stream connection request may modify the remaining QoS parameters including bandwidth and latency requirements.  All the bandwidth and latency related requirements of the stream shall be confirmed or rejected by the originator of the stream connection request in response to the final PNC acceptance message. The PNC decision on the values of the stream QoS parameters that are supported in the piconet shall be final. If the originating DEV A does not accept the PNCs final stream parameters, then DEV A shall send a stream management command to the PNC with action type set to disconnection/rejection as specified in 7.5.10.3. Then the PNC shall then send a stream management command to the target DEV B with action type set to disconnection/rejection. Otherwise, DEV A shall send a stream management command with a final confirm/accept action type, and the PNC shall then begin generating ACTIVE type CTA elements and GTS timeslots as specified upon receipt of this command.


SuggestedRemedy:
I don't understand why we need a aMinHandOvrTO ... have MAC folks verify it is needed.  If not then delete.


Comment:
In line 21 we have a parameter aMaxHandOvrTO

SuggestedRemedy:
Question is what happens if aMaxHandOverTO occurs.  Refer to the clause in the text where the next action is indicated after a time out.  MAC folks.


Comment:
On a coordinator handover, do all the authentication certificates also transfer or does each DEV need to re-authenticate?

SuggestedRemedy:
Add text after line 29 to clarify.  Security folks.    (BTW - I hope all the certificates transfer).


Comment:
Line 7 refers to a "DEV information table" in clause 7.5.1.4

SuggestedRemedy:
Clause 7.5.1.4 does not contain any tables.  Where is the table located?  Assign to MAC subcommittee.


Comment:
The paragraph starting at line 10 and ending at line 17 is not consistent.  The first two lines of this paragraph set down conditions under which a PNC SHALL handover control.  But then in the last sentence, we have this "re-authentication issue" that says a PNC running security, under some conditions,  "should not" perform a PNC handover.  Can't have it both ways folks ... need to fix this paragraph.

SuggestedRemedy:
Refer to Security/MAC committees for resolution.


Comment:
It will help to clarify by adding the actual address

SuggestedRemedy:
association address (0xFE), 7.2.3, as the ...


Comment:
In the line straddling line number 39, we are instructed what the PNC is to do if the request is not accepted.

SuggestedRemedy:
MAC folks ... add a sentence to indicate what the neighbor is suppose to if the request is not accepted.


Comment:
There is no point in having a reference to authentication in clause 8.3 that simply says "go see clause 10".

SuggestedRemedy:
Please remove the words "and authentication" from the 8.3 clause heading and completely delete clause 8.3.1.  Add the appropriate clause to the security section; that is, in clause 10.0


Comment:
Need to indicate that the MTS can also be used for association.  Modify as shown below.

SuggestedRemedy:
... during the CAP or MTS of an existing piconet.


SuggestedRemedy:
Replace the words "Both in" with "In both"


Comment:
Line 52 refers to a "CAP mode field" that is in clause 7.4.2

SuggestedRemedy:
There is not CAP mode field reference in clause 7.4.2.  What is meant here?  Refer to MAC folks.


Comment:
grammatical - add definitve article two places

SuggestedRemedy:
Rewrite as ...  ... for that channel-time with the PNC.  When the PNC grants ...


Comment:
Is believe that line 2 also needs to reference the MTS slot but I need the MAC folks to verify this.

SuggestedRemedy:
Should line 2 read ...  ... DEV shall use only the CAP or MTS for sending ...  (If this still is not correct then how do we fix this sentence?)


Comment:
The paragraph between lines 38 and 45 implies that the DEV knows where the MTS's are located by passive monitoring.  Should this be explicitly stated?


Comment:
modify line 28 to reflect a tolerance and not an absolute

SuggestedRemedy:
... to be less than or equal to +- 25 ppm.


SuggestedRemedy:
... allocations contained in the beacon to start ...


SuggestedRemedy:
... desires to source and sink, including those ...


SuggestedRemedy:
... the involvement of the intended receiver ...


SuggestedRemedy:
... retransmission window, the samller of ...


Comment:
In general Figure 88 is in poor shape.  The font appears distorted and the arrows are falling on top of text.  This figure needs to be corrected.


Comment:
... for the connection of the stream.                                                                                                                                                                   R_ALFVIN-NOTE: THIS COMMENT WAS SUBMITTED INCOMPLETE AS SHOWN.                                                                                R_ALFVIN-NOTE: THE COMMENT TYPE WAS NOT SELECTED BY THE SUBMITTER.


Comment:
In the shaded box at the bottom of Figure 89, modify the text as shown below

SuggestedRemedy:
Rest of the sequence follows as if the sender of the stream intiated the stream connnection process, as shown in Figure 88.


SuggestedRemedy:
... to the othre DEV via the same command.


Comment:
add a reference to clause 7.2.1 ... suggested text below.

SuggestedRemedy:
... in the frame control field (clause 7.2.1) set to "1".


Comment:
grammatical ... replace the phrase "at all" with the word "then"


Comment:
In general, this paragraph deals with sending the delayed ack.  The sentence at line 18 that beguns "However the recipient ..." since it implies a DEV should send a delayed ACK at the expiration of the retransmission window.  My question is this ... do you sent this at the expiration only if not previously send or do you send it again regardless.

SuggestedRemedy:
MAC committee to comment and clarify text if necessary.


Comment:
In line 46, reference is made to "the negotiated retransmission window".

SuggestedRemedy:
Please add to the sentence reference to the clause where this negotiation is described.  (assigned to MAC committee)


Comment:
grammatical ... add a comma as shown below.


Comment:
Grammatical ... modify the sentence as shown below.

SuggestedRemedy:
In addition, the DEV may use the probe request ...


Comment:
This sentence describes an algorithm with an exponential increasing time interval.

SuggestedRemedy:
Does this algorithm need an upper limit on the time delay.  MAC committee to provide comment.


SuggestedRemedy:
Power management ... what is the reference that describes the process of returning a DEV to the EPS mode.


Comment:
There are a number of problems with the paragraph starting at line 42, of which the most serious is a reference to a wrong command.

SuggestedRemedy:
On line 47 the probe request command is found at clause 7.5.4.1, not at 7.5.8.1.


Comment:
There are a number of problems with the paragraph starting at line 42, of which the most serious is a reference to a wrong command.  I'd suggest the following modifications:

SuggestedRemedy:
1. at the end of line 43, put the word "optional" so as to read "support optional rates" 2. at the end of line 44, put the word "optional" so as to read "supported optional data rate" 3. at the end of line 45, put the word "optional" so as to read "supported optional rates" 4. in line 47, change to ... piconet shall use the proble request ... 5. in line 47, the clause reference is 7.5.4.1 (not 7.5.8.1) 6. in line 48, change to ... that it is interested in establishing communications. 7. in line 48, change to ... each DEV shall periodically use the channel ... 8. in line 49, change to ... from other DEVs of interest ... (replace the phrase "that it is interested") 9. in line 50, ... transmissions to those other DEVs. (replace the word "that")


SuggestedRemedy:
... repeater service reject command (7.5.6.3) to the PNC.


Comment:
grammatical ... delete the phrase "in return"

SuggestedRemedy:
... provide their channel status via the channel status ...


Comment:
In the opening line of the paragraph starting at line 41, we are informed of a desire to quiet the piconet.

SuggestedRemedy:
The scheme to quiet the piconet, by stopping beacons, will not quiet pseudo-static GTS slots.  MAC committee to clarify if this is a problem and modify text if needed.


Comment:
grammatical ... add an s onto the word interval.


Comment:
The sentence starting on line 42 to 43 needs to be rewrite, as shown below.

SuggestedRemedy:
Within that quiet time the PNC may change to one or more other channels to check if one of the other channels are better than the current, after which it returns to the current channel.


Comment:
add reference to the association response command

SuggestedRemedy:
... association response command (7.5.2.2), the DEVs ...


Comment:
The sentence on line 49, starting with "The DEVs that ...", indicates a channel switch can take place.

SuggestedRemedy:
What happens to those devices that are in a power save mode.  Is this going to be a problem for them?  Power management to comment.


Comment:
A general comment about power management.  I can not support power management being mandatory; in other words, power management must be an optional mode ... not only for a DEV but also for a PNC.  A method must be included that allows a piconet to indicate that power management is not supported.  A DEV already has the option to not support power management.  One method to "not support power management" at the PNC level is:  1. In table 67, add a 9th action type value for the EPS action response command, and that is "EPS mode not supported"

SuggestedRemedy:
Modify table 67 as shown above and then add text to 8.13 at the end of line 31 that says:  In the case where a PNC does not support any power management mode, the EPS action response command "action type value" (Table 67) shall be value 9, "EPS mode not supported".  Those DEVs desiring RPS mode will not get slot assignments friendly to RPS mode of operation.


Comment:
In general, I can not support a power savings mode where a DEV "must" "pair up" with another DEV in some power savings "master-slave" mode of operation.  A DEV needs to have the option of telling another DEV "I don't want to do a power management mode pairing with you".

SuggestedRemedy:
I need input from the power management folks and then I'll be happy to generate the required text to indicate how a DEV declines power mode pairing with another DEV.  This text should be added to the introductory clause, 8.13.


Comment:
Reference to CAP without reference to associate MTS

SuggestedRemedy:
I need some help here from the MAC folks ... in paragraph 8.13.1, we reference an event relative to the CAP (lines 50 and 51).  Should this be rewritten to include the MTS ... for example, replace the two instances of CAP with  CAP --> CAP or associate MTS


SuggestedRemedy:
I need some help here from the MAC folks ... in paragraph 8.13.2, we reference an event relative to the CAP (line 47).  Should this be rewritten to include the MTS ... for example, replace the instance of CAP with  CAP --> CAP or associate MTS


Comment:
Completely delete the sentence locate between lines 14 and 15.


Comment:
Delete the line contained in line 23, the one that begins as "This is provided ...".


Comment:
Reference to "power resources as dictated by the DEV-host".

SuggestedRemedy:
I don't understand what this means (see above).  Please clarify the sentence, prehaps with an example.  Assigned to power management folks.


Comment:
The sentence starting at 53 is very wordy.  It can be improved as shown below.

SuggestedRemedy:
EPS devices operate either in an ACTIVE mode, where the EPS DEV is receiving each superframe, or in an EPS mode, where the EPS DEV receives information at a very much reduced rate.


Comment:
Delete the line contained in line 2 and replace with alternate text

SuggestedRemedy:
Delete the line starting with "There are three ..." and replace with "Three illustrative usage scenarios are:"


Comment:
Enumerate the three parameters contained between lines 4 and 15 as shown below

SuggestedRemedy:
1. The first is a scenario where ...  2. A Second requirement is an application ...  3. A third application is for a persistent ...  (note: include the nurmeric bullets)


Comment:
In the three paragraphs between lines 4 and 16, delete the following sentences:

SuggestedRemedy:
At line 6, delete the sentence beginning with "Both the transmitting ..."  At line 10, delete the sentence beginning with "This doesn't suggest ..."  At line 14, delete the sentence beginning with "This uses the EPS ..."


Comment:
Delete the sentence starting in line 20 as "The information in this ..."


Comment:
For the paragraph contained between lines 23 and 26, rewrite as shown below.

SuggestedRemedy:
DEVs, operating as EPS "sets", determine the basic operating EPS parameters at a peer-to-peer level and configure the PNC so that it provides the necessary tinekeeping operations.  Annex B provides informative text on how EPS-hosts provide setup information through the MLME interface.


Comment:
We talk about EPS sets ... but this is still vague.  Perhaps a figure should be added to illustrate the concept.  This figure should go into clause 8.13.3.1.

SuggestedRemedy:
The figure can be generated with help from the Power Management subcommittee


SuggestedRemedy:
... time base for periodic EPS time slots.


SuggestedRemedy:
in line 34 ...  ... using the EPS Action request command ...


Comment:
In clause 8.13.3.3 we see terms such as WAKE beacon and WAKE superframe.  In clause 8.13.3.1 a figure needs to be generated that helps visualize how these beacons & superframes are used in the EPS mode

SuggestedRemedy:
Help is needed by the power management committee to generate this figure.


Comment:
The paragraph between line 39 to 47 needs to be rewritten.  A suggestion is shown below.

SuggestedRemedy:
Figure 94 is an illustration of the EPS control process.  THe EPS action request command (7.5.7.1), and EPS action response (7.5.7.2), initiate the configuration process.  THe EPS action request command parameters are EPS set, EPSTime and EPSNExt.  A DEV which wants to form an EPS set shall issue the EPS action request command using the EPS set parameter to request a new set and provide the parameters of EPSTime and EPSNext.  The EPS action response command from the PNC shall provide an EPS set value that is not in use.  Following this exchange, additional EPS set members may request and receive acknowledgement that they have joined the EPS set.  This is followed by use of the DEV to PNC PS infomration command (7.5.7.3) to provide the parameters PowerManagementMode and PowerManagementPriority to the PNC.


Comment:
Modify the sentence between lines 49 to 53.

SuggestedRemedy:
Once the configuration process is complete, DEVs shall remain in the ACTIVE mode awaiting further commands.  A single DEV may select EPS mode as described in 8.13.3.6.


Comment:
The text between lines 1 to 9 need to be rewritten.  Suggest text is shown below.

SuggestedRemedy:
EPS configuration between DEVs occurs following association as required by changing requirements. DEVs requiring a change in EPS operation that will change EPSTime and EPSNext shall return to ACTIVE mode during the renegotiation operation.  An EPS action request command requesting EPS set termination shall be issued by the last DEV in an EPS set using the parameters EPSTime and EPSNext.  A DEV requiring EPSTime and EPSNext information for a specific EPS set may use the EPS action request commmand.


Comment:
Figure 94 needs to be reformatted.  Also, replace the "place in set" with "add to set".


Comment:
Rewrite the paragraph between lines 51 to line 2 on page 167.

SuggestedRemedy:
A DEV shall be a member of at least one EPS set prior to the creation of the EPS CTA.  A DEV, which is a member of an EPS set, may issue an EPS CTR indicating the number of the EPS set to which it belongs.


Comment:
On bullet number 2 ... what is meant bu N such that a proportion 1:N?

SuggestedRemedy:
Power management to clarify and rewrite this sentence.


Comment:
Rewrite the sentence that begins with "If the value of N ..."

SuggestedRemedy:
Replace with ...  "For example, if the value of N ..."


Comment:
Rewrite the sentence that starts with "If instead, the value of N ..."

SuggestedRemedy:
Suggest the following ...  "Likewise, if the value of N is 4 then 1 EPS ..."


SuggestedRemedy:
... or null CTA identifies that the EPS DEV shall listen to this beacon and that ...


SuggestedRemedy:
at the end of line 21, rewrite as shown ...  ... a member of the specified EPS set,


SuggestedRemedy:
... containing the reject code indicating "not a member of the requested EPS set" as shown in clause 7.5.10.3.


Comment:
Figure needs to be reformatted to remove change bars.  Also, in the second phrase on the right is the word "[repeating] ... what does this mean?

SuggestedRemedy:
What does [repeating] mean?  Refer to Power Management committee.


SuggestedRemedy:
after the word "network", place a comma ...  ... member of the network, that has missed ...


SuggestedRemedy:
... CTA blocks that have the time-beacon ....


SuggestedRemedy:
in line 17 ==> ... EPS mode, the EPS set ...  in line 18 ==> ... create the EPS CTSs and time slots ...


Comment:
In figure 96, on the last message exchange

SuggestedRemedy:
should the last message go from the PNC and terminate at DEV B instead of DEV A.  Refer to Power Management committee.


Comment:
In clause 8.13.3.8 new terminology is used to describe combinations of EPS DEV; that is, master and slave.  This concept needs to be introduced in clause 8.13.3.1 with prehaps a figure.

SuggestedRemedy:
Power Management committee to provide introductory figure.


Comment:
In line 170, reference is made that the "PNC shall save these for the next superframe".

SuggestedRemedy:
Does this mean these have to be buffered by the PNC?  Refer to the power management folks.  How is the size limit of this buffer specified?


Comment:
Line 10 indicates that the EPS DEVs recognize an error condition.

SuggestedRemedy:
How is this done?  Via Table 2 ReasonCode?  The ReasonCodes in Table 2 are not defined.  Refer to Power Management folks.


SuggestedRemedy:
Reference to clause6.3.1 should be 6.3.1.1.


Comment:
Line 12 refers to a "recovery operation"

SuggestedRemedy:
Where is this recovery operation described.  Supply reference clause.


Comment:
provide explicit reference to the tables.

SuggestedRemedy:
A list of the rules are specified in Tables 71 and 72.


SuggestedRemedy:
For the SIFS parameter, the value is defined in 11.2.6.1 (not 11.2.6.2)


SuggestedRemedy:
For the parameter aMinTPCLevel, the value is defined in 11.5.9


SuggestedRemedy:
In Table 73, for the parameter aFragThreshold, the value is shown to be "DEV chooses this value".  In this case, this should be added to the MAC PIB in clause 6.5 as MACPIBFragThreshold.


Comment:
PHY dependent parameters that should be defined in clause 11

SuggestedRemedy:
The following three items should have values that are PHY dependent and should be defined in clause 11 as added clauses 11.2.9, 11.2.10, and 11.2.11.


Comment:
This clause neweds to be rearranged.  Clause 8.6 is mentioned before clause 8.5  Also, Clause 8.9 and 8.3 are not mentioned.

SuggestedRemedy:
DEescribe clause 8.5 before 8.6 and add a description of 8.9 and 8.3.


Comment:
The text should elaborate on the Non-CAP case, especially with regards to processing time for the beacon. If the CAP is not present there must be a gap or unallocated time slot allocated to allow all deviecs to process the information in the beacon. If the amout time is not specified, a PNC may assign slots before a device can interpret its CTA.

SuggestedRemedy:
Indicate in the text that a minimum size CAP will be assigned even for the MTS only case, where the CAP will serve only as a gap between the Beacon and the GTS slots.


Comment:
There does not appear to be a guarantee that MTS only mode will have the same performance as a network with a CAP

SuggestedRemedy:
Either a minimum latency in superframes must be specified or some equivalent to the CAP should be provided to insure that devices can communicate with the PNC in a timely fashion.


SuggestedRemedy:
The term AC should be changed to child piconet PNC or child PNC for all instances.  If this is confusing, then the term child piconet representative might be considerd.


Comment:
DEVs use passive scan to detect an active piconet, but they COULD also use passive scan to detect interferers like 802.11.  This would help coexistence.

SuggestedRemedy:
Add the mechanism to scan for interference as well as just scanning for piconets.

Response:
PROPOSED ACCEPT IN PRINCIPLE. The proposed informative Annex (00000r0P802-15-3-Annex_Coexistence.pdf) has a description of the coexistence methods that are available in the draft. Also see 02/041r2 for a presentation and additional text on this issue. For 802.15.4 compatibility see subclause 6.9 in 00000D13P802-15-4__Draft_Standard.pdf.


Comment:
Piconet randomization does not address if the PNID is the same each time the piconet starts, or if it chooses a different random PNID each time.

SuggestedRemedy:
Clarify if each PNC calculates the same random number each time they generate a PNID, or if it is different each time.


Comment:
Should clarify that aCSFrameRepeat is an integer.

SuggestedRemedy:
change from "command for at least aSCFrameRepeat" to "command at least aCSFrameRepeat times"


Comment:
Why bother with PNC selection at all?  Now that we can do handover if a better PNC shows up, Just wait a random time and start sending out beacons.  This would be a much simpler process.  Also, the odds of turning on a bunch  of machines all at the exact time is small

SuggestedRemedy:
Eliminate PNC selection and simplify by just waiting a reandom amount of time then start sending out beacons.  Then, handover if more qualified PNC.


Comment:
"If during the life of a piconet the PNC decides to leave the piconet," should say "If during the life of a piconet the PNC decides to leave the piconet or a more capa ble PNC joins the piconet,"

SuggestedRemedy:
"If during the life of a piconet the PNC decides to leave the piconet or a more capa ble PNC joins the piconet,"


Comment:
If each DEV is only alowed to transit one frame at a time during the CAP with backoff time applied to every frame, then what is the "CAP MaxBurstDuration" in 6.3.12.1 used for

SuggestedRemedy:
Get rid of CAP MaxBurstDuration in clause 6.3.12.1


Comment:
Transmtting station needs to allow for Guard Time.

SuggestedRemedy:
Change sentence to "If an Imm-ACK is expected for that frame, the remaining time in CAP needs to be large enough to accommodate the current frame, 2 SIFS periods and the Imm-ACK frame at the same PHY rate as the transmitted frame and the guard time.


Comment:
The pseudo random sequence consists of integers and not bits.

SuggestedRemedy:
Change to:"Note that the current state of the PRNG should be maintained and subsequent backoffs should use subsequent integers in the pseudo-random sequence."


SuggestedRemedy:
Specify when retry counter is decremented.  I think there is disagreement about this.


SuggestedRemedy:
Change to: "However, the PNC uses the channel time grant command and coordinates the channel time grants with the CTAs in the beacon."


Comment:
Using the CAP for delayed ACK is a bad idea.  Should allocate a GTS.

SuggestedRemedy:
Alwasys allocate a GTS for delayed ACK frames.


Comment:
Random Noise will also cause Beacons to be received in error.

SuggestedRemedy:
Chang esentence as follows:"This may not happen to the same DEV all the time but may happen to different DEVs at different times depending upon their location and type of interference to which they are subjected, as well as random nooise."


Comment:
Need to be clear that a DEV that does not hear the Beacon cannot transmit during dynamic GTS, but it can still listen.

SuggestedRemedy:
Change the sentence as follows: "If a DEV did not receive the beacon, it shall not transmit in any dynamic GTSs during the CFP but it can still receive."


Comment:
Remove this entire paragraph.  The use of channel time grants for stations that cannot hear the NC well is no longer needed.  It has been replaced by pseudostatic GTS slots.


SuggestedRemedy:
We need to explicitly state how guard time is used or teh TDMA scheme will not work.


Comment:
Private GTSs will always be pseudo-static.

SuggestedRemedy:
Change to "Private GTSWs will always be pseudo-static GTSs,"


Comment:
Devs are synchronized to the Beacon interval, not the PNC's clock.

SuggestedRemedy:
Change to "All DEVs within a single piconet shall be synchronized to the Beacon Interval."


Comment:
This sentence makes it sound like a DEV only needs to stop transmitting once no beacon is heard for ATP diration.  The DEV still needs to follow the rules for dynamic or pseudostatic GTS.

SuggestedRemedy:
Add the following sentence between "PNC." and "If a DEV":  If a Beacon is not correctly received, a DEV shall forllow the rules for transmitting in a GTS, depending on whether it is a dynamic or pseudo-static GTS.


Comment:
Need to add that the DEV will send a Beacon Lost MLME to the DME to indicate that the Beacon is lost and the DEV is disassociated.

SuggestedRemedy:
Add the following: "The DEV shall send the BeaconLost.indication MLME to the DME to indicate that the Beacon has been lost.


Comment:
"All the bandwidth and latency related requirements of the stream shall be negotiated between the sender of the stream and the PNC. The PNC decision on the values of the stream QoS parameters that are supported in the piconet shall be final."

SuggestedRemedy:
The PNC knows nothing about bandwidth.  It only knows about channel time.  I don't think these QoS parameters should be negotiated at the MAC, but if they are the other DEV should have the oportunity to negotiate the values down.


Comment:
Fragmentation ad defragmentation should not be in the MAC.  It will overly complicate the designs and require large per-stream buffers.  Fragmentation should be done at the convergence layer.

SuggestedRemedy:
Move Fragmenation to the convergence layer.


Comment:
"within a SIFS"  needs clarification.  In some places it says that ACK comes before a SIFS and others it says after a SIFS.

SuggestedRemedy:
Throroughly describe be the ACK timing with a detailed description including SIFS complete with drawings.


Comment:
Need to specify that non-stream data cannot used delayed ACK

SuggestedRemedy:
Add the following sentence:  "Non Stream data cannot use the delayed ACK policy for a couple of reasons.  There is no opportunity for the reeiving DEV to negotiate the window size.  Also, since all non stream data uses stream number zero, they all use the same sequence number counter so delayed ACK is not possible."


Comment:
"The start of transmission of the response data frame shall start at the end of a SIFS, like an Imm-ACK frame transmission."  This is inconsistent with the previous section which says that Immediate ACK is sent within a SIFS.


Comment:
Movee this sentence:  "A collision during the transmission of a directed frame in the CAP is detected by the absence of the acknowledgement for that frame." to the first paragraph is 8.8.5


Comment:
Transmitting station must wait for immediate ACK time plus 2 SIFS to retransmit

SuggestedRemedy:
Change the sentence as follows:  "it shall wait for the duration of Imm-ACK frame plus two SIFSs before attempting another transmission."


Comment:
DEVS cannot reject a delayed ACK.  This must be from when we were calling them "retransmission requests"

SuggestedRemedy:
Change the paragraph as follows:  "When Del-ACK is used for a stream, the DEV transmitting the data frame may abort retransmssion attempts once the negotiated retransmission window for the stream has been reached. When retransmissions are aborted, the DEV transmitting the stream shall send transmission sequence sync command, as defined in 7.5.9.2, to the recipient of the stream in order to synchronize the delayed-ACKs."


Comment:
The DEV should not have to do a probe to determin eht PHY capability for the DEV it wants to communicate with.  That is in the DEV infor table that is broadcast by the PNC.

SuggestedRemedy:
Change as follows:  "Each DEV in a piconet shall check the DEV capabilities from the device information table that is broadcast by the PNC when a DEV associates  to obtain the supported rates from other DEV(s) that it is interested in communicating.


Comment:
Should point out that the PNC broadcasts the device information table after association.

SuggestedRemedy:
Add the following sentence:  "After Association is complete, the PNC broadcasts an update of the device information table as described in 8.2.7."


Comment:
Should point out that the PNC broadcasts the device information table after disassociation.

SuggestedRemedy:
Add the following sentence:  "After Disassociation is complete, the PNC broadcasts an update of the device information table as described in 8.2.7."


Comment:
The PNC should wait until after the authentication if authentication is required for the piconet.

SuggestedRemedy:
Add the following sentence: "If autentication is required for the piconet, the PNC shall wait until after authentication is complete to broadcast the device information table.


Comment:
"to that other DEVs" should be "to the other DEVs."


Comment:
ACK feedback can be used to determine if rate or power change is required.

SuggestedRemedy:
Add the following sentence:  "Additionally, the channel quality can be judged by the presence of ACKs on transmitted frames.  This ACK feedback can be used to determine if rate of transmssion or the power level needs to change."


Comment:
Immediate ACK has no frame body, only a header.  Since the header is always transmitted at the base rate, the table should say that Imm. ACK is transmitted at base rate.


Comment:
There is no mention of what happens to repeater service when handover occurs.  Since there is no reasona ble way to know if the new PNC link will be adequate, all repeater service should be dropped when PNC handover occurs.

SuggestedRemedy:
Add the following sentence: "When PNC handover occurs, all repeater service is discontinued and must be renegotiated with the new PNC."


Comment:
It is not clear how a DEV or the PNC knows what rate to transmit at when Repeater Service is used.  If the DEV is transmitting to BOTH the DEV and the PNC as is described here, It may choose the lowest rate, even though the link to the PNC may be very clear.  This will waste resources.  Likewaise, the PNC won't get ACKs from the receiving DEV, so it will not be able to monitor the quality of the link from the PNC to the receiving DEV.

SuggestedRemedy:
Delete repeater service althgether because it will be too complex to implement.  Repeater service should be left to the upper layers to implement.  That way immediate ACK can be used between the devices and the PNC.


SuggestedRemedy:
replace 'Figure and Figure 100' by 'Figure 99 and Figure 100'


Comment:
Table 75 shows two frequency plans.  How does a DEV know which frequency plan to use with a Piconet?  Is there a default frequency plan?  How does the PNC change the frequency plan if the 802.11b coexistence is needed?

SuggestedRemedy:
Refer to PHY subcommittee.  There will have to be commands added to the MAC to accommodate frequency plan switching.  Also, since the only frequencies in common are 2.408 and 2.468 GHz, all Piconets will have to start on one of these two frequencies and then switch to either the 5 frequency plan or the 3 frequency plan.

Response:
ACCEPT IN PRINCIPLE. Document 02/041includes addional discussion of how to apply the frequency plans when 802.11b networks are detected. The MLMEScan and MLMEStart commands include selection of channel sets to utilize. Since a channel set is scanned completely, it does not matter on which channel that scan starts. Piconets are only started once the scans are completed and a determination of channel status has been obtained.
There is no default frequency plan.


Comment:
Table 89 indicates that in the USA operation is under Part 15.249.  Given the changes in Part 15.247 (removal of processing gain) would this PHY qualify for operation under part 15.247?

SuggestedRemedy:
If part 15.247 is legal, increase the max output power in line 19 of page 211, clause 11.5.9.


Comment:
Need to complete reference to clause 6.6.1

SuggestedRemedy:
The regulatory domains are enumerated in a vector called PHYPIB_RegDomainSupported (6.6.1) and are indicated by the parameter PHYPIB_CurrentRegDomain.  The domains are mapped to PHYPIB_CurrrentRefDomain as 0x00=Europe, 0x003=Japan, 0x01=USA and 0x02=Canada.

Response:
ACCEPT IN PRINCIPLE. Use this text:

The regulatory domains are enumerated in a vector called PHYPIB_RegDomainSupported (6.6.1) and are indicated by the parameter PHYPIB_CurrentRegDomain.


SuggestedRemedy:
As indicated by Table 41, this is PHYPIB_Type value 0x00.

Response:
PROPOSED REJECT. This information in already defined in clause 6. Does not need to be defined in two different places.


Comment:
Clause 11.2.2 is misleading for deployment within the USA.  FCC Regs 15.249 indicate that the measurement of interest is 50 uV/meter at 3 meters; hence, just measuring at the antenna input is not conclusive.  If the power level is reduced by the amount of the maximum antenna directional gain then this is accurate.  Also, assuming a 0 dBi antenna is ok but a cop out.  For example, if the antenna is very inefficient (lossy) then you can actually increase the RF input power to the antenna to compenate for the antenna loss since the type acceptance metric is field strength measurements.

SuggestedRemedy:
A note needs to be added that indicates the implementor needs to refer to the rules of the country of deployment since type acceptance testing may require field strength measurements that are not the same as antenna input power.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Change "power measurement," to "power measurement for the purpose of this standard,"
Also, 11.5.9 already states that the transmit power shall conform and be measured as defined by regulatory bodies.


Comment:
Clause 11.2.3 indicates there are two frequency plans.  What is the basis for picking one frequency plan over the other?  How is this selection made?  Is it done by the DME or is it done at manufacture time?  If it is done by the DME then how is having two frequency plans supported by the PLME and the PHY PIB?

SuggestedRemedy:
PHY group to comment and clarify.  Text may need to be generated for clause 11.2.3 to clarify.

Response:
PROPOSED ACCEPT IN PRINCIPLE. See resolution of 1109.


Comment:
The data in this section needs to be tied to the PHY PIB.  This can be done as shown below.

SuggestedRemedy:
PHYPIB_NumChannelsSupported = 3 or 5 (apparently it has two values)  PHYPIB_CurrentChannel=1 or 2 or 3 (or 4 or 5) as shown in first column of table 75.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Number of channels supported is 5. PHYPIB_Current Channel is CHNL_ID of the current channel. This is applied to table 93.


Comment:
The table in clause 11.2.3 (Table 75) indicates an IEEE802.11b coexistence mode that puts the 802.15.3 transmissions directly on top of the 802.11b channels.  This is called coexistence mode.  I fail to understand how deliberately putting 15.3 transmissions on 802.11b channels is a coexistence mode.  Clause 11 needs a complete subsection that discusses coexistence with existing 802 PHY types in the 2.4 GHz band, especially given that the GTS slot assignments DO NOT listen before transmitting.  One suggestion is that even through a DEV has a GTS slot assignment, it still must listen before transmitting and reframe from transmitting if the channel is in use.  This "channel in use" data can be indicated back to the PNC by a command packet and the PNC can try to find a new channel.  The importance of coexistence, and the serious consideration being made by ExCom and SA, are exemplified by the comments that were generated by the first rejection of 802.15.1 by the SA.

SuggestedRemedy:
PHY committee to reconvene to work on coexistence mechanisms for 802.15.3 and supply text for letter ballot approval.  I'd withdraw this comment if the MAC and the PHY were split into two separate letter ballots.  Sample text can be found in TG4 draft text D13, in clauses 6.9.2 and 7.5.1.  These are copied below for reference.  6.9.2 802.15.4 2.4GHz as interferer The 802.15.4 devices have several characteristics that improves its coexistence with other wireless devices operating in the 2.4 GHz band. 802.15.4 devices are intended for low duty cycle applications (typically less than 1%) using CSMA/CCA mechanism for collision avoidance. Furthermore, it is defined to operate in two possible frequency bands (868/915 MHZ and 2.4 GHz). Finally, the low transmit power will minimize their effect on other 802.11/802.15 compliant devices.   7.5.1 Channel Access All devices must use the radio channel in such a way as not to obstruct the transmissions of other devices, which may already be transmitting. The mechanism for handling this requirement is called Carrier Sense Multiple Access - Collision Avoidance (CSMA-CA). A device wishing to transmit using CSMA-CA must first sense the channel for radio activity. If no activity is detected, the device may transmit. If activity is detected the device should back-off for some random period before beginning the CSMA-CA procedure again. A device that senses activity on the channel, repeatedly, a specified number of times may not transmit its message regardless but should consider its transmission attempt a failure. All transmission should abide by the CSMA-CA channel access mechanism.

Response:
PROPOSED ACCEPT IN PRINCIPLE. See comment 1109 for resolution. The PAR will not allow us to split the MAC/PHY ballot. See 00000r0P802-15-3-Annex_Coexistence.pdf and 02041r2P802-15_TG3-Coexistence-capabilities.ppt. Rick Roberts will be providing additional text.


Comment:
Temperature Range ... seems ok for in the house but how about outside deployment, such as a PDA that has been lying in a car.

SuggestedRemedy:
PHY committee to consider increasing range from -20 to +40, or some suitable range given outside deployment.

Response:
PROPOSED ACCEPT IN PRINCIPLE.  This was considered in detail by the committee, and the current values reflect the appropriate minimum requirements without adding excessive cost to all 802.15.3 implementations. This is the type I temperature range of 802.11b.


SuggestedRemedy:
remove the hypen in the word "transmitted"


Comment:
It was suggested previously in this letter ballot that the following items be PHY dependent.  They should be added to clause 11.2.

SuggestedRemedy:
11.2.9 MaxTransferUnitSize 11.2.10 MinSuperFrameDuration 11.2.11 MaxSuperframeDuration

Response:
PROPOSED ACCEPT IN PRINCIPLE. 11.2.10 MinSuperFrameDuration 11.2.11 MaxSuperframeDuration

Note: MaxTransferUnitSize is a MAC to LLC description.


Comment:
Add the following text at the end of the paragraph.

SuggestedRemedy:
The data rates are respectively the entries to the PHYPIB_DataRateVector.


Comment:
Last three Kmod values are missing the left bracket.


Comment:
Rewite part of the sentence as shown below.

SuggestedRemedy:
In the table, the term +jw shall be defined ...


SuggestedRemedy:
... in Figure 99 and Figure 100, respectively.


Comment:
"If the decision is made by the PNC to change the channel, the PNC shall keep the piconet quiet by not transmitting any beacon for one or more beacon interval."  The quiet command was eliminatd before pseudo-static GTS slots were introduced.  With pseudo-static GTS a DEV is allowed to transmit even if it does not hear a liminted number of beacons.  The quiet command should be added back.


Comment:
Instead of "PNC stops sending beacons"  should say "PNC issues quiet command and stops sending beacons"

SuggestedRemedy:
Change "PNC stops sending beacons"  to "PNC issues quiet command and stops sending beacons"


Comment:
How is broadcast traffic handled when a device is in EPS mode?  Is the PNC forced to perform repeater service to every DEV that is in EPS

SuggestedRemedy:
Need to decide how to handle broadcast traffic when devices are in EPS mode since TCP/IP uses broadcast.


Comment:
If anything RPS should be a state, not a mode.  No DEV should ever listen to GTS slots that are not assigned to it, so there is no difference between EPS and ACTIVE mode.


Comment:
Remove this sentence "ACTIVE mode devices may use the capabilities defined in RPS mode to provide a modest power reduction."  This only proves that ACTIVE mode and EPS mode are one and the same.

SuggestedRemedy:
Remove this sentence (along with RPS mode).


Comment:
I asked many hardware designers both at XtremeSpectrum at other companies if the position of the GTS close to the beacon would have any impact at all on power savings.  The answer I got was a unanimous "Any power savings from GTS slot location in the superframe will be negligible."


Comment:
Delete all of clauses 8.13.2, 8.13.21.1 and 8.13.2.2.  There is no need to have an RPS mode since it is identical to PM_OFF mode.


Comment:
"For DEVs configured for EPS mode of operation, specific operation of channel time allocation is necessary for both EPS mode and when EPS DEVs operate in ACTIVE mode."  According to Table 2, ACTIVE is an EPS status not a mode.  Modes are EPS (RPS) and PM_OFF.  Mixing the terminoloogy makes this cluse impossible to read.

SuggestedRemedy:
Remove all references to "ACTIVE mode" and replace with "ACTIVE state"


Comment:
"When both initialization and channel time allocation is complete, then clause 8.13.3.5 describes the operations that allow data transfer for EPS DEVs."  Does this mean that clause 8.13.3.5 does not describe anything until both initialisation and channel time allocation is complete?

SuggestedRemedy:
Change to:  "Clause 8.13.3.5 describes the operations that allow data transfer for EPS DEVs when both initialization and channel time allocation is complete."


Comment:
I am not sure what this is supposed to mean: "The value of N such that a proportion 1:N of EPS time slots that will be of that length."

SuggestedRemedy:
Reword so that it is readable: "The value of N specifies the fraction of EPS time slots (1/N) that will be of that length."


Comment:
"For EPS channel time requests, N = 0 is a special case in which the PNC shall create all EPS CTA slots with zero length. The zero length, or null CTA identifies that the EPS DEV shall listen to this beacon, and that the EPS DEV does not have GTS time allocated for data transmission."  I don't understand this at all.  If N=0, then every superframe has a CTA with duration 0?  Why make an exception like this and not say channel time =0 and N=1?

SuggestedRemedy:
Clarify what is meant by this paragraph.


Comment:
fixed maximum power applies to the CAP, and to shared and association MTSs.

SuggestedRemedy:
Change to: "systems, a fixed maximum power in the CAP and shared and association MTSs, and adjustable power in the GTS."


Comment:
"Communicating with the GTS" should be "communicating within the GTS."

SuggestedRemedy:
Change "Communicating with the GTS" should be "communicating within the GTS."


Comment:
Title should be "Fixed maximum transmitter power for CAP and beacon and Shared MTSs"

SuggestedRemedy:
Change title to "Fixed maximum transmitter power for CAP and beacon and Shared MTSs"


Comment:
the chosen power level should be the closest on that is greater than the requested one.

SuggestedRemedy:
Change to "change is not supported by the other DEV, it shall use the closest implemented TX power level that is greater than the requested level provided that is within the allowable range."


Comment:
This exxample fails to point out that rate and power level are related.  If the power level is significantly higher than required, the first thing that should happen is that the receiver should ask the transmitter to tranmit at a higher rate to conserve resources.

SuggestedRemedy:
In this example, point out that the transmitting DEV is already transmitting at the highest PHY rate supported by both DEVs before reduucing power.


Comment:
aMinChannelScan should probably be twice the MaxSuperframeDuration


Comment:
A AssocRespConfirmTime of 5 ms is too short.  There may not be any CAP or GTS slot time to respond and the PNC may be busy.

SuggestedRemedy:
Change  AssocRespConfirmTime to 2 superframe durations.


Comment:
aProbeResponseDelay of 8 ms is too short.  Should be at least 2 superframe durations.  But, responding DEV may have no channel time.

SuggestedRemedy:
Increase aProbeResponseDelay to 5 superframes.


Comment:
8196 octet aMaxTransferUnitSize of 8196 octets may sound like a lot, but we should increase it to 65536 octets for future PHYs.

SuggestedRemedy:
change aMaxTransferUnitSize to 65536 octets


Comment:
512 us is too short for aMinSuperframeDuration.


Comment:
If we change aMaxSuperframeDuration to 65535 us, then we can use 1 uS resolution.

SuggestedRemedy:
Change a MaxSuperframeDuration to 65535 uS


Comment:
Need to add a text on how asynchronus data will be efficiently handled.

SuggestedRemedy:
Need to aspecify how asynchronous data will be handled in a scheme that is both power and bandwidth efficient.


Comment:
A complex power management solution has been specified, but we need a very simple approach that will be useful for very low power devices that are not.  If the current apprach stays it sould be optional, and we should add a low-complexity solution as an alternative.

SuggestedRemedy:
I will be proposing a low complexity power management solution.


Comment:
"The information in this primaiive"  does not agree with the previous sentence which was taling about primitives.

SuggestedRemedy:
change to "The information in these primaiives"


Comment:
If the ACTIVE bandwidth needs to be reserved for these EPS devices, why complicate the protocol by adding these mechansisms?  Just allocate the channel time, and let the DEVs not use it until they need it.

SuggestedRemedy:
Simplyfy power management by just allocating the needed channel time and then letting the DEVs not use it if response time is absolutely critical.


Comment:
I don't see anything in Annex B about how the EPS-Hosts provide anything through the MLME interface.


Comment:
The beacon count of the next awake beacon for every member of the EPS set will not be synchronized.  By the time the requestor gets the information, the Beacon pointed to may already have passed.  The requesting DEV will think that it has to wait for 2^16 cycles of the beacon counter.

SuggestedRemedy:
Find a way to eliminate the need to use a frame request that ties to real time data like a beacon number.


Comment:
This could be better written: "Once configuration as defined in this clause, and presented in Figure 94, Illustration of EPS control process is complete, DEVs shall..."

SuggestedRemedy:
"Once configuration of the EPS control process is complete, as defined in this clause and presented in Figure 94, DEVs shall...  "


Comment:
"awaiting further commands."  Are they waiting for command frames or for MLME.requests from the DME?

SuggestedRemedy:
Clarify  what type of commands they are waiting for.


Comment:
It is not clear that the lone DEV creates and uses its own EPSSet.

SuggestedRemedy:
Clarify if a lone DEV creates it's own EPSSet.


Comment:
If a DEV goes into it's own EPSSet, how doesn anyone else ever communicate with it?  Do they have to request a GTS to put them into AWAKE state so they can interroget them? What happens if a broadcast message like an ARP comes in?  Doe EPS DEVs ignore broadcast?

SuggestedRemedy:
Need to explain how another DEV communicates with a Solo EPS dev.  Does it as for a CTA to each Solo EPS DEV?


Comment:
"Any DEV using the same EPS Set have a WAKE superframe" should say has

SuggestedRemedy:
change to "Any DEV using the same EPS Set has a WAKE superframe"


Comment:
If higher layers are setting up the EPS Sets, how does a new DEV find the EPS set to join?  Does it have to wake up every single EPS DEV in every EPS set in order to find the DEV with the higheer layer "master or peer" that it wants to talk to?

SuggestedRemedy:
Need to add text to explain how a new EPS DEV finds the higher layer entity that it wishes to communicate with.


Comment:
Can the PNC overbook CTAs for DEVs in EPS state?   If so, what happens if there is no chanel time available when a DEV wants to switch to use teh ACTIVE CTA?

SuggestedRemedy:
If this can happen, we need a command to tell the upper layers "Channel tiem not currently available."


Comment:
"The size of teh EPS time slots used for data" - what does "used for data add to this sentence?  Id there part of the EPS time slot that is not used for data?

SuggestedRemedy:
Change to "The size of the EPS time slots"


Comment:
"wake beacon" is discussed without being defined.  It is defined in the definitions, but it needs an introduction in the text


Comment:
EPS mode has states ACITVE and EPS.  ACTIVE is not a mode according to Table 2.  This type of inconsistency makes this clause unreadable.

SuggestedRemedy:
Be consistent: ACTIVE and EPS are EPS States.  They are not modes.   EPS and PM_OFF ate PowerManagementModes.


SuggestedRemedy:
Do a globeal change to be consistent what is EPS mode, and what is EPS state.   Be consistent: ACTIVE and EPS are EPS States.  They are not modes.   EPS and PM_OFF ate PowerManagementModes.


Comment:
EPS is so complex that I am afraid that no one will implement it.  Also, the number of commands, MLME parameters, states, etc is overwhelming.  The complexity is overkill for a WPAN.  I will propose something that meets the requirements with much lower complexity.


Comment:
Is renegotiation N-way, if there are N DEVs in the EPS set?  N way negotiation will be very complex.

SuggestedRemedy:
Describe if this is just peer to peer negotiation, N way negotiation with the N DEVs in the EPS set.


Comment:
"An EPS action command requesting release shall be used by the last DEV in an EPS set to remove the EPS set time keeping of EPSTime and EPSNext from PNC activities."  I am not quite sure what this is trying to say.

SuggestedRemedy:
Here is my attempt to simplify:  An EPS action command requesting release shall be used by the last DEV in an EPS set.  The free the PNC from the EPS set time keeping of EPSTime and EPSNext.


Comment:
How do you know what EPS Sets are active?  If you want to interrogate all DEVs in all EPS sets, you first have to know what EPS sets are active.  I don't see a way to ask for the set of active EPS sets.

SuggestedRemedy:
Need a command and MLME to request which EPS sets are active (in use).


Comment:
"by the PNC" doesn't add any value.  All Beacons are from the PNC.

SuggestedRemedy:
Eliminate "by the beacon" from both line 51 and 52


Comment:
Need to clearly explain the relationship between The EPS CTRB parameters of slot size and N, and the EPS set time of EPSTime.

SuggestedRemedy:
Please clarify the relationship.  A picture would be helpful.


Comment:
"DEVs are associated and operations of Figure 95 have been completed."  This is in FIgure 95

SuggestedRemedy:
I think that this should be Figure 94, but who knows.


Comment:
"If a DEV does not have an ACTIVE or EPS slot in a particular superframe,"  Does this mean a slot where it is the source or destination, or only where it is the source.


Comment:
Can any DEV that is not a member of an EPS set make a request for active channel time with an EPS DEV?


Comment:
Can the PNC negotiate EPSTime and EPS N.  IF not, and all EPS sets choose a different EPSTime, periodically they will all occur on the same beacon and may use a tremendous amount of channel time.

SuggestedRemedy:
Address what happens when all EPS Wake beacons happen together.


Comment:
If we are not specifying randomization, we should not have a shall in the section.

SuggestedRemedy:
The section should read "The seed for generating a randomized PNID should include the 48-bit PNC device ID in order to aid in the likelihood of a unique PNID, however the randomization process required to choose a unique PNID is beyond the scope of this standard."  Comment via Ari Singer.


Comment:
1. It appears that there is not much difference between Neighbor piconet and Child piconet. A DEV can still request to asscociate with a PNC if it can not find a free channel.   2. Fig. 82 is the same as Fig. 81 if the association process of child piconet is taken into account.  3. Fig. 80 is the same for both child and neighbor piconet.  4. No communication between PNC of neighbor piconet and parent piconet provides doesn't seem to provide additional merits for operations of WPAN  5. What's the reason for limiting the no. of neighbor piconet to 3 special AD-DA?

SuggestedRemedy:
Remove 8.2.6 neighbor piconet and all related materials in the draft standard.

Response:
PROPOSED REJECT.  The neighbor piconet is to allow networks that either are not 802.15.3 compliant or do not wish to join with the resident piconet to effectively share the channel with resident piconet. This is one of the 802.11b coexistence methods required.


Comment:
What is the meaning of private GTS in terms of various fields in CTRB(Fig. 72) for using channel time request command to setup a child piconet? Suppose stream index=0, what are appliacable values for others?

SuggestedRemedy:
Clarify the meaning of "private GTS" and usage of channel time request command for child piconet

Response:
PROPOSED ACCEPT IN PRINCIPLE. In 8.2.5, following "private GTS." add "A private GTS is a GTS that has the same source and destination DevID." Also insert in 5.3.7 following the first occurrence of "private GTS". Add the following information in 8.2.5: "In the channel time request command, the CTRBtype shall be set to active, the EPSset parameter is not used, the stream index shall be set to 0, the remaining parameters are set to the time required to contain the child superframe, and are discussed in B.2."


Comment:
RPS mode appears to be an implementation issue. It doesn't require commands exchange with PNC.

Response:
PROPOSED ACCEPT IN PRINCIPLE. RPS mode will be removed. Informative text concerning the ability of a DEV to only be active when  required to receive or transmit will be kept in the draft.


Comment:
This paragraph falls short of mentioning that streme connection is not completed until DEV receives Beacon from PNC with CTA. Fig. 3, 4 should be referred instead of using Fig. 88, 89, which do not give the complete process.

SuggestedRemedy:
Modify text that matches MSC of Fig. 3 and 4

Response:
PROPOSED ACCEPT IN PRINCIPLE. Delete Figure 88. Replace the cross references to 88  with Figure 3. Figure 89 refers to a PNC initiated stream between two other DEVs.


Comment:
This is a general comment on the Quality of service clause. There is a lack of introduction, relationships to rest of draft, helpful diagrams, and mention of EPS power management QoS.

SuggestedRemedy:
Provide additional text on introduction, relationships to rest of draft, helpful diagrams, and if possible at least a xref to power management QoS of 8.13.


Comment:
Stream index should be 8-bits in length, not TBD.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Clause deleted. Defined in 7.2.4.


Comment:
A figure showing the elements of the QoS parameter set would be helpful for a reader trying to determine parameters that will be set.

SuggestedRemedy:
Include frame format figure for QoS parameter set


Comment:
TBD in "b) Stream index: A unique value, TBD bits in length, used to identify a connection and to associate it with an active service flow." needs to be changed to 16 bits.  Was supposed to be changed in D09, but got missed.


Comment:
The clause on QoS policies is incomplete and provides little useful information that is not already present in other clauses.  In addition, it relies on an SFID which occurs in only one other place in the draft (in a figure in Annex A.)  In addition, although provisioned service flows are indicated, none are defined.  This entire process should be left to the implementer anyway.

SuggestedRemedy:
Since the definition is incomplete and relies on a non-existent parameter, the clause should be deleted.


Comment:
This clause seems to be standing by itself with no support from other clauses, neither is it seem to be supporting any other clause in the draft. BTW, it also uses lot of terms that are not used anywhere else (example SFID)

SuggestedRemedy:
There are two options here. 1. Remove this clause 2. For every description (flow, paramter, mechanism) connect them with its relavant counterpart in clauses 6, 7 and 8 (most importantly 7 and 8).

Response:
PROPOSED ACCEPT. Clause 9 will be removed. Remove references to SFID in Figure A.3 and other occurrances.


SuggestedRemedy:
MAC committee needs to resolve the TBD in line 31


SuggestedRemedy:
provisioned and active.  (no comma after provisioned)


SuggestedRemedy:
remove commma as shown below ...  ... service flow is one which has been ...


SuggestedRemedy:
... the PNC has not yet reserved the QoS ...


Comment:
rewrite sentence lin line 46 as shown below ...

SuggestedRemedy:
... QoS parameters, the benefit of which ...


SuggestedRemedy:
An active service flow is one which has ...


SuggestedRemedy:
In addition, an active service flow is one which has a non-NULL set of ActiveQoSParameters and one which indicates that the PNC has reserved the piconet resources requested.


SuggestedRemedy:
instead of "created from scratch" use "originated"


Comment:
The stream index is undefined and of an unknown length.

SuggestedRemedy:
At a minimum, define the length of the stream index.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Clause 9 has been deleted. The length of stream index is defined in 7.2.4.


Comment:
How QoS is maintained during PNC handover or an abrupt termination of PNC functions (e.g. PNC unplugged)?

SuggestedRemedy:
Think about this and propose a solution or point me to it.

Response:
PROPOSED ACCEPT. In case of PNC handover, streams are maintained as defined in 8.2.4. In case of PNC unplugged, there is no remaining piconet so QoS is lost. See 5.5.6. Section 8.5 defines what a DEV does when it fails to see a beacon.


Comment:
The difference between service flow ID and Stream Index is not clear.  Why do we need both.

SuggestedRemedy:
Clarify the difference between service flow ID and Stream Index.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Clause 9 has been deleted.


Comment:
PNC does not allocate bandwidth, only channel time.


SuggestedRemedy:
Remove or correct dangling reference. i.e. change "DEV,10.3.1.3" to "DEV".


Comment:
More complete explanation of Authentication of a DEV to the piconet is required.

SuggestedRemedy:
Add the Message Sequence Chart for successful DEV authentication figure from document 02033r0 to this section at line 33. Replace text in lines 30-32 on page 185 with the following: "When a device wishes to join a secure piconet, it must authenticate to the PNC.  The authentication process starts with an authentication request.  When the PNC receives the authentication request, it checks to see if it is willing to allow that device into the piconet and, if so, it generates a challenge for the DEV so that it can prove it is who it claims to be.  If the DEV provides a legitimate response to the challenge, the PNC sends back a confirmation that the DEV may join the piconet."

Response:
PROPOSED ACCEPT IN PRINCIPLE. Add the Message Sequence Chart for successful DEV authentication figure from document 02033r0 to this section at line 33. Replace text in lines 30-32 on page 185 with the following: "When a device wishes to join a secure piconet, it shall authenticate to the PNC.  The authentication process starts with an authentication request.  When the PNC receives the authentication request, it checks to see if it is willing to allow that device into the piconet and, if so, it generates a challenge for the DEV so that it can prove it is who it claims to be.  If the DEV provides a legitimate response to the challenge, the PNC sends back a confirmation that the DEV may join the piconet."


Comment:
This section does not describe how authentication may fail due to a timeout.

SuggestedRemedy:
Add message sequence charts from 02033r0 for "Timed out Authentication (DEV side)" and "Timed out Authentication {PNC side)" to this section following the normal authentication MSC.  Add following text prior to (DEV side): "When the DEV attempts to authenticate to the PNC, it sends an authenticate request.  Until the authentication process is completed, the DEV is not granted the rights of an authenticated DEV, so the DEV should not wait indefinitely to get an authentication response from the PNC.  While the DEV is waiting for the authentication response, it may participate in a challenge response protocol with the PNC or it may not.  In either case, if the DEV does not receive an authenticate response within a reasonable amount of time, the MLME shall return a timed out response after which the DME may choose to attempt a new authenticate request or choose not to authenticate to the PNC." Add the following text prior to the (PNC side): "During the authentication process for a particular DEV, the PNC sends a challenge to the DEV for it to prove it is who it says it is.  As with any other time a challenge is sent, the PNC sets a time limit for how long it will wait to receive the response.  One reason for this timeout is to free up the resources of the PNC that are being used to save the state of the challenge protocol.  If the challenge times out, the PNC shall send an authenticate response message to the DEV informing it that the authentication process failed."


SuggestedRemedy:
Change "If the PNC in the ..." to "If the PNC is in the ...".


Comment:
Security description seems to be incomplete.

SuggestedRemedy:
Complete description of security interoperation for all of the designated security options that will be supported.


Comment:
The word ad-hoc is spelled incorrectly here, subclause 10.1.2, page 178, line 3, and subclause 10.2.2, page 179, line 13.

SuggestedRemedy:
Ad hoc (please, no hyphen) has been an English word for over a hundred years (and yes, it has to do with Latin).  Change all occurences of this word to ad hoc.


Comment:
The note numbered list states "Notes:", most of the notes up to this page in the D09 are "Note that..." vs. "Notes: ...".  The issue is normative vs. informative; respectively.

SuggestedRemedy:
I defer to the Editor but it is likely that it should be changed to "Notes that...".  If you choose to leave as-is then remember - Notes always start with the word "NOTE" in capital letters, followed by a dash, and are set in 9-point type.


Comment:
This section is interesting, but distracts from the requirements of this clause.  Move everything up to, but not including, 10.2.2 to an informative annex that provides the rationale for the security implementation.  Also move 10.3.2 through 10.3.3 to the same area


Comment:
Since we can assume physical control of the DEVs in a PAN as well as close proximity, we should allow the verification of the public keys to use a physical connection combined with a user action.

SuggestedRemedy:
Add an enumeration item:  "3) Physical contact with user intervention: This provides a method for the public key certificates to be passed from one DEV to another without using the wireless link.  The user intervention would be required to complete the process, either by pressing a combination of buttons or in response to a prompt from the DEV.  In this case the trusted part is the user who has physical control of both DEVs."


Comment:
The external trusted part has not yet been defined.

SuggestedRemedy:
Indicate that the external trusted part is defined by the cipher suite.


Comment:
The formal language is out of place here.  The definition of the required action occurs later in the clause.

SuggestedRemedy:
Change "each DEV shall" to "each DEV will"


Comment:
Only need to re-issue keys if the DEV was authenticated as well as associated.

SuggestedRemedy:
Change "in the piconet." to be "in the piconet if the DEV that is disassociated was also authenticated in the piconet."


Comment:
Some message sequence charts would really help explain the security operations.

SuggestedRemedy:
Add MSC's that reflect the formal language in the sub-clauses.


Comment:
This subclause does not belong here. it is better suited in clause-5


Comment:
This section is described as if this is a requirement without any details, whatsoever, on the actual algorithm used for authentication and privacy. Without those two mechanisms the reader can not comment on the description provided in this clause since depending on the algorithm these descriptions ought to change.

SuggestedRemedy:
Specify authentication and privacy algorithms.


Comment:
Three equally key promises of 15.3 are high bandwidth, low cost and low power consumption.  Of these, high bandwidth is the key differentor, opening the door to the possibility of rich multimedia applications. However, rich multimedia brings with it a strong requirement for high security (to protect enhanced digital video  content). 15.3 does not yet specify a security system with assured interoperability between implementations. Without assured interoperable security, the usefulness of 15.3 for transporting protected digital content in a consumer environment will be severely limited.

SuggestedRemedy:
A default (single) encryption system must be unambiguously specified. Additional encryptions options are acceptable.


Comment:
Refers to identity of 'its communication party'.  Is this a person or a host deevice?

SuggestedRemedy:
Clarify.  If it is a host device, what assurance is there that the (new) device should be allowed to enter the network?  i.e., device could belong to a neighbor.


Comment:
From this, I believe that a device establishes its identy in na 'stand alone' fashion (i.e., true identity is established at the factory).  However, to join a piconet, the ownership of the device is what is at question.  How is that established.


Comment:
Security, to protect artistic intellectual property of rich multimedia content, is key to the widespread adoption of 802.15.3 in a multiplicity of home consumer products. This draft does not provide a default baseline encryption algorithm through which different implementations of 802.15.3 can securely communicate. It is important that a single baseline algorithm be selected. Multiple options, increasing the cost of implementation, can not replace a default system.


Comment:
As it is well understood, security is one of the most sensitive subjects in the wireless communications. Even though the mechanism using security suites is described in the current draft but there is no clear default mode description. Secured environment is made by a solid decsription including the very first association.  Otherwise, it may fall another prey of criticism from the industry.

SuggestedRemedy:
Need to specify a default security mode.


Comment:
This section, Characteristics of the IEEE 802.15.3 WPAN; seems to be out of place, it's a duplicate entry.


Comment:
The security section looks thin.  Specifically I do not believe that I can implement security according to this section in an unambiguous manner.

SuggestedRemedy:
Detail out the mechanisms to implement security in such a manner that interoperability will be assured.


SuggestedRemedy:
replace 'initial state, the it would' with  'initial state, it would'


SuggestedRemedy:
Instead of "Privacy and Security" call this section "Authentication and Security" and move all the authentication text out of clause 8.3.1 over to this section.


Comment:
Lacking detail on how authentication will be done for 802.15.3

SuggestedRemedy:
Security committee needs to provide details on authentication algorithm.


Comment:
In the sentence prior to line 2 we have a nice discussion about the external trusted party.

SuggestedRemedy:
Security committee needs to provide details on how this will be done for 802.15.3.


Comment:
Clause 10.3.3 hints at a security policy.  Is this section complete?  Is the security policy completely presented here?


Comment:
During a PNC handover, why can't the old PNC just vouche for all the authenicated devices when they are handed over to the new PNC?


SuggestedRemedy:
... back to its intitial state it would then ...


Comment:
Where is the cipher information.  In this line we talk about a cipher suite but I see no detail in clause 10.

SuggestedRemedy:
Security committee to supply detail on cipher algorithm.


Comment:
In lines 21, 23, 50 and 52 we see the phrase "cryptographic evidence" used.

SuggestedRemedy:
Security committee needs to define exactly what cryptographic evidence means to a WPAN.  This sounds like a strong term ... how is it implemented in a WPAN?


Comment:
In line 41, mention is made of public key and symmetric key techniques ... yet not details for provided for either.

SuggestedRemedy:
Security committee needs to provide the details on public and private key generation.


Comment:
In line 44 and line 45, mention is made of "key encryption key" and "entity authentication protocol", yet there are no details on either of these in the document.

SuggestedRemedy:
Security committee to provide details on key encryption key and also on the authentication protocol.


Comment:
In line 46, mention is made of a "separate key agreement protocol", yet there are no details on this protocol.

SuggestedRemedy:
Security committee to provide details on the "separate key agreement protocol".  Also, details on its usage.


Comment:
In line 53 (carrying over to the next page) there is a list of key types.  Please include in this list references to the document clauses that describe these key types.


SuggestedRemedy:
What is an integrity key.  How is it used and how is it generated.  This key is mentioned only in this sentence.  Security committee to supply the detail.


Comment:
Mention is made of a combined encryption and integrity key.

SuggestedRemedy:
No detail is supplied as to how these combo is used and how this combo is generated.  Security committee to supply the detail.


Comment:
In line 18 mention is made of a "list of authenticated DEVs".

SuggestedRemedy:
Where is this list kept?  In the PNC?  Does this list need to be specified in clause 6?  Refer to security committee.


SuggestedRemedy:
Add the word "is" ...  If the PNC is in the ...


Comment:
Mention is made that the PNC can be in the "authentication and encryption mode" ... where is this mode described?

SuggestedRemedy:
Security committee to provide clause reference for the "authentication and encryption mode".


Comment:
Mention is made of the "authentication process".

SuggestedRemedy:
Security committee to provide clause reference to the "authentication process".


Comment:
The standard does not include a specification for either authentication or encryption.

SuggestedRemedy:
Add a specification for both authentication and encryption.

Response:
PROPOSED ACCEPT IN PRINCIPLE. The draft will include directions on available cipher suites, the method of determine which cipher suite is used for a piconet, and the method used to incorporate a cipher suite to perform authentication and payload protection.


Comment:
objects are typically within 10 m apart, not around 10 m apart.

SuggestedRemedy:
Change to "moving objects that are typically within 10 m apart.


Comment:
General Comment:  Given that the entire piconet uses the same Keys, it is imperative that we choose a mandatory cipher suite as voted on in Austin.

SuggestedRemedy:
choose and document the mandatory cipher suite.


Comment:
We do authentication of the DEV, but not he owner or user.  We need to have some way of controlling access to the piconet based on the owner of the equipment.

SuggestedRemedy:
If access control is done at a higher layer, we need to at least provide the MLMEs to make it possible.


Comment:
Even if access control is provided at a higher layer for the piconet, we need some way to ensure that devices do not join the wrong piconet.

SuggestedRemedy:
Add a mechanism to control which piconet a DEV joins.


Comment:
We should make it cleat that the "communicating party" is the piece of equipment and not the human using it.

SuggestedRemedy:
Add text that makes it clear that the "communicating party" is the piece of equipment and not the human using it.


Comment:
met is probably not the best term to use.


Comment:
Need to add reference to the access control list.

SuggestedRemedy:
Change to "Regulation of admission of these DEVs requires evidence as to the true identity of the DEVs that comprise the piconet, and membership in the access control list."


SuggestedRemedy:
Change to "The authentication of the DEV will be based upon evidence regarding its true identity and proof that the DEV itself corroborated this evidence and that the DEV is also in the access control list."


Comment:
A low power DEV may belong to a piconet that has encryption on, but that DEV may wish to communicate without encryption to save power.  Sec is a field in the stream management.  We should allow streams to negotiate wheter they want to use encryption or not.

SuggestedRemedy:
Document the ability of DEVs to turn encryption off for a stream, or get the SEC bit out of stream management.


Comment:
Need to add text about access control list.

SuggestedRemedy:
Change to "Admission of a DEV to the piconet is based upon evidence regarding its true identity and proof that the DEV itself corroborated this evidence and teh DEV is in the access control list."


Comment:
If we are going to leave the Access control list to the upper layers, we need to add teh MLMEs

SuggestedRemedy:
Sorry if this is a repeat.  It is getting late (again)

Response:
PROPOSED ACCEPT IN PRINCIPLE.  We need to add the MSCs for the security related items (e.g., authentication, deauthentication, key distribution) and ensure that all the required MLMEs are present. The ACLs are outside of the MAC.


Comment:
The cryptographic evidence provided by the PNC and the DEV may give evidence of their identity, but identity alone doesn't necessarily permit a device to be in the piconet, or to act as a PNC. This decision is made on the basis of identity and other rules. Cryptographic evidence of identity isn't necessary or sufficient to identify the roles the devices are intended to assume.

SuggestedRemedy:
Change 2 bullets to: 1) The PNC shall have sufficient information to decide whether or not the DEV is authorized to join the piconet, and will have cryptographic material related to the DEV. 2) The joining DEV shall have sufficient information to decide whether or not the PNC is authorized to perform the role of security manager, and will have cryptographic material related to the PNC.  Comment via Ari Singer.


Comment:
The constraints described in this section are possible limitations and are discussed to give rationale about why we chose what we did and what dangers there are for implementers.  These are not strict constraints since not all devices will have these problems.

SuggestedRemedy:
Replace section title with "Security Limitations in an IEEE 802.15.3 WPAN".  Replace first line to: "The security of an 802.15.3 WPAN is dependent on the devices having certain properties.  When implementing 802.15.3 security in a device, the user should take into account the following possible constraints, which may limit the capability of the device to perform in a secure manner."  Comment via Ari Singer.


Comment:
Non-repudiation is more properly defined as "Prevention of an entity claiming that a DEV performed an action that it did not perform."  This is the other side of the coin of what is described in the text, but the point is that an entity that cannot deny it has done certain things also gets the benefit that it cannot be claimed that it did something that it did not do.


Comment:
If the piconet implements security, it always requires authentication (number 1) and sometimes requires payload protection (number 2), not just a combination of the two.

SuggestedRemedy:
Replace this line by: "The cipher suite in use determines the currently enforced security requirements.  If security is in use, the cipher suite shall enforce requirement 1 below and may enforce requirement 2."  Comment via Ari Singer.


Comment:
The heading is misleading and not accurate to the requirement.

SuggestedRemedy:
Change heading to "Payload protection for authenticated parties only."  Comment via Ari Singer.


Comment:
Requiring that the device not have a user interface for the input of secret keying material negates the possibility of using methods where a password/passphrase is input as a shared secret and that is used for keying material.  This may prevent the use of other mechanisms such as 802.1x and 802.11b security.

SuggestedRemedy:
Recommend the removal of the second sentence in this paragraph (leaving the parenthetical comment in some form may be okay).  Comment via Ari Singer.


Comment:
It is unclear whether this section is normative or informative, but it seems to imply the use of a certificate authority, which should not be a requirement in the standard.  The use of certificates and the method for verifying the validity of a public key should be outside the scope of the standard.  Some arguments for this point of view include: 1) If two devices do not share a common CA, they cannot set up a piconet using security. 2) Certificates should have limited lifetimes and be revocable in order to provide the expected security of certificates.  Since this section assumes that keys are never revoked, this limits the practical usefulness of certificates. 3) A device may want to act as its own CA and sign keys of devices it trusts rather than relying on an "external" trusted party. 4) A device may want to have a list of public keys that it trusts without using certificates.  Certificates have the drawbacks in that they are computationally more expensive to use than to not use and they may require more storage space than needed (even using implicit certificates).

SuggestedRemedy:
It should be made clear that this section is informative and other alternatives should be suggested such as low power PHY transmission, user interface input and 802.1x methods.  Comment via Ari Singer.


Comment:
Implicit certificates are simply a special form of public-key certificate that is proprietary to Certicom Corp.  There is no reason to explicitly describe them in the document as they provide exactly the same functionality as other certificates.

SuggestedRemedy:
Recommend removing this paragraph.  Comment via Ari Singer.


Comment:
It should not be required that the trusted party's public key be stored in each device at all, much less only at manufacture time.  This should be a recommendation for those using certificates, but not a requirement.

SuggestedRemedy:
Recommend (at least) changing "will" to "should".  Comment via Ari Singer.


Comment:
There may be more than one external trusted party (or none) and they may have control over different trust relationships.  The cipher suite determines what method is used to verify the authenticity of a public key, but this may or may not involve the use of an external trusted party.  In any case, the external trusted party is not a DEV role, so this role should not be included here.

SuggestedRemedy:
Recommend removing bullet 5).  Comment via Ari Singer.


Comment:
The role of the external trusted party is also beyond the scope of the document.

SuggestedRemedy:
Change to "Since this standard addresses PANs, the security implications of the roles of the portal and the external trusted party are beyond the scope."  Comment via Ari Singer.


Comment:
The external trusted party may not be outside the network and we need not require that it be external to the network.

SuggestedRemedy:
Recommend removing bullet 3).  Comment via Ari Singer.


Comment:
Discussion of the external trusted party should be made as general as possible and mention alternatives such as certificates, rather than stating what it will do.

SuggestedRemedy:
Recommend replacing the paragraph with "The security implications of the trusted party role should be addressed elsewhere and are considered to be out of scope."  Comment via Ari Singer.


Comment:
The security policy section should be informative rather than normative.  It is not always desirable to enforce the policy that every time a DEV times out or wishes to leave the piconet that the keys must be changed.  This is a good policy in most cases and should be encouraged, but it does not affect interoperability and should not be mandated.

SuggestedRemedy:
Remove all shall and will statements from this section and make it informative.  Comment via Ari Singer.


Comment:
The process for generating a public key and getting it registered with the external trusted party should be a recommended (alternative) method for initializing the public key on the device, not a mandatory method.

SuggestedRemedy:
The section should be called Security Initialization, rather than system initialization.  Once again, this section should be made informative, as it does not affect interoperability.  Comment via Ari Singer.


Comment:
Why must the mode of operation and the cipher suite be fixed over the life cycle of the piconet?  What if the PNC changes and needs to use a different cipher suite or mode?  This requirement does not affect interoperability and should be removed.

SuggestedRemedy:
Recommend deleting the final sentence in the paragraph.  Comment via Ari Singer.


Comment:
The 802.15.3 PAR Purpose states: "The data rate will be high enough, 20 Mbps or more...".  I am still unclear why the QPSK modulation type for 11 Mb/s is allowable.  Additionally, the subclause 11.3.1, page 190, line 14-15 sentence "The QPSK-TCM mode is implemented in assigned GTS slots to help maintain connections of devices that are in range of the PNC, but which may be more distant from each other." suggests that the 11 Mb/s is used to make the WPAN a WLAN.

SuggestedRemedy:
Please advise the WG and/or myself why an 11 Mb/s is part of the IEEE Std 802.15.3 and why the 802.15.3 PAR does not require a corrigendum to allow this fifth type.

Response:
ACCEPT IN PRINCIPLE. We are only required to provide at least 20Mbps, other data rates are acceptable. Base mode of the 2.4GHz PHY is 22 Mbps which satisfies the PAR. The mode is provided to allow devices on opposite sides of the PNC coverage range to directly communicate.


Comment:
The word "jurisdictions" is not advisable.

SuggestedRemedy:
I recommend the sentence "...jurisdictions that have allocated this band." be replaced with "...regulatory bodies that have designated this band.


Comment:
The words "air medium" are not advisable.

SuggestedRemedy:
I recommend the sentence ending "...through the air medium." be replaced with "through the common air interface."


Comment:
The following sentence does not end in a period: determined relative to the phase of the last symbol in the CAZAC sequence, 11.4.2


Comment:
The following sentence does not end in a period: defined in Table 82


Comment:
The following sentence does not end in a period: The minimum TX power level required to support TPC, aMinTPCLevel, shall be 4 dBm


Comment:
Add 15.247 to the list of applicable US standards if the NPRM for digital modulation is approved.


Comment:
The current cnannel arrangement cannot be use with the TX PSD in under US 15.249 rules.  Ignore this if the 15.247 NPRM on digital modulation reaches report and order.

SuggestedRemedy:
Change the channel locations to the following frequencies, 2412, 2432, 2442, 2451 and 2461, all in MHz.


SuggestedRemedy:
Add a row to the table that has:  RIFS   aCCADetectTime + aRXTXTurnaroundTime   11.6.5 and 11.2.6.2

Response:
PROPOSED ACCEPT IN PRINCIPLE. Add a row to the table that has:  RIFS   aCCADetectTime + aPHYSIFSTime in table 76   11.6.5 and 11.2.6.2.
APHYSIFSTime = 10 us to be defined in table 76.


Comment:
Add a reference for trellis coding here.

SuggestedRemedy:
Add a bibliograph reference following "with Trellis coding."  The reference is: Gottfried Ungerboeck, "Channel Coding with Multilevel/Phase and Signals", IEEE Trans. on Information Theory, Vol 28 January 1982.  Put this in the bibliography.


SuggestedRemedy:
Change description to 4-state if it is true (and throughout clause 11).  Otherwise leave it alone.


Comment:
The frame format shows and refers to the HCS as separate from the MAC header, but in clause 7 and most of the rest of clause 11, the HCS is considered to be part of the MAC header.

SuggestedRemedy:
Lots of changes here either way.  If we change the MAC header definition to exclude the HCS, we need to update other spots in clause 11.  Otherwise, the following modifications need to be made in 11.4.1:  Change "and appends this to the" to be "and inserts this into the end of the" in line 7, page 200 and change "and is appended this to the combined PHY and MAC" to be "and is inserted into the end of the MAC" in line 7, page 201.  Change the MAC Header boxes to be MAC Header - HCS for the first two rows of figures 107 and 108.  Delete the HCS boxes and + HCS in the other rows.  Change "Calculate HCS" to be "Calculate and insert HCS" in one place in each figure 107 and figure 108.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Change Figure 11 so that the MAC header does not include the HCS. In Figure 107 and 108, show the dummy HCS being passed down. Add the word insert as mentioned in the SuggRemedy. Change occurrances of MAC Header in clause 11 to be MAC Header + HCS as appropriate. E.g., change append to be insert into the dummy HCS field received from the MAC.


Comment:
Forgot to indicate that the header is repeated twice.

SuggestedRemedy:
Change "and MAC header, followed by" to be "and MAC header at the base rate, followed by a copy of the PHY and MAC header modulated at 11 Mb/s QPSK-TCM, followed by"


SuggestedRemedy:
Change 3 occurances of "MAC header and the HCS" to be "MAC header" on lines 35, 37 and 38.


Comment:
Change the encoding of the frame body length to be sent LSb first in b5 with the MSb at b15.

SuggestedRemedy:
Change as indicated and change the examples as well.


Comment:
While the trellis state is independent of the other bits, the symbol selection isn't.  Since it probably easier to find known symbols, lets define the last inputs as all zeros to the non-TCM portion.

SuggestedRemedy:
Indicate that the other bits (i.e. those not determined by the trellis encoder) shall be chosen to be 0 for the symbol selection.


SuggestedRemedy:
Delete the sentence "For the BPSK modulation, ... over the air."


Comment:
Should add EVM requirement for QPSK-TCM explicitly

SuggestedRemedy:
Change "DQPSK" to be "DQPSK/QPSK-TCM" in Table 87.


Comment:
It is not the standards job to require conformance to governmental regulations.

SuggestedRemedy:
Change "devices shall also" to "devices should also"


Comment:
Need formal langauge for the jamming requirements.

SuggestedRemedy:
Change "signal is to be" to be "signal shall be"


Comment:
Co-existance is very important in consumer products (refer ). While an alternate frequency plan, to enhance co-existance, is interesting, there seems to be no mechanism for automatically choosing a fewquency plan. Without some guidance in this area, it can not be said with assurance that an implementation conforming to this draft standard will have any degree of success in increasing co-existance.   Thus draft fails to meet an important and self proclaimed goal.

SuggestedRemedy:
Unfortunately, this comment is prepared while the deadline for comments draws near, preventing the extensive drafting required for an adequate solution.


Comment:
As we experienced at the ballot for 802.15.1, coexistence description need to be approached.  802.15.3 will not be an exception as far as we have 2.4GHz PHY.

SuggestedRemedy:
Need technical description for coexistence solution such as Dynamic Frequency Seleciton.


Comment:
We have a formatting problem on some symbol scripts.  The same problem is in line 47, line 51, 52, and 53.


SuggestedRemedy:
Input serial data = bn  Output serial data = sn  add bn and sn to the figure.


Comment:
Is this equation correct.  It does not seem to match Figure 110.  Figure 110 shows Xn as not being the quantity that bn is xor'ed with.

SuggestedRemedy:
Verify that the notation between Equation 7 and Figure 110 are correct.  Correct as needed.  Refer this to the PHY committee.

Response:
PROPOSED ACCEPT IN PRINCIPLE.  The figure does not reflect the equation. The figure will be corrected to reflect the equation.


Comment:
In Table 82 we have the notation "Seed value".  Is this the same as Xinit in equation 6.  If so, then be consistent on names.  Pick one name for the other.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Identify xinit as being the seed value.


Comment:
grammatical ... remove the "s" from the end of the word symbols as shown below.

SuggestedRemedy:
... of the bits/symbol that is to be used ...


SuggestedRemedy:
... added to the end of the frame body ...


SuggestedRemedy:
The math scripts in lines 31 and 33 are in need of reformatting.  Some of the symbols appear to be "chopped off".


Comment:
Font problems in table 86 on the right two column headings

SuggestedRemedy:
Please reformat the headings in the right two columns.


Comment:
This clause deals with the EVM.  Measurements are made on a "reference receiver".  It is well known that a reciever can cause EVM problems as well as the transmitter, so how does one define this "reference receiver"?  Do you deconvolve the EVM distortion caused by the receiver?

SuggestedRemedy:
PHY committee to comment on how a reference receiver is to be used.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Change 'reference receiver" to "ideal reference receiver" where used in clause 11.


Comment:
Table 93 contains reference to two PHY PIB values that do not exist.  PHYPIB_NumbTxPowerLevels and PHYPIB_PowerLevelVector are not in clause 6.

SuggestedRemedy:
The available PHY PIB values that deal with TX power are listed in clause 6.6.4.  Table 93 needs to be regenerated using the PHY PIB values of clause 6.6.4.  Assigned to PHY committee.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Already resolved in 1276.


SuggestedRemedy:
Add to table 93 PHYPIB_MPDULengthMax.  PHY committee to supply value information.

Response:
PROPOSED ACCEPT IN PRINCIPLE. In Table 47 change PHYPIB_MPDULengthMax to PHYPIB_FrameLengthMax and give it a value of aMaxFrameSize with a xref to 11.2.7 for the 2.4 PHY.


SuggestedRemedy:
Add the following text ...  Antenna diversity is an implementation specific issue.  For the PHY description of clause 11, it has been assumed that there is no diversiy; that is, PHYPIB_DiversitySupported has a value of one.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Add PIB parameter PHYPIB_DiversitySupported with value implementation dependent.


Comment:
Need to supply mapping for TX power as per the text written in clause 6.6.4 and indicated in table 44.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Copy objects from Table 44 and use implementation dependent as the values and use the mapping from the frame format.


Comment:
Need a note added to clause 11.7 to indicate that ranging is not supported by this PHY.

SuggestedRemedy:
11.7.x Ranging  The PHY description of clause 11 does not support the PHY PIB ranging group of clause 6.6.9.

Response:
PROPOSED ACCEPT IN PRINCIPLE. PHYPIB_Range in Table 93 is implementation dependent. Note that implementation is not specified for this PHY.


SuggestedRemedy:
The items of Table 50 are implmentation dependent.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Copy objects from table 50 to table 93 with values implementation dependent.


Comment:
I don't see any effort made to coexist with other 802 wireless standards or proposed standards in the 2.4 GHz band, other than selecting operation on 802.11b channels.  CCA done by ED alone requires a signal 20 dB above the minimum sensitivity defined in 11.6.2.  I do not believe this is sufficient for coexistence.  Coexistence should be a requirement, not a goal.

SuggestedRemedy:
Develop a method for coexistence with other 802 wireless standards in the 2.4 GHz band.


Comment:
In Table 91 the adjacent channel rejection is only 0 dB, when running at 55 Mb/s.  This means that if the interferer, in an adjacent channel, is closer to the receiver than the source, then the receiver will not work.  I think this level of adjacent channel rejection is insufficient. This makes operation of multiple TG2 WPANs in the same area impractical. As a reference point, the IEEE 802.11b adjacent channel rejection, operating at 11 Mb/s is 35 dB.

SuggestedRemedy:
Increase the adjacent channel rejection, for all data rates, by 20 dB.

Response:
PROPOSED REJECT. These performance requirements are roughly similar to 802.11a and are consistent with our low-cost target.


Comment:
Who makes the choice of which frequency plan to use?  The implementer or the user?

Response:
PROPOSED ACCEPT IN PRINCIPLE. Same resolution as in 1109.


Comment:
aRXTXTurnaroundTime is a range.  I am not sure how SIFS can be a range..

Response:
PROPOSED ACCEPT IN PRINCIPLE.

Change aRXTXTurnaroundTime in Table 76 to be aPHYSIFSTime (See resolution of 426). Delete reference to aRXTXTurnaroundTime in 11.6.2 and any other occurances in the draft.


Comment:
Details of the HCS should be provided to the level that they are in 7.2.8.

Response:
PROPOSED ACCEPT IN PRINCIPLE.   The IEEE would rather us use this by reference instead of duplicating the same information in multiple standards.
Include text and figure from 18.2.3.6 in 802.11b-1999.


Comment:
Sending the header twice raises some interesting questions:  What if the preamble is incorrect?  Does the PHY then always look at the payload to see if there is a 11 Mbps header?  If not, what is the purpose?

SuggestedRemedy:
Detail how the second header is processed.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Text needs to be added in clause 11 to clarify how dual headers are processed. If either correct, correct one passed up.


Comment:
What does the length field cover - the frame body, but not the second header?

SuggestedRemedy:
Clarify what the length field covers.  The additional header time must be accounted for by the MAC in calculating channel time.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Add a table as an illustrative example of the length to be expected for all PHY data rates in clause 11. James Gilb will provide.


Comment:
This is a general comment for the Annex. It is noted that this annex is too standalone and doesn't provide tie in to the rest of the draft.


Comment:
The term "PHY Sublayer", used in the Figure A.1 is spelled wrong.


Comment:
The Annex Title "Service Specific Convergence Sub layer" is spelled wrong.  Also, the annex subclause numbering should start at the introduction or line 8.

SuggestedRemedy:
Change to "Service Specific Convergence Sublayer" and insert the word "Introduction" and use the paragraph tag AH1,A.1; forcing the A.1 to start.


Comment:
The word "Classification" should not be capitalized.

SuggestedRemedy:
Change word to lower case or "classification".


Comment:
There are Editor notes here, subclause A.2.2., page 219, line 4, and line 53.


Comment:
Need to indicate that the intefaces described are only required if the interface is exposed.

SuggestedRemedy:
After the sentence ending "specified for 802.15.3" on line 18 add the following paragraph:   "If the SSCS-SAP interface is not exposed in an 802.15.3 device, then these interfaces do not have to be implemented as described here. If the interfaces are exposed, then they should support the primitives described in this clause."


SuggestedRemedy:
Delete the comment and apply the changes that are indicated (i.e. reformat the parameter definitions into a table).


Comment:
Editorial comment left in, but still valid.

SuggestedRemedy:
Since .request supports reorderable multicast, we would have to support it on the .indication side as well.  However, it appears that the standard does not support multicast at all and so this could be deleted as an allowed service class from the .request side to fix this.


Comment:
Editorial comment left in but still valid.

SuggestedRemedy:
Add a condition, "9 - Undeliverable (channel conditions are too severe).


Comment:
Only receives from peer (does not send to peer).  Who then can send?


Comment:
Need consistent name for the Convergence Sublayer

SuggestedRemedy:
Let's use "sublayer".  On page 215 we have sublayer, sub layer, sub-layer, etc.


Comment:
In line 3 we have "PDU" while in figure A.2 we show "SDU".  Is there an inconsistency here or is this OK.


Comment:
I'm confused about clause A.2 ... where are we at Figure A.1 ... are we at the SSCS SAP or at the MAC CPS SAP.  Please clarify.  Also, is there an inconsistency between clause A.2 and clause 6.8 on the names?


Comment:
Is the LLC sublayer one of the SSCS options?

SuggestedRemedy:
MAC subcommittee to clarify and to add text to remove the confusion.


Comment:
The sentence that starts half way across line 49 needs to be modified as shown below.

SuggestedRemedy:
This MAC only reports success since all failures of reception are discarded without generating a MA-UNITDAT.indication.


Comment:
We have an editorial note that needs to be resolved and removed.


Comment:
What is the relationship between the information and the assignment of GTS slots.  Why is Table A.1 relavent to the standard?


Comment:
Clause A.4 does not seem complete.  What is the point of having this clause in the standard.  If the clause is needed then it needs to be finished.  If it is not needed then it should be deleted.


Comment:
In the rest of the document I think we are calling the MAC CPS the MAC and the MAC CPS SAP the MAC SAP.  We need to be consistent

SuggestedRemedy:
Clarify what we are calling the MAC and be consistent with the rest of the document.


Comment:
The informative annex relating to Power management is not complete. There is a key informative piece prior to use of the EPS action command that either should be in the annex or be located in clause 6.

SuggestedRemedy:
Add the summary of what happens after authentication and association and until the DEVs are ready to do EPS operations.


Comment:
Resources in a piconet are allocated as channel time, not bandwidth.

SuggestedRemedy:
Change two occurrances of 'bandwidth' to 'channel time' in this sentence.


Comment:
A cipher suite needs to be chosen for the 15.3 standard. This would give a certain level of security for all devices which require security, and allow for interoperability for 15.3 devices. If higher levels of security, or differing cipher suites are needed for certain applications, then the application layer could implement its own security protocol by not using the 15.3 security, or by overlaying its protocol over the 15.3 security.


Comment:
Suggest a figure to clarify the master/slave relationship unique to EPS sets.


SuggestedRemedy:
Remove the word "be" as shown below ...  ... GTS time is then calculated using ...


SuggestedRemedy:
... indicating "anywhere in the CFP", 7.5.10.1.


Comment:
The text in B.3.1 implies there will be more than one cipher suite.  I will not be able to vote "yes" for a standard unless there is a default cipher suite.  Additonal cipher suits can be considered to be optional alternatives.  To do otherwise does the following:  1. without a default (mandatory) cipher suite then the only compatible security between all 802.15.3 devices is no security at all  2. When implementing hardware, I don't want to be burdened with having to put multiple cipher suites into the implementation.  That will be inefficient and expensive.

SuggestedRemedy:
The security subcommittee must select one cipher method as being the default, mandatory cipher method.  Additonal ciphers can be added as options.  I believe this is consistent with the motion made and passed in Austin.


Comment:
Mention is made of a trusted relationship.

SuggestedRemedy:
The standard must explain how that trusted relationship is established.


SuggestedRemedy:
add an s to key as shown below ...  ... needs to distribute keys to the DEVs ....


Comment:
In discussing authentication, mention is made of "using a processes defined by the cipher suite".

SuggestedRemedy:
The process used by the cipher suite has to take into consideration the WPAN environment.  That is, the cipher suite needs to accommodate WPAN and not the other way around.  I can not vote "yes" to a WPAN standard that does not have an authentication process that is suitable for WPAN deployments.


Comment:
EPSPhase does not occur in the rest of the document.

SuggestedRemedy:
Delete reference to EPSPhase.  If this is the wrong workd, replace it.


Comment:
In Austin we voted to have a mandatory cipher suite.  We need to include the mandatory cipher suite in the standard.

SuggestedRemedy:
Choose and document a mandatory cipher suite.


Comment:
Requirements and descriptions of the cipher suites should be part of section 10 in the main part of the document and should be normative in some capacity.  The standard needs to require that a cipher suite behave in a certain manner, otherwise there can be no guarantee that the selected cipher suite has the properties that are needed to satisfy the security requirements.

SuggestedRemedy:
Move cipher suite text to section 10 and clarify cipher suite requirements.  Comment via Ari Singer.


Comment:
The standard does not say what can't be in the MAC, so a more proper structure of the first sentence should be "The cipher suites are conceptually implemented outside of the MAC (although they may physically be implemented there), so . . ."


Comment:
The challenge response protocol as described in the standard is underspecified.  In some discussions, the idea was to use the challenge response protocol to allow for peer-to-peer authentication.  Below are some comments on this protocol:  1) There is no defined method for a DEV to send its public key to another DEV, so the protocol cannot be implemented as currently specified.   2) The challenge-response is an authentication protocol and, as such, it may require more passes than 2 (depending on the algorithms available in the cipher suite) and probably will require more if mutual authentication is desirable instead of single-party authentication.  Changing the number of passes will require a change to the MLME messages. 3) The purpose of this protocol is unclear.  Why does a device need to authenticate other devices in the piconet?  Is this because it will only trust the piconet if the security manager (PNC) and itself both authenticate all the other devices?  This policy would require a lot of overhead.  The use of this protocol should be clarified. 4) If devices wanted to authenticate each other individually, it stands to reason that they might want to exchange keys and communicate securely just between the two of them.  If this protocol is kept, it should be extended to include a method for exchanging keys.  Even better, the "authenticate" protocol, if it allows both parties to be authenticated, might be allowed between peer DEVs in the piconet.


Comment:
SDL not included. SDL should be informative instead of normative.

SuggestedRemedy:
Add high level SDL for all mandatory portions for the specification.

Response:
The committee does not want to add normative content that may conflict with the other clauses. Informative content will not be available until at least 3 months after the final draft has been approved. 
SDL clause will be removed from the draft and left for a follow on project.


Comment:
This annex is marked as NORMATIVE, yet nothing is present.  Any change to this section will be a significant technical change and require a new letter ballot not a recirculation.  If there are large holes like this in a draft, then it should not be even motioned to working group letter ballot. I have provided three suggested remedies.

SuggestedRemedy:
1) Remove the annex, but since the annex is normative. Note: this is a significant change removing somthing that is normative.  2) Changing the annex, from normative to informative.  Note: this does not solve the problem as it is still empty.  Even if SDLs are proposed as part of someone else's comments, I will consider these significant enough to warrant a new ballot. 3) Add the missing SDLs.  Note: this is a substantial technical change and will require a new ballot.

Response:
PROPOSED ACCEPT IN PRINCIPLE.   The committee does not want to add normative content that may conflict with the other clauses. Informative content will not be available until at least 3 months after the final draft has been approved. 
SDL clause will be removed from the draft and left for a follow on project.


Comment:
SDL is not defined and is not normative.

SuggestedRemedy:
Change normative to informative and get some SDL to put in here.  Or just delete the entire clause.

Response:
PROPOSED ACCEPT. The committee does not want to add normative content that may conflict with the other clauses. Informative content will not be available until at least 3 months after the final draft has been approved. 
SDL clause will be removed from the draft and left for a follow on project.


Comment:
Without SDL there is an higehr risk of non-interoperable implementations

SuggestedRemedy:
Provide formal description of the MAC and PHY. SDL can be one option.

Response:
PROPOSED REJECT. The committee does not want to add normative content that may conflict with the other clauses. Informative content will not be available until at least 3 months after the final draft has been approved. 
SDL clause will be removed from the draft and left for a follow on project.


Comment:
There are no SDL's.  This is not a valid letter ballot with normative sections missing from the draft.

SuggestedRemedy:
The SDLs should not be considered normative and should be completely removed from the document.


Response:
PROPOSED ACCEPT IN PRINCIPLE.  The committee does not want to add normative content that may conflict with the other clauses. Informative content will not be available until at least 3 months after the final draft has been approved. 
SDL clause will be removed from the draft and left for a follow on project.


Comment:
PICS not defined. PICS section should be informative since it repeats items defined in earlier clauses and only servers to determine what portions of the specification to which paticular implementation conforms.

SuggestedRemedy:
Add PICS based on final content of the specification.

Response:
PROPOSED ACCEPT. PICS content will be added as an informative clause as derived from the normative portion of the draft.


Comment:
This annex is marked as NORMATIVE, yet nothing is present.  Any change to this section will be a significant technical change and require a new letter ballot not a recirculation.  If there are large holes like this in a draft, then it should not be even motioned to working group letter ballot. I have provided two suggested remedies. A PICS is not to contain any requirements that cannot be found in the descriptive text.  It has been my experience that this is not the case.  TG1's draft 802.15.1 is the best example of where a PICS makes requirements that are not part of the descriptive text.  The PICS in this case has become a product implementation time line, which marks items as optional, if the feature is not to be supported as a first released product.  A standard is never to be written as phases of a product roll out.  Requirements must be set and options well marked.  This is what a PICS contains.  If this is true that a PICS contains only what is fully stated in the text, then why could the PICS not have been part of the balloted text at this time?  Could it be that the requirements and options are not yet finalize in the text?  If this is the case then why was this draft motioned to working group letter ballot?

SuggestedRemedy:
1) Remove the annex, but since the annex is normative. Note: this is a significant change removing somthing that is normative.  2) Add the missing PICS.  Note: this is a substantial technical change and will require a new ballot.

Response:
PROPOSED ACCEPT IN PRINCIPLE.  PICS content will be added as an informative clause as derived from the normative portion of the draft.


Comment:
The PICS are derived from the text and so are informative rather than normative.

SuggestedRemedy:
Change the annex designation from normative to informative and add the PICS tables.


Comment:
Without PICS there is an higehr risk of non-interoperable implementations

SuggestedRemedy:
Provide PICS for implementation description of the MAC and PHY.


Comment:
There are no PICs.  This is not a valid letter ballot with normative sections missing from the draft.


Comment:
"Papoulis" should be "Athanasios Papoulis"


Comment:
"Stallings" should be "William Stallings"


SuggestedRemedy:
fill in proper number for "ZZZ" in lines 5 and 6


SuggestedRemedy:
fill in proper number for "#HMAC" in lines 9 and 10


Comment:
There are no coexistence study so far regarding the coexistence property of a device implementing this specification. It is well known problem that 2.4GHz ISM band is already crowded with WLAN and BT devices. It is important to show that devices implementing this draft can coexist with the incumbent.

SuggestedRemedy:
1. Get TG2 involved in evaluating the coexistence property of the draft. 2. Add sections in the draft to explain what are the tools that can be used to have better coexistence properties. For instance, channel assessment and selection, power control, etc.

Response:
PROPOSED ACCEPT IN PRINCIPLE.  The proposed informative Annex (00000r0P802-15-3-Annex_Coexistence.pdf) has a description of the coexistence methods that are available in the draft. Also see 02/041r2 for a presentation and additional text on this issue. For 802.15.4 compatibility see subclause 6.9 in 00000D13P802-15-4__Draft_Standard.pdf. TG2 has been consulted and they will help with analysis.


Comment:
Despite the fact that 802.15.3 is described as a WPAN under the umbrella of the WPAN working group (802.15), there is no mention of interference, interoperability, or coexistence with the only other WPAN standard to go through letter ballot, 802.15.1.  This specification has no mention of how it will maintain QoS in the presence of significant other interference in the same band: Bluetooth, microwave ovens, etc.  Even in the "802.11b coexistence" mode, there is no method described that says how the 802.15.3 system will be placed in this channel plan. While older specifications such as 802.11b could have been developed without recognition of other users of the band, IEEE would do the industry a disservice by publishing specifications whose ability to coexist with other IEEE wireless standards was unknown (at best) or poor (at worst).

SuggestedRemedy:
The specification needs a coexistence section that describes: a) mechanisms for QoS maintenance in the presence of interference (with informative sections that quantify the problem), b) coexistence mechanisms for 802.15.1/Bluetooth, and c) channel selection algorithms that not only address 802.11b coexistence in an automatic way, but also describe avoidance mechanisms for microwave ovens and other types of interference (both periodic and non-periodic).

Response:
PROPOSED ACCEPT IN PRINCIPLE. The proposed informative Annex (00000r0P802-15-3-Annex_Coexistence.pdf) has a description of the coexistence methods that are available in the draft. Also see 02/041r2 for a presentation and additional text on this issue. For 802.15.4 compatibility see subclause 6.9 in 00000D13P802-15-4__Draft_Standard.pdf. Accept informative text provided by the commenter on QoS issue.


