# Main

Comment:
same as comment #537 in LB12ORIGINAL COMMENT (LB12):  What is the point in having slotted aloha access in addition to the backoff in CAP, TDMA in CFP? Why is this complexity being thrusted on the implementors of this "low cost", "low complexity" and "low power" standard?I don;t see any justification in having yet another access scheme with WPAN.ORIGINAL SUGGESTED REMEDYRemove slotted aloha scheme in 8.4.3.4 and all references to it from the draft.RESPONSE: REJECT. Slotted Aloha was added to make the MAC more versatile so that more PHYs that could use the 802.15.3 MAC. While it could be added at a later date, that would make the MACs incompatible.REBUTTAL:SAME AS THAT FOR COMMENT 536 in LB12

SuggestedRemedy:
Remove MTS mechanism and slotted aloha mechanism and all references to them from the draft (This is applicable to section 8.4.4.4 and 8.4.4.5 in the current draft)


Comment:
same as comment #548 in LB12ORIGINAL COMMENT (LB12)Without SDL there is an higher risk of non-interoperable implementationsCommentEnd:  ORIGINAL SUGGESTED REMEDY (LB12)Provide formal description of the MAC and PHY. SDL can be one option.Response:  PROPOSED REJECT. The committee does not want to add normative contentthat may conflict with the other clauses. Informative content will notbe available until at least 3 months after the final draft has beenapproved.  SDL clause will be removed from the draft and left for afollow on project.REBUTTAL:While it is agreed that ideally all clauses in a standard must be coherentand non-conflicting with each other, it is well known that textualdescriptions can be vague at many places even after many reviews. On theother hand, formal descriptions do not have that problem since the checksand reviews are done by tools in addition to human reviews. Also note thatit is virtually impossible to avoid repeatition of information in textual description due to the very nature of such description. This repetitionleads to inconsistencies and hence resulting in multiple intepretationsof the same operation. Formal descriptions can be written to have NO repititions of the same operation anywhere and hence provide unique interpretation.

SuggestedRemedy:
Provide formal description of the MAC and PHY. SDL can be one option.


Comment:
clauses 5, 6, 7 and 8:Parent-PNC-DEV-address IE is used allover the document, while it has beenremoved from D11.I was informed over email on exploder that this needs DEV-address of PNCto be informed to DEVs through some means. I recommend using Piconet BSIDIE for this purpose by including DEV-address in it (and changing its nameappropriately)

SuggestedRemedy:
Extend Parent BSID IE to include parent-PNC-DEV-address and use that IEinstead of the currently used one.Extend Piconet BSID IE to include PNC-DEV-address

Response:
REJECT. The PNC DEV-Address is no longer used to distinguish the piconet, instead BSID identifies the piconet (with the PNID).  However, many parts of the standard refer to the Parent PNC DEV-Address and these will be changed to refer to the Parent BSID.


Comment:
The 20-day recirc time for this voluminous change in the draft is waytoo short of a time window.  We have our real jobs to do apart fromreviewing these changes. The task is made even more difficult by theunfriendly change marks in comparison doc. Some text that is changedis not marked as a change while lot of text that was present in theearlier draft is also marked as change. Hence this needs paper printof two drafts and meticulous comparison of the text and the figuresfor proper commenting on the changes. Because of the unrealisticallyshort time that was provided for the LB, I could not review any changes in clause 9, 10 and appendix

SuggestedRemedy:
Time provided for the recirc ballot must be made based on realistic estimate of time required to comment on the changes


Comment:
same as comment #536 in LB12ORIGINAL COMMENT (LB12)If SA is broadcast and anybody could start tx, how's collision handled?What is the point in getting devices to collide here instead of makingthis MTS part of CAP and letting devices freely use CAP as alreadydefined. This is useless and adds unnecessary complexityORIGINAL SUGGESTED REMEDY (LB12): Remove lines 8:22 on page 151 and all references to "MTS/GTS with BC/MC-SA"from the draftResponse:  REJECT. The slotted aloha access method is used to provide access to theseslots just as CSMA/CA is used in the CAP. The TG has decided to allow bothaccess methods, CSMA/CA in the CAP and slotted aloha in the MTSs so thatthe 802.15.3 MAC is capable of supporting different types of PHYs.REBUTTAL (LB19):The response does not resolve the issue of having COLLISION basedtransmissions under COLLISION FREE PERIOD, instead of making this partof CAP.I do not see 802.15.3 PHY or applications listed in PAR requiring it.I do not see how CSMA/CA mechanism used in CAP and TDM mechanism used inCFP fail in achieving whatever the slotted-aloha cheme is achieving.I do not see any reason or justification to add extra complexityresulting from having one another channel access mechanism.

SuggestedRemedy:
Remove MTS mechanism and slotted aloha mechanism and all references to them from the draft. (This is applicable to section 8.4.4.4 and 8.4.4.5 in the current draft)


Comment:
The last sentence in this para containing "it is also possible for thechild PNC to include a child piconet as a part of its own piconet" isnot clear. If the child piconet referred to in this statement is thepiconet to which the referred child PNC is PNC, then this is redundant.On the other hand, if the child piconet referred to is one anotherpiconet that is child to the "child PNC" then the sentence is incomplete.

SuggestedRemedy:
I think the intention is latter. If so, this forms chaining of piconetsin parent-child relation. Clarify the same in the draft.


Comment:
"more than one child piconet as part of the parent piconet" is vague

SuggestedRemedy:
change "as part of the parent piconet" to "under the same piconet"


Comment:
Can a child piconet have neighbor piconet associated with it? I think NOT.

SuggestedRemedy:
Clearly specify that a child piconet can not have any neighbor piconets associated with it.


Comment:
Can a member of child piconet, except the child PNC, communicate directly with a member of its parent piconet? I think NOT.

SuggestedRemedy:
Clearly specify that the member of a child PNC can NOT communicate directly with a member of its parent piconet.


Comment:
picking nits: the sentence using too many "if"s sounds too colloquial

SuggestedRemedy:
replace all "if" in this sentence with "whether"


Comment:
The requirement in "All DEVs in PSPS mode are required to listen to wake beacons" is not clear. What does this mean? All PSPS DEVs have to receive it or just be awake to receive it if channel permits?  I am sure the intent if NOT the former. If it is latter, then the maximum sleep time is made same for all PSPS DEVs. This is not acceptable. Depending on the power requirements some devices might want to go for longer, but permitted by PNC, sleep and wake up. Making those DEVs to wakeup to the time of TBTT is fine as in 802.11. This sounds similar to DTIMs in 802.11, but with worst performance outcome.

SuggestedRemedy:
Remove PSPS and revert back to APS mode as in D10 of the draft


Comment:
The sentence "All asynchronous traffic to DEVs in PSPS mode will be allocated in the wake beacon". What does this mean? if a DEV is in PSPS mode and there are 100 other DEVs requesting to send async data to it, all the 100 requests are allocated in the wake beacon? Why is this sentence needed.


Comment:
The term "wake beacon" deserves a clear description. What is it intendedfor as far as DEV is concerned? Clearly state if DEV is allowed to sleepONLY between two wake beacons and not allowed to sleep at TBTT of wakebeacons. But if this is true, note that this is not acceptable for DEVsintending to save power in a large magnitude.


Comment:
the inclusion of "to facilitate the formal verification of the protocol" raises questions as whether 802 is involved in that process, which it clearly is not. replacing the same with "for descriptive purposes only" might convey the intention better


Comment:
An easy one! Shoudn't there be some text differentiating when the effect isto start a child piconet v/s starting a neighbor piconet?

SuggestedRemedy:
Please add text describing what combination of parameter values shouldresult in child piconet and the combination for neighbor piconet.


Comment:
While this policy seems fine on the outset, there is little more that needs to be done to cover all the cases. If a DEV-A succesfully being in communication with another DEV, say DEV-B, and then disassociates for somereason and reassociates, DEV-B will still try to communicate with it as before. But No response from DEV-A can cause confusion at DEV-B. It would beunambiguous if DEV-A could send "Need to Authenticate/Associate" informationas the response (NOT instead of imm-ACK, though).

SuggestedRemedy:
1. Mandate the transmission of imm-ACK by ths rx-DEV for all directedframes requiring imm-ack response.2. By sending Authentication-Request frame the DEV receiving frames fromunassociated/unauthenticated DEV, the auth/assoc process can be restartedat the latter. Hence mandate that the former DEV sends Authentication-Request to the latter instead of keeping quiet and causingunnecessary confusion at the latter.


Comment:
The designation "Draft P802.15.3/D11, June 2002" is incorrect.

SuggestedRemedy:
I suggest "Draft P802.15.3/D11, August 2002"; please correct for D12 release date.


Comment:
A note is recommended to reenforce the idea that this is only for the ACTIVE to SPS and not for when the DEV goes to ACTIVE.


Comment:
line 26 - change "grants" to "grant"line 30 - change to "... type is set to super-rate ..."


Comment:
missing word ".... if there will be an allocated ..."


Comment:
The xref for IntegrityCode points to 9.6 for valid range. 9.6 itself is empty!Also, the xref for EncryptedSeed should be changed.

SuggestedRemedy:
xref to the correct location in clause 9 and 10.


Comment:
Change number of security modes to three.


Comment:
Table 18 has OrigID and none of the primitives seem to use that parameter


Comment:
AWAKE is noted as a mode. It is a state.


Comment:
Request that the exceptions do not include requests from child/neighbor piconets being placed ahead of GTS allocation for PSPS and SPS DEVs. It is appropriate to have a single pseudo-static GTS immediatly following the beacon. This assures that the 100us aFirstGTSGap is utilized in cases where CAP is not used. Remaining pseudo-static GTSs should be placed after PSPS and SPS DEV allocations. That is, way into the superframe.

SuggestedRemedy:
new text suggestion - "Exceptions to placing these allocations first are as follows and in order of priority. - QoS streams that need multiple GTSs within a superframe and require a location immediately following the beacon (and CAP if used).- If CAP is not used, a single GTS as follows to occupy aFirstGTSGap.     -- MTS from PNC - directed or multicast      -- A single Pseudo-static GTS"The original sentence is removed.


Comment:
The definition of a parent piconet could do with some work

SuggestedRemedy:
"A piconet which allocates private guaranteed time slots for another piconet (child and neighbor types) operating with the same channel".


Comment:
There is a mismatch on terms for the ACK policy field of the header as described in clause 7.2.1.4 and the text of 8.8 that uses ACK request field.

Response:
ACCEPT. Specific resolutions for this in other comments.


Comment:
The delayed ack text has a few problems -1) no mention of the setting for the Dly-ACK policy initially2) no mention of what to do with ACK policy bits on decline.3) no mention of what kind of data frame (The first fragment of the stream?) is used for at least the initial negotiation.4) The third paragraph mentions max burst value when talking about the Imm-ACK sent to decline the Dly-ACK negotiation. Doesn't seem to belong there.5) last sentence on pg 192, spelling of "source"6) there doesn't seem to be tie in to the DME providing the policy. There doesn't seem to be feedback to the DME that the requested policy has been denied by the recipiant. There is a result code in two tables in clause 6 MLME and MAC SAPs that talks about INVALID_ACK_POLICY but this seems to address the local capability to support Dly-ACK rather than a rejection by the destination.7) no mention of the rest of the content of the negotiation Dly-ACK frame body fields8) what does it mean that as an alternative to repeating the last data frame, an empty data frame which was not in the original burst.

Response:
1) This is fixed by referencing both "Dly-ACK policy and Dly-ACK request bit" being set. 2) The FCSL is now notified in the MAC-ISOCH-DATA.confirm as indicated in CID 310. 3) Same resolution as 1). 4) Move the sentence "The destination DEV may change the max burst value in each Dly-ACK frame." to the end of the previous paragraph that ends "... max num (sp) frames, as provided in the Dly-ACK frame 7.3.2.2." (note spelling error). 5) Change "souce" to "source" 6) Add a sentence that says "The FCSL would then notify the DME that the Dly-ACK negotiation failed.  The DME then knows that a modification of the channel time allocation might be required." 7)  Some more text?  Jay to write suggested new text to clarify, due Tuesday by 1:00 pm. 8 ) Jay to write suggested text, due Tuesday by 1:00 pm.


Comment:
If association MTS is used, it is for the request. Suggest changing the text on this page to reflect that the Association MTS is used for traffic to the PNC. For traffic to the associating DEV, an MTS with PNCID as source and AssocID as destination.The MSC of figure 96 seems ok

SuggestedRemedy:
suggest line 11 change from "in an association MTS" to be " using an association MTS process"suggest line 17. Add additional sentence "For association using MTS, the association response command is an MTS with PNCID as source and AssocID as destination."

Response:
ACCEPT. Change from "Before a DEV has completed the association process, all frames between the PNC and the DEV shall be exchanged either in the CAP of the superframe or in an association MTS." to be "Before a DEV has completed the association process, all frames sent to the PNC by the DEV shall be exchanged either in the CAP of the superframe or in an association MTS."
Add additional sentence at the end of the first paragraph "For association using MTS, the association response command is sent in an MTS with PNCID as source and UnassocID as destination."


Comment:
The change to include the designated child or neighbor missed this revision.See the resolution for d10.


Comment:
the idea of sleep is perhaps greater than not receiving. It is at least not transmitting or receiving and perhaps reducing power in other portions of the DEV. Awake is also more than just receive.


Comment:
next awake beacon is a 4 octet field while beacon count is now a 6 octet field. Either note that the next awake beacon  is the last 4 octets of beacon counter or change next awake beacon to be 6 octets.


Comment:
there is a missmatch on text and references in this grouping of commands with regard to next awake beacon. line 24 mentions that figure 49 has something to do with next awake beacon and it doesn't.Other sections in 7.5.7 xref back to 7.5.7.2 to get the definition of next awake beacon. There is none there.


Comment:
Since the text on line 8 says that DEVs can ignore any elements in the beacon payload that are not in table 39, it seems that the table needs to be corrected.A better choice may be to move the content to table 47 (information elements) with an additional column to indicate use (beacon, command, both).

SuggestedRemedy:
change table 47 as suggested.Delete table 39change text between lines 5 and 9 to remove table 39, add table 47 content and remove the text that says that IEs may be ignored.


Comment:
Although the idea of an ACTIVE CTA for an SPS DEV is "allowed," a caution sentence at the end of this paragraph should be added.

SuggestedRemedy:
add "Although this behavior is permitted, an undesirable reduction in battery life may result from unnessesary wake periods for SPS DEVs."


Comment:
There are some extra parameters in the MLME-START-DEPENDENT.confirm primitive. The primitive does not perform any channel scanning so the NumberOfChannels and ChannelRatingList should be deleted.


Comment:
The NumberOfDEVs valid range should point to clause 7.somewhere rather than an absolute number in this table.And, why is this 247? Shouldn't we just exclude 00, FF, FE, FD?Also suggest to do an xref for NmbrHndOvrBcns as well. This makes it consistent with Table 22 NmbrOfChangeBeacons being an xref


Comment:
This is for the mentioned text and also table 22.BeaconDuration seems like the wrong name for this parameter. Perhaps BeaconChange.


Comment:
I think the language of superframe duration being equal for child and parent piconet's is confusing in reference to figure 92. superframe periodicity or rate of repetition may be a better term.This comment should also be applied to neighbor piconet figure

SuggestedRemedy:
suggested text -"Figure 92 illustrates the relationship between the parent piconet superframe and the child piconet superframe. Note that the superframe periodicity is the same for both the child and the parent piconets."


Comment:
It is my belief that the start.confirm primitive is unnecessarily complex.  The Start.request primitive has been simplified (which I think was an excellent change) by making channel scan prerequisite and specifying a single channel index. With these changes the function required by start.confirm could (should) be correspondingly simplified.  Let's examine the three possible results of a start.request:1) There's no traffic in the selected channel for aMinChannelScan period.  We initialize all PNC parameters and began transmitting beacons. We return ResultCode = SUCCESS.2) The DME is so forgetful that it doesn't remember that it's already running a piconet? We return ResultCode = ALREADY_STARTED.3) A beacon, noise, or unidentified packets occur during aMinChannelScan period on the selected channel.We return ResultCode = PICONET_DETECTED.4) One or more of the parameters is invalid. We return ResultCode = INVALID_PARAMETERS.   I cannot see a clear case to be made for returning all of the remaining piconet information specified for the start.confirm primitive.  At a minimum there seems to be no reason to include number of channels or channel rating list in the return value since the arguments for start.request indicate only a single channel index.  The remaining piconet information returned may or may not be meaningful since PICONET_DETECTED is an ambiguous result code (it may just mean noise).  I would like to propose that we simply return the result code and make incumbent upon the DME to perform a channel scan to collect detailed information in the event of a returned ResultCode = PICONET_DETECTED. I would also like to propose that the term PICONET_DETECTED be replaced by CHANNEL_BUSY.

SuggestedRemedy:
MLME-START.confirm (                    ResultCode                   )6.3.3.2.2 Effect of receiptThe DME is notified of the results of the piconet creation procedure. A ResultCode of SUCCESS indicatesthat the DEV is the PNC. If another piconet is already established, the ResultCode shall beALREADY_STARTED. If the channel for the PHY is either occupied by other 802.15.3 piconets orhave unacceptable interference, then the ResultCode shall be set to CHANNEL_BUSY. The PNCDME then has the option of either sending another MLME-START.request to its MLME with a differentChannelIndex to start a piconet in a different channel or to send an MLME-ASSOCIATE.request to itsMLME to initiate an association as either a regular DEV, child or neighbor piconet of the PNC. If any of theparameters are in error the ResultCode shall be INVALID_PARAMETERS.


Comment:
Elsewhere is a reserved 0xFD for MTS traffic.Should there be some mention of that here?I have not figured the method for a DEV to request additional MTS slots. Is it in this text?


Comment:
With d11 is the change to establishing a CTR as SPS DEVs toggle between SPS mode and ACTIVE mode rather than predefining CTRs. Missing is text to provide for an "asynchronous" CTR to provide the functionality of the intermitant (persistence bit) operation.


Comment:
Moving the HCS out of Figure-5 is acceptable, but HCS is mentioned here without any preceding reference to it. Adding a Frame format picture anda brief decription of PHY v/s MAC elements of frame format in clause-5 isneeded.

SuggestedRemedy:
Add a overall frame format picture and a brief decription of PHY v/s MAC elements of overall frame format in clause-5


Comment:
Table 37: row for 101 has extra word "formats"


Comment:
inclusion of "isochronous stream" in this sentence raises an interestingquestion. Since "streams" are not defined as part of architecture in ch.5, (ignoring the deductions from rather abstract ch. 6) this seems to leadsomeone to interpret all streams have to be isoch to use Delayed-ack. That is not acceptable. All isoch's have to be streams, but all streams need notbe isoch. In other words someone could have non-isoch streams that do notneed strictly periodic allocations as in the case of isoch. Generalizationof this concept in the standard does not cost anything to implementationsand it increases the longevity of the standard.

