# Main

Comment:
Replace "Dan Bailey" with "Daniel Bailey"

SuggestedRemedy:
Replace "Dan Bailey" with "Daniel Bailey"


Comment:
The standard should be extensible to allow for other authentication and key establishment mechanisms, such as 802.1x and the forthcoming 802 security standard.


Comment:
There is little consistency among the options for public-key establishment in the draft.  Moreover, there are too many.  Further, the standard lacks extensibility to 802.1x and the forthcoming 802 link security standard.  The MAC handles public-key authentication transparently: it's all in the DME.  802.15.4 recognized this and left key establishment to industry bodies or other follow-on documents.  That simplified their standard and let ZigBee work toward industry consensus on public-key establishment.

SuggestedRemedy:
Remove all public-key suites from the standard.  Update authentication-related command frames such as AUTHENTICATE-REQUEST and -RESPONSE and CHALLENGE-REQUEST and -RESPONSE to be more generic, simply providing OIDs and opaque blobs, rather than bitfields and specific fields like PublicKeyObject.  This will allow different authentication protocols with differing numbers of passes.  Retain MLME-SECID-UPDATE to allow the DME to transfer keying material to the MAC.
Remove most of sections 9 and 10, retaining only those items that specify symmetric key operations.  In particular, remove 10.2.1 and allow implementers to use any valid OID for authentication mechanism such as 802.1x or mechanisms to be defined by industry bodies or other documents. Suggest continuing to standardize the current public-key techniques in a separate document.


Comment:
If this requires a recirculation, please update the copyright year to 2003.


Comment:
The trademarks it your draft are handled a little incorrectly. IEEE Std 802(r) is the only registered trademark. All the others, e.g., IEEE Std 802.3(tm)-2002, should get the "TM" symbol, and this symbol should appear right after the standard number, not the standard year.


Comment:
Please make sure all figures and tables have the appropriate permissions and identifications if any have been taken from another source.


Comment:
At the time of submission to the Board, or just prior to publication, you will need to supply a mailing address for each member of the working group that worked on the document.  This will ensure that all members of the working group receive a complimentary copy of the standard.


Comment:
I have a problem with this standard. I believe 15.3 should have been completely interoperable with 15.1, 15.3 and 11b. Although it seems that 15.3 has put some effort towards that goal, it did not take the last steps, whic are essential. The result is that 802 is now sending quite a confused message to the market. What device should the portable/mobile computer be equipped with? 11g? 15.1? 15.3? All of the above? Neither?  Does 802.15 have any roadmap towards some kind of unification? Despite of that, I voted "approve", because I appreciate the effort put into the standard.  However, I would like to see, or more importantly, I want RevCom to see the group rebuttal, and I hope some effort towards a more interoperable WPAN standard is going to be made.


Comment:
Again, the Draft title is incorrect and it is my understanding that the following WG LB22 (-02/458r5) resolution will be enforced quickly in 2003 to "ACCEPT IN PRINCIPLE. The TG will start the process to create either a corrigendum or modification of the PAR. When the title is changed in the PAR, we will change the title in the draft to match it.".
Specifically, the PAR and the Draft 15 state incorrectly "Part 15" it should be "Part 15.3".
This comment is now to be considered technically binding to my negative Sponsor Ballot, also that it as an IEEE-SA issue now because of the recently (Dec02/NesCom) approved "802.15.3a" PAR which references "Part 15.3" not "Part 15":

<snip>
"P802.15.3a (C/LM) Amendment to Standard for Telecommunications and Information Exchange Between Systems - LAN/MAN Specific Requirements – **Part 15.3**: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Higher Speed Physical Layer Extension for the High Rate Wireless Personal Area Networks (WPAN) Recommendation: Approve new PAR until December 2006."
</snip>
Source: http://ieee802.org/secmail/msg02994.html [December Standards Board mtg notes 2002.pdf].

The new 802.15.3a PAR correctly refers back to 802.15.3 but the D15 title states "802.15" which is incorrect, unless the change is made.

Additionally, it is assumed that the 15.3a is an amendment to the base standard and will eventually become a part of a single base 15.3 standard; this will be problematic unless the PAR and Draft state the correct 802.15.3 title.

Finally, the 802.15 is different than other 802 Working Groups (MAC WG, etc.) in that we are fielding three (3) distinctly different MAC Sublayers (802.15.1, 802.15.3, and 802.15.4) this reinforces that we do not want to misuse the 802.15 name.

SuggestedRemedy:
Again, I suggest:
Draft Standard for Information technology-
Telecommunications and information exchange between systems-
Local and metropolitan area networks Specific requirements-

Part 15.3: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for High Rate Wireless Personal Area Networks (WPANs)

IEEE Computer Society

Sponsored by the
LAN/MAN Standards Committee

Please make the change globally.


Comment:
Again, the sentence "The Medium Access Control (MAC) sublayer protocol supports both isochronous and asynchronous data types and is designed to support additional physical layers as might be specified at a later time." is out of scope based on the PAR.  I read the WG LB22 (-02/458r5) CommentID #22 resolution but I disagree with the BRC.  The BRC resolution states "REJECT. It is not out of scope to create a standard that is extensible.  Based on the history of IEEE standards, it is the rule, not the exception, that a MAC will be used with multiple versions of a PHY.  The statement in the abstract is true, this MAC was designed with an eye to supporting multiple PHYs." is irrelevant and based on the IEEE Standards Style Manual which states: "Abstracts should be based on the scope and purpose of the standard as indicated on the PAR..." this resolution is invalid.

The statement ending "..and is designed to support additional physical layers as might be specified at a later time." has no basis and should be removed and/or the TG should apply a corrigendum or modification to the 802.15.3 PAR.  I prefer the later resolution.

SuggestedRemedy:
I suggest, based on the recent acceptance of the WG LB22 (-02/458r5) CommentID #21 to apply a corrigendum or modification to the 802.15.3 PAR due to the title problem, that the D15 abstract remain as is and that a new sentence be added to the scope of the 802.15.3 PAR.  After correcting the title I suggest adding the following to the end of the PARs scope paragraph: "The Medium Access Control (MAC) sublayer protocol will support both isochronous and asynchronous data types and will be designed to support additional physical layers as might be specified at a later time."


Comment:
The title on this page and usage of (R) and (TM) are incorrect in the draft.  For example the title "Introduction to Draft 802.15.3,2003 Edition" is incorrect and the first sentence is too "[This introduction is not part of IEEE Std 802.15.3-2003(R), Draft..."
Note: This is a recent change of trademark policy at IEEE-SA (a change that was instigated and advocatedby the 802 SEC). The typical "IEEE-SA Trademark Usage/Compliance Statement" has been deleted, and the use of trademark symbols has been revised.

