# Main

Comment:
The 802.15.3 Chair directed the removal of all public-key key establishment mechanisms from the D15 Draft (see 03/054r1). It is however not clear at all on which rationale this decision was made. In fact, one could address Paul Nikolich’s comments (as worded in 03/54r1) by implementing just 1 public-key security suite (this removing choice). This would allow a standard that is functional and complete and was also the initial intention before politics entered the 802.15.3 stage.

SuggestedRemedy:
Revert the decision to drastically modify the security properties of the standard. Re-incorporate 1 authentication and key establishment-related security mechanisms, viz. the ECMQV security suite that was removed from the draft in the transition process from Draft D15 towards Draft D16. Re-consider all sponsor ballot comments related to Draft D15.


Comment:
In reviewing D15>D16 I noticed the removal of normative text i.e., security suites and that P802.15.3 has eight (8) Letters Of Assurance in the IEEE-SA Patent DB and six LOAs in the WG archive.  Specifically, a couple of these LOAs were submitted back in 12-Apr-2002 and 16-Oct-2002 and my guess is that some of these recent edits might affect these letters.

SuggestedRemedy:
No suggested remedy as there is no issue, just an editorial comment.


Comment:
Incorrect term used:  The term "controller" is used several times in place of "control", which should have been used as the networking term "MAC sublayer" (but not the implementation term "controller") is referenced here.  That is, an SDU may be a MAC SDU (versus a PHY SDU), but not a controller SDU, and a SAP may be a MAC SAP (versus a PHY SAP), but not a controller SAP.

SuggestedRemedy:
Replace all instances of "controller" in these subclauses with "control".


SuggestedRemedy:
Add "(n>1)" after "n superframes".  Change "more than once" to "at least once".


SuggestedRemedy:
Change "the contention free period and optionally the contention access period" to "a channel time allocation period and optionally a contention access period".


Comment:
Missing definition for "power management".

SuggestedRemedy:
Add a subclause to define "power management".


SuggestedRemedy:
Change "channel time access period" to "channel time allocation period".


Comment:
Misleading term used.  A frame with the "Dly-ACK request" bit set to 1 has to be acked immediately, but not at a delay.  Moreover, The name "Delayed ack" first appeared in 802.11e submissions because such an ack was introduced to deal with the delay due to MAC-level FEC, which in turn was proposed to 802.11e early on but subsequently removed.  For 802.15.3, the intent of such an ack policy is to not to address that delay which was not even present in this MAC, but to reduce overhead and hence improve efficiency.

SuggestedRemedy:
Change "Dly-ACK (delayed ack)" to "Grp-ACK (group ack)" here and throughout the draft.


Comment:
Incorrect use of "RIFS".  The term should not have been introduced since there would not be a unique value for "RIFS" as opposed to SIFS.  For instance, if the recipient did not return an Imm-ACK or Dly-ACK at all, the sender would mostly likely not have a PHY-CCA(busy) within the preamble time of the expected response, and hence would have a short "RIFS" for the next transmission (which may not necessarily be a retransmission as specified for RIFS).  On the other hand, if the recipient did return an Imm-ACK or Dly-ACK but the sender could not receive the entire returned frame correctly, the sender would have to wait for a longer "RIFS" for the next transmission--Even in the latter case, the "RIFS" interval further varies depending on such details as the HCS status and the length of the returned frame (Imm-ACK differs from Dly-ACK in length, and Dly-ACK itself has a variable length).

SuggestedRemedy:
Delete this term here and all references to it throughout the draft.


SuggestedRemedy:
Change the last sentence as follows:  "Unlike an isochronous allocation, an asynchronous allocation may be terminated by the source DEV, destination DEV, or the PNC, 8.5.2.2."


SuggestedRemedy:
After "power management" add "(PM)".  Add "the" before "PNC" in line 48.


Comment:
Change from "improve" the frame error rate


Comment:
Only one primitive is provided to transfer security messages.

SuggestedRemedy:
Change "Primitive are also provided" to "A primitive is also provided"


Comment:
The ReceivedFramePayload field should not contain the MAC header since it is provided in another field.

SuggestedRemedy:
Delete ",and MAC header" from Valid range entry.


Comment:
SecMsgTimeout not included in parameters table.

SuggestedRemedy:
Add additional entry in Table 14 following the SecurityInformation item:SecMsgTimeout - Duration - 0-65535 - "The time in milliseconds in which the operation initiated by the MLME request needs to be completed before responding with a ResultCode of TIMEOUT."


Comment:
Not clear what is provided when ReasonCode is:BAD-TIME-TOKEN - Beacon header and payload?

SuggestedRemedy:
Add following text in 6.3.9.2.3:"When ReasonCode is BAD-TIME-TOKEN, the ReceivedMACHeader is the MAC header of the beacon frame and the ReceivedFramePayload is the payload of the beacon frame."


Comment:
The ReceivedMACHeader and ReceivedFramePayload fields have been added to the MLME-SECURITY-ERROR.indication primitive, but this technical change was never discussed by the SBRC nor is it documented in the running comments. In addition, there does not seem to be any other reference to how these field are to be used and clause 9 of the draft indicates that any frame received that fails the security check will be discarded.

SuggestedRemedy:
Remove these two fields from the primitive since they are not required to perform any of the security related operations as defined in the draft. Delete "ReceivedMACHeader," and "ReceivedFramePayload" on page 50, lines 19 and 20. Delete ReceivedMACHeader and ReceivedFramePayload entries from Table 13 on page 49.


