# Main

Comment:
As I stated in LB19 802.15.3/D11 CommentID: #10, the title is incorrect.  Specifically, "Part 15" should be "Part 15.3".

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

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

Please make the change globally.

Additionally, and in terms of the LB19 CommentID: #10 rejection, I understand the PAR issue but I think this is a clear editorial issue and we have WG precedents to apply the editorial suggestion.  Here are some issues to consider in this rebuttal
1. The 802.15.3 PAR is incorrect and is in conflict with itself and should state the previously mentioned item in the title section i.e., "2. Assigned Project Number [P802.15.3]" or section 4 should state "...Part 15.3...". http://grouper.ieee.org/board/nescom/802-15-3.pdf
2. An example is the 802.15.1 PAR which TG3 copied and is why you have the error in the first place :).  When 802.15.1 got to Sponsor Ballot the PE said 15.1 was ok cuz (a) we had a corrigendum: http://ieee802.org/secmail/msg00600.html
and (b) implicitly it was necessary to add the dot level based on the 15.2, 15.3, 15.4, etc. approvals. http://ieee802.org/15/par.html
3. Specifically, having the 802.15.1(TM)-2002 published sets a precedent as our PAR says "Part 15..." but we are published with "Part 15.1..." http://grouper.ieee.org/board/nescom/802-15.pdf

Note: 802.15.4/D17 is in Sponsor Ballot with "Part 15.4..."
4. If you release the 15.3 Draft to Sponsor Ballot there might be an issue and someone might object BUT I think going forward w/ the title as-is is a bad idea.  For example the 3rd of the 802 five criteria "Distinct Identity" will be problematic if the IEEE titles are NOT distinct and/or inconsistent in the WPAN Standards Family: http://ieee802.org/3/rules/rules.html#P72

Note: I applied (Session #20) the latest edit to the 802.15.3a DRAFT PAR because of this very issue and after careful review of other approved Alt PHY Layer Standards and their titles: http://ieee802.org/secmail/msg02824.html
In terms of the next step I suggest you ask Jennifer Longman what her opinion is i.e., leave as-is, apply edit, submit a corrigendum to the 802.15.3 PAR, etc.
Finally, I think just from a publishing and distribution point of view it will become confusing - make the edit.  If the Editor or Chairs need to change the PAR then please do so, however, the approved IEEE Std 802.15.1-2002 states "Part 15.1" and the PAR does not.  It was not an issue for RevCom and the StdBD so it should be an easy edit to apply to keep our family of standards consistent.

Response:
ACCEPT IN PRINCIPLE. The TG will start the process to create either a corrigendum or modification of the PAR. When the title is changed in the PAR, we will change the title in the draft to match it.


Comment:
The sentence ending "...isochronous and asynchronous data types and is designed to support addtional physical layers as might be specified at a later time." is out of scope based on the PAR.

SuggestedRemedy:
I suggest ""...isochronous and asynchronous data types.".

Response:
REJECT. It is not out of scope to create a standard that is extensible.  Based on the history of IEEE standards, it is the rule, not the exception, that a MAC will be used with multiple versions of a PHY.  The statement in the abstract is true, this MAC was designed with an eye to supporting multiple PHYs.


Comment:
As weitten the paragraph "Conformance test methodology" is confusing e.g., IEEE 802.3, etc.

SuggestedRemedy:
I suggest the Editor delete the entire paragraph or add something relevant to the draft.

Response:
REJECT. This text is part of the boilerplate from the IEEE.  The text here clearly indicates how the conformance test methodology is specified for IEEE standards.


Comment:
same as comment #537 in LB12 and Comment 387 in LB19 ORIGINAL 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 LB12Commenter's response (LB22)If slotted aloha is added so that the MAC is used in other PHYs, sinceDEVs using different PHYs can not directly communicate with each otherwhy should it cause incompatibility? The new mechanisms in MAC must beadded only when a defined PHY needs it, all of which we may not knowtoday. At the time of addition of new mechanism, it has to be overlaidon the existing mechanism. and there is definitely a way to do the samewith slotted aloha as and when it is needed. For example, a set of streamindices can be left reserved and used at that time for the purposedesired.Regarding MCTA, specifically, what is not objected to is the open and association MCTAs. What prevents these things to be done in CAP insteadof devicing a new mechanism altogether for such a relatively low probability events?

SuggestedRemedy:
Remove open/association MTS/MCTA mechanism and slotted aloha mechanism and all references to them from the draft (Applicable to 8.4.4.4 and 8.4.4.5 in LB22/D14)Reserve a group of stream indices in 7.2.5 for future enhancements likethe slotted aloha so that it can be added if and when it is really needed

Response:
REJECT. The open and association MCTAs were added to handle two concerns, the first was that new PHYs may not support efficient CCA detection. In this case, slotted aloha provides a contention access method that provides for the needs of the piconet. Another reason to used slotted aloha is that under certain conditions, it can be more efficient than using the CAP. Adding a new contention method to the MAC when a PHY group has been formed is probably not the best venue. At this time, the TG has many members who have expertise in the MAC available to review draft. In the future, when a new PHY is down-selected, there may not be as many people available who have the experience and knowledge of the TG3 MAC to be able to add a new contention method. Adding slotted aloha does not add much, if any complexity, the DEV needs the random number generatora and exponential increasing backoff for any contention based method. The DEV is already required to be able to send frames and look to see if it gets an ACK. Depending on the parameters used for either the CAP or the open and association MCTAs, the power usage may actually be lower using MCTAs for the DEVs in the piconet than using the CAP. MCTAs have an advantage over the CAP in that they can be put into multiple locations in the superframe allowing the PNC to potentially use the time more efficiently.


Comment:
Same as comment 513 in LB19Comment: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. Suggested Remedy: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)Response:ACCEPT IN PRINCIPLE. Add new subclause 11.2.10, ‘Channel access methods’ with text ‘A PNC-capable DEV compliant to this standard shall allow the use of the CAP for contention based access for association, data and commands, {xref 7.3.1} when using the 2.4 GHz PHY. A DEV compliant to this standard shall support the use of the CAP when using the 2.4 GHz PHY.’Use 1 bit from the reserved bits to the ‘Piconet mode field’, ‘MCTAs used’ with definitions ‘The MCTAs used bit shall be set to 1 if the PNC will be using open or association MCTAs.’ Delete the sentence on page 111, lines 1-2, ‘If the CAP end time indicates no available time and no message types are permitted during the CAP, then MTSs are implied.’ (note this deletion is in response to CID 407).Expand MLF13 in the PICs (note this will become MLF13.1 and MLF13.2 due to another comment.)MLF13.1; Open and association MCTA operations; 8.4.4.4, 8.4.4.5; O.1MLF13.2; Regular MCTA operations; 8.4.4.4; M{ed. note: the CAP stuff is like MLF13.3 now}Commentor's response:Response to this comment do not address the core issue of an additional access mechanism(MTS and slotted aloha) in the standard. The proposal does not justify why they are needed in802.15.3. Hence the resolution is unacceptable.

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:
Change of GTS into CTA from D11 to D14 in clauses 5, 7 & 8:AT many places in clause-8, this has caused lot of confusion.For example pp-188, ln-17:18 where the first reader can easily confuse this withPNC listing the CTA information in the beacon as opposed to the GTS allocation inthat superframe. To a vetern 802.15.3-WPANer this may seem same, but they are not.CTA is only a way of providing a GTS, there may be other ways in the future. changeback all the GTS as they were in D11 in Clause 7 and 8.

SuggestedRemedy:
Revert back to the use of GTS when referring to time slot in super frame and CTA being limited to the component present in the beacon that is used to allocate a GTS to a DEV.

Response:
REJECT. The name of an element in the standard is editorial decision, not technical one. A CTA is time allocated during the superframe. A CTA block is an element in an IE that tells a DEV when the CTA is allocated, the stream index, source DEVID and destination DEVID. A collection of CTA blocks is called a CTA IE that is put into the beacon. Thus the component in the beacon is either the CTA IE or the CTA block, but never the CTA. The technical editor is considering if a change to the name for the time allocation is appropriate, but any such change is editorial and not technical.


Comment:
Change parameters from aParameterName to mParameterName and pParameterName to distinguish between MAC and PHY parameters


Comment:
Do a global search on "a MLME" and change to "an MLME"

SuggestedRemedy:
Do a global search on "a MLME" and change to "an MLME"


Comment:
The sentence beginning "Consequently the..." is incorrect.

SuggestedRemedy:
I suggest "Consequently, the..."; adding the comma.
Note that on pg 2, ln 2 the sentence beginning the same way is gramatically correct but inconsistent with the comment.


Comment:
The sentence "Compatibility and coexistence criteria were included in the proposal evaluations." is vague.  The IEEE does not mandate the use of CFAs, CFPs, evaluations, and down selections so to say "...included in the proposal evaluations." does not make sense for non-IEEE 802.15 members.

SuggestedRemedy:
I suggest adding a qualifier to the sentence such as "Compatibility and coexistence criteria were required during the 802.15.3 call for proposal evaluations and subsequent down selection to the current MAC/PHY specifications." or something similar.  Or alternatively you can add the 802.15.3 Criteria Definitions document -00/110r14 URL:
http://ieee802.org/15/pub/2000/Nov00/00110r14P802-15_TG3-Criteria-Definitions.doc
or the following CFP URL:
http://ieee802.org/15/pub/TG3-Proposals.html as a footnote to the current sentence.

Response:
REJECT. This section is only the introduction and it is not intended to be an exhaustive description of everything that went into the development of the standard.  The text in this section is based on the text from the PAR.


Comment:
Again, the text "...20 Mb/s is proposed to be the lowest rate..." and the text on the next page, pg 2, ln 14 "...20 Mb/s or more..." are from the PAR but Clause 11, Table 118, pg 313, ln 14 states "...11 Mb/s...".    It is very likely that this inconsistancy (PAR vs. Draft) issue will come up in Sponsor Ballot.  A parallel PAR change now will add mimimal to no delay to the project BUT RevCom can add 3-6 months!

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

Response:
ACCEPT IN PRINCIPLE. The current PAR only states that DEVs will support greater than 20 Mb/s, i.e. that the rate will be high enough, 20 Mb/s or more. All DEVs are required to support the 22 Mb/s mode so that this fulfills the requirment. Note that the quoted text says that 20 Mb/s is proposed to be the lowest rate, but it is not a requirement from the PAR. However, as a part of the corrigendum or PAR modification process, the TG will look at the text to see if it can be clarified.


Comment:
The sentence "This standard defines the PHY and MAC specifications for high data rate wireless connectivity with fixed, portable and moving devices within or entering a personal operating space." is gramatically incorrect.

SuggestedRemedy:
In a series of three or more terms with a single conjunction, use a comma after each term except the last.  I suggest "This standard defines the PHY and MAC specifications for high data rate wireless connectivity with fixed, portable, and moving devices within or entering a personal operating space."; adding a comma after portable.  Refer to the May00, IEEE Standards Style Manual.  Please make the change globally.

Response:
REJECT. I could not find a reference to using commas for lists in the April, 2002 style guide.  It is correct to leave this comma when it is clear what are the elements of the list.


Comment:
The normative reference "IETF 1RFC 2459:..." is incorrect.
Note:http://www.ietf.org/rfc/rfc2459.txt

SuggestedRemedy:
I suggest "IETF RFC 2459:..."; drop the stray "1" character.


Comment:
The footnotes 9 and 10 are inconsistent with the rest of Clause 2.

SuggestedRemedy:
I suggest
"9 RSA publications are available from (http://www.rsasecurity.com/rsalabs/pkcs/pkcs-1)."
"10 SECG publications are available from (http://www.secg.org)."

Response:
REJECT. In the case of the other standards the address is primary and the web address is a secondary location, hence the URL is in parentheses.


Comment:
The definition of ad hoc network is correct but inconsistent with 802.15.1-2002 and P802.15.4/D17.

SuggestedRemedy:
To minimize the entries into IEEE 100, I suggest that we standardize on the definition of ad hoc.  I suggest the Editor use the 802.15.1-2002 and P802.15.4/D17 definition: "ad hoc network: A network typically created in a spontaneous manner. The principal characteristic of an ad hoc network is its limited temporal and spatial extent.".
Note: The 802.15 definition is much shorter than the 802.11 version: "ad hoc network: A network composed solely of stations within mutual communication range of each other via the wireless medium (WM). An ad hoc network is typically created in a spontaneous manner. The principal distinguishing characteristic of an ad hoc network is its limited temporal and spatial extent. These limitations allow the act of creating and dissolving the ad hoc network to be sufficiently straightforward and convenient so as to be achievable by nontechnical users of the network facilities; i.e., no specialized "technical skills" are required and little or no investment of time or additional resources is required beyond the stations that are to participate in the ad hoc network. The term ad hoc is often used as slang to refer to an independent basic service set (IBSS)." 802.11-1999.pdf

Response:
ACCEPT. ad hoc network: A network typically created in a spontaneous manner. The principal characteristic of an ad hoc network is its limited temporal and spatial extent.


Comment:
The definition of "coexistence" is correct but inconsistent with P802.15.2/D6.