SuggestedRemedy:
1. Remove the word "isochronous" from this sentence2. Add a brief introduction to streams in chapter-5 and clearly mention that   all isochs have to be streams (same as comment #496 in LB12) and there   can be non-isoch streams too that do not need strict Qos adherence as   in isoch streams

Response:
ACCEPT IN PRINCIPLE. Change ‘of an isochronous stream that is currently employing the Dly-ACK mechanism.’ to be ‘of a stream that is currently employing the Dly-ACK mechanism. It is not valid for frames using the asynchronous stream index or the MTS index.’


Comment:
Another good candidate to be moved to chapter-5 since contents of this section belongs  more as an introduction in ch-5 than along with MAC frame details in Ch-7. The details of HCS itself is in Ch-11.

SuggestedRemedy:
Move this subsection to ch-5 along with the recommended "overall frame format" information.


Comment:
the "sum" referred here must be (modulo 2) sum


Comment:
what is the use of SECID. If it is sent to a DEV in challenge-req and is repeated as is in every secure frame? Instead why not the issuing DEV keep this info for itself and map it with the DEV-ID of each destination for future use?

Response:
REJECT. To maintain proper synchronization of keying material, the SECID is required. It is the only way a DEV can determine that it is out of sync.


Comment:
DEV may reset the secure frame counter whenever key is updated too, right?

Response:
ACCEPT IN PRINCIPLE.  Add "The DEV shall set the secure frame counter to 0 whenever it receives a new key." to the end of clause 7.2.8.2.


Comment:
Why is the CTA IEs being made to appear at the beginning of the frame? In many DEVs when processing foreign beacons for MAC level channel assessment, even to look for the BSIDs associated with that rx-beacon, all the CTA must be parsed and passed through. This is a cumbersome process to be expected to be done by a DEV that is not in the same network.

SuggestedRemedy:
Move CTA IEs to appear anytime after the following basic information about the network in the payload of beacon frame.- piconet BSID- parent BSID- PNC Shutdown- piconet parameter changeOR simply move CTA IEs as the last set of IEs as was the case in D10

Response:
REJECT. Although in some cases it may help to have the CTAs last so that a DEV can shutdown early if it has not decoded a CTA assigned to that DEV within MaxProcessedCTAs.  However, with the CTAs first, the DEVs have more time to react to the channel time allocations and the CTAs start in a known location.


Comment:
This subclause mentions that "all beacons include the piconet synchronization parameter field". Where is this "field" in Table-39? Or is this an IE as it was in D10? I think Figure-12 and 13 seems to imply thatthis is a fixed-size field as opposed to variable length IE.

SuggestedRemedy:
There are two options:1. Make Piconet synchronization parameter as an IE as it was in D10. Move the description of Piconet synchronization parameter as an IE to clause 7.4. Add Piconet synchronization parameter as an IE to Table-47.OR2. if this is "fixed size field" in beacon frame, clearly mention so in 7.3.1 and update Figure-9 to include this field at the beginning of theframe-payload.

Response:
ACCEPT IN PRINCIPLE. Change the figure 9 title to be ‘Piconet synchronization parameters field format.’ Change the sentence ‘All beacons include the piconet synchronization parameter field.’ to be ‘All beacons include the piconet synchronization parameter field, as shown in the frame formats for the non-secure, {xref} and secure beacons, {xref}.’


Comment:
When CAP end time indicates no available time and no message types are permitted during the CAP, why should it imply MTSs? It should be CFP, instead.

SuggestedRemedy:
Change "MTSs are implied" to "CFP is implied"and Remove MTS from the draft


Comment:
In figure-10, clause 7.3.1, should the "CAP association" bit be set to 1 ONLY if "CAP commands" bit set to 1 OR Is the "CAP commands" is meant for non-association type commands instead of the whole set of commands? Latter helps in better differentiation of these two classes of commands.

SuggestedRemedy:
Explicitly state the intent.recommend that "CAP commands" bit in figure-10 refers to non-association type commands only

Response:
ACCEPT IN PRINCIPLE. After the sentence ending "... the CAP of the current superframe." add "The CAP command bit applies to all commands except for the association request command, which is covered by the CAP association bit."


Comment:
The inserted fields and sentences in this subclause mention the term "burst"The use of term "burst" is vague w.r.t Delayed-ack frame? Since the framessent over multiple GTSs (OR two discontinuous bursts within the same GTS)can be made to require only one Dly-ack frame response, it is not clearfrom the text whether this burst means the entire delayed-ack window or not.

SuggestedRemedy:
Please define "burst" or use some other term like "delayed-ack window"


Comment:
The new field "Num max frame size" is mostly useless. What if all the framesare (aMaxFrameSize-1) octets long? Instead of that, it is useful to includethe total number of octets as sum of number of octets in the payload of all frames sent in the dly-ack-window. this total number of octets is helpfulin buffer management at the receiver which is supposed to hold all theframes (in some corner cases) until a delayed-ack-frame is sent.

SuggestedRemedy:
1. Remove "Num max frame size" from Figure-15 and all its references from the fraft2. Include total number of octets as sum of number of octets in the payload of all frames sent in the delayed-ack-window


Comment:
Also needs to explicitly state that only "imm-ack" and "no-ack" are theonly valid alues for "ack-policy" field of all command frames to avoid mis-interpretation of absence of such explicit statements by vendors.

SuggestedRemedy:
Explicitly state that only "imm-ack" and "no-ack" are theonly valid alues for "ack-policy" field of all command frames


Comment:
In D10 the start of Information element was adjusted to be from even pos(2 octets) to help implementations having to deal with octet levelsearching for the start of required IE. Complexity involved in octetlevel searching is too much for low-cost implementations. This will also halve the computations needed in implementations that use higher size ords (like 4-octet).

SuggestedRemedy:
Put back the paragraph that mandated the start of an IE at evenposition of octets and hence the padding of a zero if an IE whenever thetotal size of that IE is odd number.


Comment:
Table-39 is incomplete. Section 8.6.2 has many more IEs listed to beincluded in beacon frame (examples are PNC handover, PCTM and P/SPS status)

SuggestedRemedy:
Include all the required IEs present in Beacon in Table-39

Response:
ACCEPT. Double check to make sure that all of the IEs that need to be there are in Table 39.


Comment:
In this sentence what does "multiple beacons" actually mean? Multiple beacons in the same superframe, similar to fragementing beacon, OR IEbeing present in beacons sent at different TBTT but each time with differentcontents of association info. I think what is intended is to say thatif there are too many assoc/disassoc, the beacon at current TBTT may notbe big enough to carry them all, so the remaining Dev-assoc-IEs will befilled into the next beacon sent at next TBTT

SuggestedRemedy:
If intended, do NOT allow fragementation of beacon. Alter the sentence inln42:43 to mean that the PNC may send IE corresponding to a recent assoc/deassoc in the beacon at next TBTT if the current beacon does nothave space for it.

Response:
ACCEPT IN PRINCIPLE. Delete the sentence "The PNC may use multiple beacons to broadcast successive DEV association IEs if too many DEVs are associating than will fit in a single beacon.." as it is confusing and does not add any new information.  The PNC is able to choose when it sends any IE.


Comment:
Can the same association info repeated over several beacons sent at consecutive TBTTs? Since a beacon could be lost at a DEV some repetitionof this info is very desirable.

SuggestedRemedy:
Mandate that the dev-assoc info must be repeated atleast twice (A totalof three transmissions) and the repitions can be delayed to accommodatethe newer assoc/disassoc.

Response:
ACCEPT IN PRINCIPLE. This is already required in 8.3.1, page 164, lines 50-51 where the PNC repeats it at least aMinBeaconInfo which has a value of 4.


Comment:
What is the use of information on (a) MaxProcessedCTAs  and (b) MaxAssignedCTAs at the DEVs that receive this info in the beacon? Whatare they supposed to do with it?

SuggestedRemedy:
Remove (a) MaxProcessedCTAs  and (b) MaxAssignedCTAs from DEV-association IE


Comment:
When a DEV wants to communicate with another DEV, it has to find itusing probe mechanism which should fetch the capability info, anyway. Whywaste the bytes in beacon to send the capability information of the newlyassociated or (even worse) disassociated DEVs?

SuggestedRemedy:
Remove capability field from Dev-association IE

Response:
ACCEPT IN PRINCIPLE. Delete the capability field, change the name of the Association status field to be "DEV characteristic".  In the new DEV characteristic field, put in a 1 bit Association status field that is 0 for disassociated and 1 for associated, a 5 bit "Supported data rates" with an xref to where defined in 7.11 (or where this goes in the future) and 2 reserved bits.  Check in other places where Association status field is defined to see if they need to be changed to match.


Comment:
What is the use of "Authenticated" value of the field, here? Since DEVs are individually responsible to authenticate other DEVs in the piconetwhy do they care whether this DEV is authenticated with PNC? Why clutterthe air time sending this information when it serves no purpose to anyone?if authentication is there, shouldn't there be de-authentication too? BTW, the field is called "association status" NOT "device status" or "assoc/auth status"

SuggestedRemedy:
Remove "authentication" as a valid value for "association status field"

Response:
ACCEPT IN PRINCIPLE. DEVs are not required to authenticate to other DEVs in a piconet.  They are only required to authenticate with the PNC in a secure piconet.  However, this status is not useful here, therefore it will be removed as valid value as indicated in the resolution of CID 417.


Comment:
keep DEV-ID and association status fields together, since they make anice two-octet word leaving other fields also in the same fashion

SuggestedRemedy:
keep DEV-ID and association status fields together as in D10 or move both of them to the RHS of Figure-28

Response:
ACCEPT IN PRINCIPLE. Move DEV address to the first position in this IE and in the PNC info command's DEV record on page 139, figure 64.


Comment:
Mention of psuedo-static GTS needs some prior description of the same (Ch 6 mentions it without describing what it is)

SuggestedRemedy:
A brief description of psuedo-GTS in contrast to GTS is needed either in5.3.5 or 5.3.6


Comment:
The textual description of this subclause is overwhelming for the simpleconcept it is trying to convey. The description is not even in the sameorder of values listed on previous page. A tabular form of the same isa better bet anyday.

SuggestedRemedy:
If this IE is retained as is (mostly) remove the textual descriptioncorresponding to the values of ChangeType


Comment:
This IE unncessarily tries to carry too many unrelated things in one baggage. Splitting this into multiple IEs eases both the understandingof the IE and its implementation. Additonal question is, if ChangeTypeis to be extended in the future for to convey some other "change" how arethe new fields required introduced into this closed bag? There is no needto require two levels of parsing to know what the intent of IE is.

SuggestedRemedy:
Split this IE into the following:1. PNID/BSID change IE with both PNID and BSID being present and being    current all the time2. TBTT change IE (define the term TBTT - it is a very useful term)3. Superframe-Size change IE4. Channel change IE


Comment:
given the current description of the IE, a better name wiould be "Vendor specific IE"

SuggestedRemedy:
a better name wiould be "Vendor specific IE"


Comment:
Why create another "Vendor ID" when OUIs are already in use in this type ofapplications? and OUIs are managed by IEEE. RAC currently does not have anyinfo on 2-octet wide ID registration scheme on their web-site. Either this2-octet ID registration does not exist or is still in the process of beingdecided/finalized. Why use something that is still in the process of makinginstead of the one that is already been established?


Comment:
What is the use of Application-data-ID? Once the Vendor ID (or OUI) ispresent the rest of the format must be left to the vendor to define anduse.


Comment:
What is the use of DEV-ID once the Vendor ID (or OUI) ispresent that lets the rest of the format to the vendor to define anduse? If the rx-DEV does not recognize the Vendor-ID, it is going to dropthe IE whether the DEV-ID is its DEV-ID or not, right? If the vendor wantsto add DEV-ID under one of the cases, let them do it on their own.


Comment:
Inclusion of BcstID and McstID in this sentence - When a CTA for BC/MC destaddress is being allocated, these bits shall be set

SuggestedRemedy:
revert back to the sentences in D10 (pp124, ln 41:45)


Comment:
There is limited use of "PNC handover" IE as it is defined and that isconveys that the current PNC is not going to continue as PNC. Instead ifthe DEV-ID and DEV address of the new PNC are also announced, then itprovides all the required info at the associated DEVs.

SuggestedRemedy:
Include DEV-ID and DEV address of the new PNC in Figure-33 and add theirdescriptions in 7.4.9ANDchange the caption appropriately. it is definitely not "DEV address information"


Comment:
Where is this "DEV address" IE used? I can't see any use for it since atall places there seems to be direct 6-octet field for the same purpose


Comment:
The changes in command frames (Assoc and disassoc) have rendered thisIE useless. Where is this IE used?

SuggestedRemedy:
remove this IE and move the defintion of "capability field" to 7.4.4 whereit is used first.


Comment:
Text in ln 19:22 and Figure-41 are utterly confusing. Is this trying to tellthat Public-key objects larger than 254 octets can be fragmented and can be sent in multiple IEs that have appropriate indices? In any case, state clearly.

SuggestedRemedy:
Change the text in ln 19:22 and figure 41 to following:Text:If the public-key object is larger than 254 octets, it can be fragementedwith fragment size of 254 and sent in atmost 4 IEs. The fragmentation isonly due to the reason that IEs do not accommodate more than 254 octets.For this purpose there are four public-key object IE indices defined for this in Table-47. They are  - Public-key object carrying first fragment or the entire public    key object if it is less than 255 octets long  - Public-key object-1 carrying second fragment, if present  - Public-key object-2 carrying third fragment, if present  - Public-key object-3 carrying fourth fragment, if presentWhen fragmentation is performed, the corresponding IEs shall be placedtogether in the frame carrying them and they shall appear in the order ofthe fragment they are carrying with fragment-0 appearing first.Figure: four different boxes, one for each IE, with their payload joining to form overall Public-key-object


Comment:
in "they should be considered to be listed in order of preference", change the use of should to shall to make it normative

SuggestedRemedy:
change "they should be considered to be listed in order of preference" to"they shall be listed in the order of preference"


Comment:
Given that same PNID can be used by multiple Piconets with different BSIDs,it's a good idea to add BSID to Figure-43 for each PNID report. This enablesthe PNC to know the number of actual piconets around in that channel.

SuggestedRemedy:
Add BSID to each piconet report in figure-43

Response:
REJECT. The overlapping PNID element is only used to report PNIDs.  The PNC is required to change its PNID if an overlapping piconet is found that uses the same one.  However, the PNC is not required to change its BSID.  The actual number of piconets using the PNID is not important, rather it is simply the existence of at least one piconet with that PNID that matters.  Furthermore, this IE is sent even if only a frame and not the beacon is detected on another channel.  In this case, the DEV doesn't know the BSID.


Comment:
1. The very concept of indicating "application layer" capabilities doesnot belong in MAC. This is a potential issue in sponsor ballot. If thisis absolutely needed, there is application specific IE that can be usedfor this purpose. The payload of the "piconet services" IE is not defined in this draft anyway (that is, it is already vendor specific).2. Inclusion of DEVID is redundant. Given that this IE is sent by a DEV in piconet to indicate its "application layer" capabilities, what is theneed for adding DEVID here since the MAC header of the frame already contains the DEVID?

SuggestedRemedy:
If possible remove this IE or atleast remove DEVID


Comment:
The corrections in these sentences are incomplete. clause 8.9 states thatDEVs can use Probe and Channel status commands to exchange information inpeer-peer fashion. But this clause seems to limit the exchange of allcommands to only between PNC and a DEV.

SuggestedRemedy:
Change all occurrences of "PNC" in sentences in ln 7:9 with "destination DEV"ORJust retain the sentences related to response from DEV to command framesin D10

Response:
ACCEPT IN PRINCIPLE. Change "PNC" to be "PNC or destination DEV"


Comment:
While the inserted text in these lines lists the commands that can befragmented, it does not provide any information as how those fragments arehandled. The subclauses on those commands also do not talk about it.The clause on frag/defrag (8.7) refers to MSDUs only. It does not talkto the case of fragmentation of commands.

SuggestedRemedy:
1. Add the following at the end of sentences on ln 31:35"The fragmentation and defragmentation of these commands are handled inthe same as that for data frames as described in clause 8.7"AND2. Update 8.7 by replacing all occurences of MSDU with "MSDU/MCDU" and define MCDU as "Mac command data unit"


Comment:
The new description of ATP is missing the units of the field (milliseconds, Kilo microseconds?)

SuggestedRemedy:
Provide the units of the ATP field as in milliseconds in consistent withother MIB/PIB time units

Response:
ACCEPT IN PRINCIPLE.  Add that the units are in millisconds here and in 7.5.1.2


Comment:
DEV utility field is unnecessary. Since piconet services are vendor specificthis should be part of vendor-specific command that can be sent by any PNC or DEV at any time after the assoc/auth process is complete as per theneeds of the implementation.

SuggestedRemedy:
Remove DEV-utility field from Figure 45 and clause 7.5.1.1


Comment:
Swap the positions of DEVID and DEV-address as they were in D10. It helpsmost all implementations by providing two-octet alignement for DEVID andATP etc in the command payload.Before the response is going to refer higher-octet alignedimplementations, Yes, it does not avoid the two-octet alignmentissues in those implementations. But it simplifies therealignement process even in those implementations

SuggestedRemedy:
Swap the positions of DEVID and DEV-address as they were in D10


Comment:
The new reason code "8 -> Association denied" probably has the intentionof association denied for unknown reasons since there can be many otherreasons that might crop up in the future that need not result in theupdation of the standard. Please provide clear description of the code

SuggestedRemedy:
Change "8 -> Association denied" to"8 -> Association denied for unknown reason(s)"


Comment:
PNC would need to allot a time limit for response to its handover requestafter which the PNC should try another capable DEV for the job. What if thethere is little time at PNC and the DEV is taking its sweet time to respondsince it has other things to check (or finish) before accepting theresponsibility? what should the PNC do?

SuggestedRemedy:
either1. Do not remove the timeout field. retain it as in D10OR2. specify that the PNC can send the request to multiple capable DEVsbut shall handover only to one of the multiple responding DEVs. PNCmust not assume that the DEV is willing accept the responsibilityuntil the "PNC handover response" command is received.At DEV side, DEVs shall not send the "PNC handover response" command ifthey are not willing to accept the responsibility of PNC and DEVsmust consider that their acceptance is not complete until the info istransferred to them through "PNC handiver information command".


Comment:
IS there a way for the DEV to reject the offer? There may be many reasonsa DEV may want to reject the offer at the time of offer, for example, ifthe DEV is also leaving the piconet in a short while OR the channel condsare just too bad at its location.

SuggestedRemedy:
Either1. Add a field of reason code to Figure-60. Reason code of 0 is acceptanceand the rest can be allocated to different possible reasons for therejection2. specify that the PNC can send the request to multiple capable DEVsbut shall handover only to one of the multiple responding DEVs. PNCmust not assume that the DEV is willing accept the responsibilityuntil the "PNC handover response" command is received.At DEV side, DEVs shall not send the "PNC handover response" command ifthey are not willing to accept the responsibility of PNC and DEVsmust consider that their acceptance is not complete until the info istransferred to them through "PNC handiver information command".


Comment:
Why is "Next Beacon" required? Once the CTRB description is provided tothe new PNC, it is upto that PNC to allocate CTAs?

SuggestedRemedy:
Remove all occurrences of the field "Next Beacon" from Figure-61


Comment:
Figure-64 has following fields with no description- ATP- MaxProcessedCTAs- MAxAsignedCTAs- AssociationStatus


Comment:
occurrences of letter n is unquoted. I think listing single letter variablesor terms is required to be under single quotes. please check.


Comment:
The very concept of indicating "application layer" capabilities doesnot belong in MAC. This is a potential issue in sponsor ballot. If thisis absolutely needed, there is application specific IE that can be usedfor this purpose with vendor specific command. The payload of the "piconet services" IE is not defined in this draft anyway (that is, it is already vendor specific). Let the vendor use the combination of "Vendor specificcommand" and "Vendor specific IE" and the freedom of command payloadformat to achieve whatever is desired in their products without causingany interoperability issues


Comment:
Textual description of CTR interval type field is vague and introduces two new terms "super-rate" and "sub-rate" without defining them.The definition of the same field in D10 is bad, but here it is worse. Retainthe lesser evil of the two.PS: Even after reading the draft several times, I had to refer to D10 tounderstand what the CTR-interval-type field values meant. Without this change, please consider this comment as part of NO vote


Comment:
This clause uses the term "TU" that is not defined before.


Comment:
Instead of posing the restriction on the request, mandate the minimum implementation.

SuggestedRemedy:
Remove the sentence in this line add insert the following.A PNC shall support atleast 8 slots per stream in the same superframeNote: reason code #9 should be the answer from PNC when a DEV requestsmore # of slots per superframe that is currently supported by the PNC


Comment:
Reason code 6 has become unreasonable. Why should a stream be terminatedjust because DEV is in PS mode?

SuggestedRemedy:
Remove the inserted text "Stream terminated, "


Comment:
The amendment is incomplete. It does not describe the DEV-to-DEV exchangewhere PNC is not involved

SuggestedRemedy:
Remove the current amendment and insert the following at the end ofline-3 on page 145:When the DestID of this command is PNCID, the values in the channelstatus shall correspond to all directed frames exchanged by the DEVand other DEVs in the piconet. On the other hand when the DestId ofthis command is a non-PNC DEV-address, the values in the channelstatus report shall correspond to the directed frames exchangedbetween the requesting DEV and the target DEV.

Response:
ACCEPT IN PRINCIPLE. ‘When the DestID of this command is PNCID, the values in the command shall correspond to all frames exchanged by the DEV with other DEVs in the piconet. When the DestID of this command is a non-PNC DEVID, the values in the command shall correspond to the frames exchanged between the requesting DEV and the target DEV.’


Comment:
The mention of "parent PNC DEV address IE, 7.4.3": This IE is not presentany more.

SuggestedRemedy:
Change"The parent DEV address is the address from a parent PNC DEV addressIE, 7.4.3, found by the DEV in a beacon"to"The parent DEV address is the address of the parent PNC  for thecorresponding piconet as extracted from its Beacon"ANDAdd parent PNC DEV address in the beacon.ORIt would be sufficient to add DEV-address field in Parent BSID IE andchange the name of that IE appropriately instead of adding a new IE.That way in Figure-78  parent PNC DEV address can be removed with no changein text

Response:
ACCEPT. Change the BSID IEs to include the MAC address of the PNC (or parent PNC). Rename the IEs to be the Piconet IE and Parent piconet IE. Rename throughout (after change from Parent DEV address to Parent BSID IE.) Change the lengths of the fields in this command to be 14-40.


Comment:
What si the difference between "awake beacon" used here and the "wake beacon" used in 5.3.10? What is the need for two different things forthe same purpose?

SuggestedRemedy:
I think they are same. If same, use the same nominclature.If not same, make them same.


Comment:
There is a grave mistake here. This is not supposed to be "number of supported SPS sets" it is supposed to be "Number of existing SPS sets".What if a PNC supports 100 sets but only 3 are existing currently. Howdoes the implementor is supposed to interpret this line in that case?PS: This this text has been there since D10, the comment is marked "Tech"only as opposed to "Tech-Req". The voter is aware that this comment maybe rejected since it is not a change from D10 to D11.

SuggestedRemedy:
Change "number of supported SPS sets" to "Number of existing SPS sets"


Comment:
Use IEEE managed OUI instead of vendor ID

SuggestedRemedy:
Use IEEE managed OUI instead of vendor ID


Comment:
use "channel statistics": In order to make the implementations uniformand interoperating in this respect, it is a good idea to define channel statistics in a concrete manner, like PER. Otherwise eachimplementor chhoses his/her own "channel statistics" and hence resultingin potentially conflicting conclusions on channel condition.

SuggestedRemedy:
Mandate DEVs to measure PER and use that as a measure for rating thechannels


Comment:
Although I think it is against the intention, the text seems to overburdenthe task of starting piconet. DME needs some channel statistics to decideon channel, which I presume obtained at the time of scanning procedure. ThenDME decides the channel. The text further imposes that DEV check for channelbeing clear and then start a piconet. If DME has already taken the channelstats into account and has decided the channel (a) this causes the DEV tosecond check the channel which is waste of time and overhead for implementations and (b) Especially the last sentence in the para that mandates (use of shall) return of failure  without starting a piconetcontradicts the next (new) para where a capable DEV can start a neighbor(or child) piconet in a channel where a piconet already in existence.

SuggestedRemedy:
Change all "shall" to "may" in the para and let implementors decide whichof the three solutions they want in their products


Comment:
Removal hnadover timeout: What if the DEV to which the handover is happeningdies or its power is plugged out? What does the PNC do in that case?

SuggestedRemedy:
Do NOT remove the timeout from the handover request command and hence inthis paragraph


Comment:
This sentence does not belong here. A generalization of this sentence isbetter suited in 7.5, pp-131 after line 34. The generalization must befor all the commands that can be fragemented as listed above line 34,pp 131.

SuggestedRemedy:
Move this sentence to clause 7.5, pp-131 after line 34 with the generalization  such that it applies to all the commands that can be fragemented as listed above line 34, pp 131.


Comment:
Scattering of text on fragmentation of command frames.This sentence does not belong here. A generalization of this sentence isbetter suited in 7.5, pp-131 after line 34. The generalization must befor all the commands that can be fragemented as listed above line 34,pp 131.AND this sentence makes the sentence on line 8:9 pp 156 redundant since thesentence on ln 17:18 includes the PNC handover information too.


Comment:
Figure-91 is a well done job, but the text needs to supplement some infothat can not expressed in the figure, which is incomplete in the currentupdate to this para. It should be mentioned that these commands shall besent by PNC even if there is no information present that fits into thosecommands so that the rx-DEV knows the exact end of the transaction. Forexample , what if there are no DEVs in power save mode. Still the SPS-inquiry-response-command shall be sent by PNC.

SuggestedRemedy:
It should be mentioned that the three commands in Figure-91 (PNC-info-command, PNC-handover-info-command and SPS-inquirey-response-cmd) shall be sent by PNC even if there is no information present that fits nto those commands so that the rx-DEV knows the exact end of the transaction. For example , what if there are no DEVs in power savemode. Still the SPS-inquiry-response-command shall be sent by PNC.


Comment:
neighbor of a child is left out. Specify whether it can be done or not.I think it can be done.

SuggestedRemedy:
Include "neighbor of a child" after "child of a neighbor" in ln-2


Comment:
Infinite (or as much as practically possible) chaining of "child of a child"deserves a mention here, especially since the mention "child of a child can be interpreted to be just the three level chaining (including the parent piconet)

SuggestedRemedy:
Either specifically limit the chaining to child of a child (three levels including parent-Piconet) or clearly state that any depth of chaining is allowed in the standard


Comment:
These two sentences have one exception and that is the PNC of the child pcionet. But the mention of child PNC comes after a complete page afterseveral other information and pictures.

SuggestedRemedy:
Please put them together for ease of readv (ln 4:9 in pp 159 andln 29:31 in pp160)


Comment:
Title of 8.2 needs to be "Starting, maintaining and stopping of piconets"

SuggestedRemedy:
Change the title of 8.2 to "Starting, maintaining and stopping of piconets"


Comment:
The reference to "child PNC" is vague and not required since those child piconets may move to another channel OR become a child piconet of the newparent-PNC or neighbor piconet of the new master without having to shut down? Let the implementor choose what they need for their products. Donot force them to shut their network for the sake of compliance.

SuggestedRemedy:
Specify that the piconets may move to another channel OR become a child piconet of the new parent-PNC or neighbor piconet of the new masterwithout having to shut down. However all this must happen before theend of the supreframe in which the current parent PNC is supposed tosend its last beacon.


Comment:
Actually this line implies that there is a way to specify the "lowest DEVID" among child piconets in the "PNC shutdown information". But figure-29 on pp 122 has no such provision.

SuggestedRemedy:
Either remove this sentence on pp 162, ln-50 AND specify that all child piconets will cease their "parent-child" relation with the parent PNC.ORadd child piconet DEV-address field to Figure-29


Comment:
Actually this line implies that there is a way to specify the "lowest DEVID" among neighbor piconets in the "PNC shutdown information". But figure-29on pp 122 has no such provision.

SuggestedRemedy:
Either remove this sentence on pp 163, ln-8:9 AND specify that all neighbor piconets will cease their "parent-neighbor" relation with the parent PNC.ORadd child piconet DEV-address field to Figure-29


Comment:
Can those neighbor piconets may move to another channel as independentpicoents without shutting down? OR become a child piconet of the newparent-PNC or neighbor piconet of the new master without having to shut down? Let the implementor choose what they need for their products. Donot force them to shut their network for the sake of compliance.


Comment:
The reference to the "remaining neighbor PNC" is vague

SuggestedRemedy:
change "remaining neighbor PNC" to "neighbor PNC whose DEVID was listed inthe parent PNC's piconet-shutdown-command"


Comment:
8.2.6.1 and 8.2.6.2 can be combined into one through the use of "dependentpiconet" and hence avoid repetition of text and the possible inconsistencies8.2.6.3 will just be an overriding statement in the combined subclause(Actually since all child PNCs are members of parent piconet, their DEVIDought to be lower than those of neighbor PNCs. Hence a generalizedstatement on parent PNC picking low DEV-ID is good enough).

SuggestedRemedy:
8.2.6.1 and 8.2.6.2 can be combined into one through the use of "dependentpiconet" and hence avoid repetition of text and the possible inconsistencieswith 8.2.6.3 as an overriding statement


Comment:
subclauses 8.2.6.4 and 8.2.6.5: There are several points that should benoted here.1. This scheme should be made same for both child and neighbor piconets.   Even use the same subclause by using the term "Dependent piconet/PNC"2. There is no reason to force the dependent piconet to shutdown. If they   can go to another channel before the parent PNC cuts them off or    establish dependent relation with the a different child/parent PNC,   why not?3. Parent PNC is keeping a max-timeout that is not known to the dependent   PNCs. This is not fair. This can be announced4. Child piconet disappearence need not mean the termination of the child   PNC's membership from parent-PNC

SuggestedRemedy:
Change clauses 8.2.6.4 and 8.2.6.5 into one clause with the followingdescription8.2.6.x Parent PNC terminating its relation with a dependent piconetIf the parent PNC wishes to terminate its relation with a dependent piconet,the parent PNC shall include "Terminate Dependent PNC" IE in itsbeacon with the termination countdown in that IE decremented by one in everysuccessive beacons. The dependent PNC has time until the end of the superframe in which the termiantion countdown reaches zero to eitherend its relation with the current parent PNC. The dependent PNC has the options of shutting down its piconet, moving onto another channel andbecoming some other PNCs dependent within this given time.AND in clause 7 define the following IE7.x.x.x Terminate Dependent PNC  1 octet          1 octet         1 octet    1 octet  Termination      DEV-ID of       Length     IE-index  count            dependent PNC   (=2)       (as appropriate)This IE shall be placed in beacon by a parent PNC only as per the descriptions in clause 8.2.6.x


Comment:
I don;t see why the description of non-PNC capable DEVs be present inthe clause where starting and managing a piconet is being described.

SuggestedRemedy:
Please move this to introduction (8.1) along with another line describing PNC and PNC capable devices.


Comment:
First complete paragraph of cluse 8.3.2:It's disappointing to see how much time and energy has been wated on thispiconet services IE given that there is very little use for it and thesame can be better achieved by Vendor-specific commands and/or IE. If thepcionet services field definition is outside the scope of the standardhow can that standard decide how this info is exchanged between DEVs?

SuggestedRemedy:
Remove this exchange mechanism (and preferably the piconet services IE)from the draft


Comment:
Third and fourth complete paragraph of cluse 8.3.2:It's disappointing to see how much time and energy has been wated on thispiconet services IE given that there is very little use for it and thesame can be better achieved by Vendor-specific commands and/or IE. If thepcionet services field definition is outside the scope of the standardhow can that standard decide how this info is exchanged between DEVs?a probe from any interested DEV to another interesting DEV can obtainthis IE. Why should PNC go through this hoops for this otherwiseeasily achivable task?Bottom line is, once a DEV comes to know of existence of another DEV inthe piconet, through PNC, the second DEVs properties must be obtainedby the first DEV by sending a SIMPLE, DIRECTED probe (req) and gettinga probe  (Response) in return.

SuggestedRemedy:
Remove this exchange mechanism (and preferably the piconet services IE)completely from the draft


Comment:
Another hoops to go through at PNC for this information that standarddoes not have any control on. LEt the vendors decide how to communicatethat info. This is not the only vendor specific info that is communicatedin implementations.

SuggestedRemedy:
Remove any updates to this clause (and preferably the entire clause)


Comment:
Sentence starting from "Similarly" is misplaced.

SuggestedRemedy:
Move its previous sentence starting from "If the DEV does not have any ..." to be before the sentence starting from "If the PNC does not receive any frame" so that the sentence starting from "Similarly" is correctly positioned.


Comment:
Relationship between RIFS and SIFS:Strongly NO to changes in D11. RIFS is deviced such that in a GTS if theGTS owner does not waste a lot of time in waiting for the response thatdoes not arrive. If the Sender of a data frame (say) did not see PHYenergy in one slot after SIFS, it should be allowed to assume that theresponse is not going to come and hence start retransmissions.An entire ACK time is way too much waste of time.


Comment:
Updates are incomplete and not quite specific:Beacons in a superframe are sent at the start of superframe. Since all CAPtransmissions are mandated to end before the end of CAP, there should notbe any hesitation in saying that the beacon must start at TBTT, definingTBTTs to be the start of superframe which occur at strictly regularintervals conditioned upon the clock accuracies as spcified by the standardand/or MOVE of superframes as decided by PNC. right? If there are otherspecial cases, please do list them, instead of leaving unspecified/vaguethe very basic concept in the standard. Specifying it now will avoidlot of headaches later, especially in the presence of psuedo static and private GTSs.

SuggestedRemedy:
Define TBTTs to to be the start of superframe which occur at strictly regular intervals conditioned upon the clock accuracies as spcified bythe standard and/or MOVE of superframes as decided by PNC


Comment:
by "subrate allocations", I presume the slots occuring once per multiplesuperframes. For those slots it'll be very difficult at PNC to manage psuedoGTS and handle all the chnages in cahnnel and/or allocations

SuggestedRemedy:
1. Define subrate and superrate slots somewhere before this2. please find some other terminology for subrate and superrate slots.   It is easy for the readers to get confused and perceive this being    unnecessarily complicated3. In any case make sure, the psuedo-GTS being not applicable to slotsoccurring once per multiple superframes

Response:
ACCEPT IN PRINCIPLE. 1. Add definitions for subrate and super-rate slots to Clause 3.  2. The TG is open for suggestions for new names for subrate and super-rate.  To date, we have been unable to find better terminology. 3. Yes, the text indicates that psuedo-static CTAs are not allowed to happen once per many superframes, rather they are allocated every superframe.


Comment:
The sentence "the PNC may overlap the allocations for the old and new psuedo-static GTSs" generalizes the overlap for all psuedo-static GTSs andhence contradicts the earlier statement that restricts the PNC from doingso.

SuggestedRemedy:
Change"the PNC may overlap the allocations for the old and new psuedo-static GTSs"to"However note that the PNC may overlap the old and new locations of the samepsuedo-static GTS within a superframe as it does not cause any issue offrame collisions"


Comment:
The restriction on the source of psuedo-static GTS is a good addition. Butit should also be mandated NOT to use both old and new allocations at thesame time. This makes the intention of the restriction very clear and avoidsthe vendors from trying get around by using the "new" allocation as perthe restriction on ln6:7 and take advantage of absence of restriction onNOT using the old allocation, because it is not allocated to anybody yet.

SuggestedRemedy:
Change"the PNC may overlap the allocations for the old and new psuedo-static GTSs"to"However note that the PNC may overlap the old and new locations of the samepsuedo-static GTS within a superframe as it does not cause any issue offrame collisions. If PNC sees the usage of the new allocation by both the source of the destination of old allocation before the expiry of aMAxLostBeacons number of supreframes, then the PNC may reuse the old allocation for another pair of DEVs"(Note: The second sentence allows for value-add at PNC without compromisingthe original intention)2. Add the following at the end of sentence ending on line 7:"However the source DEV shall not use the old location of its psuedo-staticGTS in the superframe once it starts using the new location for the same"

Response:
ACCEPT IN PRINCIPLE. Change "the PNC may overlap the allocations for the old and new psuedo-static GTSs" to "However note that the PNC may overlap the old and new locations of the same psuedo-static GTS within a superframe as it does not cause any issue of frame collisions. If PNC sees the usage of the new allocation by both the source of the destination of old allocation before the expiration of aMAxLostBeacons number of supreframes, then the PNC may reuse the old allocation for another pair of DEVs" After the end of sentence "... and begin using the new GTS." The second point is already handled in the draft with the requirment on page 171, line 6, "When the source of a pseudo-static GTS receives a beacon with the new CTA, it shall cease using the old GTS and begin using the new GTS."


Comment:
A couple of editorial comments:1. pp 172, ln 1:4 - What is the difference between the two last sentences in this para?One uses "should" and explains why and the Other uses "may" and does not.2. pp 172: line 15:17 - Multiple use of "channel time response command" making the whole sentence awkward3. pp 172, ln 19 - sentence using "will need to" sounds better with "may"

SuggestedRemedy:
1. pp 172, ln 1:4Combine the two sentences by generalizing as follows:"If a DEV misses a beacon it is upto the DEV to listen to the entire superframe to make out if the GTS (psuedo-static or not) for which the DEVis a destination is being moved"2. pp 172: line 15:17 - Please correct it3. pp 172, ln 19 - Change "will need to" to "may"


Comment:
What happens if there are more isoch streams started in the parent piconetand the parent wants to just restrict the allocation instead of kickingthe child away (being a parent, I am sympathetic on this issue :-))

