CommentID~CommenterName~CommenterEmail~CommenterPhone~CommenterFax~CommenterCo~Clause~Subclause~Page~Line~CommentType~Comment~SuggestedRemedy~Response~CommentStatus~ResponseStatus
0~Black, Simon~simon@motix.demon.co.uk~ ~+44 7780 677453~Qosine~01~1.1~2~7~E~Remove editors note referring to 2Mbps. 2Mbps is part of 802.11b and therefore this not is incorrect.~Remove editors note~~X~O
0~Black, Simon~simon@motix.demon.co.uk~ ~+44 7780 677453~Qosine~01~1.1~2~21~E~Typo IEEE802.119 should be IEEE802.11b~Fix~~X~O
0~Black, Simon~simon@motix.demon.co.uk~ ~+44 7780 677453~Qosine~04~4.1~6~26~T~This introductory clause says that the scope of this document is limited to DCF and  does not address PCF. However, Table 24 in 10.3.5 addresses how PTA functions for PCF. ~Correct introductory text, or remove PCF behaviour in PTA.~~X~O
0~Black, Simon~simon@motix.demon.co.uk~ ~+44 7780 677453~Qosine~04~4.1~6~36~E~This high-rate PHY is often referred to as IEEE802.11b. It is not often referred to but was standardized as IEEE802.11b!~Use standardized.~~X~O
0~Black, Simon~simon@motix.demon.co.uk~ ~+44 7780 677453~Qosine~05~~9~36~E~This document would be easier for a new reader if the analytical work that is the background to the actual recommended practice was moved to an annex (this applies to sections 5 through 8).~Consider dividing the document into a recommended practice body and informative simulation/analysis annexes.~~X~O
0~Black, Simon~simon@motix.demon.co.uk~ ~+44 7780 677453~Qosine~10~~40~28~TR~No new on-air signalling is required. However, a new information element for beacon and probe response management frames is defined. Sounds like new on-air signalling. This together with new MLME primitives and MIB extensions seems to be defining extensions to the 802.11 MAC. Given this is the case I dont see how this can be a recommended practice since it is defining new protocol elements and modifying the behaviour of the 802.11 MAC - it has to become a new 802.11 standard surely.~I dont believe that modifications to the 802.11 MAC are permitted within the scope of a 802.15 recommended practice. Therefore, either this has to be a new 802.11 standard, or the functionality has to be built on top of the existing MAC without modification (like 802.11 TGh has). Maybe it would be possible to still have this coexistence mechanism by assuming that implementations following the recommended practice have a view of the internal state of the MAC but surely new elements, primitives and the like are out. Even if this view is not the case, there does seem to be new on-air signalling!~~X~O
0~Black, Simon~simon@motix.demon.co.uk~ ~+44 7780 677453~Qosine~10~10.2.2~43~30~TR~Timing values to be distributed through the WLAN network management tool (i.e. outside the scope of this recommended practice). This implies that the element defined is not actually required and that some 802.15.2 MIB is being set by a higher layer protocol. If that is the case why define the element at all (which is outside the scope of a 802.15 recommended practice). I also note that (a) these need to get into STAs before active scanning to avoid getting management frames sent in the WPAN period, and (b) some description of IBSS operation is required.~This coexistence mechanism seems to be very confused. Either remove it, or rewrite it to be (a) self-consistent and (b) consistent with a recommended practice. Does it use a side channel, or new elements for parameter communication? Are the parameteters set by the AP in an infrastructure BSS? Are they set by the STA that starts an IBSS? Do other IBSS STAs inherit the values when they join?~~X~O
0~Black, Simon~simon@motix.demon.co.uk~ ~+44 7780 677453~Qosine~10~10.2.2.1~43~40~TR~New 802.11 MLME primitives are outside the scope of this recommended practice. If it is possible to specify this coexistence mechanism without change to the 802.11 MAC then this MIB should be defined as an 802.15.2 MIB.~It is not possible to change, or add to the 802.11 MAC from this document (I believe). Redefine this coexistence mechanism to use the existing MAC and define any new functionality separately. Maybe it is OK to say that implementations following the recommended practice have a view of the internal state of the 802.11 MAC? Even if MLME additions are allowed, there is no need for new primitives. This interface would be better done using MLME-GET/SET on the new MIB attributes defined (with the addition that it would be nice to have a capability MIB attribute too).~~X~O
0~Black, Simon~simon@motix.demon.co.uk~ ~+44 7780 677453~Qosine~10~10.2.3~50~17~TR~Firstly see comments from this author on appropriate scope for an 802.15  recommended practice. Second the 802.11 MAC behaviour around the start and end of the WPAN interval needs to be more precisely defined, for example, do STAs that defer due to a pending WPAN period select a backoff value, increment their retry counters, etc.. ~If I'm incorrect about it being inappropriate for this 802.15 recommended practice to add to, or modify the 802.11 MAC, then specify explicitly the MAC behaviour around the WPAN period, including back-off, IFSs used and retry counter behaviour. See the behaviour of the .11 MAC around dwell boundaries for an example.~~X~O
0~Black, Simon~simon@motix.demon.co.uk~ ~+44 7780 677453~Qosine~10~10.2.4~50~23~TR~The 802.11 MAC does not allow the transmission of a CTS frame in isolation with a specific duration value. This frame exchange sequence and duration setting facility simply do not exist in the current 802.11 MAC. This is one reason why in the IEEE802.11 TGh draft we have defined a new quiet period mechanism (an aside is that even if it did exist the duration is limited to 32Kus). Note that (a) even if this CTS mechanism existed it would be imperfect and (b) the group addressing scheme to involve other APs violates the current rules further. This latter point is due to the fact that CTS is not used in multicast communication. ~Remove this mechanism as no such facility exists and it overloads the CTS functionality.~~X~O