SuggestedRemedy:
To minimize the entries into IEEE 100, I suggest that we standardize on the definition of "coexistence".  I suggest the Editor use the P802.15.2/D6 definition: "coexistence: The ability of one system to perform a task in a given shared environment where other systems have an ability to perform their tasks and may or may not be using the same set of rules.".
Note I suggest the Editor synchronize with the 802.15.2 Editor to verify this definition i.e., LB21 comments and the 15.2 BRC before creating 802.15.3/D15.

Response:
ACCEPT IN PRINCIPLE. Change the definition for coexistence to match D6 of 802.15.2.


Comment:
The definition of "interoperability" is correct but sort of inconsistent with P802.15.2/D6.  D6 uses "interoperable and interworking"

SuggestedRemedy:
To minimize the entries into IEEE 100, I suggest that we standardize on the definition of "interoperability".  I suggest the Editor use the P802.15.2/D6 definition: "interoperable: The ability of two systems to perform a given task using a single set of rules."
Note that they also define "interworking: The ability of two systems to perform a task given that each system implements a different set of rules."

Response:
ACCEPT IN PRINCIPLE. Change interoperability to interoperable and use TG2's definition.


Comment:
LB17 Comment ID #1051 was not applied to D11, D12, D13, or D14.
-----------CommentID:  1051CommenterName:  Gifford, IanCommenterEmail:  giffordi@ieee.orgCommenterPhone:  +1 978 251 3451CommenterFax:  +1 978 815 8182CommenterCo:  SelfClause:  03Subclause:  3.33Page:  Line:  CommentType:  EComment:  The definition "The area of overlapping coverage between the two piconets may vary between congruent with the parent coverage area to mostly non-overlapping." is incorrect (I think).CommentEnd:  SuggestedRemedy:  Change sentence to read "The area of overlapping coverage between the two piconets may vary between congruency with the parent coverage area to mostly non-overlapping."; change "congruent" to "congruency".RemedyEnd:  Response:  ACCEPT. ResponseEnd:  CommentStatus:  AResponseStatus:  CTopic:  CreateDate:  7/3/2002LastModDate:  8/8/2002DispatchDate:  WrittenDate:  8/8/2002Accept_RejectDate:  8/8/2002Closed_UnsatisfDate:  VoterStatus:-----------

SuggestedRemedy:
Again, change sentence to read "The area of overlapping coverage between the two piconets may vary between congruency with the parent coverage area to mostly non-overlapping."; change "congruent" to "congruency".


Comment:
The sentence beginning "Aparameter..." is incorrect.

SuggestedRemedy:
I suggest "A parameter..."; adding a space.


Comment:
The sentence "A channel time allocations..." is gramatically incorrect.

SuggestedRemedy:
I suggest "A channel time allocation..."; change allocations to singular.


Comment:
Authentication and authroization are distinct.  Authentication is the process of determining that it really is the entity that it is claiming to be.

SuggestedRemedy:
Change the definition as follows:  authentication: Authentication is the process of determining that an entity really is the entity that it is claiming to be.

Response:
REJECT. In 802.11 authentication is defined as 'The service used to establish the identity of one station as a member of the set of stations authorized to associate with another station.'  802.15.3 uses 'authentication' to mean the combination of authentication and authorization, so this definition is correct from the usage in the draft.  I think it might be useful to have a proposal on an editorial change that could clean up the use of this terminology in the standard.  However, a correct change would likely touch on 4 or more clauses in the draft and could potentially lead to technical errors if it was not done correctly.


Comment:
In the PS text awake state is AWAKE state.

Response:
REJECT. That is true, but the definitions have an editorial requirement to be all lower case.  The technical editor will verify this with the IEEE project editor.


Comment:
does a frame include the HCS?  The FCS?  The praamble?  Other parts of the text cale the MAC header and payload the frame.

Response:
REJECT. The definitions are supposed to be general and not specific to this standard.  The definition of what is included in a frame for this standard is defined in clause 7.


Comment:
The acroynm or abbreviation "DLL data link layer" is incorrect and the term "DLL" is not used in D14.

SuggestedRemedy:
For starters if you are going to call out terms in Clause 4 then they should be found in the draft.  Also, I submit that for "DLL" it should be "Dynamic-Link Library" not "Data Link Layer".  Finally, if you want to create an acroynm or abbreviation for "Data Link Layer" use "Layer 2" or "L2".


Comment:
RX and TX should be Rx and Tx.  Dont mess with Texas.

Response:
REJECT. There are two conventions for this.  Some people use Tx, others use TX. This standard normally uses TX.


Comment:
The sentence ending "...membership in the piconet" is missing a period.


Comment:
The sentences "A piconet is formed when an 802.15.3 DEV that is capable of acting as the PNC begins transmitting beacons.  Thus even..." is gramatically incorrect.

SuggestedRemedy:
I suggest "A piconet is formed when an 802.15.3 DEV, that is capable of acting as the PNC, begins transmitting beacons.  Thus, even..."; adding three (3) commas.

Response:
REJECT. According to the style guide (13.2), if you can insert a comma before the 'that' it really needs to be a which.  The phrase set off by 'that' in this sentence is required for the description, so it needs to be 'that'


SuggestedRemedy:
I suggest "affect"; affect: to influence and effect: to cause.  Please make the change globally.


Comment:
The sentence "The PNC is allowed to use an access control lists (ACLs) to admit or deny entry to the piconet." is gramatically incorrect.

SuggestedRemedy:
I suggest either "...allowed to use an access control list (ACLs)..." or "...allowed to use access control lists (ACLs)...".

Response:
ACCEPT IN PRINCIPLE.  A DEV has only one access control list. Change to "The PNC is allowed to use an access control list (ACL) to admit or deny entry to the piconet."


Comment:
The sentence ending "...for that DEV" is missing a period.


Comment:
The term "trellis-code modulation" is different than the one in Clause 4 or "TCM trellis coded modulation".

SuggestedRemedy:
I suggest changing the sentence to "...while the 11, 33, 44 and 55 Mb/s use trellis coded modulation (TCM), 11.3." for consistency (Clause 4>5), accuracy (no hyphen) and first (after Clause 4) usage style rules.  Refer to the May00, IEEE Standards Style Manual.  Please make the change globally.


Comment:
The MLME-PS-SET-INFORMATION.confirm lacks a parameter for the number of PSStructureSet found in the confirm.

Response:
ACCEPT IN PRINCIPLE. Depending on the implementation, the number of sets in the PSStructureSet can be determined directly from the set itself. The MLMEs are a logical description not a precise description of an implementation. However, the technical editor will review the MLMEs and suggest a uniform method for specifying variable length fields.


Comment:
change the xref to point to 7.5.7.3 for description of next wake beacon

Response:
ACCEPT IN PRINCIPLE. Also change the reference for NumSupportedPSSets from 7.5.7.2 to 7.5.7.5


Comment:
The confirm has the PSSet operation included. The actual command lacks this.

SuggestedRemedy:
remove the PSSetOperation from the primitive.

Response:
REJECT. The PSSetOperation is used to identify a configuration request where the .request uses the unassigned set index and the response comes back with a new set index. The PSSetOperation is passed to the DME to tell it that this is in response to a prior configuration request.


Comment:
TrgtDEVAddress description is "The DEV Address of the security manager." However, this is only used in the Challenge.request command and the frame format for the Challenge.request command does not include this field.

SuggestedRemedy:
Remove from table and Challenge.request command.

Response:
ACCEPT IN PRINCIPLE. A mistake in changing the notiation, in Figure 154, change ‘ID_SM’ to be ‘AD_SM’, ‘ID_D’ to be ‘AD_D’, AD_SM is required to generate the IC that appears in the challenge request frame.’Also change name of ‘TrgtDEVAddress’ in table 11 to be ‘SMDEVAddress’ and in the challenge request command since this name is confusing. Also change ‘DEV address’ on page 139 in the figure and following text to be ‘SM DEV address’ to be clear. After discussion, the commenter agreed that this comment is editorial and not technical.


Comment:
The Key field in table 13 does not have a type, Valid Range, or Description.

SuggestedRemedy:
Use same fields as defined in Table 12: Type="Octet string", Valid Range="Any valid key as defined by the security suite, 10.2", but with Description="The key to be used as defined for the associated SECID"


SuggestedRemedy:
Change "There" to "These at beginning of sentence.


Comment:
The text that introduces Figure 3 is accurate but does not reference the ISO/IEC 7498-1 : 1994(E) normative reference in Clause 2; which I think would help the reader and is required of all Clause 2 entries i.e., "References are those normative documents that contain material that must be understood and used to implement the standard. Thus, referenced documents are indispensable when applying the standard. The role and relationship of each referenced document shall be explained in the body of the standard." IEEE Standards Style Manual.

SuggestedRemedy:
I suggest "This standard presents the architectural view, emphasizing the separation of the system into two major parts: the MAC of the data link layer and the PHY. These layers are intended to correspond closely to the lowest layers of the ISO/IEC basic reference model of Open Systems Interconnection (OSI) (ISO/IEC 7498-1: 1994). The layers, sublayers, SAPs, and management entities, described in this standard, are shown in Figure 3.
Note 1: The editor should create an xref (7498-1) to Clause 2.
Note 2: Remember "The purpose of this Reference Model of Open Systems Interconnection is to provide a common basis for the coordination of standards development for the purpose of systems interconnection, while allowing existing standards to be placed into perspective within the overall Reference Model." ISO/IEC 7498-1 : 1994(E) or ITU-T Rec. X.200 (1994 E).
Note 3: The reference model is a central figure in all 802 stds and D14 calls it out again in sc 6.7, pg 97, ln 1 - bottom line it would be a good idea to baseline the draft to the 7 layer reference model.

Response:
REJECT. Referencing the OSI model may be good but also somewhat redundant because the 802 overview documents clearly specifies that the scope of the 802 architecture is the Phy and DL layers (L2 is ETSI talk!). If we claim to be a part of 802 we cannot possibly represent anything but the two lower layers. In annex A we identify the upper layer to be 802.2 LLC (among others). Thus the standard already
clearly defines the scope. We currently give the same level of information as .11, .16 and other comparable standards.


Comment:
The sentence "If the SAP interfaces are not exposed in an 802.15.3 DEV, then these interfaces do not have to be implemented as described here. If the interfaces are exposed, then they should support the primitives described inthis clause."; is vague.  Is the term "not exposed" going to be clear to all readers?  The sc 6.1 is normative but the statement "do not have to be implemented" is informative.

SuggestedRemedy:
I suggest the Editor define the term "exposed" or provide examples for non native English speakers.  Also, I suggest the Editor and the BRC discuss the normative and informative split nature of this paragraph.  For example is it going to be clear to all readers what is required?  Does the PICS resolve, supercede, and/or complement this?  Should this sc point to the PICS annex as the final arbitrator?

Response:
REJECT. Clause 6 is normative in that it is part of the draft.  However, there is no requirement for an implementer to follow anything that is in the clause.  While exposed is not defined, the requirement is only 'should' and not 'shall'.  Thus, if an implementer feels that the interface is 'exposed' then they are encouraged to follow the clause, but they are not required to do so.  If it said 'shall', then we would need to clearly define what exposed meant.  The reality is that this will likely be an internal interface and it would be impossible to prove or disprove compliance.  The purpose of the clause is simply to give a logical view of the protocol.


Comment:
The reference to "SNMP" requires the addition of this reference to Annex F or the Bibliography.

SuggestedRemedy:
I suggest adding RFC XXX to Annex F or the Bibliography.