SuggestedRemedy:
Follwing the same rules for psuedo-static GTSs is sufficient for dependentpiconets also


Comment:
change "needs to be" to "shall" for mandating the behavior

Response:
ACCEPT IN PRINCIPLE. Change the sentence 'If an Imm-ACK or del-ACK is expected for that frame, ...  PHY rate as the transmitted frame.' to be ‘If an Imm-ACK or Dly-ACK is expected for that frame, the DEV shall check whether there is enough time remaining in the time slot to accomodate the current frame, 2 SIFS periods and the Imm-ACK or Dly-ACK frame at the same PHY rate as the transmitted frame.’


Comment:
ahh, This para is nicely written as an introductory material, but coming after most of its use is described in other clauses.

SuggestedRemedy:
Move this para as the second para in 8.4.4.2 or even better as part of thetext for clause 8.4.4.1


Comment:
The update does not cover whether the indicated responsiveness in the beacon can change over time due to reasons like network load. I get the impressionthat is the intention, but it is not clearly stated

SuggestedRemedy:
State that the PNC can change the value of CTRRespTime from time to time.It may be a good idea to restrict PNC from changing it an association process is ongoing to avoid any confusion.


Comment:
Sentence "There is no guarantee of the length ...": Isn't CTRRespTime designed to provide this?


Comment:
This statement is trying to have a say on the guts of an implementation,although I think the intention was to say that the PNC may send an updatedBeacon at TBTT, even if there was a failed attempt to convey the channeltime response to the source DEV.

SuggestedRemedy:
Remove the sentence on ln 11:12 on page 179 and insert the following:The PNC is allowed to send an updated Beacon at the start of a superframethat has the updated CTA corresponding to a GTS, if there was atleast oneunsuccesful transmission of channel time response command to the sourceDEV of that GTS. However the PNC shall retry the channel time response command until it is either succesful or maximum retry count is reached.


SuggestedRemedy:
There are three options:1. Remove this sentence completelyOR2.Change "DEV in its wake beacon" to "DEV in the superframe corresponding toits wake beacon"OR3. Define channel status as an IE and include it in Beacon


Comment:
It is hard to decipher this sentence. What is it actually trying to convey?Assuming it is saying the first GTS in the superframe shall be allocated tothe GTS whose destination is a power-save DEV, what if there are multiple GTSs with power-save-DEVs as GTSs? how does this "shall issue" first GTSbe implemented? As long as the PNC gives consideration to such sensitivities in the network it should be good enough. If a PNC is not sensitive about such things, it is going to fail in the market anyway. Why unnecessarily restrict the implementation. AND in addition,****THIS SENTENCE GOES AGAINST THE RESOLUTION PROVIDED FOR COMMENT #540 in LB12which is at pp-170, ln50:52****

SuggestedRemedy:
Remove the sentence starting from "The PNC shall issue the first GTS ..."


Comment:
This sentence does not belong here where the isoch streams are beingdescribed.

SuggestedRemedy:
In the sentence starting from "The PNC shall also send a ...", insert "or modified" after "DEV of any   newly allocated"Then move the entire sentence to clause  8.4.4.1, pp-171, ln16 immediately following "channel time request command, 7.5.5.1"


Comment:
This entire para is redundant since the same has already been said on thesame page ln14:17


Comment:
The inclusion of "all the other channel ..." on ln 12:13 makes the points "Target DEVID ..." on ln-8 and "Stream index field ..." on ln 10redundant

SuggestedRemedy:
remove the point starting from "Target DEVID ..." on ln-8 remove the point starting from "Stream index field ..." on ln 10


Comment:
The termination can be greatly simplified and the burden on PNC removedby using  channel response command for both source and target DEV. Sincestream index is present in the command, this serves the purpose and avoidsthe PNC having to repeat broadcast the null CTA in the beacon for the target. In addition the direct frame transaction is a one time affair andis easy to deal with.

SuggestedRemedy:
Remove the amendments and use "channel time response command" tocovey the termination of stream for both target and source, as applicable.

Response:
REJECT. The use of null CTAs allows DEVs that were listening to a BC or MC stream to know that it is no longer allocated.  This can't be done with a directed frame.  In addition, the standard is using directed frames to communicate with the source and IEs in the beacon to communicate with destinations.  The TG discussed this issue at length in Vancouver, on conference calls, the ad-hoc meeting in Schaumburg and in Monterrey.  Both methods, directed frames and null-CTAs were considered in the discussions and it was felt that null-CTAs would better serve the purposes of the standard.


Comment:
The DEVs must be required to "be awake to listen" than "required to listen"the latter gives the impression that they HAVE to somehow receive it asit is said in clause-5

SuggestedRemedy:
change "DEVs are required to listen to it" to "DEVs are required to be awaketo listen to it"


Comment:
If "fewer" number of retx are allowed, why not larger number than aMacRetransmissionLimit. Let the DEV decide how many times a frame decides to be retransmitted based on the stream/data type and life time.

SuggestedRemedy:
change "fewer" to "fewer/larger" and "short" or "different"

Response:
ACCEPT IN PRINCIPLE. Change "Any frame may beattempted at most aMaxRetransmissionLimit number of times before the transmitting DEV gives up on that frame and discards it. If a fragment of an MSDU fails retransmission up to the retry limit, the source DEV shall discard all MPDUs of that MSDU. However, a DEV might choose to attempt retransmission of an MPDU a fewer number of times as some data streams have a short life time." to be "A DEV determines the number of times a frame is retried before the DEV gives up on that frame and discards it. If the DEV gives up on a fragment of an MSDU, the DEV shall discard all MPDUs of that MSDU."


Comment:
Why SourceID? Since Stream index is unique in the network and is independentof source or dest-ID, source ID is not needed. However PNID is needed.

SuggestedRemedy:
Change "Source ID" to "PNID" in this sentence


SuggestedRemedy:
change "the target DEV should accept" to "The taregt DEV may accept"


SuggestedRemedy:
change "A DEV should not report" to "A DEV shall not report"

Response:
ACCEPT IN PRINCIPLE. Change the sentence to 'A DEV shall not report
overlapping piconets if it determines that the beacons were received from a child or 802.15.3 neighbor piconet that is associated with the DEVs current piconet.'


Comment:
The number of beacons transmitted should correspond to less than ATPthat PNC has accepted from any member DEV

SuggestedRemedy:
change "aMinChannelScan" to "aMinChannelScan and less than ATP of all current member DEVs in the piconet"


Comment:
use of "shall not be" is redundantly stressing the non-mandatory partTHIS IS PRESENT AT SEVERAL PLACES IN THE DRAFT

SuggestedRemedy:
change "shall not be required to" to "may"


Comment:
The new definitions of AWAKE and SLEEP states are vague and leave lot ofroom of contradicting interpretations.

SuggestedRemedy:
Change two sentences starting from "Being in the AWAKE state...." to the following:"AWAKE state defined as the state of the DEV where it is either transmittingor receiving. SLEEP state is defined as the state in which the DEV isneither transmitting nor receiving."


Comment:
PSPS mode is very similar to DTIMs in 802.11 but only worse. There is noway that the PNC can stop a DEV from entering PSPS mode and hence sleepstate. Hence if there is BC/MC traffic that is pending transmission anda rogue DEV insists on going to SLEEP state, the BC/MC traffic gets heldcausing issues at other DEVs.If the thinking is that the ACK from PNC can be avoided, it causes other problems , like(a) Forcing PNC to take that decision of allowing DEV to enterPSPS mode within SIFS duration (Actually only the MAC part of it) (b) avoids the implementations to implement ACK transmission partindependent of higher MAC functionality and (C) unnecessary retransmissions of PS mode command at the DEVTo avoid this PSPS mode needs a PS-mode-response frame from PNC beforewhich the DEV is not allowed to enter PSPS mode. However since there areother drawbacks as highlighted in later comments, this is not anacceptable scheme

SuggestedRemedy:
Remove PSPS mode update from the draft and retain the APS mode as in D10However the PS status bit map is useful and hence retain that as applicableto APS instead of PSPS mode. This includes retaining APS related commandsin clause 7 in D10


Comment:
I am not sure how this new scheme (PSPS) can assume that all DEVs in thepiconet have the same power save requirements and hence can use thesame wake-beacon-interval. 802.15.3 caters for variety of devices andapplications and hence there is a need for different such intervalsdepending on the kind of application served by the DEV. Atleast in802.11 the DEVs are not mandated to be awake at all DTIMs and hencethey can be sure that there will not be any directed frame that theyare going to miss when they are asleep (doze mode). In APS mode this wasenhnaced for better efficiency by allowing the DEV to request thesleep duration it wishes and the PNC permitting upto that duration.In PSPS mode that advantage has disappeared and hence this forces anupper limit on power saving for all DEVs in a given 802.15.3 piconet.Worst is it is same across the board for all DEVs in the piconet. Toget around this issue, PSPS mode needs to allow DEVs to requestintervals in multiples of wake-beacon-intervals. However given thequantization of the time durations involved and other drawbacks of thescheme, it is not recommended to retain this scheme


Comment:
PS status bit map has an issue and that is, let's say DEV-A and DEV-B aremembers of the same piconet managed by a PNC. If DEV-A sees the PS-status-bit corresponding to DEV-B as set in the beacon from PNC (meaning DEV-Bis in power save mode), but in the same superframe receives a frame (directed or not) from DEV-B, can DEV-A assume that the DEV-B is in AWAKEstate for that superframe? I think that should be allowed. it helps certainBC/MC traffic transactions

SuggestedRemedy:
1.If a DEV in in PSPS (APS) mode in a superframe, but transmits a frame theDEV shall consider itself in AWAKE state and hence may enter SLEEPstate only after another succesful transaction of power-save-commands(s)with PNC.AND2. The DEV shall enter SLEEP state only at the start of superframefollowing the succesful transaction of power-save-commands(s) with PNC.


SuggestedRemedy:
insert "without leaving any of the SPS sets that it is presentlyregistered in." after "amount and type fo data traffic"


SuggestedRemedy:
change it to mean superframe instead of beacon.


Comment:
CS (coordinator selection) is in abbreviations but does not show up in the text


Comment:
FC (frame control) is found in abbreviations but not in document text


Comment:
SA (source address) shows in abbrev but not in text


Comment:
missing space "beattempted" should change to "be attempted"


Comment:
Many of the MSCs have line widths that do not show up well when printed. Suggest editing as a low level priority to increase line width.Figs. 89, 90, 91, 92, 96, 97, 98, 107, 108, 109, 111, 112, 114, 115, 118, 121, 123, 129, 136. Also, fig 137, 138, and 139 needs work (shading etc. may not work well)


Comment:
Number of reserved stream index field shows as three in the list and two in the text.

SuggestedRemedy:
change the text to read as "three reserved values"


Comment:
The convention for noting the header parameters is not consistent with other MSCs in this document. Also, del-ack-req is not consistent with the rest of the document. Convert this figure to use the convention e.g., Dly-ACK request=1ACK policy=Dly-ACKetc.For the content of the Dly-ACK frame, use terms as found in text or provide a key.


Comment:
extra "for" in sentence. Also "-" in channel time that is not consistent with rest of text.

SuggestedRemedy:
change to "... that to request channel time ..."


Comment:
Perhaps the title of figure 9 should change to be parameter field instead of information element.


Comment:
The PNC response field format seems to be reversed from the convention

SuggestedRemedy:
suggest changing figure 11 to have CTRRespTime to the right and Reserved to the left.


Comment:
The text on use of private GTS should be changed as it seems to be reduntant. The "For example, ... should be for child. the second sentence should be named as neighbor and given the xref to 8.2.5


Comment:
The Number of CTRBs is probably unnecessary now that we are fragmenting the handover information command.

SuggestedRemedy:
delete the field from the PNC handover request command.


Comment:
It appears from the MSC that the MLME-PNC-HANDOVER.rsp is sent when the last of the information has been transferred to the new PNC, which is not correct.

SuggestedRemedy:
Add text to subclause 8.2.3 that says "In the MSC, the MLME-PNC-HANDOVER.rsp is sent when the DME is ready for the handover and is not tied to the arrival of the PNC handover information commands or SPS inquiry response commands."  Move the arrow for it so that it happens in the middle of the messaging.


Comment:
The draft does not say what the smallest fragment may be.

SuggestedRemedy:
Add a lower limit, say 127 octets, below which a MAC frame will not be fragmented (except for the last fragment).  This, combined with a smaller max transfer unit size, may allow the standard to reduce the maximum number of fragments allowed.


Comment:
The terms GTS and CTA are used interchangeably to mean the same thing.

SuggestedRemedy:
Change all occurances of GTS to be CTA.  Change MTS to be MCTA.


Comment:
The OID and OID Length are included in the command, but not the MLME.

SuggestedRemedy:
These values should be added to the list of semantics for the MLME-AUTHENTICATE.request.


Comment:
[Assoc] The term AssocID leads the reader to believe that it's the ID you get when you are associated, i.e. the DEVID. The use in the text means that it's the UNASSIGNED ID, i.e. 0xFE./KO

SuggestedRemedy:
Replace all occurances of AssocID with UnassignedID.

Response:
ACCEPT IN PRINCIPLE. Change to UnassocID and change the acronym list to be UnassocID - unassociated ID.


Comment:
CID 365 from LB17 is still not fully resolved.  This item raises numerous questions regarding protocol issues that the SPS power management scheme has yet to address.  Consequently, the issues it raised during LB17 are still valid for LB19.  Also this CID provides additional reasons for why SPS should be optional at best.CID 365 "KO> a) A DEV can join several SPS but how does it know when to be awake? b) How do you send to broadcast of DEVs are in different SPS? c) What are you supposed to do with "suspended CTA?"? d) How do transmitters know when an intended receiver is awake? e) How does it fit  with ATP? With pseudostat? with subrate?  f) How is PNC supposed to calculate available CTA when DEvs of different SPS may end up with all their CTA needs in the same superframe at some intervals? "

SuggestedRemedy:
1) Ideally remove all the SPS Power managment scheme Clauses( 8.13.2, 7.5.7.2,3,4,and 5, 6.3.12.1,2,3,4) ; 2) Have the authors of the SPS Pwr Mgt scheme address the questions raised in CID 365;3) just make the SPS Pwr Mgt scheme optional for all DEVs.


Comment:
CID 150 from LB17 is still not fully resolved.   There has been no resolution or text provided regarding the bit ordering of data sent over the RF media.

SuggestedRemedy:
Please resolve during the Monterey meeting.


Comment:
CID 365 from LB17 is still not fully resolved.  This item raises numerous questions regarding protocol issues that the SPS power management scheme has yet to address.  Consequently, the issues it raised during LB17 are still valid for LB19.  Also this CID provides additional reasons for why SPS should be optional at best.CID 365 "KO>a) A DEV can join several SPS but how does it know when to be awake?b) How do you send to broadcast of DEVs are in different SPS?c) What are you supposed to do with "suspended CTA?"?d) How do transmitters know when an intended receiver is awake?e) How does it fit  with ATP? With pseudostat? with subrate? f) How is PNC supposed to calculate available CTA when DEvs of different SPS may end up with all their CTA needs in the same superframe at some intervals? "

SuggestedRemedy:
1) Ideally remove all the SPS Power managment scheme Clauses( 8.13.2, 7.5.7.2,3,4,and 5, 6.3.12.1,2,3,4) ; 2) Have the authors of the SPS Pwr Mgt scheme address the questions raised in CID 365;


Comment:
Again, the footnote "WPAN is a trademark owned by the IEEE" is incorrect.


Comment:
No reference for ANSI X3.66 which is referenced in 7.2.7.2


Comment:
The normative reference to the EESS #1 draft standard needs to be included in this clause.

SuggestedRemedy:
The latest version of the draft should be referenced, which is the following: "Efficient Embedded Security Standard (EESS) #1: Implementation Aspects of NTRUEncrypt and NTRUSign, Consortium for Efficient Embedded Security, Draft Version 5, September 6, 2002" with the following footnote "EESS standards are available from the Consortium for Efficient Embedded Security (http://www.ceesstandards.org)."


Comment:
Some of acronyms are no longer used in the standard

Response:
ACCEPT IN PRINCIPLE. Remove DEK and KEK. CBC and CBC-MAC are used in clause 10 and Annex B.


SuggestedRemedy:
MIC - message integrity code and  SFC - secure frame counter.


Comment:
Use dependent in stead of subsidary piconetReference the defined shutdown procedures/KO

SuggestedRemedy:
change text to:In the case of dependent piconets, the parent PNC is able to end a child piconet by using the shutdown procedure in 8.2.6.4 and a neighbor piconet by using the shutdown procedure in 8.2.6.5.


Comment:
Ther are no asynchronous connections (by definition!)/KO

SuggestedRemedy:
delete the word "connections" last in the last sentence.


SuggestedRemedy:
If the parent piconet ends operation, the parent PNC will indicate in the PNC shutdown IE,7.4.5,a dependent piconet that will be able to continue to operate.


Comment:
Table 6 includes "PiconetMaxTXPower" and indicates it is defined in Table 5, but it is not in Table 5

SuggestedRemedy:
Change entries to read: "As definedin 7.3.1", "As defined in 7.3.1", and "Maximum TX power allowed in the piconet."


Comment:
Table 8, CapabilityInformation is shown as defined in 7.4.11. 7.4.11 defines the Capability Information Element which includes "Capability Field", "MaxAssignedCTAs", and "MaxProcessedCTAs". 7.4.11 also defines the breakdown of "Capability Field". How is the reader supposed to know what "CapabilityInformation" contains? Does it contain just the "Capability Field"? Does it also contain "MaxAssignedCTAs" and "MaxProcessedCTAs"? If yes, how does the reader know that the "ID Element" and "Length" are not included? This might be a general problem. That is, parameter defs pointing to an information element definition, when it is only the data portion of the IE which is required in the parameter.

SuggestedRemedy:
Split this parameter into "CapabilityField," "MaxAssignedCTAs", and "MaxProcessedCTAs" with xrefs to 7.4.11


Comment:
PNCResponse is not longer sent in the association command.

SuggestedRemedy:
Delete it from the table and the primitive parameters in 6.3.5.3 and 6.3.5.4.


Comment:
The piconet description of Figure 78 is not even close to the piconet description for the  MLME-REMOTE-SCAN.rsp/cnf. Lots of data is missing. Otherwise, if this is all the data that gets returned for a remote scan, then the definition of Piconet Description for the MLME-REMOTE-SCAN primitives needs to be changed.

SuggestedRemedy:
Delete from table 21 ChannelList and ChannelScanDuration.

Response:
ACCEPT IN PRINCIPLE. Add a table to 6.3.18 called remote piconet description, as shown in 02/392r2. In table 21, change PiconetDescription to be RemotePiconetDescription with cross references to the new table.


Comment:
The PSMode valid range needs to add one.

SuggestedRemedy:
Add SPS_AND_PSPS to the valid range to match the frame formats and functional description.


Comment:
"Status" should be "ResultCode" to match the usage in the rest of this clause.

SuggestedRemedy:
Change "Status" to "ResultCode" here and in 6.2.4, p. 26, line 30.


Comment:
There is no discussion of what is meant by static or dynamic.

SuggestedRemedy:
Either add a defintion, i.e. "Static means that the parameter is an unchangeable characteristic of the DEV while dynamic means that it is possible for the parameter to change while the DEV is operating." or simply delete the column.


SuggestedRemedy:
Add "0x03=SPS and PSPS" and renumber these to match the numbers used in the clause 7 frame format.  Also change in lines 20-24


Comment:
The description of MACPIB_PowerManagementSupported seems incomplete.

SuggestedRemedy:
Change it to read "Indicates if the DEV is capable of supporting one of the power management modes as a DEV."


Comment:
Some of the PIB names are repeated, in particular MACPIB_DEVAddress is used twice as is MACPIB_DEVID.  Also, there is no way to communicate that a bad PIB name was used.

SuggestedRemedy:
Rename the duplicate entries.  Add an error code to xxx-set and xxx-get that says "INVALID_PIB_ATTRIBUTE_NAME"


Comment:
scanning is no longer a part of MLME-START, however, NumberOfChannels and ChannelRatingList are still included in MLME-START.cnf. Also, section 8.2.1 contains text that implies that scan is still part of MLME-START.req.

SuggestedRemedy:
Delete NumberOfChannels and ChannelRatingList and delete references to MLME-START.xxx from 8.2.1.


SuggestedRemedy:
Add "DENIED" for when the PNC denies association.


Comment:
The CapabilityInformation field has been replaced by the PiconetServicesInquiry bit.

SuggestedRemedy:
Change the entry in the table to match the new name and definition.  Also, add this parameter to the .indication command.

Response:
ACCEPT IN PRINCIPLE.  Insert the PiconetServicesInquiry field (values: enumeration; REQUEST, NOREQUEST; Requests that the PNC sends the services information about the piconet as described in {xref AssociationRequest}) into the table. The capability field is still used.


Comment:
The PNCResponse parameter has been removed from association and put in the beacon.

SuggestedRemedy:
Delete the entry here and in the .response and .confirm.


Comment:
The definition of DEVInfoSet is incorrect in this instance.

SuggestedRemedy:
For handover, it is "A set of DEV information elements for all of the DEVs currently associated in the piconet."


Comment:
The MSC of figure 122 indicates that a probe command containing both requested data and a request for data results in both a MLME-PROBE.cfm and MLME-PROBE.ind at the destination devid. This implies that the requested data is given to the target devs MLME in the MLME-PROBE.cfm, and that the data request is given to the target devs MLME in the MLME-PROBE.ind. This means the that InfoElementMap is not needed in MLME-PROBE.cfm and that InfoElementList is not needed in MLME-PROBE.ind. Also, because an MLME-PROBE.rsp can also be a request for data, a ProbeTimeout value should be included with this primitive.

SuggestedRemedy:
Suggested MLME primitives to support figure 122 as shown:mlme_probe_req(DEVID_t, /*TrgtId*/ElementsRequested_t, /*InfoElementMap*/ElementsProvided_t  /*InfoElementList */Dur_t /*ProbeTimeout*/),mlme_probe_ind(DEVID_t, /*OrigId*/ElementsRequested_t, /*InfoElementMap*/),mlme_probe_rsp(DEVID_t, /*OrigId*/ElementsRequested_t, /*InfoElementMap*/ElementsProvided_t, /*InfoElementList*/Dur_t /*ProbeTimeout*//*TBD*/),mlme_probe_cnf(DEVID_t, /*TrgtId*/ElementsProvided_t, /*InfoElementList*/ResultCode_t);

Response:
ACCEPT IN PRINCIPLE.  Add an MLME-PROBE.confirm to just before the first MLME-PROBE.ind sent to DEV-2.  Change the probe primitve parameters to match the following (same definitions).

mlme_probe_req
(TrgtId
InfoElementMap
InfoElementList
ProbeTimeout),

mlme_probe_ind
(OrigId
InfoElementMap)

mlme_probe_rsp
(OrigId
 InfoElementMap
 InfoElementList
 ProbeTimeout
),

mlme_probe_cnf
(TrgtId
InfoElementList
ResultCode);


Comment:
The title of this clause is out of synch with the nomenclature used in clauses 6.3.5.3, 6.3.5.4, and Table 8 and the text submitted in 02/273r17.Also make sure that the caption for Figure 42 is synch with the indicated clauses.

SuggestedRemedy:
Please reconcile the clause 7.4.16 title with the parameter names used in 6.3.5.3,4 and Table 8.


Comment:
[PNID] PNID must be checked to filter frames from the own piconet/KO

SuggestedRemedy:
Add table entry:Header field: PNIDSetting on transmission: PNID of piconetInterpretation on reception: Decoded


Comment:
[MaxCTA] Remove the MaxProcessedCTAs and MaxAssignedCTAs from the Association request command.  These two fields are unnecessary. It is unclear to me why these parameters are needed at all.


Comment:
The fieldname in Figure 47 is out of synch with the nomenclature used in clauses 6.3.5.3, 6.3.5.4, and Table 8 and the text submitted in 02/273r17.

SuggestedRemedy:
Please reconcile the field name in Figure 47 with the parameter names used in 6.3.5.3,4 and Table 8. Also reconcile the text on p133, L4 with the aforementioned clauses and Table.


Comment:
[PNID] PNID must be checked to filter frames from the own piconetSECID irrelevant on Imm-ACK frame./KO

SuggestedRemedy:
Add table entry:Header field: PNIDSetting on transmission: PNID of piconetInterpretation on reception: DecodedChange SEC Interpretation on reception to: May be decoded


Comment:
[PNID] PNID must be checked to filter frames from the own piconetSECID irrelevant on Dly-ACK frame./KO


Comment:
[MaxCTA] Remove the MaxProcessedCTAs and MaxAssignedCTAs from the PNC Information command.  These two fields are unnecessary.


Comment:
[PNID] PNID must be checked to filter frames from the own piconetStream index is 0xFD in an MTS/KO

SuggestedRemedy:
Add table entry:Header field: PNIDSetting on transmission: PNID of piconetInterpretation on reception: DecodedChange Stream Index, setting on transmission to:0x00 or 0xFD


Comment:
[CTM/CTAStat] The CTA status command lacks any description of what it is used for or any reference to another clause where its functional use is described.  Either delete this command from the draft or provide text describing the purpose of this command as well as references to where it is used. If the above changes are made, then also make these changes:1) change the Start beacon number field length from 4 octets to 6.2) change  the command length from 5 to 10.


Comment:
Make these changes to the fields of the Channel status response command:1) Change Measurement window size -> Sampling window size.  The reason is clause 6.3.17.3 and 4 have that as their parameter. 2)Tx frames count -> Tx frame count, again consistency with 6.3.17.3 and 4.3) Rx frames count -> Rx frame count, again consistency with 6.3.17.3 and 4.4) Rx error frames count -> Rx frame error count,again consistency with 6.3.17.3 and 4. 5) Rx frames loss count -> Rx frame loss count, again consistency with 6.3.17.3 and 4.Also make the appropriate changes in the text descriptions of each of the indicated fields.


Comment:
Field "Num max frame size" is not consistent with text in 8.8.3/KO


Comment:
Change the Piconet description sets field <to> Piconet descriptions set, since it is a set comprised of multiple piconet descriptions.


Comment:
[ACK/Dly] The formatting of a dly-ACK needs to easy for the detination to do andpredictable for the source./KO

SuggestedRemedy:
Add text before "The Dly-ACK frame shall be formatted..."The MPDU-ID blocks shall be sent in the same order as the data frameswere received.


Comment:
[Scan/Remote] The piconet description field format is incorrect. It is completely out of synch with the the Piconet description defined in Table 5 of Clause 6.3.2.Replace Figure 78 with this field format:PNID, ScannedFrameType,ChannelIndex,  Piconet synchronization parameters field as displayed in Fig. 9 pg 110,PiconetType, followed by these IEs BSID-IE, ParentBSID-IE.In addition remove any text that is no longer needed and add any text that is missing.


Comment:
[Assoc] The DEVAssociations field only needs to contain DEV address,Capability, DEVID and association status/KO


Comment:
[MaxCTA] MaxProcessedCTAs and MaxAssigned CTAs are only needed for handover. It ismuch better to put them in the DEV info set./KO

SuggestedRemedy:
Delete MaxProcessedCTAs and MaxAssigned CTAs from Figure 28Move corresponding text to 7.5.1.1, since they are first used in the association request.


Comment:
[DepPN/Shutdown] The shutdown element needs a field indicating which of several dependent PNC that may continue operation (ref 02/289r1 page 3, LB17 CID 986,988, 989)/KO

SuggestedRemedy:
In figure 29 and text add:1 octetRemaining DEVID


SuggestedRemedy:
Line 33: change "superframe timing" to "superframe duration" and change "synchroniziation IE" <to> "synchronization parameters field"Line 38: change "superframe timing" to "superframe duration"Line 39: change "beacon duration field" to "superframe timing field"Line 32, 37, 47, 51: "0" and "zero" used. Pick one!


Comment:
[ChnlChng] The change of channels takes effect just before the first beacon after the countdown. The superframe after countdown=0 is still on the old channel.This is necessary to allow uninterrupted data exchange./KO

SuggestedRemedy:
Change text to:If the change type is CHANNEL, the new channel field is set to the channel where the first beacon after the beacon with the countdown field equal to 0/zero will be sent. Otherwise this field shall be ignored upon reception.


Comment:
[IE/DEVAddr] DEV Adress is no longer needed as an element since the beacon contains the BSID and not the MAC address of parent and dependents. It is not used anywhere in the standard./KO


Comment:
[MaxCTA] MaxProcessedCTAs and MaxAssigned CTAs are only needed for handover. It ismuch better to put them in the DEV info set.Elements included separately in association request, 7.5.1.1 andPNC information , 7.5.4.2/KO

SuggestedRemedy:
Delete MaxProcessedCTAs and MaxAssigned CTAs from Figure 35delete corresponding text on page 126, line 32-34


Comment:
[IE/Capabilities] For handover, it is necessary to know if a DEV supports any power save modes./KO

SuggestedRemedy:
Add to Figure 36 - capability field:b10: SPS Capableb11: PSPS CapableAdd text:The SPS Capable bit shall be set to 1 if the DEV is capable of administraring at least one SPS set as a PNC. Othwerwise this bit shall be set to 0.The PSPS Capable bit shall be set to 1 if the DEV as PNC is capable of generating system wake beacons and administrating PSPS requests. Otherwise this bit shall be set to 0.


Comment:
[ACK] For all request commands that results in a response command being sent, it is the implementers choice if he/she wants an ACK of the request or justwaits for the response. The standard doesn't need to require the useof Imm-ACK, even if that would probably be the most common implementation./KO

SuggestedRemedy:
Change text "The ACK policy field shall be set..." to "The ACK policy field may be set..."

Response:
REJECT. The ACK serves the purpose of telling the transmit state machine if it was successful in getting the frame.  The response is used to close the process at the DME level.


Comment:
[PNCHndOvr] It is crucial for handover that the old PNC knows if the new PNC canhandle all associations and CTRB it manages. Therefore a DEV shallpass this info during association (ref 02/276r6 page 21, LB 17 CID 206,422)In addition, Powerlevel needs to be passed.Last, MaxProcessedCTA and MaxAssignedCTA should be moved here from 7.4.4 and 7.4.11./KO

SuggestedRemedy:
Add to Figure 45:1 octet: MaxAssociations1 octet: MaxCTRB1 octet: MaxTXPowerLevelMove text for MaxProcessedCTA and MaxAssignedCTA from 7.4.4 to this clause.Add text:The MaxAssociations field describes how many associated DEVs this DEV can manage if it is PNC Capable and becomes the PNC. Non PNC Capable DEVs shall set this value to 0.The MaxCTRB field describes how many CTRB this DEV can manage if it is PNC Capable and becomes the PNC. Non PNC Capable DEVs shall set this value to 0.The MaxTXPowerLevel describes the maximum transmit power of this DEV as defined in {xref TxPowerLevel}


Comment:
The PNC shutdown information element referenced by clause 8.2.6.1 does not contain a field for the child DEVID.  I'm going to assume that the text is correct and that Figure 29 in 7.4.5 is incorrect. Consequently, add the DEVID field to the PNC shutdown IE in 7.4.5.  Are there any other fields that need to be added?


SuggestedRemedy:
Change from "8-255 -> Reserved" to "9-255 -> Reserved"


Comment:
[SEC/Auth] The error code "failure" seems irrelevant when there are real error codes/KO

SuggestedRemedy:
Delete "1 -> failure"Failure is not an option!              [Apollo 13]

Response:
ACCEPT IN PRINCIPLE. Change "Failure" to "Challenge verification failure".


Response:
ACCEPT IN PRINCIPLE. Change "failure" on line 45 to "ChallengeResponse generation failure".


Comment:
[PNCHndOvr] Since we now also hand over SPS sets, we need to add a numberof SPS set field to the PNC handover request./KO

SuggestedRemedy:
See frame and text in 02276r7P802-15_TG3-commentsD11_KO.doc, Resolution [03]


Comment:
[PNCHndOvr] Text missing from 02/276r6 resolution [03]./KO

SuggestedRemedy:
Add text:This command is sent by the new PNC after all information blocks indicated with the PNC handover request command has been received and the new PNC is ready to take over PNC responsibility.


Comment:
[PNCHndOvr] SPS info is passed (and is supposed to fit in one octet!) in steadof SPS index?/KO

SuggestedRemedy:
Change Figure 64:Change "SPS Info" to "SPS Index".Change text on Page 140, line 8:The SPS Index is the number of the SPS Set in which the DEV is participating, if any. If the DEV does not participate in any SPSSet, this value shall be set to 0.


Comment:
The PiconetParmChangeTimeout is not necessary.

SuggestedRemedy:
Delete the timer from the figure or add the timeout value to the appropriate MLME.  This goes for figure 128 as well.


Comment:
The Priority parameter disappeared, but it is still in the frame.

SuggestedRemedy:
Add the priority parameter to this table and to the .request primitive.

Response:
ACCEPT IN PRINCIPLE. Add the priority parameter with definition in the table as indicated in CID 160.


Comment:
There does not appear to be a way to generate the ILLEGAL_ACK_POLICY ResultCode for the MLME-xxx-STREAM primitives.

SuggestedRemedy:
Add text to the primitives to indicate when this ResultCode is sent or delete the error code here.


Comment:
The PNC doesn't necessarily know who disassociated


Comment:
The PiconetSecurity OID should only be the preferred OID for the piconet. It should be allowed for the PNC to authenticate different devices in the piconet with different security sub-suites since all of the operations are the same after the authentication process has been completed.

SuggestedRemedy:
Change text to say “Specifies the object identifier of the security suite preferred for use by the PNC.”


Comment:
The PublicKeyObjectLength is no longer used.

SuggestedRemedy:
Remove PublicKeyObjectLength from 6.3.7.1 and 6.3.7.2.

Response:
REJECT. The PublicKeyObjectLength for ECC and RSA certificates can vary. Table 10 on page 43 incorrectly states that PublicKeyObjectLength is defined by the security suite. Change "Defined by the security suite, Clause 10." to "May be constant or variable as defined by the security suite, Clause 10."


Comment:
The OID and OIDLength are no longer included in the challenge commands.

SuggestedRemedy:
Remove OID and OIDLength from 6.3.7.5 and 6.3.7.6.

Response:
ACCEPT IN PRINCIPLE. Remove OID and OIDLength from 6.3.7.5 and 6.3.7.6. And update Figure 146 in 9.8.3 to reflect this change.


Comment:
It is somewhat redundant to have both a challenge response and a challenge in the challenge response command since they are both used in the public-key operations.

SuggestedRemedy:
It may make sense conceptually to combine the Challenge and the ChallengeResponse into one value, since together they are used to continue the public-key challenge. It may be fine the way it is.


Comment:
The integrity code should be computed by the MLME, not the DME. The IntegrityCode should be removed from the MLME-REQUEST-KEY.request.


Comment:
The MLME encrypts the key itself, not the seed and the integrity code is computed by the MLME as well.

SuggestedRemedy:
The EncryptedSeed should be changed to Key and the IntegrityCode should be removed from the MLME-REQUEST-KEY.response.

Response:
ACCEPT IN PRINCIPLE. The EncryptedSeed should be changed to Key and the IntegrityCode should be removed from the MLME-REQUEST-KEY.response. Change "with an encrypted version of therequested seed" to "with the requested key" in line 4.


Comment:
The MLME decrypts the key upon receipt, so it should pass up the decrypted key, not the encrypted seed.

SuggestedRemedy:
The EncryptedSeed should be changed to Key in the MLME-REQUEST-KEY.confirm.

Response:
ACCEPT IN PRINCIPLE. See resolution of CID 20.


SuggestedRemedy:
The EncryptedSeed should be changed to Key and the IntegrityCode should be removed from the MLME-DISTRIBUTE-KEY.request.


SuggestedRemedy:
The EncryptedSeed should be changed to Key in the MLME-DISTRIBUTE-KEY.indication.


Comment:
The MLME computes the integrity code upon receipt, but the DME need not ever see it.

SuggestedRemedy:
The IntegrityCode should be removed from the MLME-DISTRIBUTE-KEY.response.


Comment:
There is no good mechanism for the old PNC to transfer trust information about devices in the piconet to the new PNC and other DEVs during PNC handover. For the mode 2 security sub-suites, it may be useful to transmit the identifier and/or certificate of the CA along with the device address so that the new PNC knows how to authenticate each DEV and vice-versa. For the mode 1 security sub-suites, it may be useful to transmit the hash of the public key of a device or the public key itself along with the device address so that the new PNC knows how to authenticate each DEV and vice-versa.