SuggestedRemedy:
Change "...command due to a timeout." to "...command or due to a timeout."


SuggestedRemedy:
After "exact", change "function" to "functionality".


SuggestedRemedy:
Change "2 octets" to "Octet string" here and in Table 12.


SuggestedRemedy:
After "primitives" change "is" to "are".  Change "primitive" to "primitives" in line 28.


SuggestedRemedy:
Change "the Announce command" to "an Announce command".


SuggestedRemedy:
Change "sends the Probe Request command" to "sends a Probe Request command".


Comment:
Incorrect/incomplete primitives defined.  Although the MLME-XXX.response is sent supposedly in response to an earlier request, so long as that request was not sent using the same base primitive, this MLME-xxx.response should be an MLME-xxx.request, and a corresponding MLME-xxx.confirm primitive should also be defined.  Recall how an MLME-SCAN.request, instead of an MLME-SCAN.response, is issued in response to a remote scan request.  The MLME-xxx.indication is correct but incomplete.  Subclauses for "When generated" and "Effect of receipt" are missing.


SuggestedRemedy:
Change the first sentence as follows: "The primitive parameters are as follows:"


Comment:
Incorrect grammar ("either" may be used only when two items are concerned).


Comment:
Incorrect punctuation & Incomplete reference.

SuggestedRemedy:
Change the semicolon to comma.  Change "following two" before "tables". Change "it" to "the".


SuggestedRemedy:
Replace the leading "MAC" in the name of each managed object with "m".


SuggestedRemedy:
Change "For each stream, all MSDUs" to "All MSDUs of a given stream". Change "in the order that" to "in the order in which". Add "the" before "Dly-ACK policy" (2 instances). After "MAC" add "when there are retries".


SuggestedRemedy:
Change "and will return" to "except to return an".


Comment:
Unwarranted restriction.  There are no grounds of prohibiting async data from using Dly-ACK.  In fact, clause 8 mentions the use of Dly-ACK for async data.


SuggestedRemedy:
Change "is either due to a TX_TIMEOUT expiration or that" to "results either due to a TX_TIMEOUT expiration or because".


SuggestedRemedy:
Change "either due to a TX_TIMEOUT expiration or that" to "results either due to a TX_TIMEOUT expiration or because".


Comment:
Apparently missing definitions for New Channel Index, Superframe Timing, PNID, and BSID.

SuggestedRemedy:
Add a sentence that says "The New Channel Index, Superframe Timing, PNID and BSID fields are defined in {xref Table 52)."  Add xrefs in all of the table entries to the locations where these fields are defined.


Comment:
With the new probe response command it would be nice to have an IE that returned an error code, i.e. 'unknown IE' or perhaps an error code in the probe response command, one octet for a reason and the other with the element ID of the problem IE.

SuggestedRemedy:
Add the error code to probe response unless there is a reason why an 'undefined IE' element ID or IE is required.


Comment:
There is no way to provide feedback on the result of an announce command.

SuggestedRemedy:
Add an announce response command with pairs of octets, the number determined by the length of the command.  The first octet is the element ID of an IE that was received in an announce command, the second is a Reason Code with the following (and possibly more) values: 0 -> IE stored successfully, 1 -> Unrecognized element ID, 2 -> Unsupported IE, 3 -> IE dropped due to problem at destination (e.g. lack of buffer storage), 4-10 -> Element ID specific reasons, defined by the IE if required, 11-255 -> Reserved.


Comment:
The standard does say that only members of the piconet can request channeltime. From page 183 line 14:"The DEVs that are members of the piconet shall use the Channel Time Requestcommand, 7.5.6.1, wheneverthey wish to make a change in their CTAs."However, even though the Dev Association IE contains "Association Status"and the PNC Information command contains a "Membership Status", the standardis written such that the Assoc IE conveys membership. From page 126 lines19-21:"The DEV Association information element shall be formatted as illustratedin Figure 29. This IE is used to notify current members in the piconet abouta recent change in the membership status of one or more DEVs which haveeither just become members of the piconet or disassociated from thepiconet."This should probably be rewritten to such that the Dev Association IEconverys association status only. The PNC Information command section shouldprobably be beefed up to make it clear that this command conveys membershipstatus if that is what we want.

SuggestedRemedy:
Change text to indicate that the Association IE only indicates that a DEV is associated.


Comment:
Stylistic inconsistency.  Not all the first letters of the words that form field names are capitalized (especially in figures and figure captions).

SuggestedRemedy:
Capitalize the first letters of ALL the words that form field names.


SuggestedRemedy:
After "frame check sequence" add "validation". Change "with ACK Policy" to "with the ACK Policy". Change "DestID is the DEVID" to "DestID set to the DEVID of this DEV".


Comment:
Unwarranted separation of Delayed-ACK Request from ACK Policy.  A precious bit is wasted and an additional time critical parsing step is needed.

SuggestedRemedy:
Use the yet unused bit combination in the ACK Policy subfield to indicate "Delayed-ACK Request", and merge reserved bits into a reserved subfield.


SuggestedRemedy:
Change "field" back to "bit" or "subfield".


SuggestedRemedy:
Delete "field" from heading.  In the next line change "field" to "bit".


Comment:
Incorrect heading, incorrect punctuation and undefined term.  What are "valid DEVs"?

SuggestedRemedy:
Change the heading to "SrcID and DestID". Delete the two commas in line 23.  Clarify the term "valid DEVs".