Response:
ACCEPT IN PRINCIPLE. IETF RFC 1157 A Simple Network Management Protocol (SNMP), May 1990 (see http://www.ietf.org).


Comment:
The column headings "Name request confirm" are incorrect.

SuggestedRemedy:
I suggest you capitalize all three (3) column titles "Name Request Confirm".  Refer to the May00, IEEE Standards Style Manual, page 19. This repeats on Table 3, etc. please make the change globally.
Note: "Only the initial letter of the first word and proper nouns shall be capitalized in Column and line headings in tables (see Table 1)" IEEE Standards Style Manual.


Comment:
The column heading "Valid Range" is incorrect.

SuggestedRemedy:
I suggest "Valid range".  Refer to the May00, IEEE Standards Style Manual, page 19.  Please make the change globally.
Note: Also, in Table 2 add periods to the first and second "description" entries to match the third entry...or delete the third entry period for consistancy.  Please make the changes globally.


SuggestedRemedy:
I suggest capitalizing columns 2-5, adding "en-dash" (from IEEE FM template (basically a long hyphen character)) to all the blank table cells, and add the word "(continued)" to the second page overflow for Table 3.  Refer to the May00, IEEE Standards Style Manual, page 19.  Please make the change globally.


Comment:
The word "piconet.l" appears to be incorrect.


Comment:
The sentence ending "...the originating MLME" is missing the period.


Comment:
The sentence "...being updated, 10." is incorrect.

SuggestedRemedy:
I suggest "...being updated, Clause 10."; that is if you mean "10" refers to Clause 10.  Please make the change globally.
Note 1: that this repeats further in the table i.e., column three last row.
Note 2: The point being that clauses are called out e.g., "Clause 10" but subclauses e.g., "10.1" are not.


SuggestedRemedy:
Again, I suggest adding "en-dash" (from IEEE FM template (basically a long hyphen character)) to all the blank table cells.  Please make the change globally.


Comment:
The sentence "An unsupported date rate..." is gramatically incorrect.

SuggestedRemedy:
I suggest "An unsupported data rate...".


Comment:
[Assoc] Capability Field is not part of the DEV association IE. Consequently, delete this parm from the MLME-DEV-ASSOCIATION-INFO.indication primitive's parm list.  After making the deletion, add DEVDataRates parm to the the list.

Response:
ACCEPT IN PRINCIPLE. The name of this field was changed from ‘capability field’ to ‘supported data rates’ so change ‘CapabilityField’ to ‘SupportedDataRates’. Add ‘SupportedDataRates’ to the table, xref 7.4.12 for valid range and type and the definition ‘The data rates supported by the associating DEV.’ After discussion, the commenter agreed that this comment is editorial and not technical.


SuggestedRemedy:
Remove second sentence about ALREADY_STARTED

Response:
ACCEPT IN PRINCIPLE. Remove the first of the duplicate sentences "If the piconet is already established, the ResultCode shall be ALREADY_STARTED. " and keep the sencond sentence "If the piconet is already started the ResultCode shall be set to ALREADY_STARTED."


Comment:
Parameter "ACLInfoSet" is called "ACL Record" in 7.5.4.4/KO


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

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


Comment:
[PM] Delete these three parms: MACPIB_PSPSSupported, MACPIB_SPSSupported, MACPIB_HibernateSupported.  These three are no longer defined in the capabilities field.  Also revamp the MACPIB_PowerManagementMode parm.  The codings  provided in the definition column are no longer correlate with the codings in 7.5.7.1.


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

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

Response:
REJECT. The current method of using the channel time request command does allow other DEVs to request that a DEV in PS mode change to ACTIVE mode. During the time that a DEV is awake, i.e. its awake beacon, it possible to send it an application specific command that would cause the DEV to switch to ACTIVE mode.


Comment:
The DME should have a dual point arrow above it to signify that there is an unspecified interface to upper layer management.


Comment:
should say "information for all associated DEVs."

SuggestedRemedy:
change to "information for all associated DEVs."


Comment:
There should not be an MLME that is sent every beacon.

Response:
ACCEPT IN PRINCIPLE. Change ‘upon reception of a beacon containing an ASIE containing its DEVID.’ to be ‘upon reception of a beacon containing an ASIE containing its DEVID, as described in {xref 8.14}.’


Comment:
there shouldn't be a period at the start of the sentence.


Comment:
remove the "a" from sentence at end of line 21.

Response:
ACCEPT IN PRINCIPLE. Change "If either a one or more CTAs per superframe are allocated, this value shall be set to zero." to "If one or more CTAs are allocated per superframe, this value shall be set to zero."


Comment:
Verification info length(=L2) does not seem to be required since the length of the ACL record field will determine length of the Verification info.

SuggestedRemedy:
Remove Verification info length if not really required.

Response:
ACCEPT IN PRINCIPLE. The 'L' value for the verification info length field is needed to define the length of the ACL record. In figure 72, change "Length" to "Length (=10+Ln)" {Ed. Note: n is subscript}. Change "Verification info length (=L2)" to "Verification info length (=Ln)". Change "octets: L2" to "octets: Ln"


Comment:
Again, the title "MAC Frame Formats" is incorrect.

Response:
ACCEPT IN PRINCIPLE. Change all headings to conform to IEEE rules.


Comment:
Same as 409 in LB19, the response wasACCEPT IN PRINCIPLE.  A burst is the collection of the frames that are pending acknowledgement via a Dly-ACK frame. But what the commentor wants is the clarification in the draft.

SuggestedRemedy:
Add that "A burst is the collection of the frames that are pending acknowledgement via a Dly-ACK frame." as the definition in clause 3 (or 5)

Response:
REJECT. Clause 3 is for general definitions, not specific definitions.  A burst is defined in clause 7 as 'A burst is the collection of the frames that are pending acknowledgement via a Dly-ACK frame.'  While we could add it to clause 5, that clause is intended to be a light overview and does not contain every technical item that occurs in the draft.  The word 'burst' isn't used in clause 5, so there is no reason to define it there.


Comment:
Same as CID 410 in LB22Original 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.Suggested Remedy: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-windowResponse:REJECT.  Two variables are needed, the total amount that can be sent as well as the number of frames that the destination DEV is able to handle.  The number of frames is important because there are physical limitations in the Dly-ACK generation. The other reason is that there are physical limitations in the buffer implemention, e.g. addressing.Commentor's response:The commenter agrees that there are two variables needed and it is evidentby the suggestion. But what is not clear is the intention in providing number of frames of size aMaxFrameSize, instead of providing a direct bound of max on totalnumber of octets that is entertained in the burst. The implementations can makeuse of this information in a useful way while the current info does not given anycluse on the size of the (MAxNumFrames - NumMAxFrameSize) of the frames. How doyou expect the implementations to guess those sizes? If all of them are(aMaxFrameSize-1), they are not indicated to the rx-DEV in this frame and the rx-DEVis supposed to handle them properly. In the worst case if all of the NumMaxFrames areof the size (aMaxFrameSize-1), then NumMAxFrameSize will be indicated as zero althoughthe rx-DEV has the pain of dealing with these mega-burst!!

SuggestedRemedy:
Remove "max frames" from Figure-17 and instead include a two-octet wide "total number of octets" as sum of number of octets in the payload of all frames sent in the burst

Response:
REJECT. The TG has considered the new suggestion, but feels that ther are two different numbers that are required, one that gives the total amount of space available for frames and another that indicates the number of frames of any size that the DEV is able to receive. Both of these values have direct implications in terms of the capabilities of the implementation. An implementation will likely need to keep track of each of the frames received individually, e.g. assign them some space and a ‘pointer’ that indicates the start point and either a length or another ‘pointer’ to the end of the buffer. This places a specific requirement on an implementation that is not communicated with a single number of the total buffer space. In addition, using aMaxFrameSize is an abstraction that allows this to be used for future PHYs that may use much larger frame sizes as opposed to using only the number of bytes.


Comment:
Same as Comment 412 in LB19Original 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).Suggested Remedy: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.Response:REJECT. The frame formats specified only shows the bits sent over the air. Implementations of the receiver functions of a DEV are free to pad and rearrange to any word length, endian or bit order they may choose to optimize the interface to their host. This issue was discussed multiple times before the TG agreed to make the change.Commentor's response:The comment itself is about the bits sent over the air, not some constructionwithin rx-DEV. The goal is to simplify, as much as possible, the processing of IEs.As noted in the comment, the even octet aligning of IEs does simplify the processingboth in hardware and software implementations. By the time the frame arrives at therx-DEV, the damage is already done in the sense that the rx-DEV has to go throughoctet level processing of the frame. Hence the resolution is NOT acceptable.

SuggestedRemedy:
Put back the paragraph that mandated the start of an IE at even position of octets and hence the padding of a zero at the tx-DEV at the end of an IE whenever the total size of that IE is odd number of octets.

Response:
REJECT. The BRC has addressed this issues and believes that while it may help some implementations to use 16 bit alignment for IEs, other impementations may not be assisted with this. For example, a 32 or 64 bit implementation would not necessarily benefit from the 16 bit alignment.


Comment:
same as CID 414 in LB19Original 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 TBTTSuggested Remedy: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.Commentor's response (LB22)The response addresses the issue only partially. For interpretations towardsconformance, "The PNC is able to choose when it sends any IE" is not correct The interpretation by vendors can go either way. that is, a group of implementors might expect the Dev-Assoc-IE contianing the recently associated DEVs to appear immediately after assoc while the rest might tolerate it appearing anytime. Hence the inclusion of the suggested remedy is required. I have rephrased the same in thefollowing text for editor's peruse (Applicable after the removal of sentence asin the response)."The the DEV association IE corresponding to an association shall be included in thebeacon sent at the start of immediate next superframe, excepting the case where thatbeacon is already at its maximum allowed size where the inclusion of IE is delayeduntil the space in the beacon permits the same."

SuggestedRemedy:
I have rephrased my earlier suggested remedy in the following text for editor's peruse (Applicable after the removal of sentence asin the response)."The the DEV association IE corresponding to an association shall be included in thebeacon sent at the start of immediate next superframe, excepting the case where thatbeacon is already at its maximum allowed size where the inclusion of IE is delayeduntil the space in the beacon permits the same."

Response:
ACCEPT IN PRINCIPLE. The sentence was deleted for draft D14 as indicated in the resolution of CID 414 for LB19. The words “multiple beacons” occurs only once in D14 in the section describing ASIE and not for association/disassociation. The repetition of beacon announcements is now described in 8.6.4 for all of the announcements, including this one. Functional descriptions, such as when announcements belong in clause 8. The location of text is editorial and the repetition of these elements is already described in clause 8.


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

Response:
REJECT. However, every other diagram in the clause is drawn the other way so reversing this one would cause confusion.


SuggestedRemedy:
Remove "Otherwise this field shall be ignored upon reception"


Comment:
[PM] There's not much use setting an element in the beacon for a DEV that doesn't listen to beacons!/KO

SuggestedRemedy:
Remove "HIBERNATE" from the first sentence.


Comment:
Rename 'Start Beacon Cycle' to 'Start Beacon Number'. We always use the name beacon number throughout the draft./KO

SuggestedRemedy:
Change Figure 38 and line 24 from 'cycle' to 'number'.


Comment:
"ACL record" is called "ACL info set" in 6.3.15.3/KO

Response:
ACCEPT IN PRINCIPLE. ACL record set in both clauses now.


Comment:
[CTA/Term] Terminate bit is terminated/KO

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

Response:
REJECT. The terminate bit is still used in clause 8.5.1.3 to indicate that the DEV wants the stream terminated. While the bit is probably redudant, at this point the text requires its presence.


Comment:
[CTA/Term] The terminate bit no longer exists./KO

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


Comment:
[RemoteScan] You can't tell from a beacon if the PNC _is_ a parent, only that it _has_ a parent./KO

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

Response:
REJECT. There are many ways that the DEV can determine that a piconet is the parent of another piconet, e.g. private CTAs, a Neighbor ID assigned, finding both the parent and dependnet beacons, etc. It is up to the DEV’s judgement to determine if it thinks the piconet it found was either a parent or independent piconet.


Comment:
Two typos:  Second sentence on line 20, change from If the PS set index "shall be" to "was". Line 23: make multiple requests to join "a" PSPS set, should be "the"./KO

Response:
ACCEPT IN PRINCIPLE. Change "shall be" to "has been". Change "a" to "the" as specified.


Comment:
[CTA/PM] CTR may be refused because destination is in hibernation. Therefore change the error code to reflect both the case were a stream is established but the destination enters hibernation or SPS, and the case where a CTR is made for a DEV in hibernation/KO

SuggestedRemedy:
Rename error code 7 to 'destination in power save mode'

Response:
ACCEPT IN PRINCIPLE. The reason code ‘Destination DEV in power save mode’ is technically equivalent to ‘Stream terminated, DEV entered power save mode.’ The stream index combined with the PS status IE tells the source DEV that the stream was terminated due to a DEV entering power save mode. Likewise, if it is a request, the source DEV knows because the unassigned stream index is used in the response. Thus changing the text here clarifies the meaning of the error code. Rename error code as ‘Destination DEV in power save mode’. After discussion, the commenter agreed that this comment is editorial and not technical.


Comment:
[SEC/Auth] Not clear whether PublicKeyObjectLength parm is required in the MLME-AUTHENTICATE.request/indication primitive's parm list since this parameter does not get used in the Authentication request command,7.5.2.1.  Either add the parameter to the Authentication request command or delete the parm from the MLME-AUTHENTICATE.request primitive's parm list.

Response:
REJECT. While the PublicKeyObjectLength is not sent explicitly over the air, it is used to calculate the length of the command frame by the MLME.


Comment:
[SEC/Auth] It is not clear whether the "Key" parm in the MLME-REQUEST-KEY.response/confirm primitive's parm list  needs to be listed as "EncryptedKey" since that is how it is named in the request key response command, 7.5.2.6. Please clarify which name is correct and make the appropriate change in either clause 6 or clause 7.

SuggestedRemedy:
Please make the requested clarification and change.

Response:
ACCEPT IN PRINCIPLE. Change 6.3.8.3.2 from ‘The MLME generates a request key response command, 7.5.2.6, and sends it to the specified DEV.’ to ‘The MLME generates a request key response command, 7.5.2.6, and sends it to the specified DEV.  The MLME encrypts the key before transmission.’ Change the last sentence of 6.3.8.4.1 from: ‘Otherwise, the ResultCode is SUCCESS.’ to ‘Otherwise,the ResultCode is SUCCESS and the MLME decrypts the key.’