SuggestedRemedy:
A new primitive should be added to allow the PNC to transmit ACL information to the new PNC and to the other DEVs in the piconet. This would be useful for all security suites.


Comment:
The security suite and public-key verification information have been removed from the MAC PIB. This implies that there is no accessible information that the MLME can use to perform verification on the public key. In particular, the CA certificate or hash of the public key are not available. In clause 10, each security sub-suite specifies that the ACL indicates which public-keys shall be accepted and which shall be rejected.

SuggestedRemedy:
Add public-key verification information back into the ACL and specify in each security suite how that ACL information is to be used. If there are operations to be performed by the DME to verify the public key, those should be mentioned in the security suites as well.  This applies to 6.5.6 as well.


Comment:
[Start] Remove NumberOfChannels and ChannelRatingList entries from the table. Neither of these parameters given the function description of the start functionality is valid since the scanning process has been removed from the start function except to verify that the channel the PNC is trying to start a piconet within is still clear.

SuggestedRemedy:
Please make the requested technical change.


Comment:
[IE/Capabilities] Add parameters for capabilities etc./KO


Comment:
[Start] Remove all the parameters listed under the MLME-START.confirm primitive except the ResultCode.  The start functionality described in clause 8.2.2 no longer includes a scan process except to verify that the chosen channel is still clear.


Comment:
[Start] Pass back only parameters that can be changed by MLME or PNC/KO

SuggestedRemedy:
delete all parameters from MLME-START.confirm except(ResultCode)


Comment:
[PNServices] Please insert this parameter (PiconetServicesInquiry) into the parameter list after the  AssociationTimeoutPeriod and before the AssocTimeout parm.. Clause 7.5.1.1 implies that it needs to be present.

Response:
ACCEPT IN PRINCIPLE. Insert the PiconetServicesInquiry field (values: enumeration; REQUEST, NOREQUEST; Requests that the PNC sends the services information about the piconet as described in {xref AssociationRequest}) into the table. The capability field is still used.


Comment:
[DepPN] MLME-START-DEPENDENT.request must have thestream index of the private GTS/KO


Comment:
[PNServices] Insert the PiconetServicesInquiry parm just below the AssociationTimeoutPeriod parameter.Also use this format:Name:PiconetServicesInquiry; Type:Boolean; ValidRange: True/False; Description As defined in {xref: 7.5.1.1}


Comment:
[Start]Pass back only parameters that can be changed by MLME or PNC/KO

SuggestedRemedy:
delete all parameters from MLME-START-DEPENDENT.confirm except(ResultCode)


Comment:
[PNCResponse] Please delete PNCResponse parm from the table since it is no longer apart of the association response command (7.5.1.2)


Comment:
[IE/Capabilities] Add parameters for capabilities etc.All these params passed to PNC during associations. Some needed for future handover (LB17 CID 206,422)./KO


Comment:
[Assoc] Change this sentence fragment <from> "If association is successful, the DEVID for the DEV." <to> " If association is successful, the PNC assigned ID for the DEV."


Comment:
[DepPN/Neighbor] Creation of neighbor piconet can be refused by parent PNC/KO


Comment:
[Start] Delete all the parameters, except the ResultCode, from the parm list of the primitive MLME-START-DEPENDENT.confirm, since the start function does not perform a general multi-channel scan anymore.


Comment:
Delete this sentence fragment: "...,piconet is already established, ..." Reason: it's redundant.


Comment:
[PNCResponse] PNCResponse no longer passed, it's in the beacon./KO


Comment:
[Start] Add this resultcode to the valid range portion of the table: ALREADY_STARTED


Comment:
PNCResponse no longer passed, it's in the beacon./KO


Comment:
[Start] Change these sentence fragments 1)  <from> "If another piconet is already established,..." <to> "If the piconet is already established,..."2) <from> If all of the channels for the PHY are either occupied by other 802.15.3 piconets or have unacceptable interference, ..." <to> "If all the channels for the PHY are occupied by other 802.15.3 piconets, ..." <and to> " If all the channels have unacceptable interference, then the ResultCode shall be set to "CHANNEL-NOISY".


Comment:
[DisAssoc] PNC DME may disassociate several DEVs. Therefore DEVID needs to be passed back. (LB17 CID 54)/KO

SuggestedRemedy:
[DisAssoc] Add parameter to MLME-DISASSOCIATE.confirm:DEVID


Comment:
[PNServices] Add the PiconetServicesInquiry parm to the end of the MLME-ASSOCIATE.indication primitive parm list, since it is a required parm in the association request command defined in clause {xref: 7.5.1.1}


Comment:
[PNCHndOvr] Definition of HandoverTimeout wrong/KO

SuggestedRemedy:
Change Valid Range to: 0-65535Change Definition to:Maximum time in milliseconds for piconet information transfer.


Comment:
[PNCResponse] Delete the PNCResponse parm from the MLME-ASSOCIATE.response primitive since the parm is not passed back to the requestor via the association response command.


Comment:
[PNCHndOvr] Missing primitive to pass up the DEVInfoSet to the new PNC during handover./KO

SuggestedRemedy:
New primitive MLME-PNC-HANDOVER-INFO.indicationSee Resolution [03] in 02276r7P802-15_TG3-commentsD11_KO.doc


Comment:
[PNCResponse] Delete the PNCResponse parm from the MLME-ASSOCIATE.confirm primitive since the parm is not passed back to the requestor via the association response command.


Comment:
[CTM/Asynch] No asynchronous data in MLME-STREAM-xxx!!!!!!!!!/KO

SuggestedRemedy:
Delete "and asynchronous data" from sentence


Comment:
Change DEVInfoSet <to> DEVRecordSet, which is more in keeping with the DEV-1 record, DEV-2 record, ... DEV-n records nomenclature used  in clause 7.5.4.2.  Also change the text in the description column for this parm <from> " A set of DEV inofrmation elements for the requested DEVs. " <to> "A set of one or more DEV records requested from the PNC."

SuggestedRemedy:
Please make the indicated parameter name change


Comment:
[CTM/Isoch] Priority needs to be passed from DME to be put in CTRB/KO


Comment:
Change the DEVInfoSet parameter name <to> DEVRecordSet, which is more in keeping with the DEV-1 record, DEV-2 record, ... DEV-n records nomenclature used  in clause 7.5.4.2.


SuggestedRemedy:
Change Enumeration "ACK" for ACKPolicy to "IMM-ACK"


Comment:
Change MLME-PNC-INFO.confirm <to> MLME-PNC-INFO.indication, which is the correct primitive name for this phase of the PNC handover process.


SuggestedRemedy:
Add table entry:Name: PriorityType: IntegerValid range: As defined in table A.1Description: 802.1 D priority level


Comment:
[PNCHndOvr] The text of this clause is incorrect description of what happens during the end beacon transition phase.  Please replace with this text:  "The PNC DME, upon receiving this primitive, is informed whether its MLME-PNC-HANDOVER.request was successful or unsuccessful. The ResultCode is set to SUCCESS when the PNC sends its last beacon as PNC before the HandoverTimeout interval expires.  The ResultCode is set to TIMEOUT, if the PNC fails to receive the PNC handover response command before the HandoverTimeout interval expires.

SuggestedRemedy:
Please make the indicated change since this was the approved text from CID 382.


Comment:
CTM/Isoch] TRUE/FALSE is a bad naming convention for a stream type/KO

SuggestedRemedy:
Change GTS-Type:Type: EnumerationValid range: DYNAMIC, PSEUDO_STATIC


Comment:
Change the DEVInfoSet parameter name <to> DEVRecordSet, which is more in keeping with the DEV-1 record, DEV-2 record, ... DEV-n records nomenclature used  in clause 7.5.4.2. Also change the text in the description column for this parm <from> " A set of DEV information elements for the requested DEVs. " <to> "A set of one or more DEV records requested from the PNC."


Comment:
[DepPN/Child] A parent PNC may refuse creation of a child piconet because it cannot support it. Just replying lack of channel time may cause the aspiringchild PNC to try again in vain (ref. 02/276r6 resolution[18])./KO

SuggestedRemedy:
Add to ResultCode, Valid range:CHILD_UNSUPPORTED


Comment:
[CTM/Isoch] Only directed streams can be opened with ack policy other than No-ACK.(ref. 02/276r6 Resolution [01])/KO

SuggestedRemedy:
Add text to MLME-CREATE-STREAM.confirm, When generated:If a multicast or broadcast stream was opened with any other ACK-Policy than no-ACK, this primitive shall be returned with ReasonCode set to INVALID_ACK_POLICY without sending a channel time request command to the PNC

Response:
ACCEPT IN PRINCIPLE. Add to when generated in MLME-CREATE-STREAM.request: 'If a multicast or broadcast stream was opened with any other ACK-Policy than no-ACK, the MLME will not send  a channel time request command to the PNC and shall be respond with MLME-CREATE-STREAM.confirm with ResultCode set to INVALID_ACK_POLICY.'


Comment:
[CTM/IsochModify] Target ID cannot be changed when modifying a stream/KO


Comment:
[CTM/Isoch] Add the StreamTermination and Priority parameters to the table just after the CTR-Type parm.Name: StreamTermination; Type: Boolean; ValidRange:True/False; Description:Indicates a request to discontinue an existing stream as defined in 7.5.5.1.Name: Priority; Type:Integer; ValidRange: as defined in Annex A, Table A.1


Comment:
[MultiCast] MLME-MULTICAST-RX-SETUP.request is not referenced anywhere in clause 8.Should it affect reception filtering?/KO

SuggestedRemedy:
Decide what it shall do and add it to clause 8.


Comment:
Move this clause to just after clause 6.3.15.7.2 and before clause 6.3.16.  The reason is: this primitive is not the result of the PNC MLME receiving the channel time request command.  Consequently, its position in the text should come after the MLME-TERMINATE-STREAM.confirm defintion.


Comment:
BeaconDuration should be changed to conform with name in 7.4.6/KO


Comment:
Change this sentence frag. <from> "...is notified of the result of its CTA termination request." <to> "...is notified of the result of its stream termination request."


SuggestedRemedy:
Change parameter "BeaconDuration" to "SuperframeTiming"


Comment:
Change the primitive name <from> MLME-MULTICAST-RX-SETUP.request <to> MLME-RX-MULTICAST.request. The new primitive name is more concise.


Comment:
Change types in Effect of receipt does not reference CHANNEL change./KO

SuggestedRemedy:
Insert this text before "Otherwise, the PNC MLME..."If the primitive is received with the ChangeType set to CHANNEL, the MLME shall take actions as defined in Dynamic Channel selection, 8.11.1.


Comment:
Delete the word "associated" from this sentence frag: "...by the originating DME to its associated MLME..." since it is redundant with the possessive its.


Comment:
[PM} As indicated in 7.5.7.1, a DEV is allowed to participate in both PSPS and SPS. Therefore a third mode is needed in table./KO

SuggestedRemedy:
Add a definition to bothMACPIB_PowerManagementMode and MACPIB_PowerManagementAllowed:0x03=PSPS and SPS


Comment:
Change the indicated sentence frag. <from> " Indicates the scan was denied or was successful,..." <to> Indicates whether the scan was denied or successful, ..."


Comment:
[CTM/Asynch] Priority is no longer passed in the header, so a destination of a data frame cannot know with which priority it was sent./KO


Comment:
Move the NmbrOfChangeBeacons parm from the end of the parm list to just after the ChangeType parm. To make it consistent with the format of the piconet parameter change IE described in 7.4.6, figure 30. Also change the name of the BeaconDuration <to> SuperframeDuration.


Comment:
[CTM/Isoch] If the dly-ACK policy was declined by the destination with an Imm-ACK, the source must be informed of this so it can modify the stream parameters, ifnecessary. (Ref 02/276r6 Resolution [01])/KO

SuggestedRemedy:
Add text to When generated:If the dly-ACK policy was used, but the destination refused the use of dly-ACK, the ResultCode shall be set to DLY_ACK_FAILED. This implies successful transmission of the corresponding data frame.

Response:
ACCEPT IN PRINCIPLE. Add text to When generated: 'If the dly-ACK policy was used, but the destination refused the use of dly-ACK, the ResultCode shall be set to DLY_ACK_FAILED. This indicates successful transmission of the corresponding data frame.'


Comment:
Table for PHY primitives incorrectly references MLME/KO

SuggestedRemedy:
In Definition of PSResultCode, change text to:Indicates the result of the PHY request.


Comment:
[CTM/Asynch] Change this sentence frag. <from> "... needs the ability to create, modify and terminate ..." <to>  "... needs the ability to reserve and terminate..."

SuggestedRemedy:
When channel time is being requested for an asynchronous data exchange, it is reserved.  There is no connection created or modifiable.  Consequently, make the requested change.


Comment:
[SEC/Auth] OID and OID_Length parms are missing from the parm list of this primitive, even though they are in the Auth-request.cmd.

SuggestedRemedy:
Please add the missing parms to the MLME-AUTHENTICATE.request primitive.


Comment:
[SEC/Auth] Why isn't the DEVAddress passed up to the PNC-DME in this primitive?  It is in the Auth-request cmd.

SuggestedRemedy:
Please either provide explanation why the DEVADdress isn't passed or add the parm to the parm list of the MLME-AUTHENTICATE.indication.


Comment:
[SEC/Auth] Why is TrgtID used? It seems like since the originating DEV requested to Authenticate that the Authenticating DEV(which is the TrgtDEV) would respond with the OrigDEV's DEVID  in the Challenge REquest parm list.Why are the OID and the OIDLength parms in the MLME-CHALLENGE.request primitive?  They aren't passed in the challlenge request cmd.Also where is the ReasonCode parm?  Its in the Challenge request cmd.

SuggestedRemedy:
Change the TrgtDEV parm name to OrigDEV.Delete the OID and OIDLength parms from the MLME-CHALLENGE.request parm list.Insert the ReasonCode parm just before the SECID parm in the MLME-CHALLENGE.request parm list.


Comment:
[SEC/Auth] Why is OrigID used?  Seems since the originating DEV requested to Authenticate that it would be receiving this primitive from the authenticating DEV which was the original TrgtDEV for the Auth request.  Also where is the reason code parm? And finally, Why are the OIDLength and OID parms being passed up to the DEV-DME? These two parms are not part of the challenge request cmd.

SuggestedRemedy:
Please change the OrigID parm name to TrgtID.Add the ReasonCode parm just before the SECID in the MLME-CHALLENGE.indication parm list.Remove the OIDLength and OID parms from the MLME-CHALLENGE.indication parm list.


Comment:
[SEC/Auth] Why is OrigID used?  Seems that since the DEV requesting to authenticate is sending the challenge response cmd back to the authenticating DEV that it would used the TrgtID parm instead.


Comment:
[SEC/Auth] Why is TrgtID used?  See previous comments regarding this issue.


Comment:
MAC PIB ACL group defined as an array whose contents are defined in Table 33. All of the entries are dynamic, but no clear mechanism to update these entries has been included in the draft. There are no limits on the minimum and maximum number of entries allowed in the ACL. The only use for this array in the MAC is for generation of the CCM nonce and obtaining the keys associated with a particular SECID for encoding or decoding payloads.

SuggestedRemedy:
Either remove the MAC PIB ACL or add appropriate method for updating the information in the array. If the ACL is kept, add limit for the minimum number of ACLs that must be supported for a DEV, SM, and PNC. Provide a mechanism for updating and accessing the contents of an ACL entry. Suggest defining MLME commands for doing this using an index to the array. Add MAC PIB entries to indicate last index used in the array. Finally, clarify relationship between DEVHost and MAC regarding use and management of informaiton in the ACL.


Comment:
"public-key object type" use here, but it is not defined until 7.5.2.1.

SuggestedRemedy:
Move the definition of public-key object type from 7.5.2.1 to 7.4.15. Move lines 1-11 on page 134 to line 16 on page 128. Replace lines 1-11 on page 134 with line 16 on page 128.

Response:
ACCEPT IN PRINCIPLE. Move the definition of public-key object type from 7.5.2.1 to 7.4.15. Replace line 16 on page 128 with lines 1-11 on page 134. Replace lines 1-11 on page 134 with "The public-key object type field specifies the type of public key specified in the public-key object {xref 7.4.15}."


Comment:
References for "Association Status", "MaxAssignedCTAs", "MaxProcessedCTAs", and "ATP" are missing. More importantly, the reference for the octet "SPS Info" says "shall be formatted as illustrated in Figure 38 and is defined in 7.4.13." Figure 38 is a multi-octet element named "SPS Status", with no clear correlation to "SPS Info"

SuggestedRemedy:
Delete SPS info, add cross references that define "Association Status", "MaxAssignedCTAs", "MaxProcessedCTAs", and "ATP".  The SPS information is passed in the SPS information command.


Comment:
The reference for the octet "SPS Set" says "The SPS set field is defined in Figure 7.5.7.2." I think he meant "Section" and not "Figure". In section 7.5.7.2, the field defined there is named "SPS Set Index" and not "SPS Set".

SuggestedRemedy:
Change the reference to say just 7.5.7.2. Change "SPS set" to be "SPS set index"


Comment:
This section mentions "next awake beacon" many times, which is no longer used in this command.


Comment:
Next awake beacon is no longer defined in 7.5.7.2.

SuggestedRemedy:
Change the field definition to be the following "The next awake beacon field is a beacon number, 7.4.2, when the DEV is scheduled to be awake."


Comment:
In 7.5.2.6 Request key response command, the "Key" field in the Request Key Response Command does not appear to line up well with the parameters of the MLME-Request-Key.rsp and MLME-Request-Key.cnf parameter "EncryptionSeed".

SuggestedRemedy:
Change "EncryptionSeed" in the MLMEs to be "Key"

Response:
ACCEPT IN PRINCIPLE. Change "EncryptionSeed" on line 32 to  "Key". Delete "in an encrypted format" from line 26.


Comment:
In 7.5.3.3 PNC handover information command, CTRB in 7.5.3.3 set at 12 bytes. CTRB in 7.5.5.1 is variable length 12-138 bytes.

SuggestedRemedy:
Either add a length field to the PNC handover information command for each of the CTRBs or change the CTRBs to use a constant length with a bit to indicate if the asynchronous request is type 1 or type 2.


Comment:
A variable length CTRB is really annoying and can be avoided by using a single bit.  Another problem is what is the PNC to do if the DEV requests asychronous time with only one DestID.  Is it in shared CTA mode or directed CTA mode?  What does the PNC do when another asynchronous request comes in?

SuggestedRemedy:
Add a bit to the CTRB that indicates if the asychronous request is for a shared CTA or directed CTA.  Then eliminate the num targets and set the DEVID to be just one octet.  The DEV sends this command with a separate CTRB for each asynrhonous destination DEVID.  The PNC simply keeps track of the total of TUs requested for all DEVIDs, in the case of a shared asynchronous CTAs, or the individual TUs in a directed asynchronous CTR.


Comment:
Should the CTA IE be last in a beacon? If a dev only has to process MaxProcessedCTAs, what's the point if  the dev has to stay awake to look for other IEs. If the CTA IE was last, then the dev could go to sleep  after MaxProcessed CTAs for the remainder of the superframe if there are no CTAs involving it.

SuggestedRemedy:
Make the CTAs last in the beacon.  Other information may still go in the probe frame that follows.


Comment:
There does not appear to be anything written to handle the case where the PNCHandoverTimeout expires before  the handover process completes. Does something need to be sent to the PNCCapableDEVID to indicate the  handover has been aborted? Can the handover process even be stopped? Is there even a need for a timeout?

SuggestedRemedy:
I suggest that HandoverStatus be added to the PNC handover request command. When the handover is initiated, HandoverStatus is STARTED. If the handover timer expires, the cmd is sent to the target devid with HandoverStatus of CANCELLED. Add an MLME-PNC-HANDOVER.ind to Figure 91 after the new beacon goes out with a HandoverStatus of COMPLETED to inform the DME that the process completed and it is now the PNC.  Also add text to clause 8 that indicates if the DEV sees a shutdown IE from the PNC during the handover process, it knows that the handover was cancelled.


Comment:
PNC Handover IE is missing from the beacon payload table 39.

Response:
ACCEPT. Double check to make sure that all of the IEs that need to be there are in Table 39 (e.g. PSPS status and SPS status).


Comment:
The remote scan response command does not tell the PNC if the remote scane request command was a malformed request.

SuggestedRemedy:
Add a reason code "invalid channel requested"


Comment:
The is currently no way for a DEV to request the channel time response information if it missed it.

SuggestedRemedy:
Change CTA response command to send IEs or simply declare the IEs to be sent with the probe command.  Either way, this lets the DEV request the information if it thinks that it lost it.  This would also give us an easy way to send multiple confirms in one CTA response command.


Comment:
Why is the CRC an exception to the bit ordering? The CRC should simply be interpreted appropriately with the bits sent in whatever order the PHY requires.

SuggestedRemedy:
Add text that indicates that the msb first applies only to the FCS.  The PHY determines how the HCS is sent.


Comment:
There is no indication in the discussion of the secure frame that the payload is encrypted.

SuggestedRemedy:
Add the following sentence before Figure 6: “The payload field in the secure MAC frame body shall be in encrypted form and shall be the same length as the payload before the encryption operation was performed.”


Comment:
The FCS should always be 4 bytes, since it is always included in secure frames.

SuggestedRemedy:
Remove “0 or” from the figure. This should also be changed in Figure 21.


Comment:
There is no description for the payload field and FCS field for the secure frame body.

SuggestedRemedy:
The text for Payload field and FCS field in sub-clause 7.2.7 should be duplicated or referenced in 7.2.8.


Comment:
There is no reason why the entire piconet must be in a particular mode or use a particular security sub-suite. If the PNC is capable of doing authentication with multiple techniques, devices should be allowed to join the piconet using different security suites. This does not pose an interoperability issue since all operations outside of the authentication process are the same for all security suites.

SuggestedRemedy:
Change the SEC mode to SEC use and set 0 to be false (no security use) and 1 to be true (security in use).


Comment:
The public-key object type is not defined.

SuggestedRemedy:
This should reference 7.5.2.1 or, more properly the list should be included here and referenced in 7.5.2.1.

Response:
ACCEPT IN PRINCIPLE. See resolution of CID 6 which did this.


Comment:
The public-key object types listed in 7.5.2.1 are not necessarily sufficient for information to verify a public-key object that is received.

SuggestedRemedy:
A new information element called ACL entry value should be added. The ACL entry value should have a type, length, DEV address and verification value. This verification value may be a SHA-1 hash, a SHA-256 hash, an X.509 CA certificate, an implicit certificate CA certificate or some other as yet undefined field. This should be flexible since in future iterations, the verification information may change form.


Comment:
The disassociation request command may be sent before the device is authenticated. In addition, the table does not specify when the commands shall be sent with security turned on.

SuggestedRemedy:
The X should be removed from the “authenticated (if required)” column for the disassociation request command and a column should be added indicating which frames shall be sent with security when authenticated. Recommend allowing the probe command and piconet services command and all of the association, authentication and challenge commands not to require security and all the rest of the commands to require security when authenticated. Alternately, this information could be added to clause 9 if that is a more appropriate location.


Comment:
There needs to be a way to handover access control information to avoid having to recreate the ACLs every time there is a handover.

SuggestedRemedy:
Add a secure PNC information command. This includes everything in the PNC information command, but it also includes an OID for authenticating with that DEV and public-key verification information. This command may be used at any time, but particularly during PNC handover to help smooth the transition process. The public-key verification information should reference the table included in the new ACL entry information element for the appropriate types of public-key verification information.


Comment:
[FrmFrmt/Payload] replace aMaxFrameSize-4 with aMaxPayloadSize which is equal to aMaxFrameSize-4.  A CID 255 from LB17, although withdrawn, indicated the confusing nature of the text.Also change this sentence frag <from> "...the number of actual information octets by 12." <to> "...the aMaxPayloadSize by 12 octets."


Comment:
Change the caption <from> "Piconet synchronization parameters information element format." <to> Piconet synchronization parameters field format."  This is a more accurate description of the diagram since it is not an IE.


Comment:
The word parameters is mispelled in the diagram.


Comment:
Payload field length for secure frames should be moved to that clause./KO

SuggestedRemedy:
Change the payload texts to:7.2.7.1 Payload fieldThe payload is a variable length field and contains information specific to individual frame types. When the SEC bit is set to 0, the minimum payload is zero octets and the maximum payload length is aMaxFrameSize -4 octets.7.2.8.1 Payload fieldThe payload is a variable length field and contains information specific to individual frame types. When the SEC bit is set to 1, the minimum payload is zero octets and the maximum payload length is aMaxFrameSize -16 octets.


Comment:
[FrmFrmt/Data]A non secure data frame format with an FCS = 0 octets implies a zero length data payload.  Does that mean we now have a "null" data frame? Please clarify.


Comment:
FCS is the same for both secure and unsecure frames/KO

SuggestedRemedy:
Move this clause to a separate clause, e.g. 7.2.9, to be put after both the secure and unsecure specific clauses.


Comment:
[FrmFrmt/Data] A zero length FCS for a secure data frame doesn't seem possible since even with a zero length encrypted data field their would still be an SECID, SFC, and Integrity code.


Comment:
[FrmFrmt/Bitorder] I still hold that MSb first is better, (ref LB17 CID 150).If MSb first is rejected, a definition for how to transmit data andvariable length fields (e.g. BSID, Vendor ID, etc.) is absolutely required./KO

SuggestedRemedy:
1) Make final decision about MSb/LSb first.Ref LB17 CID 150 and 02322r0P802-15_TG3-bitorder.doc2) If LSb first wins, specify a useful mechanism for all strings,including data payload fields. This is an excerpt from a mail discussion:----------------------------------What is critical at this point is to define how data and strings should be sent. If we send them LSb first in a byte by byte order we at least don't have toflip whole buffers. In detail, this is what I mean:Say that you have data from upper layers, or for instance a BSID to be sent in a command frame or beacon.The sample string is "Wireless".I'd like to avoid to first having to swap my buffer byte by byte to make the string "sseleriW"If I only have to mirror every byte, that is W = 01010111b will be sent over the air as 11101010b, I'm okey with that. Numeric fields spanning multiple octets, such as PNID = 765could be sent as currently defined, that is:765d = 00000010-11111101b is sent as 10111111-01000000b. Would this be ok as a LSb first solution?My biggest concern isn't mirroring a 2-4 octet field, it's to mirror a 75MB stream!-------------------------


Comment:
[MaxCTA] Are the MaxProcessedCTAs and MaxAssignedCTAs fields really necessary? If not delete them from the figure as well as any supporting text in clause 7.4.4


Comment:
[IE/ASIE] The following comment is taken from CID 76 of LB17 database 02/299r16: "The Application Specific information element is an interesting and potentially useful information element.  However, the sentence in line 50 of D10(p124, l27-28 of D11) opens the door for interoperability problems. Consequently, if the sentence: ..."The negotiation of the application specific capability between the DEV and the PNC is outside of the scope of this standard" is not deleted and replaced with a specification for how this information element is to be used, I strongly recommend that this information element be removed from the specification.  Also the text that is currently in D11 does not represent what was agreed to in Clause 2.2.7 of 02/273r17. The text in 2.2.7 of 02/273r17 included the descriptions of the required MLMEs and the functional description of how the ASIE was intended to be used. Unfortunately neither the MLMEs or the functional descriptions made it into D11. Consequently, remove the ASIE from clause 7.4.7.

Response:
ACCEPT IN PRINCIPLE. Add the text for clause 6 and clause 8 from Clause 2.2.7 of 02/273r17 to describe the use of the ASIE.


Comment:
[FrmFrmt/Bcn] The system wake beacon countdown is missing in the piconet synchronizationfield./KO

SuggestedRemedy:
Add field and text as specified in 02276r7P802-15_TG3-commentsD11_KO.doc, Resolution [14]


Comment:
[MaxCTA] Remove the MaxProcessedCTAs and MaxAssignedCTAs from the Capability IE.  These two fields are unnecessary. They are of no interest to any other DEV other than the PNC.


Comment:
[PNCHndOvr] We need to hand over the current powersave status of the DEV./KO

SuggestedRemedy:
Add field to Figure 64.1 octet, PowerSaveInfoText:The PowerSaveInfo field contains the current power save mode(s) of theDEV as defined in 7.5.7.1.


Comment:
The field Association status in Figure 64 is never defined./KO

SuggestedRemedy:
Add text:The Association status field contains the DEV's current association status as defined in 7.4.4.


Comment:
[PNCHndOvr] MaxAssociations, MaxCTRB and MaxTxPowerLevel need to be passed during handover.(ref 02/276r6 page 21, CID 206)/KO

SuggestedRemedy:
Add to Figure 64:1 octet: MaxAssociations1 octet: MaxCTRB1 octet: MaxTXPowerLevelAdd text:The MaxAssociations field is described in 7.5.1.1The MaxCTRB field is described in 7.5.1.1The MaxTXPowerLevel describes the maximum transmit power of this DEV as defined in {xref TxPowerLevel}


Comment:
[PNServices] There is no need for a new Piconet services command.If an associating DEV demands it, the PNC can reply with a probe command with the Services IE./KO

SuggestedRemedy:
Delete clause 7.5.4.4.(corresponding change in 8.3.2 in another comment)

Response:
REJECT. The information sent in the PN services command is likely much longer than an IE, thus it is easier to send it in a command.  With a single command, the DEV knows when it has received all of the data, as opposed to an set of IEs.


Comment:
[CTM/CTR] Two errors: 1) still called aynhronous stream. Should be CT2) MTS interval may be requested, as agreed in Schaumburg/KO

SuggestedRemedy:
Page 142, line 18: Change "creation, modification or termination of an asynchronous stream" to: "reservation or termination of asynchronous channel time"Page 142, line 21: Add text:In the case where the DEV is requesting a specific MTS interval, thestream index shall be set to the MTS stream value, 7.2.5.Page 142, line 52: Add text:If the request is for MTS interval, only this field shall be interpreted bythe PNC. All other fields except the stream index field shall be set to 0.


Comment:
[CTM/Asynch] For asynchronous requests, PNC only sends a response frame upon denial./KO

SuggestedRemedy:
Change text on line 43-45 from:"For asynchronous stream requests, ...DEVs request for channel time"To:For asynchronous stream requests, the response frame is only sent if the PNC is unable to fulfill the request, in which case the available number ofTUs field is set to 0.


SuggestedRemedy:
Add reason code:10->Child piconet unsupported11-255->Reserved


Comment:
[CTM/CTR] PSPS mode DEVs don't get their streams terminated when they go topowersave, since they still follow their GTSs.If they want a stream terminated they have to ask for it./KO

SuggestedRemedy:
Change reason code from:"6->Stream terminated, DEV entered power save mode"to:"6->Stream terminated, DEV entered SPS mode"


SuggestedRemedy:
Change "PS change command" to "PS mode change command".Change on line 32 and 34


Comment:
[PM] Missing from 02/276r6 Resolution [14]./KO

SuggestedRemedy:
Add text:This command shall only be sent by an associated DEV to its PNC


Comment:
[SEC/KeyDist] It was never settled if the key distribution is done by a broadcast(ref 10.2.5.1). I raised the issue on the reflector that we cannot letPNC send directed frames to every DEV every time a DEV authenticatesor disassociates because the PNC would flood the media with frames andbecause you would get recursion problems when a DEV changes associationstatus during the key distribution./KO

SuggestedRemedy:
Settle this in Monterey. It doesn't work as it is now.


Comment:
[CTM/CTAStat] The idea to send a directed CTA status command to DEVs in sleep modeand for all pseudostatic streams is not good for the following reasons.1) multicast/broadcast. We have already said that PSDEVs are not required to listen to non directed streams,but unless we announce them, they don't even have thechance to do so.This is true regardless of the stream is psudo-stat ordynamic, subrate or regular.2) The PNC has to allocate a down MTS for this directed frame.If the frame is not ack:ed it's supposed to allocate another down MTS and resend it. This will be hard to implementand the risk is that all implementors will make a long defaultdown MTS to broadcast to allow for all events. That wouldsuck power.Conclusion:since it's already taking the pain to allocate MTS in thebeacon, why not put the announcement there as proposed in 02/276r6.This would solve all the above cases./KO

SuggestedRemedy:
Introduce a CTA status IE, see 02276r7P802-15_TG3-commentsD11_KO.doc, Resolution [14]


SuggestedRemedy:
Delete this clause and replace with CTA status IE, see02276r7P802-15_TG3-commentsD11_KO.doc, Resolution [14]


Comment:
[IE/ASIE]  Delete the Application Specific IE from table 39.  The text agreed to in Schaumburg did not make it into this draft therefore, this IE represents and interoperability liability.


Comment:
Change this sentence frag. <from> "...is the integrity code associated with the auth..." <to> "...is the integrity code generated by the security manager and associatied with the auth protocol described in {xref: 10.x.y}


Comment:
The Parm list in the MLME-REQUEST-KEY.response has an EncryptedSeed parm, yet the Request key response cmd has simply a Key parm. Which is the correct parm name?

SuggestedRemedy:
Please clarify as to which parm name is correct and make the requisite change.


Comment:
The Parm list in the MLME-DISTRIBUTE-KEY.request has an EncryptedSeed parm, yet the Distribute key request cmd has simply a Key parm. Which is the correct parm name?


Comment:
[PM/SPS] Why does the SPS configuration request command format have to vary between 2 and 4 octets?  Why not just keep it 4 octets?  Seems it would make it less complicated to to decode.

SuggestedRemedy:
Please fix the SPS configuration request command length to 4 octets. Also make appropriate changes to Table 49 to reflect the fact that the frame format is fixed.


Comment:
[PM/SPS] Why does the SPS configuration response command format have to vary between 2 and 8 octets?  Why not just keep it 8 octets?  Seems it would make it less complicated to to decode.

SuggestedRemedy:
Please fix the SPS configuration request command length to 8 octets. Also make appropriate changes to Table 50 to reflect the fact that the frame format is fixed.


Comment:
[IE/ASIE] The following comment is taken from CID 76 of LB17 database 02/299r16: "The Application Specific information element is an interesting and potentially useful information element.  However, the sentence in line 50 of D10(p124, l27-28 of D11) opens the door for interoperability problems. Consequently, if the sentence: ..."The negotiation of the application specific capability between the DEV and the PNC is outside of the scope of this standard" is not deleted and replaced with a specification for how this information element is to be used, I strongly recommend that this information element be removed from the specification.  Also the text that is currently in D11 does not represent what was agreed to in Clause 2.2.7 of 02/273r17. The text in 2.2.7 of 02/273r17 included the descriptions of the required MLMEs and the functional description of how the ASIE was intended to be used. Unfortunately neither the MLMEs nor the functional descriptions made it into D11.

SuggestedRemedy:
Consequently, remove the ASIE from clause 7.4.7.


Comment:
PSPS, SPS, PSPS and SPS as separate modes are unnecessary.

SuggestedRemedy:
The differences between SPS and PSPS that cannot be merged is what dev sets the value of the SPS Interval in the SPS Set. Give the PNC an SPS Set with index 0. DEVs can already be memeber of multiple SPS Sets giving them the timing of both sets when the DEV switches to SPS mode. Therefore: only the first two entries (0 - ACTIVE, 1 - SPS) are necessary.


Comment:
In 8.9.2 Probe, tables 52 and 53 indicate that a DEV may request the "PNC Shutdown" IE and that the PNC should respond to a request. There is no data associated with this information element, so why allow a request for it? What does the PNC include in the Piconet Parameter Change IE? This IE is used to countdown and manage an upcoming change. What does in mean for a DEV to request it from the PNC? Same deal with the "PNC Handover"  IE. I would put these two IEs in the same category as the "Channel Time Allocation" IE. Maybe PCTM IE also. SPS Set IE doesn't make sense either. The IE returns the status of a single set. Which set status would the PNC return? Besides, we have specific MLME commands to request SPS Set information. Someone needs to think through these tables more carefully

SuggestedRemedy:
Change PNC shutdown, PNC handover, Piconet parameter change, SPS status and PSPS status to be Shall ignore for all three entries.

Response:
ACCEPT IN PRINCIPLE. For the PNC received request from DEV, change the following to shall ignore: DEV association, PNC shutdown, Piconet parameter change, PNC handover, SPS status.


Comment:
The comments regarding ATP are redundant and are out of place here as are the MSCs.

SuggestedRemedy:
Delete the sentences "A DEV shall hear at least one beacon before sending its request for association. If a DEV ... or search for a new piconet."  Move the MSCs to 8.3.4 and change the states from "unsynched" to "associated" and "synched" to "associated" in Figure 118.  In Figure 119, change the states to "associated" and "disassociated".The MLOME-SYNCH.{request,confirm,indicate} commands are unnecessary as well now and so should be deleted. Figure 118 is also unecessary, so it needs to be deleted as well.  If the DEV has lost synch, its ATP has expired and so it needs to reassociate.  The DME finds out via the MLME-DISASSOCIATE.ind.  The DME is not aware if the DEV has lost temporary synch, that is the job of the MAC and PHY to handle, not the DME. Otherwise, the whole synch thing needs to be rewritten to handle only short term synchronization (i.e. catching a few beacons).

Response:
ACCEPT IN PRINCIPLE. Delete the three sentences. In 8.3.4 change the last sentence in the paragraph on page 167, line 1 to be  'Similarly, if the beacons from the PNC are not received by the DEV for longer than the ATP, the DEV shall consider itself disassociated from the piconet and may try to associate again. The DEV notifies the DME that the ATP expired using the MLME-ATP-EXPIRED.ind primitive.' Keep MLME-SYNCH.{request,confirm} as they are used for the association process. Delete figure119. Rename MLME-SYNCH-LOST as MLME-ATP-EXPIRED.  Add text to 8.3.1 that indicates that the DEV needs to perform an MLME-SYNCH prior to starting the association process.


Comment:
Does the second Association Request Cmd during the association process result in an MLME-ASSOCIATE.ind to  the PNC DME? Perhaps the answer is no because the SourceDEVID does not equal AssocID? Should text be added to indicate this?

SuggestedRemedy:
Add text to 8.3.1 that explains why the second association request command does not create a .rsp primitive.

Response:
ACCEPT IN PRINCIPLE. Add a second MLME-ASSOCIATE.ind to the MSC after the second association request command.  Add the OrigID to the MLME-ASSOCIATE.ind and put a definition in the table that says it is either the UnassocID or the DEVID that was just assigned by the PNC.  Add DEVID=UnassocID to the first MLME-ASSOCIATE.ind and DEVID=0xzz to the second one.


Comment:
The single MSC in this subclause really doesn't tell all the possible ways that the probe command can be used.

SuggestedRemedy:
Add a couple of other MSCs that show 1) sending information only, 2) requesting information only and 3) the current one that shows all of them happening at the same time.


Comment:
Missing xref here.  Also, Figure 110 should be removed  and that the ability to send a MAC-ISOCH-DATA.req be without a prexisting stream be eliminated for the following reasons.  First, in all other cases of isochronous stream creation the DME is aware of the stream creation and can also make this information available to the FCSL.  This allows the FCSL to maintain a map of the assigned streams.  In addition, the DME is not aware of the stream so that it can terminate it (as described in clause 8.5.1.3)  Second, it does not make sense that an application generating isochronous data would start sending data before it determined whether the stream could be supported by the piconet.

SuggestedRemedy:
Delete figure 110 and add text to the MAC-ISOCH-DATA (and appropriate error codes) that indicate that it may only be sent if there is a prexisting CTA allocated for that stream.


Comment:
The MLME shown in figure 116 should be changed to MAC/MLME.  The MAC-ASYNC-DATA.req is not sent by the FCSL to the MLME.  This is a MAC primitive.  Also, change the MSC so that the DME be notified by the MAC/MLME with an MLME-CREATE-STREAM.cfm if the stream creation is successful for the following reason.  The DME will be aware of the stream creation as in other cases and stream termination will work.  As it is, termination will not work.

Response:
ACCEPT IN PRINCIPLE. Change as indicated. Also, show the data frame as coming from the MAC/MLME to the other MAC/MLME as well as the ACK.


Comment:
Add two columns to the probe command table 53 that indicates if a DEV or the PNC is allowed to send the request.

Response:
ACCEPT IN PRINCIPLE. Add the edits to the table 53 as shown in 02/392r2.


Comment:
On a side note, 1024 ms DEVIDReuseTime is too small unless the ATP is smaller than that.  Since the ATP can be up to 65535 ms, the DEVIDCReuse Time needs to be at least that big.BTW: Suppose you miss the disassociation frames and a few beacons.  Then you see some and assume your ATP has not expired.  You send a blank probe to the PNC and get an ACK (since it ACKs all frames with correct FCS).  The DEV assumes its ATP has been reset and that its DEVID is still correct.

SuggestedRemedy:
To be safe, DEVIDReuseTime must be more like twice the ATP.  Set the DEVIDReuseTime to be twice the maximum possible ATP.Also, state that PNC should try to disassociate a DEV again that sends a frame after its ATP has expried  In addition, state that the PNC should not reuse this DEVID until it is sure the DEVs ATP timer has expired.

Response:
ACCEPT IN PRINCIPLE. Delete aDEVIDReuseTime. Change ‘However, the reallocation of the same DEVID by PNC shall be at least aDEVIDReuseTime after the disassociation of the DEV that was allocated the same DEVID.’ to be ‘After the PNC sends a disassociation command to a DEV, the PNC shall not reuse the same DEVID of that DEV until at least two times the ATP duration for that DEV has passed.’ Add to the ATP discussion in disasociation ‘The PNC shall send a disassociation command to a DEV that sends a frame after its ATP has expired.’


Comment:
When requesting a change to MTS allocations, only the CTRB fields CTR-interval and CTR-interval type = 1 has a meaning. All other fields/values should be ignored/rejected. PNC decides duration, dest-ID (implied) and all other params. The DEV can ask for MTS every N superframe, nothing else.


Comment:
Open and association MTSs were put back into the draft (they were originally part of the Sharewave proposal, but were dropped in favor of the CAP) under the assumption that certain PHYs would have problems doing CCA in a reasonable amount of time.  However, recent work in SG3a indicates that the new PHY will be able to acquire signals in less than 15 us and should therefore be able to perform CCA in approximately the same time as the 2.4 GHz PHY.  Therefore, there is no reason to have the additional complexity of open and association MTSs.  Directed MTSs were always a part of the draft since they are simply GTSs where the source or destination is the PNC and hence are exactly the same as GTSs

SuggestedRemedy:
Remove this subclause and all references to MTS in the draft.  The PNC is still allowed to allocate channel time directly to a DEV and the DEV is able to request channel time with the PNC, just as they have always been allowed.


Comment:
Based on the clause 6 text, there should be an MLME-PNC-HANDOVER.ind after the DEV (now PNC) sends its first beacon.


Comment:
The aMaxTransferUnitSize is so large that it will prevent implementers from creating very low cost compliant DEVs.   Note that upper layer protocols are already able to determine the MTU and adjust their fragmentation accordingly.The biggest MSDU you have to reassemble is 64 kB, period. Thus for 8 QoSstreams plus asynchronous, you might have to reassemble 9*64 kB, which is pretty damn big.

SuggestedRemedy:
2 k to 8 k should be fine and would significantly reduce the buffering requirements for re-assembling the frames.


SuggestedRemedy:
I suggest "Draft Standard for Information technology—Telecommunications and information exchange between systems—Local and metropolitan area networks—Specific requirementsPart 15.3: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for High Rate Wireless Personal Area Networks (WPANs)"Please make the change to Clause 1, page 1 too.


Comment:
The sentence ending "...802.15.3-2002 was approved." should be changed for accuracy.

SuggestedRemedy:
I suggest "...802.15.3-2003 was approved." as more accurate statement.


Comment:
I recommend before you go to Sponsor Ballot that you correct the IEEE-SA Standards Board entries, they are outdated.

SuggestedRemedy:
I suggest you correct that Jim Carlo is the StdsBD Chair, etc.  More info:http://standards.ieee.org/board/stdsbd/


Comment:
Don't make the PNC wait for all ACTIVE DEVs to receiver the key, simply make him try and then give up.

SuggestedRemedy:
Change the text in clause 9 to indicate that the PNC only needs to try and wakeup the DEVs and then give up.


Comment:
Shouldn't the PNC terminate all streams with the CTR interval type set to 1?What about switching a DEV to ACTIVE mode? Are there any restrictions on the stream allocations? Need to mention here that the PNC will not necessarily align subrate allocations to the system wake beacon.

SuggestedRemedy:
Add to PSPS that the PNC terminates all streams with CTR interval type set to 1 when the DEV enters PSPS mode.Add text similar to SPS that says if the DEV gets an ACTIVE mode allocation, it shall be considered to be in ACTIVE mode.  Also add the note that the PNC will not necessarily align a subrate allocation to the system wake beacon.


Comment:
When a frame is queued for transmission but insufficient time remains in the CAP to send it (and perhaps to receive its ACK), the backoff counter for that transmission is suspended and countdown begins again for that value when the next CAP occurs. What if the PNC decides there will be no further CAPs? The frame transmission should be canceled if the time spent counting down backoff exceeds the TransmissionTimeout originally specified in theMAC-ASYNC-DATA.request primitive.

SuggestedRemedy:
Change this paragraph so it reads "...across superframes and is not reset with each beacon. If the total time elapsed since the frame was queued for transmission has exceeded the transmission timeout specified for the frame, the backoff counter shall be reset and the attempted tranmission shall be canceled."


Comment:
Reassembly of fragmented data is not supportable, practically speaking, if aMaxTransferUnitSize is set to 65535 octets and the MAC must reassemble at least 8 isochronous streams and 1 asynchronous "stream". The amount of memory required by an implemention for reassembly alone would be 9*(655535) - 9*(2044) or roughly 571,000 octets. aMaxTransferUnitSize should be limited to match the MTU for the 802.15.3 since this is larger than any probable implementation of the standard will use.

SuggestedRemedy:
For the 2.4GHz PHY, change aMaxTransferUnitSize to 2044 in Table 56 on page 215. Given this size, the amount of memory required to reassemble 9 streams is approximately a minimum of 18,400 octets. Also see another comment regarding fragmentation thresholds.


Comment:
Presently the standard doesn't provide a minimum fragment size. One effect is that some implemention might cause severe channel usage inefficiency with multiple small fragments. An undefined fragment size also complicates the design of memory management data structures in an implementation. In addition, although a "fragmentation threshold" is mentioned in this subclause, it doesn't appear to be a PIB object or a MAC sublayer parameter. Each DEV should publish its desired fragmentation threshold during association since different implementations will have varying needs, and the PNC should circulate these values to each DEV in the piconet using beacon MMPDUs.

