Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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