Comment:
[SEC/Auth] It is not clear whether the "Key" parm in the MLME-DISTRIBUTE-KEY.request/indication primitive's parm list  needs to be listed as "EncryptedKey" since that is how it is named in the distribute key request command, 7.5.2.7. Please clarify which name is correct and make the appropriate change in either clause 6 or clause 7.

SuggestedRemedy:
Please make the requested clarification and correction.

Response:
ACCEPT IN PRINCIPLE. Change 6.3.9.3.2 from ‘The MLME generates a distribute key response command, 7.5.2.8, and sends it to the specified DEV.’ to ‘The MLME generates a distribute key response command, 7.5.2.8, and sends it to the specified DEV.  The MLME encrypts the key before transmission.’ Change the last sentence of 6.3.9.4.1 from: ‘Otherwise, the ResultCode is SUCCESS.’ to ‘Otherwise, the ResultCode is SUCCESS and the MLME decrypts the key.’


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


Comment:
[PM/CWB] Delete the Continued wake beacon IE. The use of the CWB IE in the wake beacon only works if the sleeping SPS DEV hears the wake beacon and in that case the SPS DEV doesn't need the CWB IE.  And in the other case it doesn't matter, because it can't use the info in the CWB IE because it didn't hear it. The simpler solution is to implement the following rule for item 3 in clause 8.13.2.3, P219, L3, and for a combined item 2 & 3 in clause 8.6.4, P198, L41:  - If the DEV is in PSPS or SPS mode, the announcement shall be made in aMinBeaconInfoRepeat subsequent beacons starting with the system or SPS wake beacon.(solution by KO)


Comment:
[Frag] Delete the "preferred fragment size" sub-field from the DEV capabilities field of the capability information IE.  There were no CIDs from LB-19 that requested this addition.  Arbitrary additions by the TE are abominable.  If the TE felt this was a necessary item to address why wasn't it raised as a comment during LB-19?  No CID, no discussion, no to its inclusion.

Response:
ACCEPT IN PRINCIPLE. Resolve as indicated in CID 202. After discussion, the commenter agreed that this comment is editorial and not technical.


Comment:
[PM/CWB] Delete the continued wake beacon clause.  The use of the CWB IE in the wake beacon only works if the sleeping SPS DEV hears the wake beacon and in that case the SPS DEV doesn't need the CWB IE.  And in the other case it doesn't matter, because it can't use the info in the CWB IE because it didn't hear it. The simpler solution is to implement the following rule for item 3 in clause 8.13.2.3, P219, L3, and for a combined item 2 & 3 in clause 8.6.4, P198, L41:  - If the DEV is in PSPS or SPS mode, the announcement shall be made in aMinBeaconInfoRepeat subsequent beacons starting with the system or SPS wake beacon.(solution by KO)


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

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


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

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


Comment:
[CTA] Range of AvailableNumTUs is wrong. CTR response carries only one octet for this parameter, see 7.5.5.2/KO

SuggestedRemedy:
Valid range for AvailableNumTUs is 0-255.

Response:
ACCEPT IN PRINCIPLE. The requirements for this field are set out in clause 7.5.5.2, so the range in clause 6 should match. Change as indicated. After discussion, the commenter agreed that this comment is editorial and not technical.


Comment:
[CTA/Asynch] AvailableNumTUs never returned for asynchronous requests (neither is the primitive!)/KO

SuggestedRemedy:
Change description to: "The number of TUs available to the requesting DEV for allocation"

Response:
ACCEPT IN PRINCIPLE. The description does not match the usage that is clearly defined in clause 8. Change as indicated in the comment. After discussion, the commenter agreed that this comment is editorial and not technical.


Comment:
[CTA/Term] The source is not informed about termination via the NULL CTA, it's informed via the CTR response from the PNC. Ref Fig 120, page 193 and 8.3.4 page 176 line 16-17./KO

SuggestedRemedy:
Change sentence to: This primitive is used to inform the SrcDEV DME that the MLME has received a channel time response command indicating that the channel time that was previously allocated has been terminated by the PNC or the TrgtDEV. It may also be used to indicate to the TrgtDEV DME that the MLME has seen a null-CTA in the beacon with its DEVID, BcstId or McstID as the destination.

Response:
ACCEPT IN PRINCIPLE. Change ‘This primitive is used to inform the source DEV that channel time that was previously allocated is no longer present in the most recently received beacon.’ to be ‘This primitive is used to inform the DEV DME that a stream has been terminated.’ After discussion, the commenter agreed that this comment is editorial and not technical.


Comment:
NEW no longer used. Create is done by setting 'join' and PSIndex=UnAllocated Set./KO

SuggestedRemedy:
Remove 'NEW' from PSSetOperation Valid Range column.


Response:
ACCEPT IN PRINCIPLE. Change 6.3.8.3.2 from ‘The MLME generates a request key response command, 7.5.2.6, and sends it to the specified DEV.’ to ‘The MLME generates a request key response command, 7.5.2.6 ,and sends it to the specified DEV.  The MLME encrypts the key before transmission.’ Change the last sentence of 6.3.8.4.1 from: ‘Otherwise, the ResultCode is SUCCESS.’ to ‘Otherwise,the ResultCode is SUCCESS and the MLME decrypts the key.’


Comment:
[CTA/Isoch] Rename the SPSSetIndex parm to PSSetIndex since that is how the various PS sets are referenced now.

Response:
ACCEPT. The name in this location could be better, so change as indicated. Also add the clarification that HIBERNATE and PSPS are not allowed values for this set index. After discussion, the commenter agreed that this comment is editorial and not technical


Comment:
[CTA/Isoch] Reorder these parms in the MLME-CREATE-STREAM.request parm list:  CTR-TU,CTR-Interval-Type,CTR-Interval,CTA-Type,CTR-Type,Priority <to>  Priority,CTR-Type,CTA-Type,CTR-Interval-Type, CTR-Interval, CTR-TU.

SuggestedRemedy:
Please make the requested change.  Its just an editorial but it will make it easier for people to correlate the parms between the primitive and the Channel Time request command.


Response:
ACCEPT. The name in this location could be better, so change as indicated. Also add the clarification that HIBERNATE and PSPS are not allowed values for this set index.  Change the appropriate location in clause 6 as well (6.3.18). After discussion, the commenter agreed that this comment is editorial and not technical


Comment:
[CTA/Isoch] Reorder these parms in the MLME-MODIFY-STREAM.request parm list:  CTR-TU,CTR-Interval-Type,CTR-Interval,CTA-Type,CTR-Type <to>  CTR-Type,CTA-Type,CTR-Interval-Type, CTR-Interval, CTR-TU.


Comment:
[PM]  Please clarify the PSActiveEvent parm.  There does not seem to be any correlation betwen the enumerations and the parm passed in the ps-mode-change command, 7.5.7.1.

SuggestedRemedy:
Please make the requested clarification.

Response:
ACCEPT IN PRINCIPLE. The use of this MLME is described in clause 6, but it is not clear when you read clause 8 why it is used. Therefore, add a sentence to the end of 8.13 to point to the usage of this MLME that is defined in clause 6, ‘If the DEV MLME changes its PS mode to ACTIVE without the prompting of the DME, it notifies the DME with the MLME-PS-MODE-ACTIVE.ind primitive as described in {xref 6.3.24.7}.’ After discussion, the commenter agreed that this comment is editorial and not technical.


Comment:
Please move the PSSetOperation parameter from its current position in the MLME-PS-SET-CONFIGURE.request primitive's parm list to before the PSSetIndex.  It just makes it easier for the reader to correlate the parms with the ones in the PS configuration request command, 7.5.7.2.  Also in 6.3.24.3.1 change this sentence frag. <from> ...This primitive is used to request achange the PS set..." <to> "...This primitive is used to request a change to the PS set..."


Comment:
[PM] Delete the PSSetOperation parm from the MLME-PS-SET-CONFIGURE.confirm parm list since it is not returned in the PS configuration response command's parm list.


Comment:
MACPIB_MaxSPSSets needs to be renamed to MACPIB_MaxPSSets since that is how they are denoted in clause 8.


Comment:
"DEV performas a MLME-Sync.request" doesn't sound right.

SuggestedRemedy:
Vhange to "the DME issues an MLME-Sync.request"

Response:
ACCEPT IN PRINCIPLE. Change "Prior to the association process, the DEV performs a MLME-SYNC.request and receives MLME-SYNC.confirm." to "Prior to the association process, the DME issues an MLME-SYNC.request and receives an MLME-SYNC.confirm."


Comment:
Why does the MLME timeout for the DME?  Why doesn't the DME do it's own timeout.  What if the MLME gets a response just after it sends the time out?  Does it send the response up the confirm to the DME or abandon it.

SuggestedRemedy:
DME shoudl do it's own timeout.  MLME should't be tracking state for the DME request.  Elimiate the last sentence in thsis paragraph.

Response:
ACCEPT IN PRINCIPLE. Resolve as indicated in CID 100.  After discussion, the commenter agreed that this comment is editorial and not technical.


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

Response:
REJECT. The parameter has been unchanged since D11. The commenter is invited to resubmit the comment in sponsor ballot.


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


Comment:
WHy is there a MaxRetransmissionLimit?  Does that mean that a DEV that tries to associate and gets no response must self destruct?

SuggestedRemedy:
Get rid of maximum retransmission limit.  That should be left to the implementer.

Response:
ACCEPT IN PRINCIPLE. The retry limit is defined in 8.8.4. The only location this parameter is referenced is in 8.4.3, page 179, line 22 which has to do with the backoff procedure and not the retry limit. Consequently, to clean up the organization, delete the sentence ‘The DEV ... is reported through the MAC-SAP interface.’ and delete the parameter in table 64 since the parameter is not used in the draft. After discussion, the commenter agreed that this comment is editorial and not technical.


Comment:
Since the new PNC must authenticate with all of the DEVs in the piconet. It must allocate time for this to happen. If the PNC does not allow commands in the CAP, then the PNC SHALL set up CTAs for authentication.

SuggestedRemedy:
Change 'should' to 'shall' and note that this is only necessary when commands are not allowed in the CAP.

Response:
REJECT. This text is the same technically as in D11 with the exception of an editorial change. The commenter is invited to resubmit the comment in sponsor ballot.


Comment:
A DEV must associate in order to be assigned DEVID and CTAs.


Comment:
Looks like period separated from last word in sentence ending on line 21.

SuggestedRemedy:
Remove blank between period and last word in sentence ('key').


Comment:
At the Vancouver plenary, in the agreeded upon security resolution regarding security models, the GROUP was told that the architecture presented by NTRU and adopted in St. Louis as the baseline would support both piconet wide data protection and smaller groups beginning at the peer to peer level.  The current text does not support that model.  The suggested text supports the current model as well as a sub-group starting at 2 DEVs and going up to the nmaximum allowable number of DEVs in the piconet - 1.

SuggestedRemedy:
Delete section 9.1.6 and insert the following text: Data encryption uses a symmetric cipher to protect data from being read by parties without the cryptographic key.  Data may be encrypted either by using a key shared by all piconet DEVs or by using a key shared between two or more DEVs.

Response:
REJECT. Group authentication mechanisms (other than the piconet group) is outside of the scope of the standard. In addition, the changes required for the current draft to implement this have not been presented to the task group. A mechanism does exist in the standard to accomplish sub-group security. The method that is available to do this is to start a dependent piconet with the members of that piconet as members of the dependent piconet.


SuggestedRemedy:
Data integrity uses an integrity code, often referred to as a message authentication code, to protect data from being modified by parties without the cryptographic key.  It further provides assurance that data came from a party with the cryptographic key.  Integrity may be provided using a key shared by all piconet DEVs or using a key shared between two or more DEVs.  All secure data frames that fail integrity checks are discarded.


Comment:
The current text in 9.2.2 attempts to implement a very loose heartbeat function that closes teh set of authenticated DEVs in an established piconet.  The problem is that security, in the sense of a wireless network, cannot be "mushy."  In more definite terms, the text of 9.2.2 is indefinite and cannot be used to implement a method that securely, reliably closes teh network set.  Replace the exsiting text with the following text:

SuggestedRemedy:
The PNC or another DEV shall request that each DEV with which it has authenticated (previously authenticated DEV) periodically transmit a secure frame using the management key to be certain that that DEV is still in the piconet.  If no secure frames are being transmitted by the previously authenticated DEV, the PNC or requesting DEV shall send a secure probe command requesting an information element (such as the DEV adress) from the previously authenticated DEV.  If the previously authenticated DEV does not respond with a secure frame within a predetermined period of time, the previously authenticated DEV's authentication is revoked and the PNC or requesting DEV shall disassociate or deauthenticate the previously authenticated DEV.  By definition, dissassociation of an authenticated DEV results in deauthentication.

Response:
ACCEPT IN PRINCIPLE.  The text is a little confusing, so put in precise names for the particpants in this exchange, Change the paragraph to read 'The PNC or another DEV may request that each DEV with which it has authenticated periodically transmit a secure frame using the management key to be certain that the DEV is still in the piconet. If no secure frames are being transmitted by the previously authenticated DEV, the PNC or requesting DEV may send a secure probe command requesting an information element (such as the DEV address) from the previously authenticated DEV. If the previously authenticated DEV does not respond with a secure frame within a period of time, the PNC or requesting DEV may assume that the previously authenticated DEV is no longer present and disassociate or deauthenticate the previously authenticated DEV.'