SuggestedRemedy:
I suggest changing the top of the page to: "Introduction"
[This introduction is not part of IEEE Std 802.15.3(TM)-2003, Draft..."

Also, the usage of (R) or registered needs to corrected to (TM) in almost all cases and (TM) needs to be added in many instances.  An example is the use of "802.15.1" the Editor needs to state "802.15.1(TM)" or IEEE Std 802.15.1(TM)-2002.  Refer to the IEEE Std 802.15.1(TM)-2002 as an example.  Also, discuss this with the Project Editor.  Please make the change globally.


Comment:
The sentence "Keywords: Wireless; PAN; WPAN;..." is grammatically incorrect and inconsistent with other approved standards.

SuggestedRemedy:
I suggest "Keywords: Wireless, PAN, WPAN,..."; replacing the semicolon with a comma.


Comment:
Search for min beacon repeat and add xrefs back to the announcement section.


Comment:
Remove Slotted aloha scheme from the draft ref: CID 537 - LB12, CID 387 - LB19, and CID 56 - LB22.  What is the point in having slotted aloha access in addition to the backoff in CAP, TDMA in CFP? I don't see any justification in having yet another access scheme with WPAN. Why is this unncessary additional complexity being forced on to the implementors of this "low cost", "low complexity" and "low power" standard? If some future PHYs need it, let this be added as and when such a PHY is added to the 802.15.3 standard.


Comment:
Remove MCTA scheme from the standard ref: CID 536 - LB12, CID 513 - LB19, and CID 63 - LB22.  Why can't the open and association be performed in CAP instead of devicing a new mechanism altogether for such a relatively low probability events? what is the point in having another collision based access mechanism inside a declared "collision free period (CFP)". If the concern is about a new PHY that may be added in the future, this mechanism can be added at the time of including the new PHY as allocations to a currently reserved stream ID (or DEVID) so that the legacy DEVs keep off of those slots and the new DEVs use them as per the new rules.


Comment:
Replace MIFS with SIFS ref: CID 68 - LB22
- MIFS is less than SIFS
- it does not result in any significant time eficiency given the low probability of its use
- But introduces yet another IFS at the lowest level of MAC
- Mandates that the receive frames be processed within MIFS instead of SIFS since the worst case IFS is MIFS and hence drastically increases the complexity at the MAC and PHY Remove MIFS and use SIFS in its place.


Comment:
Summarise all PHY timing parameters in one table in 11.2.7 ref: CID 69 - LB22 A summary all PHY dependent parameters (aCCADetectTime,aPHYSIFS-Time etc.) in a table with actual values at one place instead of spreading them all around the PHY clause is very desirable from implementors'view. An example would be Table-64 for MAC parameters. Although Table-120 provides a list of just the IFS parameters in a table, even there the for actual values the readers have to scrouge through the individual subclauses, which can easily be avoided.


Comment:
Remove app-specific IE ref: CID 446, 477, 478 and 479 - LB19, CID 71 - LB22.  Use of Vendor specific command is the answer to the issue that is intended to be solved through this app-specific IE. This is expecially since neither the standard nor an implementation of PNC can force the interpretation of bits in the currently undefined payload of this IE at each DEV which may be implemented by variety of vendors with their own "application" specific interpretations of those bits.


Comment:
Please avoid the following verbs when "DEV" or "PNC" is the subject: to know, to want, to decide.


Comment:
It should be said somewhere in the standard that a DEV shall only transmit frames with the PNID for its piconet, ie, that a DEV shall not send a frame with the wrong PNID.  
It should also probably be said that a DEV shall not ACK a directed frame containing a PNID different from that of the piconet the to which the DEV belongs.


Comment:
The issue of piconet coalescence is not dealt with in the standard and should be to insure both interoperability and uniform behavior from the consumer's point of view.  
Consider the following scenario.  A mobile DEV (DEV B) temporarily wanders outside the range of PNC A for more than ATP.  This results in PNC A dropping DEV B from piconet A.  Next, DEV B realizes it's no longer part of piconet A, can find no other piconet, and so starts its own piconet, piconet B.  Then DEV C wanders from piconet A, times out and joins piconet B.  A short time later DEV B wanders back into range of the piconet A's PNC.  What should happen?
I imagine this kind of scenario has been discussed at length in the 15.3 WG.


Comment:
Why limit the piconet services field in the piconet services IE to 128 bytes?  Why not allow it to use the remainder of the 256-byte length space, namely, 253 bytes?


Comment:
There can be a flow imbalance problem between the PNC and DEVs in the CAP.  Eg, if there are 20 DEVs in the piconet, and CAP access is contention-bound, then the PNC will only get about 1/20 (or maybe 1/21, depending on how you count things) of the CAP tx-ops, but the PNC's CAP load will normally be about 1/2 of the MAC commands sent during the CAP. This imbalance can be fully fixed, I think, by allowing the PNC to tx a SIFS following the terminating ACK for a non-PNC CAP PDU.  Essentially, this gives the PNC half of the tx-ops.


Comment:
At the source DEV, frames are transmitted in the order in which they are delivered to the source DEV's MAC by the FCSL for transmission over the 802.15.3 WPAN on a per-stream basis.  On a per-stream basis means that considering any specific stream, MSDUs are transmitted in the order in which the FCSL hands them to the source DEV MAC for delivery.  The sole exception should be for D-Ack.  Please see my comment on D-Ack regarding this topic.
This should be explicitly stated in the specification.


Comment:
Throughout the draft, the security arguments should clearly distinguish between the different security suites defined. Moreover, each security suite shall refer to an external and vendor-independent standard for the claimed bit-security level. This applies both to the public-key based key establishment protocols (currently: ECC, RSA, and Lattice-based) and to the symmetric-key algorithms (currently: AES-CCM). If this evidence cannot be provided, the security suite shall be removed.


Comment:
Contributors (Page v): The last "e" in the first name of "Rene Struik" has an "accent aigu" on top of it. IEEE-SA (Page vi): Please make the sentence plural, since more than one IEEE-SA board member is listed.


Comment:
Remove all unnecessary data expansion due to sending over and over again security status information.


Comment:
Incorporate a way to have 802.15.3a devices interoperate with 802.15.3 devices, while using a more efficient symmetric security suite than the AES-CCM suite as in the current draft.


Comment:
Allow multicasting, both secure and non-secure.

SuggestedRemedy:
Suggested remedy: This will be provided separately.


SuggestedRemedy:
"Correct them.  For example, the heading for 5.3.7 should be "Data communications between DEVs", for 5.3.8 " Information discovery in the piconet", for 5.3.11 "Transmit power control in the piconet", for 6.3.5 "Association", for 6.3.6 "Disassociation", for 6.3.7 "Authentication and challenge", for 6.3.8 "Key request", for 6.3.9 "Key distribution", for 6.3.10 "Deauthentication", for 6.3.11 "SECID initialization and update", for 6.3.12 "Security management", for 6.3.13 "PNC handover", for 6.3.14 "PNC information request", for 6.3.15 "ACL information retrieval", for6.3.16 "ASIE management", for 6.3.17 "Peer information retrieval", for 6.3.20 "Channel status request", for 6.3.22 "Piconet parameters change", for 7.5.1 "Association and disassociation commands", for 7.5.5 "Channel time allocation request, modification, and termination commands", and for 7.5.6 "Channel status commands"."


Comment:
Stylistic inconsistencies in reference to proper names.

SuggestedRemedy:
"Capitalize the first letter of the words that form a field, a command, or an element name throughout their appearances (especially in text). This is also to avoid confusion and non-interoperability when "next" or "last" is actually the starting word of a field/element name. "


Comment:
Again, the text "...20 Mb/s is proposed to be the lowest rate..." and the text on the next page, pg 2, ln 14 "...20 Mb/s or more..." are from the PAR but Clause 11, Table 118, pg 313, ln 14 states "...11 Mb/s...".  It is very likely that this inconsistancy (PAR vs. Draft) issue will come up when submitted to RevCom for review.  A parallel PAR change now will add mimimal to no delay to the project BUT RevCom can add 3-6 months!
I read the WG LB22 (-02/458r5) CommentID #26 resolution and I agree with the BRC.  The BRC resolution states "ACCEPT IN PRINCIPLE. The current PAR only states that DEVs will support greater than 20 Mb/s, i.e. that the rate will be high enough, 20 Mb/s or more. All DEVs are required to support the 22 Mb/s mode so that this fulfills the requirment. Note that the quoted text says that 20 Mb/s is proposed to be the lowest rate, but it is not a requirement from the PAR. However, as a part of the corrigendum or PAR modification process, the TG will look at the text to see if it can be clarified.".

Please follow up this WG resolution in Sponsor Ballot.

SuggestedRemedy:
I suggest that the 802.15.3 Sponsor Ballot Review Committee (SBRC) submit a draft corrigendum 802.15.3 PAR to the TG3/WG for submission to the SEC/NesCom the goal is to update the PAR to change the minimum data rate to "11 Mb/s".
Note: The latest 15.4 PAR addressed and resolved the same issue "The draft says 20 so the PAR should say 20." said BobH but TG4 decided to act:
http://ieee802.org/secmail/msg02790.html
Here is follow up on the thread:
http://ieee802.org/secmail/msg02794.html
http://ieee802.org/secmail/msg02796.html


Comment:
The references "FIPS Pub 186-2," and "FIPS Pub 198," appear to be incomplete.  Are these also NIST publications?

SuggestedRemedy:
I suggest "NIST FIPS Pub 186-2," and "NIST FIPS Pub 198,"; adding "NIST" to the reference.


Comment:
The reference "PKCS#1 v2.1, RSA Cryptography Standard, RSA Laboratories, June 14, 2002.9" is inconsistent and incomplete.

SuggestedRemedy:
I suggest: "Public-Key Cryptography Standard (PKCS) #1, v2.1: RSA Security Inc., June 14, 2002.9"; which is consistent with the previous EESS entry and the IEEE Standards Style Manual.


Comment:
The reference "SEC 1: Standards for Efficient Cryptography, Elliptic Curve Cryptography, Version 1.0, Certicom Research, September 20, 2000.10", is inconsistent.

SuggestedRemedy:
I suggest: "Standards for Efficient Cryptography (SEC) 1, Elliptic Curve Cryptography, v1.0: Certicom Corporation, September 20, 2000.10"; which is consistent with the previous EESS entry and the IEEE Standards Style Manual.
Also, I suggest changing the footnote to: "10 SECG publications are available from http://www.secg.org."; adding a period to the end of the sentence and I would delete the leading extra space found on footnote 10.


Comment:
The EESS#1 reference should read as follows: "Consortium for Efficient Embedded Security, Efficient Embedded Security Standards (EESS), EESS #1: Implementation Aspects of NTRUEncrypt and NTRUSign, Version 1.0, November 13, 2002. Available from http://www.ceesstandards.org." The SEC1 reference should read as follows: "Standards for Efficient Cryptography, SEC 1: Elliptic Curve Cryptography, Version 1.0, Certicom Research, September 20, 2000. Available from http://www.secg.org/." These changes were suggested to the technical editor on several occasions (lastly on Nov 22, 2002), but never implemented correctly.


Comment:
The present wording suggests that revisions of the normative references do not change the specification or the scope of concepts introduced in previous versions hereof. Reality learns otherwise (e.g., with security specifications). One should explicitly avoid the risk of 'moving target' specifications, since the mere approval of a revision does not rule this out.

SuggestedRemedy:
Completely remove the last sentence of this paragraph, i.e., delete the complete sentence 'When the following standards are superseded by an approved revision, the revision shall apply'.


SuggestedRemedy:
Add new definition: secure frame: A command or data frame in which cryptographic techniques are applied to provide encryption or integrity.


Comment:
Need a definition for security relationship


Comment:
This definition seems to be incomplete.  What unauthorized replay is the nonce prevenenting?


Comment:
CTA has a specific meaning in D15, namely, an actual channel time allocation.  The term GTS was dropped in favor of CTA.  But specifically, what is a "channel time allocation"?  Is it a GTS?   Is it the channel time allocation block?  The channel time allocation block IE?  The CFP channel time specified by a channel time allocation block?  The CFP channel time reserved as a result of a CTRB?
Since the CTRB is the atomic unit of channel time request, the channel time reserved by the PNC in response to a CTRB is the resulting allocation, and thus should be the definition of channel time allocation.

SuggestedRemedy:
The phrase "channel time allocation" should be defined in clause 3 as "Channel Time Allocation:  The CFP channel time allocated by the PNC in response to a CTRB in a CTR."


Comment:
Incorporate proper security notions throughout the Draft, defined in line with well-established cryptographic practice. We give an example of improper usage: in Clause 3, Page 5, line 21, 'authentication' is confused with 'authorization', since 'authentication' refers to 'evidence as to the true source of information or the true identity of entities' (see, e.g., the Handbook of Applied Cryptography, or Slide 2 of 02/114r5), whereas 'authorization' refers to 'assurance that an entity may perform specific operations'. This improper/sloppy use of terminology leads to misleading claims regarding security services offered.  The following terms in Clause 3 need more accurate definitions: authentication, authentic data, integrity code, key establishment, key management, key transport, nonce, symmetric key.

SuggestedRemedy:
I am - again - prepared to offer help, but this would assume flexibility and an open mind from the assistant security editor as well. Let us try again…


SuggestedRemedy:
Change the definition as follows:  The process of assuring that an entity is what it claims to be.


SuggestedRemedy:
Change the definition as follows:  The unit of data delivered between medium access control service access points.


Comment:
TLA description for CBC is incorrect. Please change <from> "cipher clock chaining" <to> "cipher block chaining"


Comment:
The standard should be extensible to allow other authentication and key establishment mechanisms, such as 802.1x that may not be based on public-key technology.

SuggestedRemedy:
Remove the sentence "The authentication process is based on public-key cryptography."


Comment:
perhaps add the beacon extension idea to clarify.


Comment:
Implies that the CAP always permits data useage. Perhaps change to "The PNC may permit ..."


Comment:
I think this subclause title "5.1 What is a piconet" needs a question mark.


Comment:
The sentence "Thus even if there are no associated..."; is gramatically incorrect.

SuggestedRemedy:
I suggest "Thus, even if there are no associated..."; adding a comma.


Comment:
I think the sentence fragment "...which cover a larger geographic area,..." can be made clearer.

SuggestedRemedy:
I suggest "...which cover a successively larger geographic area,...".


Comment:
The sentence "If no channels are available, the DEV has the option of attempting to start either dependent piconet, as described in 8.2.4 and 8.2.5 and summarized in 5.3.1.3 and 5.3.1.4." is confusing.  Why is the word "either" being used?

SuggestedRemedy:
I suggest the Editor correct the sentence to reflect the DEVs option when no channels are available.


Comment:
The sentence "...which illustrated in Figure 2." is incorrect.

SuggestedRemedy:
I suggest "...which is illustrated in Figure 2."; adding "is".


Comment:
The words "shut down" should be changed.


Comment:
Change this sentence frag. <from> "...which illustrated in Figure 2." <to> "... which is illustrated in Figure 2."


Comment:
In order to avoid corner conditions on handoff (in 8.2.3), it would be necessary to have as a fundamental piconet requirement (at least for 802.15.3), that all PNC-capable DEVs must be capable of communicating with all devices in a piconet.  If for example this requirement is not met, then it cannot be assumed that beacons will be received by all DEVs in a piconet. Thus you can have situations where 2 (or more) PNC-capable devices don't get a beacon, start up piconets, & communication is lost.  So, either you've got to make the above communicability a requirement OR you've got to handle these corner conditions & exceptions.  I'm assuming, since it's a WPAN, that the "communicability" requirement is easiest to consider.


Comment:
Clause 5.3.5 talks about the CAP's use for transmitting MAC commands being able to be replaced by use of MCTAs (D15p17L2-3).  A cross-reference should be placed here to subclause 11.2.10.

SuggestedRemedy:
I suggest adding the text "subject to the requirements of 11.2.10" at the end of the sentence that ends at the beginning of D15P17L3.


Comment:
Sentence references a PS bitmap IE that does not exist.

SuggestedRemedy:
Replace "PS bitmap IE" with "PS Status IE"


Comment:
On line 15, replace 'the channels' by 'the available channels'; on line 16, replace 'that is empty' by 'that is clear'; on line 18, replace 'start either dependent piconet' by 'start a dependent piconet'.


Comment:
What happens in the event of a handover of the child PNC, where the new child PNC is not part of the parent piconet?


Comment:
The procedure by which a child piconet ends its piconet is not described. If the child PNC uses the 'disassociate' command here fore as well, this has the inadvertent side-effect that not only the child piconet is ended, but also the child piconet controller is disassociated!

SuggestedRemedy:
The disassociation command for child piconets should distinguish the child PNC from the child piconet (by using the proper DEVID as of Clause 7.2.3). I could not find this in the text, but might have overlooked this.


Comment:
Replace '(data integrity and data encryption)' by '(data authenticity and/or data encryption)'.


Comment:
change the Frame Control Field, such as to allow flexibility in the security services provided. Comment: in the current draft, the security services that are provided on frames statically depend on the frame type (beacon, ACK, command, and data frame). Conceptually, the communicating device should decide how to protect the frames it sends (although it might keep the requirements and capabilities of the recipient devices in mind). Additionally, this would allow considerable efficiency gains for applications where one requires only data authenticity or data confidentiality, but not both (since one would save a factor two in computational workload and, potentially, bandwidth). More flexibility would be provided by allowing a SEC field of 3 bits, which would allow the following 8 possibilities for frame protection to be indicated: SEC = Encr x Auth, where Encr={ON, OFF} and where Auth={0, 32-bit, 64-bit, 128-bit}. (Here, Encr=ON and Auth=64 would correspond to encrypting data and providing a 64-bit integrity check hereover, whereas, e.g., Encr=OFF and Auth=0 would correspond to having no security at all.). This security services indicator might be arranged at the frame level, but there is ample room for specifying this in the frame control field (it costs 3 bits including the SEC bit that is already provided in the current Draft D15).

SuggestedRemedy:
Change the draft in line with the flexible security services identifier example given above and adapt all impacted text. See also the last slide of document 02/290 that was already presented in July 2002 (IEEE 802 meeting in Vancouver).


Comment:
Further clarification needed in line 27.

SuggestedRemedy:
"Between "four" and "modes" add "power management"."


Comment:
Incorrect statement in the last paragraph in line 47.

SuggestedRemedy:
"Replace "In addition to the power save modes" with "Regardless of the power management mode"."


Comment:
PublicKeyObjectLength isn't sent in the frame defined in 7.5.2.1


Comment:
The MAC currently has no PIB group for peer to peer relationships

SuggestedRemedy:
Replicate Table 37 for peer to peer relationships


Comment:
Indicate that security is ignored while scanning for a piconet.

SuggestedRemedy:
Add a new paragraph: "Any security features of an existing piconet are ignored during this process" to the end of 6.3.2.


Comment:
When a piconet is first started, what is the value of the SECID?

SuggestedRemedy:
Clarify if a dummy SECID value is used, or a SECID value is generated then discarded when a DEV joins the piconet.


Comment:
The MAC presumably already knows its DEVAddress, so the DME doesn't need to send it in this primitive.


Comment:
The resolution for LB22 cid 1 is that the technical editor will review the MLMEs and suggest a uniform method for specifying variable length fields. This still needs to be applied as 6.3.24.2 MLME-PS-SET-INFORMATION.confirm and 6.3.2.2 MLME-SCAN.confirm (for example) are different in handling variable lengths. The latter includes NumberOfPiconets to describe how many PiconetDescriptionSet fields are specified. The former does not have such a parameter for the "NumberOfPSStructureSet" to specify how many PSStructureSet fields are specified.


Comment:
The xrefs in 6.7.x.x that point to table 41 do not work


Comment:
PLME-TESTMODE.request and Table 32 have a PHY dependent rate in Mb/s. Perhaps this should be the index approach used elsewhere in the standard. That is, 11 - 55 Mb/s as 0-4


Comment:
The text has PSPS and SPS mode and then relates the first IE announcement to be in a system wake beacon. For SPS, system wake beacon is not listened to.
Also, for longish system wake beacon intervals, waiting for the system wake beacon may impact performance of the piconet. Perhaps this should be up to the PNC do determine if it can wait (the system wake beacon is only a superframe or so away).

SuggestedRemedy:
fix the text to eliminate SPS from this text.
Change the text on waiting for system wake beacon.


Comment:
Other specifications of management attibutes typically call out not only the static vs. dynamic nature but also include the characteristic of "read", "write", and read/write. This standard should apply this to all PIB tables in clauses 6 and 11.


Comment:
The MLME-SCAN primitive parameters descriptions point to remote scan in 7.5.6.4. This is correct in that remote scan does have the descriptions and that the local activity (local to the MLME rather than the over-the-air remote scan) isn't defined. However, there should be a mention that this is the case.

SuggestedRemedy:
Add a sentence to 8.2.1 scanning to note the local and the remote.


Comment:
[PM] Small changes to support new TrgtID field in the PS Mode change command.

SuggestedRemedy:
Add parameter TrgtId to MLME-PS-MODE-CHANGE.request. Add TrgtId to table 29, page 84: TrgtId, Integer, as defined in 7.5.7.1.


Comment:
[General] The "When generated" and "Effect of reciept" sections tend to be redundant with the description of the actions in clause 8. It might be better to remove these from clause 6 and merge any non-redundant information into the appropriate places in either clause 8 or clause 9 (for security related stuff).  That way Clause 6 just describes the interface.

SuggestedRemedy:
Remove these subclauses throughout 6.3 (and perhaps other parts of 6) and merge the information into clause 8.


Comment:
[CTR] The text indicates that the MLME-MODIFY-STREAM.confirm primitive is generated when "A channel time response command with reason code set to SUCCESS and a beacon containing the requested stream modification". However, MSC 111 in Clause 8 shows the MLME-MODIFY-STREAM.confirm being generated without the need to see a beacon.

SuggestedRemedy:
Either modify the text in clause 6 to indicate that the beacon is not required or change the MSC in clause 8 (figure 117).


Comment:
The capability field has been split into two parts so change this table and the primitives to match.

SuggestedRemedy:
Change "Capability field" to be "PNCCapability" and "DEVCapability" as separate entries, each with Type and Valid range "As defined in 7.4.12" and descriptions "The capabilities of the DEV when acting as a PNC." and "The communication capabilities of associating DEV.", respectively.


Comment:
Please change this sentence frag.: <from> "...for either a specific PNID or any PNID..." <to> "...for either a specific PNID/BSID or any PNID/BSID..."


Comment:
Add the comment that all frames are transmitted in the order that they are received on a per-stream basis with the exception of Dly-ACK frames which can get out of order on both the transmit and the receive side.

SuggestedRemedy:
Add much better text that says the same thing.


Comment:
You can't really tell if it was an independnet piconet, so change the enumeration in the scan confirm.

SuggestedRemedy:
Change to "Dependent" and "Non-Dependent".  Check to make sure that this is OK with other sub-clauses in 6.3 that may reference this (i.e. check the pdf for the xref number to the section and table).
Also, check to see if there is a need to keep the independent piconet description.  If not, delete it from everywhere.


Comment:
Change this sentence frag.: <from> "0-the maximum..." <to> "0 to the maximum..."


Comment:
Please change this sentence frag. : <from> "...by the MLME as a result of a..." <to> "... by the MLME upon receiving a..."


Comment:
Eliminate the clause heading because it really should be a sentence under clause 6.3.12.1.


Comment:
[ASIE] OUI may be same for several calls to MLME-CREATE-ASIE.request Even if not, it's easier to call with an index when you want to remove  the IE.

SuggestedRemedy:
Add parameter to MLME-CREATE-ASIE.request: "ASIE-index", integer type, range is application specific.


SuggestedRemedy:
Add parameter to MLME-CREATE-ASIE.confirm: "ASIE-index", integer type, range is application specific.


Comment:
Please change this sentence frag. <from> "The various entitles within..." <to> "The various entities within..."


Comment:
PLease change this sentence frag. <from> "...more beacons or the terminate..." <to> "...more beacons or to terminate ..."


Comment:
Please change the "CTA-Type" type <from> Boolean <to> Enumeration.


Comment:
Delete the floating "h"  from the first column of the "MinNumTUs" row.


Comment:
Change this sentence frag. <from> "...transfer of an asynchronous MAC from one..." <to> "...transfer of asynchronous data from..."


Comment:
[ASIE] OUI may be same for several calls to MLME-CREATE-ASIE.requestEven if not, it's easier to all with an index when you want toremove  the IE.

SuggestedRemedy:
Add parameter to MLME-CREATE-ASIE.request:"ASIE-index", integer type, range is application specific.


Comment:
[ASIE] OUI may be same for several calls to MLME-CREATE-ASIE.requestEven if not, it's easier to call with an index when you want toremove  the IE.

SuggestedRemedy:
Add parameter to MLME-CREATE-ASIE.confirm:"ASIE-index", integer type, range is application specific.


Comment:
In clause 6 a request for a regular scan includes a ChannelScanDuration parameter that defines the requested length the scan should be performed.  However, the corresponding MLME-REMOTE-SCAN.request contains no such parameter.  How is the DEV receiving the remote scan request command to decide how long each channel should be scanned?  For that matter, should there be some minimum time each remotely scanned channel should be scanned, or is 1 usec sufficient?


Comment:
The table defines a parameter named "CapabilityField" with a "Type" and "Valid range" shown to be "As defined in 7.4.12", yet 7.4.12 defines two fields named "DEV capabilities" and "PNC capabilities".

SuggestedRemedy:
Replace the Table 9 parameter name "CapabilityField" with "DEVCapabilities" (leave Type, Value, and Description entries as they are). 
Replace the Table 9 parameter name "SupportedDataRates" with "PNCCapabilities" and change the Description field to "The PNC operational capability definitions of the DEV that is requesting association with the PNC." (leave Type and Value fields as they are).
Replace the "CapabilityField" parameter of both the MLME-ASSOCIATE.request primitive (6.3.5.1) and MLME-ASSOCIATE.indication primitive (6.3.5.2) with the two parameters "DEVCapabilities" and "PNCCapabilities".


Comment:
The intent of the standard is to not specify the DME or the FCSL layers. Yet, by including the sections nameed "When generated" for request and response primitives of the MLME SAP and MAC SAP, the standard is describing actions suposedly performed by the DME and FCSL layers. Likewise, by including the sections named "Effect of receipt" for indication and confirm primitives of the MLME SAP and MAC SAP, the standard is describing actions performed by the DME and FCSL layers. The MLME SAP and MAC SAP should be defined in terms of MLME and MAC functionality only.

SuggestedRemedy:
For any "request" or "response" primitive defined in Clause 06, remove each subclause titled "When generated" to remove any reference to DME or FCSL functionality. For any "indication" or "confirm" primitive defined in Clause 06, move any text from the "Effect of receipt" subclause that actually describes MLME or MAC functionality to the corresponding "When generated" subclause for the primitive, and then remove each subclause titled "Effect of receipt" to remove any reference to DME or FCSL functionality.


Comment:
If a beacon contains a Parent Piconet IE, it is clear that the PiconetType is DEPENDENT. However, it is not clear from a beacon frame alone whether or not a piconet is a PARENT or INDEPENDENT. Furthermore, a piconet can be both a PARENT and a DEPENDENT in which case it is not clear which PiconetType should be reported.

SuggestedRemedy:
Change the valid range of PiconetType in Table 6 and Table 26 (for Remote Scan) to "DEPENDENT, NON-DEPENDENT".


Comment:
Small changes to support new TrgtID field in the PS Mode change command.


Comment:
"Stylistic inconsistencies:  Prescriptive ("shall") and descriptive verbs are used in a mixed way in this clause."

SuggestedRemedy:
"Do not use "shall" in this clause unless warranted.  Instead, use descriptive verbs."


Comment:
Specific definition missing in Table 5 in lines 22 and 31.

SuggestedRemedy:
"Replace "As defined in 7.5.6.4" in line 22 with "The number of piconets found during the scanning process".  Replace "As defined in 7.5.6.4" in line 31 with "Specifies a list of found channels ordered from the best to the worst in terms of interference"."


SuggestedRemedy:
"Replace "or when it" with " when the desired BSID or PNID is found, or when the MLME"."


Comment:
Incorrect parameter range in Table 7 in line38.


Comment:
The second statement in lines 47-48 is not applicable since the MLME/MAC is directed to start a piconet at a SPECIFIC channel.

SuggestedRemedy:
"Delete the statement "If all of the channels for the PHY…set to PICONET_DETECTED."."


Comment:
Incorrect naming and reference in Table 9 in lines13-15 and the following primitives.

SuggestedRemedy:
"Change "CapabilityField" to "OverallCapabilities" in Table 9 and in the parameter lists of the following MLME-ASSOCIATE.request and MLME-ASSOCIATE.indication primitives, and change the corresponding field name "Capabilities" to "Overall Capabilities" in 7.5.1.1.  Also change "As defined in 7.4.12" to "As defined in 7.5.1.1 under "Type" and "Valid range" in Table 9."


Comment:
Incorrect description in Table 9 in lines 20-21.

SuggestedRemedy:
"Change "the PNC is able" to "this DEV is able"."


Comment:
"Incorrect parameter in Table 9 in lines 40-41:  "AssociationStatus" is reported when a DEV receives a beacon containing a DEV Association IE.  However, the DEV Association IE, and hence the "AssociationStatus", does not live up to the intent that any associated DEV can determine the DEVs currently associated with the PNC by having the PNC send a DEV Association IE in the beacon each time a DEV is associated or disassociated.   Namely, any given associated DEV may not be able to determine the DEVs that had associated with the PNC earlier than it did, because that DEV, before associating with the PNC, could have missed the DEV Association IEs broadcasting the association status of those DEVs."

SuggestedRemedy:
"Replace the "AssociationStatus" parameter with an "AssociationList" parameter, where "AssociationList" lists the DEVIDs and MAC addresses of all the DEVs associated with the PNC at the time the corresponding "Association List" IE is broadcast in the beacon, which occurs whenever a  DEV is associated with or disassociated from the PNC."


Comment:
"Incorrect parameter range in Table 9 in lines 50-54:  The actual result of an association request is contained in the "ReasonCode" instead of the "ResultCode"."

SuggestedRemedy:
"Change the "Valid range" of "ResultCode" as follows: RESPONSE_RECEIVED, TIMEOUT.  Change the corresponding "Description" to "Indicates if the association request has received a response or timed out."


Comment:
Incorrect wording in line 10.  Incorrect parameter in line 18.

SuggestedRemedy:
"Change "other associated DEVs" to "an associated DEV".  Replace "AssociationStatus" with "AssociationList"."


SuggestedRemedy:
"Change "disassociates with" to "disassociates from"."


Comment:
Incomplete Description in Table 11 in lines 16-17.

SuggestedRemedy:
"After "used in" add "Authentication Request"."


Comment:
"Incorrect parameter range in Table 11 in lines 51-52:  The actual result of an authentication request is contained in the "ReasonCode" instead of the "ResultCode"."

SuggestedRemedy:
"Change the "Valid range" of "ResultCode" as follows: RESPONSE_RECEIVED, TIMEOUT.  Change the corresponding "Description" to "Indicates if the authentication request has received a response or timed out." "


SuggestedRemedy:
"After "there is no" add "authentication".  Replace "shall" with "is" (2 occurrences).  Change "SUCCESS" to "RESPONSE_RECEIVED"."


SuggestedRemedy:
"After "challenge" add "request".  Replace "an associated DEV" with "the security manager of the authentication relationship"."


SuggestedRemedy:
"Replace "shall" with "is" (2 occurrences).  Change "SUCCESS" to "RESPONSE_RECEIVED"."


Comment:
Incomplete parameter list in lines 26-29.


SuggestedRemedy:
"Replace the paragraph as follows:  Upon receipt of the MLME-REQUEST-KEY.indication with the ResultCode set to SUCCESS, the DME issues an MLME-REQUEST-KEY.response to the MLME."


SuggestedRemedy:
Replace line 4 as follows: with the ResultCode set to SUCCESS.


Comment:
Incomplete ResultCode Value range in Table 13 in lines 27-28.


SuggestedRemedy:
"Move "TrgtID" to the beginning of the parameter list."


SuggestedRemedy:
Create a subclause to define the MLME-SECID-UPDATE.confirm primitive.


Comment:
Stylistic inconsistency in Table 16 in line 28.


SuggestedRemedy:
"Change "device" to "DEV" (2 occurrences)."


Comment:
Parameter misnaming in Table 17 in lines 5-6.


SuggestedRemedy:
"Create a new row as follows:  NewPNCDEVAddress, MAC address, Any valid individual MAC address, The DEV address of the DEV being requested to assume PNC responsibilities.  Create another new row as follows:  HandoverCountdown, Integer, 0-NmbrHndOvrBcns-1, The number of beacons the old PNC will transmit before control of the piconet is turned over to the new PNC.  Create yet another row as follows:  NumberOfCTRBs, Integer, 0-255, The number of CTRBs, excluding requests for asynchronous channel time, currently being serviced by this PNC.  Create one more row as follows:  NumberOfSPSSets, Integer, 0-255, The number of SPS sets currently being serviced by this PNC."


Comment:
Parameter misnaming and parameter missing in lines 32-38.

SuggestedRemedy:
"Rename "PNCCapableDEVID" to "NewPNCDEVID", and after this parameter add "NumberofDEVs,"."


SuggestedRemedy:
"After "handover" add "request", and replace "a PNC" with "the specified PNC"."


SuggestedRemedy:
"After "NumberOfDEVs," add "NmbrHndOvrBcns," and "DEVInfoSet,"."


SuggestedRemedy:
Rephrase the first statement as follows:  This primitive informs the originating DME that its request to initiate a PNC handover is complete.


SuggestedRemedy:
"Add the following parameters in the parentheses:  NewPNCDEVID, NewPNCDEVAddress, HandoverCountdown."


Comment:
Ambiguous Valid range for ResultCode in Table 19 in lines 23-25.

SuggestedRemedy:
Clarify in 6.3.15.4.2 what result would correspond to a ResultCode of DENIED.


SuggestedRemedy:
"After "security information" add "about the DEV specified by the QueriedDEVID as" and change "that DEV" to "the DEV of TrgtID"."


SuggestedRemedy:
"Change "CREATE" to "UPDATE" and "Create" to "Update" throughout this clause."


SuggestedRemedy:
"Change "informed of" to "informed that", delete "either", add "if" before "ResultCode = SUCCESS", and add "if" before "ResultCode = FAILURE"."


Comment:
Incomplete Valid range and Description in Table 21 in line 13.

SuggestedRemedy:
"Fill the InfoElementList/Valid range entry with "As defined in 7.4."  In the next entry on the same row, after "information" add "elements"."


Comment:
Incorrect parameter list in lines 25-30.

SuggestedRemedy:
"Remove "InfoElementMap," and 'ProbeTimeout" from the list as they do not the .indication primitive."


SuggestedRemedy:
"Change "the list of information elements requested" to "the request for the list of information elements"."


Comment:
Incomplete Description in Table 22 in lines 34-40.

SuggestedRemedy:
"In the MinNumTUs row, after "number of TUs" add "per CTA".  In the DesiredNumTUs row, after "number of TUs" add "per CTA".  In the AvailableNumTUs row, delete "Either" and after "number of TUs" add "per CTA"."


Comment:
"Incorrect parameter range in Table 22 in lines 47-50:  The actual result of a request is contained in the "ReasonCode" instead of the "ResultCode".  How is a ResultCode of FAILURE generated?"

SuggestedRemedy:
"Change the "Valid range" of "ResultCode" as follows: RESPONSE_RECEIVED, TIMEOUT.  Change the corresponding "Description" to "Indicates if the request has received a response (an ACK in the case of stream termination) or timed out." "


Comment:
"Ambiguous Description in lines 6-7:  What is "the target of the MLME.request" in the case of a side-stream, the PNC or the non-PNC DEV on the other side of the stream? "


SuggestedRemedy:
Create new subclauses to define MLME-CREATE-STREAM.indication and MLME-CREATE-STREAM.response primitives.


SuggestedRemedy:
"After "CTR-TU," add "Priority," to the parameter list."


SuggestedRemedy:
Create new subclauses to define MLME-MODIFY-STREAM.indication and MLME-MODIFY-STREAM.response primitives.


SuggestedRemedy:
"Before "ResultCode" add "ReasonCode," to the parameter list."


SuggestedRemedy:
Create a new subclause to define an MLME-TERMINATE-STREAM.indication primitive.


SuggestedRemedy:
"Move "either" to in between "DME" and "after"."


SuggestedRemedy:
"After "OrigID" add to the parameter list ", MeasurementWindowSize, TXFrameCount, RXFrameCount, RXFrameErrorCount, RXFrameLostCount"."


SuggestedRemedy:
"After "DEV" add "and performing the requested channel measurement"."


Comment:
Stylistic inconsistencies in lines 30-33.

SuggestedRemedy:
"Capitalize "x" (4 occurrences) in the parameter list."


Comment:
"Miss specific description for "NumberOfPiconets"

SuggestedRemedy:
"NumberOfChannels", and "ChannelRatingList" in Table 25 in lines 14,20, 23.","Revise the Description for "NumberOf Piconets" as follows: "As defined in 7.5.6.4" with "The number of piconets found during the scanning process".  Revise the Description for "NumberOfChannels" as follows:  "The number of channels scanned."  Revise the Description for ChannelRatingList" as follows:  "Specifies a list of channels from the best to the worst in terms of interference."


Comment:
Incorrect reference in Table 25 in line 15.  There is no need to define a new set of PiconetDescription just for remote scanning purposes.


Comment:
Redundant Table --Table 26:  There is no need to define a new set of PiconetDescription just for remote scanning purposes.

SuggestedRemedy:
Delete Table 26 and adjust the numbering for subsequent tables accordingly.


Comment:
Missing parameters from the parameter list in lines 6-8.

SuggestedRemedy:
"After "ChannelList," add to the parameter list all the parameters that appear in the next primitive, MLME-REMOTE-SCAN.response."


SuggestedRemedy:
"After "PNC" add "and performing or denying the requested remote scan"."


Comment:
Incorrect and unnecessary statements in lines 26-29.

SuggestedRemedy:
"Delete the statements beginning from "If unsuccessful" to "on its behalf.".  Also note that the parameter "REQUEST_DENIED" is contained in the "ReasonCode" but not the "ResultCode"."


Comment:
Incomplete Description in Table 27 in line 14.


Comment:
Inconsistent naming in Table 28 in line 17.


Comment:
Inconsistent naming in the parameter list in lines 35-36.

SuggestedRemedy:
"Change "TxPowerChangeValue" to "TXPowerChange" and "TxPowerChangeTimeout" to "TXPowerChangeTimeout"."


Comment:
Inconsistent naming in the parameter list in line 8.


Comment:
"Incorrect wording:  The words "PS modes" in this draft sometimes means power save (PS) modes only and sometimes means power management (PM) modes which include ACTIVE mode."

SuggestedRemedy:
"Change "PS mode" to "PM mode", "PS modes" to "PM modes" and "PS-MODE" to "PM-MODE" throughput this subclause, including the tables therein. "


Comment:
Unspecific Valid range and Description in Tables 29 and 30.

SuggestedRemedy:
"Replace "As defined in…" with specific valid range or description."


Comment:
Naming inconsistencies:  The names of some parameters in Tables 29 and 30 and the following primitives are different from those of the corresponding fields defined in 7.5.7 for the related commands.

SuggestedRemedy:
"Throughout 6.3.24, change 'PSSwitchOperation" to "NewPMMode", "PSSetOperation" to "OperationType", "PSStructureSet" to "PSSetStructureSet" (this change is especially essential since it means a set of sets), "DEVIDMapLength" to "BitmapLength", and "DEVIDMap" to "DEVIDBitmap"."


Comment:
Incorrect Valid range in the first row of Table 29:  HIBERNATE is one of the PS modes.

SuggestedRemedy:
"Either delete "HIBERNATE," or expand "PS" into "SPS, PSPS"."


SuggestedRemedy:
Create new subclauses to define MLME-PS-SET-INFORMATION.indication and MLME-PS-SET-INFORMATION.response primitives.


SuggestedRemedy:
Create new subclauses to define MLME-PS-SET-CONFIGURE.indication and MLME-PS-SET-CONFIGURE.response primitives.


SuggestedRemedy:
Create a new subclause to define an MLME-PM-MODE-CHANGE.indication primitive.


SuggestedRemedy:
Replace the first statement as follows:  The DME is informed of the PM mode change to ACTIVE.


SuggestedRemedy:
"Replace "As defined in…" with specific definition."


Comment:
Missing mode in Table 35 in lines 35-36.

SuggestedRemedy:
"Under "Octets Definition" add "0x02 = mode 2"."


Comment:
Incorrect Description in Table 39 in lines31-32.

SuggestedRemedy:
"Change "Data portion of the MSDU" to "MSDU portion of the primitive"."


SuggestedRemedy:
"Change "asynchronous MAC" to "asynchronous MSDU"."


SuggestedRemedy:
"Change "MSDU" to "MPDU" and "media" to "medium".  Change "with an error" to "with the ResultCode set to INVALID_ACK_POLICY"."


SuggestedRemedy:
"Delete "due to a transmission timeout"."


SuggestedRemedy:
"Change "due to either" to "either due to", and before "or" add "because".  Before "policy" add "ACK"."


SuggestedRemedy:
"Change "MSDU" to "MPDU" and "media" to "medium".  Rephrase the statement containing "as a stream source"."


Comment:
The low end of the PS wake beacon interval should be 2 and not 4.


Comment:
The capability field format is one of several fields that has no provision for extension. Allow this field to be extended without breaking implementations. Impacts 7.5.1.1, 7.5.4.2, and 7.4.12 at a minimum.

SuggestedRemedy:
Add a mechanism to allow the graceful growth of capabilities including the DEV and PNC capabilities of 7.4.12


Comment:
The standard lacks a 7.4.xx that is similar to 7.5.8.1. This would call out the structure of vendor IEs.

SuggestedRemedy:
Add a sub-clause after 7.19 patterned after 7.5.8.1


Comment:
Widen the column in the figure for ATP so it fits on one line.


Comment:
The membership status octet in the DEV info field uses 8 bits to represent a single bit. The remainder should be stated as reserved. The octet should take on a new name so that the 7 reserved bits may take on function distinct from the membership status.


Comment:
A 2 bit field for protocol version seems limited. Propose the use of 3 bits. Currently, 00 is current, 01 could be for a revision PAR, 10 for TG3a add-ons. This only provides a single additional revision for the life of the standard.

SuggestedRemedy:
change the protocol version field as requested


Comment:
The remote scan response lacks the possible PHY specific growth with the fixed fields of the format.

SuggestedRemedy:
Provide a mechanism to allow additional fields to be reported on channel rating that may be used by an Alt-PHY.


Comment:
[PM] Some attempts have been made to create a wakeup signal from a DEV to a sleeping peer DEV. A simple addition to the PS mode change command can cause the PNC to set the PCTM bit for a sleeping DEV.

SuggestedRemedy:
Add one octet to PS Mode change command: TrgtID  TrgtID is set to the SrcId if the DEV wants to inform the PNC that it's switching to the ACTIVE MODE. If the TrgtID is set to the DEVID of another member DEV, the PNC will set the bit for this DEV in the PCTM IE. If the PS Mode field is set to Hibernate or PS, this field shall be ignored upon reception.


Comment:
The words "...RF medium," might be better worded.

SuggestedRemedy:
I suggest "...wireless medium," or WM; from Clause 4.


Comment:
Why are only 48 bit DEV addresses supported?   802.15.4 supports 64 bit addresses as well.


Comment:
[CTR] The description of minimum number of TUs is ambiguous.

SuggestedRemedy:
Add a paragraph that says "The minimum number of TUs and the desired number of TUs are the number of TUs per CTR interval requested by the DEV.  In the case of a super-rate allocation, it is the number of TUs requested in each superframe.  In the case of a sub-rate allocation it is the number of TUs requested in each of the sub-rate superframes. For example, a request for a minimum number of TUs of 4 with a sub-rate CTR interval of 4 indicates that the DEV is requesting 4 TUs every fourth superframe.


Comment:
[PS] The definition of the wake beacon interval is misleading or at least potentially confusing.  A wake beacon interval of 4 indicates that the DEV is requesting wake beacons every 4th superframe.  Thus there are 3 non-wake beacons and non-wake superframes between each wake beacon.

SuggestedRemedy:
Change the description to "The wake beacon interval is the number of superframes, including the current one, between wake beacons, {xref 8.13}. For example, a wake beacon interval of 8 indicates that the DEV is requesting a wake beacon every 8th beacon."


Comment:
The wake beacon interval should be allowed to be as low as 2 for both SPS and PSPS.  In the case of PSPS, the PNC can always ignore the request.  In the case of SPS requests, the PNC should honor the request if possible.

SuggestedRemedy:
Change the lower ranges of '4' here to be '2' and fix all other occurances in clauses 6, 7 and 8.


Comment:
The text describing the two different modes of asynchronous allocation is confusing here.  It would be better if we could adopt names for the two modes, I suggest "group allocation" for the case when the CTAs will be overlapping in the superframe and "individual allocation" when the CTAs will be separate.  Thus there would be "asynchronous group CTRs (and CTAs)" and "asynchronous individual CTRs (and CTAs)"  Alternatively we could use "overlapping" and "non-overlapping"

SuggestedRemedy:
Change the text here and throughout to use "group" and "individual" (or other appropriate name) for the two types of asynchronous allocations.


Comment:
65535 isn't a valid wake beacon number and we haven't specified how to encode 65536.  Likewise, 256 should be allowed for PSPS requests.

SuggestedRemedy:
Either define value 0=65536 or change this to a 1-octet field with each value representing the power of two, i.e. a value of 3 indicates 2^3=8, and the value 0 represents 2^16=65536.  Alternatively, encode the octet as 2^(n+1), thus a value of 3 is 2^(3+1) = 16.


Comment:
The description of the max burst size for Dly-ACK could be improved.

SuggestedRemedy:
Add a clarification "Thus, this indicates the maximum number of frames the source DEV may send before it requests a Dly-ACK from the destination DEV."


Comment:
[ASIE] OUI may be same for several calls to MLME-CREATE-ASIE.request. Consequently, it may be necessary to add an ASIE index to both the ASIE and to the MLME-CREATE-ASIE.request/confirm primitives.


Comment:
[ASIE] OUI may be same for several calls to MLME-CREATE-ASIE.request. Consequently, it may be necessary to add an ASIE index to the Vendor specific  command just after the Vendor OUI field.


Comment:
[PiconetService] Seems there is a need for an MLME-PICONET-SERVICES.indication/response set of primitives.   During association a DEV can set its PiconetServiceInquiry bit to request a list of piconet services from the PNC.  The response to the services request bit is independent of the association response.  Also I'm assuming that since the Services database is not managed by the MAC or MLME, that the PNC DME or some other protocol layer needs to receive some sort of notification that a request for services information has been received.  Consequently, the current description of the piconet services functionality is incomplete and not acceptable.

SuggestedRemedy:
Add the missing MLME primitives regarding piconet services or delete all references to piconet services.


Comment:
[PiconetService] Clause 8.3.2, P175,  describes the passing of piconet service IEs via the probe command.  Consequently, why is the piconet services command specified? Please delete this command form clause 7.


Comment:
[FrmFrmt] Figure 7 (Frame payload) and Figure 8 (Secure payload) indicate two different types of payloads, yet only the secure payload is partially described .

SuggestedRemedy:
Add a definition for the frame payload field.  Also, add information to the secure payload definition to clarify the difference between the Frame payload and the secure payload.


Comment:
[FCS] Change this sentence frag.: <from> "...treated as a polynomial, multiplied by ..." <to> "...treated as a polynomial, is multiplied by ..."


Comment:
[PNC] Why are the parameters Max Tx Power, Max CTRBs, MaxAssociatedDEVs not part of the PNC capabilities field?  Especially since these parameters are identified in figure 60 on page 167 as being important parameters for deciding whether a DEV is better able to be a PNC than another DEV.

SuggestedRemedy:
Please make these changes:  
1) P 137, Figure 50, delete the parms(MaxTxpower, MaxCTRBs, and MaxAssociatedDEVs) from figure 50.  Increase the octet length of the PNC capabilities field from 1 octet to 4 octets.
2) Move the DEV capabilities field to a position between the PNC capabilities field and the ATP field.   The PNC capabilities field will now be first.  The fields now will be in the priority order illustrated in Figure 60 on page 167.