Comment:
Misleading naming and unwarranted subfield.  "Sequence Control" is a much better name than "Fragmentation Control", especially when no fragmentation is being used as may be expected on a super data rate PHY.  The "Last Fragment Number" has little practical benefits but consumes a precious octet in the MAC Header of EACH frame.  There are also no grounds of defining such a long (7-bit) Fragment Number subfield.

SuggestedRemedy:
Rename the field as "Sequence Control", delete the "Last Fragment Number" subfield, and reduce the "Fragment Number" subfield length.


Comment:
Incorrect spelling & wording.  BTW, you really don't want to use "for example" as a normative way to define a field.

SuggestedRemedy:
Change "upling" to "uplink". Change "be using only the CAP to provide access to the PNC" to "is using only the CAP for transmission of command frames to the PNC".


SuggestedRemedy:
Delete the redundant "the" and capitalize the first letters of "max frames" and "max burst".


SuggestedRemedy:
Change "that CTA" to "those CTAs".  Also add "that" after "indicates" in this subclause (several instances).


SuggestedRemedy:
Change "Reason Codes" to "values of Reason Code".


SuggestedRemedy:
Change "authenticated relationship" to "security relationship".  Capitalize the first letters of "frame control" (in lines 13 & 52).


SuggestedRemedy:
Change "one less than the Total Number of Frames" to "Total Number of Frames minus one".


SuggestedRemedy:
Delete "sending" from the table heading.


SuggestedRemedy:
Delete the second "with" in line 4.  Delete "either" in line 50.5.


Comment:
Incorrect specification.  The use of CTR time unit as the time unit for CTAs does not account for variable frame transmission times nor retries within the same CTA.  Transmission time may vary from frame to frame due to data rate (and potentially preamble) changes, the variable bit rate nature of the stream, and throughput considerations.  For instance,  an 1394 ISO packet may contain 0, 1, or 2 small MPEG cells (188 bytes).  Such variable length packets themselves may be further aggregated either at the so-called FCSL or right at the MAC (even though the current spec has no such aggregation mechanism) to make efficient use of the 100 Mb/s plus data rates being specified in 802.15.3a which is to be using this MAC.  On the other hand, a retry does not occur right after a prefixed CTR time unit.  Note that if CTA is not specified correctly, this MAC will just fall apart.

SuggestedRemedy:
Delete the newly introduced MIFS CTRq TU field and use natural time units, instead of "CTR time unit" to define the duration of each CTA (but not per "CTA Rate Factor") being requested.  Suggest to rename "CTA Rate factor" as "CTA Repetition".


Comment:
Incomplete specification.  What is the unit of Wake Beacon Interval and Next Wake Beacon?


Comment:
A lot of less important information is spread during the periodic piconet information broadcast (8.3.3). In stead of sending the whole PNC information (7.5.4.2) the PNC could send the DEV association IE, either using the Announce command (7.5.5.2) or the beacon. Only one bit of interest is missing in the DEV assoc IE to make that possible. PNC capability, requested system wake beacon interval  and ATP is of little interest to other DEVs.

SuggestedRemedy:
Add a bit to the DEV status field. Name "membership status". Definition identical to PNC information command, DEV Info Utility field, 7.5.4.2. Rules during association: set to 1 if association = membership otherwise 0 => no difference.


Comment:
If there was a "T-" or "E+" comment type, this would be it! Mark suggested a long time ago that we should harmonize all "countdown IEs" and instead announce the beacon number of  the change. I didn't pick up on it at the time and it got forgotten. Now Piconet Parameter Change and PNC Handover are now the only two IEs left with countdown. A change has little technical significance and will cause review of text in 8.2.3, 8.10, 8.11 and maybe more. The advantage is some reduction of PNC complexity. Before closing this for good, I'd like to explore  if changing makes sense. If so, do we announce last beacon number before change or first after (which could be the next PNC if handover).

SuggestedRemedy:
Explore replacing the countdown field with a beacon number field.


Comment:
If we don't have authentication frame exchange defined on the MAC layer level, why do we have key request and distribution? You can hardly get a key without authentication? If it is the SBRC's opinion that  security frame exchange shall be outside the MAC, then we should be consistent about it. I stand neutral as long as we stick with one decision.

SuggestedRemedy:
Either remove 7.5.2, 7.5.4.3, 7.5.4.4, 7.5.9.1 and corresponding  primitives in clause 6, or reinstate the authentication/challenge exchange.


Comment:
The standard clearly states that the DEV is responsible for calculating it's needed channel time and also to make sure it stays within it. The decision to use MIFS or SIFS is DEV internal and the DEV should also take that into consideration when figuring out it's own internal guardtime at CTA start and end. The new MIFS CTRq TU bit puts extra calculation efforts on the PNC for no good reason. Let the DEVs handle this like they do with all other CTA related calculations. The PNC should be allowed to allocate adjacent CTA at its leasure and trust that the DEVs leave enough space at the CTA boundries.


Comment:
It would be helpful for DEVs to have a way to continuously monitor the channel quality between itself and other DEVs in the piconet.  Monitoring the MCTAs would be a good way, but DEVs are not required to always transmit in their MCTAs.

