CommentID~CommenterName~CommenterEmail~CommenterPhone~CommenterFax~CommenterCo~Clause~Subclause~Page~Line~CommentType~Comment~SuggestedRemedy~Response~CommentStatus~ResponseStatus
0~Myles, Andrew~andrew.myles@cisco.com~+61 2 84461010~+61 418 656587~Cisco~00~~~~TR~The draft consists of a number of ideas supported by detailed simulations. Most of the ideas will never be implemented in practice (particularly the collaborative mechanisms and the mechanisms that require communictations between entities) and it is not even clear that the simulations are valid given their limited scope~File the document away as an interesting set of ideas and let the market forces develop appropriate solutions. Giving the document the status of recommended practice at this stage implies we understand the spectrum of solutions and can make a reasonable recommendation; we can't!~~X~O
0~Myles, Andrew~andrew.myles@cisco.com~+61 2 84461010~+61 418 656587~Cisco~01~1.1~~~E~The first paragraph is a list (or non sentences) that needs an introduction~Add introduction to list~~X~O
0~Myles, Andrew~andrew.myles@cisco.com~+61 2 84461010~+61 418 656587~Cisco~01~1.1~1~49~TR~The scope includes "to suggest modifications to other IEEE 802.15 standard(s) to ..." Why does this practice "suggest modifications" to other 802.15 standards? Wouldn't it be more sensible to actually change the standards themselves rather than making it a two step process.~Change scope so that this document provides "guidelines for all current and future 802.15 standards to ensure interoperability"~~X~O
0~Myles, Andrew~andrew.myles@cisco.com~+61 2 84461010~+61 418 656587~Cisco~01~1.1~~~TR~The scope is confusing; the first paragraph appears to suggest a wide scope including all 802.15 now and into the future. The second paragraph limits the scope to just current 802.11h. Which is it?~Clarify~~X~O
0~Myles, Andrew~andrew.myles@cisco.com~+61 2 84461010~+61 418 656587~Cisco~01~1.2~~13~E~What is a "project"?~Clarify~~X~O
0~Myles, Andrew~andrew.myles@cisco.com~+61 2 84461010~+61 418 656587~Cisco~01~1.1~~~TR~Line 3 claims 2Mb/s is included; line 7 claims it is not. Which is it?~Clarify~~X~O
0~Myles, Andrew~andrew.myles@cisco.com~+61 2 84461010~+61 418 656587~Cisco~01~1.2~~~E~"802.119" should be "802.11"~Fix~~X~O
0~Myles, Andrew~andrew.myles@cisco.com~+61 2 84461010~+61 418 656587~Cisco~03~3.1.4~~~TR~0.5 metres appears arbitrary; on what basis is this distance chosen?~Insert a functional definition for colocation~~X~O
0~Myles, Andrew~andrew.myles@cisco.com~+61 2 84461010~+61 418 656587~Cisco~03~3.1.4~~~E~"meter" is spelt "metre", even in US English!~Fix~~X~O
0~Myles, Andrew~andrew.myles@cisco.com~+61 2 84461010~+61 418 656587~Cisco~03~3.1.6~~~E~"data" should be "Data"~Fix~~X~O
0~Myles, Andrew~andrew.myles@cisco.com~+61 2 84461010~+61 418 656587~Cisco~03~3.1.7~~~E~"It is a" should be "A"~Fix~~X~O
0~Myles, Andrew~andrew.myles@cisco.com~+61 2 84461010~+61 418 656587~Cisco~03~3.1.8~~~E~"In a communication system, extraneous" should be "Extraneous"~Fix~~X~O
0~Myles, Andrew~andrew.myles@cisco.com~+61 2 84461010~+61 418 656587~Cisco~00~~~~TR~The document contains too much "why" (with very detailed supporting equations and simulations) rather than a concise statement of the problem and a recommended solution (or solutions)~At the very least remove all the "why" to an appendix~~X~O
0~Myles, Andrew~andrew.myles@cisco.com~+61 2 84461010~+61 418 656587~Cisco~03~3.1.11~~~E~"fading" should be "Fading"~Fix~~X~O
0~Myles, Andrew~andrew.myles@cisco.com~+61 2 84461010~+61 418 656587~Cisco~03~3.3~~~TR~fhop is claimed to be a frequency and yet the definition seems top refer to channel numbers. Is is a frequency or a channel number?~Clarify~~X~O
0~Myles, Andrew~andrew.myles@cisco.com~+61 2 84461010~+61 418 656587~Cisco~04~~~~E~".." should be "."~Fix~~X~O
0~Myles, Andrew~andrew.myles@cisco.com~+61 2 84461010~+61 418 656587~Cisco~04~4.1~~~TR~Presumably the recommended practice is more restrictive than just "IEEE 802.11 WLANS"; it should be 802.11 WLANS operating in 2.4GHz bands~Fix~~X~O
0~Myles, Andrew~andrew.myles@cisco.com~+61 2 84461010~+61 418 656587~Cisco~04~4.1.2~~~E~"to in increase" should be "to an increase"~Fix~~X~O
0~Myles, Andrew~andrew.myles@cisco.com~+61 2 84461010~+61 418 656587~Cisco~10~10.2.3~~~TR~The equations do not cover all cases, eg when RTS/CTS is sent before a packet/ACK~Fix~~X~O
0~Myles, Andrew~andrew.myles@cisco.com~+61 2 84461010~+61 418 656587~Cisco~10~10.2.4~~~TR~The clause does not make clear in what period the CTS is transmitted. If it is sent in the WLAN period there will be cases in which it would not be sent at all. If it is sent in the WPAN period the 802.15.1 master had better know about it~Clarify~~X~O
0~Myles, Andrew~andrew.myles@cisco.com~+61 2 84461010~+61 418 656587~Cisco~10~10.2.4~~~TR~Why wouldn't you want to use the CTS to itself technique to stop all transmission during the WPAN period? It seems strange that other AP's on the same channel are alllowed to transmit~Clarify~~X~O
