Re: [STDS-802-11-EDITORS] Draft REVmc MDR
--- This message came from the IEEE 802.11 Editors' Reflector ---
Hi Adrian,
> Regarding "is set to", I will admit there are many occasions when the usage is ambiguous. My take on this is that when it
> relates to putting a value in a field, or is a reference to the value of a field, in the context of putting the value in the field, or
> possibly in the context of what to transmit, "is set to" is correct.
As per the description related to Style 2.3, it reads
" The verb “set” should only be used when describing how a field
obtains a value, e.g. “The Measurement Duration field is set to the
preferred or mandatory duration of the requested measurement,
expressed in units of TUs.”"
and
"Where the value of the field is read or referenced, (e.g., in the
context of a condition), °is set to" shall not be used.".
For me, I will interpret this rule differently with the first two
examples you mention:
> So, looking at some at random from your long list:
> 146.56: " Beacon frame is transmitted during active scanning with the Discovery Mode field set to 1"
>
> I think this is one of the ambiguous cases.
>
> 426.56: " If LinkMetricRequestFlag is equal to REPORT_ONLY, the Request subfield is set to 0. "
> This clearly describes the act of setting the contents of the subfield,
> so it is OK as is.
It is because both describe a scenario that the value of the
field/subfield is read in the context of a condition.
I would definitely review the case again but I would like to ask for
an appropriate interpretation on this rule. Please kindly advise.
Regards,
Edward
On Mon, Jul 7, 2014 at 6:46 PM, Stephens, Adrian P
<Adrian.P.Stephens@xxxxxxxxx> wrote:
> Hello Edward,
>
> I have some issues with these findings. We will need to discuss them.
>
> Regarding state variables exported by 802.1X, I think we have to adopt
> the terminology TRUE used there. We can use our own terminology when defining our own state machines. So the question is whether the large numbers of "TRUE" reported relate to material we are incorporating by reference, or is our own invention.
>
> Regarding "is set to", I will admit there are many occasions when the usage is ambiguous. My take on this is that when it relates to putting a value in a field, or is a reference to the value of a field, in the context of putting the value in the field, or possibly in the context of what to transmit, "is set to" is correct.
>
> One learning from this exercise might be to define these rules more precisely. However, in ambiguous cases we should either get a ruling from TGmc, or apply the "conservative" approach of making no change.
>
> So, looking at some at random from your long list:
> 146.56: " Beacon frame is transmitted during active
> scanning with the Discovery Mode field
> set to 1"
>
> I think this is one of the ambiguous cases.
>
> 426.56: " If LinkMetricRequestFlag is equal to REPORT_ONLY, the Request subfield is set to 0. "
> This clearly describes the act of setting the contents of the subfield,
> so it is OK as is.
>
> 556.63: " In frames transmitted by the PC and non-QoS STAs, during the CFP, the Duration/ID field is set to a fixed value of 32 768."
> This describes setting the value of the field, so it is OK.
>
> 606.15: " All STAs use frames with the QoS subfield of the Subtype field set to 0 for nonconcealed GCR group addressed Data frames"
> I think this is ambiguous. Needs discussion.
>
> 756.12: " The Measurement Method field indicatesthe method that is to be used by the Requested STA to carry out this measurement request and report back in the measurement report. If this field is set to 0, it indicates
> ANIPI. If this field is set to 1, it indicates RCPI. If the field is set to2, it indicates Channel Load. Other values are reserved."
>
> While "If ... is set to 0" sounds like a condition or test, it is not.
> It is in the context of describing what to put in the field.
> It could be reworded "The value 0 indicates ANIPI", or "Set to 0 to indicate ANIPI". It is overly wordy as is, but I think the current usage is OK.
>
> 1015:05: " The Non-QoS Data Frames field specifies whether non-QoS Data frames can be transmitted in the frequency band indicated in the New Band ID field. If the Non-QoS Data Frames field is set to 0, non-QoS Data frames
> cannot be transmitted in the frequency band indicated in the New Band ID field. If the Non-QoS Data Frames field is set to 1, non-QoS Data frames can be transmitted in the frequency band indicated in the New Band ID field."
> Same argument as above.
>
> I picked these locations randomly from your list. I disagree with the changes in every case.
>
>
> Would you be willing to review your list according to this understanding?
> If necessary we can talk about the criteria.
>
> Alternatively, we can bring the topic for discussion to TGmc, and you might get an action to review usage as an editor in TGmc.
>
>
> Best Regards,
>
> Adrian P STEPHENS
>
> Tel: +44 (1793) 404825 (office)
> Tel: +44 (7920) 084 900 (mobile, UK)
> Tel: +1 (408) 2397485 (mobile, USA)
>
> ----------------------------------------------
> Intel Corporation (UK) Limited
> Registered No. 1134945 (England)
> Registered Office: Pipers Way, Swindon SN3 1RJ
> VAT No: 860 2173 47
>
> -----Original Message-----
> From: Edward AU [mailto:edward.ks.au@xxxxxxxxx]
> Sent: 04 July 2014 14:48
> To: Stephens, Adrian P
> Cc: STDS-802-11-EDITORS@xxxxxxxxxxxxxxxxx
> Subject: Re: [STDS-802-11-EDITORS] Draft REVmc MDR
>
> Hi Stephen, Peter,
>
> Sorry for my late reply - enclosed please find approximately 700
> comments related to Styles 2.2 and 2.3. Ahhh ... I am still
> reviewing the draft for Styles 2.1.2 and 2.8. More comments are expected in very near future.
>
> Regards,
> Edward
>
> On Fri, Jul 4, 2014 at 7:18 PM, Stephens, Adrian P <Adrian.P.Stephens@xxxxxxxxx> wrote:
>> --- This message came from the IEEE 802.11 Editors' Reflector ---
>>
>> Dear Editors,
>>
>>
>>
>> I have compiled your individual contributions into the attached document.
>>
>>
>>
>> Can you please:
>>
>> 1. Check that your contribution is present and your name is in the
>> acknowledgments if you contributed
>>
>> 2. Review at least your contribution for changes I made. If you
>> don’t like the changes, make comments or tracked changes and send to me.
>>
>> 3. Feel free to review and comment on the changes made by others.
>>
>>
>>
>> Best Regards,
>>
>>
>>
>> Adrian P STEPHENS
>>
>>
>>
>> Tel: +44 (1793) 404825 (office)
>> Tel: +44 (7920) 084 900 (mobile, UK)
>>
>> Tel: +1 (408) 2397485 (mobile, USA)
>>
>>
>>
>> ----------------------------------------------
>> Intel Corporation (UK) Limited
>> Registered No. 1134945 (England)
>> Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47
>>
>>
>>
>> _______________________________________________________________________________
>>
>> IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your
>> request to this CLOSED reflector. We use this valuable tool to communicate
>> on the issues at hand.
>>
>> SELF SERVICE OPTION: Point your Browser to -
>> http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-EDITORS and then
>> amend your subscription on the form provided. If you require removal from
>> the reflector press the LEAVE button.
>>
>> Further information can be found at:
>> http://www.ieee802.org/11/Email_Subscribe.html
>> _______________________________________________________________________________
--
_______________________________________________________________________________
IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this
CLOSED reflector. We use this valuable tool to communicate on the issues at hand.
SELF SERVICE OPTION:
Point your Browser to - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-EDITORS
and then amend your subscription on the form provided. If you require removal from the
reflector press the LEAVE button.
Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html
_______________________________________________________________________________