SuggestedRemedy:
Add a MAC sublayer parameter "aMinFragmentSize" in Table 56 on page 215, and set this to 128 (octets). If fragmentation is in use, DEVs may not transmit frames (except the last) with payloads smaller than this value. Also change the definition of the "Capability" field in association and beacon MMPDUs, as defined on page 126 in Figure 36, by using bits b8-b5 and naming this field "FragmentationThreshold". DEVs must store and use this information on a per-destination DEV basis, fragmenting any frames sent to the DEV when a frame's payload exceeds FragmentationThreshold octets. This relationship holds: aMinFragmentSize <= FragmentationThreshold <= aMaxFrameSize. All fragments except the last shall be sent using the same fragment size.


Comment:
Require some minimum ability to handle interleaved defragmentation from multiple DEVs transmitting asynchronous MSDUs.  This becomes important, for example, during the CAP when part of an MSDU has been received from one DEV and a new MSDU's fragment burst is received from another DEV.  Without support for multiple defragmentation buffers the first MDSU would be lost.  802.11 requires the ability to handle three, and that's probably a reasonable number for 802.15.3.

SuggestedRemedy:
I suggest the following text be added:  "A DEV shall support concurrent reception of fragments of at least three PDUs."


Comment:
The frame exchange sub-clause doesn't say anything, isn't complete and doesn't have any formal languages.  It is also redundant.


Comment:
The definition of RIFS was changed and so it no longer applies to the backoff procedure.

SuggestedRemedy:
Add a new timing parameter called aPHYSlot = SIFS + aCCADetectTime and use it instead of RIFS in the backoff procedure.  Modify clause 11 to match this new usage.

Response:
ACCEPT IN PRINCIPLE. Add a new timing parameter called BIFS = SIFS + aCCADetectTime and use it instead of RIFS in the backoff procedure.  Add BIFS - backoff interframe spacing to the acronyms clause. Modify clause 11 to match this new usage.


Comment:
The use of originator and target are confusing in this case.  Replace originator with SrcID and target as DestID here, in clause 7 and clause 6.


Comment:
The PNC handover description and MSC do not include any of the security related operations.

SuggestedRemedy:
Add text describing how the PNC handover is performed in a secure piconet and fix the MSC as appropriate. This should include a new command to pass ACL information to other DEVs in the piconet to facilitate future authentications if the PNC desires to send this information.


Comment:
[Scan] Change this sentence fragement <from> "...in either the MLME-SCAN.request or MLME-START.request." <to> "...in the MLME-SCAN.request."  Since the PNC capable DEV no longer does multiple channel scanning when starting up its piconet.


Comment:
Change this sentence frag. <from> "...via the MLME-SCAN.confirm or MLME-START.confirm." <to> "...via the MLME-SCAN.confirm."  Again this is because the PNC capable DEV no longer performs a multiple channel scan as part of the start process.


Comment:
Change the tense of the following sentences:- Become... -> Becoming a child or neighbor...- Reduce... -> Reducing the piconet's transmit power...Makes for more gramatically correct sentences.


Comment:
Delete the sentence starting with: "Channel change after the piconet..." is an unnecessary redundancy of the sentence in line 22.


Comment:
Move the start of this clause to the top of the next page.


Comment:
change this sentence frag. <from> "...and be prepared to receive the list of DEV information list, {xref 7.5.4.2}, ..." <to> "...and be prepared to receive the DEV information list,..."


Comment:
Please change this sentence frag. <from> "...All DEVs with asynchronous data to send needs to reissue..." <to> All DEVs with asynchronous data to send need to reissue..."


SuggestedRemedy:
Replace text on line 40-45 with new text in:02276r7P802-15_TG3-commentsD11_KO.doc, Resolution [14]


Comment:
[Scan/Remote] The parent DEV address is no longer broadcast in the beacon. Consequently, delete lines 4-6 from this subclause.

Response:
ACCEPT IN PRINCIPLE. Change the field to be the Parent BSID IE, length 8-34, change the text to be: The parent BSID IE is the address from a parent BSID IE, 7.4.3, found by the DEV in a beacon. If the DEV found only a frame and did not find a beacon, it shall include a zero length parent BSID IE. Change the length of the Piconet BSID IE to be 8-34.


Comment:
[CTM/IsochMSC] This MSC is the behavior of an asynchronous request!/KO

SuggestedRemedy:
Delete Figure 110. Asynchornous reservation already has an MSC in Figure 116.


Comment:
MSC has wrong reason code for primitiveMLME-MODIFY-STREAM.cfm.It should be same as in Table 18, page 69/KO


Comment:
"ACK mechanism" is not a defined term/KO

SuggestedRemedy:
Change "Dly-ACK mechanism" to Dly-ACK Policy".


Comment:
[ACK/Dly] Missed from 02/276r6 Resolution [01]. If destination refuses Dly-ACK,the source MLME shall pass DLY-ACK-FAILED up to its DME/KO

SuggestedRemedy:
Add text:The source upon reception of the Imm-ACK shall send a MLME_ISOCH_DATA.confirm with the ResultCode set to DLY_ACK_FAILED to the FCSL. This implies acknowledgment of the data frame and additionally indicates that the dly-ACK policy has been refused by the destination.


SuggestedRemedy:
First sentence on line 12 says the same as the paragraph on line 7ff.


Comment:
[ACK] Dly-ACK and Imm-ACK works the same/KO

SuggestedRemedy:
Change text to read:During the time slots within a CFP when an Imm-ACK or Dly-ACK is expected...


Comment:
[PNID] Filtering must also be done on PNID

SuggestedRemedy:
Change text "and retry bit" to ", retry bit and PNID"


Comment:
[ParmChng] Two errors in text, dependent PNC shall copy parent IE andthe trigger for changing channels is ChangeType=CHANNEL/KO

SuggestedRemedy:
See resolution for 8.10 in02276r7P802-15_TG3-commentsD11_KO.doc, Resolution [11]


Comment:
[ParmChng] The whole paragraph on line 16-19 is residue from old text and totallywrong now/KO

SuggestedRemedy:
Delete paragraph on line 16-19 "If the PNC decides to change PNID or BSID......value within the time-out duration and wait for beacons with the newPNID or BSID"


Comment:
This text is applied only to BSID and PNID, but is true forall piconet parameter changes.

SuggestedRemedy:
Generalize text on line 21-22 and move to 8.10.


Comment:
[ChnlChng] Several errors in 8.11.1. Wrong method to let dependent PNC stay onchannel or move by itself. Also wrong time for when channel change occurs. Superframe following beacon 0 should be on old channel tomaintain data services/KO

SuggestedRemedy:
See resolution for 8.11.1 in02276r7P802-15_TG3-commentsD11_KO.doc, Resolution [11]


Comment:
[PM/PSPS] Some parts of 02/276r6 resolution [14] missed regarding PSPS.MSC in Figure 207 has old PSAVE name./KO

SuggestedRemedy:
See resolution for 8.13.1 in02276r7P802-15_TG3-commentsD11_KO.doc, Resolution [14]


Comment:
[PM/SPS] The fairest way to enable implementations of both very simple DEVsand DEVs with better powers save features is to make both SPS and PSPSoptional. I have provided the mechanism to assign PS capabilities inthe capability field and use it as a high priority selection criteriaduring handover. As always, the market will decide and we will provide./KO

SuggestedRemedy:
Delete sentence on line 6-7:"The PNC shall support at least one SPS set when the PNC is battery powered and support at least four SPS sets when the PNC is powered by thealternating current mains, Table 51"


Comment:
[FrmSeq] This table is wrong, it repeats the same sequence with different numbersof frame exchanges. Besides, what's the purpose of the table?It may have been of interest if we listed the exact frame exchangeslike they attempted in 802.11-1999, Table 21 and 22, page 96(but they also got it wrong!) /KO

SuggestedRemedy:
Delete table. It could be fixed, plus it unnecessary.


Comment:
[PM/SPS] Change this sentence frag. <from> "... do not cause the beacon or extended beacon..." <to> "...do not cause the beacon to exceed its max. ..."The reason for this requested change is since we no longer fragment the beacon. We agreed to use the PNC info command to pass additional DEV related info .


Comment:
[PNCHndOvr] Make these corrections to the MSC:1) There are two DEV-2 MLMEs. Replace the one furthest to the right with a DEV-2 DME.2) The MLME-PNC-INFO.cfm is incorrect. Replace it with an MLME-PNC-INFO.ind. Confirms are only used when a service layer receives a request from the layer above it.  An indication is used when an unexpected signal is received.3) Remove the MLME-NEW-PNC.ind primitive directed from the PNC MLME to the PNC DME.  The PNC does not need to tell itself that there is going to be a new PNC. It already knows that.


Comment:
The PNC shutdown information element referenced from this clause does not contain a field for the child DEVID.  I'm going to assume that the text is correct and that Figure 29 in 7.4.5 is incorrect. Consequently, add the DEVID field to the PNC shutdown IE in 7.4.5.  Are there any other fields that need to be added?


Comment:
[BSID] Change this sentence frag.: <from> "...remove the parent PNC DEV address element from ..." <to> "...remove the parent PNC BSID element from ..."  This change is necessary since the PNC no longer broadcasts its DEV address in the beacon.

Response:
ACCEPT IN PRINCIPLE. Change this sentence frag.: <from> "...remove the parent PNC DEV address element from ..." <to> "...remove the parent BSID IE from ..."


Comment:
The PNC shutdown information element referenced from this clause does not contain a field for the neighbor DEVID.  I'm going to assume that the text is correct and that Figure 29 in 7.4.5 is incorrect. Consequently, add the DEVID field to the PNC shutdown IE in 7.4.5.  Are there any other fields that need to be added?


Comment:
Change this sentence fragment <from> "For piconet that does not ..." <to> "For a piconet that does not..."


Comment:
Delete this sentence fragment: "..., due it not being on the ACL."  It is redundant with the beginning of the sentence starting at the end of line 25, and it is simply poor grammar.


Comment:
Change this sentence frag. <from> "...all of them will try to ACK and collide." <to> "...all of them would try to ACK and collide."


Comment:
Change this sentence frag. <from> "The association process does wait for the piconet services..." <to> "The association process does not wait for the piconet services..."


Comment:
Please change this sentence frag. <from> "...,if requried, authentication..." <to> "..., if required, authentication..."


Comment:
Change this sentence fragment <from> "..., the DEV may a the probe commands without..." <to> "..., the DEV may use a probe command without..."


Comment:
[CTM/Isoch] Figure 108, which I am assuming is based on the text located on page 179, L19-30, is an incorrect representation of the text. The text describes what happens when either of these error conditions "channel time unavailable" and "Priority unsupported" are present. Given these conditions, the MSC in Figure 108 should be modified as follows:1) Delete the Evaluate request symbol from the PNC MLME column.2) Delete the Allocate resources symbol from the PNC MLME column.3) Move the channel time response command to just below the Check resources symbol, since this is where the decision regarding the two error conditions is determined. Also move the ACK up in the diagram as well.4) Move the MLME-CREATE-STREAM.cfm primitive to just below the starting point of the ACK to the channel time response command. In addition the Evaluate Request symbol should be moved from the PNC MLME column to the PNC DME column.


Comment:
[CTM/Isoch] Please give me a break.  This MSC illustrates a flawed understanding of the stream creation process and how it is related to the MAC-ISOCH-DATA.req primitive.  Figure 110 is so bad that there is no point in trying to use text to describe what needs to be done to correct it.  So remove it, dig a hole, and bury it.

SuggestedRemedy:
I will provide a correct version of Figure 110.


Comment:
The caption for this figure is not clear.  Change the current caption <from> "MSC of destination DEV-3 requesting termination of its stream." <to> "MSC of target DEV-3 requesting termination of source DEV-2's stream."


Comment:
[CTM/Isoch] So the PNC MLME is going to spontaneously initiate a stream termination?  Does this make sense? Hello???  Add the MLME-TERMINATE-STREAM.request and the MLME-TERMINATE-STREAM.confirm to the MSC.


Comment:
[CTM/AsynchMSC] Please give me a break.  This MSC illustrates a flawed understanding of the asynchronous channel time reservation process and how it is related to the MAC-ASYNCH-DATA.req primitive.  Figure 116 is so bad that there is no point in trying to use text to describe what needs to be done to correct it.  So remove it, dig a hole, and bury it.

SuggestedRemedy:
I will provide a correct version of Figure 116.

Response:
ACCEPT IN PRINCIPLE. Correct the figure as indicated in CID 51.


Comment:
Change this sentence frag. <from> "...for each of the target DEV."  <to> "...for each of the target DEVs."  Makes for a more grammatically correct sentence.


Comment:
Change this sentence fragment <from> "...both types of asynchronous allocations and the PNC shall..." <to>  "...both types of asynchronous allocations.  In addition, the PNC shall..."


Comment:
[PNCHndOvr] Some errors in text remain or were introduced after LB17.MSC in Figure 91 is also wrong./KO

SuggestedRemedy:
Text changes for 8.2.3 and ne MSC for Figure 91 are all collected in:02276r7P802-15_TG3-commentsD11_KO.doc, Resolution [03]


Comment:
[ACK/No-ACK] Replace all instances of "ACK request" in this clause with "ACK policy"


Comment:
[PNCHndOvr] Again: It is not the number of GTS that is the limiting factor of a PNC,it's the number of CTRB it can support.In some superframes a CTRB doesn't lead to a GTS -> subratesSometimes a CTRB leads to multiple GTS -> superrateSometimes a CTRB only leads to one instance of a GTS -> asynchronousSometimes a CTRB is split into GTS due to CT availability./KO

SuggestedRemedy:
Change table entry 5 from "Max number GTS" to "Max number of CTRB".


Comment:
[ACK/Imm-ACK] Replace all instances of "ACK request" in this clause with "ACK policy"


Comment:
[PNCHndOvr] When chosing a DEV for voluntary or forced handover, one of the mostimportant parts is support for power save. A new PNC shall be selectedin order of how advanced powersave it supports/KO

SuggestedRemedy:
Add Table entries on 4th place, after PSRC:4, SPS bit in Capability field, SPS=1 is preferred5, PSPS bit in Capability field, PSPS=1 is preferred


Comment:
[ACK/Dly-ACK] ??? Replace all instances of "Dly-ACK request bit" with "Dly-ACK policy bit"

Response:
ACCEPT IN PRINCIPLE. On line 36, change "Dly-ACK request bit" with "Dly-ACK policy and the DlyACK request bit" , same change on line 48.


Comment:
[DepPN/Child] Two errors:1) Parent DEV address should be replaced by Parent BSID2) A parent PNC may refuse creation of a child piconet because it cannot support it. Just replying lack of channel time may cause the aspiringchild PNC to try again in vain (ref. 02/276r6 resolution[18])./KO

SuggestedRemedy:
Line 48: change "DEV address" to "BSID"Add text:If the PNC rejects the fromation of a child PNC for any other reason thaninsufficient channel time, it shall send the channel time response commandwith the reason code set to 'Child piconet unsupported'.


Comment:
Change this sentence frag. <from> "Any frame may be attempted at most ..." <to> "Any frame may be transmitted at most..."


Comment:
[DepPN/Neighbor] Text for rejection of neighbor piconet needs improvement.Confusion between parent and neighbor PNC. Besides, there isonly one reason code to reject a neighbor PNC!/KO

SuggestedRemedy:
Change text from:"If the request was rejected, 7.5.1.2, depending on the reason code, theneighbor PNC capable DEV may retry the request at a later time. If thereason code in the rejection indicates that neighbor piconets are notsupported, the neighbor PNC capable DEV should not retry the request while that DEV is PNC of the parent piconet"To:"If the request was rejected, 7.5.1.2, the parent PNC shall respond with an assoictiation response command with the ReasonCode set to'neighbor piconet unsupported'.


Comment:
[PNCInfo] The "Last" bit fields were removed during comment resolution in favor of the fragmentation functionality all ready available in this draft.  Consequently, remove the "Last" bit fields from the MSC.

SuggestedRemedy:
Please make the indicated changes to the requested figure.


Comment:
[BSID] Beacon doesn't contain PNC DEV Address anymore, it contains BSID/KO

SuggestedRemedy:
Change "parent PNC DEV address element" to "parent PNC BSID element".

Response:
ACCEPT IN PRINCIPLE. Change to "Parent BSID IE"


Comment:
Change this sentence frag. <from> "...respond with a probe command, 7.5.4.3, with its response..." <to> "...respond with a probe command, 7.5.4.3, containing its response..."


Response:
ACCEPT IN PRINCIPLE.  Change to "Parent BSID IE"


Comment:
[Probe] Remove the MLME-PROBE.cfm primitive from its current position in the MSC. It would be the correct position if DEV-2 was just returning the information that DEV-3 was requesting. However, in this MSC it(DEV-2) is, in addition to returning the requested information, requesting information from DEV-3.  Consequently, the request to remove the MLME-PROBE.cfm primitive from its current position.  However, it does make sense to place it just after the last ACK in the sequence.


SuggestedRemedy:
Change text from "PNC shall send the piconet services command..." to"PNC shall send the probe command..."


Comment:
Move the two paragraphs in this subclause to after Table 53 on page 197. Also change the sentence fragment located at Line 46 <from> "...based on the results of attempted data..." <to> "....based on the results of an attempted data..."


SuggestedRemedy:
Change "the DEV may a the probe" to "the DEV may send the probe"


Comment:
Change this sentence fragment <from> "...,including of all of its child and neighbor piconets." <to> "...,including all of its child and neighbor piconets."


Comment:
Text here that belongs to modification/KO

SuggestedRemedy:
Delete sentence "DEVs may request a change in a pseudo-static GTS..."


Comment:
[ChnlChng] Replace the first paragraph of 8.11.1 starting at line 30 and ending at line 35 with this text: "The PNC may intiate dynamic channel selection, if it determines the conditions of the current channel in which it is operating are unsatisfactory and that there exist one or more other channels with better characteristics. The PNC has three mechanisms, at its disposal, to determine its current channel condition. These mechanisms are:1) Requesting one or more member DEVs to report their channel status information as described in {xref: 8.9.3} via the channel status response command {xref: 7.5.6.2}.2) Requesting one or more member DEVs to perform a remote scan {xref: 8.9.4} of the current channel and reporting their results via remote scan response commands {xref: 7.5.6.4}.  3) Performing self scans of the current channel as described in {xref: 8.9.5). In addition, the PNC may use the remote channel scanning and PNC channel scanning procedures to determine whether the conditions in other channels are better than the conditions in its current channel.The algorithm for deciding whether to change channels, is outside the scope of this standard.

SuggestedRemedy:
Please make the requested changes for these reasons:1) The text is better organized, 2) easier to understand, and 3) much more succinct.


Comment:
[ACK] The sentence about ACKPolicy should be deleted. It is irrelevant anddoesn't belong here. The DEV receives an ACK if it asked for it!/KO

SuggestedRemedy:
Delete sentence:"The requesting DEV would not expect the PNC to respond to the CTR unless..."


Comment:
[ChnlChng] The second paragraph of subclause 8.11.1 is technically a mess.  It inserts a description of the PNC's self channel scanning procedure into the middle of a description regarding the channel change procedure.  It would be much better to seperate these two procedures into seperate subclauses: a) 8.9.5 PNC channel scanningb) 8.11.1 Dynamic Channel Selection.Consequently, perform these three operations:1)Move all of paragraph 2 (Lines 37-42) to a new subclause 8.9.5 PNC Channel Scanning.2) delete the first two sentences of paragraph three (lines 44-45) they will become unnecessary.3) Add this sentence at the beginning of paragraph 3, subclause 8.11.1. : "If the PNC determines after performing its own scan of other channels, or requesting member DEVs to perform remote scans on its behalf that there are one or more other channels with better characteristics than exist in its current operating channel, then the PNC may decide to initiate the dynamic channel change procedure. In the case where the PNC decides to initiate a dynamic channel change, the PNC shall broadcast the piconet parameter change information element,7.4.6, in its current channel via its beacon for up to a NmbrOfChangeBeacons. ..."


Comment:
[MTS] The MTS stream ID is sufficient to identify an MTS in the CTA since thatID shall not be used for anything else.

SuggestedRemedy:
Change first sentence to:"Management Time Slots (MTSs) are identical to GTSs except that the streamindex is set to the MTS stream index, 7.2.5"


Comment:
Missing xrefs: at these lines:Line 19:  at the end of item c) ... {xref: 8.11.1}Line 20: at the end of item d) ... {xref: 8.11.2}Line 25: at the end of item a) ... {xref: 8.11.1}Line 26: at the end of item d) ... {xref: 8.11.2}Sentence Modification at lines 22-23:Change this sentence frag. <from> "...or another wireless network operating in the channel or overlapping with the current channel, two of the methods that the PNC may mitigate the interference are:" <to> ... or a non 802.15.3 wireless network operating in the PNC's current channel or an overlapping adjacent channel, the PNC may use either of these two interference mitigating methods:


Comment:
[MTS] MTS interval may be requested, as agreed in Schaumburg(ref 02/276r6 Resolution [19]/KO

SuggestedRemedy:
Add text:A DEV May request MTS allocation more or less often my sending a Channel Time Request command to the PNC with the Stream Index set to the MTS stream index, 7.2.5, and the CTR-Interval, 7.5.5.1, set to the DEV's desired interval for dedicated MTS. All other parameters of the CTRB shall be set to 0 and may be ignored by the PNC upon reception.


Comment:
[Scan/PNC] Subclause 8.11.1 Paragraph 2 Line 37-45 makes reference to a PNC scanning procedure which is incompletely defined in clause 8.11.1.  Consequently, use this text describing the PNC's procedure for determining the piconet's channel quality: <New text>:8.9.5 PNC channel scanningPNC channel scanning is a procedure by which the PNC may determine the channel characteristics of not only its current operating channel but also the channel characteristics of one or more alternate channels.  The PNC may use the results of its channel scans to determine whether the current channel in which it is operating has acceptable  characteristics or there is one or more other channels with better channel characteristics than its current channel.  If the characteristics of the current channel are acceptable, the PNC shall continue operating its piconet in the current channel.  If, however, the channel characteristics are unacceptable, and there exists one or more alternate channels with better characteristics than the current channel, the PNC may initiate a dynamic channel change {ref: 8.11.1} to a channel with better channel characteristics. The algorithm for determining when to change channels is outside the scope of this standard.The PNC may optionally allocate CTAs to itself such that there is quiet time during the superframe for it to scan its current channel for other 802.15.3 piconets,  non 802.15.3 wireless networks, or interference. If the PNC, after scanning its current channel, determines that the channel characteristics are unacceptable, the PNC may initiate channel scans of one or more other channels to determine whether there is an alternate channel with better characteristics than its current channel. While performing a scan of an alternate channel, the PNC shall not transmit a beacon for one or more beacon intervals. The PNC shall not suspend beacon transmissions for more than twice aMinChannelScan. The PNC, upon returning to its current channel and resuming the transmission of its beacons, shall increment the beacon number field by the number of beacons not sent during the time the PNC was scanning one or more alternate channels. The algorithm used to determine whether the characteristics of an alternate channel are better or worse than the current channel characteristics is outside the scope of this standard. The PNC after scanning its current channel and other channels may decide upon one of these actions:1) do nothing since the PNC determined that none of the alternate channels were better than its current channel2) initiate the dynamic channel change procedure described in {xref: 8.11.1}3) increase/decrease the Max Tx power level of the piconet {xref: 7.3.1, 8.11.2.1}4) initiate some other unspecified vendor specific action.


