Re: [STDS-802-11-TGAF] Additional comments on TGaf/D2.0
Mark:
We are always looking to improve our draft. Having achieved a 79.1% approval in LB 189, we have to focus on the comments received as part of the ballot. Help us get through those as fast as possible, and then we can look at your improvements. If in in fact they address accepted comments, your submissions can be reviewed in that context.
We don't turn anyone away who wants to make this better.
Rich
Rich Kennedy
Standards Manager
Research In Motion Corporation
mobile: +1 (972) 207-3554
office: +1 (972) 910-3448
rikennedy@xxxxxxx
IEEE 802.11 TGaf Chair
IEEE 802.11 to 802.18 Liaison
IEEE 802.11 Regulatory Standing Committee Chair
Wi-Fi Alliance Spectrum & Regulatory Task Group Chair
----- Original Message -----
From: Mark Rison [mailto:Mark.Rison@xxxxxxx]
Sent: Thursday, August 30, 2012 08:07 AM
To: STDS-802-11-TGAF@xxxxxxxxxxxxxxxxx <STDS-802-11-TGAF@xxxxxxxxxxxxxxxxx>
Subject: [STDS-802-11-TGAF] Additional comments on TGaf/D2.0
I would like to present the following additional comments on TGaf/D2.0
for the group's consideration, though I realise they are outside the
time limits, in the hope they will be useful. I apologise if any of
them betray my lack of understanding of TGaf!
References are of the form P.L where P is the logical page number (it
would be good for this to be aligned with physical page numbers in the
future -- Adrian Stephens can tell you how to achieve this) and L is
the line number.
- The para at 40.8 is rather confusing. I think (but am not sure!)
what it is trying to say would be better expressed as:
The Validity field is present if and only if the Device Class is not 0.
[this could be put in Table 8-14k instead]
The field tuple consisting of the Channel Number, Maximum Power
Level and, where present, Validity fields is called the Channel
Availability tuple and is present one or more times in the WSM
Information, as implied by the Length field, after the Map ID field
and before any Maximum Channel Bandwidth field, where present.
- The example at 42.4 does not seem to include a Maximum Channel Bandwidth
field, but nothing indicates that this field is optional (if this is
an error and it's not optional, then delete the last ", where present"
and replace the last "any" with "the" in my previous comment).
- 41.11 talks of "the following channel list is". But where is
this following channel list defined? I'm guessing this should be
"the following Channel Availability tuple(s) define(s)".
- 35.35 says I'm supposed to discard TLV tuples with an unknown Type,
but how can I do so if I don't know how many octets the Length is
(since it's variable and dependent on the Type)?
- 41.7 says that in the Device Class field there's a TLV comprised of
the values in 8-14b, but I think that's not true, from the example at
41.62: the Device Class field value is a single octet from 8-14b.
- I can't work out how the STA can be sure it gets all the fragments,
in the case of a partial channel list. Or are all frames in which
the WSM element is sent always unicast?
- 59.41 says that "The WSM Information field is described in the White
Space Map element (see 8.4.2.174 (White Space Map element))." but this
is not true: the WSM *Information* is described in 8.2.6.1.6.
Ditto 65.57.
- Why do some frames carry WSM elements while others only carry WSM
Information (i.e. no WSM Type), anyway?
- 68.9 suggests you can have multiple WSM elements in the
GDC Enablement Response frame but 68.34 suggests you can't.
- I understand someone has already made this comment, but: why do we
need TLVs if we already have information elements, which are
type-length-value triplets too?
Some editorials, also:
- Isn't "TLV values" a bit pleonastic?
- "The format of the TVHT Operation element is defined in Figure
8-401cl (WSM element format)" is broken.
- It should be "WSM element" or "White Space Map element" but not
both, as this sows doubt and is awkward to search for.
- "When WSM Type is '1', it indicates the WSM Information field of the
WSM element containing the available frequency information for the
operation in the TVWS. Other values are reserved." duplicates info in
Table 8-183ab.
Mark
--
Mark RISON, Systems Architect, Wi-Fi English/Esperanto/Francais
CSR, Cambridge Business Park Tel: +44 1223 692000
Cowley Road, Cambridge CB4 0WZ Fax: +44 1223 692001
ROYAUME UNI WWW: http://www.csr.com
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog