Abhi, all,
The first sentence is fine; in fact, it seems to be an improvement.
For the second sentence, I continue to struggle with the use of the word “undefined”, for reasons I’ve outlined earlier in this thread. It occurred to me that maybe there is
an alternative, which I’d like to throw out for consideration.
Leaving aside wordsmithing, the rough idea is
“Upon reception of a reserved value in a field or subfield, the set of requirements applicable to the STA is the same as it was immediately prior to the reception of the field
or subfield.”
The trouble with “reserved” / “ignore” / “undefined” is that there are very many cases to consider, some quite difficult (how do we deal with devices that use reserved bits
and fields for proprietary modes?). But isn’t it the case that receiving a reserved bit or field value should change nothing as far as the IEEE 802.11 standard is concerned? i.e., the value is “null” in some sense. Rewording in this way might finesse some
of the difficulties with “ignore” (which is not always possible, if the permitted values cover all possibilities) and “undefined” (which has the connotation of “all bets are off”).
Regards,
Sean
From: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>
Sent: Friday, February 24, 2023 11:42 PM
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] [STDS-802-11] REVme: resolution for CID 3000
|
External mail.
|
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Hi All,
Thank you for the discussion and feedback on this topic.
Any thoughts on the following text? I have revised the transmit side text to clearly states that you can’t set a (sub)field to a value that is reserved for it. And for the
receive side, I have included the additions (‘unless otherwise specified’) suggested additions by Mark.
During transmission, a field or a subfield is not set to a value that is reserved for that field or subfield.
Upon reception of a reserved value in a field or subfield, the behavior is, unless otherwise specified, undefined.
Regards,
Abhi
From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Tuesday, February 21, 2023 1:39 PM
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] [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.
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
It is not in general possible to ignore a reserved value in a non-reserved
field. Examples:
- HT Operation or Secondary Channel Offset element with Secondary Channel
Offset field set to 2. Where is the secondary channel? (I suppose you
could conservatively behave as if there's no secondary channel? But you
can't just ignore the field.)
- Channel Switch Announcement frame with Channel Switch Mode field
set to 2. Can you continue to tx until the channel switch instant?
(Maybe assume not? But you can't just ignore the field.)
- Block Ack frame with the BA Type field set to 15, after tx of an
A-MPDU. Is this acking something? What is the format of the BA
Information field if it is?
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: Jon Rosdahl <jrosdahl@xxxxxxxx>
Sent: Tuesday, 21 February 2023 20:35
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] [STDS-802-11] REVme: resolution for CID 3000
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
I would say that "ignore" is the better path.
We say in many places if a STA does not know what something is, then ignore it.
If it is important, then we should define it differently.
FWIW,
Jon
-----------------------------------------------------------------------------
Jon Rosdahl Engineer, Senior Staff
IEEE 802 Executive Secretary Qualcomm Technologies, Inc.
office: 801-492-4023 10871 North 5750 West
cell: 801-376-6435 Highland, UT 84003
A Job is only necessary to eat!
A Family is necessary to be happy!!
On Tue, Feb 21, 2023 at 11:37 AM Sean Coffey <coffey@xxxxxxxxxxx> wrote:
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Hi Joe, Abhi, Mark, and all,
I would prefer language that deletes the word “undefined” everywhere.
What exactly are we trying to achieve by including this word? In particular, just how far do we think the “undefined” behavior can go? For example, suppose a receiver encounters a reserved value that triggers “undefined” behavior in a PPDU that is not addressed to it, and interprets that as “treat the current PPDU as noise, and revert to backoff counter countdown”. Is that permissible? There is precedent for this exact interpretation.
In some ways, adding a statement that the behavior is undefined makes matters worse than saying nothing at all, because it might be taken to imply that the standard is authorizing any receiver behavior.
There must be some limits on what a receiver can do. It would be better to define those limits and leave it at that.
Regards,
Sean
From: Joseph Levy <000019588066c6b7-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Monday, February 20, 2023 6:39 AM
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] [STDS-802-11] REVme: resolution for CID 3000
External mail.
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
HI Abhi, Mark, and All –
Abhi – thanks for digging through the standard to find the text you provided. Unfortunately, I believe the text only applies to the case it addresses – the requirement is that a STA when receiving a GAS frame process the whole frame even if it finds an unknown or reserved value, if the frame is received without error. This is critical for GAS as it is possible that a STA may not know all the values sent in a GAS frame and receiving such a value should not stop the STA from receiving the rest of the values in the GAS frame. The general case we are dealing with is the reception of a reserved value in any field or subfield, the general case.
Therefore:
I would favor a more direct wording in the transmission requirement:
“Reserved values for a field or subfield shall not be used in a transmitted field or subfield.”
And I support Mark’s proposal to include “unless otherwise specified”, but suggest the following text:
"A STA’s behavior when a reserved value is received in a field or subfield is undefined, unless otherwise specified."
Regard,
Joseph
From: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>
Sent: Saturday, February 18, 2023 1:37 PM
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] [STDS-802-11] REVme: resolution for CID 3000
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
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
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
------Please consider the environment before printing this e-mail.
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
|
|
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
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