Comment:
Change this sentence frag. <from> "... for the CAP, beacon, MTSs, ..." <to> "... for the CAP, beacon, and MTSs, ..."


SuggestedRemedy:
Add text:If the request is for a private pseudo-static GTS, and the PNC does not support the creation of a child piconet, it shall respond with thereason code set to 'child piconet unsupported'.


Comment:
Change this sentence frag. <from> "...in the piconet maximum transmit power IE in the beacon." <to> "... in the piconet maximum transmit power subfield of the piconet synchronization parameters field in the beacon."


Comment:
Change this sentence frag. <from> "In order to determine what rates ..." <to> " In order to determine which rates..."


Comment:
Change this sentence frag. <from> "If Dly-ACK mechanism is used,..." <to> "If the Dly-ACK mechanism is used,..."


SuggestedRemedy:
Replace text on line 14-17 with new text in:02276r7P802-15_TG3-commentsD11_KO.doc, Resolution [14]


Comment:
[ChnlChng/MSC] The MSC for changing piconet parameters is flawed. Please make these changes:Place a hexagon spanning the PNC DME and MLME columns just below the last beacon w/Piconet parameter change IE and just above the first beacon(on new channel).  The text in the hexagon shall be: "PNC moves to new channel"Extend the current "DEV moves to new channel hexagon so that it spans both the DEV-1 MLME and DME columns.


Comment:
[PM/SPS] CID 365 from LB17 is still not fully resolved. This item raises numerous questions regarding protocol issues that the SPS power managment scheme has yet to address.  Consequently the issues it raised during LB17 are still valid for LB19.  For instance:a) A DEV can join several SPS but how does it know when to be awake? b) How do you broadcast a frame to DEVs which are in different SPS sets? c) What are you supposed to do with "suspended CTA?"? d) How do transmitters know when an intended receiver is awake? e) How does it fit  with ATP? With pseudostat? with subrate?  f) How is PNC supposed to calculate available CTA when DEvs of different SPS may end up with all their CTA needs in the same superframe at some intervals? "

SuggestedRemedy:
1) Please provide answers for the questions above or 2) Just make the SPS pwr mgt. scheme optional.


SuggestedRemedy:
Point the ACK arrow to the left, not the right


Comment:
The Association and open MTSs add complexity (new slot type and slotted aloha) and are less efficient than a using a CAP (the size of the CAP access slot is 16 us and the MTS access slot >116 us).  The multiple access element should be periodic.

SuggestedRemedy:
Eliminate open MTSs and association MTSs, but allow subrate CAPs and keep the ability to ask for more frequent CAPs.   A prdictable subrate CAP will allow DEVs to schedule transmissions.  Remove all text references to MTSs associtated with these slots.


Comment:
If open MTSs are eliminated, this refernce is not needed for MTS and is needed for variable rate CAP's

SuggestedRemedy:
Change ro requesting a change in the frequency of CAP's. Alter the channel time request mechanism to allow adjustment of CAP period, not below a subrate of 1 per n superframes.


Comment:
"Management Time Slots (MTSs)are identical to GTSs except that the PNCID is either the SrcID or the DestID in the CTA and the stream index is set to the management stream index,7.2.5."  A directed MTS is not a special kind of GTS.

SuggestedRemedy:
Define what the management stream index indicates for a GTS slot and indicate that either the PNID may be used to communicate with the PNC or the PNC may create a GTS slot to communicate with a DEV.  Eliminate MTS as separate directed GTS slot type and alter references made to directed MTSs to GTSs to or from the PNC.


Comment:
Slotted aloha is less efficent use of channel time then the access method used for CAP by a factor of 10.  It adds complexity without any additional functionality.

SuggestedRemedy:
Eliminate slotted aloha and this entire section. (If open MTSs are eliminated, this is by definition)


SuggestedRemedy:
Change refernces from MTS slots to CAP or to GTS slots as appropriate. Eliminate the term MTS.


Comment:
directed MTSs reference to power control should be changed.

SuggestedRemedy:
Chanage to GTSs with a DEV as SrcID and the PNC as the DestID.


Comment:
In removing implict stream resumption when changing from SPS to ACTIVE mode, too much inefficiency was introduced for DEVs that need to restart ACTIVE mode streams quickly.

SuggestedRemedy:
Still in the spirit of our compromise: Allow the mode change command along with one or more CTRs to occur anywhere that multiple CTRs are currently allowed. Require that the mode change command be the first command in the sequence. The result: switching to ACTIVE mode and starting an ACTIVE stream becomes efficient.


Comment:
The powering down between awake beacons is spoken of as mandatory.

SuggestedRemedy:
See text changes in Schrader-LB19-T1.doc


Comment:
A countdown counter for PSPS requires more PNC overhead than is necessary. The improved implementation shouuld be used for both SPS and PSPS.

SuggestedRemedy:
The Next Awake Beacon value must be update only once per awake beacon interval. The countdown must be updated every beacon.  The Next Awake Beacon can have the same number of bits as the countdown timer.   If the awake beacon is to be "pushed" to the next super frame, the Next Awake Beacon can be set to the beacon number of the next superframe. BOTH SPS and PSPS should have this.


Comment:
PSPS can be made more powerful by giving the PNC an SPS Set

SuggestedRemedy:
By allowing a DEV to use the SPS set controlled by the PNC (a.k.a. PSPS), the DEV can obtain subrate channel time using the same rules that apply to other SPS sets.  Even if the PNC can change the awake interval, it still may be of value to some DEVs to use this.


Comment:
SPS should be optional for all PNCs.  This is an open issue from LB 12 and 17.


SuggestedRemedy:
Change "due it not being" to "due to it not being"


SuggestedRemedy:
Change "one or more probe command" to "one or more probe commands"


Comment:
MACPIB_CurrentBeaconNumber first used here with implication that it is an element containted in the MAC PIB. However, other than the references in 9.2.9.1 and 9.2.9.2, it does not exist.

SuggestedRemedy:
Add MACPIB_CurrentBeaconNumber at the appropriate place in clause 6.5.


Comment:
MACPIB_PNCSECID first used here with implication that it is an element containted in the MAC PIB. However, other than the references in 9.2.9.2, it does not exist.

SuggestedRemedy:
Add MACPIB_PNCSECID at the appropriate place in clause 6.5.


Comment:
MACPIB_ValidBeacon first used here with implication that it is an element containted in the MAC PIB. However, other than the references in 9.2.9.2, it does not exist.

SuggestedRemedy:
Add MACPIB_ValidBeacon at the appropriate place in clause 6.5.


Comment:
Xref to Figure 167 placed in the wrong place in this sentence.

SuggestedRemedy:
Place the xref to Figure 167 following the text "the CCM nonce" as ",as shown in Figure 167,".


Comment:
CurrentBeaconNumber used in this clause but has not been defined.

SuggestedRemedy:
Either replace CurrentBeaconNumber with the appropriate replacement or propoerly define CurrentBeaconNumber where appropriate.

Response:
ACCEPT IN PRINCIPLE. Change "it shall verify that the beacon number is greater than the MACPIB_CurrentBeaconNumber, that the SECID matches the MACPIB_PNCSECID stored in the MAC PIB and that the integrity code passes. If all of these checks succeed, the DEV shall set the MACPIB_CurrentBeaconNumber to the received beacon number value and set the MACPIB_ValidBeacon to valid. If the beacon number is greater than the MACPIB_CurrentBeaconNumber, but the SECID does not match the MACPIB_PNCSECID, the device may set the MACPIB_CurrentBeaconNumber to the value in the beacon and send a key request command to the PNC to obtain the new key."
to
"it shall verify that the beacon number in the beacon is greater than the LastKnownGoodBeaconNumber, that the SECID matches the MACPIB_PNCSECID and the integrity code passes. If all of these checks succeed, accept the beacon number in the beacon as the LastKnownGoodBeaconNumber. If the beacon number in the beacn is greater than the LastKnownGoodBeaconNumber, but the SECID does not match the MACPIB_PNCSECID, the device may set the LastKnownGoodBeaconNumber to the value in the beacon and send a key request command to the PNC to obtain the new key."
Delete "stored in the MACPIB_CurrentBeaconNumber in the MAC PIB" from line 16 on page 221.
On page 220, line 41, Change "greater than the CurrentBeaconNumber and less than the CurrentBeaconNumber + aMaxBeaconChange." to "greater than the LastKnownGoodBeaconNumber and less than the LastKnownGoodBeaconNumber + aMaxBeaconChange."


Comment:
We should specify that commands that fail IC check should be ignored.  Sometimes they aren't (e.g. beacons).


Comment:
We still don't have a good description of what to do with commands sent or received with security on.  Also need to generalize for the case of peer-to-peer security.

SuggestedRemedy:
Add description including peer-to-peer security.


Comment:
There is really only two security modes, no security and encryption with authentication.  Mode 3 is just a different authentication procedure, like the OIDs in mode 2.

SuggestedRemedy:
Change the draft to be only 2 security modes with multiple, optional authentication methods determined by the OIDs.


Comment:
After the authentication process has been completed, all security suites behave in an interoperable manner.

SuggestedRemedy:
Text should be added to clause 9 indicating that a PNC may support multiple security suites in the same piconet.


Comment:
The probe command will not function as specified in this sub-clause, as the recipient device will assume that the public-key information being sent belongs to the old PNC, not the new PNC.

SuggestedRemedy:
Change this paragraph to reference a new command that may be sent to pass ACL information to other DEVs.


Comment:
Devices cannot ensure a successful authentication.

SuggestedRemedy:
Remove first sentence and begin second sentence with “Before the authentication process is initiated, the DEV or PNC may choose to ...”


Comment:
The ReasonCode specified here is not specified as a choice in the MLME-SECURITY-ERROR sub-clause.

SuggestedRemedy:
The ReasonCode BAD-BEACON-NUMBER should be added to Table 14 in clause 6.3.11 or removed from this subclause.

Response:
ACCEPT IN PRINCIPLE. Reference changed to clause where correction is to be made. Add BAD-BEACON-NUMBER to Table 14, page 54, line 49 since it is referenced in clause 9.2.8 on page 220, line 33.


Comment:
The terminology in this sub-clause refers to MAC PIB entries that have been removed.

SuggestedRemedy:
This should be changed to be consistent with other descriptive text in Clause 9.


Comment:
This sub-clause overlaps with sub-clauses 9.2.7 and 9.2.8.


Comment:
The SECID is not always for the relationship between a security manager and DEV. It may be the piconet-wide group key.

SuggestedRemedy:
Change this sentence to: “The second octet shall designate a unique value for the key associated with the security relationship.”


Comment:
Table 57: It needs to be indicated either here or in clause 7 that the probe command, piconet services command and disassociate command may be sent insecurely before authentication has taken place.

SuggestedRemedy:
Add text that indicates that the probe command, piconet services command and disassociate command may be sent insecurely before authentication has taken place.


Comment:
There needs to be a clear delineation between the aspects of the certificate usage that are within scope and those that are out of scope. If we are specifying the exact format of the entity certificate, it seems that the format of the CA key and the other information should be specified as well.

SuggestedRemedy:
It should be made clear what checks, if any, are performed by the MLME and what checks should be pushed up to the higher layer.


Comment:
There is no longer a mandatory sub-suite.

SuggestedRemedy:
Change last sentence in this paragraph to: “The list of accepted security suites and sub-suites are specified in clause 10.”


Comment:
The group key does not protect all piconet data, just the broadcast piconet data.

Response:
ACCEPT IN PRINCIPLE. On line 30 change "and security manager" to "and security manager of the piconet ". On line 31 change "security manager acts as the central security point for all DEVs to obtain keying material for the piconet." to "piconet security manager authenticates DEVs for membership in the piconet and provides the broadcast payload protection key for the piconet." On line 37, change "all piconet data." to "data using the broadcast key.".


Comment:
[SEC/MSC] Non-standard sequence diagrams in clause 9. This was pointed outin LB17 but no action was taken. We cannot publish a standard withhome-brewed sequence diagrams. Hence the TR/KO

SuggestedRemedy:
Replace with MSC:Figure 140, page 228Figure 141, page 229Figure 142, page 229Figure 143, page 230Figure 144, page 230Figure 146, page 240Figure 151, page 251Figure 152, page 252Figure 155, page 255Figure 163, page 265Figure 164, page 267Replace with MSC with state represented as condition:Figure 150, page 249Figure 158, page 259Figure 159, page 262Figure 160, page 263Figure 161, page 264Figure 165, page 267Figure 166, page 270


SuggestedRemedy:
In order to maintain the security provided by this standard, care needs to be taken to protect keys from


Comment:
The way that states are numbered and and state transitions can lead to confusion and difficulty understanding the transitions.

SuggestedRemedy:
Label states 1.0, 2.0, 3.0, ... N.0 and label state transitions as n.m to indicate a transition from state n.0 to state m.0.  This impacts a lot of diagrams and text, but it would be a major improvement. Use "x" as the "any" state indicator.


Comment:
Authentication is used to provide evidence to the PNC that the DEV is authorized to join the piconet, but it also lets the PNC provide evidence to the DEV that it is authroized as a trusted PNC.

SuggestedRemedy:
Add the following to the sentence that ends with "to join the secure piconet."  New text:  and vise versa.


Comment:
Only integrity protected commands are protected.

SuggestedRemedy:
Change to "Integrity protected commands sent between..."


Comment:
Only securecommands are protected by the management keys


Comment:
Why can't a mode 0 PNC use the ACL?  I thought this is how we got rid of mode 1.  Maybe this is just an oversight.

SuggestedRemedy:
Change to "A device operating in mode 0 shall not perform any security related operations on MAC frames."


Comment:
Sorry for the TR, butr I complained about these names before and they didn't get better.  The names are inconsistent and not easy to follow

SuggestedRemedy:
Change Pub_D to Pub_key_DChange Pr_D to Pr_key_DChange Pub_SM to Pub_key_SMChange Pr_SM to Pr_key_SMChange Keys_D to Sym_keys_DChange Keys_G to Sym_keys_GChange BH to SBH and add SCH for secure command header.  Beacon and command shouldn't be lumped together.  Add CD for command Data to separate it from BD.

Response:
ACCEPT IN PRINCIPLE. Change Pub_D to Pub_key_DChange Pr_D to Pr_key_DChange Pub_SM to Pub_key_SMChange Pr_SM to Pr_key_SMChange Keys_D to Sym_keys_DChange Keys_G to Sym_keys_GChange BH to SBH and add SCH for secure command header.  Beacon and command shouldn't be lumped together.  Add CD for command Data to separate it from BD.  Use these identifiers as a guideline and update tables, text and figures in clause 9 as required.


Comment:
In LB17 I commented that MSCs were neededd Instead of or in addition to these state diagrams.

SuggestedRemedy:
Add an MSC or replace figure 148 with an MSC.


SuggestedRemedy:
Add an MSC or replace figure 149 with an MSC.


SuggestedRemedy:
Add an MSC or replace figure 150 with an MSC.


Comment:
Remove the " from the end of the paragraph.


Comment:
Since the symmetric cryptography building blocks are shared by each security suite, there is no reason to reference them in the security suites themselves.

SuggestedRemedy:
Make sub-clause 10.2.4 a stand alone section that does not relate to the security suites. Each security suite should deal only with the authentication operations and the reference to 10.2.4 from the security suites should be removed.


Comment:
Figure 168: This figure does not reflect the current version of secure beacons.

SuggestedRemedy:
This figure should be updated to match the secure beacon frame format specified in 7.3.1.2.  Better still, replace this with a cross reference to the correct figure.


Comment:
The ECMQV security suite is not presented in a similar fashion to the NTRUEncrypt and RSA-OAEP security suites. Change this security suite to better match the other security suites and/or change the other security suites to match this security suite.

SuggestedRemedy:
Recommend combining 10.3.1.1 to 10.3.1.4 into one sub-clause (making ECMQV a level 5 heading and removing the heading for ECC certificates) and combining other sub-clauses of 10.3 for clarity.


Comment:
The ECC manual certificate is simply a raw key as with the other security suites.

SuggestedRemedy:
Since the DEV address is already included in the frame, this should be changed to a raw key and the redundant Subject value should be removed.


Comment:
The symmetric cryptography operations specified in Table 89 do not describe fully what data is to be authenticated. The input to the HMAC operation is not fully specified, so interoperability cannot be achieved.

SuggestedRemedy:
Completely specify the data (and the order of the data) that is to be authenticated in the HMAC operation. This should include information from previous frames of the authentication protocol, such as the OID and the identities of each participant. Diagrams should be added to this sub-clause and the NTRU and RSA subclauses showing the data input to the symmetric key operations for the challenge response and authentication response.


Comment:
The processing of ECC manual certificates provides no security. There must be some information stored by the DEV that provides evidence of the validity of the public key. For the other raw security suites, this is achieved by requiring that the devices store the hash of the public key with the DEV address.

SuggestedRemedy:
For ECC manual certificates, require that the DEV maintain some information such as the key itself or the SHA-256 hash of the key to give the DEV evidence of the validity of the key.


Comment:
The latest draft of EESS #1 provides a parameter set that includes an encoding method that provides better provable security properties than the parameter set currently included in 802.15.3. Although the current parameter set is secure for 802.15.3 due to the fact that NTRUEncrypt is being used exclusively to encrypt random challenges, it would be desirable for future compatibility and for the use of current best practice to use the parameter set ees251ep3.

SuggestedRemedy:
Change sub-clause 10.4.1.1 to the following:10.4.1.1. NTRUEncrypt parameter set ees251ep3All NTRUEncrypt objects and cryptographic operations used in this security suite shall use the parameter set ees251ep3 as specified in EESS #1. All transmitted NTRUEncrypt polynomials shall be sent in uncompressed form as specified in EESS #1.


Comment:
10.4.2.1, 10.4.2.2, 10.5.3.1 and 10.5.3.2: The process for computing the integrity code in the challenge response and authentication response commands is different than for normal frames and there may be latency between when the frame is created and when it is sent and checked. The current beacon counter when the IC is created should be included in the frame to facilitate processing the integrity code offline (i.e. not in real time).

SuggestedRemedy:
Add the current beacon counter as part of the authentication response and challenge response, to make each a 14-byte value (6 bytes for the beacon counter and 8 bytes for the integrity code) and modify the text for computing these values to indicate that the beacon counter included in the CCM nonce is obtained from the frame.


Comment:
10.4.2.1 & 10.4.2.2: If the parameter set ees251ep3 is used rather than ees251ep1, the length of the challenges need to be changed to 20 octets instead of 21 octets.

SuggestedRemedy:
Change the length of the challenges to 20 octets and the length of the seed for the management key to 40 octets.  Verify that the challenge length is either 251 or 20 octets.


Comment:
The following issues is not addressed:  If a frame is retranmitted and even a single bit in the header is changed, a new nonce has to be used.

SuggestedRemedy:
Add the following text: "If a frame is retransmitted and a single bit in the header or frame body has changed, a new nonce shall be used.  To ensure this, each time a frame is retransmitted the secure frame counter shall be incremented."


Comment:
Should only say mode 0, not mode 0 and 1.


Comment:
The FCSL is supposed to handle DEVID<->MAC address mapping. The PNC assigns DEVIDs during association. The interface between the DME and the FCSL is undefined, but this makes Annex A very unclear because this states that the FCSL shall "[map] each received PDU 48-bit source and destination address to a corresponding 8-bit, 802.15.3 source and destination DEVID."  This paragraph should be changed to make it clear that the FCSL obtains the proper DEVID mappings from the DME, given MAC addresses.

SuggestedRemedy:
Change line 43 to read "source and destination DEVID, by communicating in an implementation-defined manner with the DME, which maintains this information."


Comment:
IN B.3 it references a to-be-published reference, which is a big no-no and quite silly.

SuggestedRemedy:
Delete the references to RFC 3280 and RFC 3278


Comment:
The title "Protocol implementation conformance statement" is incorrect.

SuggestedRemedy:
I suggest you change to "Protocol implementation conformance statement (PICS Proforma)" and add the following as a footnote "Copyright release for PICS proformas: Users of this standard may freely reproduce the PICS proforma in this annex so that it can be used for its intended purpose and may further publish the completed PICS."


Comment:
Change MLF16.2 to be 'extended beacon support, reception', "M"Add 'extended beacon support, generation', FD2: O


Comment:
It seems that the types of security support that are listed here are limited only to the methods that are explicitly defined in the standard. There may be additional methods that should be allowed and there should be a means for vendors to indicate that there are vendor specific methods implemented. For instance, certificates that are not in the format specified here, such as X.509 certificates used in browsers, may be useful to use to provide evidence of the validity of a public key while in mode 1 or mode 2.

SuggestedRemedy:
Change the ECC and RSA X.509 certificates to be simply an X.509 certificate.  The certificate indicates the method used for authentication.


Comment:
[MTS] I think the idea is that the PNC shall support at least one CAP orMTS. If so, a better notation would be to collect the two as subclausesunder MLF 12 and list support as O.1. As it stands now it's not obviouswhat the O.1 is an anlternative of.Second: only the PNC has this option, however the DEV needs to supportboth to be able to associate. In practicality it's likely that different PHY will use different options, but at a MAC level we need to specifyit in the way listed in the Suggested Remedy./KO

SuggestedRemedy:
Change to:12    - Management channel time support12.1  - CAP channel access during piconet operations       - 8.4.2 - FD1:M, FD2:O.112.2  - MTS operations - 8.4.4.4 - FD1:M, FD2: O.1


Comment:
[PM] The fairest way to enable implementations of both very simple DEVsand DEVs with better power save features is to make both SPS and PSPSoptional. I have provided the mechanism to assign PS capabilities inthe capability field and use it as a high priority selection criteriaduring handover. As always, the market will decide and we will provide./KO

SuggestedRemedy:
Change status for MLF24.2 and MLF24.3 to O


Comment:
[PM/SPS] Table E.4 indicates that PSPS is optional for all DEVs whether PNC capable or not, while the table entries for SPS indicate that SPS is optional for non-PNC capable DEVs, but mandatory for PNC capable DEVs. Given the complexity of the SPS power management scheme in terms of amount of memory required to store SPS sets and CPU processing required to manage numerous SPS sets it is inappropriate that this scheme be mandatory.  The SPS scheme imposes implementation requirements that preclude deploying simple, inexpensive, PNC capable devices.

SuggestedRemedy:
Consequently, I strongly recommend that items MLF24.2 and MLF4.3 be made optional for DEVs whether PNC capable or not. This way implementors can decide which scheme best meets their needs.


Comment:
Table E.4 indicates that PSPS is optional for all DEVs whether PNC capable or not, while the table entries for SPS indicate that SPS is optional for non-PNC capable DEVs, but mandatory for PNC capable DEVs. Given the complexity of the SPS power management scheme in terms of amount of memory required to store SPS sets and CPU processing required to manage numerous SPS sets it is inappropriate that this scheme be mandatory.  The SPS scheme imposes implementation requirements that preclude deploying simple, inexpensive, PNC capable devices.

SuggestedRemedy:
Consequently, I strongly recommend that items MLF24.2 and MLF24.3 be made optional for DEVs whether PNC capable or not. This way implementors can decide which scheme best meets their needs, rather than a minority in the 802.15.3 standards community.


SuggestedRemedy:
MLF24.2 and MLF4.3 should be made optional for DEVs whether PNC capable or not. This way implementors can decide which scheme best meets their needs, rather than a minority in the 802.15.3 standards community.


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