SuggestedRemedy:
Add the following DEV capabilities bit:  MCTA_Always_TXAdd the following text: The MCTA_Always_TX bit indicates that the DEV always transmits a command in its assigned MCTAs, whether or not it needs to send anything as described in 8.4.3.3.  Add the following to 8.4.3.3: A DEV with the MCTA_Always _TX capability bit sent always transmits a command its MCTAs, even if it has nothing to send.  This allows other DEVs in the piconet to monitor the channel conditions from other DEVs.  It is recommended that a DEV send a null probe when it has no other command to send.


SuggestedRemedy:
Add the following DEV capabilities bit:  MCTA_Always_TX

Add the following text: The MCTA_Always_TX bit indicates that the DEV always transmits a command in its assigned MCTAs, whether or not it needs to send anything as described in 8.4.3.3.

Add the following to 8.4.3.3:
A DEV with the MCTA_Always _TX capability bit sent always transmits a command its MCTAs, even if it has nothing to send.  This allows other DEVs in the piconet to monitor the channel conditions from other DEVs.  It is recommended that a DEV send a null probe when it has no other command to send.


Comment:
Move text up a paragraph and merge with text that is redundant.

SuggestedRemedy:
Move 'If the requesting DEV included SIFS-MIFS following the last MIFS as shown in Figure 113 it shall set the MIFS CTRq TU in the Channel Time Request to zero. If the SIFS-MIFS time is not included in the CTRq TU, the MIFS CTRq TU bit shall be set to one and the PNC shall add SIFS-MIFS to the CTRq TU to calculate the duration of the CTA.' to the paragraph above and merge with the existing text that is redundant.


Comment:
Figures 121, 122, 123 missing request timeout timers.


Comment:
Figure 102When the PNC sends the Association Response command with the newly assignedDEVID for the associating dev it waits for an second Association Requestcommand from the associating dev with the newly allocated DEVID. The PNCshould start a timer when it send the Asssociation Response command tohandle the situation where the associating dev doesn not response in areasonable amount of time. When this timer expires, the association processshould be aborted by the PNC. If the dev that was associating sends thesecond Association Request command after the PNCs timer expires, the PNCneeds a way to tell the associating dev that it is really not associated.Therefore, a second Association Response command should be sent by the PNCin response to the second Association Request command because the receptionof an Ack is not sufficient for the associating dev to assume it isassociated. NOTE! THIS IS NOT A VALID ARGUMENT FOR USING THE BEACON AS THECONFIRMATION FOR THE ASSOCIATION REQUEST. THE BEACON METHOD HAS ALEADY BEENDETERMINED TO BE FLAWED BECAUSE IT HAS BEEN SHOWN THAT THE REQUESTING DEVAND THE PNC CAN VERY EASILY GET OUT OF SYNC EVEN IF NO MESSAGES ARE LOST.

SuggestedRemedy:
Have the PNC send another Association Response command that allows the PNC to tell the associating DEV that there is a problem. Perhaps the disassociation command could be used to do this?


Comment:
It seems odd to me that we have MLME-TERMINATE-STREAM.ind but not a MLME-CREATE-STREAM.ind. If the target of a stream generates an indication  when it receives a null-cta (figure 121), why wouldn't we want to generate an indication when it discovers it is the target of a stream (figure 115)?

SuggestedRemedy:
Add an MLME-CRREATE-STREAM.ind and add it to the appropriate locations in the MSCs


SuggestedRemedy:
Add "a" after "sending" in line 29.5.  Delete the second "as" in line 32.5. Change "this case" to "the latter case" in the same line.  Change "the PNC" to "another PNC" in line 36.5.  After "send" change "the" to "a" in line 43.5.  Change "When" to "Once" in line 46.5.  After "using" change "the" to "a" in the following line.  After "send" change "the" to "a" in line 48.5.


SuggestedRemedy:
Change "put the" to "place a" in line 16.


SuggestedRemedy:
Change "and not" to "but not" in line 52.  Add "a" before "PNC handover" in the following two lines (2 instances).


SuggestedRemedy:
Change "change type" to "Change Type field" in line 27.5.


SuggestedRemedy:
Change "sending the" to "sending a" in line 35.5.  Change "and not" to "but not" in line 37.5.  Replace "authenticate" with a new term in line 39.5.  Delete the second "as" in line 40.5 and add "the" before "target" in the same line.  Change "the PNC" to "a PNC" in line 42.5 (2 instances).  Change "the PS" to "a PS" in line 43.5.  Change "using the" to "using a" in line 44.5.


SuggestedRemedy:
Change "authentication" to an appropriate term in line 1 and "during time" to "during the time" in the same line.  Change "only occurs during time" to "occurs only during the time" in the next line.  Add "the" before target DEV" in line 44.5.  Change "lets the dependent PNC know" to informs the dependent PNC" in line 46.5.  After "ready" add "to" in the next line.


SuggestedRemedy:
Rephrase "the last superframe that it will be the PNC using the procedure indicated in 8.2.3" in lines 3-4.  After "it" add "is" in line 8. Change "time that" to "time when".  After "sending" add "a" in line 11. Change "and" to "but" in line 15.  Delete the second "as" in line 20. Change "send the" to "send a" in line 21.  Delete "over" in line 23.


SuggestedRemedy:
Change "that has the same SrcID and DestID" to "for which the SrcID and DestID are identical" in line 1.  Change "source and destination addresses" to "SrcID and DestID fields" in lines 1-2.  Change "set to be" to "set to" in line 2. Change "stream index shall be set to zero" to "Stream Index field to zero," in lines 2-3.  Change "send the" to "send a" in line 8.  Change "configures" to "shall configure" in line 11.  Change "contains the" to "contains a".