Comment:
[PNC] The PNC capabilities illustrated in figure 41 are in an order inconsistent with that illustrated in Figure 60 page 167.  Consequently, I recommend that the parameters be reoranized to this pattern:PSRC|SEC|PNC Des-mode|PNC capable|reserved|Neighbor PNC|.  In addition, I recommend that three more octets be added to the left end of figure 41, with these parameters:|MaxTxPwr|MaxCTRBs|MaxAssociatedDEVs|
Also modify figure 39 so that the PNC capabilities field length is now four octets and the Length field of the IE is increased from 2 to 5.


Comment:
Change this sentence frag.: <from> "The RX error frame count is ..." <to> "The RX frame error count is ..."


Comment:
Move the PS mode change command clause to just after the PS configuration response command and move the PS set information request command to just before the PS configuration request command.  The reason for this request is to make the order of the commands consistent with the order specified in clause 6.3.24 for these MLME primitives: MLME-PS-SET-INFO, MLME-PS-SET-CONFIGURE, MLME-PS-MODE-CHANGE.


Comment:
Change this sentence frag. <from> "The CAP command bit applies..." <to> "The CAP commands bit applies..."


Comment:
Change this sentence frag. <from> "When the piconet is is ..." <to> "When the piconet is..."


Comment:
Change this sentence frag. <from> "...as illustrated in Table 50." <to> "...as illustrated in Figure 50."


Comment:
Change this sentence frag. <from> "...in the piconet to an any other DEV..." <to> "...in the piconet to any other DEV..."


Comment:
[CTA/Term] Delete the Terminate bit from b3 and then shift all bit assignments right one position so that b7 is now reserved.  The terminate bit is redundant. And as we all know: "Redundancy is evil"  In addition, delete the sentence at line 12 which describes the termination bit, since it is no longer needed.


Comment:
[PiconetService] Delete this clause since there is no need for the piconet services command now that the probe command is fragmentable.


Comment:
Comment on BSID.  The standard specifies, for a closed scan, that the DEV/PNC should search for a beacon with a specified PNID and BSID. “If open scan is not specified, the DEV shall ignore all received frames not matching the PNID and BSID parameters contained in the request.” (8.2.1).  The placement of the BSID (in an IE) is late in the beacon and not in a constant location.  "The IEs in the beacon payload may appear in any order except for the channel time allocation (CTA) IEs" (7.3.1.1) This implies the BSID IE could appear anywhere after the CTA IEs, even in the beacon extensions.  The MAC needs confirmation the beacon is correct before using the data.

SuggestedRemedy:
The BSID should be included in the sequence of fields in a specific order, immediately following the piconet synchronization parameters.  The BSID should be early in the beacon, and in a specified location to facilitate fast filtering of undesired beacons.  The BSID is included in the IEs because it is a variable length field, but its nature is that of a piconet parameter.   Currently, other IEs may occur in the beacon before the BSID IE.  This forces a MAC to begin decomposing the information from the beacon before it is possible to confirm the beacon is the correct one.  The MAC does have the opportunity to check the PNID early in the beacon, but PNIDs may be duplicate.  The probability that a PNID is duplicate is low, but it will happen some of the time and the use of BSID to verify the beacon before use lowers the probability of error further.


Comment:
[Bitorder] The current text and figure will be very informative if you just make a vertical flip of the picture. That is, draw the transmission order arrow from left to right and flip the figure so that Octet 0 is to the left.This is no change in bitorder. The only result is that you see the picture the same way as a text field is put in a memory buffer. This will make more sense to most people!


SuggestedRemedy:
Remove 'stream termination', pack all fields to the right and let b7 be reserved.


Comment:
[Stream] The terminate bit no longer exists.

SuggestedRemedy:
Delete the sentence "The stream termination field...".


Comment:
[PNC_Scan] You cannot always tell from a beacon if the PNC _is_ a parent, only if it _has_ a parent.

SuggestedRemedy:
Change piconet type codes to:0 -> Independent or parent piconet1 -> Dependent piconet2-255 -> Reserved


Comment:
Should have a brief section describing vendor specific IEs in clause 7.4.  That section should then be reference in the appropriate places, eg, Table 51


Comment:
I suspect the intent here is to say the wake beacon can occur no more frequently than every fourth beacon.  What is actually said is that the wake beacon can occur no more frequently than every fifth beacon because wake beacon interval is specified as the number of superframes *between* wake beacons.   If this was not what was intended then the wording must be changed.  If, on the other hand, what was said is what was meant, then the wording should probably also be changed to avoid the ambiguity.


Comment:
It should be explicitly stated that in all cases when the target ID list type field value is set to 0, all previous async allocations are replaced.  The current wording doesn't say this.


Comment:
The CTRB's CTR interval field is currently unused for async requests.  It should probably be put to use.  A couple of possibilities are suggested below.  Other uses may also be useful.

SuggestedRemedy:
1)  One possibility is that for async CTRBs, the CTR interval type field be required to be 0 (super-rate), and the CTR interval field be interpreted in the usual super-rate fashion.
2)  Another possibility is to use the CTRB's CTR interval field to encode the maximum amount of time the requestor can use during any single superframe.


Comment:
There should be a cross-reference to 11.2.10 (D15p315L42-44) in the part of 7.3.1.1 that talks about the CAP association, CAP command and CAP data bit fields in the piconet mode field of the piconet parameters field of the beacon (D15p116L6-14).

SuggestedRemedy:
I suggest adding the text "and 11.2.10" at the end of the sentence at D15p116L14.


Comment:
There is no text in the standard that indicates that a DEV should ignore a frame received which contains a PNID other than the PNID of the piconet that the DEV has synchronized with. Even a DEV that is not yet associated and/or authenticated knows what the PNID should be because DEVs synchronize to a piconet based on PNID.

SuggestedRemedy:
Add the following sentence to the end of the identified paragraph:
"If a DEV receives a frame from a PNID other than the PNID of the piconet with which the DEV is synchronized, it shall ignore the received frame."


Comment:
The last sentence in this paragraph states that: "Valid values for the wake beacon interval for either the PSPS or SPS ranges are in powers of 2 (e.g. 2, 4, 8, ...)." However, the previous sentence states that "The wake beaconinterval shall have a value between 4 and 255 for PSPS and between 4 and 65535 for SPS."
The values "255" and "65535" are not powers of 2. As currently written, the maximum allowed intervals for PSPS and SPS would be 128 and 32768 respectively. If the values 256 and 65536 were intended for the maximum interval values, then there is an additional problem that the value 65536 can not be expressed with only 2 octets.

SuggestedRemedy:
Change:
"The wake beacon interval is the number of superframes between wake beacons, 8.13. The wake beacon interval shall have a value between 4 and 255 for PSPS and between 4 and 65535 for SPS. Valid values for the wake beacon interval for either the PSPS or SPS ranges are in powers of 2 (e.g. 2, 4, 8, ...)."
To:
"The wake beacon interval is the number of superframes from one wake beacon to another, 8.13. Valid values for the wake beacon interval for either the PSPS or SPS ranges are in powers of 2 (e.g. 2, 4, 8, ...). Furthermore, the wake beacon interval shall have a value between 2 and 256 for PSPS and between 2 and 65536 for SPS. Because the value 65536 can not be represented with 2 octets, a wake beacon interval of 0 shall represent the interval value 65536."


Comment:
By including the security suite OID IE in the association response command, the length of the command is unnecessarily lengthened by one byte.

SuggestedRemedy:
1) Replace the "Security suite OID IE" field in this figure with 2 new fields. The first named "Security suite OID Length" with a field length of "1", and the second named "Security suite OID" with a length of "Ln". Change the definition of the Length field for the command from "Length(=10+Ln)" to "Length(=11+Ln)". 
OR
2) Replace the "Security suite OID IE" field in this figure with field named "Security suite OID block" with a field length of "1+Ln". Change the definition of the Length field for the command from "Length(=10+Ln)" to "Length(=11+Ln)". Add a new figure which defines "Security suite OID block" as two fields. The first field named "Security suite OID" with a length of "1" and the second field "Security suite OID" with a length of "Ln".


Comment:
The information element "Continued wake beacon" is missing from this table.

SuggestedRemedy:
Add Continued wake beacon to the table after information element PS status and complete the table appropriately for this IE.


Comment:
The definition of the Max frames field is not clear and is open to interpretation.

SuggestedRemedy:
Change:
"The max frames field indicates the maximum number of frames, regardless of size, that may be sent in a burst."
To:
"The max frames field indicates the maximum number of frames, regardless of size, that may be sent before requesting a Dly-ACK from the DEV receiving the frames."


Comment:
The length of the Piconet services field is unneccessarily restricted to 127 octets when the IE could support a Piconet services field length of 252.

SuggestedRemedy:
Change the definition of the Piconet services field from "octets:(0-127)" to "octets:(0-252)" and change "Length=3 to 130" to "Length=3 to 255".


Comment:
SPS Wake Beacon Intervals need further restriction.

SuggestedRemedy:
Each wake beaccon interval should be unique in value and allocation.


Comment:
SPS Interval range is inconsistent with the diagrams in 8.13.

SuggestedRemedy:
Either allow the range to go to 2 or qualify the figure as having a not allowed value for illustration purposes.


Comment:
[PM] Some attempts have been made to create a wakeup signal from a DEV to a sleeping peer DEV. A simple addition to the PS mode change command can cause the PNC to set the PCTM bit for a sleeping DEV. New sublause 8.13.x Waking up a DEV in power save mode

SuggestedRemedy:
The PNC may request that a DEV in power save mode switches to ACTIVE mode after its next wake beacon. In this case, the PNC shall set the bit for the DEV it wants to wake up in the PCTM IE. The bit shall be set to 1 until the power save DEV informs the PNC that it's switching to ACTIVE mode by sending the PS Mode change command with the PS Mode field set to ACTIVE and the TrgtID field set to it's own DEVID.  A power save DEV that wakes up and finds its bit set in the PCTM shall switch to ACTIVE mode and remain ACTIVE for at least the CTRResponseTime indicated in the beacon.  A DEV may request that the PNC sets the PCTM bit for another DEV by sending the PS Mode change command with the PS Mode field set to ACTIVE and the TrgtID field set to the DEVID of the peer DEV it wishes to wake up.


Comment:
Though I agree with the goal of limiting the response time to a probe command, I believe there are problems with the proposed mechanism.
The mProbeResponseDelay (8 ms) response time requirement will often be impossible to meet.  For example, if the original probe command comes at the end of the CAP, the superframe duration is 65 ms, and no MTSs are provided, in the best case the responder will miss the response deadline by 58 ms.  And I'll assert superframe durations much longer than 8 ms will be common.  This is a serious flaw in the response timeout mechanism and calls the whole response timeout mechanism into question.
An aside:  The last sentence (p203L46-48) says to add required channel backoff time.  Does it mean add it to the time between retransmitting an ACK'd probe command, or does it mean add it to the time the target DEV has before it must respond to the probe?  If it's the latter, then the probe source DEV has no way of knowing what the required channel backoff time of the target DEV will be.  This ambiguity should be cleared up.


Comment:
What does "… PNC is not able to support the requested priority" mean in the context of an isochronous stream?  What this means should be explicitly stated.


Comment:
This part of isoc stream allocation should be explained better in 8.5.1.1.  Bullet two (p188L24-25) says set the available number of TUs below the minimum requested.  The intent is that when not enough time is available this is to be interpreted as the amount of time that was available.  The text should explicitly say this.


Comment:
Figures 137, 138, and 139 all show wake beacon intervals of two.  But the PS configuration request command (D15p157L41-42) specifies four as the lowest valid value.  This inconsistency should be corrected.


Comment:
To make clear that a BIFS should be waited before resuming backoff countdown whenever the channel transitions from busy to clear during the CAP, the following text should replace the three sentences in D15p179L7-11.
"Whenever the channel is busy, the backoff counter shall be suspended.  The medium shall be determined to be idle for the duration of a BIFS period before backoff slot countdown is resumed.  When the backoff counter reaches zero, the DEV shall transmit its frame."


Comment:
The sentence in D15p181L30-31 should be replaced by "In any individual superframe, the PNC may allocate more dynamic CTA time than the amount indicated in the channel time response command."  This clarifies we're only talking about dynamic CTAs here.


Comment:
D15 is a little unclear about what should happen when the backoff counter value drawn during the backoff procedure is zero - can the DEV transmit immediately without waiting any BO slots, or does it have to wait at least one BO slot anyway?  I've heard both views expressed by knowledgeable people.

SuggestedRemedy:
To clarify, add the following text after the last sentence on D15p179L11:  "When a backoff count of zero is drawn the DEV can transmit immediately following the channel having been idle for a BIFS."


Comment:
D15p178L16-22 talks about checking to verify there is enough time remaining in the CAP to complete the current frame exchange sequence before starting that exchange sequence when the backoff counter decrements to zero.  It says "Hence, once a DEV decrements its backoff counter to zero, it shall check ...".  Rather than waiting until the backoff counter decrements to zero to do the check, the check should be performed when the backoff countdown is first begun, immediately after drawing the backoff count.
In addition, this check should also be performed whenever a suspended backoff countdown is resumed (as specified in D15p179L13-14 which also reverences D15p178L17-22).  To be clear, D15p178L17-22 should also mention these two cases.


Comment:
D15 says (p180L19-21), "If PNC sees the usage of the new allocation by both the source of the destination of old allocation before the expiration of aMaxLostBeacons number of superframes, then the PNC may reuse the old allocation for another pair of DEVs."  However, what constitutes "usage" is ambiguous.  Does usage mean "sees a transmission from the DEV"?  And if so, does transmitting an ACK constitute "usage"?  Or does usage mean "transmits a PDU"?   Note that just because a DEV ACKs a transmission doesn't necessarily mean it knows about the pseudo-static CTA change.  This is because the DEV could have dropped recent beacons (and therefore not know about the CTA change) but always be listening and so have received and ACK'd the directed frame despite not knowing about the CTA change.

SuggestedRemedy:
Resolve these ambiguities by replacing the ambiguous term "usage of the new allocation" with the unambiguous phrase "transmission of a PDU during the new allocation".


