# Main

Comment:
The term 'network device' should be replaced by 'device' throughout the draft.


Comment:
The running header 'Draft Standard Low-Rate Wireless Personal Area Networks' is inconsistent with the title '...Low Rate...'; meaning hyphenated and not hyphenated.  This is true throughout D16.

SuggestedRemedy:
I suggest the Editor choose to hyphenate or not to hyphenate the term or use either 'Low Rate' or 'Low-Rate' not both.


SuggestedRemedy:
I suggest you change 'Content' to 'Contents'.


Comment:
[PAJ] Major contributions: 'Tony Adamson' - font anomoly!  Please add: Martin Digon & Rod Miller.


Comment:
The sentence 'Methods for controlling keying material throughout its life cycle...' is vague.

SuggestedRemedy:
I suggest removing 'its' for example 'Methods for controlling keying material throughout the life cycle of the LR-WPAN including creation,distribution and destruction.' or something more clear.  Do not forget to add the missing period


Comment:
[PAJ] Pg. 5, line 6: Change '...perform an specific...' to '...perform a specific...'.  Pg. 6, line 11: Change '...contact to its...' to '...contact with its...'.  Pg. 6, line 47: Change '...command frame or a data...' to '...command or data...'.


Comment:
Replace the term 'network device' with the term 'device' and change the definition.

SuggestedRemedy:
A device is 'any entity (RFD or FFD) containing an implementation of the IEEE 802.15.4 medium access control and physical interface to the wireless medium.'


Comment:
Change the defintion of 'nonce' to read '...provide uniqueness each time the protocol is used.'


Comment:
The following full term entries:ERC european radio communications committeeETSI european telecommunications standards instituteFCC federal communications commissionITU-T International telecommunication union - telecommunication servicesneed to be capitalized.

SuggestedRemedy:
I suggest you change to:ERC European Radio Communications CommitteeETSI European Telecommunications Standards InstituteFCC Federal Communications CommissionITU-T International Telecommunication Union - Telecommunication Standardization SectorNote: the ITU-T abbreviation has been corrected, more info: http://www.itu.int/ITU-T/


Comment:
[PAJ] We should not be using ACK or SEC in the text - later comments remove these so remove them from here.  BSP, No-ACK & PAR are not used anywhere so remove them from here.  DA and SA are used as variables in the SDL - no need to have them here.  As we have RX and TX we should also have TRX = transceiver.  Add MCPS = MAC common part sublayer.


Comment:
Can the word 'shall' appear in this clause? Reword as '...network will include at least one FFD, which will act as the PAN coordinator.'


Comment:
Figure 1 has already been referenced in this subclause. Remove the sentence beginning 'Figure 1 shows...', as it is redundant.


Comment:
Replace the term 'network idnetifier' with 'PAN identifier' throughout the clause.


Comment:
Add the text 'to join its network; both FFDs and RFDs may join a star network.'


Comment:
Remove this sentence. It already appears under 5.2.1 and so is redundant.


Comment:
Replace the entire cluster tree formation text (see suggested remedy).

SuggestedRemedy:
The cluster-tree network is a special case of a peer-to-peer network. Every device in a cluster tree network is an FFD. Any of the devices may act as a coordinator, providing synchronization services to other devices or other coordinators. Only one of these coordinators can be the overall PAN coordinator, which may have greater computational resources than any other device in the PAN.The PAN coordinator forms the first cluster by establishing itself as the cluster head (CLH) with a cluster identifier (CID) of zero, choosing an unused PAN identifier and broadcasting beacon frames to neighboring devices. A candidate device receiving a beacon frame may request to join the network at the cluster head. If the PAN coordinator permits the device to join, it will add the new device as a child device in its neighbor list. Then the newly joined device will add the cluster head as its parent in its neighbor list and begin transmitting periodic beacons; other candidate devices may then join the network at that device. If the original candidate device is not able to join the network at the cluster head, it will search for another parent device. The detailed procedures describing how a PAN is started and how network devices join a PAN can be found in subclauses 7.5.2 and 7.5.3.The simplest form of a cluster tree network is a single cluster network, but larger networks are possible by forming a mesh of multiple neighboring clusters. Once predetermined application or network requirements are met, the PAN coordinator may instruct a device to become the cluster head of a new cluster adjacent to the first one. Other devices gradually connect and form a multi-cluster network structure, such as the one seen in Figure 2. The lines in Figure 2 represent the parent-child relationships of the devices and not the communication flow. The advantage of a multi-cluster structure is increased coverage area, while the disadvantage is an increase in message latency.For further information on cluster tree networks, see <add reference to IEEE cluster tree document>.


Comment:
Change the key to the drawing to read 'PAN coordinator' instead of 'DD' and 'device' instead of 'member device'. Also the drawing must be edited to replace the 'DD' with 'PAN coordinator'.


Comment:
Divide the sentence. Change wording to '...function of the device. The defintions of these upper layers are outside...'


Comment:
Change text to '...provided below; for more ...'


Comment:
Reword as '...to select the other devices with which it is willing to communicate. In this...provided, a device...'


Comment:
Delete the sentence 'In this standard...', since the frame types have not been introduced at this point. Do the same for lines 19-20.Also in line 17, get rid of '(MIC)', as it is not needed here.


Comment:
Replace both occurrences of the word 'fresher' with 'newer'.


Comment:
Reword as '...the mode in which the device is operating and...'


Comment:
Reword last sentence as 'The service that may be ...mode is access control (See subclause 5.4.2.1.1).' Get rid of the hyphen. Also should this sentence read 'The service that is provided' instead of 'may be'?


Comment:
What is the meaning of the 't'? Should there be another one at the start of the second beacon? See also fig 5.


Comment:
Remove redundancy by wording as 'with its PAN and may enter a low power mode.'


Comment:
Get rid of first parargaph and move its info into another place.

SuggestedRemedy:
Reword line 20 as 'For a star topology, data may be exchanged only between the PAN coordinator and a device and there are two...The second transfer is...in which a device receives the data.'Also move the sentence from line 18 ('In a peer-to-peer...') to a new paragraph at the end of this subclause.


Comment:
The source address information field may now be 3,4 or 10 octets in length. The beacon sequence number field should immediately follow the frame control field. Also move the data sequence number field in fig 11 and fig 13.


Comment:
The ending of the last sentence in the second paragraph '...topologies.4' is incorrect.

SuggestedRemedy:
I suggest '...topologies.'; deleting the stray '4' character.


Comment:
The sentence '...independent networks (network bridging).' introduces 'bridging'; I believe this term needs to be used carefully.  Also, a search does not reveal further use of 'bridging' in D16.

SuggestedRemedy:
I suggest you review IEEE word usage and 'bridging'; I think you will want to use another term and/or delete the paranthetical altogether.


