IEEE P802.15 Wireless Personal Area Networks Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Title: 02064r0P802-15_WG-LB12-Comments.txt Date Submitted: 22 January, 2002 Source: Richard L. Alfvin Appairent Technologies, Inc 150 Lucius Gordon Drive West Henrietta, NY 14586 Voice: (585) 214-2464 Fax: (585) 214-2464 E-mail: alfvin@appairent.com Re: Abstract This text file contains the collection of Technical (T) and Technical Required (TR) comments submitted during IEEE 802.15 Letter Ballot 12. Purpose This document is submitted to aid voters in managing the comment resolution process. Notice This document has been prepared to assist the IEEE P802.15. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release The contributor acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P802.15. _______________________________________________________________________________________________ ----------- CommentID: 1482 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 00 Subclause: Page: Line: CommentType: TR Comment: We agreed to change Kus to ms throughout the document. Looks like only half of the instances got update. Half still have Kus. CommentEnd: SuggestedRemedy: Change all values of Kus to ms. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1755 CommenterName: Chen, Hung-Kun CommenterEmail: hkchen@inprocomm.com CommenterPhone: +886-3-516-5106 ext 661 CommenterFax: CommenterCo: InProComm, Inc. Clause: 00 Subclause: Page: Line: CommentType: TR Comment: The backward compatibilty or relationship with 802.15.1 devices is not addressed CommentEnd: SuggestedRemedy: Please address the compatibility/relationship issue clearly. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1720 CommenterName: Young, Song-Lin CommenterEmail: syoung@sharplabs.com CommenterPhone: 360-817-7509 CommenterFax: CommenterCo: Sharp Labs. of America Clause: 00 Subclause: Page: Line: CommentType: TR 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 CommentEnd: SuggestedRemedy: MAC clauses add functions for piconets becoming overlap, considering piconets will be moving RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1772 CommenterName: Maa, Yeong-Chang CommenterEmail: ycmaa@inprocomm.com CommenterPhone: +886-3-5165106 ext 201 CommenterFax: CommenterCo: InProComm, Inc. Clause: 00 Subclause: Page: Line: CommentType: TR Comment: The backward compatibilty or relationship with 802.15.1 devices is not addressed CommentEnd: SuggestedRemedy: Please address the compatibility/relationship issue clearly. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 768 CommenterName: Huckabee, Laura CommenterEmail: laura.huckabee@timedomain.com CommenterPhone: 256.428.6422 CommenterFax: 256.759.0678 CommenterCo: Time Domain Corporation Clause: 00 Subclause: Page: Line: CommentType: T Comment: It is not clear that <= 1 second connect time is achievable (especially with existing security clauses). CommentEnd: SuggestedRemedy: Clarify in Clause 5 all connection time issues. Review impact of security to see if connect time is attainable. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1746 CommenterName: Chen, Kwang-Cheng CommenterEmail: kc@inprocomm.com CommenterPhone: +886-3-5165106 ext {201, 865, 668, 661} CommenterFax: CommenterCo: InProComm, Inc. Clause: 00 Subclause: Page: Line: CommentType: TR Comment: The backward compatibilty or relationship with 802.15.1 devices is not addressed CommentEnd: SuggestedRemedy: Please address the compatibility/relationship issue clearly. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 97 CommenterName: DuVal, Mary CommenterEmail: m-duval@ti.com CommenterPhone: 972-575-2330 CommenterFax: CommenterCo: Texas Instruments Clause: 00 Subclause: Page: Line: CommentType: TR 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 CommentEnd: SuggestedRemedy: Requirements needed to meet the intent of the PAR. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1358 CommenterName: Shellhammer, Steve CommenterEmail: shell@symbol.com CommenterPhone: (631) 738-4302 CommenterFax: CommenterCo: Symbol Technologies Clause: 00 Subclause: Page: Line: CommentType: TR 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. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1739 CommenterName: Golmie, Nada CommenterEmail: nada@nist.gov CommenterPhone: (301) 975-4190 CommenterFax: CommenterCo: NIST Clause: 00 Subclause: Page: Line: CommentType: T Comment: The current TG3 draft does not address the issue of coexistence between 802.15.3 devices and other devices in the band such as 802.11b and Bluetooth. CommentEnd: SuggestedRemedy: 1) Add a clause or subclause that describes the interference problem resulting from having 802.15.3 devices co-located with 802.11b, Bluetooth devices. Performance results quantifying the impact of interference can be added as well. 2) Include solutions to remedy the problem. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1730 CommenterName: Lansford, Jim CommenterEmail: jimlansford@mobilian.com CommenterPhone: +1 405 377 6170 CommenterFax: +1 405 747 5229 CommenterCo: Mobilian Clause: 00 Subclause: Page: Line: CommentType: T 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). CommentEnd: 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). RemedyEnd: Response: \ ResponseEnd: ----------- CommentID: 1728 CommenterName: Liang, Jie CommenterEmail: jliang@ieee.org CommenterPhone: 214 480 4105 CommenterFax: CommenterCo: Texas Instruments Clause: 00 Subclause: Page: Line: CommentType: T 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. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1356 CommenterName: Shellhammer, Steve CommenterEmail: shell@symbol.com CommenterPhone: (631) 738-4302 CommenterFax: CommenterCo: Symbol Technologies Clause: 00 Subclause: Page: Line: CommentType: TR Comment: The standard does not address the issue of wireless coexistence sufficiently. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1790 CommenterName: Liu, Shawn CommenterEmail: shawnliu@inprocomm.com CommenterPhone: +886-3-5165106 ext 865 CommenterFax: CommenterCo: InProComm, Inc. Clause: 00 Subclause: Page: Line: CommentType: TR Comment: The backward compatibilty or relationship with 802.15.1 devices is not addressed CommentEnd: SuggestedRemedy: Please address the compatibility/relationship issue clearly. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1844 CommenterName: Rasor, Gregg CommenterEmail: Gregg.Rasor@motorola.com CommenterPhone: (561) 739-2952 CommenterFax: CommenterCo: Motorola Clause: 00 Subclause: Page: Line: CommentType: TR Comment: 7. (TR) Page 185, line 6: in front of the sentence 'To facilitate…' insert the following sentence: 'It will accept any commands from an authenticated device.' Comment: the current text does not cover the consequences of a successful authentication. CommentEnd: SuggestedRemedy: RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1836 CommenterName: Rasor, Gregg CommenterEmail: Gregg.Rasor@motorola.com CommenterPhone: (561) 739-2952 CommenterFax: CommenterCo: Motorola Clause: 00 Subclause: Page: Line: CommentType: TR Comment: Statically identifying the device Id with the IEEE MAC address gives rise to anonymity concerns, since then the device Id identifies the device in a static and traceable way. One distinguishes a number of issues, including (1) Tracking of devices and thereby their users; (2) trace-ability of the manufacturer of the WPAN-chip, which might lead to passively monitoring which devices are owned by whom (e.g., for device theft). (Note: lack of anonymity was a major criticism of the original Bluetooth specification. It led to a change requirement by Ericcson, after this privacy issue had been advertised on the front cover of the NY Times). CommentEnd: SuggestedRemedy: Do not statically identify the device Id with the IEEE MAC address. Instead, add a separate section on how the device Id should be interpreted. Add a separate section on how the device Id should be interpreted, thus leaving room for dynamic linkage of the device Id to a (pseudonym) of the IEEE MAC address of the device. As for now, this section would just describe that the device Id equals the IEEE MAC address (so, we have compliance with the current draft and formats). If anonymity concerns give rise to a change requirement, one only needs to change this added section to cater for the anonymity requirement, not all occurrences of the device Id throughout the whole standard (i.e., it is acts as an abstract module). Of course, we should give the proper format and, in particular, the required length of the device Id proper consideration. The current 48-bit device Id might not be enough to provide anonymity guarantees (if these are required). RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1751 CommenterName: Chen, Hung-Kun CommenterEmail: hkchen@inprocomm.com CommenterPhone: +886-3-516-5106 ext 661 CommenterFax: CommenterCo: InProComm, Inc. Clause: 00 Subclause: Page: 107 Line: 36 CommentType: TR Comment: There are TBDs. CommentEnd: SuggestedRemedy: Please fill in the appropriate values. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1786 CommenterName: Liu, Shawn CommenterEmail: shawnliu@inprocomm.com CommenterPhone: +886-3-5165106 ext 865 CommenterFax: CommenterCo: InProComm, Inc. Clause: 00 Subclause: Page: 107 Line: 36 CommentType: TR Comment: There are TBDs. CommentEnd: SuggestedRemedy: Please fill in the appropriate values. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1768 CommenterName: Maa, Yeong-Chang CommenterEmail: ycmaa@inprocomm.com CommenterPhone: +886-3-5165106 ext 201 CommenterFax: CommenterCo: InProComm, Inc. Clause: 00 Subclause: Page: 107 Line: 36 CommentType: TR Comment: There are TBDs. CommentEnd: SuggestedRemedy: Please fill in the appropriate values. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1742 CommenterName: Chen, Kwang-Cheng CommenterEmail: kc@inprocomm.com CommenterPhone: +886-3-5165106 ext 668 CommenterFax: CommenterCo: InProComm, Inc. Clause: 00 Subclause: Page: 107 Line: 36 CommentType: TR Comment: There are TBDs. CommentEnd: SuggestedRemedy: Please fill in the appropriate values. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1769 CommenterName: Maa, Yeong-Chang CommenterEmail: ycmaa@inprocomm.com CommenterPhone: +886-3-5165106 ext 201 CommenterFax: CommenterCo: InProComm, Inc. Clause: 00 Subclause: Page: 133 Line: 39 CommentType: TR Comment: There are TBDs. CommentEnd: SuggestedRemedy: Please fill in the appropriate values. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1752 CommenterName: Chen, Hung-Kun CommenterEmail: hkchen@inprocomm.com CommenterPhone: +886-3-516-5106 ext 661 CommenterFax: CommenterCo: InProComm, Inc. Clause: 00 Subclause: Page: 133 Line: 39 CommentType: TR Comment: There are TBDs. CommentEnd: SuggestedRemedy: Please fill in the appropriate values. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1743 CommenterName: Chen, Kwang-Cheng CommenterEmail: kc@inprocomm.com CommenterPhone: +886-3-5165106 ext 668 CommenterFax: CommenterCo: InProComm, Inc. Clause: 00 Subclause: Page: 133 Line: 39 CommentType: TR Comment: There are TBDs. CommentEnd: SuggestedRemedy: Please fill in the appropriate values. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1787 CommenterName: Liu, Shawn CommenterEmail: shawnliu@inprocomm.com CommenterPhone: +886-3-5165106 ext 865 CommenterFax: CommenterCo: InProComm, Inc. Clause: 00 Subclause: Page: 133 Line: 39 CommentType: TR Comment: There are TBDs. CommentEnd: SuggestedRemedy: Please fill in the appropriate values. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1770 CommenterName: Maa, Yeong-Chang CommenterEmail: ycmaa@inprocomm.com CommenterPhone: +886-3-5165106 ext 201 CommenterFax: CommenterCo: InProComm, Inc. Clause: 00 Subclause: Page: 175 Line: 31 CommentType: TR Comment: There are TBDs. CommentEnd: SuggestedRemedy: Please fill in the appropriate values. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1744 CommenterName: Chen, Kwang-Cheng CommenterEmail: kc@inprocomm.com CommenterPhone: +886-3-5165106 ext 668 CommenterFax: CommenterCo: InProComm, Inc. Clause: 00 Subclause: Page: 175 Line: 31 CommentType: TR Comment: There are TBDs. CommentEnd: SuggestedRemedy: Please fill in the appropriate values. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1788 CommenterName: Liu, Shawn CommenterEmail: shawnliu@inprocomm.com CommenterPhone: +886-3-5165106 ext 865 CommenterFax: CommenterCo: InProComm, Inc. Clause: 00 Subclause: Page: 175 Line: 31 CommentType: TR Comment: There are TBDs. CommentEnd: SuggestedRemedy: Please fill in the appropriate values. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1753 CommenterName: Chen, Hung-Kun CommenterEmail: hkchen@inprocomm.com CommenterPhone: +886-3-516-5106 ext 661 CommenterFax: CommenterCo: InProComm, Inc. Clause: 00 Subclause: Page: 175 Line: 31 CommentType: TR Comment: There are TBDs. CommentEnd: SuggestedRemedy: Please fill in the appropriate values. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 291 CommenterName: Gifford, Ian CommenterEmail: giffordi@ieee.org CommenterPhone: +1 978 251 3451 CommenterFax: +1 978 815 8182 CommenterCo: Self Clause: 00 Subclause: 00 Page: 0 Line: 0 CommentType: T Comment: Are the use of shall/should/may/can/will/must throughout the document in accordance with IEEE's style? CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1828 CommenterName: Rasor, Gregg CommenterEmail: Gregg.Rasor@motorola.com CommenterPhone: (561) 739-2952 CommenterFax: CommenterCo: Motorola Clause: 00 Subclause: 3.4.2.2 Page: 186 Line: CommentType: TR Comment: If disassociation request by a particular device would be automatically honored without evidence regarding the authenticity of this request, one can launch a simple denial of service attack on each device in the piconet. CommentEnd: SuggestedRemedy: The details of the disassociation request initiated by the device itself should be specified. Specify the disassociation request protocol in such a way that honoring this request is subject to positive evidence as to the identity of the originator of that request (data origin authentication). RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1318 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 00 Subclause: 7.5.7.1 Page: 124 Line: 31 CommentType: TR 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." CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 721 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 00 Subclause: 8.2.7 Page: 143 Line: 36 CommentType: TR Comment: The text between lines 36 and 41 is an incorrect description of the PNC information broadcasting function. CommentEnd: SuggestedRemedy: See detailed resolution in doc 02/037r0 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1548 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 00 Subclause: 8.4.2.1 Page: 147 Line: 16 CommentType: TR 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. CommentEnd: SuggestedRemedy: Specify that a uniqueue seed is required, not a unique random number algorithm. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 78 CommenterName: Barr, John CommenterEmail: John.Barr@Motorola.com CommenterPhone: 847-576-8706 CommenterFax: 847-651-6822 CommenterCo: Motorola Clause: 00 Subclause: multiple Page: Line: CommentType: TR 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. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1 CommenterName: Alfvin, Rick CommenterEmail: alfvin@appairent.com CommenterPhone: 585-214-2464 CommenterFax: 585-781-0952 CommenterCo: Appairent Technologies, Inc. Clause: 01 Subclause: 1 Page: 1 Line: 35 CommentType: T Comment: The Scope section of the Draft should reflect essentially the same wording as the Scope section of the PAR. CommentEnd: SuggestedRemedy: Change the Scope section of the Draft to reflect the wording of the Scope section of the PAR. RemedyEnd: Response: PROPOSED ACCEPT. ResponseEnd: ----------- CommentID: 92 CommenterName: CYPHER, DAVID CommenterEmail: david.cypher@nist.gov CommenterPhone: 1 301 975 4855 CommenterFax: CommenterCo: NIST Clause: 01 Subclause: 1.1 Page: 1 Line: 37 CommentType: TR Comment: The scope does not match the one listed in the PAR CommentEnd: SuggestedRemedy: Match the scope text with the text of the original PAR RemedyEnd: Response: PROPOSED ACCEPT. ResponseEnd: ----------- CommentID: 484 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 01 Subclause: 1.1 Page: 1 Line: 38 CommentType: T 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. CommentEnd: SuggestedRemedy: Change the wording to be essentially the same as what is found in the PAR. RemedyEnd: Response: PROPOSED ACCEPT. ResponseEnd: ----------- CommentID: 90 CommenterName: CYPHER, DAVID CommenterEmail: david.cypher@nist.gov CommenterPhone: 1 301 975 4855 CommenterFax: CommenterCo: NIST Clause: 01 Subclause: 1.1 Page: 1 Line: 44 CommentType: TR 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. CommentEnd: SuggestedRemedy: Remove this statement from the document. RemedyEnd: Response: PROPOSED ACCEPT. ResponseEnd: ----------- CommentID: 765 CommenterName: Huang, Bob CommenterEmail: robert.huang@am.sony.com CommenterPhone: 201-358-4409 CommenterFax: CommenterCo: Sony Electronics Clause: 01 Subclause: 1.1 Page: 1 Line: 4648 CommentType: TR 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. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 91 CommenterName: CYPHER, DAVID CommenterEmail: david.cypher@nist.gov CommenterPhone: 1 301 975 4855 CommenterFax: CommenterCo: NIST Clause: 01 Subclause: 1.1 Page: 1 Line: 47 CommentType: TR 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. CommentEnd: SuggestedRemedy: Remove this statement from the document. RemedyEnd: Response: PROPOSED ACCEPT. ResponseEnd: ----------- CommentID: 93 CommenterName: CYPHER, DAVID CommenterEmail: david.cypher@nist.gov CommenterPhone: 1 301 975 4855 CommenterFax: CommenterCo: NIST Clause: 01 Subclause: 1.2 Page: 2 Line: 3 CommentType: TR Comment: The Purpose does not match the purpose in the PAR CommentEnd: SuggestedRemedy: Replace the current purpose with the text from the original PAR RemedyEnd: Response: PROPOSED ACCEPT. ResponseEnd: ----------- CommentID: 96 CommenterName: DuVal, Mary CommenterEmail: m-duval@ti.com CommenterPhone: 972-575-2330 CommenterFax: CommenterCo: Texas Instruments Clause: 01 Subclause: 2 Page: 2 Line: 9 CommentType: T 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. CommentEnd: 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. RemedyEnd: Response: PROPOSED ACCEPT IN PRINCIPLE. Replace text with the wording from the definition 3.39. ResponseEnd: ----------- CommentID: 854 CommenterName: Kleindl, Guenter CommenterEmail: guenter.kleindl@siemens.at CommenterPhone: 43 51707 35738 CommenterFax: CommenterCo: Siemens Clause: 02 Subclause: Page: 34 Line: CommentType: T Comment: Subclause 7.4.7 refers to IEEE P1363 CommentEnd: SuggestedRemedy: Include reference to IEEE P1363 RemedyEnd: Response: PROPOSED ACCEPT. ResponseEnd: ----------- CommentID: 483 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 02 Subclause: 2 Page: 3 Line: 16 CommentType: T Comment: The ASN.1 references are not relevant to this standard. CommentEnd: 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. RemedyEnd: Response: PROPOSED ACCEPT. ResponseEnd: ----------- CommentID: 858 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 03 Subclause: Page: 5 Line: 50 CommentType: T Comment: missing a definition CommentEnd: SuggestedRemedy: add definition for device-ID: Specifies the MAC address of the DEV under consideration. RemedyEnd: Response: PROPOSED ACCEPT. Device ID: The MAC address of a device in an 802.15.3 piconet. ResponseEnd: ----------- CommentID: 859 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 03 Subclause: 3.19 Page: 6 Line: 1 CommentType: T Comment: definition for enhanced power save seems incomplete. Does differentiate EPS from RPS. CommentEnd: SuggestedRemedy: have power management sub-group clarify the definition. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 860 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 03 Subclause: 3.20 Page: 6 Line: 4 CommentType: T Comment: Too wordy ... CommentEnd: SuggestedRemedy: remove all text in the definition except the following: the nominal time value for the inter-wake periods for enhanced power save devices. RemedyEnd: Response: PROPOSED ACCEPT. ResponseEnd: ----------- CommentID: 862 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 03 Subclause: 3.22 Page: 6 Line: 12 CommentType: T Comment: Remove second sentence CommentEnd: SuggestedRemedy: Remove sentence that starts with "A single enhanced ..." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 11 CommenterName: Bain, Jay CommenterEmail: jay.bain@timedomain.com CommenterPhone: 256 428 6415 CommenterFax: 256 527 4778 CommenterCo: Time Domain Clause: 03 Subclause: 3.50 Page: 7 Line: 39 CommentType: T 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. CommentEnd: SuggestedRemedy: change "excluding the beacon" to "when contention free period slots are not allocated to the device" RemedyEnd: Response: PROPOSED ACCEPT. ResponseEnd: ----------- CommentID: 12 CommenterName: Bain, Jay CommenterEmail: jay.bain@timedomain.com CommenterPhone: 256 428 6415 CommenterFax: 256 527 4778 CommenterCo: Time Domain Clause: 03 Subclause: 3.61 Page: 8 Line: 18 CommentType: T 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. CommentEnd: SuggestedRemedy: also be available for sending or receiving operations "based on beacon information." RemedyEnd: Response: PROPOSED ACCEPT IN PRINCIPLE. Change "and also" to be "and based on beacon information also" ResponseEnd: ----------- CommentID: 857 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 03 Subclause: 3.8 Page: 5 Line: 24 CommentType: T Comment: unclear sentence structure ... not sure what is the correct definition CommentEnd: SuggestedRemedy: have power management sub-group rewrite this sentence RemedyEnd: Response: ResponseEnd: ----------- CommentID: 98 CommenterName: DuVal, Mary CommenterEmail: m-duval@ti.com CommenterPhone: 972-575-2330 CommenterFax: CommenterCo: Texas Instruments Clause: 03 Subclause: 40 Page: 7 Line: 7 CommentType: T Comment: "other services" - this description does not provide any information about how the piconet coordinator is different from other devices in the piconet. CommentEnd: SuggestedRemedy: Need to provide categories of services that are provided by the coordinator. RemedyEnd: Response: PROPOSED ACCEPT IN PRINCIPLE. Change the word services to "services, e.g. quality of service, synchronization, association, " ResponseEnd: ----------- CommentID: 1357 CommenterName: Shellhammer, Steve CommenterEmail: shell@symbol.com CommenterPhone: (631) 738-4302 CommenterFax: CommenterCo: Symbol Technologies Clause: 04 Subclause: Page: 910 Line: CommentType: TR 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. CommentEnd: 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. RemedyEnd: 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. ResponseEnd: ----------- CommentID: 871 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 05 Subclause: Page: 17 Line: 54 CommentType: TR Comment: Need to add a clause 5.6 CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1719 CommenterName: Young, Song-Lin CommenterEmail: syoung@sharplabs.com CommenterPhone: 360-817-7509 CommenterFax: CommenterCo: Sharp Labs. of America Clause: 05 Subclause: 2 Page: 14 Line: 1 CommentType: TR 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. CommentEnd: SuggestedRemedy: Make basic PNC function (beacon) mandatory so two devices can at least discover each other and exchange capability. RemedyEnd: Response: PROPOSED REJECT. The group feels that certains devices for cost consideration will always required a separate PNC for operation. E.g., remote speaker. ResponseEnd: ----------- CommentID: 112 CommenterName: DuVal, Mary CommenterEmail: m-duval@ti.com CommenterPhone: 972-575-2330 CommenterFax: CommenterCo: Texas Instruments Clause: 05 Subclause: 3.1 Page: 14 Line: 27 CommentType: TR 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? CommentEnd: SuggestedRemedy: Clarify RemedyEnd: 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." ResponseEnd: ----------- CommentID: 115 CommenterName: DuVal, Mary CommenterEmail: m-duval@ti.com CommenterPhone: 972-575-2330 CommenterFax: CommenterCo: Texas Instruments Clause: 05 Subclause: 3.2 Page: 15 Line: 7 CommentType: TR Comment: Does this paragraph indicate that the defined method could be over written by a higher level protocol? CommentEnd: SuggestedRemedy: Need clarification. RemedyEnd: Response: PROPOSED ACCEPT IN PRINCIPLE. Delete that sentence. "Higher level . . . this standard." ResponseEnd: ----------- CommentID: 120 CommenterName: DuVal, Mary CommenterEmail: m-duval@ti.com CommenterPhone: 972-575-2330 CommenterFax: CommenterCo: Texas Instruments Clause: 05 Subclause: 3.6 Page: 15 Line: 32 CommentType: T Comment: What if none of the remaining devices have the capability to be a PNC? Does the piconet disappear? CommentEnd: SuggestedRemedy: Finish explaining all cases. RemedyEnd: 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." ResponseEnd: ----------- CommentID: 123 CommenterName: DuVal, Mary CommenterEmail: m-duval@ti.com CommenterPhone: 972-575-2330 CommenterFax: CommenterCo: Texas Instruments Clause: 05 Subclause: 3.8 Page: 15 Line: 49 CommentType: T 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. CommentEnd: SuggestedRemedy: More explanation needed here to determine benefit of this functionality. RemedyEnd: Response: PROPOSED ACCEPT. ResponseEnd: ----------- CommentID: 130 CommenterName: DuVal, Mary CommenterEmail: m-duval@ti.com CommenterPhone: 972-575-2330 CommenterFax: CommenterCo: Texas Instruments Clause: 05 Subclause: 5 Page: 16 Line: 27 CommentType: TR Comment: How do the states relate? Is there a state flow diagram? CommentEnd: SuggestedRemedy: Provide state flow diagram. RemedyEnd: Response: PROPOSED ACCEPT IN PRINCIPLE. State diagrams will be added to the appropriate clauses with a cross reference in clause 5. ResponseEnd: ----------- CommentID: 864 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 05 Subclause: 5.1.1 Page: 13 Line: 25 CommentType: T Comment: Don't understand what the text is trying to say "The PHY is unprotected from outside signals." CommentEnd: SuggestedRemedy: add additional text to clarify meaning RemedyEnd: Response: PROPOSED ACCEPT IN PRINCIPLE. Delete the itemization point. "the PHY . . . signals." ResponseEnd: ----------- CommentID: 289 CommenterName: Gifford, Ian CommenterEmail: giffordi@ieee.org CommenterPhone: +1 978 251 3451 CommenterFax: +1 978 815 8182 CommenterCo: Self Clause: 05 Subclause: 5.2 Page: 13 Line: 5054 CommentType: T 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. CommentEnd: SuggestedRemedy: I suggest a figure be created and added that depicts the components of the IEEE 802.15.3 WPAN. RemedyEnd: Response: PROPOSED ACCEPT. ResponseEnd: ----------- CommentID: 799 CommenterName: Kinney, Patrick CommenterEmail: pat.kinney@ieee.org CommenterPhone: 724-425-7952 CommenterFax: CommenterCo: Invensys Clause: 05 Subclause: 5.2 Page: 16 Line: CommentType: T 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. CommentEnd: SuggestedRemedy: add verbage or mechanism to include authorization from a higher layer? RemedyEnd: 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. ResponseEnd: ----------- CommentID: 1359 CommenterName: Shellhammer, Steve CommenterEmail: shell@symbol.com CommenterPhone: (631) 738-4302 CommenterFax: CommenterCo: Symbol Technologies Clause: 05 Subclause: 5.3 Page: 15 Line: CommentType: T 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. CommentEnd: SuggestedRemedy: Eliminate the child and neighboring piconet concept or alternativly include a short statement of the utility of these capabilities. RemedyEnd: Response: PROPOSED ACCEPT IN PRINCIPLE. Add text that identifies possible uses of child and neighbor piconets. Bob Huang to provide by Monday evening. ResponseEnd: ----------- CommentID: 1660 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 05 Subclause: 5.3.2 Page: 15 Line: 2 CommentType: T 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. CommentEnd: 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. RemedyEnd: Response: PROPOSED ACCEPT. ResponseEnd: ----------- CommentID: 866 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 05 Subclause: 5.3.2 Page: 15 Line: 7 CommentType: T Comment: add to clause 4 CommentEnd: SuggestedRemedy: add "ssh" to clause 4 ... off-hand I do not know what ssh means. RemedyEnd: Response: PROPOSED ACCEPT IN PRINCIPLE. Sentence was deleted. ResponseEnd: ----------- CommentID: 16 CommenterName: Bain, Jay CommenterEmail: jay.bain@timedomain.com CommenterPhone: 256 428 6415 CommenterFax: 256 527 4778 CommenterCo: Time Domain Clause: 05 Subclause: 5.3.8 Page: 15 Line: 54 CommentType: T Comment: 1. use reserved or another term rather than private 2. add clarification as to what assoc, auth, sec and acks are related to CommentEnd: SuggestedRemedy: 1. change "private" to "reserved" 2. after acknowledgments, insert "for the neighbor" RemedyEnd: Response: PROPOSED ACCEPT IN PRINCIPLE. Change "private GTS" to "time slot". Accept second part as written. ResponseEnd: ----------- CommentID: 1712 CommenterName: Young, Song-Lin CommenterEmail: syoung@sharplabs.com CommenterPhone: 360-817-7509 CommenterFax: CommenterCo: Sharp Labs. of America Clause: 05 Subclause: 5.3.8 Page: 16 Line: 4 CommentType: TR Comment: Does this suggest any 802-compliant wireless devices can operate as a 15.3 neighbor piconet and solve co-existing issue? CommentEnd: SuggestedRemedy: This statement should be removed or clarified. RemedyEnd: 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". ResponseEnd: ----------- CommentID: 1661 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 05 Subclause: 5.5.2 Page: 16 Line: 3940 CommentType: T Comment: Again, privacy should be payload protection. CommentEnd: 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. RemedyEnd: Response: PROPOSED ACCEPT. Replacing sentence "If privacy . . . encrypt data." Change "during" to "after" the the suggested remedy. ResponseEnd: ----------- CommentID: 19 CommenterName: Bain, Jay CommenterEmail: jay.bain@timedomain.com CommenterPhone: 256 428 6415 CommenterFax: 256 527 4778 CommenterCo: Time Domain Clause: 05 Subclause: 5.5.2 Page: 16 Line: 42 CommentType: TR 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. CommentEnd: 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" RemedyEnd: Response: PROPOSED ACCEPT. ResponseEnd: ----------- CommentID: 868 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 05 Subclause: 5.5.3 Page: 16 Line: 48 CommentType: TR Comment: add some text CommentEnd: SuggestedRemedy: ... from the PNC during the CAP or MTS. RemedyEnd: Response: PROPOSED ACCEPT. Change "CAP" to "CAP or MTS". ResponseEnd: ----------- CommentID: 22 CommenterName: Bain, Jay CommenterEmail: jay.bain@timedomain.com CommenterPhone: 256 428 6415 CommenterFax: 256 527 4778 CommenterCo: Time Domain Clause: 05 Subclause: 5.5.4 Page: 17 Line: 4 CommentType: T Comment: I thought that we dropped the "data window." If we did, we should change the text in this subclause. CommentEnd: SuggestedRemedy: remove "data window of the" RemedyEnd: Response: PROPOSED ACCEPT. ResponseEnd: ----------- CommentID: 135 CommenterName: DuVal, Mary CommenterEmail: m-duval@ti.com CommenterPhone: 972-575-2330 CommenterFax: CommenterCo: Texas Instruments Clause: 05 Subclause: 5.6.1 Page: 17 Line: 38 CommentType: T 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? CommentEnd: SuggestedRemedy: Explain why this possible operation? Explain why it is necessary. RemedyEnd: Response: PROPOSED ACCEPT IN PRINCIPLE. Delete sentence on line 38 "However . . . The new piconet.". ResponseEnd: ----------- CommentID: 1376 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 05 Subclause: FIgure 1 Page: 14 Line: 41 CommentType: T Comment: CAP is devided into Command and Data - inconsistent with text CommentEnd: SuggestedRemedy: Remove reference to command and data from the cap in Figure 1 RemedyEnd: Response: PROPOSED ACCEPT. ResponseEnd: ----------- CommentID: 113 CommenterName: DuVal, Mary CommenterEmail: m-duval@ti.com CommenterPhone: 972-575-2330 CommenterFax: CommenterCo: Texas Instruments Clause: 05 Subclause: Figure 1 Page: 14 Line: 41 CommentType: T 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. CommentEnd: SuggestedRemedy: Clarify figure and explain in the section. RemedyEnd: 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." ResponseEnd: ----------- CommentID: 138 CommenterName: DuVal, Mary CommenterEmail: m-duval@ti.com CommenterPhone: 972-575-2330 CommenterFax: CommenterCo: Texas Instruments Clause: 06 Subclause: 1.1 Page: 20 Line: 5 CommentType: T Comment: How does MAC CPS fit into figure 2? CommentEnd: SuggestedRemedy: Include this term and how it relates in figure 2 RemedyEnd: Response: PROPOSED ACCEPT IN PRINCIPLE. Copy Figure A.1 to Figure 2 with any appropriate changes. Make sure suppporting text is adequate. ResponseEnd: ----------- CommentID: 1715 CommenterName: Young, Song-Lin CommenterEmail: syoung@sharplabs.com CommenterPhone: 360-817-7509 CommenterFax: CommenterCo: Sharp Labs. of America Clause: 06 Subclause: 3.13, 3.14 Page: 5055 Line: CommentType: TR Comment: No time out for these two primitives CommentEnd: SuggestedRemedy: Add time out parameters to the MLME-CREATE-STREME & MLME-MODIFY-STREME primitives RemedyEnd: Response: ResponseEnd: ----------- CommentID: 446 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 06 Subclause: 6.1 Page: 19 Line: 20 CommentType: T Comment: The figure does not include the SSCS layer. CommentEnd: SuggestedRemedy: Replace the figure with the one from A.1 or modify it to include the SSCS layer. RemedyEnd: Response: PROPOSED ACCEPT IN PRINCIPLE. Copy Figure A.1 to Figure 2 with any appropriate changes. Make sure suppporting text is adequate. ResponseEnd: ----------- CommentID: 447 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 06 Subclause: 6.1 Page: 19 Line: 44 CommentType: T Comment: Should list all of the SAPs in this enumeration. CommentEnd: SuggestedRemedy: Add SSCS SAP, MAC SAP and PHY SAP as items a and b (and fix numbering). RemedyEnd: Response: PROPOSED ACCEPT. ResponseEnd: ----------- CommentID: 550 CommenterName: GUBBI, RAJUGOPAL CommenterEmail: rgubbi@broadcom.com CommenterPhone: 408-543-3470 CommenterFax: CommenterCo: Broadcom, corp Clause: 06 Subclause: 6.1 Page: 76 Line: 41 CommentType: TR 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 CommentEnd: SuggestedRemedy: The 5 GHz and UWB should not be mentioned in this table to avoid confusion. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 874 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.2 Page: 20 Line: 20 CommentType: T Comment: replace the word PAN with personality CommentEnd: SuggestedRemedy: ... as a personality information ... RemedyEnd: 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". ResponseEnd: ----------- CommentID: 448 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 06 Subclause: 6.2 Page: 20 Line: 34 CommentType: T Comment: Add a table with definitions of the parameters for these commands. CommentEnd: 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 RemedyEnd: 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. ResponseEnd: ----------- CommentID: 1662 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.3 Table 1 Page: 22 Line: 51 CommentType: T 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. CommentEnd: SuggestedRemedy: Add a response message. Comment via Ari Singer. RemedyEnd: Response: PROPOSED REJECT. If DEV does not properly decode message, it will make another request. ResponseEnd: ----------- CommentID: 1422 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.3.1 Page: 23 Line: CommentType: TR Comment: Break MLME-POWERMGT command up into separate MLMEs, like security/authentication did. CommentEnd: SuggestedRemedy: Break up into Peer Wakup, wakeup, DEV to PNC PS Information, query, join... RemedyEnd: Response: PROPOSED ACCEPT. Jay and WMS will draft the new MLMEs. ResponseEnd: ----------- CommentID: 1407 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.3.1 Page: 25 Line: CommentType: TR Comment: Why is there no MLME-POWERMGT.response. The PNC should send a response in response to an indication. CommentEnd: SuggestedRemedy: Add MLME-POWERMGT.response RemedyEnd: 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. ResponseEnd: ----------- CommentID: 1405 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.3.1 Page: 25 Line: 10 CommentType: TR 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. CommentEnd: SuggestedRemedy: Add appropriate parameters to the indication. RemedyEnd: 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. ResponseEnd: ----------- CommentID: 25 CommenterName: Bain, Jay CommenterEmail: jay.bain@timedomain.com CommenterPhone: 256 428 6415 CommenterFax: 256 527 4778 CommenterCo: Time Domain Clause: 06 Subclause: 6.3.1.1 Page: 23 Line: 30 CommentType: TR Comment: Text mentions that information is available prior to association. In fact, the power management information is a post-assocation process. CommentEnd: SuggestedRemedy: change "prior to association" to "after association" RemedyEnd: Response: PROPOSED ACCEPT. ResponseEnd: ----------- CommentID: 450 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 06 Subclause: 6.3.1.1 Page: 23 Line: 31 CommentType: T Comment: Power managment commands are relevant only in the context of an associated device. CommentEnd: SuggestedRemedy: Change "to the DEV prior to association" to be "to the DEV after association" RemedyEnd: Response: PROPOSED ACCEPT. ResponseEnd: ----------- CommentID: 1393 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.3.1.1.2 Page: 24 Line: CommentType: T Comment: Need to specify which commands are associated with the generation of the MLME-POWERMANAGEMENT .request. CommentEnd: 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. RemedyEnd: Response: PROPOSED ACCEPT. Jay and WMS will do this while adding new MLME text. ResponseEnd: ----------- CommentID: 1404 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.3.1.1.2 Page: 24 Line: 48 CommentType: TR 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? CommentEnd: SuggestedRemedy: Put together a table that shows explicitly which PM commands are sent as a result of which PM primatives in the MLME RemedyEnd: Response: PROPOSED ACCEPT IN PRINCIPLE. Split MLME into separate primitives. Jay and WMS to provide. ResponseEnd: ----------- CommentID: 451 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 06 Subclause: 6.3.1.3 Page: 25 Line: 27 CommentType: T Comment: The power managment changes come about as a result of changes in the beacon, not from direct communications with other DEVs. CommentEnd: 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." RemedyEnd: Response: PROPOSED ACCEPT. ResponseEnd: ----------- CommentID: 1669 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.3.10 Page: Line: CommentType: T 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. CommentEnd: SuggestedRemedy: Recommend removing these commands. Comment via Ari Singer. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 462 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 06 Subclause: 6.3.10.1 Page: 44 Line: 34 CommentType: T Comment: The DeviceID parameter description is inaccurate. CommentEnd: SuggestedRemedy: Change "de-authentication process" to be "de-authentication process or the MAC entity which is requesting de-authentication" RemedyEnd: Response: ResponseEnd: ----------- CommentID: 463 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 06 Subclause: 6.3.10.1 Page: 44 Line: 36 CommentType: T Comment: The valid rane of the ReasonCode for de-authenticate is incorrect. CommentEnd: SuggestedRemedy: Add the "TIMEOUT" to the valid range RemedyEnd: Response: ResponseEnd: ----------- CommentID: 464 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 06 Subclause: 6.3.10.1 Page: 44 Line: 49 CommentType: T Comment: The de-authenticate command does not use a reason code. CommentEnd: 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). RemedyEnd: Response: ResponseEnd: ----------- CommentID: 592 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.11.1 Page: 46 Line: 10 CommentType: T Comment: DeviceID is an unnecessary parameter left over from 802.11. CommentEnd: SuggestedRemedy: Please remove. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 465 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 06 Subclause: 6.3.11.1 Page: 46 Line: 10 CommentType: T Comment: The DeviceID of a DEV is set through the PIB commands and should not be set here. CommentEnd: SuggestedRemedy: Delete the DeviceID primitive parameter from the semantics and table 18. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 595 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.11.1.2 Page: 46 Line: 38 CommentType: T Comment: Text describing the effect reception of the MLME-RESET.request primitive has on the local MAC entity is incomplete. CommentEnd: 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." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 597 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.11.1.2 Page: 46 Line: 40 CommentType: T Comment: Text describing the effect this primitive has upon the PNC MLME is missing. CommentEnd: 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. " RemedyEnd: Response: ResponseEnd: ----------- CommentID: 596 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.11.1.2 Page: 46 Line: 40 CommentType: T Comment: The last sentence of this clause is unnecessary. CommentEnd: SuggestedRemedy: Please remove the last sentence from this clause since the MLME-RESET.confirm is unneeded. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 598 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.11.2 Page: 46 Line: 42 CommentType: T Comment: Clauses 6.3.11.2, 6.3.11.2.1, 6.3.11.2.2, and Table 19 are unnecessary. CommentEnd: SuggestedRemedy: Please remove. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 293 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 06 Subclause: 6.3.12.1 Page: 47 Line: 45 CommentType: T Comment: The parameter CapabilityInformation field is listed in the primitive but is not defined. CommentEnd: SuggestedRemedy: Delete the parameter CapabilityInformation RemedyEnd: Response: ResponseEnd: ----------- CommentID: 916 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.3.12.1 Page: 47 Line: 53 CommentType: TR Comment: Add a figure CommentEnd: SuggestedRemedy: Add a figure to show the MACParameterSet vector RemedyEnd: Response: ResponseEnd: ----------- CommentID: 917 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.3.12.1 Page: 47 Line: 54 CommentType: TR Comment: Reference to CAP Mode CommentEnd: SuggestedRemedy: CAP Mode is not defined in clause 7.4.2. MAC subcommittee needs to clarify the reference here. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 601 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.12.2 Page: 48 Line: 20 CommentType: TR Comment: The PiconetDescriptionSet parameter is missing from the MLME-START.confirm primitive. CommentEnd: SuggestedRemedy: Please add the PiconetDescriptionSet parameter to the MLME-START.confirm primitive. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1424 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.3.12.2 Page: 48 Line: 21 CommentType: TR Comment: MLME-START.confirm should have the channel number that the piconet was started in. CommentEnd: SuggestedRemedy: Add Channel Number to the MLME-START.confirm parameters. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 602 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.13 Page: 48 Line: 45 CommentType: TR Comment: The MLME-CHANNEL-TIME.request, indication,response and confirm are missing. CommentEnd: SuggestedRemedy: Please insert clauses 6.xxxx from 01/410r1 into the space just before clause 6.3.13 Stream creation. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1428 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.3.13.1 Page: 50 Line: 22 CommentType: TR Comment: Add direction parameter to MLME-CREATE-STREAM.request CommentEnd: SuggestedRemedy: Add direction parameter RemedyEnd: Response: ResponseEnd: ----------- CommentID: 466 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 06 Subclause: 6.3.13.5 Page: 53 Line: 10 CommentType: T Comment: The primitive parameters for MLME-STREAM-CTA.indication are not defined. CommentEnd: SuggestedRemedy: Copy the definitions from table 25 for StreamIndex and SlotStartTimeSet into a table in 6.3.13.5 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1434 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.3.13.6 Page: 54 Line: CommentType: TR Comment: Eliminate tripartate negotiation. CommentEnd: SuggestedRemedy: bipartate negotiaon between the PNC and DEV is all that is needed. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1435 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.3.14 Page: 55 Line: CommentType: TR 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. CommentEnd: SuggestedRemedy: Add destination address to the MLME-MODIFY-STREAM.request RemedyEnd: Response: ResponseEnd: ----------- CommentID: 924 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.3.14.4.2 Page: 57 Line: 46 CommentType: TR Comment: ACK_TIMEOUT is referenced several times in clause 6.3.XX, but I can't find the definition of ACK_TIMEOUT. CommentEnd: SuggestedRemedy: MAC subcommittee to provide a clause reference to ACK_TIMEOUT. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 467 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 06 Subclause: 6.3.15 Page: 59 Line: 7 CommentType: T Comment: The definition of the ReasonCode for terminate stream is incorrect. CommentEnd: SuggestedRemedy: Change the 3 entries as follows: Type Valid range Description Enumeration SUCCESS, TIMEOUT Indicates the result of the stream termination command. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 604 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.16 Page: 61 Line: 23 CommentType: TR Comment: The MLME-Tx-POWER-CHANGE.request, indication, and confirm primitives are missing from Clause 6.3 MLME-SAP interface. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 468 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 06 Subclause: 6.3.16 Page: 61 Line: 31 CommentType: T Comment: The RequestorDEVAddress is not defined and the ReasonCode is missing an enumeration. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1438 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.3.16.1 Page: 62 Line: 7 CommentType: T Comment: The requesting DEV choose the window size, not the responding DEV. CommentEnd: 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 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 606 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.16.1 Page: 62 Line: 7 CommentType: T Comment: DestinationDEVAddress is an incorrect parameter name. CommentEnd: SuggestedRemedy: Please change to RemoteDevAID. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 607 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.16.1 Page: 62 Line: 8 CommentType: T Comment: ChannelIndex is an unnecessary parameter. Since the current Channel-Status command frame is only valid in the current piconet channel. CommentEnd: SuggestedRemedy: Please remove the ChannelIndex parameter from this primitive. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 470 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 06 Subclause: 6.3.16.1 Page: 62 Line: 8 CommentType: T Comment: ChannelIndex is an invalid parameter for a status report since all DEVs in the piconet use the same channel. CommentEnd: SuggestedRemedy: Delete ChannelIndex from the semantics of the primitive and delete "on the indicated ChannelIndex" from line 21. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 469 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 06 Subclause: 6.3.16.1 Page: 62 Line: 8 CommentType: T Comment: DestinationDEVAddress does not match other usage. CommentEnd: SuggestedRemedy: Change "DestinationDEVAddress" to be "RemoteDEVAddress" RemedyEnd: Response: ResponseEnd: ----------- CommentID: 608 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.16.1.1 Page: 62 Line: 16 CommentType: T Comment: DestinationDEVAddress is the wrong parameter name. CommentEnd: SuggestedRemedy: Please change from DestinationDEVAddress to RemoteDEVAID. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 613 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.16.1.1.2 Page: 62 Line: 22 CommentType: T Comment: The DestinationDEVAddress parameter at the end of the indicated sentence is incorrect. CommentEnd: SuggestedRemedy: Please change to RemoteDEVAID. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 610 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.16.1.2 Page: 62 Line: 21 CommentType: T Comment: the sentence fragment ...on the indicated ChannelIndex... is not needed. CommentEnd: SuggestedRemedy: Please remove the indicated sentence fragment. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 611 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.16.2 Page: 62 Line: 30 CommentType: T Comment: The RequestorDEVAddress in an incorrect parameter name. CommentEnd: SuggestedRemedy: Please change from RequestorDEVAddress to RequestorDEVAID. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 612 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.16.3 Page: 63 Line: 7 CommentType: T Comment: The RequestorDEVAddress is an incorrect parameter name CommentEnd: SuggestedRemedy: Please change to RequestorDEVAID. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 615 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.16.4 Page: 63 Line: 35 CommentType: T Comment: The RemoteDEVAddress is incorrect. CommentEnd: SuggestedRemedy: Please change to RemoteDEVAID. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 616 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.16.4.1 Page: 63 Line: 49 CommentType: T Comment: the ReasonCode message "ACK_TIMEOUT" at the end of the indicated sentence is incorrect. CommentEnd: SuggestedRemedy: Please change from ACK_TIMEOUT to RESPONSE_TIMEOUT. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 617 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.16.5 Page: 64 Line: 15 CommentType: T Comment: The MLME-CHANNEL-STATUS message sequence chart is missing the ChnlStatusRspTO timer. CommentEnd: SuggestedRemedy: Please provide the appropriate timer symbol for the message sequence chart. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 618 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.16.5 Page: 64 Line: 31 CommentType: TR Comment: The MLME-CREATE-REPEATER.request, indication, response, and confirm primitives are missing from the MLME-SAP interface clause. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 620 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.17 Page: 64 Line: 31 CommentType: TR Comment: The MLME-REMOTE-SCAN.request, indication, response and confirm primitives are missing from the MLME-SAP interface clause. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 619 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.17 Page: 64 Line: 31 CommentType: T Comment: The MLME-CHANNEL-STATUS and MLME-CREATE-REPEATER message sequence chart is missing. CommentEnd: 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 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 621 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.17 Page: 64 Line: 42 CommentType: T Comment: The NewChannelIndex data type is incorrect. CommentEnd: SuggestedRemedy: Please change from octet to integer. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 623 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.18 Page: 65 Line: 49 CommentType: T Comment: The MLME-CHANNEL-STATUS-, MLME-REMOTE-SCAN, and MLME-CHANGE-CHANNEL message sequence chart is missing from the MLME-SAP interface clause. CommentEnd: SuggestedRemedy: Please insert Clause 6.3.1.19 from doc 01/410r1 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 624 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.18 Page: 65 Line: 49 CommentType: T Comment: The MLME-PNC-HANDOVER.request is missing from the MLME-SAP interface clause. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 471 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 06 Subclause: 6.3.18 Page: 66 Line: 15 CommentType: T Comment: The ReasonCode needs "TIMEOUT" added as part of its valid range. CommentEnd: SuggestedRemedy: Change as indicated. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 472 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 06 Subclause: 6.3.18.1 Page: 66 Line: 19 CommentType: T Comment: The use of the probe request does not require that a DEV be authenticated. CommentEnd: 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). RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1670 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.3.18.1 Page: 66 Line: 1939 CommentType: T 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? CommentEnd: SuggestedRemedy: Recommend explaining the purpose of this command (if it isn't in there already). Comment via Ari Singer. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 630 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.18.1 Page: 66 Line: 24 CommentType: T Comment: The QueriedDEVIDSet parameter name is incorrect CommentEnd: SuggestedRemedy: Please change the QueriedDEVIDSet parameter name to QueriedDEVAID. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1440 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.3.18.1.2 Page: 66 Line: 35 CommentType: T Comment: What is the PROBE-PNC-REQUEST command? CommentEnd: SuggestedRemedy: Remove this and keep only DEVICE-INFORMATION-REQUEST command. Do this globally for 6.3.18.1-4 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 633 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.18.2 Page: 66 Line: 48 CommentType: T Comment: RequestorDEVAddress parameter name is incorrect. CommentEnd: SuggestedRemedy: Please change to: RequestorDEVAID. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 634 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.18.3 Page: 67 Line: 17 CommentType: T Comment: RequestorDEVAddress parameter name is incorrect CommentEnd: SuggestedRemedy: Please change to RequestorDEVAID RemedyEnd: Response: ResponseEnd: ----------- CommentID: 635 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.18.3 Page: 67 Line: 18 CommentType: T Comment: DevInfoSet parameter name is incorrect CommentEnd: SuggestedRemedy: Please change to: PNCInfoSet. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 637 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.18.4 Page: 67 Line: 38 CommentType: T Comment: DEVInfoSet parameter name is incorrect. CommentEnd: SuggestedRemedy: Please change to: PNCInfoSet RemedyEnd: Response: ResponseEnd: ----------- CommentID: 639 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.18.4.1 Page: 67 Line: 48 CommentType: T Comment: ACK_TIMEOUT ReasonCode is incorrect. CommentEnd: SuggestedRemedy: Please change to: RESPONSE_TIMEOUT RemedyEnd: Response: ResponseEnd: ----------- CommentID: 640 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.18.4.2 Page: 68 Line: 1 CommentType: TR Comment: This sentence fragment " ...and may initiate another MLME-PROBE-PNC.request... CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 632 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.18/2 Page: 66 Line: 47 CommentType: T Comment: QueriedDEVIDSet parameter name is incorrect. CommentEnd: SuggestedRemedy: Please change to: QueriedDEVAID. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 473 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 06 Subclause: 6.3.19 Page: 68 Line: 50 CommentType: T Comment: The definition of the ReasonCode is incorrect. CommentEnd: SuggestedRemedy: Change the two entries to be: Type Valid range Enumeration SUCCESS, TIMEOUT RemedyEnd: Response: ResponseEnd: ----------- CommentID: 474 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 06 Subclause: 6.3.19 Page: 69 Line: 1 CommentType: T Comment: The sentence "The ReasonCode ... for failure." does not belong here since it has been put into the table. CommentEnd: SuggestedRemedy: Delete the sentence. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 648 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.19.1 Page: 69 Line: 11 CommentType: T Comment: DestinationDEVAddress parameter name is incorrect CommentEnd: SuggestedRemedy: Please change to RemoteDEVAID RemedyEnd: Response: ResponseEnd: ----------- CommentID: 649 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.19.2 Page: 69 Line: 34 CommentType: T Comment: REquestorDEVAddress parameter is incorrect CommentEnd: SuggestedRemedy: Please change to RequestorDEVAID. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 650 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.19.3 Page: 70 Line: 8 CommentType: T Comment: RequestorDEVAddress parameter name is incorrect. CommentEnd: SuggestedRemedy: Please change to RequestorDEVAID RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1445 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.3.19.4 Page: Line: CommentType: TR Comment: MLME-DEV-INFO.confirm needs a DestinationDeviceID so the DME knows who is responding. CommentEnd: SuggestedRemedy: Add DestinationDeviceID (or new name) to the MLME confirm. RemedyEnd: Response: PROPOSED ACCEPT. ResponseEnd: ----------- CommentID: 652 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.19.4.1 Page: 70 Line: 37 CommentType: T Comment: ACK_TIMEOUT ReasonCode is incorrect. CommentEnd: SuggestedRemedy: Please change to RESPONSE-TIMEOUT. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 927 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.3.19.5 Page: 71 Line: 1 CommentType: TR Comment: Opening sentence is missing the opening clause. Modify as shown below. CommentEnd: SuggestedRemedy: Figure 10 illustrates the sequence of ... RemedyEnd: Response: ResponseEnd: ----------- CommentID: 452 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 06 Subclause: 6.3.2.1 Page: 26 Line: 21 CommentType: T Comment: No such thing as a generic PNID. This is handled by the OpenScan parameter. CommentEnd: SuggestedRemedy: Delete the words "generic or a" RemedyEnd: Response: PROPOSED ACCEPT. ResponseEnd: ----------- CommentID: 561 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.2.1 Page: 26 Line: 7 CommentType: TR Comment: OpenScan is an unneeded parameter. CommentEnd: SuggestedRemedy: Please remove the OpenScan parameter from the paramter list for the MLME-SCAN-REQUEST primitive. RemedyEnd: Response: PROPOSED REJECT. Openscan needed since there is no reserved PNID. ResponseEnd: ----------- CommentID: 453 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 06 Subclause: 6.3.2.1.2 Page: 26 Line: 42 CommentType: T 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. CommentEnd: SuggestedRemedy: Delete the sentences "The time spent by ... and aggregated into a PiconetDescriptionSet. RemedyEnd: Response: PROPOSED ACCEPT. Note that multiple paragraphs are being deleted. ResponseEnd: ----------- CommentID: 1409 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.3.2.1.2 Page: 26 Line: 45 CommentType: T 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 CommentEnd: SuggestedRemedy: Continue scan until all channels are scanned regardless if desired PNID is found. RemedyEnd: 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. ResponseEnd: ----------- CommentID: 1413 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.3.3 Page: 29 Line: CommentType: TR Comment: Need a MLME-SyncLost.indicate to tell the DME that the DEV can no longer hear the Beacon. CommentEnd: SuggestedRemedy: Add a MLME-SyncLost.indicate RemedyEnd: Response: PROPOSED ACCEPT IN PRINCIPLE. WMS to provide text. Has no parameters. Sent when the ATP expires with no beacon heard. ResponseEnd: ----------- CommentID: 569 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.3.1 Page: 28 Line: 8 CommentType: TR Comment: The functional description of the MLME-SYNCH.request primitive is incomplete. CommentEnd: 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. RemedyEnd: Response: PROPOSED REJECT. ResponseEnd: ----------- CommentID: 656 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.4.1 Page: 29 Line: 46 CommentType: T Comment: The DeviceAddress parameter is missing from the parameter list. CommentEnd: SuggestedRemedy: Please insert the DeviceAddress parameter into the MLME-ASSOCIATE.request parameter list just before the CapabilityInformation parameter. RemedyEnd: Response: PROPOSED REJECT. ResponseEnd: ----------- CommentID: 655 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.4.1.2 Page: 30 Line: 8 CommentType: T Comment: the sentence fragment "...specified by the the DeviceID parameter." is unnecessary. CommentEnd: SuggestedRemedy: Please remove the indicated sentence fragment. RemedyEnd: Response: PROPOSED ACCEPT. ResponseEnd: ----------- CommentID: 657 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.4.2 Page: 30 Line: 18 CommentType: T Comment: The DeviceID parameter name is incorrect. CommentEnd: SuggestedRemedy: Please change to DeviceAddress. RemedyEnd: Response: PROPOSED ACCEPT IN PRINCIPLE. DEVAddress instead of DeviceAddress. ResponseEnd: ----------- CommentID: 658 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.4.3 Page: 30 Line: 41 CommentType: T Comment: The DeviceID parameter name is incorrect CommentEnd: SuggestedRemedy: Please change to DeviceAddress. RemedyEnd: Response: PROPOSED ACCEPT IN PRINCIPLE. DEVAddress instead of DeviceAddress. ResponseEnd: ----------- CommentID: 659 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.4.3 Page: 30 Line: 42 CommentType: T Comment: The AssocDEVAddress parameter name is incorrect. CommentEnd: SuggestedRemedy: Please change to DeviceAID. RemedyEnd: Response: PROPOSED ACCEPT IN PRINCIPLE. DevID instead of DeviceAID. ResponseEnd: ----------- CommentID: 575 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.4.4 Page: 31 Line: 12 CommentType: TR Comment: AssocDEVAddress parameter name is incorrect. CommentEnd: SuggestedRemedy: Please change AssocDEVAddress to DeviceAID RemedyEnd: Response: PROPOSED ACCEPT IN PRINCIPLE. DevID instead of DeviceAID ResponseEnd: ----------- CommentID: 576 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.4.4.1 Page: 31 Line: 20 CommentType: TR Comment: The sentence fragment "...and a directed frame with null payload..." CommentEnd: SuggestedRemedy: Please change the indicated phrase to: "...and a beacon containing the NewAssociatedDEV Information element..." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 578 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.4.4.2 Page: 31 Line: 26 CommentType: TR Comment: AssocDEVAddress is an incorrect parameter name. CommentEnd: SuggestedRemedy: Please change both instances of AssocDEVAddress to DeviceAID. RemedyEnd: Response: PROPOSED ACCEPT IN PRINCIPLE. Use DevID instead of DeviceAID. ResponseEnd: ----------- CommentID: 579 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.4.5 Page: 32 Line: 1 CommentType: TR Comment: The title of clause 6.3.4.5 MLME-ASOCIATION-RESPONSE.indication is incorrect. CommentEnd: SuggestedRemedy: Please change the indicated clause title to: MLME-NEW-ASSOCIATED-DEV.indication. RemedyEnd: Response: PROPOSED ACCEPT IN PRINCIPLE. The clause is being deleted so it doesn't matter any longer. ResponseEnd: ----------- CommentID: 454 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 06 Subclause: 6.3.4.5 Page: 32 Line: 1 CommentType: T 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. CommentEnd: 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. RemedyEnd: Response: PROPOSED ACCEPT. Delete the command. 6.3.4.5 up to but not including 6.3.4.6 and including table 9. ResponseEnd: ----------- CommentID: 660 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.4.5 Page: 32 Line: 3 CommentType: TR Comment: The sentence fragment : "...reception of a broadcast ASSOCIATION-RESPONSE command." is incorrect. CommentEnd: SuggestedRemedy: Please change the indicated sentence fragment to: " ...reception of a beacon containing a NEW-ASSOCIATED-DEV information element. RemedyEnd: Response: PROPOSED ACCEPT IN PRINCIPLE. This section has been deleted. ResponseEnd: ----------- CommentID: 662 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.4.5 Page: 32 Line: 6 CommentType: TR Comment: The MLME-ASSOCIATION-RESPONSE.indication primitive no longer needed. CommentEnd: SuggestedRemedy: Please change the indicated primitive to: MLME-NEW-ASSOCIATED-DEV.indication. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 661 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.4.5 Page: 32 Line: 8 CommentType: T Comment: The ReasonCode parameter name is unneeded. CommentEnd: SuggestedRemedy: Please remove the ReasonCode parameter from the MLME-NEW-ASSOCIATED-DEV.indication parameter list. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 666 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.4.5.1 Page: 32 Line: 30 CommentType: T Comment: The sentence fragment "... a broadcast ASSOCIATION-RESPONSE command with a ReasonCode of SUCCESS." CommentEnd: SuggestedRemedy: Please change the indicated fragment to: "... a beacon containing a NEW-ASSOCIATED-DEV information element." RemedyEnd: Response: PROPOSED ACCEPT IN PRINCIPLE. This section has been deleted. ResponseEnd: ----------- CommentID: 667 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.4.5.2 Page: 32 Line: 35 CommentType: T Comment: The text describing the Effect of receipt is incorrect CommentEnd: 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." RemedyEnd: Response: PROPOSED ACCEPT IN PRINCIPLE. This section has been deleted. ResponseEnd: ----------- CommentID: 580 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.4.6 Page: 32 Line: 38 CommentType: T Comment: Missing Association message sequence chart. CommentEnd: SuggestedRemedy: Please provide missing message sequence chart. RemedyEnd: Response: PROPOSED ACCEPT IN PRINCIPLE. Al Heberling wil proivde MSC. ResponseEnd: ----------- CommentID: 886 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.3.4.6 Page: 32 Line: 39 CommentType: TR Comment: Missing MSC CommentEnd: SuggestedRemedy: Add in the MSC ... MAC subcommittee RemedyEnd: Response: PROPOSED ACCEPT IN PRINCIPLE. See 580. ResponseEnd: ----------- CommentID: 582 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.5.1 Page: 33 Line: 6 CommentType: TR Comment: DeviceID is incorrect parameter name and its data type is incorrect as well. CommentEnd: SuggestedRemedy: Please change DeviceID to DeviceAID and change the data type from MAC address to Integer with range 1-255. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 583 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.5.1 Page: 33 Line: 7 CommentType: T Comment: ReasonCode is unneccesary. CommentEnd: SuggestedRemedy: Please remove ReasonCode as a parameter. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 587 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.5.2 Page: 33 Line: 41 CommentType: T Comment: DeviceID parm name is incorrect. CommentEnd: SuggestedRemedy: Please change DeviceID to DeviceAID. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 588 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.5.2 Page: 33 Line: 42 CommentType: T Comment: ReasonCode is unneccesary. CommentEnd: SuggestedRemedy: Please remove ReasonCode as a parameter for this primitive. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 591 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.3.5.3 Page: 34 Line: 13 CommentType: TR 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. CommentEnd: SuggestedRemedy: Please remove MLME-Disassociate.confirm and its subclauses. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 850 CommenterName: Kleindl, Guenter CommenterEmail: guenter.kleindl@siemens.at CommenterPhone: 43 51707 35738 CommenterFax: CommenterCo: Siemens Clause: 06 Subclause: 6.3.6 Page: 3536 Line: CommentType: TR Comment: Include the possibility for authentication of the PNC. CommentEnd: SuggestedRemedy: Include the 'PublicKeyChallenge' as an optional parameter in the MLME-AUTHENTICATE.request and MLME-AUTHENTICATE.indication. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 851 CommenterName: Kleindl, Guenter CommenterEmail: guenter.kleindl@siemens.at CommenterPhone: 43 51707 35738 CommenterFax: CommenterCo: Siemens Clause: 06 Subclause: 6.3.6 Page: 3637 Line: CommentType: TR Comment: Include the possibility for authentication of the PNC. CommentEnd: SuggestedRemedy: Include the 'PublicKeyProofe' as a conditional parameter in the MLME-AUTHENTICATE.response and MLME-AUTHENTICATE.confirm. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1663 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.3.6 Table 13 Page: 35 Line: 140 CommentType: T 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. CommentEnd: SuggestedRemedy: Comment via Ari Singer. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 894 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.3.6.2.2 Page: 36 Line: 30 CommentType: TR Comment: The text says ... "The DME may use the MLME-CHALLENGE.request command to obtain additional security information from the associated DEV. CommentEnd: SuggestedRemedy: Security subgroup needs to provide reference in text where this procedure is described. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 895 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.3.6.2.2 Page: 36 Line: 32 CommentType: TR Comment: The text at the end of line 32 describes an authentication sequence. CommentEnd: SuggestedRemedy: Security subcommittee needs to provide text reference to this authentication sequence. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 455 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 06 Subclause: 6.3.7 Page: 37 Line: 54 CommentType: T Comment: The reason code is missing. CommentEnd: SuggestedRemedy: Add the following row to the table: Reason code enumeration SUCCESS, FAIL, Indicates the result of TIMEOUT the challenge command RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1664 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.3.7 Table 14 Page: 37 Line: 3554 CommentType: T 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. CommentEnd: SuggestedRemedy: Comment via Ari Singer. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 897 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.3.7.1 Page: 38 Line: 3 CommentType: TR Comment: Description of public key authentication challenge CommentEnd: SuggestedRemedy: What and where are the public key authentication challenge described? RemedyEnd: Response: ResponseEnd: ----------- CommentID: 898 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.3.7.4 Page: 39 Line: 31 CommentType: TR Comment: Missing ReasonCode CommentEnd: SuggestedRemedy: Table 14 does not define the ReasonCode. The security subcommittee needs to provide the reason codes. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1416 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.3.7.4 Page: 39 Line: 32 CommentType: TR Comment: Reason Code needs to be defined in Table 14 CommentEnd: SuggestedRemedy: Define the reason code in Table 14. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 456 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 06 Subclause: 6.3.8 Page: 40 Line: 11 CommentType: T Comment: The device ID purpose is incorrect. CommentEnd: SuggestedRemedy: Change "with which ... process" to "that is requesting the key" RemedyEnd: Response: ResponseEnd: ----------- CommentID: 458 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 06 Subclause: 6.3.8 Page: 40 Line: 25 CommentType: T Comment: The reason code for request key is missing. CommentEnd: 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 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1665 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.3.8 Table 15 Page: 40 Line: 725 CommentType: T Comment: EncryptedKeyObjectLength should have values greater than or equal to 0, not 1. It may be that this field is intentionally left blank. CommentEnd: SuggestedRemedy: Comment via Ari Singer. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 904 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.3.8.1.1 Page: 40 Line: 41 CommentType: TR Comment: PNC requirement to be the security manager CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 905 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.3.8.2.2 Page: 41 Line: 19 CommentType: TR Comment: Line 19 indicates that "the PNC shall encrypt and return the designated key" CommentEnd: SuggestedRemedy: Security committee needs to provide the encryption algorithm. What is the algorithm? RemedyEnd: Response: ResponseEnd: ----------- CommentID: 906 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.3.8.2.2 Page: 41 Line: 22 CommentType: TR Comment: In line 22, reference is made to a null key and the appropriate result code. CommentEnd: SuggestedRemedy: Security committee to provide definition of a null key and what are the associated (and appropriate) result codes. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 907 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.3.8.3 Page: 41 Line: 35 CommentType: TR Comment: Problem with ReasonCode parameter CommentEnd: SuggestedRemedy: Referenced table 15 does not provide the reason code definitions. Security committee needs to provide these reason codes. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1419 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.3.8.3 Page: 41 Line: 35 CommentType: TR Comment: Reason code needs to be defined in Tsable 15. CommentEnd: SuggestedRemedy: Define reason code in Table 15 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 909 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.3.8.4 Page: 42 Line: 4 CommentType: TR Comment: in line 4, reference is made to an "encrypted format". CommentEnd: SuggestedRemedy: Security subcommittee to provide the details as to what is this encrypted format. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1668 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.3.9 Page: Line: CommentType: T 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. CommentEnd: SuggestedRemedy: Comment via Ari Singer. RemedyEnd: Response: PROPOSED REJECT. If DEV does not properly decode message, it will make another request. ResponseEnd: ----------- CommentID: 459 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 06 Subclause: 6.3.9 Page: 42 Line: 35 CommentType: T Comment: The DeviceID description is incorrect. CommentEnd: SuggestedRemedy: Change "which which ... process" to "to which the key will be sent" RemedyEnd: Response: ResponseEnd: ----------- CommentID: 460 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 06 Subclause: 6.3.9 Page: 42 Line: 47 CommentType: T Comment: The ReasonCode for distribute key is not defined. CommentEnd: SuggestedRemedy: Add the following to the end of table 16: ReasonCode Enumeration SUCCESS, TIME_OUT Indicates the result of the distribute key command. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1667 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.3.9 Table 16 Page: 42 Line: 3147 CommentType: T Comment: EncryptedKeyObjectLength should have values greater than or equal to 0, not 1. It may be that this field is intentionally left blank. CommentEnd: SuggestedRemedy: Comment via Ari Singer. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 911 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.3.9.1/.2/.3 Page: 43 Line: 1 CommentType: TR Comment: Spelling error in 6.3.9.1, 6.3.9.2, and 6.3.9.3 CommentEnd: SuggestedRemedy: The commands are misspelt ... replace "distibute" with "distribute" RemedyEnd: Response: ResponseEnd: ----------- CommentID: 912 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.3.9.2.2 Page: 43 Line: 45 CommentType: T Comment: question on command type CommentEnd: SuggestedRemedy: Question for security committee ... in line 45 the command is given as "MLME.DISTRIBUTE-KEY.response". Should this be "MLME.DISTRIBUTE-KEY.indication"? RemedyEnd: Response: ResponseEnd: ----------- CommentID: 461 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 06 Subclause: 6.3.9.2.2 Page: 43 Line: 45 CommentType: T Comment: The MLME-DISTRIBUTE-KEY.response command does not exist. CommentEnd: SuggestedRemedy: Delete the sentence "The DME shall ... command." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1421 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.3.9.3 Page: 44 Line: 8 CommentType: TR Comment: Reason Code needs to be added to table 16 CommentEnd: SuggestedRemedy: Add reason code to table 16 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 913 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.3.9.3 Page: 44 Line: 8 CommentType: TR Comment: ReasonCode missing CommentEnd: SuggestedRemedy: Table 16 does not provide the reason code ... security committee needs to define the reason code. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 914 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.3.9.3.1 Page: 44 Line: 15 CommentType: TR Comment: Reference to "directed distribute key request command" and a "broadcast distributed key request command". These seem like two different commands. CommentEnd: SuggestedRemedy: Security commmittee needs to clarify what primitives handle these two commands. Are they differentiated by parameters? If so, which parameters? RemedyEnd: Response: ResponseEnd: ----------- CommentID: 654 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.4 Page: 71 Line: 21 CommentType: T Comment: The MLME-PNC-HANDOVER message sequence chart is missing. CommentEnd: 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 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 653 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: 6.4 Page: 71 Line: 26 CommentType: T Comment: The MLME-NEW-PNC.request, indication and confirm primitives are missing from the MLME-SAP interface clause. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 929 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.4.1 Page: 71 Line: 47 CommentType: T Comment: Modify as shown below ... CommentEnd: SuggestedRemedy: ... shall be a request by the PLME to reset ... RemedyEnd: Response: ResponseEnd: ----------- CommentID: 482 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 06 Subclause: 6.4.19.1 Page: 92 Line: 22 CommentType: T Comment: The descriptions of When generated and Effect of receipt are copied from another sub-clause and are incorrect for this one. CommentEnd: 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 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 930 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.4.2.2 Page: 72 Line: 33 CommentType: T Comment: Modify as shown below ... CommentEnd: SuggestedRemedy: The PLME is notified ... RemedyEnd: Response: ResponseEnd: ----------- CommentID: 932 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.4.4.2 Page: 73 Line: 42 CommentType: T Comment: Modify as shown below ... CommentEnd: SuggestedRemedy: The PLME is notified ... RemedyEnd: Response: ResponseEnd: ----------- CommentID: 934 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.5.1 Page: 74 Line: 41 CommentType: T Comment: Add reference to table CommentEnd: SuggestedRemedy: The PIB PNC group, Table 37, ... RemedyEnd: Response: ResponseEnd: ----------- CommentID: 935 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.5.2 Page: 74 Line: 46 CommentType: T Comment: Add reference to table CommentEnd: SuggestedRemedy: The PIB characteristics group, Table 38, ... RemedyEnd: Response: ResponseEnd: ----------- CommentID: 936 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.5.3 Page: 74 Line: 51 CommentType: T Comment: Add reference to the table CommentEnd: SuggestedRemedy: ... authentication group, Table 39, ... RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1671 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.5.3 Table 39 Page: 76 Line: 319 CommentType: T Comment: Why does the device care about the last device to authenticate and deauthenticate? Where does it get this information? CommentEnd: SuggestedRemedy: Remove AuthenticateFailDevice (why is it called "Fail" anyway?) and DeauthenticateDevice. Comment via Ari Singer. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 937 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.5.4 Page: 75 Line: 45 CommentType: T Comment: Add reference to table CommentEnd: SuggestedRemedy: ... association group, Table 40, contains ... RemedyEnd: Response: ResponseEnd: ----------- CommentID: 939 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.6.1 Page: 76 Line: 34 CommentType: T Comment: modify as shown below CommentEnd: SuggestedRemedy: ... on the regulatory domains for the 2.4 GHz PHY is given in 11.1. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1731 CommenterName: Karaoguz, Jeyhan CommenterEmail: jeyhan@broadcom.com CommenterPhone: 949 585 6168 CommenterFax: CommenterCo: Broadcom Corp. Clause: 06 Subclause: 6.6.1 Page: 76 Line: 41 CommentType: T 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. CommentEnd: SuggestedRemedy: The 5 GHz and UWB should not be mentioned in this table to avoid confusion. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 444 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 06 Subclause: 6.6.1 Page: 76 Line: 42 CommentType: T 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. CommentEnd: SuggestedRemedy: Delete the assignments for 5 GHz and UWB. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 940 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.6.2 Page: 77 Line: 4 CommentType: TR 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? CommentEnd: SuggestedRemedy: Refer to the PHY subgroup. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 445 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 06 Subclause: 6.6.8 Page: 79 Line: 5 CommentType: T Comment: The CCA threshold should depend on the transmitter power, which can be changed. CommentEnd: SuggestedRemedy: Change "Static" to "Dynamic" RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1732 CommenterName: Karaoguz, Jeyhan CommenterEmail: jeyhan@broadcom.com CommenterPhone: 949 585 6168 CommenterFax: CommenterCo: Broadcom Corp. Clause: 06 Subclause: 6.6.8 Page: 79 Line: 5 CommentType: T Comment: PHYPIB_CCA_Threshold is programmable but not enough guidance as to what values it should assume has been given in the standard. CommentEnd: SuggestedRemedy: I suggest that CCA threshold values should be defined depending on TX power levels similar to 802.11b standard. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1696 CommenterName: Siwiak, Kazimierz CommenterEmail: kai.siwiak@timedomain.com CommenterPhone: 954-755-6828 CommenterFax: 256-990-9062 CommenterCo: Time Domain Clause: 06 Subclause: 6.6.9 Page: 79 Line: 1023 CommentType: TR 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. CommentEnd: SuggestedRemedy: Remove the PHYPIB_Range object. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1733 CommenterName: Karaoguz, Jeyhan CommenterEmail: jeyhan@broadcom.com CommenterPhone: 949 585 6168 CommenterFax: CommenterCo: Broadcom Corp. Clause: 06 Subclause: 6.6.9 Page: 79 Line: 19 CommentType: T 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. CommentEnd: SuggestedRemedy: Allocate more bits for the fraction part of the range. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 945 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.6.9 Page: 79 Line: 9 CommentType: TR Comment: Need to add a statement to clause 6.6.9 that the PHY of clause 11 does not support ranging. CommentEnd: 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). RemedyEnd: Response: ResponseEnd: ----------- CommentID: 475 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 06 Subclause: 6.7.1.1 Page: 80 Line: 4 CommentType: T Comment: Multicast is not supported in this standard. CommentEnd: 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" RemedyEnd: 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. ResponseEnd: ----------- CommentID: 1454 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.7.1.1 Page: 80 Line: 6 CommentType: TR 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. CommentEnd: SuggestedRemedy: Make asynchronous data service optional. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 77 CommenterName: Barr, John CommenterEmail: John.Barr@Motorola.com CommenterPhone: 847-576-8706 CommenterFax: 847-651-6822 CommenterCo: Motorola Clause: 06 Subclause: 6.7.2 Page: 80 Line: 1824 CommentType: TR 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. CommentEnd: SuggestedRemedy: Remove Section 8.7.2. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 551 CommenterName: GUBBI, RAJUGOPAL CommenterEmail: rgubbi@broadcom.com CommenterPhone: 408-543-3470 CommenterFax: CommenterCo: Broadcom, corp Clause: 06 Subclause: 6.8 Page: 76 Line: 41 CommentType: TR Comment: PHYPIB_CCA_Threshold is programmable but not enough guidance as to what values it should assume has been given in the standard. CommentEnd: SuggestedRemedy: CCA threshold values should be defined depending on TX power levels similar to 802.11b standard. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1456 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.8.1 Page: 81 Line: CommentType: T Comment: Need a MAC_DATA.confirm to indicate status in the event of a failure. CommentEnd: SuggestedRemedy: Add a MAC_DATA.confirm RemedyEnd: Response: ResponseEnd: ----------- CommentID: 476 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 06 Subclause: 6.9.3 Page: 82 Line: 46 CommentType: T Comment: There is only one type of primitive defined in the PHY service specification now. CommentEnd: SuggestedRemedy: Delete "The primitives associated ... sub-layer to sub-layer interactions." and connect the following paragraph to the previous one. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 477 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 06 Subclause: 6.9.3.1 Page: 83 Line: 1 CommentType: T Comment: This sub-clause is redundant and therefore really irritates the technical editor while simultaneously promoting bad habits. CommentEnd: SuggestedRemedy: Delete sub-clause 6.9.3.1 in its entirety and wipe it from our minds. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 478 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 06 Subclause: 6.9.4.1 Page: 84 Line: 51 CommentType: T Comment: The definition of the DATA parameter is redundant and annoying. CommentEnd: SuggestedRemedy: Delete the sentence "The DATA parameters is an octet value." in 6.9.4.1 and 6.9.4.2. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 955 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.9.4.12 Page: 89 Line: 6 CommentType: TR 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. CommentEnd: SuggestedRemedy: Replace STATE with STATUS in two places as discussed above. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 480 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 06 Subclause: 6.9.4.12.1 Page: 89 Line: 18 CommentType: T Comment: The criteria given are not applicable to this standard. CommentEnd: SuggestedRemedy: Change "the period indicated ... has expired." to be "the chnannel has been quiet for an aCCADetectTime period." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 481 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 06 Subclause: 6.9.4.13 Page: 89 Line: 34 CommentType: T Comment: The AntSelect parameter is already defined and we don't need any more ants at our picnic. CommentEnd: SuggestedRemedy: Replace the sentence "AntSelect is an ... shall be used." with "The primitive parameter is defined in Table 55" RemedyEnd: Response: ResponseEnd: ----------- CommentID: 26 CommenterName: Bain, Jay CommenterEmail: jay.bain@timedomain.com CommenterPhone: 256 428 6415 CommenterFax: 256 527 4778 CommenterCo: Time Domain Clause: 06 Subclause: 6.9.4.19 Page: 92 Line: 1 CommentType: TR 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. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 27 CommenterName: Bain, Jay CommenterEmail: jay.bain@timedomain.com CommenterPhone: 256 428 6415 CommenterFax: 256 527 4778 CommenterCo: Time Domain Clause: 06 Subclause: 6.9.4.19.1 Page: 92 Line: 19 CommentType: TR 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. CommentEnd: SuggestedRemedy: change the when generated to : This primitive wil 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 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 479 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 06 Subclause: 6.9.4.4 Page: 86 Line: 11 CommentType: T Comment: There is no PLCP CommentEnd: SuggestedRemedy: Change "contains both the PLCP and PHY" to be "contains the PHY" RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1459 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: 6.9.4.4.2 Page: 86 Line: 21 CommentType: TR Comment: Need to specify that the preamble starts when this command is received. CommentEnd: SuggestedRemedy: Specify that the Preamble starts when PHY-TX-START.request is received. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 147 CommenterName: DuVal, Mary CommenterEmail: m-duval@ti.com CommenterPhone: 972-575-2330 CommenterFax: CommenterCo: Texas Instruments Clause: 06 Subclause: 8 Page: 80 Line: 44 CommentType: T Comment: MAC CPS SAP is not shown in Figure 2. It is hard to understand how it fits in without seeing the relationships pictorially. CommentEnd: SuggestedRemedy: Add MAC CPS SAP to Figure 2. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 23 CommenterName: Bain, Jay CommenterEmail: jay.bain@timedomain.com CommenterPhone: 256 428 6415 CommenterFax: 256 527 4778 CommenterCo: Time Domain Clause: 06 Subclause: figure 2 Page: 19 Line: 18 CommentType: T Comment: It would seem that the reference model should include something like a convergence layer for QoS. CommentEnd: SuggestedRemedy: Update the figure to include QoS sublayer if appropriate RemedyEnd: Response: PROPOSED ACCEPT IN PRINCIPLE. Copy Figure A.1 to Figure 2 with any appropriate changes. Make sure suppporting text is adequate. ResponseEnd: ----------- CommentID: 1390 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Figure 2 Page: 19 Line: 18 CommentType: T 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? CommentEnd: 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. RemedyEnd: Response: PROPOSED ACCEPT IN PRINCIPLE. Copy Figure A.1 to Figure 2 with any appropriate changes. Make sure suppporting text is adequate. ResponseEnd: ----------- CommentID: 668 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: Table 10 Page: 33 Line: 15 CommentType: T Comment: DeviceID parm name, data type, valid range, and description are incorrect CommentEnd: 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." RemedyEnd: Response: PROPOSED ACCEPT IN PRINCIPLE. DevID, type Integer, range any valid DevID (xref 7.2.3) Specifies the DevID of the peer MAC entity . . . ResponseEnd: ----------- CommentID: 584 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: Table 10 Page: 33 Line: 19 CommentType: T Comment: ReasonCode is unneccesary. CommentEnd: SuggestedRemedy: Please remove ReasonCode from Table 10. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 590 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: Table 11 Page: 34 Line: 10 CommentType: T Comment: ReasonCode is unnecessary. CommentEnd: SuggestedRemedy: Please remove ReasonCode from Table 11. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 589 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: Table 11 Page: 34 Line: 5 CommentType: T Comment: DeviceID parameter name, data type, Valid range and description fields are incorrect. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 889 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table 13 Page: 35 Line: 1 CommentType: T 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? CommentEnd: SuggestedRemedy: Refer to MAC/security subcommittee to supply number of octets. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 893 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table 13 Page: 35 Line: 17 CommentType: T Comment: Wrong word CommentEnd: SuggestedRemedy: second line of description for AuthenticationInfoLength parameter ... change the word "device" to "defined" RemedyEnd: Response: ResponseEnd: ----------- CommentID: 890 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table 13 Page: 35 Line: 22 CommentType: TR Comment: Unused parameters CommentEnd: SuggestedRemedy: The following are listed as parameters for a primitive ... but no primitives use these. Where are they used? SecurityManagerPublicKeyObjectLength SecurityManagerPublicKeyObject RemedyEnd: Response: ResponseEnd: ----------- CommentID: 891 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table 13 Page: 35 Line: 28 CommentType: T Comment: Unused parameters CommentEnd: SuggestedRemedy: Delete the following parameters from table 13. They are used in table 14 and are redundant. PublicKeyChallengeLength PublicKeyChallenge PublicKeyProofLength PublicKeyProof RemedyEnd: Response: ResponseEnd: ----------- CommentID: 892 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table 13 Page: 35 Line: 8 CommentType: TR Comment: Reference to cipher suite CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 74 CommenterName: Barr, John CommenterEmail: John.Barr@Motorola.com CommenterPhone: 847-576-8706 CommenterFax: 847-651-6822 CommenterCo: Motorola Clause: 06 Subclause: Table 14 Page: 37 Line: 0 CommentType: TR Comment: The MLME-CHALLENGE primitive parameters does not include the ReasonCode parameter CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 896 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table 14 Page: 37 Line: 35 CommentType: T 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? CommentEnd: SuggestedRemedy: Refer to MAC/security subcommittee to supply number of octets. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 902 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table 15 Page: 40 Line: CommentType: TR Comment: Add following to clause 4 acronyms CommentEnd: SuggestedRemedy: DEK DIK SEED RemedyEnd: Response: ResponseEnd: ----------- CommentID: 901 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table 15 Page: 40 Line: CommentType: T Comment: Need octets associated with Types integer and byte string in table 15 CommentEnd: SuggestedRemedy: MAC/security provide octets RemedyEnd: Response: ResponseEnd: ----------- CommentID: 903 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table 15 Page: 40 Line: CommentType: TR Comment: Unused parameter CommentEnd: SuggestedRemedy: In table 15, the parameter DistributeKeyFailureTimeout is defined but not used by any primitives. Security committee needs to clarify. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 900 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table 15 Page: 40 Line: 13 CommentType: TR Comment: Lacking definition and explaination CommentEnd: SuggestedRemedy: security subcommittee needs to define and explain usage of the following items from table 15 KEK DEK DIK SEED RemedyEnd: Response: ResponseEnd: ----------- CommentID: 910 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table 16 Page: 42 Line: CommentType: TR Comment: In type column of table 16, how many octets are required? CommentEnd: SuggestedRemedy: security committee to provide octets RemedyEnd: Response: ResponseEnd: ----------- CommentID: 593 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: Table 18 Page: 46 Line: 19 CommentType: T Comment: DeviceID is an unnecessary entry in the parameter table. CommentEnd: SuggestedRemedy: Please remove. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1397 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table 2 Page: 24 Line: 12 CommentType: T Comment: Why is EPSTime in ms and not superframes? CommentEnd: SuggestedRemedy: Change EPS time to superframes. Only 8 bits needed. RemedyEnd: Response: PROPOSED REJECT. This is just to wake up the dev host. Not required who did it and could be multiple. ResponseEnd: ----------- CommentID: 1396 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table 2 Page: 24 Line: 19 CommentType: T Comment: Is EPS Sync only allowed in the PNC? CommentEnd: SuggestedRemedy: Clarify RemedyEnd: Response: PROPOSED ACCEPT IN PRINCIPLE. Clarification will be made in 7.5.7.1. ResponseEnd: ----------- CommentID: 879 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table 2 Page: 24 Line: 43 CommentType: TR Comment: Reason code definitions ... there are no reason codes in clause 7.5.7.2 CommentEnd: SuggestedRemedy: have management subgroup provide proper reference to reason codes RemedyEnd: Response: PROPOSED ACCEPT IN PRINCIPLE. Change xref from 7.5.7.2. To Table 67. Change ResonCode to ActionType. ResponseEnd: ----------- CommentID: 1427 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table 22 Page: 49 Line: CommentType: TR Comment: Direction bit needed for the MLME-CREATE-STREAM parameters. CommentEnd: SuggestedRemedy: Add direction bit. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 918 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table 22 Page: 49 Line: CommentType: TR Comment: Provide a figure that shows the vector representation of "ServiceFlowList" and "ARQList" as reflected in tables 23 and 24 respectively. CommentEnd: SuggestedRemedy: Add these two figures to clause 6.3.13 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1426 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table 22 Page: 49 Line: 17 CommentType: TR 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. CommentEnd: SuggestedRemedy: Change 2 octet Sequence Number field to 1 octet StreamRequestIdentifier. Change all instances of SequenceNumber to StreamRequestIdentifier in all of clause 6. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1425 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table 22 Page: 49 Line: 5 CommentType: TR 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. CommentEnd: SuggestedRemedy: Replace these 8 bit AD-ADs with 48 bit MAC Address RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1429 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table 23 Page: 49 Line: 3540 CommentType: TR 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. CommentEnd: SuggestedRemedy: Remove Peak Rate, Min rate and Max Burst Size from from service flow and stream management. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 139 CommenterName: DuVal, Mary CommenterEmail: m-duval@ti.com CommenterPhone: 972-575-2330 CommenterFax: CommenterCo: Texas Instruments Clause: 06 Subclause: Table 23 Page: 49 Line: 49 CommentType: TR Comment: Is MaxTXDelayVariation the same thing as Jitter? 802.11e has both a jitter and a delay bound. Which is being specified here? CommentEnd: SuggestedRemedy: I would like to see both jitter and delay defined. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 921 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table 25 Page: 55 Line: CommentType: TR Comment: How is EPS impacted by a stream modification. Does the "SlotStartTimeSet" parameter shown in table 25 also apply to SFNext? CommentEnd: SuggestedRemedy: Refer this question to the power management subcommittee. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 920 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table 25 Page: 55 Line: CommentType: TR Comment: Add a figure to show the ChannelTimeList vector as referenced in table 26 CommentEnd: SuggestedRemedy: Add this figure RemedyEnd: Response: ResponseEnd: ----------- CommentID: 141 CommenterName: DuVal, Mary CommenterEmail: m-duval@ti.com CommenterPhone: 972-575-2330 CommenterFax: CommenterCo: Texas Instruments Clause: 06 Subclause: Table 26 Page: 55 Line: 42 CommentType: TR 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? CommentEnd: SuggestedRemedy: I would like to see both jitter and delay defined. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 605 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: Table 28 Page: 61 Line: 33 CommentType: T Comment: The RemoteDEVAddress is an inconsistent parameter name. Also its data type is incorrect. CommentEnd: SuggestedRemedy: Please change RemoteDevAddress to RemoteDevAID and its data type to an integer with a range of 0-255 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 622 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: Table 29 Page: 64 Line: 45 CommentType: T Comment: The ChannelChangeTimeout data type is incorrect. CommentEnd: SuggestedRemedy: Please change the data type from octet to Duration with valid range of 0 to 255 ms? RemedyEnd: Response: ResponseEnd: ----------- CommentID: 562 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: Table 3 Page: 26 Line: 16 CommentType: TR Comment: The OpenScan paramter is unneeded. CommentEnd: SuggestedRemedy: Please remove the OpenScan parameter from Table 3. RemedyEnd: Response: PROPOSED REJECT. ResponseEnd: ----------- CommentID: 563 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: Table 3 Page: 26 Line: 22 CommentType: TR Comment: The definition for PNID is partially correct. CommentEnd: 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." RemedyEnd: Response: PROPOSED REJECT. Openscan is used rather than a reserved PNID. ResponseEnd: ----------- CommentID: 881 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table 3 Page: 26 Line: 27 CommentType: T Comment: Valid range for the ChannelScanDuration CommentEnd: SuggestedRemedy: range is listed as 100-65535 ... should this be 0-65535? RemedyEnd: Response: PROPOSED ACCEPT. ResponseEnd: ----------- CommentID: 564 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: Table 3 Page: 26 Line: 29 CommentType: T Comment: The last sentence of the ChannelScanDuration description is not needed. CommentEnd: SuggestedRemedy: Please remove the last sentence of the ChannelScanDuration description. RemedyEnd: Response: PROPOSED ACCEPT. ResponseEnd: ----------- CommentID: 629 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: Table 30 Page: 66 Line: 11 CommentType: T Comment: DEVInfoSet is an incorrect parameter name. CommentEnd: SuggestedRemedy: Please change the DEVInfoSet parameter name to: PNCInfoSet. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 627 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: Table 30 Page: 66 Line: 5 CommentType: T Comment: QueriedDEVIDSet is an incorrect parameter name, data type and valid range. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 628 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: Table 30 Page: 66 Line: 8 CommentType: T Comment: The RequestorDEVAddress parameter name, its data type, valid range and description are incorrrect. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 642 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: Table 31 Page: 68 Line: 39 CommentType: T Comment: DestinationDEVAddress parameter name is incorrect, data type is incorrect, valid range is incorrect, and description are incorrect. CommentEnd: 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 ..." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 643 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: Table 31 Page: 68 Line: 42 CommentType: T Comment: RequestorDEVAddress parameter name is incorrect, the data type is incorrect, valid range is incorrect, and the description is incorrect. CommentEnd: 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." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 644 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: Table 31 Page: 68 Line: 50 CommentType: T Comment: The ReasonCode data type field is incorrect and its valid range is incorrect. CommentEnd: SuggestedRemedy: Please change ReasonCode data type field to: Enumeration, and the valid range to: "SUCCESS, RESPONSE_TIMEOUT RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1447 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table 38 Page: 75 Line: 34 CommentType: T Comment: Dont really need 65535 CTAs CommentEnd: SuggestedRemedy: Change MACPIBMaxProcessedCTAs to 8 bits RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1248 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table 39 Page: 76 Line: CommentType: TR Comment: The second entry in this table is "privacy". Are we going to call this privacy or security. CommentEnd: 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.) RemedyEnd: Response: ResponseEnd: ----------- CommentID: 941 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table 44 Page: 77 Line: CommentType: TR Comment: The Managed objects are PHY dependent but are not defined in clause 11. CommentEnd: SuggestedRemedy: The PHY subcommittee needs to add the following items to clause 11 PHYPIB_TxMaxPower PHYPIB_TxPowerStepSize PHYPIB_CurrentPowerLevel RemedyEnd: Response: ResponseEnd: ----------- CommentID: 942 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table 47 Page: 78 Line: CommentType: TR Comment: Managed Object in Table 47 is misspelt CommentEnd: SuggestedRemedy: Correct spelling ... it should be PHYPIB_MPDULengthMax RemedyEnd: Response: ResponseEnd: ----------- CommentID: 943 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table 47 Page: 78 Line: CommentType: TR Comment: Clause 11 does not list the managed object CommentEnd: SuggestedRemedy: Define PHYPIB_MPDULengthMax in clause 11 ... refer to PHY subcommittee RemedyEnd: Response: ResponseEnd: ----------- CommentID: 944 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table 48 Page: 79 Line: CommentType: TR Comment: Managed Object is misspelt CommentEnd: SuggestedRemedy: Spelling should be PHYPIB_CCAThreshold RemedyEnd: Response: ResponseEnd: ----------- CommentID: 565 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: Table 5 Page: 27 Line: 35 CommentType: TR Comment: DeviceID is inconsistently used through out the document. CommentEnd: 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. RemedyEnd: 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. ResponseEnd: ----------- CommentID: 566 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: Table 5 Page: 27 Line: 37 CommentType: T Comment: The Beacon Period data type is incorrect. CommentEnd: SuggestedRemedy: Please change the Beacon Period data type to duration. RemedyEnd: 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. ResponseEnd: ----------- CommentID: 567 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: Table 5 Page: 27 Line: 39 CommentType: T Comment: The parameter Channel is incomplete. CommentEnd: SuggestedRemedy: Please change the parameter Channel to ChannelIndex and its data type to integer. RemedyEnd: Response: PROPOSED ACCEPT. ResponseEnd: ----------- CommentID: 568 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: Table 5 Page: 27 Line: 41 CommentType: T Comment: The parameter name " Parent Device ID" is inconsistent. CommentEnd: SuggestedRemedy: Please change the parameter name from Parent Device ID to ParentDevAddress which is more consistent with its data type of MAC address(48bit) RemedyEnd: Response: PROPOSED ACCEPT. ResponseEnd: ----------- CommentID: 946 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table 50 Page: 79 Line: CommentType: TR Comment: Clause 11 does not address the managed objects of table 50 CommentEnd: SuggestedRemedy: The PHY committee needs to add reference to the values used for PHYPIB_NumPSLevels and PHYPIB_PSLevelReturn. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 952 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table 54 Page: 84 Line: CommentType: T Comment: Add figures to illustrate the vectors TXVECTOR and RXVECTOR CommentEnd: SuggestedRemedy: add two figures RemedyEnd: Response: ResponseEnd: ----------- CommentID: 953 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table 55 Page: 84 Line: CommentType: TR Comment: Unused parameter ... CommentEnd: 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? RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1458 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table 56 Page: 84 Line: 33 CommentType: TR Comment: Remove PHYPIB_DataRates from the Rx vector. It should be Rxtate, not PIB. CommentEnd: SuggestedRemedy: Change PHYPIB_DataRates to RxRate RemedyEnd: Response: ResponseEnd: ----------- CommentID: 883 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table 6 Page: 28 Line: 25 CommentType: T Comment: Type for SyncFailureTimeout CommentEnd: SuggestedRemedy: Should this be one octet? Is there an upper limit? RemedyEnd: Response: PROPOSED ACCEPT IN PRINCIPLE. Resolved as in 566. Upper limit not specified. ResponseEnd: ----------- CommentID: 570 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: Table 8 Page: 29 Line: 25 CommentType: T Comment: DeviceID is inconsistent with its data type. CommentEnd: SuggestedRemedy: Please change DeviceID to DeviceAddress since its data type is MAC address(48bit) RemedyEnd: Response: PROPOSED ACCEPT IN PRINCIPLE. DEVAddress ResponseEnd: ----------- CommentID: 884 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table 8 Page: 29 Line: 31 CommentType: T Comment: Type for AssociationTimeOutPeriod CommentEnd: SuggestedRemedy: Should be integer with 2 octets RemedyEnd: 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. ResponseEnd: ----------- CommentID: 572 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: Table 8 Page: 29 Line: 32 CommentType: TR Comment: AssociationTimeOutPeriod has an incorrect data type. CommentEnd: SuggestedRemedy: The AssociationTimeOutPeriod data type should be changed from Integer to Duration. RemedyEnd: Response: PROPOSED ACCEPT. ResponseEnd: ----------- CommentID: 571 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: Table 8 Page: 29 Line: 33 CommentType: T Comment: AssocDevAddress is inconsistent with its data type. CommentEnd: SuggestedRemedy: Please change AssocDevAddress to DeviceAid which is short for Device Assoiciation ID. Also change the data type from octet to integer. RemedyEnd: Response: PROPOSED ACCEPT IN PRINCIPLE. Change AssocDevAddress to DevID. Note: Change AD-AD to DevID as well in draft. ResponseEnd: ----------- CommentID: 663 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: Table 9 Page: 32 Line: 18 CommentType: T Comment: The ReasonCode parameter, data type, valid range, and Description are unnecessary given the new name of this primitive. CommentEnd: SuggestedRemedy: Please remove the indicated fields from the table. RemedyEnd: Response: PROPOSED ACCEPT IN PRINCIPLE. Table 9 has been deleted. ResponseEnd: ----------- CommentID: 664 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: Table 9 Page: 32 Line: 20 CommentType: T Comment: The DeviceID parameter name, and description are incorrect. CommentEnd: SuggestedRemedy: Please change the DeviceID parm name to DeviceAddress. Also change the Description to: The deviceAddress of the DEV that has been associated. RemedyEnd: Response: PROPOSED ACCEPT IN PRINCIPLE. Table 9 has been deleted. ResponseEnd: ----------- CommentID: 665 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 06 Subclause: Table 9 Page: 32 Line: 23 CommentType: T Comment: The AssocDEVAddress parm name, data type, and description are incorrect. CommentEnd: 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." RemedyEnd: Response: PROPOSED ACCEPT IN PRINCIPLE. Table 9 has been deleted. ResponseEnd: ----------- CommentID: 1414 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table13 Page: 35 Line: 5 CommentType: TR 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. CommentEnd: SuggestedRemedy: Add maximum values into the Valid Range column for all fields. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1415 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table14 Page: 37 Line: 37 CommentType: TR Comment: Table 14 needs maximum valuse in the range so that implementers can size their design. CommentEnd: SuggestedRemedy: Add maximum values into the range column in Table 14 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1417 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table15 Page: 40 Line: 725 CommentType: TR Comment: Table 15 needs maximum values in the range column CommentEnd: SuggestedRemedy: Add max into the Valid Range column RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1420 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table16 Page: 42 Line: 32 CommentType: TR Comment: Need max values column CommentEnd: SuggestedRemedy: Need Max Values Column. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1406 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table2 Page: 24 Line: CommentType: TR Comment: If you have peer wakeup, you need to have a peer address CommentEnd: SuggestedRemedy: add peer address to the MLME parameters RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1401 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table2 Page: 24 Line: 23 CommentType: TR Comment: It is not clear why the PNC needs to know that the device is RPS vs. PM_OFF. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1402 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table2 Page: 24 Line: 28 CommentType: TR Comment: Why is PowerManagementPriority here and not in the capability field where it belongs. CommentEnd: 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. RemedyEnd: 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. ResponseEnd: ----------- CommentID: 1400 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table2 Page: 24 Line: 37 CommentType: TR Comment: There is no request type for Peer Wakeup, wakeup, DEV to PNC PS Information Command CommentEnd: SuggestedRemedy: Add Peer wakeup request type RemedyEnd: Response: PROPOSED ACCEPT IN PRINCIPLE. Split MLME PowerMgmt command into separate MLMEs for each command. Jay and WMS are providing. ResponseEnd: ----------- CommentID: 1408 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table31 Page: 26 Line: 21 CommentType: TR 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? CommentEnd: SuggestedRemedy: Need to address where PNID to scan for comes from. RemedyEnd: Response: PROPOSED ACCEPT IN PRINCIPLE. DME has option of remembering PNID to allow DEV to join a specific piconet. ResponseEnd: ----------- CommentID: 1446 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table37 Page: 75 Line: 7 CommentType: T Comment: What is MACPIBCFPMaxDuration used for CommentEnd: SuggestedRemedy: Get rid of MACPIBCFPMaxDuration RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1449 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table42 Page: 77 Line: CommentType: TR Comment: PHYPIB_CurrentDataRate shouldn't be a PHY PIB. It is passed at the PHY SAP on a packet by packet basis. CommentEnd: SuggestedRemedy: Remove PHYPIB_CurrentDataRate from the PIB RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1450 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table43 Page: Line: CommentType: TR 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. CommentEnd: SuggestedRemedy: Remove current Rx and Current Tx antenna from PIB RemedyEnd: Response: PROPOSED ACCEPT. ResponseEnd: ----------- CommentID: 1451 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table44 Page: 77 Line: 52 CommentType: TR Comment: Current Power Level doesn't belong in the PIB. It is sent with each packet at the PHY SAP CommentEnd: SuggestedRemedy: Remove PHYPIB_CurrentPowerLevel from the PIB RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1410 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table5 Page: 27 Line: 33 CommentType: TR Comment: There is no way to indicate that a frame with the PNID was found, but not a beacon CommentEnd: 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. RemedyEnd: 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. ResponseEnd: ----------- CommentID: 1412 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table5 Page: 27 Line: 43 CommentType: TR Comment: No indication of power level if no beacon found. CommentEnd: SuggestedRemedy: Provide a signal strength field for avoidance of 802.11 or other users RemedyEnd: 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." ResponseEnd: ----------- CommentID: 1457 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Table55 Page: 84 Line: CommentType: TR Comment: Data Rate and Power Level should not be PIB parameters. Rename the value. CommentEnd: SuggestedRemedy: change data rate and power lavel from being PIB valuse RemedyEnd: Response: ResponseEnd: ----------- CommentID: 954 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 06 Subclause: Tables 55 and 56 Page: 84 Line: CommentType: T Comment: Add text to explain why the TX and RX MAC headers are passed in the TX and RX vectors. CommentEnd: 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." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1499 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Page: 109 Line: 33 CommentType: TR 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? CommentEnd: SuggestedRemedy: Please clarify. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1469 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 12 Page: 97 Line: 12 CommentType: T 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. CommentEnd: SuggestedRemedy: Reduce sequence number to 4 bits if we eliminate delayed ACK. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 154 CommenterName: DuVal, Mary CommenterEmail: m-duval@ti.com CommenterPhone: 972-575-2330 CommenterFax: CommenterCo: Texas Instruments Clause: 07 Subclause: 2.1.10 Page: 96 Line: 15 CommentType: T 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)? CommentEnd: SuggestedRemedy: Need understanding of this feature. Not explained well. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 492 CommenterName: GUBBI, RAJUGOPAL CommenterEmail: rgubbi@broadcom.com CommenterPhone: 408-543-3470 CommenterFax: CommenterCo: Broadcom, corp Clause: 07 Subclause: 2.1.7 Page: Line: CommentType: TR 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. CommentEnd: SuggestedRemedy: Remove "retry bit" from frame control field and mark its current position as reserved for future use RemedyEnd: Response: ResponseEnd: ----------- CommentID: 495 CommenterName: GUBBI, RAJUGOPAL CommenterEmail: rgubbi@broadcom.com CommenterPhone: 408-543-3470 CommenterFax: CommenterCo: Broadcom, corp Clause: 07 Subclause: 2.3 Page: Line: CommentType: TR Comment: Reserve 0xF0 to 0xF9 for future use: We never know what else we'll need special addresses for. CommentEnd: SuggestedRemedy: Reserve 0xF0 to 0xF9 for future use RemedyEnd: Response: ResponseEnd: ----------- CommentID: 496 CommenterName: GUBBI, RAJUGOPAL CommenterEmail: rgubbi@broadcom.com CommenterPhone: 408-543-3470 CommenterFax: CommenterCo: Broadcom, corp Clause: 07 Subclause: 2.3 Page: 97 Line: 8 CommentType: TR Comment: In clause 8, it is mandated that isoch data shall always be streams. But here it seems to say it is upto DEV. CommentEnd: SuggestedRemedy: Remove "or isochronous" in line 8 and add "All isochronous data transfers shall be streams" RemedyEnd: Response: ResponseEnd: ----------- CommentID: 157 CommenterName: DuVal, Mary CommenterEmail: m-duval@ti.com CommenterPhone: 972-575-2330 CommenterFax: CommenterCo: Texas Instruments Clause: 07 Subclause: 3.1 Page: 98 Line: 29 CommentType: T 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? CommentEnd: SuggestedRemedy: Clarify meaning or method of information determination. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 158 CommenterName: DuVal, Mary CommenterEmail: m-duval@ti.com CommenterPhone: 972-575-2330 CommenterFax: CommenterCo: Texas Instruments Clause: 07 Subclause: 3.1 Page: 98 Line: 30 CommentType: T 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. CommentEnd: SuggestedRemedy: Need a clear understanding of what is optional and what is mandatory. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1721 CommenterName: Young, Song-Lin CommenterEmail: syoung@sharplabs.com CommenterPhone: 360-817-7509 CommenterFax: CommenterCo: Sharp Labs. of America Clause: 07 Subclause: 3.1, Table 60 Page: 98 Line: CommentType: TR Comment: PNC should be able to broadcast Application specific information (Table 63, p101) as needed CommentEnd: SuggestedRemedy: Add entry for Application specific information in Table 60 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 498 CommenterName: GUBBI, RAJUGOPAL CommenterEmail: rgubbi@broadcom.com CommenterPhone: 408-543-3470 CommenterFax: CommenterCo: Broadcom, corp Clause: 07 Subclause: 4 Page: Line: CommentType: TR 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 CommentEnd: SuggestedRemedy: Chnage the description in 7.5.5.1 from info-element to command RemedyEnd: Response: ResponseEnd: ----------- CommentID: 497 CommenterName: GUBBI, RAJUGOPAL CommenterEmail: rgubbi@broadcom.com CommenterPhone: 408-543-3470 CommenterFax: CommenterCo: Broadcom, corp Clause: 07 Subclause: 4 Page: Line: CommentType: TR 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 CommentEnd: SuggestedRemedy: Move Transmit power change from Table-63 to Table-65 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 502 CommenterName: GUBBI, RAJUGOPAL CommenterEmail: rgubbi@broadcom.com CommenterPhone: 408-543-3470 CommenterFax: CommenterCo: Broadcom, corp Clause: 07 Subclause: 4.10 Page: 106 Line: CommentType: TR 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 CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 503 CommenterName: GUBBI, RAJUGOPAL CommenterEmail: rgubbi@broadcom.com CommenterPhone: 408-543-3470 CommenterFax: CommenterCo: Broadcom, corp Clause: 07 Subclause: 4.10 Page: 107 Line: CommentType: TR Comment: Key change field in figure-31 is unused CommentEnd: SuggestedRemedy: remove "key change" field from figure-31 and mark b2 as reserved. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 161 CommenterName: DuVal, Mary CommenterEmail: m-duval@ti.com CommenterPhone: 972-575-2330 CommenterFax: CommenterCo: Texas Instruments Clause: 07 Subclause: 4.10 Page: 107 Line: 34 CommentType: T 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? CommentEnd: SuggestedRemedy: Pick a value of 1. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1351 CommenterName: Seals, Michael CommenterEmail: mseals@intersil.com CommenterPhone: (321) 724-7172 CommenterFax: CommenterCo: Intersil Clause: 07 Subclause: 4.10 Page: 107 Line: 35 CommentType: TR Comment: The meaning of the key change bit is TBD. CommentEnd: SuggestedRemedy: Define the meaning or remove the bit. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 162 CommenterName: DuVal, Mary CommenterEmail: m-duval@ti.com CommenterPhone: 972-575-2330 CommenterFax: CommenterCo: Texas Instruments Clause: 07 Subclause: 4.10 Page: 107 Line: 35 CommentType: TR 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. CommentEnd: SuggestedRemedy: Looks like agreement is needed here to determine the requirement for this place holder. Finish discussion and complete requirement. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 505 CommenterName: GUBBI, RAJUGOPAL CommenterEmail: rgubbi@broadcom.com CommenterPhone: 408-543-3470 CommenterFax: CommenterCo: Broadcom, corp Clause: 07 Subclause: 4.10 Page: 107 Line: 46 CommentType: TR Comment: Use of "guard time" without defining it. Beacon does not contain it. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 507 CommenterName: GUBBI, RAJUGOPAL CommenterEmail: rgubbi@broadcom.com CommenterPhone: 408-543-3470 CommenterFax: CommenterCo: Broadcom, corp Clause: 07 Subclause: 4.12 Page: 108 Line: CommentType: TR 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. Besdie 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. CommentEnd: SuggestedRemedy: Remove DEV GTS status element and all references to it from the draft. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 508 CommenterName: GUBBI, RAJUGOPAL CommenterEmail: rgubbi@broadcom.com CommenterPhone: 408-543-3470 CommenterFax: CommenterCo: Broadcom, corp Clause: 07 Subclause: 4.13 Page: 109 Line: CommentType: TR 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? CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 165 CommenterName: DuVal, Mary CommenterEmail: m-duval@ti.com CommenterPhone: 972-575-2330 CommenterFax: CommenterCo: Texas Instruments Clause: 07 Subclause: 4.13 Page: 109 Line: 18 CommentType: T 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? CommentEnd: SuggestedRemedy: RemedyEnd: Response: ResponseEnd: ----------- CommentID: 510 CommenterName: GUBBI, RAJUGOPAL CommenterEmail: rgubbi@broadcom.com CommenterPhone: 408-543-3470 CommenterFax: CommenterCo: Broadcom, corp Clause: 07 Subclause: 4.15 Page: 110 Line: CommentType: TR 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. CommentEnd: SuggestedRemedy: Move the association related commands to the top to start from value 0x0000, followed by authentication commands. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 512 CommenterName: GUBBI, RAJUGOPAL CommenterEmail: rgubbi@broadcom.com CommenterPhone: 408-543-3470 CommenterFax: CommenterCo: Broadcom, corp Clause: 07 Subclause: 4.15 Page: 110 Line: CommentType: TR 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? CommentEnd: 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 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 499 CommenterName: GUBBI, RAJUGOPAL CommenterEmail: rgubbi@broadcom.com CommenterPhone: 408-543-3470 CommenterFax: CommenterCo: Broadcom, corp Clause: 07 Subclause: 4.2 Page: 103 Line: 13 CommentType: TR 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. CommentEnd: SuggestedRemedy: Remove Key number from Figure-19 and all references to it from the draft RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1722 CommenterName: Young, Song-Lin CommenterEmail: syoung@sharplabs.com CommenterPhone: 360-817-7509 CommenterFax: CommenterCo: Sharp Labs. of America Clause: 07 Subclause: 4.3, Fig.22 Page: 103 Line: CommentType: TR 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. CommentEnd: SuggestedRemedy: Add 'product category' field to capability information RemedyEnd: Response: ResponseEnd: ----------- CommentID: 160 CommenterName: DuVal, Mary CommenterEmail: m-duval@ti.com CommenterPhone: 972-575-2330 CommenterFax: CommenterCo: Texas Instruments Clause: 07 Subclause: 4.5 Page: 104 Line: 54 CommentType: T Comment: "in Kus" (with u meaning micro here) - is this to mean that units are 1024 usecs? CommentEnd: SuggestedRemedy: Unclear about actual meaning. State clearly. RemedyEnd: Response: Changing all Kus to ms in document. ResponseEnd: ----------- CommentID: 500 CommenterName: GUBBI, RAJUGOPAL CommenterEmail: rgubbi@broadcom.com CommenterPhone: 408-543-3470 CommenterFax: CommenterCo: Broadcom, corp Clause: 07 Subclause: 4.6 Page: 105 Line: CommentType: TR Comment: Supported rates in 11.7 presents less than one octet encoding to indicate the support for multiple rates. CommentEnd: SuggestedRemedy: Change "supported rates" field in figure-25 from (1-8) octet(s) to 1-octet. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1716 CommenterName: Young, Song-Lin CommenterEmail: syoung@sharplabs.com CommenterPhone: 360-817-7509 CommenterFax: CommenterCo: Sharp Labs. of America Clause: 07 Subclause: 5.10 Page: 130 Line: 25 CommentType: TR 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). CommentEnd: 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 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 526 CommenterName: GUBBI, RAJUGOPAL CommenterEmail: rgubbi@broadcom.com CommenterPhone: 408-543-3470 CommenterFax: CommenterCo: Broadcom, corp Clause: 07 Subclause: 5.10.1 Page: Line: CommentType: TR 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. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 524 CommenterName: GUBBI, RAJUGOPAL CommenterEmail: rgubbi@broadcom.com CommenterPhone: 408-543-3470 CommenterFax: CommenterCo: Broadcom, corp Clause: 07 Subclause: 5.10.1 Page: Line: CommentType: TR 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. CommentEnd: SuggestedRemedy: Remove CTRB type, EPS set and allocation period from figure-72 and all references to those fields from the draft. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 525 CommenterName: GUBBI, RAJUGOPAL CommenterEmail: rgubbi@broadcom.com CommenterPhone: 408-543-3470 CommenterFax: CommenterCo: Broadcom, corp Clause: 07 Subclause: 5.10.1 Page: Line: CommentType: TR 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. CommentEnd: 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 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 527 CommenterName: GUBBI, RAJUGOPAL CommenterEmail: rgubbi@broadcom.com CommenterPhone: 408-543-3470 CommenterFax: CommenterCo: Broadcom, corp Clause: 07 Subclause: 5.10.1 Page: Line: CommentType: TR Comment: Action type is incomplete CommentEnd: SuggestedRemedy: specify a value of '3' to be applicable for "Dest-DEV to PNC" case also. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 528 CommenterName: GUBBI, RAJUGOPAL CommenterEmail: rgubbi@broadcom.com CommenterPhone: 408-543-3470 CommenterFax: CommenterCo: Broadcom, corp Clause: 07 Subclause: 5.10.3 Page: Line: CommentType: TR 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. CommentEnd: 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 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 529 CommenterName: GUBBI, RAJUGOPAL CommenterEmail: rgubbi@broadcom.com CommenterPhone: 408-543-3470 CommenterFax: CommenterCo: Broadcom, corp Clause: 07 Subclause: 5.10.3 Page: Line: CommentType: TR Comment: MAx TX delay variation in figure-77 and MAximum allocation delay in figure-72 are same but have different name and description CommentEnd: 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 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1352 CommenterName: Seals, Michael CommenterEmail: mseals@intersil.com CommenterPhone: (321) 724-7172 CommenterFax: CommenterCo: Intersil Clause: 07 Subclause: 5.10.3 Page: 133 Line: 39 CommentType: TR Comment: The security field is TBD. CommentEnd: SuggestedRemedy: Define the field or remove it. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 515 CommenterName: GUBBI, RAJUGOPAL CommenterEmail: rgubbi@broadcom.com CommenterPhone: 408-543-3470 CommenterFax: CommenterCo: Broadcom, corp Clause: 07 Subclause: 5.3 Page: Line: CommentType: TR Comment: Use of redundant fields that increase the overhead and lead to inconsistencies in the implementation CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 516 CommenterName: GUBBI, RAJUGOPAL CommenterEmail: rgubbi@broadcom.com CommenterPhone: 408-543-3470 CommenterFax: CommenterCo: Broadcom, corp Clause: 07 Subclause: 5.4 Page: Line: CommentType: TR 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 CommentEnd: 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 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 518 CommenterName: GUBBI, RAJUGOPAL CommenterEmail: rgubbi@broadcom.com CommenterPhone: 408-543-3470 CommenterFax: CommenterCo: Broadcom, corp Clause: 07 Subclause: 5.7 Page: Line: CommentType: TR 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? CommentEnd: 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 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1718 CommenterName: Young, Song-Lin CommenterEmail: syoung@sharplabs.com CommenterPhone: 360-817-7509 CommenterFax: CommenterCo: Sharp Labs. of America Clause: 07 Subclause: 5.8.3 Page: 128 Line: CommentType: T 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? CommentEnd: SuggestedRemedy: Please clarify RemedyEnd: Response: ResponseEnd: ----------- CommentID: 299 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.1 Page: 93 Line: 14 CommentType: T Comment: Enumeration items are inclomplete in their description. CommentEnd: 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" RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1112 CommenterName: Schrader, Mark CommenterEmail: mark.e.schrader@kodak.com CommenterPhone: 585-253-5241 CommenterFax: CommenterCo: Eastman Kodak Co. Clause: 07 Subclause: 7.1 Page: 93 Line: 15 CommentType: T 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. CommentEnd: 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). RemedyEnd: Response: ResponseEnd: ----------- CommentID: 957 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.1 Page: 93 Line: 16 CommentType: TR 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). CommentEnd: SuggestedRemedy: Question for MAC subcommittee ... resolve if this is the correct name. Is there another more common name used in the document? RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1462 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.1.1 Page: 93 Line: 26 CommentType: T 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. CommentEnd: SuggestedRemedy: replace with "order in which they are transmitted on the air," RemedyEnd: Response: ResponseEnd: ----------- CommentID: 300 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.1.1 Page: 93 Line: 26 CommentType: T Comment: Requirements are not strong enough for bit ordering. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 301 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.1.1 Page: 93 Line: 27 CommentType: T Comment: Need a figure to show how the bit ordering is used in the figures that follow. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 960 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.1.1 Page: 93 Line: 36 CommentType: TR Comment: Item to add to clause 3 CommentEnd: SuggestedRemedy: Please add the definition of a "natural number" to clause 3 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1360 CommenterName: Shellhammer, Steve CommenterEmail: shell@symbol.com CommenterPhone: (631) 738-4302 CommenterFax: CommenterCo: Symbol Technologies Clause: 07 Subclause: 7.2 Page: 9596 Line: CommentType: T Comment: The MAC Frame includes a retry bit and a sequence number field. It seems that the sequence number makes the retry bit unnecessary. CommentEnd: SuggestedRemedy: Eliminate the retry bit if it is in fact redundant RemedyEnd: Response: ResponseEnd: ----------- CommentID: 302 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.2.1 Page: 94 Line: 25 CommentType: T Comment: The description of the frame control field repeats what is in the figure and therefore is redundant and evil. CommentEnd: SuggestedRemedy: Change "consists of the ... and repeater" with "is used to identify the type of frame and how it is to be handled." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 805 CommenterName: Kleindl, Guenter CommenterEmail: guenter.kleindl@siemens.at CommenterPhone: 43 51707 35738 CommenterFax: CommenterCo: Siemens Clause: 07 Subclause: 7.2.1 Page: 94 Line: 30 CommentType: TR Comment: in Figure 12 bit 10 is missing CommentEnd: SuggestedRemedy: Add bit 10 in figure 12 and indicate 'reserved', possibly reorder the bits. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 303 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.2.1 Page: 94 Line: 44 CommentType: T Comment: "will" is not formal language. CommentEnd: SuggestedRemedy: Change "supports will discard" to "supports may discard" RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1464 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.2.1.2 Page: 95 Line: 4 CommentType: T Comment: Get rid of Delayed ACK. This will unnecessarily complicate the MAC to implement. We should keep a WPAN as simple as possible. CommentEnd: SuggestedRemedy: Eliminate Delayed ACK. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 852 CommenterName: Kleindl, Guenter CommenterEmail: guenter.kleindl@siemens.at CommenterPhone: 43 51707 35738 CommenterFax: CommenterCo: Siemens Clause: 07 Subclause: 7.2.1.3 Page: 95 Line: 21 CommentType: T Comment: Immediate acknowledgement can be indicated in the ACK-policy field. Therefore the frame type 'Immediate acknowledgement' is redundant. CommentEnd: SuggestedRemedy: If ACK-policy field is used to indicate 'immediate acknowledgement' than the frame type 'Immediate acknowledgement' may be removed. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 304 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.2.1.5 Page: 95 Line: 37 CommentType: T Comment: Informal language used, change to shall CommentEnd: 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 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 806 CommenterName: Kleindl, Guenter CommenterEmail: guenter.kleindl@siemens.at CommenterPhone: 43 51707 35738 CommenterFax: CommenterCo: Siemens Clause: 07 Subclause: 7.2.1.5 Page: 95 Line: 38 CommentType: T Comment: clarify value of frag-start field for frames, which are not fragmented CommentEnd: SuggestedRemedy: add additional text at the end of the first sentence e.g.: ...start of the current MSDU/MCDU, which consists of multiple fregments. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 961 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.2.1.5 & 7.2.1.6 Page: 95 Line: 36 CommentType: T Comment: Why two Frag fields ... start and end? CommentEnd: SuggestedRemedy: Couldn't the fragmentation process be signified by setting a single bit? 0=not fragmentating and 1=fragmentating RemedyEnd: Response: ResponseEnd: ----------- CommentID: 807 CommenterName: Kleindl, Guenter CommenterEmail: guenter.kleindl@siemens.at CommenterPhone: 43 51707 35738 CommenterFax: CommenterCo: Siemens Clause: 07 Subclause: 7.2.1.6 Page: 95 Line: 43 CommentType: T Comment: clarify value of frag-end field for frames, which are not fragmented CommentEnd: SuggestedRemedy: add additional text at the end of the first sentence e.g.: ...end of the current MSDU/MCDU, which consists of multiple fregments. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 962 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.2.1.9 Page: 96 Line: 9 CommentType: TR Comment: Lack reference to information on encryption key CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1467 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.2.2 Page: 96 Line: 20 CommentType: TR 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? CommentEnd: SuggestedRemedy: Need to describe the details of persistence of the PNID. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 305 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.2.3 Page: 96 Line: 34 CommentType: T 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). CommentEnd: 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). RemedyEnd: Response: PROPOSED REJECT. ResponseEnd: ----------- CommentID: 1468 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.2.3 Page: 96 Line: 35 CommentType: T Comment: Not sure why 3 addresses are reserved for neighbor piconets. Why 3? Is that enough? CommentEnd: SuggestedRemedy: Describe the benefit of using a reserved address, or else just use the capability field for a DEV to indicate a neighbor piconet? RemedyEnd: Response: ResponseEnd: ----------- CommentID: 963 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.2.3 Page: 96 Line: 35 CommentType: TR Comment: There are only 3 addresses available for neighor piconets. CommentEnd: SuggestedRemedy: Please increase the addresses available from 3 to 6 ... 4 on each side, 1 above and 1 below. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 808 CommenterName: Kleindl, Guenter CommenterEmail: guenter.kleindl@siemens.at CommenterPhone: 43 51707 35738 CommenterFax: CommenterCo: Siemens Clause: 07 Subclause: 7.2.3 Page: 96 Line: 35 CommentType: T Comment: There are address values for neighbor piconets, but not for child piconets. CommentEnd: SuggestedRemedy: Add address values for child piconets, if required. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 306 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.2.4 Page: 96 Line: 40 CommentType: T Comment: Informal language CommentEnd: 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 " RemedyEnd: Response: ResponseEnd: ----------- CommentID: 307 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.2.4 Page: 96 Line: 50 CommentType: T Comment: Add requirement for formatting. CommentEnd: SuggestedRemedy: Change "... and priority." to be "... and priority and shall be formatted as illustrated in Fig. 13." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1470 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.2.5 Page: 97 Line: 14 CommentType: T 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. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1361 CommenterName: Shellhammer, Steve CommenterEmail: shell@symbol.com CommenterPhone: (631) 738-4302 CommenterFax: CommenterCo: Symbol Technologies Clause: 07 Subclause: 7.2.6 Page: 97 Line: CommentType: T 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. CommentEnd: SuggestedRemedy: Have the MAC, not the PHY, calculate and implement the MCS. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1471 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.2.6 Page: 97 Line: 28 CommentType: T Comment: Need to clarify that the MAC ignores the HCS. CommentEnd: SuggestedRemedy: add the following sentence "The MAC always ignores the CS field upon reception." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 308 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.2.7 Page: 97 Line: 33 CommentType: T Comment: Security information is no longer included as separate data, delete this reference. CommentEnd: SuggestedRemedy: Delete ", including the security information if any" RemedyEnd: Response: ResponseEnd: ----------- CommentID: 964 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.2.7 Page: 97 Line: 34 CommentType: TR Comment: This clause states there is security information in the frame body. CommentEnd: SuggestedRemedy: Provide reference to the specific clause 10 subclause that describes this security information. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 309 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.2.8 Page: 97 Line: 43 CommentType: T Comment: Informal language CommentEnd: 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" RemedyEnd: Response: ResponseEnd: ----------- CommentID: 310 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.2.8 Page: 98 Line: 1 CommentType: T Comment: Informal language. Also, shouldn't all implementations initiallize the the HCS remainder to the same number? CommentEnd: 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 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1473 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.3.1 Page: 98 Line: 29 CommentType: TR Comment: Allowing inforamtion elements in any order in the beacon will complicate the design. CTAs should be the last IEs in the beacon. CommentEnd: 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." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 311 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.3.1 Page: 98 Line: 44 CommentType: T 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. CommentEnd: 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" RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1478 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.3.3 Page: Line: CommentType: TR 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. CommentEnd: SuggestedRemedy: Change to : "Command data units (MCDUs) cannot be fragmented." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 312 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.3.3 Page: 100 Line: 6 CommentType: T Comment: Not all commands are allowed to be chained together. Some shall be sent individually CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 313 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.4 Page: 101 Line: 26 CommentType: T Comment: The transmit power change is a command, not an information element and has already been moved to the appropriate location in the draft. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 736 CommenterName: Huang, Bob CommenterEmail: robert.huang@am.sony.com CommenterPhone: 201-358-4409 CommenterFax: CommenterCo: Sony Electronics Clause: 07 Subclause: 7.4 Table 63 Page: 101 Line: 3637 CommentType: TR 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. CommentEnd: 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). RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1480 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.4.1 Page: 102 Line: CommentType: T Comment: What is the purpose of max burst duration? Is this for a single frame, or for multiple frames? CommentEnd: SuggestedRemedy: Clarify the use of max burst duration or eliminate it. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 320 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.4.10 Page: 106 Line: 46 CommentType: T Comment: Change the label "Slot Start time or SFNext" to be "slot location" since that is how it is referenced in the definitions. CommentEnd: SuggestedRemedy: Change as indicated. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1489 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.4.10 Page: 107 Line: 1 CommentType: TR 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. CommentEnd: SuggestedRemedy: Change this to say that directed frames are allowed in a broadcast GTS. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 989 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.4.10 Page: 107 Line: 28 CommentType: T Comment: This paragraph references a field that contains "the least significant two octets of a beacon number". CommentEnd: SuggestedRemedy: This paragraph is confusing. Power management subcomittee needs to clarify and provide addditional references to other clauses. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 990 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.4.10 Page: 107 Line: 33 CommentType: TR Comment: appears there is a typo as shown below CommentEnd: SuggestedRemedy: ... and shall be set to 1 if they are in EPS mode. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1113 CommenterName: Schrader, Mark CommenterEmail: mark.e.schrader@kodak.com CommenterPhone: 585-253-5241 CommenterFax: CommenterCo: Eastman Kodak Co. Clause: 07 Subclause: 7.4.10 Page: 107 Line: 33 CommentType: T Comment: CTA type specified the same for ACTIVE and EPS modes CommentEnd: SuggestedRemedy: Change to: ... and shall be set to 1 if they are in EPS mode. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 818 CommenterName: Kleindl, Guenter CommenterEmail: guenter.kleindl@siemens.at CommenterPhone: 43 51707 35738 CommenterFax: CommenterCo: Siemens Clause: 07 Subclause: 7.4.10 Page: 107 Line: 34 CommentType: TR Comment: incorrect setting of CTA-type-bit CommentEnd: SuggestedRemedy: correct text to: ... shall be set to 1 if they are in EPS mode. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 991 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.4.10 Page: 107 Line: 35 CommentType: TR Comment: Need to resolve TDB CommentEnd: SuggestedRemedy: Security subcommittee needs to resolve this TBD in this line. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1674 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.4.10 Page: 107 Line: 35 CommentType: T 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. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 296 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.4.10 Page: 107 Line: 36 CommentType: T Comment: TBD in "The key change bit is reserved for possible security implementation with TBD meaning" CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1491 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.4.10 Page: 107 Line: 43 CommentType: TR 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. CommentEnd: 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." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1492 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.4.10 Page: 107 Line: 46 CommentType: TR Comment: This line will change when we add the duration field back in as we agreed to. CommentEnd: SuggestedRemedy: Modify this sentenc to say" The eand of each GTS slot is the start of the GTS slot plus the duration. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1114 CommenterName: Schrader, Mark CommenterEmail: mark.e.schrader@kodak.com CommenterPhone: 585-253-5241 CommenterFax: CommenterCo: Eastman Kodak Co. Clause: 07 Subclause: 7.4.10 Page: 108 Line: 10 CommentType: T Comment: Line in table says AWAKE rather than WAKE, and does not indicate that there is a GTS slot. CommentEnd: SuggestedRemedy: Change entry to: EPS CTA, WAKE superframe w/ GTS RemedyEnd: Response: ResponseEnd: ----------- CommentID: 321 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.4.11 Page: 108 Line: 30 CommentType: T Comment: Multicast capabilities are not defined for this protocol. CommentEnd: SuggestedRemedy: Delete the sentence "The destination address may include group or multicast destinations." RemedyEnd: 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'. ResponseEnd: ----------- CommentID: 1495 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.4.11 Page: 108 Line: 33 CommentType: TR 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. CommentEnd: SuggestedRemedy: Remove the Max CTAs field and all references to it. We would be better off limiting the number of CTAs in a piconet. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 819 CommenterName: Kleindl, Guenter CommenterEmail: guenter.kleindl@siemens.at CommenterPhone: 43 51707 35738 CommenterFax: CommenterCo: Siemens Clause: 07 Subclause: 7.4.12 Page: 108 Line: 49 CommentType: TR Comment: wrong octet number and length (256 bits = 32 octets) CommentEnd: SuggestedRemedy: correct from 8 to 32 octets Lenth(=32) RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1500 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.4.13 Page: 109 Line: 33 CommentType: TR 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. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 322 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.4.13 Page: 109 Line: 33 CommentType: T Comment: Informal language used to define characteristics. CommentEnd: 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" RemedyEnd: Response: ResponseEnd: ----------- CommentID: 323 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.4.13 Page: 109 Line: 36 CommentType: T Comment: Informal language to describe the characterisitcs of EPS status CommentEnd: 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" RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1497 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.4.13 Page: 5 Line: 8 CommentType: TR 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. CommentEnd: SuggestedRemedy: Please clarify where this element is used or remove it. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 997 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.4.14 Page: 109 Line: CommentType: T Comment: Deletion of clause 7.4.14 CommentEnd: SuggestedRemedy: I see no need for the application specific information information element. Unless someone can justify it, please delete the entire clause. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1502 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.4.14 Page: 109 Line: 4 CommentType: TR Comment: How is gteh application specific data put into the ASIE There is no MLME to do this. CommentEnd: SuggestedRemedy: Need to create and MLME to put application specific data into the ASIE. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 763 CommenterName: Huang, Bob CommenterEmail: robert.huang@am.sony.com CommenterPhone: 201-358-4409 CommenterFax: CommenterCo: Sony Electronics Clause: 07 Subclause: 7.4.14 Page: 110 Line: 9 CommentType: TR 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. CommentEnd: SuggestedRemedy: Add MLME. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 324 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.4.14 Page: 110 Line: 9 CommentType: T Comment: The restrictions on negotiating theuse of the ASIE is too restrictive. CommentEnd: SuggestedRemedy: Delete " using a standard a GTS or CFP message exchange" since the negotiation is outside of the scope of the standard. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 972 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.4.2 Page: 102 Line: 43 CommentType: T 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. CommentEnd: SuggestedRemedy: Bill Shvodian of XtremeSpectrum to provide text on a recommended solution. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 314 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.4.2 Page: 102 Line: 49 CommentType: T Comment: The CAP duration is not the time offset from the start of the beacon to the start of the CFP. CommentEnd: SuggestedRemedy: Change "The same value is used as the time offset" to "The same value is used to calculate the time offset" RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1479 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.4.2 Page: 102 Line: 50 CommentType: TR 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. CommentEnd: SuggestedRemedy: The duration of the CAP is computed as the difference between the superframe duration and the CFP duration minus the Beacon time. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 45 CommenterName: Bain, Jay CommenterEmail: jay.bain@timedomain.com CommenterPhone: 256 428 6415 CommenterFax: 256 527 4778 CommenterCo: Time Domain Clause: 07 Subclause: 7.4.2 Page: 102 Line: 52 CommentType: T 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. CommentEnd: SuggestedRemedy: specify setting for MTS. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 973 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.4.2 Page: 103 Line: 1 CommentType: TR Comment: Reference is made to the "current data encyrption key (DEK)" CommentEnd: SuggestedRemedy: Provide reference to the DEK details. If the subclause is missing in clause 10 then provide the details. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 315 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.4.2 Page: 103 Line: 29 CommentType: T 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. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1481 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.4.2 Page: 103 Line: 29 CommentType: TR Comment: Rather than wasting a value, change the ecoding so that in the future we can allow a key per SA/DA pair. CommentEnd: 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 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 813 CommenterName: Kleindl, Guenter CommenterEmail: guenter.kleindl@siemens.at CommenterPhone: 43 51707 35738 CommenterFax: CommenterCo: Siemens Clause: 07 Subclause: 7.4.3 Page: 103 Line: 50 CommentType: T Comment: there is a bit for 'Neighbor PNC', but not for 'Child PNC' CommentEnd: SuggestedRemedy: Add a bit for 'Child PNC', if required. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 316 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.4.3 Page: 104 Line: 17 CommentType: T Comment: The PNC Des-mode description is incorrect. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 44 CommenterName: Bain, Jay CommenterEmail: jay.bain@timedomain.com CommenterPhone: 256 428 6415 CommenterFax: 256 527 4778 CommenterCo: Time Domain Clause: 07 Subclause: 7.4.3 Page: 104 Line: 8 CommentType: T 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 CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 982 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.4.7 Page: 105 Line: 30 CommentType: T Comment: Addition to clause 4 CommentEnd: SuggestedRemedy: Add OID to the acronyms list RemedyEnd: Response: ResponseEnd: ----------- CommentID: 983 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.4.7 Page: 105 Line: 33 CommentType: TR Comment: Reference is made to IEEE P1363 CommentEnd: SuggestedRemedy: Clause 10 does not make reference to IEEE P1363 and it appears that it should. How does P1363 enter into the security algorithms? RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1673 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.4.7 Page: 105 Line: 3334 CommentType: T 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. CommentEnd: SuggestedRemedy: Recommend changing the sentence to "The OID field specifies a unique cipher suite." Comment via Ari Singer. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 815 CommenterName: Kleindl, Guenter CommenterEmail: guenter.kleindl@siemens.at CommenterPhone: 43 51707 35738 CommenterFax: CommenterCo: Siemens Clause: 07 Subclause: 7.4.8 Page: 105 Line: 44 CommentType: TR Comment: wrong length value CommentEnd: SuggestedRemedy: Length(=3) RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1486 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.4.8 Page: 106 Line: 6 CommentType: T Comment: Why is power at the antenna used, and not eirp? CommentEnd: SuggestedRemedy: change to eirp RemedyEnd: Response: ResponseEnd: ----------- CommentID: 816 CommenterName: Kleindl, Guenter CommenterEmail: guenter.kleindl@siemens.at CommenterPhone: 43 51707 35738 CommenterFax: CommenterCo: Siemens Clause: 07 Subclause: 7.4.9 Page: 106 Line: 10 CommentType: TR Comment: wrong sentence above figure 28 (correct description below figure 28) CommentEnd: SuggestedRemedy: Delete wrong sentence about TPC capabilities of a DEV. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 318 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.4.9 Page: 106 Line: 10 CommentType: T Comment: The description of piconet maximum transmit power is incorrect. CommentEnd: 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" RemedyEnd: Response: ResponseEnd: ----------- CommentID: 319 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.4.9 Page: 106 Line: 15 CommentType: T Comment: Delete reserved field, elements can be defined as odd lengths, the protocol automatically pads them to even numbers of octets. CommentEnd: SuggestedRemedy: Delete the field "Reserved" and change the length of the element to 1 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1487 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.4.9 Page: 106 Line: 23 CommentType: T Comment: Why would we limit transmit power and not eirp? CommentEnd: SuggestedRemedy: Change piconet maximum transmit power to limit eirp. Antennal gain PIB may be needed. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 853 CommenterName: Kleindl, Guenter CommenterEmail: guenter.kleindl@siemens.at CommenterPhone: 43 51707 35738 CommenterFax: CommenterCo: Siemens Clause: 07 Subclause: 7.4-7.5 Page: Line: CommentType: TR Comment: Each command has its own defined structure. This requires to store all the command structures. CommentEnd: 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'. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 295 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.5 Page: 110 Line: 17 CommentType: T Comment: Some of the commands have the settings specified for the MAC header fields, while other commands do not. CommentEnd: SuggestedRemedy: Add a sentence that says that the MAC header fields are set as appropriate unless otherwise specified. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 325 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.5 Page: 110 Line: 18 CommentType: T Comment: The restriction on transmitting command frames is too restrictive. It would not allow an unassociated DEV to associate. CommentEnd: 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." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1505 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5 Page: 111 Line: 33 CommentType: TR 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? CommentEnd: SuggestedRemedy: For the good of the protocol, only allow one command per command frame. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 326 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.5.1 Page: 111 Line: 47 CommentType: T 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. CommentEnd: 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" RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1506 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.1 Page: 111 Line: 50 CommentType: TR 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. CommentEnd: SuggestedRemedy: Change frag start and frag end to 1 for PNC selection and handover. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 328 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.5.1 Page: 112 Line: 11 CommentType: T Comment: Reserved fields are no longer used in the commands or information elements. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 327 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.5.1 Page: 112 Line: 2 CommentType: T Comment: Directed frames are no longer used in the PNC selection process. CommentEnd: 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). RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1507 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.1 Page: 112 Line: 25 CommentType: TR Comment: Tx power level should be PHY dependant. Some PHYs may be regulated as powerspectral density, not power. CommentEnd: SuggestedRemedy: Makd Tx Poweer level PHY dependant and move the description of this field to Clause 11. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1508 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.1 Page: 112 Line: 34 CommentType: T 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? CommentEnd: SuggestedRemedy: Explain how this change impacts the process. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 670 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 07 Subclause: 7.5.1.1 Page: 112 Line: 36 CommentType: TR Comment: Alternate PNC announcement command unneeded. CommentEnd: SuggestedRemedy: Please delete clause 7.5.1.1 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 671 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 07 Subclause: 7.5.1.2 Page: 112 Line: 42 CommentType: TR Comment: Alternate PNC pullout command unneeded given the change in Clause8.2.3 p139 line30-32. CommentEnd: SuggestedRemedy: Please delete this clause 7.5.1.2 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 329 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.5.1.2 Page: 112 Line: 42 CommentType: T Comment: The alternate PNC pullout command was deleted from the functional description a couple of revisions ago. This command is no longer used. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 738 CommenterName: Huang, Bob CommenterEmail: robert.huang@am.sony.com CommenterPhone: 201-358-4409 CommenterFax: CommenterCo: Sony Electronics Clause: 07 Subclause: 7.5.1.2 Page: 112 Line: 4247 CommentType: TR Comment: There was agreement by the meeting to remove this section. CommentEnd: SuggestedRemedy: Remove. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 330 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.5.1.3 Page: 112 Line: 48 CommentType: T 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. CommentEnd: 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." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 331 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.5.1.4 Page: 113 Line: 9 CommentType: T 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. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 725 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 07 Subclause: 7.5.10.1 Page: 130 Line: 21 CommentType: TR Comment: The Channel Time request command is inadequately defined for the functions required of it in this protocol. CommentEnd: SuggestedRemedy: The Channel Time request command clause in doc 02/037r0 provides detailed resolution to this issue. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 837 CommenterName: Kleindl, Guenter CommenterEmail: guenter.kleindl@siemens.at CommenterPhone: 43 51707 35738 CommenterFax: CommenterCo: Siemens Clause: 07 Subclause: 7.5.10.1 Page: 130 Line: 2333 CommentType: TR Comment: wrong length indicated CommentEnd: SuggestedRemedy: replace at the end of line 23: '9' by '12' correct in Figure 71: Length(n*12) RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1332 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.10.1 Page: 131 Line: CommentType: TR Comment: 2 fields had to be added to the CTREZB, plus 7 paragraphs to attempt to explain their usage. CommentEnd: SuggestedRemedy: This type of complexity in the name of powermangement is unwarranted. Revisit power management. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 2 CommenterName: Bain, Jay CommenterEmail: jay.bain@timedomain.com CommenterPhone: 256 428 6415 CommenterFax: 256 527 4778 CommenterCo: Time Domain Clause: 07 Subclause: 7.5.10.1 Page: 131 Line: 12 CommentType: TR 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. CommentEnd: SuggestedRemedy: Add - The PNC shall provide the switch to ACTIVE operation even if it is unable to return the full CTR allocation. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1122 CommenterName: Schrader, Mark CommenterEmail: mark.e.schrader@kodak.com CommenterPhone: 585-253-5241 CommenterFax: CommenterCo: Eastman Kodak Co. Clause: 07 Subclause: 7.5.10.1 Page: 131 Line: 12 CommentType: T 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. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 358 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.5.10.1 Page: 131 Line: 14 CommentType: T Comment: The frame format description contains a redundant (evil) functional description. CommentEnd: SuggestedRemedy: Delete the sentence "The PNC shal create and retain this EPS CTR based on this request." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 359 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.5.10.1 Page: 131 Line: 22 CommentType: T Comment: Need to add clarification for the stream index setting when this command is used to allocate a non-stream CTA. CommentEnd: 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." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1090 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.10.1 Page: 131 Line: 26 CommentType: T 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? CommentEnd: SuggestedRemedy: Have power management subcommittee clarify line 26. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1345 CommenterName: Schrader, Mark CommenterEmail: mark.e.schrader@kodak.com CommenterPhone: 585-253-5241 CommenterFax: CommenterCo: Eastman Kodak Co. Clause: 07 Subclause: 7.5.10.1 Page: 131 Line: 28 CommentType: T Comment: "A zero value is not allowed ... to be ignored by the recipient" is not correct. A requested edit did not make this draft. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1091 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.10.1 Page: 131 Line: 31 CommentType: T Comment: Restructure sentence assuming the technical comment is correct CommentEnd: 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") RemedyEnd: Response: ResponseEnd: ----------- CommentID: 48 CommenterName: Bain, Jay CommenterEmail: jay.bain@timedomain.com CommenterPhone: 256 428 6415 CommenterFax: 256 527 4778 CommenterCo: Time Domain Clause: 07 Subclause: 7.5.10.1 Page: 131 Line: 32 CommentType: T 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 CommentEnd: SuggestedRemedy: change to 8 us and 0 - 524280 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1333 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.10.1 Page: 131 Line: 41 CommentType: TR 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. CommentEnd: SuggestedRemedy: Remove maximum allocation delay variaion from the CTRB. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1088 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.10.1 Page: 131 Line: 8 CommentType: TR Comment: poor sentence structure. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1336 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.10.2 Page: 132 Line: CommentType: TR Comment: What is the CTA element set to if it is not the same in every superframe? CommentEnd: SuggestedRemedy: Need to define what the CTA is set to in the chanel time grant if it is not the same for every SF. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 360 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.5.10.2 Page: 132 Line: 17 CommentType: T Comment: Informal language defines the CTA elements. CommentEnd: SuggestedRemedy: Change "element is defined" to be "element shall be formatted as illustrated in Figure 30 and is defined" RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1347 CommenterName: Schrader, Mark CommenterEmail: mark.e.schrader@kodak.com CommenterPhone: 585-253-5241 CommenterFax: CommenterCo: Eastman Kodak Co. Clause: 07 Subclause: 7.5.10.2 Page: 132 Line: 30 CommentType: T Comment: Incorrect term used CommentEnd: SuggestedRemedy: Change: "...start time of next GTS" to ... superframe of next GTS. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 50 CommenterName: Bain, Jay CommenterEmail: jay.bain@timedomain.com CommenterPhone: 256 428 6415 CommenterFax: 256 527 4778 CommenterCo: Time Domain Clause: 07 Subclause: 7.5.10.2 Page: 132 Line: 31 CommentType: T 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. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1115 CommenterName: Schrader, Mark CommenterEmail: mark.e.schrader@kodak.com CommenterPhone: 585-253-5241 CommenterFax: CommenterCo: Eastman Kodak Co. Clause: 07 Subclause: 7.5.10.3 Page: Line: CommentType: T 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. CommentEnd: 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 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1096 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.10.3 Page: 132 Line: CommentType: T Comment: line 51 CommentEnd: SuggestedRemedy: replace the 4th word in line 51 (index) with the word "identifier" RemedyEnd: Response: ResponseEnd: ----------- CommentID: 726 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 07 Subclause: 7.5.10.3 Page: 132 Line: 36 CommentType: TR Comment: The Stream managment command is an inordinately complicated frame command for the functions it is needed in this draft. CommentEnd: SuggestedRemedy: Replace the Stream managment command with the upgraded Channel Time request command described in doc 02/037r0. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 839 CommenterName: Kleindl, Guenter CommenterEmail: guenter.kleindl@siemens.at CommenterPhone: 43 51707 35738 CommenterFax: CommenterCo: Siemens Clause: 07 Subclause: 7.5.10.3 Page: 132 Line: 4451 CommentType: TR Comment: some inconsistencies CommentEnd: 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) RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1533 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.10.3 Page: 132 Line: 45 CommentType: TR 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. CommentEnd: SuggestedRemedy: Have stream management command use the 48 bit address. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1116 CommenterName: Schrader, Mark CommenterEmail: mark.e.schrader@kodak.com CommenterPhone: 585-253-5241 CommenterFax: CommenterCo: Eastman Kodak Co. Clause: 07 Subclause: 7.5.10.3 Page: 132 Line: 51 CommentType: T Comment: stream request indes is the wrong term CommentEnd: SuggestedRemedy: change "stream request index" to stream request identifier RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1121 CommenterName: Schrader, Mark CommenterEmail: mark.e.schrader@kodak.com CommenterPhone: 585-253-5241 CommenterFax: CommenterCo: Eastman Kodak Co. Clause: 07 Subclause: 7.5.10.3 Page: 133 Line: 13 CommentType: T Comment: The Action Type field cannot encode 0-5 CommentEnd: SuggestedRemedy: Change to 3 bits, 0 - 2 in Figure 76 and change line 20 from "2-bit" to 3-bit RemedyEnd: Response: ResponseEnd: ----------- CommentID: 840 CommenterName: Kleindl, Guenter CommenterEmail: guenter.kleindl@siemens.at CommenterPhone: 43 51707 35738 CommenterFax: CommenterCo: Siemens Clause: 07 Subclause: 7.5.10.3 Page: 133 Line: 1420 CommentType: TR Comment: For Action Type more than 2 bits are required CommentEnd: SuggestedRemedy: change action type length to 3 bits RemedyEnd: Response: ResponseEnd: ----------- CommentID: 361 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.5.10.3 Page: 133 Line: 20 CommentType: T Comment: The action type requires a 3 bit field, not a 2 bit field. CommentEnd: SuggestedRemedy: Change the text from "a 2-bit" to "a 3-bit" and re-number the bits accordingly in figure 76 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 751 CommenterName: Huang, Bob CommenterEmail: robert.huang@am.sony.com CommenterPhone: 201-358-4409 CommenterFax: CommenterCo: Sony Electronics Clause: 07 Subclause: 7.5.10.3 Page: 133 Line: 20 CommentType: TR Comment: Text specifies a 2 bit field, yet there are 6 outcomes (6 values). CommentEnd: SuggestedRemedy: Expand action type. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1117 CommenterName: Schrader, Mark CommenterEmail: mark.e.schrader@kodak.com CommenterPhone: 585-253-5241 CommenterFax: CommenterCo: Eastman Kodak Co. Clause: 07 Subclause: 7.5.10.3 Page: 133 Line: 27 CommentType: T 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. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 362 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.5.10.3 Page: 133 Line: 38 CommentType: T Comment: Security is not defined on a stream by stream basis, but rather for the piconet as a whole. CommentEnd: SuggestedRemedy: Delete the security bits in the control information field and delete the sentence "The security field is a 3 bit field that . RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1097 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.10.3 Page: 133 Line: 38 CommentType: TR Comment: Line 38 contains a TBD CommentEnd: SuggestedRemedy: Resolve TBD ... security subcommittee RemedyEnd: Response: ResponseEnd: ----------- CommentID: 294 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.5.10.3 Page: 133 Line: 39 CommentType: T Comment: The security field is a 3-bit field that CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 75 CommenterName: Barr, John CommenterEmail: John.Barr@Motorola.com CommenterPhone: 847-576-8706 CommenterFax: 847-651-6822 CommenterCo: Motorola Clause: 07 Subclause: 7.5.10.3 Page: 133 Line: 39 CommentType: TR Comment: Security field not required. CommentEnd: SuggestedRemedy: Remove "The security field is a 2 bit field defined in 7.2.1.2. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1119 CommenterName: Schrader, Mark CommenterEmail: mark.e.schrader@kodak.com CommenterPhone: 585-253-5241 CommenterFax: CommenterCo: Eastman Kodak Co. Clause: 07 Subclause: 7.5.10.3 Page: 133 Line: 39 CommentType: T Comment: TBD present CommentEnd: SuggestedRemedy: must be removed or replaced with spec. I ask guidance from the security subcommittee members. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 52 CommenterName: Bain, Jay CommenterEmail: jay.bain@timedomain.com CommenterPhone: 256 428 6415 CommenterFax: 256 527 4778 CommenterCo: Time Domain Clause: 07 Subclause: 7.5.10.3 Page: 133 Line: 40 CommentType: T Comment: there is a TBD for the security field CommentEnd: SuggestedRemedy: define the TBD RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1118 CommenterName: Schrader, Mark CommenterEmail: mark.e.schrader@kodak.com CommenterPhone: 585-253-5241 CommenterFax: CommenterCo: Eastman Kodak Co. Clause: 07 Subclause: 7.5.10.3 Page: 134 Line: 48 CommentType: T Comment: "frequency" is the wrong term. CommentEnd: SuggestedRemedy: change "frequency" to period. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1341 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.10.3 Page: 134 Line: 52 CommentType: TR Comment: Setting the resolution of the channel time to 8 us will result in inefficient CTAs. This should be change to 1 us resolution. CommentEnd: SuggestedRemedy: Change CTA resolution to 1 us. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1342 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.10.3 Page: 135 Line: CommentType: TR Comment: All of these parameters have use K which is 1024. They should be small k, which according to the definitions is 1000. CommentEnd: SuggestedRemedy: Change K to k. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1099 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.10.3 Page: 135 Line: 18 CommentType: T Comment: In line 18 ... in the middle of the sentence is the word "over" ... would a better word be "after" CommentEnd: SuggestedRemedy: ... the time, in Kus, after which the retransmission ... Review by MAC people. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1510 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.2.1 Page: 113 Line: 41 CommentType: TR 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. CommentEnd: SuggestedRemedy: Change frag start and frag end to 1 for Association Request Command. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 332 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.5.2.1 Page: 113 Line: 43 CommentType: T 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) CommentEnd: 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." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1509 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.2.1 Page: 113 Line: 43 CommentType: TR Comment: Ignoring the header fields should be optional and not mandatory. Setting the bits should be mandatory, ignoring them on reception should be optional. CommentEnd: SuggestedRemedy: change to "may be ignored upon reception" This applies to all of the commands. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 333 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.5.2.1 Page: 114 Line: 19 CommentType: T 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. CommentEnd: SuggestedRemedy: Change "the DEV and expect the DEV to associate again." to be "the DEV." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1511 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.2.2 Page: 114 Line: 38 CommentType: TR 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. CommentEnd: SuggestedRemedy: Change frag start and frag end to 1 for Association Response Command. This applies to all commands. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 334 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.5.2.2 Page: 114 Line: 42 CommentType: T Comment: The ACK policy for the association response command is defined in three places and therefore is evil. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1512 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.2.2 Page: 115 Line: 10 CommentType: T Comment: Why is "DEV wishes to disassociate" a reason code? CommentEnd: SuggestedRemedy: Need to explain this. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 335 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.5.2.2 Page: 115 Line: 11 CommentType: T 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. CommentEnd: SuggestedRemedy: Change reason code 5 from "DEV wishes to disassociate" to "Neighbor piconet not allowed" RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1513 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.2.2 Page: 115 Line: 14 CommentType: TR Comment: Security required should be a reason code. CommentEnd: SuggestedRemedy: Add "security requered" as a reason code. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 820 CommenterName: Kleindl, Guenter CommenterEmail: guenter.kleindl@siemens.at CommenterPhone: 43 51707 35738 CommenterFax: CommenterCo: Siemens Clause: 07 Subclause: 7.5.2.2 Page: 115 Line: 6 CommentType: TR Comment: Add possibility for reject, without giving a detailed reason CommentEnd: SuggestedRemedy: add a reason code 'reject' RemedyEnd: Response: ResponseEnd: ----------- CommentID: 678 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 07 Subclause: 7.5.2.3 Page: 115 Line: 33 CommentType: T Comment: Text between lines 33 and 43 is not needed if the DeviceAddress, ReasonCode, and Reserved fields are deleted. CommentEnd: SuggestedRemedy: Please remove the indicated text. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 336 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.5.2.3 Page: 115 Line: 37 CommentType: T 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. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1514 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.2.3 Page: 115 Line: 37 CommentType: T Comment: What does "DEV state has expired" mean? Does this mean that ATP timeout? CommentEnd: SuggestedRemedy: Describe what this means. If this does not mean ATP, add ATP expired as a valid reason code. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 337 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.5.3 Page: 115 Line: 48 CommentType: T Comment: The definition of the role of the PNC as PSM redundant and is therefore an abomination to the technical editor. CommentEnd: SuggestedRemedy: Delete the two sentences "In all cases ...maager in a piconet." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1014 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.3 Page: 115 Line: 49 CommentType: T Comment: acronym PSM CommentEnd: SuggestedRemedy: add PSM to clause 4 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1015 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.3 Page: 115 Line: 49 CommentType: TR Comment: Piconet Security Manager CommentEnd: SuggestedRemedy: Add text to clause 10 the details of the Piconet Security Manager - security subcommittee. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1516 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.3.1 Page: 116 Line: 11 CommentType: TR 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. CommentEnd: SuggestedRemedy: Need to sensure max key object size is less than the max frame size or figure out how to fragement commands. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1515 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.3.1 Page: 116 Line: 11 CommentType: T Comment: Public Key Object Length and Length are redundant. CommentEnd: SuggestedRemedy: Delete Public Key Object Length. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 822 CommenterName: Kleindl, Guenter CommenterEmail: guenter.kleindl@siemens.at CommenterPhone: 43 51707 35738 CommenterFax: CommenterCo: Siemens Clause: 07 Subclause: 7.5.3.1 Page: 116 Line: 810 CommentType: TR Comment: Include the possibility for authentication of the PNC in the authentication request. CommentEnd: SuggestedRemedy: Include the 'Public Key Challenge' as optional information in the authentication request command. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1022 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.3.2 Page: 116 Line: 29 CommentType: TR Comment: in correct figure number CommentEnd: SuggestedRemedy: change figure 50 to figure 43 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 824 CommenterName: Kleindl, Guenter CommenterEmail: guenter.kleindl@siemens.at CommenterPhone: 43 51707 35738 CommenterFax: CommenterCo: Siemens Clause: 07 Subclause: 7.5.3.2 Page: 116 Line: 3235 CommentType: TR Comment: Include the possibility for authentication of the PNC. CommentEnd: SuggestedRemedy: Include the 'Public Key Proof' as conditional information in the authentication response command. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 338 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.5.3.2 Page: 116 Line: 35 CommentType: T Comment: Move the Authentication timeout field to be prior to AuthenticationInfo in the command format so that the variable field is last. CommentEnd: SuggestedRemedy: Change as indicated. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1518 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.3.2 Page: 116 Line: 38 CommentType: T Comment: AuthenticationInfoLength is redudant with Length CommentEnd: SuggestedRemedy: Delete AuthenticationInfoLength RemedyEnd: Response: ResponseEnd: ----------- CommentID: 339 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.5.3.3 Page: 117 Line: 10 CommentType: T Comment: Move the AuthenticateFailueTimeout to be the first field so that the variable length field is last in the command format. CommentEnd: SuggestedRemedy: Change as indicated in the figure. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1519 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.3.3 Page: 117 Line: 10 CommentType: T Comment: PublicKeyChallengeLength is redundant with Length CommentEnd: SuggestedRemedy: Delete PublicChallengeLength RemedyEnd: Response: ResponseEnd: ----------- CommentID: 79 CommenterName: Barr, John CommenterEmail: John.Barr@Motorola.com CommenterPhone: 847-576-8706 CommenterFax: 847-651-6822 CommenterCo: Motorola Clause: 07 Subclause: 7.5.3.3 Page: 117 Line: 2021 CommentType: TR 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. CommentEnd: SuggestedRemedy: Remove the last field (AuthenticationFailureTimeout) from Figure 44 on page 117. Remove lines 20-22 on page 117. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1023 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.3.3 Page: 117 Line: 5 CommentType: TR Comment: in correct figure number CommentEnd: SuggestedRemedy: should be figure 44 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1024 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.3.4 Page: 117 Line: 32 CommentType: TR Comment: in correct figure number CommentEnd: SuggestedRemedy: figure should be 45 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1520 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.3.4 Page: 117 Line: 37 CommentType: T Comment: PublicKeyProofLength is redundant with Length CommentEnd: SuggestedRemedy: Eliminate PublicKeyProofLength RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1030 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.3.5 Page: 118 Line: 1 CommentType: TR Comment: incorrect figure number CommentEnd: SuggestedRemedy: should be figure 46 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 829 CommenterName: Kleindl, Guenter CommenterEmail: guenter.kleindl@siemens.at CommenterPhone: 43 51707 35738 CommenterFax: CommenterCo: Siemens Clause: 07 Subclause: 7.5.3.5-7.5.3.7 Page: 118 Line: CommentType: TR Comment: could not find the details of the cipher suite list CommentEnd: SuggestedRemedy: clarify contents of cipher suit list RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1031 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.3.6 Page: 118 Line: 21 CommentType: TR Comment: incorrect figure number CommentEnd: SuggestedRemedy: should be figure 47 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1033 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.3.7 Page: 118 Line: 43 CommentType: TR Comment: Incomplete specification for usage of distribute key request CommentEnd: SuggestedRemedy: Clause 10 needs detail on usage and specs for distribute key request - security subcommittee. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1034 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.3.7 Page: 119 Line: 1 CommentType: TR Comment: incorrect figure number CommentEnd: SuggestedRemedy: should be figure 48 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 340 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.5.3.7 Page: 119 Line: 6 CommentType: T 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. CommentEnd: SuggestedRemedy: Change as indicated. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1037 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.3.8 Page: 119 Line: 23 CommentType: TR Comment: Deauthenticate Request Command Usage CommentEnd: SuggestedRemedy: Security subcommittee to provide details on Deauthenticate Request command in clause 10 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1299 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.3.8 Page: 119 Line: 24 CommentType: TR 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. CommentEnd: SuggestedRemedy: This command should be deleted unless someone can find a use for it. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1038 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.3.8 Page: 119 Line: 29 CommentType: TR Comment: wrong figure number CommentEnd: SuggestedRemedy: figure 49 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 830 CommenterName: Kleindl, Guenter CommenterEmail: guenter.kleindl@siemens.at CommenterPhone: 43 51707 35738 CommenterFax: CommenterCo: Siemens Clause: 07 Subclause: 7.5.3.8 Page: 119 Line: 34 CommentType: TR Comment: correct length value CommentEnd: SuggestedRemedy: Lengt(=0) RemedyEnd: Response: ResponseEnd: ----------- CommentID: 679 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 07 Subclause: 7.5.4.1 Page: 119 Line: 45 CommentType: T 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. CommentEnd: SuggestedRemedy: Please change the clause title to Device Information request command. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 680 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 07 Subclause: 7.5.4.1 Page: 119 Line: 46 CommentType: T Comment: Text between line 46 and 49 referencing the probe name command is incorrect. CommentEnd: SuggestedRemedy: Please replace all instances of probe request with device information request. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 341 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.5.4.1 Page: 119 Line: 49 CommentType: T 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. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1044 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.4.1 Page: 120 Line: CommentType: TR Comment: So how is the MSB of the information request filed mapped (ref. Figure 50)? Suggestion below. CommentEnd: SuggestedRemedy: 1=binary coded 0=bit map RemedyEnd: Response: ResponseEnd: ----------- CommentID: 681 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 07 Subclause: 7.5.4.1 Page: 120 Line: 1 CommentType: T Comment: Text between line 1 and 27 referencing the probe name command is incorrect. CommentEnd: SuggestedRemedy: Please replace all instances of probe request with device information request. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1301 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.4.1 Page: 120 Line: 27 CommentType: TR Comment: Why does the probe request command contain information elements? This is requesting IEs not sending them. CommentEnd: SuggestedRemedy: Remove Information Elements from the probe request command. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 342 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.5.4.2 Page: 120 Line: 26 CommentType: T Comment: Clarify what is the purpose of the information elements field. CommentEnd: 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." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 682 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 07 Subclause: 7.5.4.2 Page: 120 Line: 29 CommentType: T 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. CommentEnd: SuggestedRemedy: Please replace all instances of probe response with device information response. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 343 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.5.4.2 Page: 120 Line: 44 CommentType: T Comment: The information request field is not used in the probe response command. CommentEnd: SuggestedRemedy: Delete the field from figure 51 and the sentence referencng it on line 44. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1305 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.4.3 Page: 121 Line: 40 CommentType: T Comment: Specify that the frames received in error wer from the destination of this command. CommentEnd: 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." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1309 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.4.4 Page: 121 Line: CommentType: TR Comment: Channel status gives no more information to the transmitter than if acknowledgements are used. CommentEnd: SuggestedRemedy: Eliminate channel status request and response altogether an just use ACKs if you want to determine channel status. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1303 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.4.4 Page: 121 Line: 29 CommentType: T Comment: Max window sizeshould be an integer number of superframes, not ms. CommentEnd: SuggestedRemedy: Change max window size to be an integer number of superframes. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1049 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.4.4 Page: 121 Line: 37 CommentType: TR Comment: Question to PHY subcommittee about which directed frames should be counted. CommentEnd: SuggestedRemedy: Is it that we should only count frames from the probe response source? RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1304 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.4.4 Page: 121 Line: 37 CommentType: T Comment: Should specify that the frame counts was for frames feceived from the destination of the command. CommentEnd: SuggestedRemedy: Modify the sentence as follows "by the sender of this command from the destianation of this command." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1307 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.4.4 Page: 121 Line: 43 CommentType: T 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. CommentEnd: SuggestedRemedy: Redo this paragraph and remove inconsistencies so that we have a solid definition of what frame loss count means. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1306 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.4.4 Page: 121 Line: 44 CommentType: T 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? CommentEnd: SuggestedRemedy: Explain how it is determined gthat a frame was received correctly on its first attempt. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1308 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.4.4 Page: 121 Line: 49 CommentType: T 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. CommentEnd: 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." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1310 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.6.1 Page: 122 Line: CommentType: TR 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. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 344 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.5.6.1 Page: 122 Line: 33 CommentType: T 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. CommentEnd: 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." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1052 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.6.2 Page: 122 Line: CommentType: TR Comment: Symmetric Repeater Channel CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 345 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.5.6.2 Page: 123 Line: 1 CommentType: T Comment: The last sentence defines functional requirements that are already defined in clause 8. The redundant definition is therefore evil and shall be exorcised. CommentEnd: SuggestedRemedy: Move the sentence "If the DEV ... next becomes available" to clause 8.11 or delete the sentence. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 346 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.5.6.3 Page: 123 Line: 12 CommentType: T Comment: The AD-AD should be used instead of the destination device ID. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 708 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 07 Subclause: 7.5.7 Page: 123 Line: 37 CommentType: TR 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. CommentEnd: SuggestedRemedy: Please remove clauses 7.5.7 through 7.5.7.6. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1108 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.7.1 Page: 123 Line: 38 CommentType: TR 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? CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1169 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.7.1 Page: 123 Line: 41 CommentType: T Comment: Add reference to a clause for clarity CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 347 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.5.7.1 Page: 123 Line: 41 CommentType: T Comment: There is a redundant and therefore evil definition of functional requirements in this frame format section. CommentEnd: SuggestedRemedy: Delete the sentence "When and EPS set is .. for that EPS set." since this requirement is already in clause 8. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1313 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.7.1 Page: 124 Line: CommentType: TR Comment: How does a DEV know what EPS sets are out there and which to join? CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1314 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.7.1 Page: 124 Line: 19 CommentType: TR 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? CommentEnd: SuggestedRemedy: This needs to be fully clarified. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1316 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.7.1 Page: 124 Line: 25 CommentType: TR 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." CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1317 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.7.1 Page: 124 Line: 30 CommentType: TR 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? CommentEnd: SuggestedRemedy: The aauthors need to explain this. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1061 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.7.1 Page: 124 Line: 30 CommentType: T Comment: Rewrite sentence as shown below CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1060 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.7.1 Page: 124 Line: 31 CommentType: TR Comment: Reference to SME CommentEnd: SuggestedRemedy: Change to DME RemedyEnd: Response: ResponseEnd: ----------- CommentID: 348 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.5.7.2 Page: 124 Line: 37 CommentType: T Comment: Again, there is a redundant and evil inclusion of functional description in the frame formats clause. CommentEnd: SuggestedRemedy: Delete the sentence "When an EPS set is confirmed ... for that EPS set." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 349 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.5.7.3 Page: 124 Line: 49 CommentType: T 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. CommentEnd: SuggestedRemedy: Delete the two sentences. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1319 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.7.3 Page: 124 Line: 50 CommentType: TR 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. CommentEnd: SuggestedRemedy: Remove the reference to RPS mode. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 350 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.5.7.3 Page: 125 Line: 22 CommentType: T 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. CommentEnd: 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." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1171 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.7.3 Page: 125 Line: 23 CommentType: TR Comment: Add to the exisiting sentence ending at line 23 the following: CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1321 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.7.3 Page: 125 Line: 34 CommentType: TR Comment: Why is PowerManagementMode of 1 (rps) allowed but mode 0 (PM_Off) not allowed? What will RPS do with EPS actions? CommentEnd: SuggestedRemedy: Explain why an rps device would send an EPS action, but not a PM_OFF device. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1322 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.7.3 Page: 125 Line: 36 CommentType: TR Comment: Use of PowerManagementPriority to specify power sensitivity is open to abuse by manufacturers and should be eliminated. CommentEnd: SuggestedRemedy: remove PowerManagementPriority completely. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 31 CommenterName: Bain, Jay CommenterEmail: jay.bain@timedomain.com CommenterPhone: 256 428 6415 CommenterFax: 256 527 4778 CommenterCo: Time Domain Clause: 07 Subclause: 7.5.7.4 Page: 125 Line: 41 CommentType: T 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. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1066 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.7.4 Page: 126 Line: 2 CommentType: T Comment: reference to "self wake" CommentEnd: SuggestedRemedy: Power management committee needs to supply definition of what a "self wake" is ... I don't understand what is being implied here. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 351 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.5.7.5 Page: 126 Line: 16 CommentType: T Comment: The structure of the command is not stated in formal language (missed in the last update). CommentEnd: 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" RemedyEnd: Response: ResponseEnd: ----------- CommentID: 352 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.5.7.5 Page: 126 Line: 19 CommentType: T 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. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1349 CommenterName: Schrader, Mark CommenterEmail: mark.e.schrader@kodak.com CommenterPhone: 585-253-5241 CommenterFax: CommenterCo: Eastman Kodak Co. Clause: 07 Subclause: 7.5.7.5 Page: 126 Line: 20 CommentType: T 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. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1069 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.7.5 Page: 126 Line: 20 CommentType: T Comment: Clairfication of self sleep CommentEnd: SuggestedRemedy: Ask power management guys what self sleep is ... I don't understand. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 21 CommenterName: Bain, Jay CommenterEmail: jay.bain@timedomain.com CommenterPhone: 256 428 6415 CommenterFax: 256 527 4778 CommenterCo: Time Domain Clause: 07 Subclause: 7.5.7.6 Page: 126 Line: 32 CommentType: TR 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. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 353 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.5.7.6 Page: 126 Line: 34 CommentType: T Comment: The command format is specified in formal language (missed in the last round of updates). CommentEnd: SuggestedRemedy: Change "The structure ... as illustrated in Figure 61." to "The momentary EPS CTA command shall be formatted as illustrated in Figure 61." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1071 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.7.6 Page: 126 Line: 35 CommentType: TR Comment: The sentence says that the EPS CTR is contained within the EPS CTA. CommentEnd: SuggestedRemedy: The EPS CTR is NOT contained within the EPS CTA. Clarify what is intended here. (power management subcommittee) RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1072 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.7.6 Page: 126 Line: 36 CommentType: TR Comment: The sentence beginning with "If the wave beacon ..." is poorly written and I don't understand. CommentEnd: SuggestedRemedy: Please have power management subcommittee rewrite the sentence to clarify the text. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 683 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 07 Subclause: 7.5.8 Page: 126 Line: 48 CommentType: TR 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. CommentEnd: SuggestedRemedy: Please change this clause title to: PNC information. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 697 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 07 Subclause: 7.5.8 Page: 126 Line: 48 CommentType: TR 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. CommentEnd: SuggestedRemedy: See document 01469r3 for details regarding resolution to this comment. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 684 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 07 Subclause: 7.5.8 Page: 126 Line: 50 CommentType: TR Comment: The text between lines 50 and 51 is incorrect. CommentEnd: 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." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 685 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 07 Subclause: 7.5.8.1 Page: 127 Line: 1 CommentType: TR 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. CommentEnd: SuggestedRemedy: Please change the title of this clause to "Probe PNC request command" RemedyEnd: Response: ResponseEnd: ----------- CommentID: 687 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 07 Subclause: 7.5.8.1 Page: 127 Line: 14 CommentType: TR Comment: The text between lines 14 and 15 is incorrect. CommentEnd: SuggestedRemedy: Please change to: " The queried device AID is the DeviceAID of the DEV whose information is being requested from the PNC. ..." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 354 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.5.8.1 Page: 127 Line: 3 CommentType: T 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 CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 688 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 07 Subclause: 7.5.8.2 Page: 127 Line: 17 CommentType: TR Comment: The title of clause 7.5.8.2 Device information response command is incorrect. CommentEnd: SuggestedRemedy: Please change the title to PNC information response command. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 689 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 07 Subclause: 7.5.8.2 Page: 127 Line: 19 CommentType: TR Comment: The text between lines 19 and 22 is incorrect. CommentEnd: SuggestedRemedy: Please replace all instances of device information with PNC information . RemedyEnd: Response: ResponseEnd: ----------- CommentID: 355 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.5.8.2 Page: 127 Line: 22 CommentType: T 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. CommentEnd: 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." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1324 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.8.2 Page: 127 Line: 36 CommentType: TR Comment: It is not clear why a DEV would need to know the CTRBs for another DEV. CommentEnd: SuggestedRemedy: Remove all CTRBs from the device information response command records. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1076 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.8.2 Page: 127 Line: 49 CommentType: T Comment: Line 49 says, "The device ID is for the DEV whose allocations are given in the record". CommentEnd: SuggestedRemedy: How is broadcast mode supported? RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1077 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.8.2 Page: 127 Line: 53 CommentType: T Comment: Line 54 says, "The number of TX slots is the number of allocated transmission lsots for the DEV within each superframe". CommentEnd: SuggestedRemedy: what is done for the broadcast mode? RemedyEnd: Response: ResponseEnd: ----------- CommentID: 696 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 07 Subclause: 7.5.8.3 Page: 128 Line: 30 CommentType: TR Comment: Text between lines 30 and 39 is inconsistent with the text on page 131 between lines26 and 44. CommentEnd: SuggestedRemedy: Please make consistent. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1079 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.8.3 Page: 128 Line: 31 CommentType: T Comment: KuS seems too coarse CommentEnd: SuggestedRemedy: Suggest in Figure 66 we make the "duration between time slots" a 2 octet field which whould give a resolution of 4 uS. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 836 CommenterName: Kleindl, Guenter CommenterEmail: guenter.kleindl@siemens.at CommenterPhone: 43 51707 35738 CommenterFax: CommenterCo: Siemens Clause: 07 Subclause: 7.5.8.3 Page: 128 Line: 34 CommentType: TR Comment: 32ms is too long CommentEnd: SuggestedRemedy: replace '32ms' by '32us' RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1080 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.8.3 Page: 128 Line: 34 CommentType: TR Comment: resolution of 32 mS CommentEnd: SuggestedRemedy: Should this not be 32 uS? RemedyEnd: Response: ResponseEnd: ----------- CommentID: 356 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.5.8.3 Page: 128 Line: 4 CommentType: T 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. CommentEnd: 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". RemedyEnd: Response: ResponseEnd: ----------- CommentID: 693 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 07 Subclause: 7.5.8.3 Page: 128 Line: 6 CommentType: TR Comment: The sentence fragment "... the device information response command,..." is incorrect. CommentEnd: SuggestedRemedy: Please change the indicated fragment to: "... the PNC information response command,..." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1330 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: 7.5.9.1 Page: 129 Line: 32 CommentType: TR Comment: Sequence number provides no useful information. CommentEnd: SuggestedRemedy: Remove this sentence about end sequence number. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 357 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 07 Subclause: 7.5.9.1 Page: 129 Line: 38 CommentType: T Comment: Informal language defines the field settings. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1713 CommenterName: Young, Song-Lin CommenterEmail: syoung@sharplabs.com CommenterPhone: 360-817-7509 CommenterFax: CommenterCo: Sharp Labs. of America Clause: 07 Subclause: Fig. 74 Page: 132 Line: CommentType: TR Comment: SFNext field also used in CTA elemnet (Fig. 73 & 30), this is redundant. CommentEnd: SuggestedRemedy: Remove SFNext field RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1717 CommenterName: Young, Song-Lin CommenterEmail: syoung@sharplabs.com CommenterPhone: 360-817-7509 CommenterFax: CommenterCo: Sharp Labs. of America Clause: 07 Subclause: Fig.64 Page: 127 Line: CommentType: TR 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 CommentEnd: SuggestedRemedy: Remove CTRB and no. of TX slot or replace with something else RemedyEnd: Response: ResponseEnd: ----------- CommentID: 153 CommenterName: DuVal, Mary CommenterEmail: m-duval@ti.com CommenterPhone: 972-575-2330 CommenterFax: CommenterCo: Texas Instruments Clause: 07 Subclause: Figure 11 Page: 94 Line: 13 CommentType: T Comment: Where is the PHY preamble and PHY header in this figure? CommentEnd: SuggestedRemedy: RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1477 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 15 Page: 100 Line: 23 CommentType: T Comment: Don't really need two octets for command type. One is more than adequate. CommentEnd: SuggestedRemedy: Change command type to 1 octet. Update all relevant references to 2 octets. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 970 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 18 Page: 102 Line: CommentType: T Comment: Explicitly provide element ID CommentEnd: SuggestedRemedy: 0x00 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 702 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 07 Subclause: Figure 18 Page: 102 Line: 20 CommentType: TR Comment: Device ID field name is incorrect CommentEnd: SuggestedRemedy: Please change indicated field name to: Device Address and make the necessary change in parameter description following the figure. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 971 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 19 Page: 102 Line: CommentType: T Comment: Explicitly provide element ID CommentEnd: SuggestedRemedy: 0x01 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 978 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 21 Page: 103 Line: CommentType: T Comment: Provide explicit element ID CommentEnd: SuggestedRemedy: 0x02 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 975 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 23 Page: 104 Line: CommentType: T Comment: Provide explicit element ID CommentEnd: SuggestedRemedy: 0x03 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 976 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 24 Page: 104 Line: CommentType: T Comment: Provide explicit element ID CommentEnd: SuggestedRemedy: 0x04 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 979 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 25 Page: 105 Line: CommentType: T Comment: Provide element ID CommentEnd: SuggestedRemedy: 0x05 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 974 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 25 Page: 105 Line: CommentType: TR 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? CommentEnd: SuggestedRemedy: Suggest the 5 bits of table 94 represent the 5 LSBs and that the upper 3 bits of the octet be zeros. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 43 CommenterName: Bain, Jay CommenterEmail: jay.bain@timedomain.com CommenterPhone: 256 428 6415 CommenterFax: 256 527 4778 CommenterCo: Time Domain Clause: 07 Subclause: figure 25 Page: 105 Line: 1 CommentType: T 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. CommentEnd: SuggestedRemedy: change Figure 25 in clause 7.4.6 to allow up to 16 supported rates. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 981 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 26 Page: 105 Line: CommentType: T Comment: Provide explicit element ID CommentEnd: SuggestedRemedy: 0x06 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 984 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 27 Page: 105 Line: CommentType: T Comment: Provide explicit element ID CommentEnd: SuggestedRemedy: 0x07 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 986 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 28 Page: 106 Line: CommentType: T Comment: Provide explicit element ID CommentEnd: SuggestedRemedy: 0x09 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 987 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 29 Page: 106 Line: CommentType: T Comment: Provide explicit element ID CommentEnd: SuggestedRemedy: 0x0A RemedyEnd: Response: ResponseEnd: ----------- CommentID: 988 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 30 Page: 106 Line: CommentType: T 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 CommentEnd: SuggestedRemedy: As shown above RemedyEnd: Response: ResponseEnd: ----------- CommentID: 164 CommenterName: DuVal, Mary CommenterEmail: m-duval@ti.com CommenterPhone: 972-575-2330 CommenterFax: CommenterCo: Texas Instruments Clause: 07 Subclause: Figure 30 Page: 106 Line: 46 CommentType: T 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? CommentEnd: SuggestedRemedy: Need more information. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 699 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 07 Subclause: Figure 30 Page: 106 Line: 47 CommentType: TR Comment: Figure 30 is missing a slot duration field. CommentEnd: SuggestedRemedy: Please add the slot duration field to figure 30. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 698 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 07 Subclause: Figure 30 Page: 106 Line: 47 CommentType: T Comment: The Source DEV address and Destination DEV Address fields are incorrectly named and inconsistently located in the figure. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 993 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 32 Page: 108 Line: CommentType: TR Comment: Modifications to Figure 32 as shown below CommentEnd: SuggestedRemedy: element ID = 0x0B use full name "MACPIBMaxAssignedCTAs" use full name "MACPIBMaxProcessedCTAs" RemedyEnd: Response: ResponseEnd: ----------- CommentID: 995 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 33 Page: 108 Line: CommentType: T Comment: Provide explicit element ID CommentEnd: SuggestedRemedy: 0x0C RemedyEnd: Response: ResponseEnd: ----------- CommentID: 996 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 34 Page: 109 Line: CommentType: T Comment: Provide explicit ID CommentEnd: SuggestedRemedy: 0x0D RemedyEnd: Response: ResponseEnd: ----------- CommentID: 998 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 36 Page: 109 Line: CommentType: T Comment: Explicit element ID CommentEnd: SuggestedRemedy: 0x0E RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1002 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 37 Page: 112 Line: CommentType: T Comment: Provide explicit commands types CommentEnd: SuggestedRemedy: 0x000B "Alternate PNC announcement command" 0x000C "Alternate PNC pullout command" 0x000D "PNC handover command" RemedyEnd: Response: ResponseEnd: ----------- CommentID: 669 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 07 Subclause: Figure 37 Page: 112 Line: 12 CommentType: T Comment: DeviceID parameter name is incorrect. CommentEnd: SuggestedRemedy: Please change to DeviceAddress. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1004 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 38 Page: 113 Line: CommentType: T Comment: provide explicit command type CommentEnd: SuggestedRemedy: 0x000E RemedyEnd: Response: ResponseEnd: ----------- CommentID: 673 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 07 Subclause: Figure 38 Page: 113 Line: 15 CommentType: T Comment: PNC-device-id and AC-device-id parm names are incorrect. CommentEnd: 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 . RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1006 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 39 Page: 114 Line: CommentType: T Comment: Provide explicit command type CommentEnd: SuggestedRemedy: 0x0012 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 674 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 07 Subclause: Figure 39 Page: 114 Line: 6 CommentType: T Comment: DeviceID parm name is incorrect. CommentEnd: SuggestedRemedy: Please change to DeviceAddress and its related text describing the parm. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1010 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 40 Page: 114 Line: CommentType: T Comment: explicit command type CommentEnd: SuggestedRemedy: 0x0013 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1517 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: FIgure 40 Page: 114 Line: 30 CommentType: TR 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. CommentEnd: SuggestedRemedy: Add security parameters IE into the association response command. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 675 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 07 Subclause: Figure 40 Page: 114 Line: 30 CommentType: T Comment: Device ID and AD-AD parm names are incorrect. CommentEnd: SuggestedRemedy: Please change to DeviceAddress and DeviceAID. Also make the necessary text changes in the text describing the parms in this figure. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 676 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 07 Subclause: Figure 40 Page: 114 Line: 30 CommentType: T Comment: DeviceAID ( aka AD-AD) is mislocated in the figure. CommentEnd: SuggestedRemedy: Please move DeviceAID to the ReasonCode location in the table and the ReasonCode to the former DeviceAID table location. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1012 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 41 Page: 115 Line: CommentType: T Comment: provide explicit command type CommentEnd: SuggestedRemedy: 0x0014 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 677 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 07 Subclause: Figure 41 Page: 115 Line: 28 CommentType: T Comment: The DeviceID, ReasonCode, and Reserved fields of the Disassociation request command are unnecessary. CommentEnd: SuggestedRemedy: Please remove the indicated fields. Also set the Length parm = 0. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1016 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 42 Page: 116 Line: CommentType: T Comment: Do folllowing to Figure 42 CommentEnd: SuggestedRemedy: 1. explicit command type = 0x001C RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1017 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 42 Page: 116 Line: CommentType: TR Comment: DEVPublicKeyObject CommentEnd: SuggestedRemedy: In clause 10, provide technical details for the DEVPublicKeyObject RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1018 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 43 Page: 116 Line: CommentType: T Comment: provide explicit command type CommentEnd: SuggestedRemedy: 0x001D RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1019 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 43 Page: 116 Line: CommentType: TR Comment: AuthenticationInfo CommentEnd: SuggestedRemedy: In clause 10, please provide details of the AuthenticationInfo - security subcommittee. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1021 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 44 Page: 117 Line: CommentType: TR Comment: technical detail CommentEnd: SuggestedRemedy: security subcommittee to provide detail of PublicKeyChallenge RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1020 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 44 Page: 117 Line: CommentType: T Comment: provide explicit command type CommentEnd: SuggestedRemedy: 0x001E RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1026 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 45 Page: 117 Line: CommentType: TR Comment: PublicKeyProof CommentEnd: SuggestedRemedy: Security subcommittee needs to provide technical detail in clause 10 on the PublicKeyProof RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1025 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 45 Page: 117 Line: CommentType: T Comment: see below CommentEnd: SuggestedRemedy: provide explicit command type = 0x001F RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1028 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 46 Page: 118 Line: CommentType: TR Comment: KeyPurpose CommentEnd: SuggestedRemedy: Security subcommittee to provide technical detail in clause 10 about the KeyPurpose RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1027 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 46 Page: 118 Line: CommentType: T Comment: provide explicit command type CommentEnd: SuggestedRemedy: 0x0020 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1032 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: figure 47 Page: 118 Line: CommentType: TR Comment: incomplete specification on EncryptedKeyObject CommentEnd: SuggestedRemedy: Security subcommittee to provide detailed text in clause 10 about the EncryptedKeyObject RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1029 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 47 Page: 118 Line: CommentType: T Comment: explicit command type CommentEnd: SuggestedRemedy: 0x0021 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1831 CommenterName: Rasor, Gregg CommenterEmail: Gregg.Rasor@motorola.com CommenterPhone: (561) 739-2952 CommenterFax: CommenterCo: Motorola Clause: 07 Subclause: Figure 48 Page: 119 Line: CommentType: TR Comment: In Figure 48 (Distribute Key Format), the DistributeKeyTimeout parameter is included. I don't think it should be passed in the frames, just used in the MAC to timeout a pending command that may not come back within the allotted time. I don't see any reason why the other MAC could make any use of this value since it the entity which is producing the result. CommentEnd: SuggestedRemedy: Remove the timeout parameter from the frame. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1035 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: figure 48 Page: 119 Line: CommentType: T Comment: provide explicit command type CommentEnd: SuggestedRemedy: 0x0022 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1036 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: figure 48 Page: 119 Line: CommentType: TR Comment: lack of detail on usage CommentEnd: SuggestedRemedy: security subcommittee needs to provide details on DistributeKeyFailureTimeout in clause 10 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1039 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 49 Page: 119 Line: CommentType: TR Comment: Incomplete command? CommentEnd: 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? RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1040 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: figure 49 Page: 119 Line: CommentType: T Comment: provide explicit command type CommentEnd: SuggestedRemedy: 0x0023 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1041 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 50 Page: 120 Line: CommentType: T Comment: provide explicit command type CommentEnd: SuggestedRemedy: 0x0004 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1042 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 50 Page: 120 Line: CommentType: T Comment: No margin on information request CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1045 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 51 Page: 120 Line: CommentType: T Comment: provide explicit command type CommentEnd: SuggestedRemedy: 0x0005 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1047 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 52 Page: 121 Line: CommentType: T Comment: explicit command type CommentEnd: SuggestedRemedy: 0x0009 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1302 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 52 Page: 121 Line: 7 CommentType: TR Comment: The Channel Status request command should specify a window size, not leave it up to the responer CommentEnd: SuggestedRemedy: Add channel status request window field and the appropriate descriptive text. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1048 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 53 Page: 121 Line: CommentType: T Comment: explicit command type CommentEnd: SuggestedRemedy: 0x000A RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1050 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 54 Page: 122 Line: CommentType: T Comment: explicit element ID type CommentEnd: 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? RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1051 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 55 Page: 122 Line: CommentType: T Comment: Explicit command types CommentEnd: SuggestedRemedy: 0x0006 = Repeater service request command 0x0007 = Repeater service grant command RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1053 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 56 Page: 123 Line: CommentType: T Comment: Write in the command type CommentEnd: SuggestedRemedy: 0x0008 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1055 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 57 Page: 123 Line: CommentType: T Comment: Provide the command type number CommentEnd: SuggestedRemedy: 0x0015 = EPS action request 0x0016 = EPS action response RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1064 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 58 Page: 125 Line: CommentType: T Comment: provide command type CommentEnd: SuggestedRemedy: 0x0017 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1172 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 58 Page: 125 Line: CommentType: TR Comment: Question for Power Management folks CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1067 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 59 Page: 126 Line: CommentType: T Comment: provide command number CommentEnd: SuggestedRemedy: 0x0018 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1070 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 60 Page: 126 Line: CommentType: T Comment: use command type number CommentEnd: SuggestedRemedy: 0x0019 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1073 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 61 Page: 126 Line: CommentType: T Comment: provide command type number CommentEnd: SuggestedRemedy: 0x001A RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1074 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 62 Page: 127 Line: CommentType: T Comment: use command number CommentEnd: SuggestedRemedy: 0x000F RemedyEnd: Response: ResponseEnd: ----------- CommentID: 686 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 07 Subclause: Figure 62 Page: 127 Line: 9 CommentType: T Comment: The Queried Device ID field is incorrectly named and reserves to many octets. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1075 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 63 Page: 127 Line: CommentType: T Comment: Use command number CommentEnd: SuggestedRemedy: 0x0010 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 690 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 07 Subclause: Figure 63 Page: 127 Line: 31 CommentType: TR Comment: The caption for figure 63 is incorrect. CommentEnd: SuggestedRemedy: Please change to PNC information response command format. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 691 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 07 Subclause: Figure 64 Page: 127 Line: 38 CommentType: TR Comment: The AD-AD and Device ID fields are incorrectly named CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1078 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 65 Page: 128 Line: CommentType: T Comment: Use command number CommentEnd: SuggestedRemedy: 0x001B RemedyEnd: Response: ResponseEnd: ----------- CommentID: 694 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 07 Subclause: Figure 66 Page: 128 Line: 23 CommentType: T Comment: The Neighbor PNC Device ID field name is incorrect. CommentEnd: SuggestedRemedy: Please change the indicated field to: PNC DeviceAddress RemedyEnd: Response: ResponseEnd: ----------- CommentID: 695 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 07 Subclause: Figure 66 Page: 128 Line: 23 CommentType: TR 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. CommentEnd: SuggestedRemedy: Please make consistent. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1081 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 67 Page: 129 Line: CommentType: T Comment: List actual command number CommentEnd: SuggestedRemedy: 0x0000 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1083 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 69 Page: 129 Line: CommentType: T Comment: provide explicit command type CommentEnd: SuggestedRemedy: 0x0001 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1087 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 71 Page: 130 Line: CommentType: T Comment: give command number CommentEnd: SuggestedRemedy: 0x0002 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1092 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 73 Page: 132 Line: CommentType: T Comment: Use command number CommentEnd: SuggestedRemedy: 0x0003 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1334 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 73 Page: 132 Line: 8 CommentType: TR 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. CommentEnd: SuggestedRemedy: Remove grant status from the channel time grant. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1093 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 75 Page: 132 Line: CommentType: T Comment: Use command number CommentEnd: SuggestedRemedy: 0x0011 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1094 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 75 Page: 132 Line: CommentType: TR Comment: Width of Stream QoS parameters CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 76 CommenterName: Barr, John CommenterEmail: John.Barr@Motorola.com CommenterPhone: 847-576-8706 CommenterFax: 847-651-6822 CommenterCo: Motorola Clause: 07 Subclause: Figure 76 Page: 133 Line: 15 CommentType: TR Comment: Security field is not required. CommentEnd: SuggestedRemedy: Remove Security field from the control information field and shift other fields left increasing size of reserved field by 2 bits. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1340 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 77 Page: 134 Line: CommentType: TR 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 CommentEnd: SuggestedRemedy: Remove all of the stream parameters and only request channel time. This will greatly simplify the protocol. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1098 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure 77 Page: 134 Line: CommentType: TR Comment: Figure 77 lists the QoS parameters but it doesn't implicitly show which order the parameters are sent. CommentEnd: SuggestedRemedy: Add a figure that shows how to put the QoS VECTOR together and where are the MSBs. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 170 CommenterName: DuVal, Mary CommenterEmail: m-duval@ti.com CommenterPhone: 972-575-2330 CommenterFax: CommenterCo: Texas Instruments Clause: 07 Subclause: Figure 77 Page: 134 Line: 36 CommentType: T Comment: What does "ReTX" mean? It also appears on page 135, line 18. CommentEnd: SuggestedRemedy: Need a definition to understand. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 174 CommenterName: DuVal, Mary CommenterEmail: m-duval@ti.com CommenterPhone: 972-575-2330 CommenterFax: CommenterCo: Texas Instruments Clause: 07 Subclause: Figure 78 Page: 139 Line: CommentType: T 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. CommentEnd: SuggestedRemedy: See above. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1488 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure30 Page: 106 Line: 45 CommentType: TR Comment: Add Duration field back into the CTA. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1490 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure31 Page: 107 Line: 15 CommentType: TR 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. CommentEnd: SuggestedRemedy: Remove the Key change bit from the CTA control boock, and remove line 36 on page 107 about the key change bit. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1329 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure67 Page: 129 Line: 9 CommentType: TR Comment: The figure says Record for stream 1, 2, ...n, but you could have multiple records for the same stream. CommentEnd: SuggestedRemedy: Add text that says that that there could be multiple records for the same stream. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1328 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Figure68 Page: 129 Line: 18 CommentType: TR Comment: Why is End sequence number needed? The start sequence number and the RxStatus bitmap is all that is needed. CommentEnd: SuggestedRemedy: Remove the End Sequence number. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1474 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Table 60 Page: 98 Line: CommentType: TR Comment: Need to add DEV GTS Status ie in table 60. This appears in every beacon. CommentEnd: SuggestedRemedy: Add DEV GTS status to table 60. It appears in every beacon. It is described in 7.4.12 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1475 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Table 61 Page: 99 Line: 9 CommentType: TR 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. CommentEnd: SuggestedRemedy: Change frag-start and frag-end to 1 in the beacon in table 61 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1476 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Table 62 Page: 99 Line: 36 CommentType: TR 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. CommentEnd: SuggestedRemedy: Change frag-start and frag-end bits to "1" in the immediate ACK. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 700 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 07 Subclause: Table 63 Page: 101 Line: 10 CommentType: TR Comment: Missing from the Information elements table are these new information elements: PicoNet Shutdown and New Associated DEV CommentEnd: 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) RemedyEnd: Response: ResponseEnd: ----------- CommentID: 701 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 07 Subclause: Table 63 Page: 101 Line: 14 CommentType: TR Comment: The Device Identifier info element is misnamed. CommentEnd: SuggestedRemedy: Please change to Device Address info element RemedyEnd: Response: ResponseEnd: ----------- CommentID: 999 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Table 65 Page: 110 Line: CommentType: T Comment: Why do we need 16 bit commands? CommentEnd: SuggestedRemedy: MAC subcommittee needs to justify 16 bit commands ... prefer to replace with 8 bit commands RemedyEnd: Response: ResponseEnd: ----------- CommentID: 703 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 07 Subclause: Table 65 Page: 110 Line: 31 CommentType: TR Comment: Probe Request command and Probe response commands are incorrect. Also the xref in the table are incorrect. CommentEnd: SuggestedRemedy: Please Rename the indicated commands to Probe-PNC-Request command and Probe-PNC-Response command. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 704 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 07 Subclause: Table 65 Page: 110 Line: 42 CommentType: TR Comment: Alternate PNC announcement command and Alternate PNC pull out command are not needed. CommentEnd: SuggestedRemedy: Please remove the indicated commands and their xrefs. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 705 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 07 Subclause: Table 65 Page: 110 Line: 42 CommentType: TR 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. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 706 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 07 Subclause: Table 65 Page: 110 Line: 48 CommentType: TR Comment: The xrefs for the Device information request and response commands is incorrect. CommentEnd: SuggestedRemedy: Please have the xref point to the clause previously known as Probe request and response respectively. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 707 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 07 Subclause: Table 65 Page: 111 Line: 7 CommentType: TR Comment: The power managment frame commands introduce an inordinate amount of complexity into D09. Consequently, they are not needed. CommentEnd: SuggestedRemedy: Remove from this table all references to EPS action request/response, Swith to Active, Switch to EPS, Momentary EPS RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1504 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Table 65 Page: 111 Line: 8 CommentType: TR Comment: 6 commands were added just for power management. Something is wrong when so many new commands are needed just for power management. CommentEnd: SuggestedRemedy: Simplify power management. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1056 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Table 66 Page: 124 Line: CommentType: T Comment: Better terminology CommentEnd: SuggestedRemedy: Instead of saying "place in set" how about instead "add to set". Make a universal replacement. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1170 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Table 67 Page: 125 Line: CommentType: TR Comment: Add a 9th action type value CommentEnd: SuggestedRemedy: In table 67, add 9th action type value ... Power Saving Modes Not Supported ... 9 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1494 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Table64 Page: 108 Line: 10 CommentType: TR 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. CommentEnd: SuggestedRemedy: Another reason to add the duration field back into the CTA. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1312 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 07 Subclause: Table66 Page: 124 Line: CommentType: TR 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. CommentEnd: SuggestedRemedy: Need to describe what each of these action types do and when they are used. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1640 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 08 Subclause: Page: Line: CommentType: TR 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? CommentEnd: SuggestedRemedy: If this can happen, we need a command to tell the upper layers "Channel tiem not currently available." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1656 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 08 Subclause: Page: Line: CommentType: T Comment: Can any DEV that is not a member of an EPS set make a request for active channel time with an EPS DEV? CommentEnd: SuggestedRemedy: Please clarify RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1542 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 08 Subclause: Page: Line: CommentType: TR 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. CommentEnd: SuggestedRemedy: Add Guard Time Text from 01/439 after I update it to add slot durations back into the channel time request. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1651 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 08 Subclause: Page: Line: CommentType: TR 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. CommentEnd: SuggestedRemedy: Need a command and MLME to request which EPS sets are active (in use). RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1724 CommenterName: Rofheart, Martin CommenterEmail: Martin@xtremespectrum.com CommenterPhone: 703-269-3007 CommenterFax: 240-463-3306 CommenterCo: XtremeSpectrum Clause: 08 Subclause: Page: Line: CommentType: TR Comment: The power management method is overly complex and vague. CommentEnd: SuggestedRemedy: Refer to the remedy indicated by Bill Shvodian RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1657 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 08 Subclause: Page: Line: CommentType: TR 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. CommentEnd: SuggestedRemedy: Address what happens when all EPS Wake beacons happen together. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1639 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 08 Subclause: Page: Line: CommentType: TR 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? CommentEnd: SuggestedRemedy: Need to add text to explain how a new EPS DEV finds the higher layer entity that it wishes to communicate with. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1594 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 08 Subclause: Page: Line: CommentType: TR 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? CommentEnd: SuggestedRemedy: Clarify what is meant by this paragraph. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1653 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 08 Subclause: Page: Line: CommentType: T Comment: Need to clearly explain the relationship between The EPS CTRB parameters of slot size and N, and the EPS set time of EPSTime. CommentEnd: SuggestedRemedy: Please clarify the relationship. A picture would be helpful. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 540 CommenterName: GUBBI, RAJUGOPAL CommenterEmail: rgubbi@broadcom.com CommenterPhone: 408-543-3470 CommenterFax: CommenterCo: Broadcom, corp Clause: 08 Subclause: 13.1.1 Page: 163 Line: 2630 CommentType: TR 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? CommentEnd: 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" RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1710 CommenterName: Young, Song-Lin CommenterEmail: syoung@sharplabs.com CommenterPhone: 360-817-7509 CommenterFax: CommenterCo: Sharp Labs. of America Clause: 08 Subclause: 13.2 Page: 163 Line: CommentType: TR Comment: RPS mode appears to be an implementation issue. It doesn't require commands exchange with PNC. CommentEnd: SuggestedRemedy: Remove this mode in draft RemedyEnd: Response: ResponseEnd: ----------- CommentID: 541 CommenterName: GUBBI, RAJUGOPAL CommenterEmail: rgubbi@broadcom.com CommenterPhone: 408-543-3470 CommenterFax: CommenterCo: Broadcom, corp Clause: 08 Subclause: 13.2 Page: 163 Line: CommentType: TR Comment: some more inconsistencies that can potentially lead to non-interoperable implementations CommentEnd: 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" RemedyEnd: Response: ResponseEnd: ----------- CommentID: 543 CommenterName: GUBBI, RAJUGOPAL CommenterEmail: rgubbi@broadcom.com CommenterPhone: 408-543-3470 CommenterFax: CommenterCo: Broadcom, corp Clause: 08 Subclause: 13.3 Page: Line: CommentType: TR 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. CommentEnd: 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 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 544 CommenterName: GUBBI, RAJUGOPAL CommenterEmail: rgubbi@broadcom.com CommenterPhone: 408-543-3470 CommenterFax: CommenterCo: Broadcom, corp Clause: 08 Subclause: 16 Page: Line: CommentType: TR Comment: Table 73 has some "ms". please make them Kus for ease of implementation CommentEnd: SuggestedRemedy: Table 73 has some "ms". please make them Kus for ease of implementation RemedyEnd: 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. ResponseEnd: ----------- CommentID: 800 CommenterName: Kinney, Patrick CommenterEmail: pat.kinney@ieee.org CommenterPhone: 724-425-7952 CommenterFax: CommenterCo: Invensys Clause: 08 Subclause: 2 Page: 137 Line: CommentType: T 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 CommentEnd: SuggestedRemedy: describe the techniques to detect network id duplication and the procedures to resolve it. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 176 CommenterName: DuVal, Mary CommenterEmail: m-duval@ti.com CommenterPhone: 972-575-2330 CommenterFax: CommenterCo: Texas Instruments Clause: 08 Subclause: 2.4 Page: 141 Line: 2 CommentType: T 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. CommentEnd: SuggestedRemedy: Provide new figure. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 531 CommenterName: GUBBI, RAJUGOPAL CommenterEmail: rgubbi@broadcom.com CommenterPhone: 408-543-3470 CommenterFax: CommenterCo: Broadcom, corp Clause: 08 Subclause: 2.5 Page: Line: CommentType: TR Comment: the restriction for forming child piconet is not clear, although it might have been the intent. CommentEnd: SuggestedRemedy: Add "Only an AC that is associated to a PNC in an existing piconet shall form a child piconet" RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1705 CommenterName: Young, Song-Lin CommenterEmail: syoung@sharplabs.com CommenterPhone: 360-817-7509 CommenterFax: CommenterCo: Sharp Labs. of America Clause: 08 Subclause: 2.5 Page: 141 Line: 22 CommentType: TR 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? CommentEnd: SuggestedRemedy: Clarify the meaning of "private GTS" and usage of channel time request command for child piconet RemedyEnd: Response: ResponseEnd: ----------- CommentID: 532 CommenterName: GUBBI, RAJUGOPAL CommenterEmail: rgubbi@broadcom.com CommenterPhone: 408-543-3470 CommenterFax: CommenterCo: Broadcom, corp Clause: 08 Subclause: 2.6 Page: Line: CommentType: TR Comment: the restriction on transactions with neighboring piconet is not clear, although it might have been the intent. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 180 CommenterName: DuVal, Mary CommenterEmail: m-duval@ti.com CommenterPhone: 972-575-2330 CommenterFax: CommenterCo: Texas Instruments Clause: 08 Subclause: 2.6 Page: 142 Line: CommentType: TR Comment: Need to add a figure similar to Figure 80 to describe a neighbor piconet. What is different? Why are they not the same? CommentEnd: SuggestedRemedy: Clarification needed on neighbor piconets. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 178 CommenterName: DuVal, Mary CommenterEmail: m-duval@ti.com CommenterPhone: 972-575-2330 CommenterFax: CommenterCo: Texas Instruments Clause: 08 Subclause: 2.6 Page: 142 Line: 28 CommentType: TR 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. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1704 CommenterName: Young, Song-Lin CommenterEmail: syoung@sharplabs.com CommenterPhone: 360-817-7509 CommenterFax: CommenterCo: Sharp Labs. of America Clause: 08 Subclause: 2.6 Page: 142 Line: 28 CommentType: TR 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? CommentEnd: SuggestedRemedy: Remove 8.2.6 neighbor piconet and all related materials in the draft standard. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 179 CommenterName: DuVal, Mary CommenterEmail: m-duval@ti.com CommenterPhone: 972-575-2330 CommenterFax: CommenterCo: Texas Instruments Clause: 08 Subclause: 2.6 Page: 142 Line: 31 CommentType: TR 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? CommentEnd: SuggestedRemedy: This does not present a clear understanding of a neighbor piconet. Clarification needed. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 182 CommenterName: DuVal, Mary CommenterEmail: m-duval@ti.com CommenterPhone: 972-575-2330 CommenterFax: CommenterCo: Texas Instruments Clause: 08 Subclause: 2.6 Page: 143 Line: 30 CommentType: T Comment: "... it is neither authenticated nor associated) ..." - but figure 82 shows an association sequence. CommentEnd: SuggestedRemedy: If diagram is not wrong, paragraph is wrong. Make the two consistent. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 183 CommenterName: DuVal, Mary CommenterEmail: m-duval@ti.com CommenterPhone: 972-575-2330 CommenterFax: CommenterCo: Texas Instruments Clause: 08 Subclause: 3.2 Page: 144 Line: 17 CommentType: T Comment: You define what an associated response is not ... "directed frame". So what is an associated response? A broadcast frame? CommentEnd: SuggestedRemedy: Please clarify RemedyEnd: Response: ResponseEnd: ----------- CommentID: 534 CommenterName: GUBBI, RAJUGOPAL CommenterEmail: rgubbi@broadcom.com CommenterPhone: 408-543-3470 CommenterFax: CommenterCo: Broadcom, corp Clause: 08 Subclause: 4.1 Page: Line: CommentType: TR Comment: Clearly state the relation between SIFS and RIFS CommentEnd: SuggestedRemedy: change "SIFS < RIFS" to "RIFS = SIFS + aBackoffSlot" change "actual values of IFSs are" to "actual value of aBackoffSlot is" RemedyEnd: Response: ResponseEnd: ----------- CommentID: 535 CommenterName: GUBBI, RAJUGOPAL CommenterEmail: rgubbi@broadcom.com CommenterPhone: 408-543-3470 CommenterFax: CommenterCo: Broadcom, corp Clause: 08 Subclause: 4.2 Page: Line: CommentType: TR Comment: Backoff or IFS for beacon transmission is not clear. Either Beacon tx should be after a small backoff or reasonably long IFS. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 536 CommenterName: GUBBI, RAJUGOPAL CommenterEmail: rgubbi@broadcom.com CommenterPhone: 408-543-3470 CommenterFax: CommenterCo: Broadcom, corp Clause: 08 Subclause: 4.3.3 Page: 151 Line: 822 CommentType: TR 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 CommentEnd: SuggestedRemedy: Remove lines 8:22 on page 151 and all references to "MTS/GTS with BC/MC-SA" from the draft RemedyEnd: Response: ResponseEnd: ----------- CommentID: 537 CommenterName: GUBBI, RAJUGOPAL CommenterEmail: rgubbi@broadcom.com CommenterPhone: 408-543-3470 CommenterFax: CommenterCo: Broadcom, corp Clause: 08 Subclause: 4.3.4 Page: 151 Line: CommentType: TR 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. CommentEnd: SuggestedRemedy: Remove slotted aloha scheme in 8.4.3.4 and all references to it from the draft. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1714 CommenterName: Young, Song-Lin CommenterEmail: syoung@sharplabs.com CommenterPhone: 360-817-7509 CommenterFax: CommenterCo: Sharp Labs. of America Clause: 08 Subclause: 6.1, & Fig.88, 89 Page: 153 Line: CommentType: T 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. CommentEnd: SuggestedRemedy: Modify text that matches MSC of Fig. 3 and 4 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1100 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.1 Page: 137 Line: 11 CommentType: TR Comment: Reference to sub-clause 8.2.7 CommentEnd: SuggestedRemedy: Should be sub-clause 8.2.4 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1101 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.1 Page: 137 Line: 20 CommentType: TR Comment: wrong sub-clause reference CommentEnd: SuggestedRemedy: reference to 8.6 but should be 8.4? Have MAC people verify. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1346 CommenterName: Schrader, Mark CommenterEmail: mark.e.schrader@kodak.com CommenterPhone: 585-253-5241 CommenterFax: CommenterCo: Eastman Kodak Co. Clause: 08 Subclause: 8.1 Page: 146 Line: 2 CommentType: T 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. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1157 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.10 Page: 159 Line: 47 CommentType: TR 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. CommentEnd: SuggestedRemedy: On line 47 the probe request command is found at clause 7.5.4.1, not at 7.5.8.1. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 714 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 08 Subclause: 8.10 Page: 159 Line: 47 CommentType: TR Comment: The sentence fragment in line 47 is incorrect: "Each DEV in a piconet shall use probe request command,..." CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1571 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.10 Page: 159 Line: 47 CommentType: TR 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. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 389 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 08 Subclause: 8.10 Page: 159 Line: 48 CommentType: T Comment: Should not require the DEV to check the channel status. CommentEnd: SuggestedRemedy: Change "each DEV shall periodically" to "each DEV may periodically" RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1576 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.10 Page: 159 Line: 50 CommentType: TR Comment: ACK feedback can be used to determine if rate or power change is required. CommentEnd: 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." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 390 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 08 Subclause: 8.10 Page: 159 Line: 52 CommentType: T Comment: The first sentence is redundant and therefore evil since the requirement is in the table. CommentEnd: SuggestedRemedy: Delete the sentence "All group ... receive these frames." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 392 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 08 Subclause: 8.10 Page: 160 Line: 14 CommentType: T Comment: We should allow the lower rate modes to be used in the CAP for more reliable communications. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 391 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 08 Subclause: 8.10 Page: 160 Line: 5 CommentType: T Comment: Group addressed frames are not supported in the standard. CommentEnd: SuggestedRemedy: Change "group addressed" to "broadcast" in table 69. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1581 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.11 Page: Line: CommentType: T 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. CommentEnd: SuggestedRemedy: Add back the quiet command. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1579 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.11 Page: 160 Line: CommentType: TR 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. CommentEnd: SuggestedRemedy: Add the following sentence: "When PNC handover occurs, all repeater service is discontinued and must be renegotiated with the new PNC." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1580 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.11 Page: 160 Line: CommentType: TR 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. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 711 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 08 Subclause: 8.11 Page: 160 Line: 26 CommentType: TR 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. CommentEnd: SuggestedRemedy: See the repeater function clause in doc 02/037 for a detailed resolution. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 393 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 08 Subclause: 8.11 Page: 160 Line: 31 CommentType: T Comment: The current text does not give the PNC the option of rejecting the repeater service request. CommentEnd: 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." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1159 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.11 Page: 160 Line: 33 CommentType: TR Comment: Wrong Figure number CommentEnd: SuggestedRemedy: Figure 92, not figure 8.12 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 394 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 08 Subclause: 8.11 Page: 160 Line: 37 CommentType: T 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). CommentEnd: 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 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1160 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.11 Page: 160 Line: 45 CommentType: T Comment: Add clause reference CommentEnd: SuggestedRemedy: ... repeater service reject command (7.5.6.3) to the PNC. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 395 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 08 Subclause: 8.11 Page: 161 Line: 4 CommentType: T 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. CommentEnd: SuggestedRemedy: Change the MSC in Figure 92 to indicate that the channel time has already been negotiated prior to the repeater service setup. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 396 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 08 Subclause: 8.12 Page: 161 Line: 40 CommentType: T Comment: The PNC cannot keep the piconet quiet since psuedostatic timeslots still operate even without the beacon. CommentEnd: 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." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1162 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.12 Page: 161 Line: 41 CommentType: T Comment: In the opening line of the paragraph starting at line 41, we are informed of a desire to quiet the piconet. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 710 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 08 Subclause: 8.12 Page: 161 Line: 41 CommentType: TR Comment: The text between lines 41 and 47 describing how the PNC determines the availablity of a more suitable channel is incorrect. CommentEnd: SuggestedRemedy: See text in doc 02/037 for details regarding a more reasonable approach to determining the suitability of another channel. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 28 CommenterName: Bain, Jay CommenterEmail: jay.bain@timedomain.com CommenterPhone: 256 428 6415 CommenterFax: 256 527 4778 CommenterCo: Time Domain Clause: 08 Subclause: 8.12 Page: 161 Line: 41 CommentType: T 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. CommentEnd: SuggestedRemedy: Make mention that specific DEV to DEV operations are allowed during the quiet time but that no DEV to PNC traffic is allowed RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1165 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.12 Page: 161 Line: 44 CommentType: T Comment: add reference to the association response command CommentEnd: SuggestedRemedy: ... association response command (7.5.2.2), the DEVs ... RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1166 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.12 Page: 161 Line: 49 CommentType: T Comment: The sentence on line 49, starting with "The DEVs that ...", indicates a channel switch can take place. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1629 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.13 Page: Line: CommentType: TR 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. CommentEnd: SuggestedRemedy: I will be proposing a low complexity power management solution. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1584 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.13 Page: 162 Line: CommentType: TR 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 CommentEnd: SuggestedRemedy: Need to decide how to handle broadcast traffic when devices are in EPS mode since TCP/IP uses broadcast. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1585 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.13 Page: 162 Line: CommentType: TR 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. CommentEnd: SuggestedRemedy: Remove all references to EPS mode. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1586 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.13 Page: 162 Line: CommentType: TR 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. CommentEnd: SuggestedRemedy: Remove this sentence (along with RPS mode). RemedyEnd: Response: ResponseEnd: ----------- CommentID: 767 CommenterName: Huang, Bob CommenterEmail: robert.huang@am.sony.com CommenterPhone: 201-358-4409 CommenterFax: CommenterCo: Sony Electronics Clause: 08 Subclause: 8.13 Page: 162 Line: CommentType: TR 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. CommentEnd: SuggestedRemedy: Clarity needs to be brought to the text before technical merit can be adequately assessed. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1173 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.13 Page: 162 Line: 29 CommentType: TR 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". CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 709 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 08 Subclause: 8.13 Page: 162 Line: 29 CommentType: TR 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. CommentEnd: SuggestedRemedy: Remove clauses 8.13 through 8.13.3.12. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1168 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.13 Page: 162 Line: 29 CommentType: TR 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" CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1174 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.13.1 Page: 162 Line: 51 CommentType: TR Comment: Reference to CAP without reference to associate MTS CommentEnd: 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 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1587 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.13.1 Page: 162 Line: 51 CommentType: TR 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." CommentEnd: SuggestedRemedy: Delete all of 8.13.1 and 8.13.1.1 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 70 CommenterName: Barr, John CommenterEmail: John.Barr@Motorola.com CommenterPhone: 847-576-8706 CommenterFax: 847-651-6822 CommenterCo: Motorola Clause: 08 Subclause: 8.13.1.1 Page: 163 Line: 2830 CommentType: T Comment: PNC does not negotiate nor allocate bandwidth. Use of bandwidth in this paragraph does not match other parts of the specification. CommentEnd: SuggestedRemedy: Replace 'bandwidth' with 'channel time' in this paragraph. Bandwidth occurs twice. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1175 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.13.1.1 Page: 163 Line: 47 CommentType: TR Comment: Reference to CAP without reference to associate MTS CommentEnd: 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 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 411 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 08 Subclause: 8.13.12 Page: 171 Line: 25 CommentType: T Comment: The sentence "It is the responsibility ... is to wake." is redundant, adds no new information or requirements and is evil. CommentEnd: SuggestedRemedy: Delete the sentence. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1588 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.13.2 Page: 163 Line: CommentType: TR 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. CommentEnd: SuggestedRemedy: Remove all of 8.13.2, 8.13.21.1 and 8.13.2.2. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 397 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 08 Subclause: 8.13.2.1 Page: 164 Line: 14 CommentType: T Comment: What is changed is not listed here. CommentEnd: SuggestedRemedy: Change "Latency to change is" to "Latency to change channel time allocations is" RemedyEnd: Response: ResponseEnd: ----------- CommentID: 398 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 08 Subclause: 8.13.2.2 Page: 164 Line: 20 CommentType: T Comment: Redundant and therefore icky description of slot positioning. CommentEnd: SuggestedRemedy: Delete the text "Slot positioning ... used by RPS and EPS DEVs." (lines 20 through 23). RemedyEnd: Response: ResponseEnd: ----------- CommentID: 399 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 08 Subclause: 8.13.3 Page: 164 Line: 33 CommentType: T 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. CommentEnd: SuggestedRemedy: Delete the sentence. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1178 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.13.3 Page: 164 Line: 34 CommentType: T Comment: Reference to "power resources as dictated by the DEV-host". CommentEnd: SuggestedRemedy: I don't understand what this means (see above). Please clarify the sentence, prehaps with an example. Assigned to power management folks. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1188 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.13.3.1 Page: 164 Line: 36 CommentType: T 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 CommentEnd: SuggestedRemedy: Help is needed by the power management committee to generate this figure. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1185 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.13.3.1 Page: 164 Line: 36 CommentType: T 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. CommentEnd: SuggestedRemedy: The figure can be generated with help from the Power Management subcommittee RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1645 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.13.3.1 Page: 164 Line: 45 CommentType: TR 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. CommentEnd: SuggestedRemedy: Be consistent: ACTIVE and EPS are EPS States. They are not modes. EPS and PM_OFF ate PowerManagementModes. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1589 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.13.3.1 Page: 164 Line: 46 CommentType: TR 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. CommentEnd: SuggestedRemedy: Remove all references to "ACTIVE mode" and replace with "ACTIVE state" RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1210 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.13.3.11 Page: 171 Line: 10 CommentType: TR Comment: Line 10 indicates that the EPS DEVs recognize an error condition. CommentEnd: SuggestedRemedy: How is this done? Via Table 2 ReasonCode? The ReasonCodes in Table 2 are not defined. Refer to Power Management folks. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1213 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.13.3.11 Page: 171 Line: 12 CommentType: T Comment: Line 12 refers to a "recovery operation" CommentEnd: SuggestedRemedy: Where is this recovery operation described. Supply reference clause. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1211 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.13.3.11 Page: 171 Line: 12 CommentType: T Comment: Reference to a clause CommentEnd: SuggestedRemedy: Reference to clause6.3.1 should be 6.3.1.1. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 41 CommenterName: Bain, Jay CommenterEmail: jay.bain@timedomain.com CommenterPhone: 256 428 6415 CommenterFax: 256 527 4778 CommenterCo: Time Domain Clause: 08 Subclause: 8.13.3.11 Page: 171 Line: 18 CommentType: T Comment: Should provide clarification on recovery from incorrect beacon. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 400 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 08 Subclause: 8.13.3.2 Page: 165 Line: 11 CommentType: T Comment: The formal definition here is redundant and therefore evil. CommentEnd: SuggestedRemedy: Change "operation shall use the" to "operation uses the" RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1631 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.13.3.2 Page: 165 Line: 4 CommentType: TR 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. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1632 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.13.3.3 Page: Line: CommentType: TR Comment: I don't see anything in Annex B about how the EPS-Hosts provide anything through the MLME interface. CommentEnd: SuggestedRemedy: Fix this or remove this statement. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1630 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.13.3.3 Page: 165 Line: 20 CommentType: TR Comment: "The information in this primaiive" does not agree with the previous sentence which was taling about primitives. CommentEnd: SuggestedRemedy: change to "The information in these primaiives" RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1184 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.13.3.3 Page: 165 Line: 23 CommentType: T Comment: For the paragraph contained between lines 23 and 26, rewrite as shown below. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 754 CommenterName: Huang, Bob CommenterEmail: robert.huang@am.sony.com CommenterPhone: 201-358-4409 CommenterFax: CommenterCo: Sony Electronics Clause: 08 Subclause: 8.13.3.3 Page: 165 Line: 25 CommentType: TR 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? CommentEnd: SuggestedRemedy: Clarify RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1187 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.13.3.3 Page: 165 Line: 34 CommentType: T Comment: grammatical ... incomplete command name CommentEnd: SuggestedRemedy: in line 34 ... ... using the EPS Action request command ... RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1633 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.13.3.3 Page: 165 Line: 35 CommentType: TR 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. CommentEnd: SuggestedRemedy: Find a way to eliminate the need to use a frame request that ties to real time data like a beacon number. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1189 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.13.3.3 Page: 165 Line: 39 CommentType: T Comment: The paragraph between line 39 to 47 needs to be rewritten. A suggestion is shown below. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 401 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 08 Subclause: 8.13.3.3 Page: 165 Line: 40 CommentType: T Comment: The sentence "The EPS action command ... and EPSNext parameters." is redundant an therefore really annoying. CommentEnd: SuggestedRemedy: Delete the sentence. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 402 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 08 Subclause: 8.13.3.3 Page: 165 Line: 48 CommentType: T Comment: DEVs should be able to enter EPS mode when they finish configuration and should not have to wait for a command. CommentEnd: SuggestedRemedy: Delete the sentence "Once configuration ... further commands." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1635 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.13.3.3 Page: 165 Line: 50 CommentType: TR Comment: "awaiting further commands." Are they waiting for command frames or for MLME.requests from the DME? CommentEnd: SuggestedRemedy: Clarify what type of commands they are waiting for. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1636 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.13.3.3 Page: 165 Line: 5153 CommentType: TR Comment: It is not clear that the lone DEV creates and uses its own EPSSet. CommentEnd: SuggestedRemedy: Clarify if a lone DEV creates it's own EPSSet. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1637 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.13.3.3 Page: 165 Line: 5153 CommentType: TR 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? CommentEnd: SuggestedRemedy: Need to explain how another DEV communicates with a Solo EPS dev. Does it as for a CTA to each Solo EPS DEV? RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1191 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.13.3.3 Page: 166 Line: 1 CommentType: T Comment: The text between lines 1 to 9 need to be rewritten. Suggest text is shown below. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1649 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.13.3.3 Page: 166 Line: 13 CommentType: T Comment: Is renegotiation N-way, if there are N DEVs in the EPS set? N way negotiation will be very complex. CommentEnd: SuggestedRemedy: Describe if this is just peer to peer negotiation, N way negotiation with the N DEVs in the EPS set. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 753 CommenterName: Huang, Bob CommenterEmail: robert.huang@am.sony.com CommenterPhone: 201-358-4409 CommenterFax: CommenterCo: Sony Electronics Clause: 08 Subclause: 8.13.3.3 Page: 166 Line: 3 CommentType: T 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. CommentEnd: SuggestedRemedy: Clarify RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1650 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.13.3.3 Page: 166 Line: 56 CommentType: T 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. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 32 CommenterName: Bain, Jay CommenterEmail: jay.bain@timedomain.com CommenterPhone: 256 428 6415 CommenterFax: 256 527 4778 CommenterCo: Time Domain Clause: 08 Subclause: 8.13.3.4 Page: 166 Line: 45 CommentType: T 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. CommentEnd: SuggestedRemedy: Update the stream command in clause 7 and clause 6 primitives to provide a match between the stream operations and CTR. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1592 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.13.3.4 Page: 167 Line: 7 CommentType: T 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." CommentEnd: 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." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1194 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.13.3.4 Page: 167 Line: 7 CommentType: T Comment: On bullet number 2 ... what is meant bu N such that a proportion 1:N? CommentEnd: SuggestedRemedy: Power management to clarify and rewrite this sentence. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1655 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.13.3.5 Page: Line: CommentType: T 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. CommentEnd: SuggestedRemedy: Please clarify. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 404 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 08 Subclause: 8.13.3.5 Page: 168 Line: 24 CommentType: T 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. CommentEnd: SuggestedRemedy: Change the text to indicate that only the DEV-A/DEV-B slots are put into EPS sleep mode. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 403 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 08 Subclause: 8.13.3.5 Page: 168 Line: 3 CommentType: T Comment: The sentence "The PNC shall create ... their slot time." is redundant, evil and adds no new information. CommentEnd: SuggestedRemedy: Delete the sentence, the PNC is already required to do this. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 405 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 08 Subclause: 8.13.3.5 Page: 168 Line: 34 CommentType: T Comment: The PNC should not be required to create the EPS CTA if the piconet is too busy. CommentEnd: SuggestedRemedy: Change "The PNC shall create" to be "If the channel time is available, the PNC shall create" RemedyEnd: Response: ResponseEnd: ----------- CommentID: 406 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 08 Subclause: 8.13.3.7 Page: 170 Line: 18 CommentType: T 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. CommentEnd: SuggestedRemedy: Delete the paragraph. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 407 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 08 Subclause: 8.13.3.8 Page: 170 Line: 36 CommentType: T Comment: Master and slave are not defined in this context and the sentence does not add useful information. CommentEnd: SuggestedRemedy: Delete the sentence "Likely combinations ... and is an EPS DEV." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1208 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.13.3.8 Page: 170 Line: 36 CommentType: T 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. CommentEnd: SuggestedRemedy: Power Management committee to provide introductory figure. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 408 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 08 Subclause: 8.13.3.9 Page: 170 Line: 43 CommentType: T Comment: Multicast is not supported in this standard. CommentEnd: SuggestedRemedy: Change "piconet wide multicast and broadcast to" to be "broadcast frames to" RemedyEnd: Response: PROPOSED REJECT. ResponseEnd: ----------- CommentID: 1209 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.13.3.9 Page: 170 Line: 44 CommentType: T Comment: In line 170, reference is made that the "PNC shall save these for the next superframe". CommentEnd: 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? RemedyEnd: Response: ResponseEnd: ----------- CommentID: 409 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 08 Subclause: 8.13.3.9 Page: 170 Line: 46 CommentType: T Comment: The sentence "The EPS DEV shall interpret ... directed to it." is redundant and annoying. This is already required of all DEVs. CommentEnd: SuggestedRemedy: Delete the sentence. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 410 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 08 Subclause: 8.13.3.9 Page: 170 Line: 48 CommentType: T Comment: A formal requirement is listed without listing all of the required activity. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1595 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.14 Page: 171 Line: 32 CommentType: TR Comment: fixed maximum power applies to the CAP, and to shared and association MTSs. CommentEnd: SuggestedRemedy: Change to: "systems, a fixed maximum power in the CAP and shared and association MTSs, and adjustable power in the GTS." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1598 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.14.2 Page: 172 Line: 1 CommentType: T Comment: the chosen power level should be the closest on that is greater than the requested one. CommentEnd: 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." RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1599 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.14.2 Page: 172 Line: 6 CommentType: TR 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. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1215 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.15 Page: 172 Line: 20 CommentType: T Comment: provide explicit reference to the tables. CommentEnd: SuggestedRemedy: A list of the rules are specified in Tables 71 and 72. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 412 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 08 Subclause: 8.15 Page: 172 Line: 30 CommentType: T Comment: Association response has no ACK. CommentEnd: SuggestedRemedy: Delete the reference to the ACK and change the number of frames to be 1. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 413 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 08 Subclause: 8.15 Page: 172 Line: 36 CommentType: T Comment: Group addressed frames are not supported in this standard. CommentEnd: SuggestedRemedy: Change "Group addressed" to be "Broadcast" in figures 71 and 72 RemedyEnd: Response: ResponseEnd: ----------- CommentID: 414 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 08 Subclause: 8.16 Page: 173 Line: 46 CommentType: T Comment: The aProbeResonseDelay is too short, a DEV should have at least 1 superframe to respond. CommentEnd: SuggestedRemedy: Change 8 ms to be aMaxSuperframeDuration. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 415 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 08 Subclause: 8.16 Page: 173 Line: 48 CommentType: T Comment: aFragThreshold is not a constant and should be defined earlier in 8 as indicated in another comment. CommentEnd: SuggestedRemedy: Delete the constant. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 416 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 08 Subclause: 8.16 Page: 174 Line: 8 CommentType: T Comment: aBroadcastDEVInfoDuration is repeated twice, use first definition. CommentEnd: SuggestedRemedy: Delete the definition on line 8, page 174. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 37 CommenterName: Bain, Jay CommenterEmail: jay.bain@timedomain.com CommenterPhone: 256 428 6415 CommenterFax: 256 527 4778 CommenterCo: Time Domain Clause: 08 Subclause: 8.2 Page: 137 Line: 44 CommentType: TR 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. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 724 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 08 Subclause: 8.2.1 Page: 137 Line: 50 CommentType: TR 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. CommentEnd: SuggestedRemedy: The scanning clause and the Start Piconet clause of doc 02/037 describes in detail the resolution to this problem. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1522 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.2.1 Page: 137 Line: 51 CommentType: TR 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. CommentEnd: SuggestedRemedy: Add the mechanism to scan for interference as well as just scanning for piconets. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1102 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.2.1 Page: 138 Line: 13 CommentType: T Comment: add some words to exclude open scan mode ... as shown below CommentEnd: 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) RemedyEnd: Response: ResponseEnd: ----------- CommentID: 30 CommenterName: Bain, Jay CommenterEmail: jay.bain@timedomain.com CommenterPhone: 256 428 6415 CommenterFax: 256 527 4778 CommenterCo: Time Domain Clause: 08 Subclause: 8.2.1 Page: 138 Line: 7 CommentType: TR 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! CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1524 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.2.2 Page: 138 Line: 27 CommentType: TR 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. CommentEnd: SuggestedRemedy: Clarify if each PNC calculates the same random number each time they generate a PNID, or if it is different each time. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1526 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.2.3 Page: 138 Line: CommentType: TR 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 CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 723 CommenterName: Heberling, Allen CommenterEmail: aheberling@xtremespectrum.com CommenterPhone: 703-269-3022 CommenterFax: 571-220-1211 CommenterCo: XtremeSpectrum, Inc. Clause: 08 Subclause: 8.2.3 Page: 138 Line: 30 CommentType: TR 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. CommentEnd: SuggestedRemedy: the PNC challenge and handover clause in doc 02/037r0 contains detailed text describing a more efficient approach. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 38 CommenterName: Bain, Jay CommenterEmail: jay.bain@timedomain.com CommenterPhone: 256 428 6415 CommenterFax: 256 527 4778 CommenterCo: Time Domain Clause: 08 Subclause: 8.2.3 Page: 138 Line: 30 CommentType: TR 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. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 297 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 08 Subclause: 8.2.3 Page: 138 Line: 32 CommentType: T Comment: The PNC selection process does not define a channel access method for the ACs that are broadcasting their messages. CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 363 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 08 Subclause: 8.2.3 Page: 139 Line: 31 CommentType: T Comment: Informal language use for required action. CommentEnd: SuggestedRemedy: Change "selection command and wait for the piconet" to "selection conmmand and shall wait for the piconet" RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1529 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.2.4 Page: Line: CommentType: TR Comment: What happens if the PNC wants to shut down, but there is no other alternate PNC available. Does the PNC just go away? CommentEnd: SuggestedRemedy: Add a PNC shutdown command or IE in the beacon to inform the piconet the at the PNC is shutting down. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1105 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.2.4 Page: 140 Line: 17 CommentType: TR 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. CommentEnd: SuggestedRemedy: MAC folks ... where is this table? RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1123 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.2.4 Page: 140 Line: 20 CommentType: T Comment: line 20 refers to aMinHandOvrTO CommentEnd: SuggestedRemedy: I don't understand why we need a aMinHandOvrTO ... have MAC folks verify it is needed. If not then delete. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1124 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.2.4 Page: 140 Line: 21 CommentType: T Comment: In line 21 we have a parameter aMaxHandOvrTO CommentEnd: 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. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 734 CommenterName: Huang, Bob CommenterEmail: robert.huang@am.sony.com CommenterPhone: 201-358-4409 CommenterFax: CommenterCo: Sony Electronics Clause: 08 Subclause: 8.2.4 Page: 140 Line: 24 CommentType: T Comment: As stream transmission need not be inturrpted during coordinator handover, it would be useful to add that the PNID remains the same. CommentEnd: SuggestedRemedy: insert text ', using the original PNID,' between the words 'beacon at'. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 364 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 08 Subclause: 8.2.4 Page: 140 Line: 26 CommentType: T Comment: Need clarification of when the new PNC begins using the PNC address. CommentEnd: 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" RemedyEnd: Response: ResponseEnd: ----------- CommentID: 755 CommenterName: Huang, Bob CommenterEmail: robert.huang@am.sony.com CommenterPhone: 201-358-4409 CommenterFax: CommenterCo: Sony Electronics Clause: 08 Subclause: 8.2.4 Page: 140 Line: 28 CommentType: TR 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. CommentEnd: SuggestedRemedy: Fix RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1125 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.2.4 Page: 140 Line: 29 CommentType: TR Comment: On a coordinator handover, do all the authentication certificates also transfer or does each DEV need to re-authenticate? CommentEnd: SuggestedRemedy: Add text after line 29 to clarify. Security folks. (BTW - I hope all the certificates transfer). RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1530 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.2.4 Page: 141 Line: CommentType: TR Comment: What happens when two piconets wander withing range of each other? They will not know that the other PNC is there. CommentEnd: SuggestedRemedy: Need to have the PNCs do a periodic scann to look for traffic from other piconets including beacons in their channel. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1528 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.2.4 Page: 141 Line: CommentType: TR Comment: What happens to repeater treaffic when a handover takes place? Is it all dropped? CommentEnd: SuggestedRemedy: All repeater traffic should be dropped and renegotiated whan a PNC handover takes place. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1127 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.2.4 Page: 141 Line: 10 CommentType: TR 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. CommentEnd: SuggestedRemedy: Refer to Security/MAC committees for resolution. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1128 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.2.4 Page: 141 Line: 13 CommentType: TR Comment: Wrong table reference. CommentEnd: SuggestedRemedy: Should be Table 68, NOT table 79. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1126 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.2.4 Page: 141 Line: 7 CommentType: TR Comment: Line 7 refers to a "DEV information table" in clause 7.5.1.4 CommentEnd: SuggestedRemedy: Clause 7.5.1.4 does not contain any tables. Where is the table located? Assign to MAC subcommittee. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 365 CommenterName: Gilb, James CommenterEmail: gilb@ieee.org CommenterPhone: 858-538-3903 CommenterFax: 858-213-6706 CommenterCo: Appairent Clause: 08 Subclause: 8.2.5 Page: 142 Line: 11 CommentType: T Comment: The directed frame with Private GTS is optional and should be noted as such in Figure 81. CommentEnd: 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" RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1129 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.2.6 Page: 142 Line: 33 CommentType: T Comment: It will help to clarify by adding the actual address CommentEnd: SuggestedRemedy: association address (0xFE), 7.2.3, as the ... RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1130 CommenterName: Roberts, Richard CommenterEmail: rroberts@xtremespectrum.com CommenterPhone: 703-269-3043 CommenterFax: 301-613-5016 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.2.6 Page: 142 Line: 39 CommentType: T Comment: In the line straddling line number 39, we are instructed what the PNC is to do if the request is not accepted. CommentEnd: SuggestedRemedy: MAC folks ... add a sentence to indicate what the neighbor is suppose to if the request is not accepted. RemedyEnd: Response: ResponseEnd: ----------- CommentID: 1532 CommenterName: Shvodian, William CommenterEmail: bshvodian@xtremespectrum.com CommenterPhone: 703-269-3047 CommenterFax: 301-523-1538 CommenterCo: XtremeSpectrum Clause: 08 Subclause: 8.2.6 Page: 143 Line: CommentType: T Comment: In a neighbor p