2014-02-28 22:55 GMT+08:00 Tom Taylor <[email protected]>:
>
> On 28/02/2014 5:58 AM, Liu Dapeng wrote:
>
>> Hi Tom,
>>
>> Thanks for your review.
>>
>>
>> 2014-02-28 5:47 GMT+08:00 Tom Taylor <[email protected]>:
>>
>> Numerous grammatical and stylistic suggestions that I gave you in my
>>> first
>>> review haven't made it into the revision, so I won't bother with any
>>> more.
>>>
>>
>>
>> I searched the mailing list and can not find your "grammatical and
>> stylistic suggestions" comments. Do you mind to give me a pointer?
>>
>> [PTT] Sorry, I sent it to you privately as a marked-up .docx on 7 Nov
> 2013. It's only 19 kB, so I suppose I could send it to the list too, or
> just resend it. Alternatively I could work directly on something you send
> me. Let me know
[Dapeng] I am sorry that I just found this mail is in my mailbox's trash
folder. I will incorporate your changes and submit a new version this week.
Thanks for the detailed review and corrections.
>> However, there are still points where the intention isn't clear and the
>>> text needs to be tightened up.
>>>
>>> Section 4.1.2 regarding antenna configuration:
>>> ----------------------------------------------
>>> I don't understand the explanation of this field. It says each bit
>>> represents the number of antennas corresponding to that bit. Taking that
>>> literally, I could see 1+2+...+8 = a total of 36 antennas being
>>> configured.
>>> Is this what you mean, or do you mean that there are eight antennas, each
>>> bit corresponds to one of them, and the bits determine which of those
>>> eight
>>> antennas are enabled?
>>>
>>>
>> It is the latter case, only eight antennas.
>>
>> How about adding the following sentence for clarification:
>>
>> "Only one bit is allowed to be set to 1."
>>
>
> [PTT] If that is so, why do you need 8 bits and not just 3 (if you number
> the antennas starting from 0)? Are you sure this isn't a matter of
> configuring a specific set of antennas, so that multiple bits can be set?
> For example, 10010000 enables antennas 8 and 5 and disables the rest?
>
>
[Dapeng] Yes, 3 bits could also work. The 8 bits design is better to align
with current existing implementations.
>
>>
>> Section 5.1 first paragraph:
>>> ----------------------------
>>>
>>> Currently says: "... if those information element is zero ..."
>>> Do you mean that literally (I haven't looked those information elements
>>> up), or do you mean: "... if those information elements are not present
>>> ..."?
>>>
>>>
>> It should be the channel field of those information element. How about the
>> following sentence?
>>
>> "If the channel field of those information element is set to 0"
>>
>>
>> Section 5.3 explanation of scanning procedure:
>>> ----------------------------------------------
>>>
>>> Do the three parameters that determine scan operation apply to both
>>> passive and active scanning, or just to active scanning? I can get the
>>> answer by looking in Section 5.3.1, but it wouldn't hurt to say it here.
>>>
>>>
>> OK, how about adding a sentence after the first sentence in page 9:
>>
>> There are three parameters that will determine the working mode of
>> scan: PrimeChlSrvTime, On Channel ScanTime, Off Channel ScanTime. It
>> applies to both active and passive scan.
>>
>> [PTT] I believe the definitions of the On and Off Channel Scan Time
> parameters say that they apply to active mode only.
>
>>
>>
[Dapeng] Those parameters could apply to both active and passive scan.
Active and passive scan only have difference of whether sending scan probes
or not.
>
>>
>>
>> Section 5.3.1 Scan Parameter message element:
>>
>>> ---------------------------------------------
>>>
>>> The M and S bits are described as having values 1 or 2, but are only one
>>> bit wide. They should be 0 or 1.
>>>
>>
>>
>> Yes. I will change its values to 0 and 1.
>>
>>
>> You probably mean to designate that M bit is "WTP oper mode", not "AP
>>> oper
>>> mode".
>>>
>>>
>>> Yes, I will change the "AP" to "WTP".
>>
>>
>> You may want to specify what L=0 and D=0 mean.
>>>
>>>
>> I will add the following:
>>
>> L=0: Disable Load Balance Scan.
>> D=0: Disable Rouge WTP detection scan.
>>
>>
>>
>>> 5.3.4. Neighbor WTP Report:
>>> ---------------------------
>>>
>>> You should probably use phrasing similar to that of Section 4.1.1 to
>>> specify transport of the Neighbor Report Element in the 802.11
>>> Information
>>> Element, rather than talking about a new message type.
>>>
>>>
>> OK. How about changing it to the following:
>>
>> This document specifies use of the IEEE 802.11 Information Element (Type
>> 1029) that defined in section 6.6 of RFC5416 and IEEE 802.11 Neighbor
>> Report Element that defined in section 8.4.2.39 of IEEE-802.11.2012 to
>> carry the neighbor WTP report message.
>>
>> [PTT] The point is that there is no such thing as the neighbour WTP
> report message. The sentence should be:
>
> "This document specifies use of the IEEE 802.11 Information Element (Type
> 1029) defined in section 6.6 of RFC5416 to carry the IEEE 802.11 Neighbor
> Report Element defined in section 8.4.2.39 of [IEEE-802.11.2012], possibly
> along with other IEEE 802.11 elements."
>
> [Dapeng] OK, will be incorporated in the new version and re-submit again
within this week.
Thanks again for the kind review and help.
Cheers,
Dapeng Liu
>
>> Cheers,
>> Dapeng Liu
>>
>> _______________________________________________
>>> OPSAWG mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/opsawg
>>>
>>>
>>
>>
>>
--
------
Best Regards,
Dapeng Liu
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