Comment:
The first use of 'Zigbee Alliance' suggests the need for more info.
 Also, if you can add the referenced industry Recommended Practice document to Clause 2 and/or to a Bibliography I suggest you do so.  Finally, will Zigbee create additional industry Specifications or Recommended Practice documents e.g., Service Specific Convergence Sublayer (SSCS)?  If yes, how will 802.15.4-Annex A and this Zigbee SSCS doc stay synchronized?

SuggestedRemedy:
I suggest adding a footnote with a URL, etc.


SuggestedRemedy:
I suggest correcting the spelling of 'THe' to 'The' or 'The transaction is now complete.'.


Comment:
The sentence '...data using unslotted CSMA.' appears to be incorrect.  I searched on CSMA without CA and I found no occurence.

SuggestedRemedy:
I suggest '...data using unslotted CSMA-CA.'


Comment:
[PAJ] Change bullet 3 to '8-, 16- or 64 bit addressing'?  Change bullet 4 to 'Allocation of guaranteed time slots'.  Add '8- or 16-bit' to bullet 6.  Split bullet 9 at 'link quality indication'.


Comment:
[PAJ] Remove the sentence beginning 'An FFD can switch...' (it can't!!).  Change 'An FFD can talk to RFDs or other FFDs and can control...network device' to 'An FFD can talk to RFDs or other FFDs.'.  Change 'A RFD cannot...' to 'An RFD cannot...'.


Comment:
[PAJ] Line 2: Change '...IEEE...' to '...64-bit IEEE...'.  Line 2/3: Remove 'In a star topology'.  Line 3: Change '...with the PAN coordinator or...' to '...within the PAN...'.  Line 4: Change '...network association is established...' to '...device associates...'.


Comment:
[PAJ] Line 9: Change 'the difference is' to 'it differs from the star topology in'.  Line 16: Remove trailing '4'.


Comment:
[PAJ] There are a lot of general things mentioned here but it looks like it is star topolofy specific.  Separate out the general points into a separate paragraph.


Comment:
[PAJ] Line 34 & 35: Change 'network' to 'PAN'.  Line 34: Change '...unique PAN identifier.' to '...unique identifier.'.


Comment:
[PAJ] Line 46: Change '...become a PAN coordinator.' to '...become the PAN coordinator.'.  Line 48: Change 'range' to 'sphere of influence'.


Comment:
[PAJ] Change 'Further topology...' to 'Further network...'.


Comment:
[PAJ] Line 40: Change '...the specification.' to '...this specification.'.  Lines 43-44: Change 'and any' to 'along with its'.  Line 44: Change 'of the transceiver' to 'mechanisms'.  Line 45: Remove 'and ensures the reliable transfer of frames'.  Lines 50-51: Remove the sentence beginning 'Between the...'.  Line 52: Change '...(SSCS).  The SSCS is included' to '...(SSCS), defined'.


Comment:
[PAJ] Figure 3:  Remove all SAPs.  Remove block 'Other LLC' and extend arrows to 'Upper Layers' block.


Comment:
[PAJ] Line 31: Change '...two services,' to '...two services; these are'.  Remove 'accessed through...services are'.  Line 32: Remove 'accessed through the PD-SAP'.  Line 33: Remove 'accessed through the PLME-SAP'.  Lines 34-35: Remove 'through the RF-SAP'.


Comment:
[PAJ] Lines 43-45: Remove 'the' and 'band' from all bullets.  Line 47:  Change 'Please refer...' to 'Refer...'.


Comment:
[PAJ] Pg. 13, Line 51: Change '...two services,' to '...two services; these'.  Remove 'accessed through...  These services'.  Line 52: Remove 'accessed through...(MCPS-SAP)'.  Line 53: Remove 'service access...MLME-SAP'.  Pg. 14, Line 4: Remove 'mechanism'.  Lines 5-6: Change '...association as well as disassociation and hooks...' to '...association and disassociation.  In addition, the MAC sublayer provides hooks...'.


Comment:
[PAJ] Move clauses 5.4.1 and 5.4.2 after 5.4.6.


Comment:
[PAJ] Line 41: Change '...out of scope for this...' to '...out of the scope of this...'.  Replace the last sentence of this paragraph with 'The security operations provided by the MAC sublayer are described in detail in clause 7.  However, an introduction is given below.'  Line 50: Change '...ZigBee...' to '...the ZigBee...'.


Comment:
[PAJ] Line 16: Change 'The network beacon occupies...' to 'The beacon frame is transmitted in...'.  Line 18: Change 'network' to 'PAN'.  Line 34: Change '...active...' to '...active (receiver enabled)...'.  Line 35: Change '...PAN...' to '...PAN and...'.  Line 42: Remove 'it is recommended to leave' and change 'active superframe' to 'CAP must remain'.


Comment:
[PAJ] Remove first paragraph.  Line 20: Remove 'In a star topology'.  Change 'there are two types of transactions.' to 'There are three types of transfers possible in an IEEE 802.15.4 PAN.'.  Lines 20 & 21: Change 'the PAN' to 'a'.  Line 22: Remove 'PAN'.  Add between the sentences 'The third is the data transfer between two peer devices.'.


Comment:
[PAJ] Line 29: Remove 'PAN'.  Line 31 & 34: Change 'the PAN' to 'a'.  Line 37: Remove 'PAN' in both instances.


Comment:
[PAJ] Line 4: Remove 'PAN'.  Line 8: Remove 'Network'.  Line 12: Remove 'Frame'.  Figure 6 & 7 caption: Change 'PAN' to 'a'.  Line 21: Change 'the PAN' to 'a'.  Line 22: Remove 'to the PAN coordinator'.  Remove 'PAN'.  Line 26: Remove 'PAN'.  Line 30: Remove 'Frame'.


Comment:
[PAJ] Line 39: Change 'PAN' to 'a'.  Line 41: Change 'the PAN' to 'a'.  Line 44: Remove 'PAN'.  Change 'the coordinator' to 'it'.  Line 47: Remove ', to the PAN coordinator'.  Remove 'PAN'.  Pg. 19, line 1: Change 'THe' to 'The'.  Line 4: Remove 'PAN'.  Line 7: Remove 'Network'.  Line 15: Remove 'Frame'.  Figures 8 & 9 caption: Change 'PAN' to 'a'.  Line 22: Change 'the PAN' to 'a'.  Change '...the coordinator should keep the data until...' to '...it stores the data for...'.  Line 23: Change '...device makes...' to '...device to make...'.  Change 'requests' to 'request'.  Line 25: Change 'the PAN' to 'its'.  Remove 'PAN'.  Lines 27, 28 & 33: Remove 'PAN'.  Line 40: Remove 'Frame'.


Comment:
[PAJ] Line 51: Remove 'belonging to the same network'.  Line 53: Change 'CSMA' to 'CSMA-CA'.


Comment:
[PAJ] Line 7: Change 'transmitting' to 'transmission'.  Line 10: Change 'an FFD' to 'a coordinator'.  Line 13: Remove 'which is'.  Line 14: Change 'which' to 'used to'.


Comment:
[PAJ] Line 22: Change 'an FFD' to 'a coordinator'.  Line 24: Change '...specification field (SSF), the pending address specification field, the address...' to '...specification, pending address specification,  address...'.  Change '...list, and beacon...' to '..list and beacon payload fields'.  Line 25: Remove 'specific data...payload'.  Line 27: Change '...fields, the addressing information field and a frame beacon sequence number field.' to '..., beacon sequence number and addressing information fields.'.  Change 'MRF' to 'MFR'.  Change '...contains the...' to '...contains a 16-bit'.  Line 28: Remove 'field'.  Change '...MFR form...' to '...MFR together form...'.  Line 31: Change '3 or 10' to '3, 4 or 10'.  Figure 10: Swap the 'Src. Address Information' and 'Beacon Sequence Number' fields.  Line 36: Change '8 + (3 or 10) + m + n' to '8 + (3, 4 or 10) + m + n'


Comment:
[PAJ] Lines 3 & 4: Remove the sentence beginning 'The data...'.  Figure 11: Swap the 'Addressing Information' and 'Data Sequence Number' fields.  Line 23: Change '...control field, the addressing information field and a frame data sequence number field.' to '...control, data sequence number and addressing information fields.'.  Line 24: Remove 'field'.


Comment:
[PAJ] Line 38: Remove 'field'.  Line 42: Change '...PSDU) and...' to '...PSDU).  The PSDU...'.  Line 42: Change '...(SHR) and the PHY header (PHR).' to '...(SHR), containing a preamble sequence field and start of frame delimiter field, and a PHY header (PHR) containing the length of the PSDU in octets.'.  Line 44: Change '...PSDU form...' to '...PSDU together form...'.  Pg. 22, lines 1 & 2: Remove the sentence beginning 'This PPDU...'.


Comment:
[PAJ] Lines 26-27: Change '...control field, the addressing information field and a frame data sequence number field.' to '...control, data sequence number and addressing information fields.'.  Line 27: Change '...contains the frame...' to '...contains a 16-bit frame...'.  Line 28: Remove 'field'.  Change '...MFR form...' to '...MFR together form...'.  Figure 13: Swap the 'Addressing Information' and 'Data Sequence Number' fields.  Line 49: Remove 'a field indicating'.


Comment:
[PAJ] Line 14: Remove 'and beacon'.  Lines 21-22: Change 'Acknowledgement frames indicate a previous transmission and shall...' to 'Acknowledgement and beacon frames shall...'.


Comment:
[PAJ] Line 29: ...frame or a MAC...' to '...or MAC...'.  Remove 'either' and 'or no acknowledgement'.


Comment:
Change text to read 'The main objectives...are...'.


Comment:
Change text to read 'Up to 254 devices using 8-bit short addresses or more using either 16-bit short addresses or 64-bit extended addresses.' Also, there is another bullet item on line 15 referring to allocated addesses; this is redundant and should be deleted.


Comment:
Table 5 specifies the parameter for PD-DATA.confirm.


Comment:
[PAJ] The effect on receipt is not fully described.  How and when are the status values for the .confirm primitive generated?

SuggestedRemedy:
Expand the text to describe the status values.  See the MAC clause for details.


Comment:
[PAJ] Change '...a MPDU...' to '...an MPDU...'.


Comment:
[PAJ] Remove 'to the local MAC sublayer entity'.


Comment:
[PAJ] Change to 'On receipt of this primitive, the MAC sublayer is notified of the arrival of an MPDU across the PHY data service.'.


Comment:
[PAJ] Lines 11, 18 & 46: Change 'DME' to 'MLME'.  Clause 6.2.2.1.3 needs to be augmented with descriptions of how the status values are generated.  E.g. 'If the channel is assessed to be idle, the PLME shall generate the PLME-CCA.confirm primitive with a status of IDLE.', etc.


Comment:
[PAJ] Centralise 'Valid Range' column of tables 8, 11, 12, 13, 14, 15 & 16.  Centralise 'Value' column of table 17.  Centralise 'Type' and 'Range' columns of table 22.


Comment:
[PAJ] Lines 3 & 19: Change 'DME' to 'MLME'.  Clause 6.2.2.3.3: Expand to describe the .confirm status values.  Line 36: Remove odd 'l' in the interface description.


Comment:
[PAJ] Lines 3 & 12: Change 'DME' to 'MLME'.  Clause 6.2.2.5.3: Make this clause consistent with the MAC - see 7.1.6.1.3.


Comment:
[PAJ] Make this subclause consistent with the MAC - see 7.1.6.2.2.


Comment:
[PAJ] Make this subclause consistent with the MAC - see 7.1.12.1.3.


Comment:
[PAJ] Make subclauses 6.2.2.10.1 and 6.2.2.10.2 consistent with the MAC - see 7.1.12.2.2 and 7.1.12.2.3, respectively.


Comment:
[PAJ] Lines 17-19: Font size is not consistent.  Line 23: Change 'DME' to 'MLME'.  Table 17: The value of SUCCESS should really be 0x00 - reorder and renumber the table.


Comment:
[PAJ] Line 35: Is the word 'identical' really necessary?  Remove!  Line 49: Change '1g' to '1' and '0xA7' to '0xa7'.


Comment:
[PAJ] Line 3: Change '...bytes occupied by the...' to '...octets contained in...'.  Line 23: Change '...field is a...' to '...field has a...'.  Line 27: Remove 'identical'.


Comment:
[PAJ] Line 15: Change '32-bit field' to 'Bitmap'.  Change 'see Description' to 'See description'.  Line 24: Change '8-bit field' to 'Integer'.  Change 'CF' to '0xcf'.


Comment:
Put reference as '(See Table 95)'. Change lines 47-49 to read '...select the other devices with which it...communicate.'


Comment:
Replace both occurrences of 'fresher' with 'newer'. Change line 28 to 'mode in which the device is operating and...'. In lines 42-44, combine the hyphen text into the paragraph; 'The service that may be...mode is access control (See...).' Also, should this text be 'is' instead of 'may be' (the same question for clause 5)?


Comment:
Change text to 'The MAC PIB ACL contains...The default ACL entry is used...Individual ACL entries are used...' In line 8, the term 'controller' is used but not defined. What is meant by this? Remove the text in lines 10-13 beginning 'Each ACL entry...', because it is repeated in the two following paragraphs. In line 23 the term 'peer device' is used; can this be replaced by 'trusted device'?


Comment:
For SecurityUse, ACLEntry and SecurityFailure, use TRUE and FALSE instead of 1 and 0. Put the reference to Table 53 in parenthesis. In lines 39-41, what should the value of SecurityFailure be? Make similar changes to p160, lines 1-3 also.


Comment:
Replace 'receives a frame' with 'receives an incoming frame'. Lines 45-47 are redundant and should be removed ('Therefore, data outside of...'). Reword lines 53-54 and lines 1-2 (p 161) as '...addition to any encrypted data. If the payload field does not contain any data, then it shall contain only the integrity code. Integrity codes shall not be used for ACK frames.'


Comment:
Reword as '...and the placement of the resulting encrypted data or integrity code within the beacon...data payload field is defined...' In line 45, change 1 to TRUE and 0 to FALSE and also put the ref to table 53 in parenthesis; make these changes on page 162 too. On page 162, line 6 change 'encryption' to 'decryption'.


Comment:
Remove the second occurrence of 'on the MAC frames'. Change text in line 30 to '...standard, the algorithm used shall be...' In table 100, add a column called 'security services' with subheadings called 'encryption' and 'authentication'; use an 'X' to indicate which service(s) is implemented by each security suite.


Comment:
This subclause is unclear. Please clarify.


SuggestedRemedy:
Change puntuation to 'a key stream, using a block cipher...nonce, and performing...' Then add the sentence 'A nonce is simply a byte string used to provide uniqueness each time the protocol is used.'


Comment:
Replace 'CTR encryption' with 'CBC-MAC authentication'. In lines 29-30 replace it with 'CCM combined encryption and authentication'. In lines 43-44, reword as '...perform either CTR encryption, CCM ...authentication or CBC-...'


Comment:
Add a sentence to the end of the paragraph. 'The frame counter will be reset if a new key is issued.'More explanation is needed for key sequence counter. Add a sentence following lines 50-51. 'This value may be used by the higher layers to facilitate key management by allowing the higher layers to reset the frame counter and not generate the same nonce twice.'


Comment:
Rewrite as '...Table 104. The bit values in this flag octet are chosen simply to distinguish the AES-CTR flags from the AES-CCM flags (see Annex B for information on the AES-CCM flags).' Change puntuation in line 30 to 'operation, as defined...suite, shall'.


Comment:
Add wording to link step 1 to sequential freshness protection terminology. In line 19, what is the error returned here?


Comment:
Merge subclauses 7.6.3 - 7.6.5 AES CCM text to remove repetition. Do the same for 7.6.6 - 7.6.8 AES CBC-MAC text.


Comment:
Change punctuation to '16 octets and the nonce'. In 7.6.3.3.1 step 2, the sentence is too long and punctuation is wrong; change to '7.6.1.6. The parameters are specified...data, a, the payload...message, m, and the nonce...'


Comment:
In step 1, add wording to link to sequential freshness protection terminology. Step 3 is too word and needs restructuring.


Comment:
Change wording to 'The indirect transmission bit shall be ignored if either the GTS transmission bit is set to 1, the destination address is not present or the MAC sublayer receiving this primitive is not that of a coordinator.'


Comment:
The MLME primitives are not in alphabetical order in the text. Perhaps the present groupings will make it too difficult to find a particular primtive.


Comment:
Most of the parameters listed are the same as those included in the PAN Descriptor of the SCAN primitive. It would be clearer to encapsulate these individual parameters in the PAN descriptor. Then move the PAN Descriptor table after table 41.


Comment:
Change description of SecurityUse to 'This parameter is set to TRUE if the security enabled subfield of the received beacon frame was set to 1. Otherwise, the parameter is set to FALSE.' Make similar changes to any other occurrence of the SecurityUse parameter.


Comment:
Reword description to '...active portion of the superframe, including the beacon frame. The...' Change also in table 94 lines 40-42.


Comment:
Reword as 'primitive prompts the device to request data...' In line 51, change to the singular 'parameter'. On p. 102 line 32, change to for the data frame from the...'.


Comment:
Clarify the origins of this default value. In table 95 lines 22-25, 'that are not in the ACL' is a little vague; reword to clarify. After line 29, add a ref to 7.6.1.8; add the same reference to table 96 line 27.


Comment:
Reword the sentence beginning 'If BO = 15...' to 'The value of macSuperframeOrder shall be ignored if BO = 15.' Reword lines 20-21 as 'The active portion of each superframe shall be divided into...aBaseSlotDuration and is composed...(CFP). The beacon shall be transmitted...'.


Comment:
Make the reference to the source addressing fields more general to include the address. Also reword as '...PAN identifier shall be the ...'


Comment:
The primitive names begin with 'MLME' but the text that follows references the DME.


Comment:
Add text to describe the circumstances under which it is issued.


Comment:
Add the word 'subclause' before the two references.


Comment:
Add in '...beacon interval, BI, ...superframe duration, SD,...' In line 46 add in '...that can be quickly transmitted...'


Comment:
Change the text to '...pause the backoff countdown...' In line 35, delete 'be able to' and change to 'shall proceed'. At the end of the same paragraph, swich the order of the last two sentences.


Comment:
Reword as '...suspend beacon transmissions, if applicable, and...' In 7.5.2.1.1 second paragraph, switch the order of the last two sentences. In 7.5.2.1.2 line 36, give more detail about the security flags; do the same for p140 line 6.


Comment:
Reword as 'command shall occur'. In lines 38-39 reword as 'perform the PAN identifier conflict resolution procedure.' Reword line 53 to 'if the following applies:'


Comment:
Reword as 'and short addresses'. Also try to combine tables 97-99.


Comment:
Reword as 'allows the other'. Continue to page 142. On p 142, change line 1 to 'An FFD, that is not the...PAN. The transmission...by the device...'. In line 23, add a comma 'allowing association, as'. In line 37 add 'all previously obtained device specific'. In line 44 add comma 'message, and'. In line 51, reword as 'allocated a unique short address'.


Comment:
Change to 'the active portion of the superframe'. On p 145 line 45, reword as 'its address with those in the address list'.


Comment:
The text does not seem to be consistent with the definition of a 'transaction'. See, for example, p147 line 19. Reword to clarify.


Comment:
Reword as 'a unique short address'. In line 44, reword as 'coordinator; the destination address field shall be present in this case.'


Comment:
Restructure the security text and add to the list of items above (lines27-34). Also include the exception for when performing a beacon scan.


Comment:
Smooth out the text by reordering the information in the first 4 paragraphs. On p 149 line 27 change to 'inter-frame'. On p 151 line 8 remove 'deemed to have been'; change to 'is considered successful'.


Comment:
[PAJ] Add a 'Conventions' subclause to describe the use of PIB attributes and constants, etc.  Probably also in PHY clause.  Can we not have a general section??  If we don't do this we should add Xrefs to every use of a PIB attribute or constant.


Comment:
[PAJ] Line 48: Change '...can complete before...' to '...can be completed before...'.  Line 51: Add case for when a CAP doesn't exist - no beacons.


Comment:
[PAJ] Line 2: Change '...by a coordinator...' to '...by the MAC sublayer of a coordinator...'.  Line 13: Add case when there is no CAP - no beacons.  Line 16: Change '...the security...' to '...security...'.


Comment:
[PAJ] Pg. 54, lines 23-24, Pg. 60, line 39, Pg. 63, line 19, Pg. 66, line 39, Pg. 75, lines 37-38. Pg. 82, line 13, Pg. 94, line 26, Pg. 98, line 27: Change '...shall apply the secure processing on the frame...' to '...shall use it to apply security to the frame...'.


Comment:
[PAJ] Pg. 54, line 40, Pg. 60, line 49, Pg. 63, line 25, Pg. 66, line 49, Pg. 75, line 46, Pg. 82, line 19, Pg. 94, line 33, Pg. 98, line 36: Change '...primitive TX_ON...' to '...primitive with a state of TX_ON...'.


Comment:
[PAJ] Pg. 57, lines 39-41, Pg. 62, lines 10-12, Pg. 68, lines 10-12, Pg. 71, lines 41-43, Pg. 78, lines 23-25, Pg. 80, lines 30-32, Pg. 89, lines 34-36: Change 'Description' cell to 'TRUE if the security enabled subfield of the received frame was set to 1.  FALSE otherwise.'.


Comment:
[PAJ] Change '...and MLME...' to '...and the MLME...'.


Comment:
[PAJ] Line 12: Change 'The MLME of the device shall...' to 'If the MLME of the device extracts a frame from the coordinator it shall...'.  Line 19: Change 'MAC sublayer' to 'MLME'.


Comment:
[PAJ] Change ...parameter is set...' to '...parameter shall be set...'.


Comment:
[PAJ] The association response command must be pended not sent immediately - adjust the text to clarify.


Comment:
[PAJ] Change 'This parameter is set to 0x00ff if the association was unsuccessful.' to 'This parameter shall be equal to 0x00ff if the association attempt was unsuccessful.'.


Comment:
[PAJ] Pg. 65, Figure 22, Pg. 69, Figure 23, Pg. 72, Figure 24, Pg. 79, Figures 26 & 27, Pg. 82, Figure 28: Remove 'procedure' from figure caption.  Pg. 74, Figure 25: Change in caption '...procedure to read...' to '...reading a...'.  Pg. 85, Figure 29: Change in caption '...procedure to change...' to '...changing...'.  Pg. 90, Figure 30: Change in caption '...scan procedure' to '...scanning'.  Pg. 92, Figure 31: Change in caption '...procedure to write...' to '...writing...'.  Pg. 95, Figure 32: Change in caption '...procedure to begin...' to '...beginning...'.


Comment:
[PAJ] Change '...received.' to '...received during normal operating conditions.'.  General question: Should RFDs have to implement this primitive?


Comment:
[PAJ] All these parameters is clumsy - why not simply use a PAN descriptor along with any other required parameters?


Comment:
[PAJ] This figure is not particularly useful - remove it?


Comment:
[PAJ] Change '...DeviceAddress parameter...' to '...address of the PAN coordinator, macCoordExtendedAddress...'.


Comment:
[PAJ] Line 10: Change 'The MLME of the device shall...' to 'If the MLME of the device extracts a frame from the PAN coordinator it shall...'.  Line 39: Change '...will be set equal...' to '...shall be set...'.


Comment:
[PAJ] Add text to describe the case for when this primitive is generated by the device MLME.


Comment:
[PAJ] Line 13: Remove 'and reallocations'.  Lines 15-16: Change '...deallocated or reallocated...' to '...allocated or deallocated...'.  Lines 46-47: Remove 'either' and 'or reallocation'.


Comment:
[PAJ] Change 'AllocatedAddress' to 'ShortAddress'.


Comment:
[PAJ] Line 30: Change 'unique allocated' to 'short'.  Line 31: Change 'assigned' to 'allocated'.  Line 32: Change 'extended 64-bit' to '64-bit extended'.  Lines 36-37: Change 'Description' cell to 'TRUE if the orphaned device is associated with this coordinator, FALSE otherwise.'.  Line 51: Change 'commend' to 'command'.


Comment:
[PAJ] Pg. 82, lines 23-24, Pg. 94, lines 36-37: This depends on whether the receiver is to be turned on after the transmission.  Adjust the text for the second case.


Comment:
[PAJ] Is it really feasible to reset to a default PIB or NOT?  Perhaps this parameter is not needed?


Comment:
[PAJ] Change '...the MLME-RX-ENABLE.request...set to 0.  The MAC...' to '...the PLME-SET-TRX-STATE.request primitive with a state of TRX_OFF.  On receipt of the PLME-SET-TRX-STATE.confirm primitive, the MAC...'.


Comment:
[PAJ] Change row to 'EnableRx', 'Boolean', 'TRUE or FALSE', 'TRUE to enable the reciever, FALSE to disable it.'.  We can then remove ENABLE and DISABLE from table 63.


Comment:
[PAJ] Line 34: Change '...receiver.' to '...receiver at a time relative to the start of the superframe.'.  Subclause 7.1.10.1.3: Add text to describe HOW the MAC requests the PHY enable its receiver, i.e. issues the PLME-SET-TRX-STATE.request primitive.


Comment:
[PAJ] Change ...shall commence with the...' to '...shall be performed on each channel by the...'.


Comment:
[PAJ] Either remove this figure (it is of no use) or incorporate the reception of beacons, ScanDurations, etc.


Comment:
[PAJ] Subclause 7.1.13.1.2: Add warning text re: setting the short address beforehand.  Subclause 7.1.13.1.3: Add text describing how the PAN identifier, logical channel, etc. are set.


Comment:
[PAJ] This figure is not particularly useful!  Add beacon or remove the figure.


Comment:
[PAJ] Change this primitive to a general radio error primitive so it can be used after .response primitives as well as security errors.


Comment:
[PAJ] Separate the MLME-POLL primitive into its own section.


Comment:
[PAJ] Line 2: Add Xref to this primitive.  Line 13: Change 'request data from' to 'poll'?


Comment:
[PAJ] Change '...DME on...the coordinator.' to '...DME in response to an MLME-POLL.request primitive.  If the request was...' (etc. like 7.1.3.4.2).


Comment:
[PAJ] Line 5: Change 'SyncMode' to 'Track'.  Table 61: Change row to 'Track', 'Boolean', 'TRUE or FALSE', 'TRUE to track the beacon or FALSE to find it once.'.  Subclause 7.1.15.3.3: Adjust for the new 'Track' parameter.  Line 33: Change '...data.' to '...data provided macAutoRequest is equal to TRUE.'.  We can then remove SINGLE and TRACK from table 63.


Comment:
[PAJ] Line 30: Change '...frame pending subfield...' to '...frame pending (FP) subfield...'.  Subclause 7.1.16.1: Group with the MLME-SYNC primitive?  Line 44: Change 'of' to 'with'.


Comment:
[PAJ] Change '...conflict, the...' to '...conflict and communicated it to the coordinator, the...'.  This may change if we remove device PAN identifier conflict detection.


Comment:
[PAJ] Change '...address and sequence number...' to '...sequence number and address...'.


Comment:
[PAJ] The value of SUCCESS should probably be 0x00.  Reorder and renumber the table.


Comment:
[PAJ] Change '...for that security relationship.' to '...for the security relationship indicated by the current frame.'.


Comment:
[PAJ] Subclause 7.2.1.1.3: This subclause needs more detail on how this subfield is used.  E.g. how is it used by a device? - it needs to re-send a data request command to retrieve the data.  Subclause 7.2.1.1.4: Add text to describe when the frame is valid.  Line 24: Change '...acknowledgement...' to '...acknowledgement or beacon...'.  Table 67: Always saying 'Destination/source' looks messy - put this in the title.


Comment:
[PAJ] Line 13: Change 'The Frame...' to 'The frame...'.  Line 32: Remove the line beginning 'The FCS field...'.


Comment:
[PAJ] Lines 15-16: Swap 'sequence number field' with addressing fields.  Swap paragraphs 3 and 4.  Lines 26 & 27: Remove 'the MAC PIB attribute' in both cases.


Comment:
[PAJ] Change sentence to 'If the security enabled subfield of the frame control field is set to 1, the device shall process the frame according to the security suite corresponding to the address of the coordinator in macCoordExtendedAddress.'.


Comment:
[PAJ] Swap paragraphs 3 and 4.  Lines 31 and 33: Remove 'the MAC PIB attribute' in both cases.


Comment:
[PAJ] Line 40: Change '...subfield in the...' to '...subfield of the...'.  Line 42: Change '...the selected security suite...' to '...the security suite corresponding to the destination address or the coordinator address in macCoordExtendedAddress...'.  May need to pad this with some explanation of when each case is used.


Comment:
[PAJ] Swap paragraphs 3 and 4.  Pg. 114, lines 1 & 3: Remove 'the MAC PIB attribute' in both cases.


Comment:
[PAJ] Pg. 114, line 8, Pg. 117, line 48, Pg. 118, line 51, Pg. 124, line 43, Pg. 127, line 7: Change '...the values...' to '...the non reserved values...'.


Comment:
[PAJ] Line 14: Change '...field contains...' to '...field shall contain...'.  Line 16: Change '...selected security suite...' to '...security suite corresponding to the destination address or the coordinator address in macCoordExtendedAddress'.  May need to pad this with explanation of each case.


Comment:
[PAJ] Lines 13-14: Reword - sentence is clumsy.  Line 27: Change '...command occur...' to '...command shall occur...'.  Line 53: Change '...if any of the following apply.' to '...if the following applies.'.


Comment:
[PAJ] Change 'the PHY PIB' to 'phyCurrentChannel'.


Comment:
[PAJ] Line 8: Change 'extended 64-bit' to '64-bit extended'.  Line 18: Change '...PAN with...' to '...PAN, with...'.  Line 19: Change '...associate from...' to '...associate, from...'.  Line 31: Change '...during the CAP...' to '...to the coordinator...'.  Line 42: Change 'addressing' to 'transmission'.


Comment:
[PAJ] In the second paragraph add text about indirect transmission such as that given on pg. 142.


Comment:
[PAJ] Relocate subclause 7.5.4.1 in subclause 7.5.2.  Line 13: Change 'A coordinator...' to 'An FFD...' and 'The coordinator...' to 'The FFD...'.  Table 99: Change the description column so that shall is included.  E.g. 'The beacon shall contain an 8-bit short address.', etc.  Line 47: 'A third condition' sounds clumsy - reword.


Comment:
[PAJ] Line 1: Remove 'the amount of time required for'.  Line 11: Add a third bullet: 'A GTS has been allocated.'.  Line 28: Change '...(2BO+1) symbols.' to '...(2n+1) symbols, where n is the value of macBeaconOrder.'.  Line 30: Change '...respond with...' to '...notify the DME by issuing...'.  Lines 46 & 47: Change '...short address...' to '...short or extended address...'.  Lines 49-50: Remove the sentence beginning 'If the address...'.


Comment:
[PAJ] Line 7: Change '...as defined by...' to '...at the descretion of...'.  Line 19: Change '...shall issue...' to '...shall notify the DME by issuing...'.  Line 31: Change '...upper layer...' to '...DME...'.  Line 43: Change '...MCPS-DATA.request or via...' to '...MCPS-DATA.request primitive or via...'.  Line 44: Add an example of this after 'DME'.


Comment:
[PAJ] Line 2: Change '...dealt with...' to '...extracted by the appropriate device...'.  Lines 26-29: This poaragraph is not relevant - remove and put some other introductory text in its place.  Line 54: Change '...(2BO+1)) symbols...' to '...(2n+1)) symbols, where n is the value of macBeaconOrder...'.


Comment:
[PAJ] Add text to explain what happens when a coordinator can pend >7 messages at once, i.e. which 7 does it choose to go in the beacon?  E.g. the text should say 'the first 7 if more than 7 are pended'.


Comment:
[PAJ] Should 'aMaxFrameResponseTime' be 'aMaxResponseTime'?  If not why not?

SuggestedRemedy:
Change the text so that only one constant is used and adjust the meaning of aMaxResponseTime as necessary.


Comment:
[PAJ] Change '...request subfield...' to '...request (AR) subfield...'.


Comment:
[PAJ] Add text in this subclause to explain that the DSN is copied from the received data or MAC command frame into the acknowledgement frame.


Comment:
[PAJ] Line 44: Change '...passes on the frame...' to '...passes the frame...'.  Line 46: Change '...the MAC sublayer...' to '...the originator MAC sublayer...'.


Comment:
[PAJ] Lines 1 & 12: Change '...failed, and...' to '...failed and...'.  Line 3: Change '...the MAC sublayer...' to '...the originator MAC sublayer...'.  Line 10: Change '...passes on the frame...' to '...passes the frame...'.


Comment:
[PAJ] Add text to explain how 'adverse conditions' are detected.  E.g. the text should mention something like 'if transfers repeatedly fail to several devices after aMaxCommunicationFailures then dynamic channel selection is invoked.'.


Comment:
[PAJ] Change '...scan through its list of available channels using an...' to '...perform an...'.


Comment:
[PAJ] Add text indicating that only the PAN coordinator shall allocate GTSs.  Line 23: Change '...deallocated at the...' to '...deallocated at any time at the...'.  Line 32: Change 'requesting' to 'owning'.


Comment:
[PAJ] Add text to explain how Rx GTSs are handled.  I.e. enabling the receiver at the right time, etc.


Comment:
[PAJ] Remove 'remove the GTS from its list of allocated GTSs and'.


Comment:
[PAJ] Line 4: Change '...MLME-GTS.indication primitive...' to '...MLME-GTS.indication primitive and set macTxGTSId to 0 (etc.)...'.  Line 8: Change 'being' to 'becoming'.  Change 'Figure 40, for example, shows...' to 'For example, Figure 40 shows...'.


Comment:
[PAJ] Add text to explain the use of the timeout aMaxResponseTime.


Comment:
[PAJ] Pg. 157, line 37, Pg. 159, line 39, Pg. 160, line 3, Pg. 161, line 45, Pg. 162, line 14: Change ' ' to '(see )'.


Comment:
[PAJ] Change '...specified by the macSecurityMode field in the MAC PIB ACL.' to '...specified by macSecurityMode.'.


Comment:
[PAJ] Line 12: Change '...perform on sent and received frames...' to '...perform on frames to be sent or received...'.  Lines 12-13: Remove 'or keys'.  Lines 15-20: Change '...the <PIB attribute> field...' to '...<PIB attribute>...' in all six cases.  Line 22: Change '...in the...' to '...in...'.  Unitalicise 'Each ACL entry'.  Line 23: Change '...PANId, extended IEEE address and short PAN address...' to '...PAN identifier, a 64-bit extended address, a short address...'.  Line 24: Remove 'stored in...fields respectively'.  Line 25: Remove 'stored in a macACLSecuritySuite field.'.  Line 26: Remove 'that is stored in a macACLSecurityMaterial field'.


Comment:
[PAJ] Line 32: Change '...on MAC frames.  While in this mode, when a device receives a frame...' to '...on incoming frames.  When a device receives a frame while in this mode...'.  Line 33: Change '...shall check the FCS and send the appropriate ACK, if applicable (See 7.5.6.2)...' to '...shall perform its filtering operations on the incoming frame, as described in subclause 7.5.6.2...'.  Line 35: Change '...shall return an MLME-SECURITY-ERROR.indication...' to '...shall issue the MLME-SECURITY-ERROR.indication primitive...'.  Line 36: Change '...the ReasonCode set to UNAVAILABLE_KEY...' to '...a ReasonCode of UNAVAILABLE_KEY,...'.  Line 38: Unitalicise italic text.  Change '...fields to 1, 0 and 1 respectively...' to '...fields of the PAN descriptor to TRUE, FALSE and TRUE, respectively...'.


Comment:
[PAJ] Line 49: Change 'source' to 'originator'.  Lines 49-50: Change 'While in this mode, when the device receives a frame...' to 'When a device receives a frame while in this mode...'.  Change '...shall check the FCS and send the appropriate ACK, if applicable (See 7.5.6.2)...' to '...shall perform its filtering operations on the incoming frame, as described in subclause 7.5.6.2...'.  Lines 52-53: Change '...shall return an MLME-SECURITY-ERROR.indication...' to '...shall issue the  MLME-SECURITY-ERROR.indication primitive...'.  Line 53: Change '...with the ReasonCode set to UNAVAILABLE_KEY unless...' to '...with a ReasonCode of UNAVAILABLE_KEY, unless...'


Comment:
[PAJ] Lines 1-2: Unitalicise italic text.  Line 2: Change '...fields to 1, 0 and 1 respectively...' to '...fields of the PAN descriptor to TRUE, FALSE and TRUE, respectively...'.  Line 6: Change '...with a macACLPANId...' to '...with a value of ACLPANId...'.  Line 7: Change '...PANId and with a macACLAddress or macACLPANAddress...' to '...PAN identifier and with an ACLExtendedAddress or ACLShortAddress...'.


Comment:
[PAJ] Lines 22: Change 'macACLPANId' to 'ACLPANId'.  Line 23: Change 'macACLAddress' and 'macACLPANAddress' to 'ACLExtendedAddress' and 'ACLShortAddress', respectively.  Line 25: Change 'macACLSecuritySuite' to 'ACLSecuritySuite'.  Line 26: Change 'macACLSecurityMaterial' to 'ACLSecurityMaterial'.  Line 52: Change '...placed in...' to '...placed after...'.


Comment:
[PAJ] Need to add text about how the DSN is not used for the integrity computation.


Comment:
[PAJ] In general anything in the ACL descriptor should not be in italics - applies throughout the rest of clause 7.


Comment:
[PAJ] Line 2: Change 'ACK' to 'acknowledgement'.  Line 9: Change '...with the ReasonCode set to...' to '...with a ReasonCode of...'.  Line 11: Change '...return an MLME-SECURITY-ERROR.indication...' to '...issue the MLME-SECURITY-ERROR.indication primitive...'.  Change '...with the ReasonCode set to...' to '...with a ReasonCode of...'.


Comment:
[PAJ] Change '...from another...(See 7.5.6.2).' to '...it shall perform its filtering operations on the incoming frame, as described in subclause 7.5.6.2...'.


Comment:
[PAJ] Add a list of services for each security suite as extra columns so that the result is a matrix.


Comment:
[PAJ] Add text to explain what is meant by 'parameters that are left undefined'.


Comment:
[PAJ] Line 23: Change '...stored in the...' to '...stored in...'.  Change '...or macACLSecurityMaterial...' to '...or the ACLSecurityMaterial...'.  Line 24: Remove 'MAC PIB'.


Comment:
[PAJ] Table 103: add text explaining where this is stored.  Table 104: Add text explaining what this represents.  This has been repeatedly commented on but it is still not satisfactorily described.  Perhaps representing it like this is not the best thing to do?


Comment:
[PAJ] Line 46: Change '...extended 64-bit, IEEE...' to '...64-bit extended...'.  Pg. 167, line 2: Add text explaining under what circumstances the increment operation may fail.


Comment:
[PAJ] Pg. 167, lines 3, 14 & 19, Pg. 169, lines 18, 34 & 40, Pg. 176, line 27: Spell out which error is being referred to here.


Comment:
[PAJ] Change '...extended 64-bit, IEEE...' to '...64-bit extended...'.


Comment:
[PAJ] Use of the term 'nonce' without first describing it.


Comment:
[PAJ] Line 44: Change '...stored in the...' to '...stored in...'.  Line 45: Change 'macACLSecurityMaterial fields' to ' the ACLSecurityMaterial field'.  Remove 'MAC PIB'.


Comment:
[PAJ] Pg. 166, line 46, Pg. 169, line 6: The extended address of a device is a constant NOT a MAC PIB attribute.


Comment:
[PAJ] Change '...extended, 64-bit IEEE...' to '...64-bit extended...'


Comment:
[PAJ] Subclauses 7.6.4 and 7.6.5 are identical to 7.6.3 in everything but the AES-CCM payload field (figure 106) and can hence be merged to simplify the document.

SuggestedRemedy:
Remove subclauses 7.6.4 and 7.6.5 and adjust 7.6.3 to describe the three versions of the AES-CCM security suites.


Comment:
[PAJ] Subclauses 7.6.7 and 7.6.8 are identical to 7.6.6 in everything but the AES-CBC payload field (figure 115) and can hence be merged to simplify the document.

SuggestedRemedy:
Remove subclauses 7.6.7 and 7.6.8 and adjust 7.6.6 to describe the three versions of the AES-CBC security suites.


Comment:
[PAJ] Line 48: Change '...stored in the...' to '...stored in...'.  Line 49: Change 'macACLSecurityMaterial fields' to 'the ACLSecurityMaterial field'.  Remove 'MAC PIB'.


Comment:
[PAJ] Change '...system.' to '...system by using various message sequence charts.'.


Comment:
[PAJ] Change 'Perform scan (see figure xx)' to 'Perform energy detection scan (see figure 42)'.


Comment:
[PAJ] Line 3: Change 'Higher layer' to 'DME'.  Line 7: Change 'xx' to '45'.  Lines 11 & 26: Remove '(see figure xx)'.  General: Move all 'aAckWaitDuration' timers from the PHY to the MAC process.


Comment:
[PAJ] Lines 19-22: Activation of the Rx should probably occur after the response has arrived - investigate and change as necessary.  Lines 42-45: Move the 'aAckWaitDuration' timer from the PHY to the MAC process.


Comment:
[PAJ] Lines 20-25: Remove timer 'Listen for incoming beacon frames' and replace it with two beacon frame inputs to the PHY process before the .indication primitives are issued.  Lines 35-41: Remove timer 'Record incoming beacon frames' and replace it with two beacon frame inputs to the PHY process before the .indication primitives are issued.  Line 22: Remove 'Record incoming frames for at most'.  Lines 24 & 39: Add at end of sentence ', recording all received beacon frames'.


Comment:
[PAJ] Move the 'aAckWaitDuration' timer from the PHY to the MAC process.


Comment:
[PAJ] Remove double bars on all processes.  We use this to indicate a completely separate MSC, not time passes...


Comment:
This line should be omitted, meaning that the FCS field contains a direct copy of the remainder. If this line is not removed, then a line has to be inserted after line 29 stating: 'Change the FCS field into the ones complement of the received FCS'


Comment:
Description is not unambiguous. It can lead to different implementations.

SuggestedRemedy:
add sample bit stream showing the MPDU (header+data+footer) within an airframe indicating which bit is transmitted first. make explicit which bit of the MPDU bit stream is processed first within the CRC algorithm. make explicit how the CRC remainder bits are located within the MAC footer in the order of transmission


Comment:
PAN ID is given to the primitive but it is not clear if the macPANId in the PIB will be updated according to this value.


Comment:
Setting the PANCoordinator parameter to FALSE will start transmitting beacons on the PAN the device is connected to, so multiple = beacons can exist in a PAN. What is the function of having this and can a device outside of the coordinators range communicate with the coordinator via this beaconing device (cluster network principle)?


Comment:
[PAJ] Change '...CAP.' to '...CAP for beacon enabled PANs or at any time for non beacon enabled PANs.'.  Table 74: The column 'FFD' is not really necessary - remove it.


Comment:
[PAJ] Subclauses 7.3.1.1.1, 7.3.1.2.1, 7.3.1.3.1, 7.3.2.1.1, 7.3.2.2.1, 7.3.2.3.1, 7.3.2.5.1, 7.3.3.1.1, 7.3.3.2.1: In the security paragraph, change '...the selected security suite.' to '...the security suite corresponding...' and add text suitable for each case.


Comment:
[PAJ] Change final sentence to 'The source address field shall contain the value of aExtendedAddress.'.


Comment:
[PAJ] Tables 76, 87, 89, 91: Change the column names 'b0', etc. to just '0', etc.


Comment:
[PAJ] Change '...extended address of the coordinator.' to '...value of macCoordExtendedAddress.'.


Comment:
[PAJ] Change '...that device.' to '...that device when macAutoRequest is equal to TRUE.'.


Comment:
[PAJ] Line 8: Change '...identifier fields shall...' to '...identifier field shall...'.  Line 47: Change '...extended address of the PAN coordinator.' to '...value of macCoordExtendedAddress.'.


Comment:
[PAJ] Change '...the short addressing mode supported on the PAN.' to '...1 (8-bit short addressing).'.


Comment:
[PAJ] Line 7: Change '...set to 0.' to '...set to 0 (source addressing information not present).'.  Line 27: Change '...in receive mode.' to '...able to receive.'.


Comment:
[PAJ] Change '...subfield shall...' to '...subfield is 1 bit in length and shall...'.


Comment:
[PAJ] Line 18: Change '...that owns...' to '...that requested or owns...'.  Line 48: Add text for the case for an allocation failure.


Comment:
[PAJ] Change '...CAP.' to '...CAP to allow certain crucial MAC commands to be transferred to a device.'?  Or words to that effect.


Comment:
[PAJ] Pg. 130, lines 9-11: Describe the cases when TRUE and FALSE are used.  Description cell for 'macCoordShortAddress' and 'macShortAddress' (Pg. 131): Change to be consistent with the text on pg. 117.  Pg. 132, line 49: Change 'pended' to 'indicated'.


Comment:
[PAJ] From 'Attribute' column drop 'mac' from all attribute names.  Attribute 'ACLAddress': Change 'attribute' cell to 'ACLExtendedAddress' and 'type' cell to 'IEEE address'.  Attribute 'ACLPANAddress': change 'attribute' cell to 'ACLShortAddress' and reword 'description' cell for consistency with pg. 117.  Line 27 & 31-32: Change 'macACLAddress' to 'ACLExtendedAddress'.  General question: how do we know the length of the security material if it is variable length?


Comment:
[PAJ] Lines 9 & 14: Remove 'The MAC PIB attribute' in both cases.  Line 24: Add the sentence 'Any allocated guaranteed time slots (GTSs) shall be located within the CFP.'.  Pg. 136, line 1: Change 'illustrated' to 'shown'.


Comment:
[PAJ] Lines 14 & 31: Change '...value of ScanDuration...' to '...value of the ScanDuration...'.  Line 49: Change '...influence.'  to '...influence.  However, the beacon request command is not transmitted.'.


Comment:
The BER curves are a bit suspect since they are based upon the 802.15.2 theoretical section.  I have already made this comment within TG2 and I hope to see an updated section in TG2.  Also the TG4 BER curve seems a little aggressive. As stated in the text it only requires 5-6 dB SNR for a 1% PER. That is VERY good. IEEE 802.11b uses a 256-ary modulation and does not do that well. TG4 must have some fancy coding or something.


Comment:
Figure E.4 is a little too busy for my taste.  Too many curves on the same plot. I would recommend splitting it into a few plots.


SuggestedRemedy:
I suggest 'IEEE Standard for Information technology—Telecommunications and information exchange between systems—Local and metropolitan area networks—Specific requirementsDraft Standard for Part 15.4: Wireless Medium Access Control (MAC) andPhysical Layer (PHY) Specifications for Low Rate Wireless Personal AreaNetworks (LR-WPANs)'.  Apply the same change to Clause 1, page 1.


Comment:
There is an error in the listing of 'Major contributors'.


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