SuggestedRemedy:
Change "authenticate" to an appropriate term in line 8.


SuggestedRemedy:
Change "the Parent" to "a Parent" in line 29.


Comment:
Incorrect grammar/wording.  Dot not use "either" for more than two items.

SuggestedRemedy:
Delete "either" in lines 20, 21 & 49.  Change "perhaps" to "such as" in line 20. Change "capable to take" to "capable of taking" in line 21. Change "will" to "shall" in line 22.  Change "places the PNC shutdown" to "shall place a PNC Shutdown" in line 27. After "IE" add a comma and delete "either" in line 36.  Add "arrival" before "time" in line 37.


SuggestedRemedy:
Add "DEV" before "Association IE" in this figure and some other figures as well.


SuggestedRemedy:
Change "send the" to "send a" and add "the" before "newly" in line 2. Add a comma after "that is" in line 4, page 178.


SuggestedRemedy:
Change "it has joined and will" to "that DEV has joined and shall" in line 48.


SuggestedRemedy:
Change "the" to "a" in line 52 (3 instances).


Comment:
Incorrect specification.  The inclusion of MCTAs in the CTAP is not reflected.

SuggestedRemedy:
After "streams" add "as well as commands" in line 53. After "individual" add "and/or group" in line 2, page 180.


SuggestedRemedy:
Change "Dly-ACK Request bit not set" to "the Delayed ACK Request bit set to 0".


SuggestedRemedy:
Change "applicable for" to "be applied to" in line 43.  Add "to" after "required" in line 49.


Comment:
Incomplete specification.  In this insufficient time case, how should the DEV reset its backoff counter? Or should the DEV start its transmission right after the next beacon if the next CAP is allowed for such a transmission?


Comment:
Incomplete description.  This subclause barely mentions slotted-Aloha based MCTAs which yet are part of the CTAP.

SuggestedRemedy:
Change "allocated a CTA" to "given a directed CTA" in line 3. Change "occupies mFirstCTAGap" to "follows the beacon without the mFirstCTAGap restriction" in line 26.  Delete "location of the" in line 33.  Change "locations" (which means starting times in this spec) to "intervals" in line 34.  Change "PDU" to "frame" in line 36. Change "may" to "should" in line 40.  Change "location" to "interval" in line 42. After "destination" add "DEV" in line 42.  Change "If the destination wants to avoid this, it would need to" to "To avoid this, the destination DEV should" in line 43. Change "if" to "for which" in line 2, page 183.


Comment:
Incomplete specification.  The benefits of having DEVs to stay AWAKE all the time or in some selective CTAs not destined to themselves should be explored here.

SuggestedRemedy:
At the end of line 26, add the following:  The source DEV may also send a frame to a destination DEV in a CTA assigned to that source but not destined to that destination DEV, provided the source DEV has determined that the destination DEV will be receiving in that CTA.


SuggestedRemedy:
Add "the" after "If" in line 2.  Change "will need to use" to "shall use" in line 3. Change "sending the" to "sending a" in line 4.


SuggestedRemedy:
Change "number targets" to "Num Targets" and "target ID" to "Target ID" in line 36.


Comment:
Undesirable specification.  The use of the MIFS CTRq TU field for calculating the channel time is based on fixed frame transmission boundaries which do not hold in the case of retries.

SuggestedRemedy:
Remove the MIFS CTRq TU field from the draft and all references to it.


SuggestedRemedy:
In lines 4-5, change "all streams where the target DEV is in a power save mode and for streams with the TrgtId set to BcstId or McstId if any DEV is in a power save mode" to "those streams for which the destination DEV, or any intended destination DEV in the case of broadcast and multicast streams, is in power save mode." In line 6, change "all streams where either the PM CTRq Type, the CTA Rate Type, or the" to "those streams for which one or more of the PM CTRq Type, CTA Rate Type, and". In line 15, change "either be" to "be either". In line 35, change "modifications or the termination" to "modification or termination".


SuggestedRemedy:
In line 31, change "individual" to "group".  In line 32, change "group" to "individual".


Comment:
Incorrect specification.  The Retry bit must never be used for duplicate frame filtering.  Why?


SuggestedRemedy:
In line 33.5, change "when" to "the appropriate time".


SuggestedRemedy:
In lines 16-17, change "are available" to "may use".


SuggestedRemedy:
In line 27, delete "for".  In line 52, delete "mode".


SuggestedRemedy:
Change "associate" to "associating" and "or request" to "and requesting".


Comment:
The text "If the piconet is a dependent piconet" could be ambigous, since it doesn't clearly state that both PNC capable DEVs are in the same dependent piconet in this situation.


Comment:
This comment also regards Figure 94 on page 164 and Figure 99 on page 170 and Figure 101 on page 172. MSC references should have a reference to an MSC, otherwise they are not MSC references (sic!). In the case of "becoming member", the association procedure in Figure 102 should be referenced. Figure 118 describes modifying a stream. Text should also reference the appropriate security suite MSCs for authentication (if used) and optional security handover.

SuggestedRemedy:
Make references as paragraphs in the text following the MSC in Figure 94 and 95. Same in figure 99 and 101. I do not recommend putting the reference text inside the symbol in the MSC since it would make the use of {xrefs} impossible.


Comment:
The Piconet Services Inquiry bit can be set in any or both of the two association requests to trigger the PNC to send the services command after completed association.

