CommentID~CommenterName~CommenterEmail~CommenterPhone~CommenterFax~CommenterCo~Clause~Subclause~Page~Line~CommentType~Comment~SuggestedRemedy~Response~CommentStatus~ResponseStatus
0~Spiess, Gary~Gary.Spiess@Intermec.com~319 369 3580~319 310 4425~Intermec Technologies~04~3~8~39~E~This clause starts with a reference to the group that wrote the recommended practice as "IEEE 802.15.2".  It is awkward in the context of a completed recommended practice~Replace "IEEE 802.15.2 has decided to select" to "This recommended practice selects".~~X~O
0~Spiess, Gary~Gary.Spiess@Intermec.com~319 369 3580~319 310 4425~Intermec Technologies~04~3.2~9~22~E~Frequency nulling is mentioned, but the definition is not easily found (or possibly unavailable.)~Add "Frequency nulling" to clause 3.1 as a definition or term.~~X~O
0~Spiess, Gary~Gary.Spiess@Intermec.com~319 369 3580~319 310 4425~Intermec Technologies~05~1~10~26~E~This discussion of stationarity indicates that the parameters are constant when they are, in fact, assumed constant.~Change "(and hence link loss) is constant." to "(and hence link loss) is assumed constant."~~X~O
0~Spiess, Gary~Gary.Spiess@Intermec.com~319 369 3580~319 310 4425~Intermec Technologies~10~2.2.6.1~47~33~TR~To the best of my knowledge, a recommended practice is not permitted to directly make changes to a standard.  A new beacon element for 802.11 violates my assumption.  The description of AFH later in the document attempts to modify 802.15, which is also beyond the license of a recommended practice.~Either correct my assumption about what a recommended practice may do, or complete the required coordination with 802.11 to insert this into the standard (possibly under QoS enhancements).  (802.15 coordination needed too)~~X~O
0~Spiess, Gary~Gary.Spiess@Intermec.com~319 369 3580~319 310 4425~Intermec Technologies~10~2.3~48~49~TR~There is insufficient information in the beacon element to determine the start of the WPAN interval.  The value of T1 is required and does not explicitly appear.  There is a mention of shared knowledge of T1, but I can't see how.~Illustrate how the knowledge of T1 is shared, or explicitly share it in the beacon element.~~X~O
0~Spiess, Gary~Gary.Spiess@Intermec.com~319 369 3580~319 310 4425~Intermec Technologies~10~3.1~51~12~E~Table 19 appears to swap "None" and "Receive" in the "in-band" and "out-of-band" locations of "receive" vs "receive".~Since table 20 defines the "receive" collision type as "in-band", then it makes sense to swap the entries in table 19 so "receive" appears in the "in-band" location.~~X~O
0~Spiess, Gary~Gary.Spiess@Intermec.com~319 369 3580~319 310 4425~Intermec Technologies~10~3.5~55~11~TR~Table 24 shows PCF reacting to denied TX requests by waiting a PIFS time before resuming operation.  I don't understand if this is an additional PIFS time, or a PIFS instead of a SIFS, or something else.  I read this to mean that the PCF is unaffected by a denial of a TX request.~Explain more fully how the PCF is affected by a denial at a TX request.~~X~O
0~Spiess, Gary~Gary.Spiess@Intermec.com~319 369 3580~319 310 4425~Intermec Technologies~12~3.3~84~50~T~The minimum number of frequencies permitted by the FCC is something on the order of 72 or 76 hops of the total 80 available.  Does eliminating 3 to 7 hops do much to enhance cooperation between technologies?  The importance of the AFH technique is not apparent.~Include a comparison of before and after AFH similar to figure 46 and its supporting text.~~X~O
0~Spiess, Gary~Gary.Spiess@Intermec.com~319 369 3580~319 310 4425~Intermec Technologies~00~~~~E~Great research, information and proposals.  Good job.~~~X~O