Comment:
The current text reads: "The authentication and challenge commands are designed to be used with security turned off."  Is this an accurate statement?


Comment:
In reading this clause, an implementer will certainly be confused.  The Access Control List is said to contain information "about which devices are authorized to authenticate with the DEV using their corresponding public key."  The implemener then see the "manner in which the ACL is used depend[ing] on the application and the security suite in use."  This is very confusing for the following reason.  In the 802.15.3 ad-hoc network, DEVs are openly admitted (associated), and admitted DEVs then request authentication, and if successful, the PNC will add the authenticated DEV to the ACL.  Does the current text preclude this operation?

SuggestedRemedy:
The text must be modified to address the correct issue.  That issue is the binding of a DEV's identity to its public key, then the subsequent addition of the DEV's public key, or other representation into the ACL to control future group membership in the piconet.

Response:
ACCEPT IN PRINCIPLE. Change 9.3.2, 2nd paragraph to move the last sentence ‘See C.4 for further details on authorization of public keys.’ to be the second sentence in the paragraph.


Comment:
The reference "While the security suites are interoperable," is inaccurate and misleading.  Interoperation implies exactness in purpose, operation and results.  In our case, the purpose of all security suites is the same, but the operation and results are different.  For example, the ECMQV suite establishes a 128 bit key, while the NTRU and RSA suites establish only 80 bit keys.

SuggestedRemedy:
Repair the text to accurately reflect the defined operation of any current or future security suite.

Response:
ACCEPT IN PRINCIPLE. Change 9.4, line 49 from ‘While the security suites are interoperable, it is possible that there are differences in the levels of security provided as described in C.3’ to ‘While the security suites all establish symmetric keys, it is possible that there are differences in the levels of security provided as described in C.3.’


Comment:
The SRF - Security requirements field, defined as being included in the authentication response command used to indicate the authentication policies of the security manager.   This should be more fully discussed with respect to the operation and establishment of data keys.  It needs to be able to establish a required bit level of security in a system.

SuggestedRemedy:
Reference to current sections:
7.5.2.2  Authentication response command
If the certificates required bit is set to 1, the security manager shall only authenticate DEVs with a security suite that uses certificates, 1.2.1 and Table 96, while it operates as the security manager.  If the 128-bit security required bit is set to 1, the security manager shall only authenticate DEVs with a security suite that is stated to provide 128-bit security in Table 96 while it operates as the security manager.  The auth response field is the integrity code generated by the security manager and associated with the authentication protocol, 10.2. 10.3.1.3 ECMQV key agreement protocol The optional parameter Text2 as specified in sections 6.11.1 and 6.11.2 of ANSI X9.63-2001 shall be the one-byte value of the security requirements field included in the authentication response command,7.5.2.2.

Response:
REJECT. The security requirements field allows the PNC to require an 128-bit security suite and/or certificate usage. It does not adversely affect the security of the piconet to allow higher levels of security.


Comment:
The fact that a public key is in the ACL is not what provides theat the public key belongs to the intended DEV.  The trust is established by the fact that the DEV can respond to the challenge and prove that it has the private key that accompanies the public key in the ACL.  The fact that the public key and dev address are in the ACL provides the authorization that the DEV should be allowed into the piconet, provided it can authenticate by proving that it has the private key.

SuggestedRemedy:
Change to: In order to use a public key to achieve mutual authentication, it is necessary to trust that the received public key belongs to the intended DEV.  This trust shall be indicated by a certificate or by a DEV rsponding sucessfully to a challeng, proving that it has the private key that corresponds to the public key in the ACL. the key’s representation in an ACL or by the DEV verifying a digital certificate at the time of authentication.

Response:
ACCEPT IN PRINCIPLE. Change ‘that the received public key belongs to the intended DEV.’ to be ‘that the received public key belongs to the intended DEV associated with the DEV address.’


Comment:
It needs to be made clear if authentication is required for a neighbor piconet.  If so, a separate table is needed for neighbor authentication where the sym_keys_D are not passed.

SuggestedRemedy:
Create a table for neighbor authentication.

Response:
ACCEPT IN PRINCIPLE. While the Neighbor PNC is allowed to request authentication from the parent PNC, it is unlikely that this would be successful based on the security policy of the parent PNC. However, it is not prohibited in the draft, so the text in 8.2.5 is correct.


Comment:
When mode 2 was removed, implementation of any of the defined security suites for the remaining security mode is required. This sentence limits the suites to the non-certificate security suites which was not the intention of the BRC when this was accepted.

SuggestedRemedy:
Change "ECMQV manual, NTRUEncrypt raw 1, or RSA-OAEP raw 1" with "ECMQV manual, ECMQV implicit, ECMQV X.509, NTRYEncrypt raw 1, RSA-OAEP Raw 1, or RSA-OAEP X.509 1"

Response:
ACCEPT IN PRINCIPLE. The text has an incorrect set of cross references and a sentence that is not clear. Change ‘one of the following sub-suites: ECMQV manual, NTRUEncrypt raw 1, or RSA-OAEP raw 1. All other defined security subsuites may be implemented by a compliant DEV.’ to be ‘one of the sub-suites listed in {xref Table 95}. A DEV may implement more than one of the defined security subsuites.’ This matches the requirements in the PICS clause.


Comment:
The MLME commands and frame formats imply that ChallengeResponse is defined with a fixed length for all security suites. ChallengeResponse was left out of Table 105.

SuggestedRemedy:
Add ChallengeResponse to Table 105 with proper Length, Value, and Description from other portions of clause 10 or by definition by Rene Struik.

Response:
ACCEPT IN PRINCIPLE. The description of the challenge response is given in table 100.


Comment:
The previous draft was changed to specify a "new" encryption scheme for NTRUEncrypt, referencing EESS #1, ees251ep3.  The current draft specification is supposed to represent a guide to implementers that will stand the test of time as a standard if approved.  It is a fact that the evolving NTRUEncrypt scheme has been proven vulnerable to attacks that completely render the encryption useless.  Additionally, the immature, relatively untested and unreviewed nature of this cryptographic scheme exposes the proposed standard to early obsolescence in this unproven element.

SuggestedRemedy:
Completely remove the NTRUEncrypt security suite from the draft specification until such time that the evolving NTRUEncrypt scheme is stable enough for relaible commercial delopyment.

Response:
REJECT. The NTRUEncrypt suite has been included as an optional security suite since D10. The TG will ask the IEEE if this specification or other references should be archived so that it will be available in the future for an implmenter. Inclusion of any security suite in this standard is not an evaluation that any one of the suites are suitable for security purposes.


Comment:
Why are raw keys called manual certificates for ECMQV

SuggestedRemedy:
Be consistent and call them goth raw or manual

Response:
REJECT. There are two different view points.  The first is that there are raw keys and the second is that everything should be a certificate.  Since the manual certificate includes the DEV address it is not simply a raw key.  Thus the descriptions are correct for the technical content.


Comment:
What is the purpose of listing DEV Address as a separate line item in the ECC Certificate frame object format?  The definition of DEV address is consistent throughout the draft.  Listing it here is redundant, and as some would say say, evil.

Response:
REJECT. This was suggested to the person who submitted the ECC suite, but he feels strongly that the DEV address should be included.


Comment:
It looks like certificate use has been added for Ntru and RSA.  WHy are these not listed as sub-suites in Table 95 as they are for ECMQV

SuggestedRemedy:
Be consistent.  Either add sub-suites for Ntru and RSA or delete them for ECMQV.

Response:
REJECT. The specification and content of the ACL is left up to the implementer and as such can contain hashes, keys, certificates, or anything else.  The ACL may be consulted as part of an authentication protocol. Subsuites exist for those suites that explicitly use certificates as part of the authentication procedure, rather than as part of the ACL.


Comment:
Table-120:Definition of MIFS and BIFS: Since MIFS is less than SIFS, make them same as SIFS. The channel time saving by the use of MIFS is very little given the probability of its use, but this is another unnecessary IFS that the MAC has to deal with and it is not optional. Making MIFS same as SIFS adds to uniformity at the lowest level of MAC. If the committee is so bent on saving channel time, please explore putting back the chaining of commands and similar options where the saving is huge and not just a few (at most 10+) microseconds.

Response:
REJECT. While the benefit with the 2.4GHz PHY of the draft is nominal, it is still about 5% at the highest data rate. With increased data rates of alt-PHYs the overhead becomes pronounced and is necessary to realize the promise of higher throughput. While chaining commands could save some overhead, commands are sent very infrequently while the vast majority of the traffic in the piconet is data. Thus, reducing the overhead for data is much more important than reducing the overhead for commands. Currently, the draft defines four IFS, all of which are based on the characteristics of a PHY. The MIFS relates directly to a PHY’s ability to send or receive multiple frame when it does not have to switch between sending or receiving. Thus it makes sense to keep this as a separate parameter.