Comment:
When D-Ack is used it will likely be impractical for the destination DEV to maintain MSDU order (ie, the order in which the MSDUs were delivered to the source DEV's FCSL) when delivering the MSDUs to the destination DEV's FCSL.  This should be explicitly stated somewhere in 8.8.3 and in D15p200L15-16 in 8.7.


Comment:
The paragraph does not clearly state when the backoff counter should be resumed. The paragraph also contains unnecessary commentary.

SuggestedRemedy:
Change from:
"The DEV shall then choose backoff_count = bw_random(retry_count) and shall maintain a counter for backoff_count which is decremented only when the medium is idle for the entire duration of pBackoffSlot. The retry_count shall be set to 0 for the first transmission attempt of a frame. Whenever the channel is busy, the backoff counter shall be suspended. This avoids the problem of unfair channel access when a backoff counter of a DEV ending in the middle of a reception and hence resulting in larger backoff for that DEVwhile another DEV starting after the current reception choosing smaller value for backoff. When the backoff counter reaches zero, the DEV shall transmit its frame."
To:
"The DEV shall then choose backoff_count = bw_random(retry_count) and shall maintain a counter for backoff_count which is decremented only when the medium is idle for the entire duration of pBackoffSlot. The retry_count shall be set to 0 for the first transmission attempt of a frame. Whenever the channel is busy, the backoff counter shall be suspended. The channel shall be determined to be idle for the duration of a BIFS period before the backoff slot countdown is resumed. When the backoff counter reaches zero, the DEV shall transmit its frame."


Comment:
The sentence "The association process does not wait for the piconet services command to complete." can result in problems. For example, if the association process completes before the PNC transmits the piconet services command, the newly associated dev would not receive the command because the command is addressed to the UnsssocID and not the associated DEVs newly aquired DEVID.

SuggestedRemedy:
Change:
"If the DEV sets the piconet services inquiry bit, the PNC shall send the piconet services command, 7.5.4.6, with DestID set to UnassocID. The association process does not wait for the piconet services command to complete."
To:
"If the DEV sets the piconet services inquiry bit, the PNC shall send the piconet services command, 7.5.4.6, with DestID set to UnassocID before it allocates a DEVID to the associating DEV via the association response command."


Comment:
The purpose for returning rhe available number of TUs is not clear.

SuggestedRemedy:
Change bullet text from:
"The available number of TUs field shall be set to a value less than the minimum number of TUs requested."
to:
"The available number of TUs field shall be set to a value less than the minimum number of TUs requested. This value represents the number of TUs the PNC could have allocated."


Comment:
Figure references non-existent MLME primitives

SuggestedRemedy:
Change instances of "MLME-INIT" to "MLME-START"


Comment:
It is not clear how the PNC obtains a DEVID for the purpose of data communication with other members of the piconet.

SuggestedRemedy:
Add text similar to below to clause 8.2.2:
"A PNC should consider itself a member of the established piconet and should allocate a DEVID to itself for the purposes of exchanging data with other DEVs that may become members of the established piconet."


Comment:
In the current draft, if devices do not yet share a key, these use the broadcast key. This creates a false sense of security.

SuggestedRemedy:
Suggested remedy: correct this violation of proper security policy.


Comment:
"Table 68, row 3, column 3:  Text ends with "If the SECID"."


Comment:
A PNC may allow several authentication security suites.

SuggestedRemedy:
Update the second to last sentence to read: "Within a piconet, the PNC shall choose the security suites that will be used by all DEVs for authentication with the PNC."


Comment:
The fact that the rest of the data exchanged as part of the protocol is not protected allows spoofing of certain information relating to the piconet.  All of this data should be included in Text1 and Text2.

SuggestedRemedy:
Text1 and Text2 should include the rest of the data exchanged during the authentication protocol.


Comment:
What does it mean that validation of an implicit certificate is "outside the scope of this standard?"

SuggestedRemedy:
Either specify how to validate an implicit certificate, or point to a reference that does so.


Comment:
Are those frame headers available to the DME process which is computing this integrity code?


Comment:
The NTRUEncrypt X.509 certificate verification type references RFC3280 which indicates "Identification and encoding of public key materials and digital signatures are not included in this specification, but are now described in a companion specification [PKIXALGS]". PKIXALGS is documented in RFC3279 (April 2002). However, RFC3279 only includes OIDs for RSA, DSA, Diffie-Hellman, KEA, ECDSA, and ECDH algorithms, not NTRUEncrypt.

SuggestedRemedy:
Remove clauses 10.4.2.2, 10.4.2.3, 10.4.2.5, and all other references to use of NTRUEncrypt used as a public key algorithm for certificates.


Comment:
The inclusion of two security suites to handle 80-bit strength security has not been justified in the draft. In addition, the NTRUEncrypt 251-1 algorithms have been recently modified to correct flaws in algorithms originally presented to the 802.15.3 committee as "secure" algorithms. Since this algorithm does not have a strong record of secure products in the industry, it should not be included as one of the recommended security suites in the 802.15.3 standard.

SuggestedRemedy:
Remove all references and usage of the NTRUEntrypt 251-1 security suite and sub-suites from the draft. Delete line 16 in table 94, delete line 34 in table 95, delete clause 104 starting at line 44 on page 299 until line 27 on page 303, change text on lines 10-12 on page 367 from "the NTRUEncrypt 251-1 security suite provides 80-bit security and the RSA-OAEP 1024-1 security suite provides 80-bit security. Some guidance on the estimated bit-strengths of AES, ECC, NTRU and RSA may be found in IEEE Std P1363-2000, [B2] and [B7]." to "and the RSA-OAEP 1024-1 security suite provides 80-bit security. Some guidance on the estimated bit-strengths of AES, ECC and RSA may be found in IEEE Std P1363-2000, [B2] and [B7].", on page 396, table E.5 remove all references to NTRUEncrypt 251-1 sections of the draft as optional security items (items S2.2, S4.4, S4.5, S4.6, S4.7, and S4.8), lines 14-15 on page 3 (references), line 28 on page 133 (move other items up on list), line 52 in Table 55 on page 146 (move last item up), and line 30 in Table 56 on page 147 (move last item up).


Comment:
The OIDs used in this standard all have the same prefix of 9 bytes. The OIDs can therefore be encoded more economically, by only encoding the sub-strings hereof that may differ. Thus, the OIDs for security sub-suites, currently encoded using 10 bytes, can be encoded using 2 bytes only. In fact, one could encode these sub-suites using an even more compact representation, by enumerating the OIDs for the sub-suites and encoding the corresponding integers as binary strings (this would allow encoding of OIDs as 1-byte strings). The current encoding is extremely wasteful.

SuggestedRemedy:
adopt the efficient encoding of OIDs proposed above and do away with the current wasteful encoding.


Comment:
The changes to the NTRUEncrypt primitive in Clause 10.4 constitute far more than guarding against the padding scheme attack. This suggests that NTRUEncrypt is not robust.

SuggestedRemedy:
One should have credible evidence that NTRUEncrypt, as defined in this D14 draft specification, is robust, including independent confirmation of the claimed security level, both for the cryptographic primitive, the padding scheme, and the key establishment protocol around it. Failure to do so shall result in the removal of the security suite.


Comment:
The NTRUEncrypt Security Suite should be complete and specify domain parameters, security parameters, and scheme options (see EESS #1, Draft 5). Some of these items are missing, such as the wrapping tolerance, message padding method, private key space, and key generation primitive.

SuggestedRemedy:
Completely specify the NTRUEncrypt security suite.


Comment:
The PHYPIB has the RSSI and LQI as a parameters yet these values are parameters in either PHY-RX-START.ind or PHY-RX-END.ind.


Comment:
As part of building Channel Time requests, the PHY specific parameters for elements that consume channel time should be part of the PHY-PIB. This includes SIFS, MIFS, PHY header duration, and preamble length.


Comment:
It is presumed that the DME should have the values of rates for the PHY to allow calculation of CTRs. The PHY-PIB should have a list of actual rates cooresponding to the indexed data rate that the MAC relates to the PHY for each frame sent.


Comment:
The range list in table 140 mentions DEVID and range. The PHY would not normally understand DEVID however. Perhaps an additional parameter list that provides the DEVID values to the PHY. Even though this is implementation specific, the standard should not suggest a crossover of the layers.


Comment:
Change the PHY preamble to be 12 CAZAC sequences to allow more time for the AGC to settle.

SuggestedRemedy:
Change from 10 to 12 here and in figure 197


Comment:
The pBackoffSlot should include the SIFS time as well based on the definition in clause 8.

SuggestedRemedy:
Change pBackoffSlot to be pCCADetectTime + pPHYSIFSTime


Comment:
Collecting channel status for each source DEV in the piconet will add a substantial burden to any simple DEV and it will provide questional benefits.  Any DEV using ImmACK or Del-ACK will know if the frames are getting through.  A DEV should be able to respond that it doesn't provide channel response statistics.

SuggestedRemedy:
Add the following sentence:  A measurement window size of zero indicates that the responding DEV does not provide channel status statistics


Comment:
Do rx and frame counts include retransmissions?

SuggestedRemedy:
Clarify that retransmissions are not included in tx and rx transmission counts.


Comment:
Increase the synchronization field in the piconet synchronization parameters field to 14 octets to keep it 16 bit aligned.

SuggestedRemedy:
Add an 8 bit reserved field to the piconet synchronization parameters field to make is 16 bit aligned.  This impacts Figure 11, Figure 12 and figure 15.


Comment:
Field name "ATP" unnecessarily spans two lines.

SuggestedRemedy:
Increase the size of the cell containing "ATP" such that the word fits on one line.


Comment:
The benefit of the more data bit in a data frame is questionable.  Just because you don't have another frame to transmit when you start one frame doesn't mean you won't have one by the time you finish transmitting.  Also, if you have to retransmit because an ACK wasn't received the receiver may not be listening if more data wasn't set. The use of more data is not described in clause 8 except for beacon frames.

SuggestedRemedy:
Change this paragraph to The more data bit shall be set to 1 when the PNC is sending an extended beacon, 8.6.2. It shall be set to 0 otherwise and may be ignored.


Comment:
Early on, the power save text had a separate mode called reduced power save, wher a DEV didn't listen to slots (excuse me, CTAs) that were not assigned to him.  At the time we decided that DEVs only ever listen to slots that are explicitly assigned to them.
I now believe there is a case where it would be bemenficial to have DEVs that listen to all channel time regardless of the destination ID.   Some have raised the issue of the ability to do statistical multiplexing between various streams effectively.  There are some complicated ways to do this, but there is a simple way: have DEVs that are not power sensitive listen to all channel time, regardless of the assigned destination DevID.

SuggestedRemedy:
Add a capability bit to the PNC capabilities field (OK, this is not the best place for it but there are reserved bits) called "receive always."  A DEV transmitting to another DEV that has the "receive always" bit set can send frames to that DEV in any CTA assigned to the transmitting DEV, regardless of the destination DEVID of the CTA.


Comment:
the description of the FCS field is completely unclear. It is unclear whether the provision of a CRC check and the verification hereof are inverses of one another: conversion between bit strings and polynomials and encoding/decoding procedures lack clarity and precision. Moreover, statements as 'in the absence of transmission errors …' (Page 114, line 2) lack meaning.

SuggestedRemedy:
replace the text by an unambiguous and clear description of the encoding/decoding procedures.


Comment:
One can save 1 byte in each MAC header, by encoding information for the Fragment Control Field differently. The current encoding is unnecessarily wasteful. Suggested remedy: The Frame Control Field consists of 3 bytes, including the last fragment number, say N (7 bits), the current fragment number, say i (7 bits). Obviously, one has 0 £i£N. One uses the natural ordering of fragments: 0,1,2,3,...,N. Since, if a frame is lost in a stream, the whole stream is discarded, one can use the following more economical encoding for the Fragment Control Field: (a) Fragment number, say i (7 bits);  (b) Indication as to whether a fragment is the first one (1 bit). Natural ordering of fragments: N,N-1, N-2, ..., 2, 1, 0. The 1-bit indicator (b above) indicates whether one is dealing with the first frame in a fragmented message or not. If so, one knows that the corresponding frame number is the highest one to expect. Then one just counts down. Note that the fragment number i now indicates the number of fragments one still has to receive.  Adopting this encoding would save 6 bits compared to the current encoding. Moreover, one does not need to firmly now the total frame size in advance, only an estimate. So, accidental out-of-order receipt of the first fragment does not really hurt. The Frame Control Field (Clause 7.2.1) has 5 reserved bits. The Fragment Control Field (Clause 7.2.4, with my suggestion) would have 7 reserved bits. Combining both the frame and the fragment control field and pooling reserved bits would yield 12 reserved bits. It seems reasonable to cut down this number of reserved bits by 1 byte (12 ® 4 reserved bits), thus cutting down the total number of bytes that has to be communicated in EVERY frame header (thus in every frame) by 1, from 10 to 9 bytes. Suggested remedy: Change the draft in line with the more economical representation given above and adapt all impacted text.

SuggestedRemedy:
The Frame Control Field consists of 3 bytes, including the last fragment number, say N (7 bits), the current fragment number, say i (7 bits). Obviously, one has 0 £i£N. One uses the natural ordering of fragments: 0,1,2,3,...,N. Since, if a frame is lost in a stream, the whole stream is discarded, one can use the following more economical encoding for the Fragment Control Field: (a) Fragment number, say i (7 bits);  (b) Indication as to whether a fragment is the first one (1 bit). Natural ordering of fragments: N,N-1, N-2, ..., 2, 1, 0. The 1-bit indicator (b above) indicates whether one is dealing with the first frame in a fragmented message or not. If so, one knows that the corresponding frame number is the highest one to expect. Then one just counts down. Note that the fragment number i now indicates the number of fragments one still has to receive.  Adopting this encoding would save 6 bits compared to the current encoding. Moreover, one does not need to firmly now the total frame size in advance, only an estimate. So, accidental out-of-order receipt of the first fragment does not really hurt. The Frame Control Field (Clause 7.2.1) has 5 reserved bits. The Fragment Control Field (Clause 7.2.4, with my suggestion) would have 7 reserved bits. Combining both the frame and the fragment control field and pooling reserved bits would yield 12 reserved bits. It seems reasonable to cut down this number of reserved bits by 1 byte (12 ® 4 reserved bits), thus cutting down the total number of bytes that has to be communicated in EVERY frame header (thus in every frame) by 1, from 10 to 9 bytes. Suggested remedy: Change the draft in line with the more economical representation given above and adapt all impacted text.


Comment:
the non-secure beacon frame format has no sequence number associated with it, whereas the secure beacon frame format does. A similar remark applies to Imm-ACK (Clause 7.3.2), command frames (Clause 7.3.3), and data frames (Clause 7.3.4).


Comment:
the non-secure Immediate ACK Frame Format does not contain a FCS, which is incompatible with practice with all other frame formats.


Comment:
The piconet controller should indicate in its piconet mode field (see Figure 13) the security policy the piconet adheres to. Currently, it only indicates whether security is ON or OFF, but this does not sufficiently indicate other security characteristics, such as the minimum bit-security level at which access control in the piconet is arranged. This information, in the current D15 draft contained in the Security Requirements Field (see Table 54), logically belongs in the piconet mode field and should be moved there.

SuggestedRemedy:
Change the Draft D15 text to accommodate for this sound security policy principle and adopt impacted text, both in Clause 7.3.1.1 and in Clause 7.5.2.2. See also the discussion in document 02/364r2.


Comment:
In Table 54, bit b1 shall be set to 0 if the piconet intends to operate at (at least) the 80-bit security level and to 1 if the piconet intends to operate at the 128-bit security level.


Comment:
One can save 1 byte in the public-key object by listing sequence numbers in decreasing order and reserving the first bit of the sequence number field to indicate whether one received the first fragment of the public key or not. The current encoding is wasteful (see also comment on encoding of Fragment Control Field).


Comment:
One can save 1 byte in the public-key object by combining the public-key object type and the sequence number in 1 byte. Note that if, e.g., the number of public-key fragments is at most 8 (allowing keys of size <16k bits), this would still allow for up to 32 public-key types. The current encoding is wasteful.

SuggestedRemedy:
adapt the public-key object format in line with the comment above.


Comment:
The public-key object types should distinguish between X509 certificates for the RSA-OAEP and the ECQMV security suite, since not doing so would block the use of 'lazy evaluation' techniques.


Comment:
If 'ACL info handover' is enabled, only the so-called 'manual certificate modes' of the supported security suites shall be used, since implementing this ACL transfer mode is sufficient for continuing the smooth operation of the piconet in the event of a PNC handover. All the other presently defined modes in Draft D15 miss a proper justification and should be removed.

SuggestedRemedy:
Remove all verification information formats that do not represent these so-called 'manual certificates'. Moreover, completely remove the following clauses: Clauses 10.3.2.2-10.3.2.3, Clauses 10.4.2.2-10.4.2.5, and Clauses 10.5.2.2-10.5.2.5.


Comment:
Table 56, Clause 7.5.4.4: The security suite is encoded using a 5-bit field and as an OID in Clause 10. This is inconsistent.

SuggestedRemedy:
Use the OID to indicate the security suite. This also removes the need to define verification information types, since this is implied by the OID of the security sub-suite.


Comment:
The description of the implementation of ACL transfer should not impose constraints on how the ACL transfer modes are represented in memory. Since this is the sole role of applying the SHA-1 function to public-keying material in this ACL transfers (the occasional bandwidth savings are negligible over time), this compression function shall not be specified, by lack of justification.

SuggestedRemedy:
completely remove all Clauses that refer hereto.


Comment:
The use of URLs shall be banned. We are talking about MAC/PHY functionality here! No justification is given at all (and I can honestly not think of one).


Comment:
The request key response command should return all the keys that are shared with the requesting device, including information on the group of devices the key is shared with. Currently, no freshness is provided either.


Comment:
The NTRUEncrypt security suite is not scalable (since it does not have a sub-suite using certificates). According to Annex C, only scalable solutions would be implemented with this standard. S.

SuggestedRemedy:
specify a sub-suite of the NTRUEncrypt security suite using certificates. Failure to do so shall result in removal of the NTRUEncrypt security suite altogether.


Comment:
Some attempts have been made to create a wakeup signal from a DEV to a sleeping peer DEV. A simple addition to the PS mode change command can cause the PNC to set the PCTM bit for a sleeping DEV.


SuggestedRemedy:
"Change "PNID, e.g. the SID is different, it will" to "PNID but a different BSID, it shall"."


Comment:
The final statement of the first paragraph contradicts with its previous statement.


Comment:
"Stylistic consistencies in Table 53:  Some command names end with "command" and some do not."


SuggestedRemedy:
"Delete "either".  Change "by the DEV" to "by a DEV"."


Comment:
Redundant statements in lines 3-4 as they are covered by lines 29-30 of page 136.

SuggestedRemedy:
Delete the second and third statements from the first paragraph.


Comment:
"Confusing naming in Figure 49 and the following text in lines 9 and 14:  There is already a "Capability" information element, and here there are a "Capabilities" field, a "DEV Capabilities" field, and a "PNC Capabilities" field."

SuggestedRemedy:
"In Figure 49 change "Capabilities" to "Overall Capabilities" and in lines 14-15 change "The capabilities" to "the Overall Capabilities".  Also change "CapabilityField" in clause 6.3.5 and Table 9 to "OverallCapabilities"."


SuggestedRemedy:
"Change "inquiry field" to "inquiry subfield"."


Comment:
Stylistic inconsistencies in lines 24-33.

SuggestedRemedy:
"Change "Channel is" to "Channel", "PNC is" to "PNC", "change is" to "change", and "hand over is" to "handover"."


SuggestedRemedy:
"Change "ATP has" to "ATP", "Channel is" to "Channel", and "PNC is" to "PNC"."


SuggestedRemedy:
"In Figure 4, after "OID Length" add "(=L sub m)".  In the following text, define "Length", "OID" and "OID Length" fields."


SuggestedRemedy:
"After "num targets field" add "in the CTRB"."


Comment:
Confusing naming in Figure 69 and the following text in lines 15 and 27.

SuggestedRemedy:
"Change "Capability" to 'Overall Capabilities" (2 occurrences).  Make the corresponding changes in 7.5.1.1."


SuggestedRemedy:
"Delete "DEV-1", "DEV-2", and "DEV-m" from Figure 71, and add "1", "2", or "m" after each "ACL record".  In line 16 change "The ACL record" to "A given ACL Record"."


Comment:
"Ambiguous definition for the "Sequence Number" field in line 14."

SuggestedRemedy:
Rephrase the definition as follows:  The Sequence Number field specifies the number of frames that have been sent prior to this frame by this DEV in the response to the request.


Comment:
"Confusing naming and incorrect encoding of the fields in the Probe Command.  Also it is not worth going through the encoding specified by Figure 75, which, in fact, would not fit with the case of binary encoding of an information element's ID (the ID is 8 bits long, while the Elements requested subfield has 31 bits."

SuggestedRemedy:
"Rename the field name "Information elements" to "IEs Provided" and "Information request" to "IEs Requested" (m octets) in this subclause and in 8.9.2.  Delete Figure 75 and the paragraph immediately about it.  Replace the four paragraphs immediately below Figure 75 with the following paragraph:  The IEs Requested field specifies the Element IDs of the information elements requested by this DEV, with each Element ID occupying one octet."


Comment:
Incorrect table title for Table 57 and Table 58 in lines 1 and 27.

SuggestedRemedy:
"In the title of Table 57 change 'probe requests" to "requests in Probe Commands". In the title of Table 58 change "sending probe requests" to "requesting or sending"."


Comment:
Incorrect wording in Table 57 and Table 58.

SuggestedRemedy:
"In the first row of Table 57 change "received" to "receiving" (3 occurrences).  In the first row of Table 58 delete "allowed to request" (2 occurrences) and "sends" (2 occurrences)."


SuggestedRemedy:
"Change "or with asynchronous data traffic" to "or asynchronous bursts"."


Comment:
Ambiguous naming:  CTR could be interpreted as either channel time request as defined in 7.5.5.1 or channel time response as defined in 7.5.5.2.

SuggestedRemedy:
"Rename "Channel time request command" to "Channel Time Allocation (CTA) Request Command" and "Channel time response command" to "Channel Time Allocation (CTA) Response Command".  Change "channel time request block (CTRB)" to "Channel Time Allocation Request Block (CTARB).  Change "CTR" to "CTA request" throughout the draft.  In fact, part of the draft (like 8.5) already uses "CTA"."


Comment:
"Incorrect article use in line 40, line 151."

SuggestedRemedy:
"Change "a isochronous" to "an isochronous"."


Comment:
"Ambiguous statement in lines 15-16:  What is an "ACTIVE channel time allocation" and what is an "SPS (not just PS?) channel time allocation"?"


SuggestedRemedy:
"Rename "CTR type" to "Power Type" throughout the draft."


SuggestedRemedy:
"Rename "CTR interval type" to "Rate Type" and "CTR Interval" to "Rate" throughout the draft."


SuggestedRemedy:
Delete the last statement of the 3rd paragraph.


SuggestedRemedy:
"Change "RF medium" to "wireless medium"."


SuggestedRemedy:
"Rename "pMaxFrameSize" to "pMaxFrameBodySize" throughout the draft."


Comment:
This MAC does not accommodate VBR streams well.

SuggestedRemedy:
"Use b11-b13 for a non-PNC DEV to request additional channel time for transferring remaining buffered data of the stream to which this frame belongs, when this frame is the last frame sent by this non-PNC DEV in the current superframe."


Comment:
Inaccurate Description in Table 43 in line14.

SuggestedRemedy:
"Change "the information" to "a Dly-ACK frame"."


SuggestedRemedy:
"Change "successful authentication protocol" to "successful authentication procedure"."


SuggestedRemedy:
"After "MAC frame" add "Body" and change "frame" to "Frame"."


Comment:
Wording missing in lines 35 and 37.  This causes ambiguity in the case of secure frames.

SuggestedRemedy:
"Before "payload" add "Frame" and change "payload" to "Payload"."


Comment:
"Stylistic inconsistencies in line 42, page 115."


SuggestedRemedy:
"After "allowed" add "in the current superframe"."


Comment:
"Wording missing in lines 15-16, page 116."

SuggestedRemedy:
"After "association MCTAs" add "in the current superframe"."


Comment:
Stylistic inconsistencies in Table 45 in line 18.


Comment:
Stylistic inconsistencies in Table 46 in line 18.


Comment:
Stylistic inconsistencies in Table 47 in line 32.


Comment:
"Incorrect definition for "Burst" and hence for "Max Burst" in lines 50-51:  Suppose five frames of consecutive sequence were transmitted but the second and fourth frames were not correctly received.  The "burst" should include the third frame, even though this frame was correctly received, because the third frame would most likely be still sitting in the receive buffer in waiting for the missing second frame and hence occupied the receive buffer space--which the 'Max Burst" field was to indicate."

SuggestedRemedy:
"Redefine the "Max Burst" field accurately."


Comment:
"Ambiguous specification in line 50:  What does "frames of pMaxFrameSize" mean?  Practically, the recipient DEV has to assume that the frames to be sent are of maximum allowable size in setting the value for the Max Burst field."


Comment:
Unwarranted field:  The Max Frames field provides no more information than the Max Burst field.

SuggestedRemedy:
Delete the Max Frames field and all references to it.


Comment:
Stylistic inconsistencies in Table 48 in line 31.


SuggestedRemedy:
"Change "either set to" to "set to either"."


SuggestedRemedy:
"After "command block" add "and an FCS field"."


Comment:
"Confusing naming: "Data" is already used to denote frames of type "Data", and now is also used to designate the frame payload of Data frames."

SuggestedRemedy:
"Rename "Data" to "MSDU Payload" whenever it references the "Data" field of a Data frame."


Comment:
"Confusing naming: "Data" is further used to represent the information field of information elements!."

SuggestedRemedy:
"Rename "Data" to IE Payload" whenever it references the "Data" field of an IE."


SuggestedRemedy:
"After "highest value" add "being the"."


Comment:
"Confusing definition in line 32: Do not use the word "associated with" since it already has a special meaning.  Also, the channel time may be used by the DEV to send data from other streams than indicated by the Stream Index, as specified in Clause 8."

SuggestedRemedy:
Rephrase the statement as follows:  The Stream Index indicates the stream to which the channel time is allocated.  The allocated DEV may use this channel time to send data belonging to other streams when this allocated stream has no more data to send.


Comment:
"This IE does not serve the purposes it was intended for.  The DEVs "newly" associated with the PNC and announced via this IE would not necessarily be known to DEVs that are associated later on (i.e., after the announcement of this IE."

SuggestedRemedy:
"If this IE is to enable any given DEV associated in the piconet to be aware of all the other DEVs associated in the same piconet, rename it to "Association List" and redefine it such that it covers all the associated DEVs."


Comment:
"Incorrect specification:  How could a PCTM IE sent in a beacon make a HIBERNATE DEV switch to ACTIVE mode, given that the PNC has no definite knowledge of when that DEV is going to enter the AWAKE state?"


SuggestedRemedy:
"Change "about certain characteristics of the CTAs" to "of certain characteristics of an allocated CTA"."


SuggestedRemedy:
"Change "the destination for this stream" to "this allocated CTA", and "the source for this stream" to "this allocated CTA".  Change "stream allocation" to "stream"."


SuggestedRemedy:
"Change "the first CTA of the new or modified stream will be allocated" to "this allocated CTA will first appear."."


SuggestedRemedy:
"Change "PNC capability" to "PNC Capabilities"."


SuggestedRemedy:
"Change "that is" to "indicating" (2 occurrences)."


Comment:
"The current TX power" is actually referencing the "Current TX Power" field, but is not obvious at all without appropriate Capitalization."

SuggestedRemedy:
Capitalize the first letters of the words forming proper names throughout this draft!


SuggestedRemedy:
"Change "DEVID shall be set to one when a DEV" to "DEV shall be set to one when the DEV"."


SuggestedRemedy:
"Change "reserved IDs" to "reserved DEVIDs"."


Comment:
"Ambiguous definition in lines 20-29, page 152:  The word "CTA" is used to mean both a single CTA and a collection of CTAs."

SuggestedRemedy:
"Rephrase these two paragraphs as follows:
The Rate Type field is set to 0 for a subrate CTA request and 1 for a superrate CTA request.  A subrate CTA request indicates a need for a CTA every N superframes where N > 1, while a superrate CTA request indicates a need for N CTAs in every superframe where N = 1 or N > 1.
The Rate field specifies the value of N referenced in the last paragraph.  For a subrate CTA request, the Rate field value shall be a power of 2.  A PNC shall support up to eight CTAs per superframe for each stream."


Comment:
Ambiguous definition for the Target ID List Type field in lines 36-38:  What is the additional information conveyed by this field?  Does an asynchronous CTA request not always replace a previous asynchronous request?

SuggestedRemedy:
Delete the Target ID List Type field and the paragraph defining it.


Comment:
Ambiguous definition for the CTR time unit in lines 40-42.

SuggestedRemedy:
"Change "for its request" to "for the CTA(s) it is requesting".  After "units of CTA" delete "time".  After "allocate" change "CTA time" to "CTAs".  Delete the next statement "It also…"."


SuggestedRemedy:
"Change "per CTR interval" to "per CTA", and "the requested stream" to "the specified isochronous stream"."


Comment:
Ambiguous definition in lines 5-6:  How would this command be responded when the DestID is set to the BcstID?

SuggestedRemedy:
Describe the response or delete the statement.


SuggestedRemedy:
"Change "FCS calculation" to "FCS validation"."


SuggestedRemedy:
"After "fragmentation" add "Control" and capitalize "F"."


SuggestedRemedy:
"Rename "Remote piconet description set" to "Piconet Description Set"."


SuggestedRemedy:
"Rephrase the statement as follows:  If the request is denied, then the Command shall include only the Command Type, Length, and Reason fields."


SuggestedRemedy:
"Change "channels indices" to "channel indices"."


SuggestedRemedy:
"Expand Figure 86 to define "Piconet Description" such that it covers all the parameters (fields) listed in Table 6."


Comment:
"Incorrect wording in line 1, page 156."

SuggestedRemedy:
"Change "and shall" to "each of which shall"."


Comment:
"Incomplete definition in line 16, page 156."

SuggestedRemedy:
"Change "in a frame" to "in a non-beacon frame"."


Comment:
"Incorrect naming:  As noted by this commenter earlier, the term "PS mode" is used to mean  "PM mode" (power management mode), which includes ACTIVE mode and other modes (i.e., PS modes), and truly PS mode."

SuggestedRemedy:
Change PS to PM (power management) when it references all power management modes.


Comment:
Incomplete naming in Figure 88 and the following sentence.

SuggestedRemedy:
"In Figure 88 (and in 8.1) change "PS mode" to "New PM Mode".  Rephrase the following statement as follows:  The New PM Mode specifies the PM mode the non-PNC DEV is requesting to change to."


Comment:
"Incorrect range for the "PS mode" field:  HIBERNATE is one of the PS modes."

SuggestedRemedy:
"Either delete "Hibernate mode" or expand "PS mode" into "SPS mode" and "PSPS mode"."


SuggestedRemedy:
"Change "PS set structure 1" to "PS Set 1 Structure", and "PS set structure n" to "PS Set n Structure"."


SuggestedRemedy:
"Change "number PS set structures" to "Number of Supported PS Sets", and "The PS set structure" to "Each PS set structure"."


SuggestedRemedy:
"Change "non zero value" to "than 0 or 1", and "in this particular SPS set" to "in a particular SPS mode"."


Comment:
"Incorrect statement in line 2, page 160."

SuggestedRemedy:
"Change "a DEVID" to "the corresponding DEV" (2 occurrences)."


Comment:
"States "For a piconet that has pseudo-static CTAs, NbrOfChangeBeacons shall be at least four."

SuggestedRemedy:
Should reference the MAC parameter: mMaxLostBeacons.


Comment:
"Table 53, column 1 is Titled "Command type hex value b31-b0".  This is a 16-bit field."


Comment:
This paragraph (clause) does not clearly specify how dependent piconets are handled during a PNC handover. Is CTRB information for a child piconet transferred to the new PNC? Is the new PNC obligated to determine where the CTA for the child piconet should go even though CTA information is not transferred to the new PNC? Is CTRB information for a neighbor piconet transferred to the new PNC even though the neigher PNC is not a member of the piconet that is being handed over? Is the new PNC obligated to determine where the CTA for a neighbor piconet should go even though CTA information is not transferred to the new PNC?


Comment:
Will the beacon of the new PNC have a psuedo-static CTA for each dependent piconet in the same location as the previous PNC? How is this done if CTA information is not transferred from the old PNC to the new PNC?


Comment:
The sentence beginning with "If a child or 802.15.3 neighor piconet has the same superframe duration as the parent," is confusing because all dependent piconets have the same superframe duration as their parent piconet.


Comment:
A requirement for maintaining synchronization in dependent piconets is missing from this section. If the change type is set to size, then a dependent piconet must also change the size of the private CTA for the parent piconet at the appropriate time.

SuggestedRemedy:
Add the following sentence to the paragraph: "Furthermore, if the change type is set to SIZE, a dependent PNC must change the length of the private CTA used to reserve time for the operations of the parent piconet in the first beacon it broadcasts in the parent superframe of the new superframe size."


Comment:
LB 12 resolution called for aMinSuperFrameDuration to be changed from 512 usec to 1 msec. This change didn't get edited in.


Comment:
LB 12 called for a change to aAssocConfirmTime from 5 ms to 4*aMaxSuperframeDuration. This was missed in editing.


Comment:
With the introduction of MIFS is the need to change additional figures and text that show SIFS for additional frames within a CTA that do not have Imm-ACK or Dly-ACK.

SuggestedRemedy:
Change figure 107 to use MIFS.
Change additional figures and text elsewhere to include MIFS.


Comment:
For transmit power control, the word "fixed" in the text of 8.11.2 and the use of fixed in 8.11.2.1 subclause title is misleading since the PNC may change the max power level (and the text of 8.11.2.1 discusses this).

SuggestedRemedy:
remove the word "fixed" in the text of 8.11.2 and in the subclause title.


Comment:
Remove the SIFS from the guard time calculation since it is already present in the CTA makeup.


Comment:
Add an xref to line 11 to point to the changing nature of pseudo-static CTAs with regard to mFirstCTAGap.
Also use mFirstCTAGap instead of aFirstCTAGap.


Comment:
Fragmentation threshold sounds as if it were a reserved name. Change the text to help the reader. Also be clear that the "threshold" is not a MAC global value.


Comment:
Need to add reference to table 61 in the text. 
Also, the text is a bit redundant with the contents of table 61 so it doesn't read real well.


Comment:
text has aMinFragmentSize. It should be pMinFragmentSize. This is a leftover editing omission it would seem.


Comment:
Change text to "...MSDU/MCDUs including streams, asynchronous data and commands.


Comment:
Why is it necessary to have an exchange if no further IE exchanges are to take place


Comment:
between 8.9.2 and 8.15 mProbeResponseDelay, it would seem that 8 ms is not appropriate. It can't be accomplished considering either lack of CTA, contention in CAP (although line 46-47 deals with that case) or open MCTA, or just that this is typically less than a superframe. Is this another parameter we agreed to change and that didn't make it in editing?

SuggestedRemedy:
Change to be 4*mMaxSuperFrameDuration in 8.15 but in 8.9.2 provide a "should"  that the time should be as short as possible.


Comment:
In figures 129, 127, and 128 show in the key, the meaning of ??.

SuggestedRemedy:
key should indicated that there is content but can be one of several different IEs.


Comment:
Do we want to restrict a CTA to the stream and non data, or allow async data as well.

SuggestedRemedy:
Change the text to indicate "... other than the CTA requested for the destination DEV, ...."


Comment:
Pg 180 ln 43-46 and pg 181 ln 13-19 say the same thing. The pg 180 lines should be deleted.


Comment:
"unless ..." is not desirable. There is no specification of when the MLME should read the PIB parameter and take action. Better is an MLME primitive.

SuggestedRemedy:
retain the PIB to read back the current BSID but add an MLME primitive to change the BSID.


Comment:
The DEVID is mentioned instead of DEV adddress with regard to ACL.


Comment:
Add a sentence on encountering secure beacons and how to report them as part of the scan. Also consider adding an enumeration to the remote piconet description field, scanned frame type of "2 -> The DEV found the PNID in a beacon with a secure frame body"

SuggestedRemedy:
While searhing, if a MAC header indicates that the frame is a beacon and that that the frame is SECmode 1, the frame body parameters of the piconet description are not valid. The piconet shall be counted as part of the NumberOfPiconets.


Comment:
line 30-31, is a shall change base on more than one in same channel.Line 35-36, says "any channel" results in a change

SuggestedRemedy:
change line 30-31 to be for "any channel"


Comment:
[Assoc] How does a PNC meet aAssocRespConfirmTime of 5 ms?  The assoc may be at the end of the CAP or in an association MTS and the PNC may not have any channel time available in 5 ms. or DEV.


Comment:
[Probe] How does a PNC or DEV meet aProbeResponseDelay of 8 ms?  The probe may be at the end of the CAP or in a CTA and the responder may have no available channel time.


Comment:
[PM/SPS-4] Delete this sentence frag.  "... when the PNC is battery powered and support at least four SPS sets when the PNC is powered by the alternating current mains, Table 60."  As Allen Heberling stated in his BRC PM e-mail ballot of 10/29/02 regarding his opposition to making 4 SPS sets mandatory: "...Mr. M. Schrader, on the other hand is advocating 4 SPS sets for an AC powered device. This approach constrains the customer/implementor to having to support a powermanagement scheme that forces the PNC to manage DEV defined wake beacon intervals  for each SPS set instantiation(this has complex implications for the MAC CTA scheduler and Beacon generation algorithms). In addition, it also forces the customer/implementor to implement a MAC that has to support a minimum of 4 SPS sets regardless of whether it is battery powered or AC powered. It is highly unlikely that implementors are going to develop/support two different MAC HW/SW instantiations based on whether one instantiation is going to be in a battery powered environment and one is going to be in an AC powered environment."


Comment:
[PM/SPS-4] Delete MLF23.3  I agree with Allen Heberling, I don't have a problem with making Hibernate, PSPS and 1 SPS set mandatory.  However, I do get heartburn when 4 SPS sets are mandated.  A 15.3 DEV can support up to 252 streams yet we only mandate that a DEV support at least 1 isochronous stream.  We leave it optional as to how many more streams a DEV or a PNC capable DEV may handle.


Comment:
[PM] The requestor cannot hang and wait an indefinite time for a decision from the PNC. Either you get your channel time or you don't. If the destination is in hibernation, any CTR shall be denied. If a DEV wants to know about traffic it can select PSPS or SPS. In Hibernation it just wants to sleep. I would kindly urge all editors to please try to refrain from putting undiscussed ad hoc inventions into the draft. If you really want to wake up a sleeping DEV at some unknown time in the future, we could consider having a new command to set the PCTM bit. One way would be to add a DEVID to PS mode change. If (operation == ACTIVE && dev != UNASSOC) set PCTM(dev)./KO

SuggestedRemedy:
Delete page 221 line 11-16. Replace with: "The PNC shall deny a channel time request if the destination is in HIBERNATE mode. The PNC shall return a channel time response command with the error code set to 'destination in power save mode' (rename error code 7 in 7.5.5.2)


Comment:
[PM] Some attempts have been made to create a wakeup signal from a DEV to a sleeping peer DEV. A simple addition to the PS mode change command can cause the PNC to set the PCTM bit for a sleeping DEV. New sublause 8.13.x Waking up a DEV in power save mode.


Comment:
[PM] Small changes to support new TrgtID field in the PS Mode change command. Editorial: Switching to ACTIVE is the same procedure regardless of PS mode. Maybe lift out to the general clause?

SuggestedRemedy:
8.13.1 page 216 line 12. (for PSPS) 8.13.2.2 page 217 line 31. (for SPS) 8.13.3 page 221 line 7. (for HIBERNATION) Add "with the PS Mode field set to ACTIVE and the TrgtID set to its own DEVID" Change Figure 146, page 224. Add param TrgtID=SrcID to MLME-PS-MODE-CHANGE.req and to PS mode change command.


Comment:
[CTR] Describe the termination procedure better.

SuggestedRemedy:
Change "via a directed channel time response command." to be "via a directed channel time response command, 7.5.5.2, with the reason code set to the appropriate value."


Comment:
It isn't clear what "suspended" means and the paragraph fails to mention that the channel needs to be clear for a BIFS before the countdown begins again.

SuggestedRemedy:
Change "Whenever the channel is busy, the backoff counter shall be suspended.  This avoids the problem of unfair channel access when a backoffcounter of a DEV ending in the middle of a reception and hence resulting in larger backoff for that DEV while another DEV starting after the current reception choosing smaller value for backoff." to be "If the medium is determined to be busy at any time during a backoff slot, then the backoff procedure is suspended; that is, the backoff timer shall not decrement for that slot. The medium shall be determined to be idle for the duration of a BIFS period before the backoff procedure is allowed to resume."


Comment:
For simplicity and to allow DEVs to use more sets, require that SPS wake beacon intervals are unique.

SuggestedRemedy:
Add a sentence that says "Each SPS Set shall have a unique wake beacon interval"


Comment:
The PNC shouldn't handover to a new one if the security policy prevents it, even if the DEV has Des mode set.

SuggestedRemedy:
Add an exception to the text, change "shall perform PNC handover." to be "shall perform PNC handover if permitted by the current security policies."  We probably need to define what is meant by the security policy, probably something like that it is a DME decision and so is outside of the scope of the standard.


Comment:
The current draft does not provide support by the Parent PNC for the handover of the dependent PNC to another DEV in the dependent piconet.  For example, the DEV chosen for handover may not be a member of the parent piconet.  It may not be possible, due to security or physical limitations, for the DEV to join the parent piconet.

SuggestedRemedy:
Fix handover of dependnet PNCs or delete dependnet networks from the draft.


Comment:
The piconet IE may not occur in the first beacon frame or if it does, it might be at the end.

SuggestedRemedy:
Move the piconet IE to the beginning of the beacon since it is so important, like the piconet synchronization parameters.


Comment:
[MISC] mAssocRespConfirmTime is too short at 5 ms.  This has probably been superseded by the PNC responsiveness, so delete it here and everywhere it occurs.


Comment:
[MISC] mProbeResponseDelay is too short at 8 ms.


Comment:
[Assoc]How does a PNC meet aAssocRespConfirmTime of 5 ms?  The assoc may be at the end of the CAP or in an association MTS and the PNC may not have any channel time available in 5 ms.  or DEV


Comment:
[Probe]How does a PNC or DEV meet aProbeResponseDelay of 8 ms?  The probe may be at the end of the CAP or in a CTA and the responder may have no available channel time.


Comment:
[PM/SPS-4] Delete this sentence frag.  "... when the PNC is battery powered and support at least four SPS sets when the PNC is powered by the alternating current mains, Table 60."  As I stated in my BRC PM e-mail ballot of 10/29/02 regarding my opposition to making 4 SPS sets mandatory:  "...Mr. M. Schrader, on the other hand is advocating 4 SPS sets for an AC powered device. This approach constrains the customer/implementor to having to support a powermanagement scheme that forces the PNC to manage DEV defined wake beacon intervals  for each SPS set instantiation(this has complex implications for the MAC CTA scheduler and Beacon generation algorithms). In addition, it also forces the customer/implementor to implement a MAC that has to support a minimum of 4 SPS sets regardless of whether it is battery powered or AC powered. It is highly unlikely that implementors are going to develop/support two different MAC HW/SW instantiations based on whether one instantiation is going to be in a battery powered environment and one is going to be in an AC powered environment."


Comment:
[PM] The requestor cannot hang and wait an indefinite time for a decision from the PNC. Either you get your channel time or you don't. If the destination is in hibernation, any CTR shall be denied. If a DEV wants to know about traffic it can select PSPS or SPS. In Hibernation it just wants to sleep. I would kindly urge all editors to please try to refrain from putting undiscussed ad-hoc inventions into the draft. If you really want to wake up a sleeping DEV at some unknown time in the future, we could consider having a new command to set the PCTM bit. One way would be to add a DEVID to PS mode change. If (operation == ACTIVE && dev != UNASSOC) set PCTM(dev)./KO


SuggestedRemedy:
8.13.1 page 216 line 12. (for PSPS) 8.13.2.2 page 217 line 31. (for SPS) 8.13.3 page 221 line 7. (for HIBERNATION) Add "with the PS Mode field set to ACTIVE and the TrgtID set to its own DEVID" Change Figure 146, page 224. Add param TrgtID=SrcID to MLME-PS-MODE-CHANGE.req and to PS mode change command


Comment:
[MISC] mMinProcessedCTAs does not appear anywhere else in the draft.


Comment:
[MISC] mCHFrameRepeat is a left over from the old handover process and is no longer used.


Comment:
Change the Check Resources symbol <from> "Check Resources" <to> "Resources Available" to make it consistent with Figures 114,115,116. Also delete the "Allocate resources" symbol from the diagram for the same reason.


Comment:
Change the Check Resources symbol <from> "Check Resources" <to> "Resources Available" to make it consistent with Figures 114,115,116.


Comment:
Change this sentence frag. : <from> "...with the piconet starting in the ACTIVE mode." <to> "...with the piconet while in the ACTIVE mode."

SuggestedRemedy:
Please make the requested change to the indicated sentence frag.


Comment:
Change this sentence frag.: <from> "...this persistence shown shall be..." <to> "...this persistence shall be..."


Comment:
Change this sentence frag. <from> "...have enough time to to wait..." <to> "...have enough time to wait..."


Comment:
Please change this sentence frag. <from> "...to determine if the DEVID in the request is..." <to> "...to determine if the DEVAddress in the request is..."


Comment:
[CTA/Isoch] The original purpose of the CTA Status IE got lost! All subrates shall also be announced, regardless of whether the DEV is in PS mode. The DestDEV cannot find the CTR-interval in any other way and it needs it if it wants to go into a PS mode.

SuggestedRemedy:
Add "and of all subrate streams" to the sentence on line 14.


Comment:
[CTA/Isoch] All changed subrates shall also be announced, regardless if the DEV is in PS mode. The DestDEV cannot find the CTR-interval in any other way and it needs it if it wants to go into a PS mode.

SuggestedRemedy:
Always announce CTR-Interval changes. Remove the words "if any DEV is in power save mode" from line 5.


Comment:
[CTA/Term] The terminate bit is an unnecessary and rendundant mechanism for requesting the termination of a stream. Please delete this sentence: "The stream termination field in the CTR..."


Comment:
[MCTA] We need a little better specification on how often MCTA are allocated to assure that the PNCRespTime can be met.

SuggestedRemedy:
Please add this new text, starting after the sentence beginning: "When MCTA are used...": "The PNC shall allocate MCTA assigned to a DEV, open MCTA or both. The frequency of assigned MCTA shall be at least CTRRespTime, as defined in the beacon. If only open MCTA are used, the PNC shall allocate at least one open MCTA per DEV and CTRRestTime. The PNC may reduce the MCTA allocation frequency for power save DEVs, and for DEVs requesting a longer interval between assigned MCTA using the CTR command, 7.5.5.1. Special rules power save DEVs is listed in 8.13.1, 8.13.2.2 and 8.13.3"


Comment:
[PiconetServices] Replace the references to piconet services command in line 5 and 6 with the probe command, since the piconet services command is unnecessary now that the probe command is fragmentable.


Comment:
There are terms like broadcastMCTA and unassigned MCTA in 13 line 185 page.  Are they kinds of MCTA or they mean Open MCTA and Association MCTA, respectively?


Comment:
How can 802.15.3 impose normative behavior on devices that are not 802.15.3 compliant?


Comment:
It appears to me that the concept of a "neighbor" piconet is nearly identical to the concept of a "child" piconet (the difference seems to be that non-802.15.3 piconets are "permitted," although what it appears that is really described here is the CTA. Furthermore, the concept of a "neighbor" piconet is somewhat misleading: a piconet can only be a "neighbor" of one other piconet, and one has to be a parent.

SuggestedRemedy:
I would suggest the 2 behaviors of "child" & neighbor be merged, with the removal of the "neighbor" terminology.


SuggestedRemedy:
Change the first sentence, up to the first comma, to "When the PNC leaves the piconet or when it transfers its PNC functionality to another DEV,..."


Comment:
I must be missing something. Parent PNC's can't hand over to dependent PNCs. Only PNCs provide association. How, therefore can "Max associated DEVs" be a criterion?


Comment:
Never mind previous comment [Comment ID #211] re: Table 60 & Max assocated Devs -if you make it editorial & change to Max Associations.


Comment:
Is PNC handover permitted within dependent piconets? If "yes," should not the handover procedure incorporate the parent piconet? If it weren't permitted, how would, e.g., the new PNC get apprised of the parent PNC's change, if one were to happen? So it would seem that some form of communicability requirement within the dependent piconet is required with the parent PNC ...

SuggestedRemedy:
Please clarify- either explicitly state that such behavior is permitted or forbidden & provide parental PNC approval if permitted.


Comment:
[PM/SPS-4] Delete this sentence frag.  "... when the PNC is battery powered and support at least four SPS sets when the PNC is powered by the alternating current mains, Table 60."  As Allen Heberling stated in his BRC PM e-mail ballot of 10/29/02 regarding his opposition to making 4 SPS sets mandatory:  "...Mr. M. Schrader, on the other hand is advocating 4 SPS sets for an AC powered device. This approach constrains the customer/implementor to having to support a powermanagement scheme that forces the PNC to manage DEV defined wake beacon intervals  for each SPS set instantiation(this has complex implications for the MAC CTA scheduler and Beacon generation algorithms). In addition, it also forces the customer/implementor to implement a MAC that has to support a minimum of 4 SPS sets regardless of whether it is battery powered or AC powered. It is highly unlikely that implementors are going to develop/support two different MAC HW/SW instantiations based on whether one instantiation is going to be in a battery powered environment and one is going to be in an AC powered environment."


Comment:
[PM/SPS-4] Delete this sentence frag.  "... when the PNC is battery powered and support at least four SPS sets when the PNC is powered by the alternating current mains, Table 60."


Comment:
[PM] The requestor cannot hang and wait an indefinite time for a decision from the PNC. Either you get your channel time or you don't. If the destination is in hibernation, any CTR shall be denied. If a DEV wants to know about traffic it can select PSPS or SPS. In Hibernation it just wants to sleep. I would kindly urge all editors to please try to refrain from putting undiscussed ad-hoc inventions into the draft. If you really want to wake up a sleeping DEV at some unknown time in the future, we could consider having a new command to set the PCTM bit. One way would be to add a DEVID to PS mode change. If (operation == ACTIVE && dev != UNASSOC) set PCTM(dev).


Comment:
[PM] Some attempts have been made to create a wakeup signal from a DEV to a sleeping peer DEV. A simple addition to the PS mode change command can cause the PNC to set the PCTM bit for a sleeping DEV. New subclause 8.13.x Waking up a DEV in power save mode


Comment:
[PNC_Shutdown] Second sentence in paragraph is only true if PNC decides to do shutdown, not if it does handover. If battery doesn't permit a handover the PNC will do shutdown instead. The referenced text is present in shutdown, 8.2.6, page 171, line 38-40.

SuggestedRemedy:
Delete sentence on line 20 "The only exception ... to complete the handover process"


Comment:
[CTA/Isoch] The original purpose of this IE got lost! All subrates shall also be announced, regardless if the DEV is in PS mode. The DestDEV cannot find the CTR-interval in any other way and it needs it if it wants to go into a PS mode.


SuggestedRemedy:
Always announce CTR-Interval changes. Change sentence on line 4-6 to:"The PNC shall announce modification of all streams if the CTR type or CTR interval is modified."


Comment:
[CTA/Isoch] The last sentence on line 13-14 belongs to stream creation, 8.5.1.1


Comment:
[PM] The rule in SPS that beacon announcements shall be done in N subsequent wake beacons, in stead of just N subsequent beacons starting with the wake beacon, makes PNC implementation utterly complicated. All this calls for a unified rule for PSPS and SPS: If you miss your wake beacon, listen to the next beacon. From the DEV's point of view, the requirement to listen to the following beacon may be relaxed to a 'may' or 'should' for SPS. The intent  with this comment is to simplify PNC implementation.

SuggestedRemedy:
In rules for individual DEV, combine second and third rule to:- If the DEV is in PSPS or SPS mode, the announcement shall be made in aMinBeaconInfoRepeat subsequent beacons starting with the system or SPS wake beacon.


Comment:
[PM] The rule in SPS that beacon announcements shall be done in N subsequent wake beacons, in stead of just N subsequent beacons starting with the wake beacon, makes PNC implementation complicated. All this calls for a unified rule for PSPS and SPS: If you miss your wake beacon, listen to the next beacon. The requirement can be relaxed for SPS

SuggestedRemedy:
Add text after description of wake beacon:"A DEV that does not correctly receive its wake beacon shall listen to the following beacon if it's in PSPS or HIBERNATE mode, and it should (may?) listen to the following beacon if it's in SPS mode".


Comment:
[MCTA] SPS DEV gets an MCTA to use for PS mode change, not a CTA.

SuggestedRemedy:
change to "and an MCTA with the SPS DEV ..."Same on page 218, line 6, change "CTA" to "MCTA".


SuggestedRemedy:
Delete "The stream termination field..". Change MSC Figure 120 and Figure 119


Comment:
[PM/SPS-4] "The PNC shall support one PS set for HIBERNATE and one PS set for PSPS. In addtion the PNC shall supportat least one SPS set, i.e. a PS set with PS set index between 2 and 253, when the PNC is battery poweredand support at least four SPS sets when the PNC is powered by the alternating current mains, Table 60."

SuggestedRemedy:
Change to:  "The PNC shall support one PS set for HIBERNATE and one PS set for PSPS. In addtion the PNC shall support at least one SPS set, i.e. a PS set with PS set index between 2 and 253."


SuggestedRemedy:
New text, continuing on "When MCTA are used...": "The PNC shall allocate MCTA assigned to a DEV, open MCTA or both. The frequency of assigned MCTA shall be at least CTRRespTime, as defined in the beacon. If only open MCTA are used, the PNC shall allocate at least one open MCTA per DEV and CTRRestTime. The PNC may reduce the MCTA allocation frequency for power save DEVs, and for DEVs requesting a longer interval between assigned MCTA using the CTR command, 7.5.5.1. Special rules power save DEVs is listed in 8.13.1, 8.13.2.2 and 8.13.3"


Comment:
[PM] The requestor cannot hang and wait an indefinite time for a decision from the PNC. Either you get your channel time or you don't. If you really want to wake up a sleeping DEV at some unknown time in the future, we could consider need to have a better mechanism, such as deferred CTRB or a new wakeup command.


Comment:
[Assoc]How does a PNC meet aAssocRespConfirmTime of 5 ms?  The association may be at the end of the CAP or in an association MTS and the PNC may not have any channel time available in 5 ms.  or DEV


Comment:
[PM/SPS-4] Delete this sentence fragment.  "... when the PNC is battery powered and support at least four SPS sets when the PNC is powered by the alternating current mains, Table 60."  This approach constrains the customer/implementor to support a power management scheme that forces the PNC to manage DEV defined wake beacon intervals for each SPS set instantiation. This has complexity implications for the MAC CTA scheduler and Beacon generation algorithms. In addition, it also forces the customer/implementor to implement a MAC that has to support a minimum of 4 SPS sets regardless of whether it is battery powered or AC powered. It is highly unlikely that implementors are going to develop/support two different MAC HW/SW instantiations based on whether one instantiation is going to be in a battery powered environment and one is going to be in an AC powered environment."


Comment:
[PM] The requestor cannot wait an indefinite time for a decision from the PNC on channel timer allocation. If the destination is in hibernation, any CTR shall be denied. If a DEV wants to know about traffic it can select PSPS or SPS. In Hibernation it just wants to sleep. If one wants to wake up a sleeping DEV at some unknown time in the future, we should consider having a new command to set the PCTM bit. One way would be to add a DEVID to PS mode change. If (operation == ACTIVE && dev != UNASSOC) set PCTM(dev)./KO


Comment:
The sentence "Note that the PNC handover should not stop any of the data connections." conflicts with other statements in the standard because async data connections are not maintained during PNC handover.

SuggestedRemedy:
Replace "Note that the PNC handover should not stop any of the data connections." with "Note that the PNC handover should not stop any of the isochronous data connections."


Comment:
The IE's sent a aMinBeaconInfoRepeat times to SPS and PSPS DEVs are now sent in successive WAKE beacons. This is only the best stategy if the DEV is oblivious to the transmission, a highly unlikely case

SuggestedRemedy:
Change text to: "The IEs shall be sent in aMinBeaconInfoRepeat subsequent beacons.  If any DEV is in PSPS or SPS mode, the first IE announcement shall be made in a system wake beacon."


Comment:
A policy for adjusting available channel time is needed to avoid arbitrary implementations

SuggestedRemedy:
Define the policy so that all isochronous streams allocation must be increased by 1/N times the total time increment available, where N is the number of streams.


SuggestedRemedy:
Replace "capability field" with "PNC capabilities field"


Comment:
The figure contains incorrect information

SuggestedRemedy:
The 3rd instance of "None" on the "Communications rules" sub-figure should line up with the 2nd instance of "Beacon" of the "Parent Piconet" sub-figure.


Comment:
He PNC only needs to see the source, not the source and destination, using the new slot.

SuggestedRemedy:
Change to "usage of the new allocation by the source of the old allocation..."


Comment:
This paragraph mentiones pseudo-static CTAs before they are defined in the next paragraph

SuggestedRemedy:
Move the paragraph starting with "A private CTA" until somewhere after the following paragraph.


Comment:
How does a PNC meet aAssocRespConfirmTime of 5 ms?  The assoc may be at the end of the CAP or in an association MTS and the PNC may not have any channel time available in 5 ms.


Comment:
How does a PNC or DEV meet aProbeResponseDelay of 8 ms?  The probe may be at the end of the CAP or in a CTA and the responder may have no available channel time.


Comment:
Delete this sentence frag.  "... when the PNC is battery powered and support at least four SPS sets when the PNC is powered by the alternating current mains, Table 60."  As Allen Heberling stated in his BRC PM e-mail ballot of 10/29/02 regarding his opposition to making 4 SPS sets mandatory:"...Mr. M. Schrader, on the other hand is advocating 4 SPS sets for an AC powered device. This approach constrains the customer/implementor to having to support a powermanagement scheme that forces the PNC to manage DEV defined wake beacon intervals  for each SPS set instantiation(this has complex implications for the MAC CTA scheduler and Beacon generation algorithms). In addition, it also forces the customer/implementor to implement a MAC that has to support a minimum of 4 SPS sets regardless of whether it is battery powered or AC powered. It is highly unlikely that implementors are going to develop/support two different MAC HW/SW instantiations based on whether one instantiation is going to be in a battery powered environment and one is going to be in an AC powered environment."


Comment:
The requestor cannot hang and wait an indefinite time for a decision from the PNC. Either you get your channel time or you don't. If the destination is in hibernation, any CTR shall be denied. If a DEV wants to know about traffic it can select PSPS or SPS. In Hibernation it just wants to sleep.  If you really want to wake up a sleeping DEV at some unknown time in the future, we could consider having a new command to set the PCTM bit. One way would be to add a DEVID to PS mode change. If (operation == ACTIVE && dev != UNASSOC) set PCTM(dev).

SuggestedRemedy:
Delete page 221 line 11-16. Replace with: "The PNC shall deny a channel time request if the destination is in HIBERNATE mode. The PNC shall return a channel time response command with the error code set to 'destination in power save mode' (rename error code 7 in 7.5.5.2


Comment:
Some attempts have been made to create a wakeup signal from a DEV to a sleeping peer DEV. A simple addition to the PS mode change command can cause the PNC to set the PCTM bit for a sleeping DEV. New sublause 8.13.x Waking up a DEV in power save mode


Comment:
Small changes to support new TrgtID field in the PS Mode change command. Editorial: Switching to ACTIVE is the same procedure regardless of PS mode. Maybe lift out to the general clause?


SuggestedRemedy:
"After "MLME" add "/MAC" whenever it appears in a box in any figure of this clause."


Comment:
"Incorrect illustration in the last paragraph in lines 30-33 and Figure 95:  A returned MLME-XXX.confirm does not necessarily contain a ResultCode of SUCCESS, because the result may be something other than SUCCESS or because the result may be encoded in the ReasonCode rather than the ResultCode as is the case in many primitives."


SuggestedRemedy:
"Change "regular DEV in" to "member of" (2 occurrences)."


Comment:
"Incorrect statements in lines 42-46:  The interval "mMinChannelScan" should not be referenced to reception of a frame--how long would the searching DEV have to stay in the channel if no frame was ever received?"

SuggestedRemedy:
"Delete "While searching, if any frame is received,", Capitalize the first letter of the following article, and further delete the words "from the time…as part of the MLME-SCAN.confirm primitive"."


Comment:
"Incorrect statements in lines 29-36:  The Start procedure follows the Scan procedure immediately, and hence there is no point to require the DEV to perform another scan."

SuggestedRemedy:
Delete all the statements other than the first one from the third paragraph of this subclause.


Comment:
"Ambiguous terms in lines 23-25, page 164."

SuggestedRemedy:
"Change "capability field" to  "PNC Capabilities field" and "capabilities information" to "PNC Capabilities information"."


Comment:
"Incorrect wording in lines 9 and 12, page 165."

SuggestedRemedy:
"Change "last handover beacon" to "last beacon".  Add "the" before "old and new" ."


Comment:
"Ambiguous terms in lines 14-15, page 165:  What is "PNC related traffic" and what is "non-PNC related traffic"?"


Comment:
"Unnecessary restriction in line 23, page 165."


SuggestedRemedy:
"Add "PNC" before "handover IE" (4 occurrences)."


SuggestedRemedy:
"Change the left arrowhead pointing from "new PNC beacon" to an right arrowhead pointing to the vertical line connected to the "PNC MLME" box."


SuggestedRemedy:
"Add "PNC" before "capabilities field"."


Comment:
"Ambiguous statement in lines 1-2, page 168."

SuggestedRemedy:
"Add "parent" before "PNCID" and change "the source and destination DEV address" to "SrcID and DestID"."


SuggestedRemedy:
"After "request" add "command", and change "capability field" to "PNC Capabilities field"."


Comment:
"Words missing in lines 37 and 41, page 169."

SuggestedRemedy:
"Add "Association Response" before "command" and "the" before "PNC of the parent piconet"."


SuggestedRemedy:
"Change "the neighbor" to "After the association request is accepted, the neighbor".  After "by the PNC" add "in the Association Response command"."


Comment:
"Ambiguous statement in lines 5-6, page 170."

SuggestedRemedy:
"Change "the neighbor beacon, using the PNCID" to "its beacon, using the parent PNCID"."


Comment:
"Incorrect wording in lines 13-14, page 170."

SuggestedRemedy:
"Change "its transmitting" to "its own transmissions" and change "parent's" to "parent PNC's"."


SuggestedRemedy:
"Change "CTR request" to "CTA request"."


Comment:
"Incomplete command name in line 31, page 171."


Comment:
"Incorrect wording in lines 43, 46, and 47, page 171."

SuggestedRemedy:
"Change "networks" to "piconets" (3 occurrences)."


SuggestedRemedy:
"Add "PNC" before "shutdown IE" (this is needed because it is part of the name for this IE)."


SuggestedRemedy:
"Change "a free-standing" to "an independent"."


SuggestedRemedy:
"Change "stream allocated to" to "CTA for"."


SuggestedRemedy:
"Change "disassociate request" to "Disassociation Request command"."


Comment:
"Incorrect wording in line 20, page 172."


Comment:
"Stylistic inconsistency in line 54, page 172."


Comment:
"Incorrect wording in lines 1 and 2, page 173."

SuggestedRemedy:
"Change "on the piconet" to "in the piconet", and change "shall be" to "are"."


Comment:
"Undefined parameter in line 11, page 173."


Comment:
"Missing article in line 21, page 173, incorrect wording in line 22, page 173, and word missing in line 23, page 173."

SuggestedRemedy:
"Add "an" before "association MCTA".  Change "initialized with" to "set to".  After "of the association request" add "command"."


Comment:
"Incorrect statement in lines 24-25, page 173:  As noted elsewhere by this balloter, the DEV Association IE does not serve the purposes it was intended for.  The DEVs "newly" associated with the PNC and announced via this IE would not necessarily be known to DEVs that are associated later on (i.e., after the announcement of this IE.  The balloter has suggested to replace the "DEV Association IE" with an "Association List IE" that lists all the DEVs associated with this PNC."

SuggestedRemedy:
"Rephrase the statement "The PNC after…" as follows:  The PNC after acknowledging this second request shall send a beacon containing an Association List IE that includes the requesting DEV.  Change "the DEV association information element" in line 27 to "an Association List IE that includes itself".  Change "DEV association IE" in lines 28, 29, and 30 to "Association List IE"."


SuggestedRemedy:
"Change "association IE" to "Association List IE" and "ack with" to "ACK with"."


Comment:
"Incorrect grammar in line 38, page 174."

SuggestedRemedy:
"Change "when a DEV leaves" to "after a DEV left"."


Comment:
"Incorrect command name in line 39, page 174."

SuggestedRemedy:
"Change "disassociation command" to "Disassociation Request command"."


SuggestedRemedy:
"Change "serving as PNC" to "serving as a PNC"."


Comment:
"Redundant information in line 49, page 174:  The PNC Information command contains all the information in the "DEV Association IE"."

SuggestedRemedy:
Delete this requirement or expand this procedure to replace the requirement that the PNC send a beacon containing a DEV Association IE to reflect the association status of a newly associated DEV.


SuggestedRemedy:
"After "IEs" add "in the Piconet Services command", and add "the" before "information"."


Comment:
"Ambiguous statements in lines 13-19:  After a DEV disassociates from the PNC, should the PNC update the Piconet Services IEs via a beacon or a Piconet Services command?"


Comment:
"Incorrect wording in line 2, page 176."

SuggestedRemedy:
"Change "the current DEV" to "an associated DEV"."


Comment:
"Incomplete command name in line 11, page 176."


Comment:
"Incorrect grammar in line 13, page 176."


Comment:
"Incorrect specification in line 14, page 176."

SuggestedRemedy:
"Change "DEV Association IE" to "Association List IE which no longer includes the newly disassociated DEV"."


Comment:
"Ambiguous statement in lines 14-15, page 176."

SuggestedRemedy:
"Change "for the disassociating DEVs" to "with the disassociated DEV as the SrcID or DestID"."


Comment:
Incorrect illustration in Figure 104 and Figure 105.

SuggestedRemedy:
"Change "beacon with association IE" to "Beacon with Association List IE no longer including DEV-2",  change "ack" and "ACK" to "Imm-ACK", and "ASSOCIATE-INFO" to "ASSOCIATION-INFO".  Delete "DEVID=DEV-2, status=disassociated", "DEVID =DEV-2", and "Status = disassoc"."


Comment:
"Incorrect definition in line 31, page 177."


Comment:
"Ambiguous wording in line 52, page 177."

SuggestedRemedy:
"After "frame" add "either", and after "or" add "with"."


Comment:
"Incorrect wording in line 3, page 178."

SuggestedRemedy:
"Change "for the beacon" to "after the beacon"."


Comment:
"Articles missing in lines 16, 18 and 19, page 178."

SuggestedRemedy:
"Change "during CAP" to "during the CAP", "of current frame" to "of the current frame", and "in CAP" to "in the CAP"."


Comment:
"Incorrect wording in line 27, page 178."

SuggestedRemedy:
"Change "piconet synchronization fields" to "Piconet Synchronization Parameters field"."


Comment:
"Incorrect statement in lines 8-10, page 179."

SuggestedRemedy:
"Delete the statement "This avoids the problem…"."


Comment:
"Incorrect terms:  Channel access in the CFP is not necessarily contention free, because open and association MCTAs are subject to Aloha-based contention."

SuggestedRemedy:
Either modify the terms or add a statement to that effect.


Comment:
"Incorrect specification regarding local selection in lines 35-38, page 179:  Each CTA block contains a Stream Index that is tied to a specific stream."

SuggestedRemedy:
"Rephrase the statement "The selection of a…" as follows:  The source DEV of a CTA shall use that CTA to send data from the stream specified for that CTA, or to send data from other streams between the same source and destination DEVs if the specified stream has no more data to send."


Comment:
"Incorrect grammar in line 43, page 179."


Comment:
"Incorrect wording in line 44, page 179."

SuggestedRemedy:
"Change "for channel time request" to "in the Channel Time Allocation request"."


Comment:
"Incorrect wording in line 4, page 180."


Comment:
"Ambiguous wording in line 10, page 180."

SuggestedRemedy:
"Change "from PNC" to "with PNC as the SrcID"."


Comment:
"Ambiguous specification in lines 13-14, page 180:  It is not clear if dynamic CTAs may be allocated to isochronous streams."

SuggestedRemedy:
"Before "Asynchronous CTAs" add "Dynamic CTAs may be allocated for isochronous streams."."


Comment:
"Incorrect wording in lines 14 and 15, page 180."

SuggestedRemedy:
"Change "wants" to "needs".  Change "the associated CTAs in the beacon" to "that CTA via the beacon"."


Comment:
"Incorrect wording and restriction in lines 15-17, page 180:  "

SuggestedRemedy:
"Rephrase the statement "The PNC shall not create..." as follows: The PNC shall not specify any CTA(s) overlapping with an existing pseudo-static CTA allocated to a different source DEV unless that pseudo-static CTA has been changed or terminated for mMaxLostBeacons superframes."


Comment:
"Incorrect and unnecessary statements in lines 17-21, page 180."

SuggestedRemedy:
"Delete the two statements "However note…another pair of DEVs."."


Comment:
"Incorrect wording in lines 21-24, page 180."

SuggestedRemedy:
"After "When the source" add "DEV", and after "When the destination" add "DEV".  Change "beacon with the new CTA" to "beacon indicating a change to that CTA" (2 occurrences).  Change "may also receive during the old CTA" to "shall continue receiving during the old CTA for mMaxLostBeacons superframes in case the source DEV of the CTA continues to transmit into the old CTA because of missing beacons."."


Comment:
"Incorrect statements in lines 26-28, page 180:  The destination DEV may miss traffic for more than mMaxLostBeacons superframes."

SuggestedRemedy:
"Rephrase the two statements as follows:  To avoid missing traffic, an associated DEV shall listen for the entire superframe duration whenever it missed a beacon."


Comment:
"Ambiguous wording in lines 48-49, page 180."

SuggestedRemedy:
"After "When a" add "source", change "the destination" to "a destination" and "the DEV is free to" to "the source DEV may"."


Comment:
"Incomplete statement in lines 51-52, page 180."

SuggestedRemedy:
"After "associated DEV" add "known to be in the AWAKE state"."


SuggestedRemedy:
"Change "for which it is the destination" to "destined to it"."


Comment:
"Incorrect specification in lines 24-25, page 181:  How does the PNC indicate in its Channel Time Response command that it will not update the channel time request?"

SuggestedRemedy:
"Clarify and rephrase the statement "If the PNC…additional channel time."."


Comment:
"Incorrect wording in line 50, page 181."


SuggestedRemedy:
"Change "management stream index" to "MCTA traffic index"."


SuggestedRemedy:
"Add "sending" before "command frames"."


SuggestedRemedy:
"Delete "in the CTA for the MCTA" (2 occurrences)."


Comment:
"Incomplete command name in lines 18, 19, and 20."

SuggestedRemedy:
"Change "association command" to "Association Request command", "Association commands" to "Association Request commands", and "association commands" to "Association Request commands"."


Comment:
"Undesirable specification:  The Aloha access algorithm defined in this subclause is undesirable in two folds:  (1) The "binary backoff" nature of the contention algorithm, i.e., doubling the contention window after an inferred collision, in a PAN would unnecessarily increase the access latency, as an inferred collision could be a result of a non-collision event such as interference or bad channeling.  Also, the backoff has a memory which could spread over a large number of superframes, and hence does not allow the PNC to adapt the CW to load changes for optimal channel throughput and access latency.  Instead, re-randomizing the backoffs without doubling the CW among contending DEVs in every superframe would be more effective in avoiding collision, especially considering the generally low DEV population in a PAN, and hence in improving channel throughput and access delay.  (2) Potentially each contending DEV may have to buffer a large number of MCTA definitions as announced in the beacon, and determine which of those MCTAs may be used for an initial transmission, a retransmission, and a retransmission again, ..., of a command frame, all within the same superframe.  This would certainly increase the implementation cost."

SuggestedRemedy:
"(1) The number "a" should not be individual functions of retransmission attempts by contending DEVs.  Instead, it should be a parameter whose value is updated and annonced by the PNC in each beacon.  To this effect, add two 1-octet subfields to the Piconet Synchronization Parameters field for encoding "a", one for use with Association MCTAs and one for use with Open MCTAs.  "a" may be called Associaiton CW exponent and Open CW exponent, respectively.  Eliminate the first branch of Equation (1) and the condition in the second branch.  Each contending DEV shall redraw a backoff after receiving a beacon using the "a" value contained in that beacon, even if the previous backoff has not expired (and hence the DEV did not transmit in the previous superframe).  A DEV shall regenerate a backoff for a retransmission within the same superframe using the same "a" value as in the initial transmission.
(2) Add a statement to limit the number of MCTAs (for each type, Association or Open) that may be used by any given DEV to two within each superframe.  That is, only one retransmission is allowed by each DEV following a failed transmission in the same superframe."


Comment:
"Incorrect wording in line 8, page 183."

SuggestedRemedy:
"Change "counting r sub a from the open or association MCTA" to "counting the Association or Open MCTAs"."


Comment:
"Ambiguous specification in lines 9-10, page 183."

SuggestedRemedy:
"Change "ACK" to "Imm-ACK" (2 occurrences).  Change "presence" to "reception".  Change 'association frame" to "Association Request command frame"."


Comment:
"Incorrect specification in lines 13-16, page 183."

SuggestedRemedy:
"Change "broadcast or unassigned" to "Association or Open".  Delete "the open or association MCTA with the number r=".  Change "ACK" to "Imm-ACK".  Delete the last statement "After receiving" if "a", and hence the "backoff", is to be updated every superframe, as suggested earlier by this balloter."


Comment:
"Incorrect wording in line 24, page 183."


Comment:
"Incorrect illustrations in Figure 107, Figure 108, and Figure 109."

SuggestedRemedy:
"Change "SIFS" to "MIFS" in Figure 107 (3 occurrences).  Delete "CTR time unit" (which does not necessarily cover a whole frame plus MIFS due to variable frame sizes) from all the three figures.  Change "SIFS" to "MIFS" after "Frame 1" and "Frame 2", respectively, in Figure 109."


Comment:
"Incomplete specification in lines 40-41, page 184."

SuggestedRemedy:
"Change 'Including SIFS" to "Including MIFS/SIFS".  Change "at least a SIFS" to "at least a MIFS/SIFS" (2 occurrences, one on the next page)."


Comment:
Incorrect specification in Equation (2).

SuggestedRemedy:
"Change "/" to "x" and "* interval" to "x Superframe Duration"."


Comment:
"Word missing in lines 34-35, page 185."


Comment:
Incorrect specification in Equation (3).


Comment:
"Incorrect grammar in lines 47-48, page 185."

SuggestedRemedy:
"Change "where it calculates the start of the CTA to be" to "which it calculates is the start of the CTA"."


SuggestedRemedy:
"Change "SIFS" to "MIFS" after "Frame 1" and "Frame 2", respectively."


Comment:
"Incorrect grammar in lines 51-53, page 186."

SuggestedRemedy:
"After "calculates" add "is", and delete "to be"."


Comment:
"Incorrect wording in lines 6-11, page 187."

SuggestedRemedy:
"Change "CTA to be" to "CTA,", "allocation" to "appropriate interval", "at the end" to "after the end", and "including" to "accounting for the"."


Comment:
"Incorrect wording in line 18, page 188."

SuggestedRemedy:
"Change "in the superframe of the CTA status IE announcement" to "in the superframe indicated in the CTA Status IE"."


Comment:
"Incorrect grammar in line 26, page 188."


SuggestedRemedy:
"Change "CTA status command" to "CTA Status IE"."


Comment:
"Incorrect illustrations in Figure 114, Figure 115, and Figure 116."

SuggestedRemedy:
"Change "ACK" to "Imm-ACK" (2 occurrences in each figure).  Change "presence" to "reception".  Change 'association frame" to "Association Request command frame".  Change "ResultCode" to "ReasonCode" in each of these three figures (recall that the actual result is contained in the ReasonCode).  Change "= FAILED" to "not equal to SUCCESS" in Figure 115."


Comment:
"Incorrect wording in lines 48 and 51, page 190."

SuggestedRemedy:
"Change "when requesting" to "for requesting" (2 occurrences)."


Comment:
"Incorrect wording in line 2, page 191."

SuggestedRemedy:
"Change "requested channel time" to "modified CTA"."


Comment:
"Ambiguous wording in line 8, page 191."


Comment:
"Incomplete specification in line 9, page 191."

SuggestedRemedy:
"After "MCTA" add "for that target DEV" and after "CTA is" add "first"."


Comment:
"Incorrect wording in line 11, page 191."

SuggestedRemedy:
"Change "when requesting" to "in requesting"."


Comment:
Incorrect illustrations in Figure 117 and Figure 118.

SuggestedRemedy:
"Change "ACK" to "Imm-ACK" (2 occurrences in each figure).  Change "ResultCode" to "ReasonCode" in each of these two figures (recall that the actual result is contained in the ReasonCode).  Change "= FAILED" to "not equal to SUCCESS" in Figure 118."


Comment:
"Incorrect wording in lines 37, 38 and 41, page 192."

SuggestedRemedy:
"Change "ACK" to "Imm-ACK".  Change "shall than" to "shall then".  Change "and DestID with" zero values" to ",DestID, and zero values"


Comment:
Incorrect illustrations in Figure 119 and Figure 120.

SuggestedRemedy:
"Change "ACK" to "Imm-ACK" in both figures.  Change "ResultCode" to "ReasonCode" in each of these two figures (recall that the actual result is encoded in the ReasonCode)."


SuggestedRemedy:
"Change "ACK" to "Imm-ACK".  Change "reason code = stream terminated" to "ReasonCode = Stream terminated by PNC".  Move the text together with the arrow between the two lines connected to the "DEV-3 MLME" and DEV-3 DME" boxes down below the arrow with text "beacon with null-CTA SI = x"."


SuggestedRemedy:
"Delete "-SPS" and rename "CTR type" if needed."


Comment:
"Incomplete statement in line 12, page 195."

SuggestedRemedy:
"After "superframe" add ", with any such CTA again announced by multiple CTA blocks each of which corresponds to a destination."


Comment:
"Article, space and word missing in lines 14-16, page 195."

SuggestedRemedy:
"Add "the" before "PNC".  After "in the" add a space.  Add "destination" before "DEVs in power save"."


SuggestedRemedy:
"Change "ACK" to "Imm-ACK" (2 occurrences)."


SuggestedRemedy:
"Change "CTR command" to "CTA Request command"."


Comment:
"Incorrect wording in lines 47 and 48, page 196."

SuggestedRemedy:
"Change "networks" to "piconets".  Change "CTA" to "CTAs".  Change "DEV" to "DEVs"."


Comment:
"Ambiguous wording in line 36, page 197."

SuggestedRemedy:
"Change "in the frames" to "in these frames"."


Comment:
"Misplaced article in line 46, page 197."


SuggestedRemedy:
"Change 'In some cases these" to "Some".  Change "certain features are in use, such as power save or a dependent piconet" to "certain operations, such as with power save or a dependent piconet, are in use"."


SuggestedRemedy:
"Change "for at least" to "in at least".  Add "consecutive" before "beacons"."


SuggestedRemedy:
"Under "Intended for" change "DestID" to "CTA source and destination DEVs"."


Comment:
Incorrect wording  or specification in lines 32-47.

SuggestedRemedy:
"After "recipient of" change "the IE" to "an IE" (2 occurrences).  Change "IEs" before "shall" to "IE" (3 occurrences).  Change "subsequent" to "consecutive" (3 occurrences).  In line 42, change "the first IE announcement shall be made in a system wake beacon" to "the IE shall be announced in a System Wake beacon and the following mMinBeaconInfoRepeat-1 beacons".  In line 43, change "the IEs shall be sent in mMinBeaconInfoRepeat subsequent SPS set wake beacons" to "the IE shall be sent in a Next Wake beacon and the following mMinBeaconInfoRepeat-1 beacons".
Replace lines 46 and 47 as follows:  "A CTA IE is considered to be intended for all DEVs if the SrcID or/and DestID contained in that IE is the BcstID or McstID, and otherwise for the pair of DEVs defined by the SrcID and DestID."


SuggestedRemedy:
"After "synchronizing" add "with a PNC"."


Comment:
"Ambiguous specification in line 31, page 199:  The draft never defines a fragmentation threshold on a per stream basis, as implied by "the fragmentation threshold for the current isochronous stream or asynchronous data"."


Comment:
"Incorrect wording in lines 37 and 40, page 199."

SuggestedRemedy:
"Change "capabilities information" to "Capability Information".  Change "total amount" to "total number"."


Comment:
"Incorrect wording in line 11, page 200."

SuggestedRemedy:
"Change "stream number" to "stream index"."


Comment:
"Incomplete statements in lines 14-16, page 200."

SuggestedRemedy:
"Change "multiple SDUs" to "multiple MSDUs belonging to the same stream".  Change "the SDUs" to "the MSDUs"."


Comment:
Ambiguous specification:  The last paragraph of 8.7 is the only place indicating that MSDUs must be delivered to the upper layer in order when they are transmitted with the Dly-ACK mechanism.

SuggestedRemedy:
"If this is the intent for Dly-ACK, restate it clearly in 8.8.3"


Comment:
"Is the receiving MAC supposed to wait for any missing frames? If so, for how long?  For instance, the sender sent 5 consecutive frames, of which frame 1 was not received by the recipient but was discarded by the sender after its last transmission (due to exceeding delay limit.  Should the recipient hold all the received frames after frame 1 in waiting for frame 1?  The issue is resolved in a similar mechanism defined in the latest 802.11e draft, which introduces a field in the frame requesting a Dly-ACK to indicate a Sequence Control value such that all frames with a smaller Sequence Control value have been discarded by the sender and hence should not be awaited by the recipient.  This expedites the delivery of received frames to the upper layer in the case of missing frames at the recipient. "


Comment:
"Incorrect wording in lines 45-48, page 200."

SuggestedRemedy:
"Change "amount of pMaxFrameSize MPDUs" to "number of MPDUs of maximum allowable size".  Delete the statement "Since the receiver…7.3.2.2."


Comment:
"Incorrect wording in lines 17-18, page 201."

SuggestedRemedy:
"Change "the max burst size value" to "a number of Max Burst as"."


Comment:
"Incorrect wording in line 22, page 201."

SuggestedRemedy:
"Change "total amount" to "total number"."


Comment:
"Incorrect wording in lines 1 and 2, page 202."

SuggestedRemedy:
"Delete "gives up on that frame and".  Change "gives up on" to "discards"."


Comment:
"Incorrect article in line 25, page 202."


Comment:
"Incorrect wording in lines 26 and 28, page 202."

SuggestedRemedy:
"After "command to" delete "be" (2 occurrences)."


Comment:
"Incorrect wording in line 2, page 203 and in the caption of Figure 126."


SuggestedRemedy:
"Change "ACK" to "Imm-ACK" (3 occurrences)."


Comment:
"Incorrect field name in line 30, page 203."


Comment:
"Incorrect grammar in lines 42-43, page 203."

SuggestedRemedy:
"Change "when it received" to "receiving"."


Comment:
"Incorrect wording in line 46, page 203."

SuggestedRemedy:
"Change "probe command with" to "Probe command containing"."


Comment:
"Incorrect wording in lines 49-50, page 203."

SuggestedRemedy:
"Change "with the CTA" to "containing a CTA"."


Comment:
"Incorrect statement in lines 51-52, page 203."

SuggestedRemedy:
"Change "bits for either the CTA status IE or the CTA request status IE in the information request field" to "bit for the CTA Status IE in the IEs Requested field"."


Comment:
"Incorrect wording in line 1, page 204."

SuggestedRemedy:
"Change this line to "containing a CTA Status IE by sending a Probe command containing that CTA Status IE,"."


Comment:
"Incorrect wording in line 4, page 204."

SuggestedRemedy:
"Change "information request field set to zero and ACK request field" to "IEs Requested field set to zero and ACK Policy field"."


SuggestedRemedy:
"After "probe" add "command" (2 occurrences)."


Comment:
"Incorrect illustrations in Figure 127, Figure 128, and Figure 129."

SuggestedRemedy:
"Change "ACK" to "Imm-ACK" (3 occurrences in Figure 127, 1 occurrence in Figure 128, and 2 occurrences in Figure 129).  Change "IR field" to "IEs Provided" (3 occurrences in Figure 127, 1 occurrence in Figure 128, and 2 occurrences in Figure 129).  Change "IEs = null" to "IEs Requested = Null" (1 occurrence each in Figure 127 and Figure 129).  Change "IEs = ??" to "IEs Requested = ??" (1 occurrence in Figure 128).  Delete "IR = information request" (1 occurrence each of the three figures).  Change "information elements" to "information element" (1 occurrence in each of the three figures)."


Comment:
"Incorrect grammar in line 28, page 205."


Comment:
"Incorrect wording in line 30, page 205."

SuggestedRemedy:
"Change "a request for a specific IE" to "or requesting specific IEs"."


Comment:
"Incorrect grammar in line 41, page 206."


Comment:
"Incorrect wording in line 49, page 206."


Comment:
"Incorrect grammar in line 8, page 207."

SuggestedRemedy:
"Change ", unsolicited, a" to "an unsolicited"."


Comment:
"Incorrect wording in line 11, page 207."

SuggestedRemedy:
"Change "that is associated with" to "of".  Change "DEVs current" to "DEV's current"."


Comment:
"Awkward wording in lines 52-53, page 207."

SuggestedRemedy:
"Change "one or more alternate" to "the other"."


Comment:
"Incorrect statement in line 16, page 208:  Pseudo-static CTAs are actually changed when the superframe duration is changed."

SuggestedRemedy:
"Change "pseudo-static CTAs" to "pseudo-static CTA blocks"."


SuggestedRemedy:
"Change "the piconet parameter" to "the new piconet parameter(s)"."


Comment:
"Incorrect wording in lines 5-6, page 209."

SuggestedRemedy:
"Change "the size of the superframe following" to "the new size of the superframe which follows"."


Comment:
"Incorrect information element name in lines 37 and 42, page 209."

SuggestedRemedy:
"Change "overlapping piconets information element" to "Overlapping PNID IE" (2 occurrences)."


Comment:
"Ambiguous wording in line 42, page 209."

SuggestedRemedy:
"Change "PNC with the" to "PNC including an"."


Comment:
"Incorrect word forms in lines 6-10, page 211."

SuggestedRemedy:
"Change "the PNC" to "The PNC" (3 occurrences).  Change "sending the" to "sending a" and "via the" to "via a"."


Comment:
"Incorrect wording in lines 17, 20, and 23, page 211."

SuggestedRemedy:
"Change "PNC is able to" to "PNC may".  Change "the NbrOfChangeBeacons" to "NbrOfChangeBeacons consecutive".  After "with the first beacon" add "sent"."


Comment:
"Incorrect grammar in line 31, page 211."


Comment:
"Incorrect IE name in lines 37-38, page 211."

SuggestedRemedy:
"Change "channel change element" to "Piconet Parameter Change IE"."


Comment:
"Incorrect wording in line 33, page 212."


Comment:
"Incorrect field name in line 53, page 212."

SuggestedRemedy:
"Change "piconet maximum transmit power field" to "Max TX Power Level field".  Change "maximum power level" to "Max TX Power Level"."


SuggestedRemedy:
"Change "for the 2.4 GHz PHY in 11.5.9" to "in 11.5.9 for the 2.4 GHz PHY"."


Comment:
"Incorrect field name in line 2, page 213."

SuggestedRemedy:
"Change "piconet maximum transmit field" to "Max TX Power Level field"."


SuggestedRemedy:
"Change "ACK" to "Imm-ACK".  Change ".cnf" to ".cfm"."


Comment:
"Confusing and incorrect definitions for power management modes, power save modes, power states, and their relationships:  ACTIVE mode is NOT a power save mode as is often confused throughout this draft.  A DEV may be in "AWAKE" state beyond the time when it is either transmitting or receiving.  For instance, a DEV may be in "AWAKE" state when the channel is idle.  A DEV may not be in a "SLEEP" state even if it is neither transmitting nor receiving."

SuggestedRemedy:
"Rewrite the first paragraph as follows:
There are four power management (PM) modes defined in this standard, ACTIVE, HIBERNATE, PSPS, and SPS modes.  The latter three modes are collectively referred to as power save (PS) modes.  A DEV that is in ACTIVE, HIBERNATE PSPS, or SPS mode is said to be an ACTIVE DEV, a HIBERNATE DEV, a PSPS DEV, or an SPS DEV, respectively.  In any given PM mode, a DEV may have two power states, AWAKE and SLEEP states.  A DEV in AWAKE state is able to transmit and receive and is fully powered, while a DEV in SLEEP state is not able to transmit or receive and consumes very low power.  A DEV, regardless of its PM mode, is allowed to enter the SLEEP state during a CTA for which it is neither the source nor the destination, and between CTAs other than the beacon times and CAPs.  A DEV is allowed to enter the AWAKE state during any time when it is in a power save mode."


Comment:
"Incomplete statement in lines 49-50, page 214."

SuggestedRemedy:
"Change "system wake beacon" to "System Wake Beacon".  Change "and the wake beacon" to "and the Next Wake Beacon"."


Comment:
"Confusing statement in lines 50-51, page 214."

SuggestedRemedy:
"Change "A DEV that is in SPS mode may have multiple wake beacons" to "A DEV in SPS  mode may be in multiple SPS sets and hence may have multiple wake beacons in the sense that each of those SPS sets may have its own wake beacon."


Comment:
"Incorrect word form in line 6, page 215."


Comment:
Incorrect wording in the title of Table 63.

SuggestedRemedy:
"Change "PS rules" to "Power management rules"."


SuggestedRemedy:
"After "All other CTAs" add "and intervals" (between CTAs)."


Comment:
"Unwarranted word in line 40, page 215."

SuggestedRemedy:
"Delete "requested" before "system wake"."


Comment:
"Incomplete statement in line 46, page 215."


Comment:
"Incomplete specification in line 50, page 215."

SuggestedRemedy:
"After "desired system wake beacon interval" add "which may or may not be honored by the PNC"."


Comment:
"Incomplete specification in lines 53 and 54, page 215."

SuggestedRemedy:
"After "requirement changes" add "However, the PNC may not be able to honor the system wake beacon interval desired by the DEV if that interval is different from the interval requested by other DEVs also in PSPS mode."


SuggestedRemedy:
"Change "the 'unallocated set" value" to "a PS set index not yet allocated"."


SuggestedRemedy:
"Change "power save mode" to "power management mode"."


Comment:
"Incomplete statement in lines 18-19, page 217."

SuggestedRemedy:
"After "change its" add "power management".  After "set the bit" add "in the DEVID Bitmap field"."


Comment:
"Ambiguous wording in line 21, page 217."

SuggestedRemedy:
"Change "which are not using an SPS wake beacon interval" to "the CTAs of which are not announced only in wake beacons"."


SuggestedRemedy:
"Change  "at has" to "it has" and delete "as response"."


Comment:
"Incorrect word forms in line 34, page 217."

SuggestedRemedy:
"Change "set the bits" to "set the bit", and "status IEs" to "status IE"."


Comment:
"Incorrect wording in line 36, page 217."

SuggestedRemedy:
"Delete "the state of", change "is the same as" to "indicates", and change "this indicates that" to "then"."


Comment:
"Incorrect word form in line 53, page 217."

SuggestedRemedy:
"Change "ACTIVE mode DEVs" to "ACTIVE mode DEV".  Change "channel time request" to "CTA request"."


Comment:
"Unwarranted specification in lines 2-4, page 218."

SuggestedRemedy:
"Delete the words "and a channel time request…terminated"."


Comment:
"Unwarranted specification in lines 6-7, page 218."

SuggestedRemedy:
"Delete the statement "The SPS DEV may send…following the PS change command."."


Comment:
"Ambiguous specification in line 8, page 218."

SuggestedRemedy:
"Change "for the granted channel time" to "with the ID of the SPS DEV as the DestID"."


SuggestedRemedy:
"Change "and shall request that the PNC" to ".  The PNC shall"."


Comment:
"Incorrect word forms in line 10, page 218."


Comment:
"Incorrect naming in line 36, page 218."

SuggestedRemedy:
"Change "channel time request interval" to "CTR interval", which is suggested to be renamed "Rate" by this balloter."


Comment:
"Incorrect wording in line 39, page 219."

SuggestedRemedy:
"Change "3 actions" to "the following three actions"."


Comment:
"Ambiguous term in line 49, page 219:  What are "wake CTAs"?"


Comment:
"Ambiguous wording in line 45, page 220."


Comment:
"Incorrect wording in line 52, page 220."

SuggestedRemedy:
"Change "PS status bitmap" to "DEVID Bitmap in the PS Status IE"."


Comment:
"Incomplete specification in line 1, page 221."

SuggestedRemedy:
"After "the bit" add "in the DEVID Bitmap"."


Comment:
"Incomplete command name in line 9, page 221."


Comment:
"Incorrect word form in line 11, page 221."


Comment:
"Unambiguous specification in lines 12-13, page 221:  The PNC cannot tell when the HIBERNATE DEV is going to be awake, so in which beacon should it send the PCTM IE to the HIBERNATE DEV?"


Comment:
"Incomplete statement in line 15, page 221."

SuggestedRemedy:
"After "the stream" add "corresponding to the CTA request"."


Comment:
"Ambiguous wording in line 18, page 221."

SuggestedRemedy:
"Change "new allocation" to "the granted CTA"."


Comment:
"Incorrect wording in line 23, page 221."

SuggestedRemedy:
"Change "channel time request" to "the stream corresponding to the CTA request"."


Comment:
Incorrect illustrations in Figures 140-147.

SuggestedRemedy:
"Change "ACK" to "Imm-ACK" in each of these figures.  In Figures 141-143, change "PS set configuration command" to "PS Configuration Request command", and "PS set configuration response command" to "PS Configuration Response command".  In Figure 144, change "PSMode = PS" to "NewPMMode = PSPS/SPS" (2 occurrences) and "PS mode = PS" to "New PM Mode = PSPS/SPS" (2 occurrences).  In Figure 147, change "beacon in DEV-3's wake superframe," to "DEV-3's wake beacon:"."


Comment:
Incomplete figure captions in Figures 140-147.

SuggestedRemedy:
"In Figure 140, change "request command" to "exchange".  In Figure 141, delete "command".  In Figure 142, change "requesting to join" to "joining".  In Figure 143, change "requesting to leave" to "leaving".  In Figures 144-146, change "DME initiating PS" to "MSC showing DME initiated PM".  In Figure 147, change "Message sequence for DEV changing" to "MSC showing MLME initiated PM mode change". "


Comment:
"Incorrect term in lines 1 and 25, page 224."


Comment:
"Incorrect wording in line 35, page 225."

SuggestedRemedy:
"Change "IE data" to "Application Specific Data in this IE"."


Comment:
"Ambiguous specification in lines 47-52, page 225:  What is the "application data identifier field"?"


Comment:
"Undefined parameter in Table 64 in line 36, page 226:  This revision does not define or reference "mMinProcessedCTAs"."


Comment:
"Section 8.5 states "Each DEV shall support at least one isochronous stream."  This is an uneccesary requirement to place on all DEVs.  Some DEV applications may only have a need for asynchronous transfers."


Comment:
"Spec does not define what determines a "Lost Beacon".  Is it just not receiveing a beacon frame type at the expected time?  Or if data within the beacon is wrong or unexpected (such as PNID, DestID, SrcID, Time Token), such that the beacon be ignored and lost beacon counter incremented?  Some of this is implied but not explicitly specified."

SuggestedRemedy:
"Add table or text to describe which info within a beacon must be valididated.  Section 8.6.3, "Beacon Reception," would be a good location for such info."


Comment:
"In Table 61-Repeated beacon announcements, for the Clause field for Element PCTM has value 8.13.2.  However, only sub-clauses 8.13.2.2 and 8.13.3 have references to PCTM."

SuggestedRemedy:
"Replace Clause field for Element entry PCTM
-from: 8.13.2
- to: 8.13.2.2, 8.13.3"


Comment:
Impact of child/neighbor piconets on security needs further definition.

SuggestedRemedy:
Update clause 9.3.2 to detail that a child PNC is handled just like any other DEV and a neighbor PNC is allowed to send a subset of commands without security.


Comment:
ACL description should describe for what an ACL can be used.

SuggestedRemedy:
Update section 9.1.1 to read: An access control list (ACL) may be used to determine which DEVs are authorized to authenticate.


Comment:
Clauses 9.2.3 and 9.2.5 contain redundant material.

SuggestedRemedy:
Remove paragraphs two, three, and four from 9.2.3, and refer to 9.2.5.


Comment:
9.2.7 doesn't handle the case that the DEV couldn't verify the last beacon received, but has received a request to transmit a frame.

SuggestedRemedy:
Provide guidance in the text on this case, taking into account the need for streams to continue uninterrupted in the case of a PNC handover.


Comment:
9.2.7 and 9.2.8 should mention these things are done only in Mode 1.


Comment:
This format for SECIDs isn't enforced by the receiving DEV.

SuggestedRemedy:
Add a sentence to the end of 9.2.9: "A DEV that receives a SECID that does not follow this convention shall reject it."


Comment:
Clarify key usage for two DEVs with no peer to peer relationship.

SuggestedRemedy:
Change second to last sentence to read "If two DEVs in a secure piconet do not have a peer-to-peer security relationship, they shall use the piconet group data key for commands that are required to be sent securely and they shall use the piconet group data key for data frames transmitted between them."


Comment:
For readability, should move the mode discussion to 9.1.  That would allow text in 9.2 to refer to mode 0 and 1.


Comment:
The last sentence in 9.3.2 should be moved to 9.2.8.


Comment:
Some of this section is for people developing or proposing security suites.  It would be best off in an annex, or deleted.


Comment:
Command protection is missing from the bulleted list.

SuggestedRemedy:
Add command protection to the bulleted list.


Comment:
This figure should be an overview of the protocol, not the protocol itself.


Comment:
There are issues with devices not knowing the security properties of the authenticated device if the data variables data1 and data2 do not include all of the data included in the security protocol.

SuggestedRemedy:
Add a sentence after Figure 154: "Data1 and Data2 should include the contents of the frames exchanged during the authentication protocol."


Comment:
In 9.4, text is "The PNC may perform the authentication process using different security suites with different devices in the same piconet". In 10. In 10, text is Within a piconet, the PNC shall choose a security suite that will be used by all DEVs for authentication and ...."
It seems like a conflict. The text of 10 matches the intention.

SuggestedRemedy:
Change the text of 9.4 to match (or perhaps reference) that of 10


Comment:
Need to make it clear how we handle authentication or not for neighbor PNCs requesting channel time.  Likely we simply specify that this command is sent in the clear or we specify a different authentication procedure that does not hand out the group key.

SuggestedRemedy:
Figure out how authentication will be handled for neighbor piconets and document it clearly


Comment:
The PHY MIFS time for 55 Mb/s does not buy much in the way of efficiency (< 1 %), so set it to 10 us for simplicity sake.


Comment:
The pCCADetectTime is likely sufficient, but perhaps it could be somewhat longer to reduce the probability of collisions.

SuggestedRemedy:
Change from 4 to 5 or 6 CAZAC periods depending on the efficiency hit.


Comment:
The transmit PSD is appropriate for ZIF and super-het archictectures, but it isn't friendly to low-IF and VLIF architectures.

SuggestedRemedy:
Add an exception to the TX PSD, "The transmitter may have one in-band image with a relaxed PSD requirement of -40 dBr." (or better text).


Comment:
The pMinTPCLevel should be 0 dBm to match the rest of the TX power requirements.


Comment:
[PHY] While the extra 1 MHz of separation from the restricted band is a help, it does not out-weigh the problem of trying to co-ordinate with 802.11b.

SuggestedRemedy:
Change the channel 5 center frequency to 2.462 GHz to match 802.11b US channelizations.


Comment:
The backoff slot size specified in D15 is too small for CSMA/CA to work as intended.  CSMA/CA is a channel acquisition mechanism developed to minimize the probability of collisions in a CSMA setting.  The probability of collision can be controlled/limited by making appropriate protocol design tradeoffs between the size of the contention window and the number of DEVs contending.  The idea is that only DEVs whose backoff countdown values reach zero in the same backoff slot will collide.  
For 802.15.3 the channel acquisition process consists of the following.  When a DEV (say DEV A) counts down its backoff value to zero, it then turns off its receiver, turns on its transmitter, and begins transmitting.  Other DEVs (say DEVs B and C) will then hear DEV A's transmission, and thereby know the channel is occupied and suspend their backoff countdowns.  The problem is that D15's backoff slot size is too small compared to the Rx/Tx turnaround time and the CCADetectTime, with the result that other DEVs are able to countdown their backoff values to zero during succeeding slots and collide, even though they had higher backoff countdown values than DEV A.
The three time periods of interest are backoff slot size, Rx/Tx turnaround time, and CCADetectTime.  D15 defines the size of a backoff slot as pBackoffSlot, which is defined, in turn, as pCCADetectTime (D15p313L25) for the current PHY.  In its turn, pCCADetectTime is defined as four CAZAC periods, equivalent to 5.8181… usec.  Finally, the maximum allowable Rx/Tx turnaround time is defined as a SIFS interval, ie, 10 usec.  Note that a Tx/Rx turnaround time (SIFS) plus a pCCADetectTime together are 15.8181… usec, nearly three backoff slots.  This means that DEVs whose backoff value decrements to zero during the two slots following DEV A counting down to zero will also transmit and thereby cause a collision even though they had larger BO values. (I have a diagram showing this more clearly, but it doesn't paste to this text-only field)

SuggestedRemedy:
The solution is to increase the backoff slot size to be equal to the worst-case Rx/Tx turnaround (SIFS) plus pCCADetectTime, ie, 15.8181… usec.  This will minimize the probability of collision and thereby lead to greater throughput during the CAP (and the CSMA/CA mechanism working as intended).


Comment:
Are four CAZAC periods really enough to reliably detect if the channel is busy in all cases?  I'm not a PHY/RF guy, but I thought I'd bring it up.  Seems short compared to 802.11.


Comment:
The specification currently says (D15p341L1) that CCA detection time, pCCADetectTime, is four CAZAC periods.  Should a little additional time be added to pBackoffSlot to allow for the worst-case RF signal propagation delay plus a little HW signal propagation in the RF/BBP/MAC HW in addition to the four CAZACs?  I'm thinking of something like increasing from the current 5.8181... usec to 6 usec, something on that order.


Comment:
The low EVM values for the QAM modes will require very flat amplitude and group delay responses from the transmit filters - and hence greater cost. It seems likely that any demodulator that implements the QAM modes will include an equaliser quite capable of correcting moderate amounts of distortion in the transmitter anyway.

SuggestedRemedy:
Allow the ideal receiver used to measure these parameters to include an equaliser - perhaps also specify some larger EVM values for an unequalised measurement to keep some limits on the level of distortion allowed.


Comment:
"Incorrect wording in lines 19-20, page 330."

SuggestedRemedy:
"The polynomial generator, g(D), for the pseudo random binary sequence (PRBS) shall be."


Comment:
"There is an inconsistency between equation (8), which defines x_init, and Table 126. The vector x_init specifies the initial state for the scrambler as x_init = [x_(n-1)^i ... x_(n-15)^i], whereas Table 126 specifies the seed for the scramble as x_15 ... x_0. First, x_15 ... x_0 represents 16 bits, but only 15 bits are need to specify the initial state.
Second, how does x_15 through x_1 map onto [x_(n-1)^i ... x_(n-15)^i]?"

SuggestedRemedy:
Specify the mapping or correct the notation.


Comment:
802.15.3 doesn't have service classes (or shouldn't) so remove the error codes associated with service classes.

SuggestedRemedy:
Delete error codes 4 and 5 and renumber as appropriate.


Comment:
Annex A is the only place that service class is mentioned.  802.15.3 doesn't support these classes, so just delete them.

SuggestedRemedy:
Change "transfer: ... reorderable multicast." to be "transfer. For 802.15.3 the ServiceClass parameter shall be null." On page 351, line 24, change "IEEE 802.15.3 ... or strictly ordered." to "For 802.15.3 the ServiceClass parameter shall be null." on page 352, line 26, change "The ProvidedServiceClass ... as defined in A.2.1." to be "The ProvidedServiceClass shall be null for 802.15.3."


Comment:
Apparently, IntServ -type QoS might be able to be supported, beyond 802.1p.


Comment:
The specification of the CCM mode does NOT match the specification of this mode in 802.11 Tgi (contrary to the message conveyed by the 802.11/802.15 liaison Dan Bailey at the closing ceremony of the IEEE 802 meeting in Hawaii and all the way back in Sydney, when we were voting in symmetric key cipher suites to be used). See also the 802.11 Tgi submissions as of March 6, 2002 (02/001r1) and as of May 28, 2002 (02/001r2). See also Draft D2.5 of 802.11 Tgi that was released in Nov 2002 (Clause 8.3.4.4). Moreover, the AES-CCM mode specification in 802.11 TG I DOES match the officially submitted specification of this mode to NIST, with as reference "R. Housley, D. Whiting, N. Ferguson, Counter with CBC-MAC (CCM), submitted to NIST, June 3, 2002. Available from http://csrc.nist.gov/encryption/modes/proposedmodes/." Following the official NIST-submission would have obvious advantages, as this would allow single-chip implementations for devices that support both 802.11 and 802.15; it would allow proper cryptographic scrutiny of AES-CCM by the brightest cryptographic minds in the community without the need to translate the impact of their cryptanalysis on our current 'twisted' specification; it would also allow for simplified integer arithmetic.

SuggestedRemedy:
adapt the AES-CCM mode as specified in the current draft, such as to follow the official NIST submission specification. This is relatively straightforward, since it merely comes down to reformatting blocks in the presently described specification.


Comment:
the encoding of the integers L and M in the authentication flags octet (see Figure B.2) follows highest-order bit last conventions for encoding an octet as integer, whereas the length encoding (see Figure B.3) follows lowest-order bit last conventions (e.g., 0xFEFF corresponds to 216-28). The current inconsistency in integer representation conventions unnecessarily increases the complexity of implementing integer arithmetic.

SuggestedRemedy:
Suggested remedy: use lowest-order bit last conventions everywhere throughout all security specifications (e.g., 802.11 does this.)


Comment:
(and elsewhere): To avoid ambiguity, 'concatenation' should read 'right-concatenation'; similarly, 'appending' should read 'right-appending'.


Comment:
The last operation (on the XOR of Bn and Xn) has as output Xn+1 rather than T (since the tag T corresponds to a certain prefix of Xn+1 only).


Comment:
To avoid ambiguity, 'concatenation' should read 'right-concatenation'. Similarly, 'first' should read 'leftmost'.


Comment:
m is the plaintext, not the encrypted message.

SuggestedRemedy:
change 'encrypted message m' to 'encrypted message'. Alternatively, define the cipher-text in a more formal way and refer thereto. See also 02/469r0.


Comment:
This table is outdated.  Also, the ECMQV does not provide the same security assurances for linkage of data to the protocol, since it is not integrity protected.  See earlier comment.


Comment:
The word 'private' should be 'public' in line 51 on pg. 367.  Oops!


Comment:
the only assumption that is a physical assumption is the first one, which is an intrinsic property of wireless communication media.


Comment:
although the network size is restricted to at most 256 devices at any instance, this is not true over time (since devices may join and leave the network in an ad-hoc fashion and may not have met before). Thus, the security solution should scale arbitrary sets of devices (which may not have met before at all), rather than to a fixed set of limited size.


Comment:
specify the security threat model that is assumed at system set-up. Without a proper indication of the threats considered, one cannot draw conclusion on the security provided by the 802.15.3 WPAN.


Comment:
(and Pages 368-369, Annex C.5):  The security arguments should be based on proper security analysis and not merely on an ad-hoc informal argument (the latter might have been common place 20 years ago, but cryptography has moved on). Currently, the security analysis for the key establishment mechanisms based on NTRUEncrypt and RSA are based on such ad-hoc informal analysis. The security analysis of ECMQV is even obscured! (witness the reference on Page 368, line 21 to 'The security suite specifications in this document are able to specify other algorithms).

SuggestedRemedy:
Replace the ad-hoc security analysis of the public-key mechanisms by proper security arguments, both for each of the public-key mechanisms in the current Draft D15 standard, and for the symmetric-key based mechanisms, such as authenticated key transport, data encryption and authentication, and key updates.


Comment:
The selection criteria described in this clause miss any rationale. We give two examples: (1) 'time to market': not all the security suites are robust and time-tested security technology, witness the recent changes to NTRUEncrypt from Draft D11 towards D14 that were necessitated by recent attacks on their padding scheme and the non-acceptance of the NTRUEncrypt technology in any standard that is not controlled bt NTRU, Inc. (2) 'market suitability': to-date, there is not even a single published review of the adequacy of any of the protocols in the standard for 802.15.3 applications.

SuggestedRemedy:
completely remove this clause, as it is misleading.


Comment:
1the '802.15.3 security model' to which this clause refers is nowhere to be found!

SuggestedRemedy:
provide an adequate security model (the current wording is misleading).


Comment:
The text in the current draft - again - confuses authentication with authorization! (Note: The text below that I provided was originally accepted, but without reason, again, changed by the assistant security editors!).

SuggestedRemedy:
Replace this sentence by the following sentence: "For applications were trust in the authenticity of public keys is not established through the use of certificates, this has to be established via non-cryptographic means, e.g., via user intervention or pre-loading of keys in a controlled environment."


Comment:
The RSA-based and NTRUEncrypt-based public-key establishment protocols that are claimed to be based on TLS, but do deviate from this protocol in so many aspects that the suggestions as if the security analysis for TLS would also automatically apply to the ad-hoc variant of TLS used for the RSA- and NTRUEncrypt-based protocols is misleading.

SuggestedRemedy:
Provide a proper and adequate rationale that the variant of TLS used for the RSA-based and NTRUEncrypt-based public-key key establishment protocols is as secure as the underlying cryptographic primitives.


Comment:
The paragraph seems to assume behaviors of equipment which don't exist- and can't exist without some kind of a PAR in 802.11. 802.11 AP's (not 11b AP's) do not have any optional or normative ability to request neighbor piconet status.  And, change the paragraph to "802.11 overlapping with 802.15.3..."

SuggestedRemedy:
Remove the paragraph.  However, coexistence in timeCAN be accomdated if the INFORMATION element that was approved (see 802.15.2 coexistence) is used by the 2.4GHz AP.  Please state something to that effect.


Comment:
The power save requirements for 4 SPS sets for PNC capable devices will increase complexity for portable devices that need to be able to quickly communicate with another peer device since one of the devices will need to be the PNC. Because of this, all FD2 devices should not have a requirement to support 4 SPS sets.

SuggestedRemedy:
Change the PNC capable device requirement (FD2) to be the same as a non-PNC device for SPS sets. Remove FD2 from MLF23.3 on line 17.


Comment:
Since many portable devices will use embedded rechargable batteries, they will be able to operate as an AC powered device. However, their primary mode of operation will be as a battery operated device and need to be designed to operate efficiently. Requiring these devices to be able to support 4 SPS sets when they are connected to AC power will significantly increase their complexity as a batter operated device.

SuggestedRemedy:
Remove the 4 SPS set requirement for AC powered devices and just require a maximum of one SPS set for any PNC capable devices and do not make a distinction between battery operated and AC power devices for this power saving feature. Remove MLF23.3 from the table (delete lines 15-16).


Comment:
[PM/SPS-4] Delete MLF23.3  I don't have a problem with making Hibernate, PSPS and  1 SPS set mandatory. However, I do get heartburn when 4 SPS sets are mandated.  A 15.3 DEV can support up to 252 streams yet we only mandate that a DEV support at least 1 isochronous stream.  We leave it optional as to how many more streams a DEV or a PNC capable DEV may handle.


Comment:
The PICS does not reflect that CAP support is mandatory for this PHY.

SuggestedRemedy:
Add an entry to Table E.2 on page 289 with Idem Number "PLF7", Item Description "CAP mandatory", Reference "11.2.10", and Status "M".  Also add the text ", PLF7: M" to the Status entry of item MLF12.1 to indicate the CAP is mandatory when the 2.4 GHz PHY is used.


Comment:
[PM/SPS-4] Delete MLF23.3  I agree with Allen Heberling, I don't have a problem with making Hibernate, PSPS and 1 SPS set mandatory. However, I do get heartburn when 4 SPS sets are mandated.  A 15.3 DEV can support up to 252 streams yet we only mandate that a DEV support at least 1 isochronous stream.  We leave it optional as to how many more streams a DEV or a PNC capable DEV may handle.


Comment:
[PM/SPS-4] Delete MLF23.3  I don't have a problem with making Hibernate, PSPS and  1 SPS set mandatory. However, I do not like when 4 SPS sets are mandated.  A 15.3 DEV can support up to 252 streams yet we only mandate that a DEV support at least 1 isochronous stream.  We leave it optional as to how many more streams a DEV or a PNC capable DEV may handle.


Comment:
[PM/SPS-4] Delete MLF23.3  It is acceptable to make Hibernate, PSPS and  1 SPS set mandatory; however, mandating 4 SPS sets is unacceptable.  A 15.3 DEV can support up to 252 streams yet we only mandate that a DEV support at least 1 isochronous stream.  We should leave it optional as to how many more streams a DEV or a PNC capable DEV may handle.


Comment:
D15 PICS says (D15p393L41-46) that both CAP and MCTA are optional, but that at least one of them is required.  The specification also says (D15p315L42-44) for the 2.4 MHz PHY that support of the CAP is mandatory for DEVs and PNCs.  These conflict.  The conflict should be resolved as an editorial comment since it's just clarifying the intent.

SuggestedRemedy:
To resolve this conflict I suggest the PICS be changed as follows.  Add an entry to Table E.2 on page 289 with Idem Number "PLF7", Item Description "CAP mandatory", Reference "11.2.10", and Status "M".  Also add the text ", PLF7: M" to the Status entry of item MLF12.1 to indicate the CAP is mandatory when the 2.4 GHz PHY is used.


Comment:
PICS says that both CAP and MCTA are optional, but thatat least one of them is required.  The specification also indicates for the 2.4 MHz PHY that support of the CAP is mandatory for DEVs and PNCs.  These conflict.  The conflict should be resolved.

SuggestedRemedy:
To resolve this conflict I suggest the PICS be changed as follows.  Add anentry to Table E.2 on page 289 with Idem Number "PLF7", Item Description"CAP mandatory", Reference "11.2.10", and Status "M".  Also add the text ",PLF7: M" to the Status entry of item MLF12.1 to indicate the CAP ismandatory when the 2.4 GHz PHY is used.


Comment:
Delete MLF23.3. I agree with Allen Heberling, I don't have a problem with making Hibernate, PSPS and 1 SPS set mandatory. However, I will not support it when 4 SPS sets are mandated.  A 15.3 DEV can support up to 252 streams yet we only mandate that a DEV support at least 1 isochronous stream.  We leave it optional as to how many more streams a DEV or a PNC capable DEV may handle.


Comment:
"In Table E.4, item MLF17, Acknowledgement and retransmission, appears to be associated with sub items MLF18.1 to MLF18.5."

SuggestedRemedy:
"Either
 a)renumber MLF17 as MLF18 or
 b)renumber MLF18.x, with MLF17.x, where x is the respective subitem numbers."


# TypeList

TypeList:
[CommentType] In("TR") AND [ResponseStatus] Not In("C", "Z")


TypeList:
[CommentType] = "TR" AND [ResponseStatus] = "W"  AND [CommentStatus] In ("A","R")

Header:
Thank you for your participation in the recent IEEE 802.15 ballot. We have received your ballot.
not yet received an email from you confirming your reaction to the committee's 
proposed responses to your comments. Please take the time to let us know, 
for each item, whether each response, in your judgement, satisfactorily 
resolves your comment(s). 

If you would like, you may simply insert the word APPROVE, or DISAPPROVE, 
next to each comment and return this file.  That is all that is required.

In those instances where you indicate that you APPROVE or DISAPPROVE the committee's 
proposed response, our records will be updated. In those instances where you 
do not indicate a response, your vote will stand as previously submitted.

Thank you for your assistance.

Sincerely,
Dr. Howard Johnson, 
Chief Technical Editor of IEEE P802.3z Gigabit Ethernet

----**<copy of proposed committee responses attached>**----
>
>


TypeList:
[CommentType] In ("T","E") AND [CommentStatus] In ("A","R") AND [ResponseStatus] In ("W")

Comment:
The report "close T and E" will change these response statuses to "C"


TypeList:
[CommentType] In("TR") AND [ResponseStatus] Not In ("C","Z")