SuggestedRemedy:
In the MSC, delete the word "first" in the MSC reference text "... set to one in the first Association Request command..."


Comment:
The current broadcast has two problems. First it sends information that is of little interest to other DEVs, i.e. PNC capability, ATP and desired system wake beacon interval. That is because a handover command is used instead of an appropriate IE. The current DEV association IE fills all needs if one membership status bit is  added. DEVs can always request other info if they need it. The second problem is that the PNC is forced to use a command, even if it would have fit in the beacon. This is very inefficient for simple solutions for small piconets, where only the address resolution table is of interest to share.

SuggestedRemedy:
Change txt to: "... at least every mBroadcastDEVInfoDuration with the DEV association IE (7.4.4) using either the Announce command (7.5.5.2) or the beacon. When the PNC broadcasts the piconet information, the PNC shall ..." The needed membership status bit in 7.4.4 is mentioned in another comment.


SuggestedRemedy:
Delete page 188 line 33-39 and page 189 all reference to MIFS CTRq TU. The figures can stay to illustrate what the DEV needs to calculate. The PNC only allocates raw CTA and the DEV has to figure out how to use it.


Comment:
The suggested scheme is very inefficent, since it forces a PNC that wants to use extended beacons to also allocate MCTA for the following beacon and to enqueue it appropriately. In most implementations it's likely that there are separate queue entities for beacons and commands for timing reasons. All of this overhead is completely unnecessary. We have the moredata bit set. Just let  the PNC continue to send Announce commands with SIFS intervals until it's done (MIFS may be hairy in beacons?). The beacon transmission period is, from the PNC's internal point of view, a CTA where it can fit a certain amount of frames. The PNC desides this "beacon CTA" and will make sure it has enough space for a beacon + desired amount of Announce commands. Sending them in one slot also saves power for the listeners.

SuggestedRemedy:
Change page 201 line 44-52 to say that the PNC sends extended beacons by setting the moredata bit in the beacon and all but the last Announce and sends them all in a burst before the CAP or CTAP.


Comment:
Keep table from D15 with the conditional IEs. It was informative.

SuggestedRemedy:
Reinstate D15 Table 56. Add IEs rather than withdraw from it.


Comment:
What is the location in the CTA block? In 8.4.3.2, page 183, line 19 it says that it is referenced to the start of the beacon frame, 8.6.5? Start as in preamble? header? HCS? Body? 8.6.5 gives no clarification. Using the start of the preamble isn't good for two reasons: - You don't know it's a beacon before it's too late. - You don't necessarily know that you just received the first   symbol since some are repeated (like CAZAC) and the first   n symbols could have been missed. The best sync point seems to be after reception of HCS. 802.11, 11.1.2, defines the sync point as the transmission of the first bit of the timestamp (TSF), which is the first bit of the beacon frame body. Since the TSF is transmitted in the beacon, synchronization based on transmitter time is possible. In our case, we have to trust that beacons are sent exactly  at TBTT and let the receiver sync on calculatable delays referencing a point in the frame that is unambigous.

SuggestedRemedy:
Define the 802.15.3 synchronization point to be the start of the first symbol after the HCS. All DEVs know it's a beacon at  that point and they can discount their own HCS decoding latency and other known Phy delays.


Comment:
"piconet parameter change" should be capitalized throughout 8.10.3. Replace numerous "information element" with "IE".


Comment:
"piconet parameter change" should be capitalized throughout 8.11.1. Replace numerous "information element" with "IE".


Comment:
Inconsistent naming for the shared date key.

SuggestedRemedy:
Each instance of the piconet-wide group data key should use that name rather than "piconet protection key", "piconet-wide group key", etc.    In particular, pg. 234, line 44, and in Table 61, but I believe there are several others.


Comment:
We describe what a DEV does with unexpected values in the beacon in multiple places.  This is redundant information found in 9.3.6.

SuggestedRemedy:
This paragraph should be deleted and we should simply add a sentence that says "A DEV may use the beacon to determine that the piconet-wide group data key has been changed and initiate a key request process, 9.3.6."


Comment:
My apologies that this comment isn't more specific, but time didn't permit a more helpful suggestion.  We should be sure that we are clear about when we use the term "authentication" and when we use "group membership".  Authentication is used in many places where group membership may be more appropriate.  Having clear definitions of each of these terms should help us clean up the draft to be clearer about what these different functions mean.  In particular, we need to be clear that when the MembershipStatus is set to MEMBER, that information dictates the key used in Table 61.

SuggestedRemedy:
Use the following definitions as guidelines for changes in the standard where the term "authenticated" (or "authentication") is used.Authenticated: The MLME considers another device to be authenticated if the membership status associated with that device is set to member.  Note that this does not require that they share a key.  All keys may be absent, in which case the device is unable to send or receive secure commands to the device (or piconet) in that relationship.  Authentication process: The authentication process is an out-of-scope operation that may happen between DEVs to establish group membership with each other.  The result of a successful authentication process is that the DME of each DEV sends an MLME-MEMBERSHIP-UPDATE.request to its MLME indicating that the DEV has a secure membership relationship with the other DEV.Establishing secure membership: Synonymous with authentication process, but should be preferred generally in the standard, since secure membership is all the MAC/PHY is aware of.Secure member of the piconet: When the DEV has the membership status with the PNC set to MEMBER. Secure relationship: Defines the relationship with another DEV that is authenticated.  In other words, a DEV has a secure relationship with another DEV (or secure membership in the piconet if the relationship is with the PNC) if that DEV is a secure member with the other DEV.  Note that the MLME does not know whether it is considered to be a secure member by the other DEV.