Comment:
Table-120:PLEASE summarise all PHY parameters (aCCADetectTime, aPHYSIFSTime etc.) in a table at one place instead of spreading them all around the PHY clause (something on the lines of Table-64, for MAC, is very desirable from implementors' view). Although Table-65 provides a list of PHY parameters in a table, the values have to be searched through in those referred clauses, which can easily be avoided.

SuggestedRemedy:
Create a summary table of PHY parameters instead of spreading them all over the PHY clause(s).

Response:
ACCEPT IN PRINCIPLE. The location of the parameters in the draft is an editorial decision, not a technical decision (and this location did not change from draft D11 to D14). However, the technical editor will consider putting all of the parameters into a single table at the end of the PHY clause.


Comment:
Market suitability criteria seems to be incomplete.

SuggestedRemedy:
Change "The protocols have been reviewed by" to "The protocols have been reviewed by (whomever reviewed these protocols)"

Response:
ACCEPT IN PRINCIPLE. Changed sentence to 'The protocols have been reviewed by 802.15.3 task group to ensure that they satisfy the requirements of 802.15.3 applications.'


Comment:
Are the references to draft standards allowed? I thought IEEE allowed references only to the already existing standards. Please check.

Response:
ACCEPT IN PRINCIPLE. There is a way to use a draft standard as a reference, however Annex F is not the reference section, it is the bibliography.  The references are normative and so they are treated differently than the entries in the bibliography, which is an informative annex.  So, in this case, there is no restriction on what is listed in the annex.


Comment:
[CTA/isoch] support of pseudostatic streams are not mandatory, while support for an isochronous stream (would imply dynamic) is./KO

SuggestedRemedy:
Add two subrequirements to MLF13. 13.1 dynamic isochronous stream, 8.4.4.1, M 13.2 pseudo-static isochronous steam, 8.4.4.1, O

Response:
ACCEPT IN PRINCIPLE. The description in the table is not clear while the text in clause 8 does describe this correctly. Change ‘Isochronous stream - at least one’ to be ‘Isochronous stream in a dynamic CTA- at least one’ After discussion, the commenter agreed that this comment is editorial and not technical.


Comment:
[PM/CWB] Delete the CWB entry from the table.  It is not needed. The use of the CWB IE in the wake beacon only works if the sleeping SPS DEV hears the wake beacon and in that case the SPS DEV doesn't need the CWB IE.  And in the other case it doesn't matter, because it can't use the info in the CWB IE because it didn't hear it. The simpler solution is to implement the following rule for item 3 in clause 8.13.2.3, P219, L3, and for a combined item 2 & 3 in clause 8.6.4, P198, L41:  - If the DEV is in PSPS or SPS mode, the announcement shall be made in aMinBeaconInfoRepeat subsequent beacons starting with the system or SPS wake beacon.(solution by KO)


Comment:
Missing the clause xref for the Non-secure beacon.


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

Response:
REJECT. There are applications that would require more than a single SPS set supported by the PNC. Based on this view of the market requirements, having 4 SPS sets as mandatory for AC powered PNCs is reasonable for these applications.


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


Comment:
Change all references to "SPS set" in this clause <to> "PS set" since power management resolutions from LB-19 implemented  in clause 8 have changed all references to an "SPS set" to a "PS set".

Response:
ACCEPT IN PRINCIPLE. Changed in essentially every location in the draft except where an SPS set is specifically called out.  Please check and check for an PS set as well.


Comment:
Change this field <from> "Rx error frame count" <to> "Rx frame error count".  This change will make the parameter name consistent with the parm name in the parm list of MLME-CHANNEL-STATUS.response primitive.


Comment:
The octet field sizes for the PS set structure are incorrect.  Please change from field size of 37 to a variable size ranging from 8 to 39 octets. Also make an appropriate change to the Length field.  A suggested change is: > Length (= 1+(sum of PS set structure lengths))

Response:
ACCEPT IN PRINCIPLE.  Change size of PS Set Structure as specified. Change Length field  to "Length (=(1+ sum of length of n PS set structure)"


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


Comment:
[PNC/Scan] A new IE is needed to support comment about PNC channel scan in 8.9.5. This IE informs the piconet that the beacon will be suspended for a certain time./KO

SuggestedRemedy:
Add new IE: PNC Scan IE.  The PNC scan IE is used to inform all DEVs in the piconet that the PNC beacon transmission will be suspended for a specified time, and to order all DEVs in the piconet to suspend all transmission for the same time. [octets:1    |          2    |     1    |     1      ] [Quiet       |Suspend beacon | Length=3 | Element ID ] [superframes |   number      |          |            ]

Response:
REJECT. For sleeping DEVs, it is very advantageous to keep the beacon numbers incrementing at a regular rate, especially for DEVs that sleep for long periods of time. Likewise, the PNC really can’t wait for all of them to reach their wake beacon before it goes off to look at its own or other channels.


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

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


Comment:
'PNC response' was change to 'CTRRespTime' in 8.4.4.3 and 7.3.11. Recommend changing it in all places to 'CTRResponseTime'./KO

SuggestedRemedy:
Change field to CTRResponseTime, or at a minimum to CTRRespTime.

Response:
REJECT. The only two locations it occurs in clause 7 it is not used to refer to the CTRRespTime but rather to another field that includes the CTRRespTime and some reserved bits.


Comment:
Delete the "preferred fragment size" sub-field from the DEV capabilities field of the capability information IE.  There were no CIDs from LB-19 that requested this addition.  If the TE felt this was a necessary item to address why wasn't it raised as a comment during LB-19?  No CID, no discussion, no to its inclusion.

Response:
ACCEPT IN PRINCIPLE. On page 129, line 6, change ‘that indicates the MAC frame size preferred’ to be ‘that indicates the maximum MAC frame size preferred’ After discussion, the commenter agreed that this comment is editorial and not technical.


Comment:
Delete the Continued wake beacon IE. The use of the CWB IE in the wake beacon only works if the sleeping SPS DEV hears the wake beacon and in that case the SPS DEV doesn't need the CWB IE.  And in the other case it doesn't matter, because it can't use the info in the CWB IE because it didn't hear it. The simpler solution is to implement the following rule for item 3 in clause 8.13.2.3, P219, L3: "If the DEV is in PSPS or SPS mode, the announcement shall be made in aMinBeaconInfoRepeat subsequent beacons starting with the system or SPS wake beacon."


Comment:
Delete the continued wake beacon clause.  The use of the CWB IE in the wake beacon only works if the sleeping SPS DEV hears the wake beacon and in that case the SPS DEV doesn't need the CWB IE.  And in the other case it doesn't matter, because it can't use the info in the CWB IE because it didn't hear it. The simpler solution is to implement the following rule for item 3 in clause 8.13.2.3, P219, L3: "If the DEV is in PSPS or SPS mode, the announcement shall be made in aMinBeaconInfoRepeat subsequent beacons starting with the system or SPS wake beacon."


Comment:
If conformant DEVs are not allowed to send reserved values in fields, how does a DEV receive a reserved value?  Unsupported version?

SuggestedRemedy:
Clarify by changing the sentence to:  "Reserved values in non-reserved fields shall not be transmitted by conformant DEVs. However, a DEV may receive frames of a different protocol version with values that it considers to be reserved values in non-reserved fields.


Comment:
Part of the MAC frame is called the payload, as is part of the non-secure frame body and the secure frame body.  This is inconsistent, especially since PHY Table 127 has a "payload length" field.  Which payload???

Response:
ACCEPT IN PRINCIPLE.  Change "Payload" to "Frame payload"


Comment:
"maximum frame length" is not specific enough becauswe the definition of frame vague.

SuggestedRemedy:
change to "maximum MAC frame body length"


Response:
ACCEPT IN PRINCIPLE. Change "Payload" to "Frame payload" to match figure 6. See also CID 219 and 222.


SuggestedRemedy:
Change payload to Secure Payload.  Also show that everything in the figure but the FCS is part of the MAC payload.

Response:
ACCEPT IN PRINCIPLE. Change "Payload" to "Secure Payload". Also show that everything in the figure but the FCS is part of the "Frame payload". See also CIDs 219 and 221.


Comment:
"maximum number of fragments" is confusing.


Response:
ACCEPT IN PRINCIPLE. Change 7.2.7.3 heading from "Payload field" to "Secure payload field". Change the clause text from "The payload is a.." to "The secure payload is.."


Response:
ACCEPT IN PRINCIPLE. Change ‘may be decoded’ to be ‘may be ignored’ in two tables, 47 and 48 since the terms are technically equivalent. However, this needs to be changed for consistency in the draft. After discussion, the commenter agreed that this comment is editorial and not technical.


Comment:
Application Specific IE?  What Applicaation?

Response:
REJECT. The application is defined by the OUI.  The name has been historically ASIE.  To avoid problems in changing the name, the technical editor would like to keep it the same.


Comment:
IEs that don't are only used in probe commandds should mention that.

SuggestedRemedy:
Example 7.4.10 "The CTA status request IE in a probe is used by a DEV..."

Response:
REJECT. We have added this information to a single place.  Defining it in multiple places would lead to evil redundancy.


Comment:
What is the "preferred fragment size?"  Is it the biggest, smalest or nominal?   What if it is ignored?  Is it the preferred fragment size as transmitter or receiver?

SuggestedRemedy:
This field has no place and should be deleted.  The fragment size is solely up to the transmitter based on the channel conditions. Drop this from tex, too.


Comment:
This is inconsistent with 10.3.4.2.1  The public key object is not the key in clause 10, it is the "manual certificate" Which includes the dev address.

SuggestedRemedy:
WHich is it - a manual certificate or a key?

Response:
REJECT. Clause 10 defines the format for this object.  It depends on the security suite what this field includes.  So the field is a public key object which may be a key, a manual certificate or a certificate.


Comment:
The channel tiem request command normally requires authentication, but what is the authentication process for neighbor piconets.  The piconet group key clearly cannot be exchanged.

SuggestedRemedy:
Clarify how security works with neighbor piconets.

Response:
ACCEPT IN PRINCIPLE. Section 8.2, page 161 line 49 defines a neighbor piconet as ‘A dependent piconet where the PNC is not a regular DEV in the parent piconet.’ Table 53 applies only to regular DEVs in the piconet.  Add sentences to 7.5, line 8: ‘Since a neighbor PNC is not a regular DEV in the piconet, it sends commands without authentication.’


Comment:
Why aren't the Max CTRBs and Max associated DEVs part ot the PNC capabvilities?

SuggestedRemedy:
MMake ax CTRBs and Max associated DEVs part ot the PNC capabvilities


Response:
REJECT.  This error code was not changed from D11 to D14.  The commenter is encouraged to resubmit this comment in sponsor ballot.


Comment:
Why are bcast and multicast excluded from the Rx frame count.  A DEV gets a feel for channel status by whether or not it is getting ACKs.  However, mcast and bcast cannot have ACKs, so channel status could be more important.

SuggestedRemedy:
include mcast and bcast frames into channel status response command.

Response:
REJECT. The text for the RX frames is unchanged (other than editorial) from the last draft. The commenter is invited to resubmit this comment in Sponsor ballot.


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


Comment:
The use of shall may not  be correct for this. Perhaps "If the PS set index field has been set to zero ..."

Response:
ACCEPT IN PRINCIPLE. This is a grammatical mistake. Change to ‘If the PS set index field has been set to zero ...’ as this does not affect operation for the DEV. After discussion, the commenter agreed that this comment is editorial and not technical.


Comment:
In figure 92, each structure is noted as 37 octets in length. In figure 93, the DEVID bitmap is 1 to 32 octets in length so the each structure may take on values of from 8 to 37 octets. The Length calculation requires change.

SuggestedRemedy:
Change the headers in figure 92 to be "8 to 37" in two places.Change the Length formula to (1 + sum of PS set structure 1 through PS set structure n)).

Response:
ACCEPT IN PRINCIPLE. An editorial change since the following figure indicates the correct range. Change ‘37’ to be ‘8-39’ in the figure. Also change the total length to be ‘ (1 + sum of PS set structure 1 through PS set structure n)’. After discussion, the commenter agreed that this comment is editorial and not technical.


Comment:
The wake beacon interval and next wake beacon should be set to zero for set 0 by the PNC and ignored on reception.

SuggestedRemedy:
Separate the text of PSPS and HIBERNATE with regard to unused fields for HIBERNATE.

Response:
ACCEPT IN PRINCIPLE. Add to then end of the paragraph on page 158, lines 17 and 18 ‘Note that the wake beacon interval has no interpretation for PS set 0, {xref 8.13.3}.’ Add to then end of the paragraph on page 158, lines 20 and 21‘Note that the next wake beacon has no interpretation for PS set 0, {xref 8.13.3}.’


SuggestedRemedy:
Remove note and replace with correct name if necessary.


Comment:
Definition of wake beacon is vague and hence can cause confusion to theimplementors who are not part of TG3

SuggestedRemedy:
A wake beacon is a beacon sent by PNC at a previously declared periodic interval at which time all the sleeping DEVs, except those in HIBERNATE mode, are expected to be awake and be able to receive. Wake beacons contains <TBD???> in addition to other fields/elements that can be present in beacons transmitted at other times. The BC/MC traffic in a piconet shall always be in the superframe in which a wake beacon was transmitted by the PNC.[NOTE: If beacon transmission time is defined (BTT), this can be defined as WBTT which makes the text flow naturally since wake beacon referred here is mostly to do with the time of its transmission than its contents]

