There was an error when I sent the email below to the REVme reflector yesterday. Retrying again.
From: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>
Sent: Friday, February 17, 2023 11:07 AM
To: m.rison@xxxxxxxxxxx; STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11] REVme: resolution for CID 3000
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Hi Mark,
Thank you for your email.
I am fine with the additional text you suggested.
>> [What are examples of "the behavior at the receiver is clearly defined (i.e., to ignore the reserved value)"?
>> Are there any outside Clause 12?]
Yes, I found some instances in other clause (see P1891 L01, L31, L50 in D2.1) where there is a behavior associated when a certain (reserved) value is received.
Take for example the following instance in clause 11 (P2642):
There are many other such instances (outside clause 12).
Therefore, we can’t say the behavior is undefined at the receiver.
Your proposed addition (“unless otherwise specified”) will address it.
Regards,
Abhi
From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Friday, February 17, 2023 9:21 AM
To: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>;
STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11] REVme: resolution for CID 3000
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
[Restricting to TGm reflector to avoid spamming the world.]
The group came-up with the following text for the receive side [second sentence on line 36 page 574]:
"Upon reception of a reserved value in a field or subfield, the behavior is undefined."
However, there is a debate on whether or not we need to specify anything for the receive side. For instance, there are occasions where the behavior at the receiver is clearly defined (i.e., to ignore the reserved value) and therefore, it
is incorrect to say the receive side behavior is undefined. Personally, I feel, we should delete the sentence and leave the behavioral aspects to the pertinent clauses (which is already the case at several instances in the spec).
I do think we need to make it clear that using reserved values in
non-reserved fields will in general have unpredictable effects.
Note that the scope of all this is just Clause 9, so anything
in say Clause 12 about needing to ignore reserved values is not
affected. However, we could make this clear like this:
"Upon reception of a reserved value in a field or subfield, the behavior is, unless otherwise specified, undefined."
[What are examples of "the behavior at the receiver is clearly defined (i.e., to ignore the reserved value)"?
Are there any outside Clause 12?]
Thanks,
Mark
--
Mark RISON, Standards Architect, WLAN English/Esperanto/Français
Samsung Cambridge Solution Centre Tel: +44 1223 434600
Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601
ROYAUME UNI WWW:
http://www.samsung.com/uk
From: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>
Sent: Friday, 17 February 2023 16:34
To: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11] REVme: resolution for CID 3000
--- This message came from the IEEE 802.11 Working Group Reflector ---
Hi All,
Thank you for the discussion during today's REVme call. We made some more progress on the topic but could not reach consensus on a mutually agreeable text.
After a few iterations between different members, the group seemed to have stabilized on the following text for the transmit side [replacement to line 36 page 574 in REVme D2.0]:
"In a field or subfield, values that are reserved for that field or subfield are not used for transmission."
The group came-up with the following text for the receive side [second sentence on line 36 page 574]:
"Upon reception of a reserved value in a field or subfield, the behavior is undefined."
However, there is a debate on whether or not we need to specify anything for the receive side. For instance, there are occasions where the behavior at the receiver is clearly defined (i.e., to ignore the reserved value) and therefore, it
is incorrect to say the receive side behavior is undefined. Personally, I feel, we should delete the sentence and leave the behavioral aspects to the pertinent clauses (which is already the case at several instances in the spec).
I'd like to hear if there any further suggestions for the text on the transmit side and opinions on deleting the text for the receive side.
Regards,
Abhi
From: Stephen McCann <mccann.stephen@xxxxxxxxx>
Sent: Monday, February 13, 2023 2:24 AM
To: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>
Cc: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11] REVme: resolution for CID 3000
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Abhi,
thanks. I think your
proposed text is good.
Kind regards
Stephen
On Mon, 13 Feb 2023 at 04:16, Abhishek Patil <appatil@xxxxxxxxxxxxxxxx> wrote:
--- This message came from the IEEE 802.11 Working Group Reflector ---
Hi All,
TGm had discussed the proposed resolution for CID 3000 (DCN: 11-22/2208) during the January meeting but could not come to an agreement. This email is a follow-up to continue with the discussion and make progress towards a suitable resolution.
CID
Commenter
Pg/Ln
Section
Comment
Proposed Change
3000
Abhishek Patil
574.35
9.2.2
What is the purpose of the paragraph starting line 36? Per the previous paragraph (line 30), a reserved field/subfield is set to 0 by the transmitter and is ignored by the receiving STA. In addition, the 2nd sentence of paragraph starting line 36 seems to conflict with the receiver side requirement on line 30 (i.e., ignore vs undefined).
Either delete the paragraph starting line 36 or harmonize it with that on line 30.
Brief summary of the discussion (during the Jan meeting):
The first paragraph is meant to cover the case of reserved (sub)fields while the second paragraph (being modified) is intended to cover the case of reserved values. The proposal was to modify the second paragraph to clarify reserved values carried in non-reserved (sub)field. The group could not converge on a suitable text. Two alternatives were considered.
--------
9.2.2 Conventions[3000]
TGm editor: Please update the following paragraphs in this subclause as shown below:
Reserved fields and subfields defined in this clause are set to 0 upon transmission and are ignored upon reception.
NOTE 2—This applies to reserved fields and subfields in MAC headers. Reserved fields and subfields in PHY headers might be set to a nonzero value upon transmission, and might not be ignored upon reception.
Reserved field and subfield values are not used upon transmission.Upon reception of a reserved field or subfield value, the behavior is undefined.Proposed text: Reserved values are not used in non-reserved fields and subfields upon transmission. Upon reception of a reserved value in a non-reserved field or subfield, the behavior is undefined. Alternate text: In non-reserved fields and subfields, reserved values result in undefined behavior upon reception.
--------
Could you please review the proposed text and let me know if you have a preference or suggest an alternate?
Regards,
Abhi
To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1
To unsubscribe from the STDS-802-11 list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1
|
|
To unsubscribe from the STDS-802-11-TGM list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1
To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1