Comment:
This information is redundant.  We should describe what keys are to be used in 9.3.8 only.

SuggestedRemedy:
Add a pointer to 9.3.8 instead of these paragraphs.


Comment:
It is more accurate to describe frame generation in mode 1 than to say "secure frame generation".

SuggestedRemedy:
The title of this section should be changed to say "Mode 1 frame generation".  We should also clarify in the paragraphs that these sections define the rules for mode 1 frame transmission and reception.


Comment:
This sub-clause should describe frame reception in mode 1, not just "secure frame reception".


Comment:
This paragraph only talks about command frames.


Comment:
The description of what the rules are for the selection of the SECID was removed.  The shall in line 8 makes no sense without the rules defined.

SuggestedRemedy:
The previous text should be put back in.


Comment:
Conflicting and almost duplicate sentence of the previous sentence.

SuggestedRemedy:
Delete this sentence and add the word "secure" before "data" in line 23.  This gets across the point that IF a secure data frame is sent, it SHALL be sent with the piconet-wide group data key.  Note that piconet group data key should be changed to piconet-wide group data (or whatever will be consistent through the draft).


Comment:
This should be updated to indicate that the keys used are strictly dependent on the membership states for the various DEVs in the piconet.  The DEV needs to select the key based on whether it is a member with the peer and then if it is a member with the PNC.

SuggestedRemedy:
Change first sentence to "The key used to protect a particular frame depends on the purpose of the frame and the membership states of the DEV.  If the DEV is in a secure piconet (i.e. the DEV is the PNC or the DEV is a member with the PNC), the DEV will have entries for the piconet-wide group data key and for the PNC-DEV management key.  If the DEV has a secure relationship with a peer-DEV (i.e. the DEV is a member with a peer DEV), the DEV will have entries for a peer-to-peer data key and a peer-to-peer management key that it shares with that DEV.  For any given frame, the DEV shall either send the frame without security if required or with the single key that is required for that frame.  If the key that is required for an outgoing frame has length 0 (i.e. the key is not present, but the relationship is set to MEMBER), the DEV shall not send the outgoing frame.  If the key that is required for an incoming frame has length 0 (i.e. the key is not present, but the relationship is set to MEMBER), the DEV shall reject the incoming frame."


Comment:
This part of the document is normative not informative.


Comment:
The state machine needs to show only 2 state machines per target DEV.


SuggestedRemedy:
Change "The standard support the" to "The standard supports the"


Comment:
The opening sentence has not been corrected to reflect the change from defining policies to defining mechanisms.

SuggestedRemedy:
Change the sentence on lines 13-14 to: "Security mechanisms provided by this standard allow security services to be implemented to control the admission of DEVs into a security relationship between the PNC and a DEV or between two ordinary DEVs and protect the information and integrity of communications between DEVs in a security relationship."


Comment:
This paragraph implies that the standard does not provide anything to support the authentication of DEVs. The Security Message (xref 7.5.9.1) has been included to allow implementation of an authentication protocol.

SuggestedRemedy:
Add sentence following "...not specified in this standard.", "The Security Message has been included as a special command to assist in the implementation of vendor specific authentication protocols."


Comment:
Extra information included that is not necessary.

SuggestedRemedy:
Delete ", often referred to as a message authentication code,"


Comment:
Text implies that CTAs must be used for authentication while this may be done in the CAP without using any CTAs.

SuggestedRemedy:
Change "should set up CTAs" to "should allow"


Comment:
Page numbering in the document seems to be broken. Section 9 ends with page numbered 296 and then Section 10 starts with a page numbered 263. Similarly Section 10 ends with a page numbered 298 and Section 11 starts with a page numbered 273.


Comment:
The changes to the D15 draft are so dramatic that a sponsor ballot period of only 15 days is completely inadequate for proper review by all members of the sponsor ballot pool. The Comparison document (p802.15.3_00000D16P802-15-3__Draft_StandardCMP) is unreadable: due to the many strike-outs a proper comparison of D15 with D16 is impossible. Moreover, dramatic changes of the type incorporated in Draft D16 evidence that the decision to move to the sponsor ballot stage of the standardization process was completely inappropriate. The draft should be reviewed by the complete TG3 membership, not just members of the sponsor ballot pool.

SuggestedRemedy:
Stop the sponsor ballot review process and go back to letter ballot stage; this standard is obviously and demonstrably not ready for prime time!


Comment:
The 802.15.3 Chair directed the removal of all public-key key establishment mechanisms from the D15 Draft (see 03/054r1). It is however not clear at all on which rationale this decision was made. In fact, one can easily provide technical arguments that the decision lacks any justification and is not based on sound professional or engineering arguments The 802.15.3 standard without proper entity authentication and key establishment mechanisms is a standard that cannot be implemented by industry, since it is incomplete. Moreover, no concrete suggestions are done how to provide adequate specifications for this functionality. Without this, this standard cannot be implemented by industry and will not be used or used with considerable delay. Last, but not least, the decision on what is supposed to be inside scope and what isn’t seems to be based on arbitrary arguments. For a detailed rationale considering this comment, see the document I will post during the March 2003 Dallas meeting and the presentation I intend to give there.

SuggestedRemedy:
Revert the decision to drastically modify the security properties of the standard. Re-incorporate all authentication and key establishment-related security mechanisms that were removed from the draft in the transition process from Draft D15 towards Draft D16. Re-consider all sponsor ballot comments related to Draft D15.


Comment:
Text implies that CTAs must be used to perform the authentication process.


SuggestedRemedy:
Change "that DEV that" to "any DEV that"


SuggestedRemedy:
Delete sentence "The MLME-MEMBERSHIP ... used to update and delete keys in the MAC/MLME."


Comment:
Sentence references something that was "described above" but is no longer described in this section.

SuggestedRemedy:
Change "as described above" to "as described in {xref 7.2.7.2}"


Comment:
Figure 149 still includes "Authentication state machine" entry when this is no longer defined in the standard.

SuggestedRemedy:
Update Figure 149 to remove the four "Authentication state machine" boxes.


Comment:
Use of "authentication status" not relavent to the standard. This should be security status.

SuggestedRemedy:
Change two occurances of "authentication" in this sentence to "security"


Comment:
This paragraph has not been updated to reflect the changes made to remove authentication and replace it with "membership in a security relationship".

SuggestedRemedy:
Change:Line 24: "such as a change in authentication state" to "such as a change in security relationship"Line 25: "transitions from being unauthenticated to authenticated or vice-versa" to "changes membership status in a security relationship"Line 27: "change in authentication status" to "change in membership"


Comment:
This paragraph also includes reference to authentication status instead of using security status or membership.

SuggestedRemedy:
Change:Line 31: "authentication status" to "security status"Line 31: "successful authentication" to "change of membership status in a security relationship"Line 32: delete "succesful de-authentication"Page 244, Line 1: "authentication status" to "security status"


Comment:
Another place where the exorcism of authentication processes has not been completed as required.

SuggestedRemedy:
Change title of Table 63 to "Security status changes"Delete the Authentication and Deauthentication rows of Table 63 or replace them with Security membership change rows.


Comment:
Reference to "authentication process" instead of membership in a security relationship"

SuggestedRemedy:
Change "the authentication process" to "the process of establishing DEV membership in a security relationship"


Comment:
Reference to authentication protocol that is no longer in the standard

SuggestedRemedy:
Change ", but that are not part of the authentication protocol." to "."


Comment:
Left over inclusion of vendor specific command used for de-authentication.

SuggestedRemedy:
Remove "Vendor Specific command (related to de-authentication)"


Comment:
Leftover content from old authentication protocol and state machines

SuggestedRemedy:
Change "When a DEV ... an authentication" to "When a DEV in the unavailable key state receives an indication that the key has been obtained"


Comment:
Vendor specific command use for de-authentication still left in table.

SuggestedRemedy:
Replace two occurances of "or a Vendor Specific command related to de-authentication form the key originator" with "or a Security Membership command removing the DEV from membership in the group membership"


Comment:
Leftover reference to authentication process.

SuggestedRemedy:
Change two occurances of "authentication complete" to "security relationship membership established"May require more changes since de-authenticate also used in this figure.


Comment:
Old authentication state transitions still included in table.

SuggestedRemedy:
Replace with updated security membership updates.


Comment:
table still includes references to authentication process

SuggestedRemedy:
Update to include use of security membership command to update membership is a security relationship.


Comment:
de-authentication command referenced in figure


Comment:
Leftover authentication process in Figure 159

SuggestedRemedy:
Change de-authentication to more appropriate security membership change.


SuggestedRemedy:
Change the heading for 9.4.4 to "Key distribution protocol".


Comment:
Keys protect beacon frames also, not just command and data frames.

SuggestedRemedy:
Line 6, change "support" to "supports".  Line 6, change "command" to "command, beacon".  Line 7, change "command" to "command, beacon".


Comment:
Title of the section is "security mechanisms", but it only talks about security services.

SuggestedRemedy:
Should add some text to this saying "This standard provides symmetric cryptography mechanism that assist in providing these security services.  Additional security services should be provided by the higher layers to ensure proper management and establishment of the symmetric keys used in this standard."


Comment:
For aesthetic reasons, the integrity protection clauses should stay together.


Comment:
We don't really define CurrentTimeToken and LastValidTimeToken sufficiently.

SuggestedRemedy:
Add the following to the end of this paragraph: "A DEV in a secure piconet maintains two values for freshness.  The CurrentTimeToken is the time token value found in the beacon for the current superframe and is used to protect all messages sent and check all messages received during that superframe.  The LastValidTimeToken is used by the DEV to ensure that the security of the beacons have not been compromised."


Comment:
"Known key" is ambiguous.  We want to be clear that the DEV may keep an old key as well as "knowing" the new key.

SuggestedRemedy:
Change "with the known key" to "protected by the old piconet-wide group data key."


Comment:
Old text seems to have crept into this table.

SuggestedRemedy:
Seed should be changed to key in all cases.


Comment:
The description concerning selection of an authenticatin method, the use of particular commands, and an authentication process are outside the scope of the standard and should not be included.

SuggestedRemedy:
Remove this paragraph since it does not represent any facts defined in the standard.


Comment:
Fix text for CCA threshold in PHY PIB, it is 2's complement, but no larger than the value given in 11.6.5.

SuggestedRemedy:
Change description to "The CCA threshold in dBm encoded as 2's complement.  The value is implementation dependent but is no larger than the value given in 11.6.5.  For example, -55 dBm would be encoded as 0xC9."


# 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")