Response:
REJECT. The wake beacons are defined in 8.6.2 (for system wake beacons) and in 8.13 (for all of the wake beacons and in 8.13.2.1 (for SPS wake beacons). A wake beacon is when a DEV wakes up and otherwise is a normal beacon. It does not contain any special fields that are not present in any other beacon. The concept of the wake beacon is well defined for all power save modes and is used consistently in the draft.


Comment:
Same as comment 509 in LB19 (Applicable for 8.13.2 also)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 transactionsSuggested Remedy:1.If a DEV in in PSPS (SPS) 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.Response:ACCEPT IN PRINCIPLE. 1. A DEV in PSPS keeps it’s GTS and may transmit in them. This does not imply that the DEV wishes to change power save mode. 2. It is specified in 13.1 that a DEV may enter the SLEEP state only after having received an ACK from PNC on a PS mode change command with the PS Mode set to PSPS.Commentor's response (LB22)The comment exposes an ambiguity in the interpretation of PS-status bits andframe transmissions by a PSPS DEV as read in the draft (D11). But the resolution is justan explantory to the commentor with no clarification in the draft. Hence the ambiguityin the draft is still left remaining.

SuggestedRemedy:
1.If a DEV in in PSPS (SPS) 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.

Response:
REJECT. It is clear in the text that AWAKE and SLEEP states are not the same as a power save mode. A DEV will be in AWAKE and SLEEP states when it is in a power save mode or even when it it ACTIVE. The draft clearly states this on page 214, line 54 ‘Regardless of the power save mode, a DEV is allowed to go to the SLEEP state during a CTA where it is neither the source or the destination. A DEV is also allowed to switch to the AWAKE state during any time when it is in a power save mode.’ Thus, the second sentence clearly states that a DEV may be AWAKE for some period of time without changing its power save mode. Since AWAKE means either transmitting or receiving, a DEV is allowed to send frames without changing its power save mode. This is an intended feature of 802.15.3’s power save modes that is an different from the 802.11 power save modes.


Comment:
Lines 32:34 describe an two cases of handover cancellation. But the sentences make them to be percieved as just one case.

SuggestedRemedy:
Insert "In addition, " before "If the DEV sees a shutdown IE ...."


Comment:
Lines 53-54 on pp-178 with lines 1-3 on pp-179 create an unnecessary special case for starting backoff algorithm at the start of CAP. The save is not worth the special case at the lowest level of MAC where Backoff algo is run. Added to that, applicability of this special case gets narrowed by another level by the probability of not-correctly-receiving the beacon and/or the last extended beacon by a DEV. Although this specail case has a "may" in it and hence does not enforce its applicability, it is worth the space in the standard given the above reasoning.

SuggestedRemedy:
Change "SIFS" to "BIFS" in Lines 53-54 on pp-178 and lines 1-3 on pp-179

Response:
REJECT. If the DEV does not correctly receive the beacon, it cannot use the CAP anyway. If it correctly receives the beacon, it knows if there are extended beacons and it knows when the beacon eneded. If it is too complex for the DEV to implement this special case, it doesn’t have to do it. However, if the DEV can use this, it should be allowed to.


Comment:
Table-66. The cell corresponding to "Hibernate in wake superframe" column and "Beacon" row contradicts the text on pp-220, lines36-41 where the hibernating DEVs are allowed the liberty of sleeping through "any" beacon until they themselves change over to ACTIVE state (and it should be within ATP to retain the membership of Piconet)

SuggestedRemedy:
Change the referred entry from "AWAKE" to "May sleep"

Response:
ACCEPT IN PRINCIPLE. The text above the table indicates that the HIBERNATE DEV only wakes up when it wants to listen to the beacon and that is called its wake beacon. Therefore, the table is correct since a HIBERNATE DEV’s wake superframe is defined as any superframe where it listens to the beacon. The relevant text from 8.13 is ‘The wake beacon for a DEV in HIBERNATE mode occurs at times determined by the DEV and is unknown to the PNC and other DEVs in the piconet. Unlike the SPS and PSPS wake beacons, the wake beacon of the DEV in HIBERNATE mode is not periodic and is only guaranteed to happen once per ATP period for that DEV.’


Comment:
See CID-446, 477, 478 and 479 in LB19Use of Vendor specific command is the answer to the issue that is intended to be solved through this app-specific IE.

SuggestedRemedy:
Remove this subclause and references to ASIE from the draft

Response:
REJECT. The ASIE is intended to be included in the beacon as an announcement. A command cannot be sent in the beacon so the vendor specific command would not be applicable to solve this need. The ASIE was put in to enable new functionality for some DEVs without breaking compatibility for all DEVs. Since the TG cannot possibly forsee all uses that might be required, this is left to be defined by the vendors.


Comment:
The information is not only associations and CTRB, but also PS and ACL./KO

SuggestedRemedy:
Change from "be prepared to receive the PNC information command, 7.5.4.2, and CTRB records" To "be prepared to receive the piconet records"


Comment:
[PNC_HndOvr] The two sentences on line 20-22 belongs in 8.2.6, where they are missing. The first sentence should be changed to "handover announcement" and be kept here./KO

Response:
ACCEPT IN PRINCIPLE. Editorial mistakes here, One page 165, line 20, change ‘shutdown announcement’ to be ‘handover announcement’, (Ed. note, ‘enought’ is misspelled). The text on page 171, lines 37 and 38, is redundant now with the change for beacon announcements, so change the sentence to be a cross-reference, i.e. change ‘The PNC shall ... down the piconet.’ to be ‘The PNC shall ensure that the shutdown announcement complies with the rules for beacon announcements in 8.6.4. The only exception to this requirement is if the PNC will be shutting down and does not have enough time to to wait for the next system wake beacon to complete the handover process.’ After discussion, the commenter agreed that this comment is editorial and not technical.


Comment:
[PNC_HndOvr] Old MSC. Please use the correct one in 02/276r13. The Optional ACL handover is not only between MLME and DME. Besides the symbol for sub-MSC is wrong. The text referring to the ACL handover is missing. There is no MSC for cancellation./KO

SuggestedRemedy:
Start with the MSC on page 5 in 02276r13P802-15_TG3-commentsD11_KO.doc. Delete second MLME-PNC-HANDOVER.ind(COMPLETED). Add text under MSC: "The ACL Handover is described in {xref 9.2.4}. See also Figure nn {xref 'whereever you moved the ACL handover MSC to'}  Make a new MSC for CANCELLED.

Response:
ACCEPT IN PRINCIPLE. Change the shape of the optional ACL handover MSC reference to be a rounded edge box and extend it to cover both the PNC and DEV-1. After discussion, the commenter agreed that this comment is editorial and not technical.


SuggestedRemedy:
remove (or possibly do what it suggests!)


Comment:
SUB MSC does not use the condition symbol./KO

SuggestedRemedy:
Please refer to example in 02276r13P802-15_TG3-commentsD11_KO.doc page 5 for correct syntax. Replace both association and CTR symbols.


Comment:
[PiconetService] The probe isn't used for service response due to its potential length. The fragmentable piconet services command shall be used. /KO

SuggestedRemedy:
In the first sentence on line 21-22, replace "probe command" with "piconet services command".


Comment:
[CTA] The last sentence "Channel time requests that are ACKed are valid until the next channel time request is made" is only true for asynchronous data, and only if the TrgtIdList bit is set. In all other cases it's false./KO

Response:
ACCEPT IN PRINCIPLE. The sentence is redundant since the text in 8.5.1 and 8.5.2 more completely describes the behavior of the channel time requests. Delete the sentence ‘Channel time requests that are ACKed are valid until the next channel time request is made.’ from page 180, line 38. After discussion, the commenter agreed that this comment is editorial and not technical.


Comment:
[CTA] MaxProcessedCTA and MaxAssignedCTA are deleted from standard and thus the paragraph on lines 40-43 is obsolete./KO

Response:
ACCEPT. The MaxProcessedCTA and MaxAssignedCTAs are no longer passed to the PNC, thus the PNC is not required to make any consideration for this in the current draft. This text is redundant and will be deleted. After discussion, the commenter agreed that this comment is editorial and not technical.


Comment:
[CTA/Isoch] The last sentence is what happens with asynchronous data if no CTA arrives before the SDU timeout. In the case of ISOCH-DATA, you do MLME-CREATE-STREAM first./KO

SuggestedRemedy:
Delete the last sentence of the paragraph on page 187 line 38-40

Response:
ACCEPT IN PRINCIPLE. The sentence is redundant since the timeout is already described for MAC-ISOCH-DATA in 6.6.5.1. Delete the last sentence of the paragraph on page 187 line 38-40. After discussion, the commenter agreed that this comment is editorial and not technical.


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

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

Response:
REJECT. Although announcing the subrate allocation is very helpful, it is not required. An ACTIVE mode DEV will eventually find out about the subrate allocation and can even request this information from the PNC.


Comment:
This comment concerns Figure 114, Figure 115 and Figure 116. "Evaluate request", "Allocate resources" and "Build beacon" is unnecessary information. Delete all these. Rename "Check resources" to "Resources available". The reason is that they are in a condition symbol and not in a task symbol, so the condition for approving the request is that resources are available./KO


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

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


Comment:
The last sentence on line 13-14 belongs to stream creation, 8.5.1.1/KO

Response:
REJECT. If the PNC modified the interval to make it active, then the PNC needs to allocate the uplink MCTA. The DEV may also want to modify its own allocation in the reverse direction to match the change in the new allocation to it.


Comment:
Left over Ed note. BTW, name is correct./KO


Comment:
[Frag] Unclear what "A DEV shall support concurrent reception of fragments of at least three MSDU/MCDUs" means. Is it per stream or totally? Where did this sentence come from?/KO

Response:
ACCEPT IN PRINCIPLE. The sentence is unclear, change the sentence from A DEV shall support concurrent reception of fragments of at least three MSDU/MCDUs’ to be ‘A DEV shall support concurrent reception of fragments of at least three MSDU/MCDUs for all streams, including asynchronous data and commands.’ After discussion, the commenter agreed that this comment is editorial and not technical.


Comment:
sentence in paranthesis says "transmission" where you mean a new frame/KO

SuggestedRemedy:
Change to: (or new frame if the failed...


Comment:
Replace algorithim with  A-L-G-O-R-I-T-H-M. :-)/KO


SuggestedRemedy:
Insert text: PNC shall broadcast the piconet parameter change information element, 7.4.6, with the change type set to CHANNEL...

Response:
ACCEPT IN PRINCIPLE. The text in clause 7 indicates that the change type shall be set to CHANNEL when there is a channel change in progress. However, it is good to mention it here as well for completeness. One page 211, line 39, change ‘piconet parameter change information element, 7.4.6, in its current channel’ to be ‘piconet parameter change information element, 7.4.6, with the change type set to CHANNEL in its current channel’ After discussion, the commenter agreed that this comment is editorial and not technical.


Comment:
[PM] range for system wake beacon interval has no lower limit/KO

SuggestedRemedy:
Change to: "The system wake beacon interval shall not be less than 4 and not greater than 255".

Response:
ACCEPT IN PRINCIPLE. The range for the wake beacons is defined in clause 7, but there is no reference Change sentence to “The valid range for requested system wake beacons is defined in {xref 7.5.7.2}.” Also add an xref to the appropriate place for SPS, this is on page 216, line 52, change the explicit definition to an xref since it is redundant and therefore is evil. After discussion, the commenter agreed that this comment is editorial and not technical.


Comment:
[PM] The DEV is not forced to be in the AWAKE state during the entire wake superframe, only as described in 8.13. Use the correct text from 02/276r13./KO

SuggestedRemedy:
Change first sentence to: "In the PSPS mode the DEV is only required to listen to system wake beacons and CTAs where its DEVID is indicated as the destination."


Comment:
This sentence is a repetition of almost the same text on page 215 line 42/KO

Response:
ACCEPT IN PRINCIPLE. While this is not completely redundant, the sentence is out of place.  Check and see if the new location makes it read better. The sentence is now at the beginning of 8.13.1 and says 'A DEV in PSPS mode shall listen to all system wake beacons, as announced by PNC and is required to be in the AWAKE state during system wake superframes as indicated in Table 63.'


Comment:
The first part of this sentence is a repetition of almost the same text on page 220 line 42/KO

Response:
ACCEPT IN PRINCIPLE. Modifed the sentence on line 42, it now reads 'HIBERNATE mode shall not be used in combination with any other power save mode. A DEV shall not use the PS configuration request command to set parameters for the HIBERNATE PS set.'


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

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


Comment:
[PNC Scan] Implementation wise it is preferrable to just stop beacon transmission and then start at a later time continuing from where it stopped. The reason we force the PNC to upgrade the timetoken for silent beacons is that a consistent increment is needed for SEC DEVs. On the other hand, if the PNC wants to scan it would be better to have the whole piconet silent. Unfortunately the PNC cannot just remove the CTA since that would cause dependent networks to cease operations on the current channel. A better solution would be to announce when scan starts and how long it will last./KO

SuggestedRemedy:
1) Create a new PNC Scan IE. Parameters: Suspend beacon number[16b], Quiet superframes [8b]. Add to clause 7.4. (see other comment). 2) Change text in 8.9.5, line 48-51: If the PNC initiates a scan of one or more alternate channels, the PNC shall insert the PNC scan IE with the Suspend beacon number field set to the last beacon number before the scan and the Quiet superframes set to the number of superframe durations where no beacon will be sent. The PNC scan IE shall be sent in at least one system wake beacon and at least aMinBeaconInfoRepeat beacons including that system wake beacon. After the beacon that was indicated as suspend beacon number has been sent, the PNC shall suspend beacon transmissions. The PNC shall not suspend beacon transmissions for more than twice aMinChannelScan. The PNC shall resume beacon transmission after the indicated amount of superframes. The PNC, upon returning to its current channel and resuming the transmission of its beacons, shall increment the time token field from the last beacon before the scan by one.  A DEV that receives the PNC scan IE shall suspend transmission of the indicated amount of superframes, regardless of the CTA.  A Dependent PNC that receives the PNC scan IE shall immediately insert its own PNC scan IE in its beacon


Comment:
[PM/CWB] PCTM and CWB don't work if the DEV missed its wake beacon. The rule in SPS that beacon announcements shall be done in N subsequent wake beacons, in stead of just N subsequent beacons starting with the wake beacon, makes PNC implementation unnecessarily complicated. All this calls for a unified rule for PSPS and SPS: If you miss your wake beacon, listen to the next beacon/KO

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

Response:
REJECT. The only IE affected by this is the CTA status IE which is sent in SPS wake beacons for the minimum repeat sequence. The implication is that the DEVs in SPS mode have decreased battery life in exchange for a slightly simpler implementation for the PNC.


Comment:
Replace association address with the phrase "unAssocID"  Also run a "Find and Change" search on the phrase "association address" for the rest of clause 8.

Response:
ACCEPT IN PRINCIPLE. Change instances of "association address" to "UnassocID" in clause 8.


Comment:
Please change this sentence frag. < from> "...should periodically allocate the CFP such that..." <to> "... should periodically allocate channel time in the CFP so that..."

SuggestedRemedy:
Please make the requested change so that the sentence is easier to read and understand.


Comment:
Change this sentence frag. <from> "...SPS sets to transfer." <to> "...PS sets to transfer."  The reason for the requested change is because the power management resolutions have switched to talking about all the power management schemes in terms of Power Save (PS) sets.  Please run a "Find & Change" search on the phrase "SPS set" and replace with "PS set"

SuggestedRemedy:
Please make the requested change and excute the requested Find and change search.

Response:
ACCEPT IN PRINCIPLE. There are still a few places where it is really referring to only SPS sets.  Please check to see if there are any other ones remaining that need to change.


Comment:
[PM] Remove from the table all the entries for "SPS supported in capability", "PSPS supported in capability", and "Hibernation supported in capability".  These modes are no longer indicated in the capability fields.

Response:
ACCEPT IN PRINCIPLE. As defined in the standard, these fields would always be set to one for a PNC capable DEV. Therefore there is no reason to include these in the table. Deleting these items does not change the operation or compliance of a DEV. Another editorial change, change ‘capability field’ to be ‘PNC capabilities field’ in the remaining entries where it occurs. After discussion, the commenter agreed that this comment is editorial and not technical.


Comment:
[Assoc] Please change this sentence frag. <from> "...,accept the DEVID as its address for all future communications." <to> "...accept the DEVID for all future communications."  This change will make the sentence less confusing. Address implies a 48bit MAC address and not the 8 bit assignment.

Response:
ACCEPT IN PRINCIPLE. Make the editorial change. After discussion, the commenter agreed that this comment is editorial and not technical.


Comment:
Change this sentence frag. <from> "...delay to around ns, or even..." <to> "...delay to around 33 ns, or even..."


Comment:
Change this sentence frag. <from> "...in the superframe of the CTR status IE announcement." <to> "...in the superframe of the CTA status IE announcment, (xref: CTA Status IE)."


Comment:
Change this sentence frag. <from> "...shall be set to the either ..." <to> "...shall be set to either ..."


Comment:
[CTA/Term] Delete this sentence "The stream termination field in the CTR control field shall be set to one."  It is my recollection that one of the resolutions to a LB-19 comment required the elimination of the termination bit.  If that is a valid recollection than make the requested change.  Also modify the MSCs in Figure 119 and 120 so that there is no reference to the "termination bit"

Response:
ACCEPT IN PRINCIPLE. There was not a CID in LB19 that requested the deletion of this bit.


Comment:
[Frag] Delete this sentence: "A dEV indicates its preferred fragment size for reception in the preferred frament size field in the capabilities IE,..."  There were no CIDs from LB-19 that requested this addition.  Arbitrary additions by the TE are abominable.  If the TE felt this was a necessary item to address why wasn't it raised as a comment during LB-19?  No CID, no discussion, no to its inclusion.


Comment:
Change the title  <from> "MSC showing requesting information only using probe command" <to> "MSC of DEV requesting information via the probe command"


Comment:
Change the sentence frag. <from> "...probe requests are listed in Table 57     ." <to> "...probe requests are listed in Table 57."


Comment:
[ChnlStatus] This sentence is too exclusive: "Thus, the command should only be used for DEVs that are actively participating in a data transfer as the information would not have much meaning otherwise."  The reason for this comment is that the PNC can request that all DEVs in the piconet send it(PNC) channel status responses as described in 8.11.1, item 3.  Either delete the qouted sentence above or add an additional qualifying sentence regarding the PNC.

SuggestedRemedy:
Please make one of the requested changes.

Response:
ACCEPT IN PRINCIPLE. Add a sentence following the paragraph on page 205, line 43, ‘The PNC also uses this command to get the channel status information from the DEVs in the piconet, as described in {xref 8.11.1}, {xref 7.5.6.1} and {xref 7.5.6.2}.' After discussion, the commenter agreed that this comment is editorial and not technical.


Comment:
Change this sentence frag. <from> " ThePNC may optionally allocate the CFP such that there is ..." <to > "The PNC may optioanlly allocate channel time in the CFP so that there is..."


Comment:
Delete the first sentence at the top of this page, it is redundant with the second sentence which is more informative than the first sentence.  And as we all know: Redundancy is bad.


Comment:
[TxPwr] This whole concept of reducing the maximum transmit power in the piconet seems wrong.  I could see it if we had a mechanism for overlapping piconets to negotiate a more appropriate power level but we don't.  So if I(the PNC) get an indication that one of my piconet DEVs is having trouble hearing my beacon because of its proximity to an overlapping piconet, I(the PNC) am going to reduce my power?  I don't think so, I'm going to crank it up, baby!  Consequently, I think we need to either rethink the whole concept reducing Tx power as an inteference mitigation mechanism or just delete any occurence of the concept in this document.


Comment:
Change this sentence frag. <from> "...when deciding whether to change of channel is outside of the scope of this standard." <to> "...when deciding whether to change channels is outside the scope of this standard."


Comment:
[ChnlChng] Change this sentence frag. <from> "...after it has performed a PNC channel scan,8.9.5, and ..." <to> "...after it has performed either a PNC channel scan,8.9.5, or a remote channel scan, 8.9.4, and..."  The original sentence is too restrictive in its scope and implies that an implementor can only execute a channel change after performing only a PNC channel scan.

Response:
ACCEPT IN PRINCIPLE. Add to page 211, line 38, 'Note that in addition to the PNC channel scan, the PNC is able to use other methods, describe above, to determine which channel to use as the new channel.’ After discussion, the commenter agreed that this comment is editorial and not technical.


Comment:
Change this sentence frag. <from> "...to the channel indicated in the IE at the appropriate time." <to> "...to the channel indicated in the piconet parameter change IE at the appropriate time."


Comment:
Please change this sentence frag. <from> "...shall remove the parent BSID IE from its beacon..." <to> "...shall remove the parent piconet IE from its beacon..."


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


Comment:
Change this sentence frag. <from> "...every beacon is a system wake beacons..."  <to> "...every beacon is a system wake beacon ..."  Also change this sentence frag. on page 216, line 22: <from> "Once this command is sent the DEV shall..." <to> "Once this command is sent, the DEV shall..."  And this sentence frag. on page 216, line 23: <from> "...ACTIVE mode regardless if the command was ack..." <to> "...ACTIVE mode whether the command was ack..."


Comment:
Change this sentence frag. <from> "...created and managed by PNC, but ..." <to> "...created and managed by the PNC, but ..."


Comment:
Change this sentence frag. <from> "...Both of these parameters of shall be..." <to> "...Both of these parameters shall be ..."


Comment:
Change this sentence frag. <from> "...inteval, the PNC shall terminate those streams,..." <to> "...interval, the PNC shall..."  Also change this sentence frag. on p217,line 40: <from> "...as in the ACTIVE mode regardless if the command ..." <to> "...as in the ACTIVE mode whether the command..."

SuggestedRemedy:
please make the requested spelling change to the word interval.  Also make the other requested editorial change as well.


Comment:
[PM] Please clarify the intent of this sentence which starts with these words: "In the SPS DEV DEV's next wake superframe, ..." <and ends with these words:> "...that is long enough to handle a PS change command and a channel time request command with 4 isochronous CTRBs."  Why 4 isoch CTRBs?

SuggestedRemedy:
Please clarify and if need me rewrite to make the intent clearer.

Response:
ACCEPT. Add a sentence to page 218, line 10 following the paragraph ‘This allows the SPS DEV to request a change to one of the current channel time allocations, to request new channel time or to request that a channel time allocation be terminated.’ After discussion, the commenter agreed that this comment is editorial and not technical.


Comment:
Change this sentence frag. <from> "Continue to attempt to allocate..." <to> "...Continue attempting to allocate..."


Comment:
[PM/CWB] Delete item 3 from this clause.  The use of the CWB IE in the wake beacon only works if the sleeping SPS DEV hears the wake beacon and in that case the SPS DEV doesn't need the CWB IE.  And in the other case it doesn't matter, because it can't use the info in the CWB IE because it didn't hear it.  The simpler solution is to implement the following rule:  - If the DEV is in PSPS or SPS mode, the announcement shall be made in aMinBeaconInfoRepeat subsequent beacons starting with the system or SPS wake beacon.(solution by KO)


Comment:
Missing xrefs to PS mode change command in clause 7. First missing xref is in line 41 and the second missing xref regarding disassoc is at the end of line 45.


Comment:
Change the title of figure 143 <from> "MSC for PS set inquiry command" <to> "MSC for PS set information request command"  Also it would make more sense to move Figure 143 to just before Figure 140, since the text in Clause 8.13.2.1 &2 describes the SPS set creation and management as being:  1) query PNC as to whether there are existing SPS sets via the PS set information request command 2) If one isn't available create/join an SPS set via the PS set configure command. 3) If one is available join an SPS set ia the PS set configure command. 4) and so on.


Comment:
[PNC scan] Add the new PNC scan IE to table/KO

SuggestedRemedy:
PNC scan IE, 7.4.x, aMinBeaconInfoRepeat, 8.9.5


Comment:
[PNC_HndOvr] aMaxLostBeacons used for minimum repetition of IE, but in 8.6.4 we has specified it to be aMinBeaconInfoRepeat. Change here accordingly/KO

SuggestedRemedy:
replace aMaxLostBeacons with aMinBeaconInfoRepeat and change "following that system wake beacon" to "including that system wake beacon"

Response:
ACCEPT IN PRINCIPLE. The sentence is redundant since the beacon announcement requirements are given line 20 of the same page. Delete the sentence ‘The PNC shall ensure that the beacon countdown includes at least one system wake beacon and at least aMaxLostBeacons beacons following that system wake beacon.’ After discussion, the commenter agreed that this comment is editorial and not technical.


Comment:
[ChngParms] aMaxLostBeacons used for minimum repetition of IE, but in 8.6.4 we has specified it to be aMinBeaconInfoRepeat. Change here accordingly/KO

Response:
ACCEPT. The sentence is redundant since the exact same requirement is listed in 8.6.4. On page 208, lines 30-31, change ‘parameters, the PNC shall ensure that the beacon countdown includes at least one system wake beacon and at least aMaxLostBeacons beacons following that system wake beacon.’ to be ‘parameters, the PNC shall ensure that the piconet parameter change announcement complies with the rules for beacon announcements in {xref 8.6.4}.’ After discussion, the commenter agreed that this comment is editorial and not technical.


Comment:
[ChnlChng] aMaxLostBeacons used for minimum repetition of IE, but in 8.6.4 we has specified it to be aMinBeaconInfoRepeat. Change here accordingly/KO

Response:
ACCEPT. The sentence is redundant since the exact same requirement is listed in 8.6.4. On page 212, line 6, change ‘The PNC shall ensure that the beacon countdown includes at least one system wake beacon and at least aMaxLostBeacons beacons following that system wake beacon.’ to be ‘The PNC shall ensure that the piconet parameter change announcement complies with the rules for beacon announcements in {xref 8.6.4}.’ After discussion, the commenter agreed that this comment is editorial and not technical.


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

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


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

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


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

Response:
REJECT. A directed MCTA is exactly the same as a CTA with the PNC as the destination, so the text is correct.


Comment:
[PM/MCTA] Just like with SPS, HIBERNATE DEVs needs enough MCTA to change modes when they wake up/KO

SuggestedRemedy:
Add sentence: "The PNC shall provide enough assigned MCTA or open MCTA for the DEV in HIBERNATE mode that it is able to send a PS Mode change, probe or other command to the PNC before its ATP expires."

Response:
ACCEPT IN PRINCIPLE. It would be useful to add some editorial guidance to the implementers regarding the allocation of MCTAs for power save mode DEVs. Add to page 220, line 45 ‘Because the HIBERNATE DEV will need to send a frame to the PNC at least once during its ATP, the PNC needs to take this into consideration when allocating MCTAs if the CAP is not available for commands.’ After discussion, the commenter agreed that this comment is editorial and not technical.


Comment:
[PM/MCTA] Just like with SPS, PSPS DEVs needs an MCTA to change modes when they wake up. I chose the wording "should" because there may be overload in the system wake superframe so there is no space for all MCTA, or the PNC may use another predictable cyclic allocation scheme in which case the PSPS DEVs will know when the next MCTA occurs/KO

SuggestedRemedy:
Add sentence: "The PNC should allocate assigned MCTA for PSPS DEVs or open MCTA in the system wake beacon"

Response:
ACCEPT IN PRINCIPLE. It would be useful to add some editorial guidance to the implementers regarding the allocation of MCTAs for power save mode DEVs. Add to page 215, line 52 ‘Because the PSPS DEV at some point will need to send commands to the PNC, e.g. the PS mode change command, the PNC needs to take this into consideration when allocating MCTAs if the CAP is not available for commands.’ After discussion, the commenter agreed that this comment is editorial and not technical.


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

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

Response:
REJECT. The current usage of CTRRespTime does not include the time required for getting the command to the PNC.


Comment:
[Assoc] This should be obvious, but the fact is that a dumb PNC implementation can create problems for other DEVs! Examples are PS status and PCTM. Let's plug this one/KO

SuggestedRemedy:
Add text: "When a DEV is disassociated, the PNC shall reset its bit from all relevant bitmaps in all IEs in the beacon ."

Response:
ACCEPT IN PRINCIPLE. Add to page 176, line 18, a new paragraph ‘Note that when a DEV is disassociated, it loses its DEVID and so the PNC will reset the bits that refer to this DEVID in all of the relevant bitmaps, e.g. PS status IE, PCTM IE, CWB IE.' After discussion, the commenter agreed that this comment is editorial and not technical.


Comment:
[PM/CWB] PCTM and CWB don't work if the DEV missed its wake beacon. The rule in SPS that beacon announcements shall be done in N subsequent wake beacons, in stead of just N subsequent beacons starting with the wake beacon, makes PNC implementation utterly complicated. All this calls for a unified rule for PSPS and SPS: If you miss your wake beacon, listen to the next beacon/KO

SuggestedRemedy:
Add text: "A DEV that misses its wake beacon shall listen to the following beacon".


Comment:
Delete this sentence: "A dEV indicates its preferred fragment size for reception in the preferred frament size field in the capabilities IE,..."  There were no CIDs from LB-19 that requested this addition.  If the TE felt this was a necessary item to address why wasn't it raised as a comment during LB-19?  No CID, no discussion, no to its inclusion.


Comment:
Delete item 3 from this clause.  The use of the CWB IE in the wake beacon only works if the sleeping SPS DEV hears the wake beacon and in that case the SPS DEV doesn't need the CWB IE.  And in the other case it doesn't matter, because it can't use the info in the CWB IE because it didn't hear it.  The simpler solution is to implement the following rule: "If the DEV is in PSPS or SPS mode, the announcement shall be made in aMinBeaconInfoRepeat subsequent beacons starting with the system or SPS wake beacon."


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


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


