Hi Xiangxin, Jay, Zhenpeng,
Thanks for clarifying the intent. I understand now.
I don’t have a strong opinion, but I think simply removing “corresponding” from the current sentence is a simple and sufficient for now.
Zhenpeng, since everyone seems to be okay, I guess we can go with that.
Best regards,
Gaius
From:
顾祥新 (Xiangxin Gu) <000046f9987a2d10-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Wednesday, 26 November 2025 9:06 am
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] Follow-up discussion on 25/1869 CR for MAPC agreement negotiation
Hi Jay, Gaius and Zhenpeng,
Sorry for the misleading. My intention is like what Jay said, like
“The Status Code field shall be set to SUCCESS if the MAPC responding AP
accepts at least one of the requests carried in the received MAPC Negotiation Request frame. Otherwise,
the field shall be set to corresponding Status code to indicate a specific rejection as per Table 9-92 (Status codes).”
Just removing
“corresponding”
from the currently sentence also works.
BR,
Xiangxin Gu
Institute of Communication Technology
From: Jay Yang
<yang.zhijie@xxxxxxxxxx>
Sent: Wednesday, November 26, 2025 8:03 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] Follow-up discussion on 25/1869 CR for MAPC agreement negotiation
Hi All,
That's an interesting topic. I would like to jump in the discussion.
If I understand correctly, Xiangxin wants to have something like "The
Status Code field shall be set to SUCCESS if the MAPC responding AP accepts at least one of the requests carried in the received MAPC Negotiation Request frame. Otherwise, the MAPC
responding AP shall set the corresponding
value of the Status Code field to
indicate …" But, the _expression_ " value of ...field" is deprecated in editorial style guide document(09/1034r21).
Also, removing "corresponding" works to me, as Zhenpeng mentioned during the call, there is only one Status Code field in this frame, and no need
to stress the "corresponding" here. It looks like "if condition A is met, the field is set to XX; otherwise, the field is set to YY(s).."
Welcome your further opinion.
Thanks
Best Regards
Jay Yang (杨志杰)
Original
From: GaiusYaoHuangWee
<yaohuang.wee@xxxxxxxxxxxxxxxx>
Date: 2025年11月25日
18:36
Subject: Re: [STDS-802-11-TGBN] Follow-up discussion on 25/1869 CR for MAPC agreement negotiation
Hi Xiangxin , Zhenpeng
Sorry, I missed this discussion completely!
> Regarding CID #7680, Xiangxin suggests to keep “corresponding” in the sentence. As this CID is from you, could you take a look and let me know your preference?
>[// Xiangxin Gu ] I guess there
would be Status Code(s) for rejection operation. To be future-proof, it is better to keep the word
“corresponding”.
I’m not sure I understand your concern about removing “corresponding”. Is the intent to keep the “corresponding Status Code field” in case we add additional
Status Codes fields to the MAPC Negotiation Response frame in the future?
At least currently I think it does not make sense to include “corresponding” since there is only one Status Code field in the frame. It might mislead the reader to think otherwise.
Also, the preceding sentence refers to the Status Code field directly so it doesn’t match well. Do you mean to also add “corresponding” to the preceding
sentence?
“The Status Code field shall be set to SUCCESS if the MAPC responding
AP accepts at least one of the requests carried in the received MAPC Negotiation Request frame. Otherwise, the MAPC responding AP shall set the
corresponding Status
Code field to indicate …”
In my current view “corresponding” should be deleted.
Could you explain the rationale to keep it? I may have missed something.
Best regards,
Gaius
From:
顾祥新 (Xiangxin Gu ) <Xiangxin .Gu @unisoc.com>
Sent: Tuesday, 25 November 2025 4:17 pm
To: Shizhenpeng <shizhenpeng1@xxxxxxxxxx>; Gaius Yao Huang Wee <yaohuang.wee@xxxxxxxxxxxxxxxx>
Cc: Ganming(Ming Gan ) <ming.gan@xxxxxxxxxx>;
STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: RE: Follow-up discussion on 25/1869 CR for MAPC agreement negotiation
Hi Zhenpeng ,
Thanks for the mail discussion. Please see in line responses.
BR,
Xiangxin Gu
Institute of Communication Technology
From:
Shizhenpeng <shizhenpeng1@xxxxxxxxxx>
Sent: Tuesday, November 25, 2025 4:05 PM
To:
顾祥新 (Xiangxin Gu ) <Xiangxin .Gu @unisoc.com>;
yaohuang.wee@xxxxxxxxxxxxxxxx
Cc: Ganming(Ming Gan ) <ming.gan@xxxxxxxxxx>;
STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Follow-up discussion on 25/1869 CR for MAPC agreement negotiation
Hi Xiangxin ,
Thank you for commenting during today’s TGbn call. I would like to continue our discussion on resolution for CID #7680 in 25/1869 here.
As far as I understand, in 11bn D1.0 (and D1.1), only one Status Code field is present in MAPC Negotiation Response frame (see 9.6.7.68). It seems unnecessary
to have the word “corresponding” before “Status Code field”, so I deleted the word following the commenter ’s suggestion. In general, I suppose it does not make a huge difference whether we keep the word “corresponding” or not. If the commenter (@Gaius ) is
okay with it, I can also reject CID #7680 and keep the sentence as it is.
[// Xiangxin Gu ] I guess there would be Status Code(s) for rejection operation. To be future-proof, it is better to keep the
word “corresponding”.
I remember you also mentioned “Table 9-92” should be “Table 9-80” in the CR doc. In fact, “Table 9-92” was one of the updates made in 11bn D1.1 for consistency
with REVmf (see P904 in REVmf D1.0). Since the CR document is based on 11bn D1.1, I think no further change is needed.
[// Xiangxin Gu ] You are right. Sorry for the wrong comment (I looked it up in 802.11-2024)
Hi Gaius ,
Regarding CID #7680, Xiangxin suggests to keep “corresponding” in the sentence. As this CID is from you, could you take a look and let me know your preference?
Regards,
Zhenpeng
This email (including its attachments) is intended only for the person or entity
to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. Unauthorized use, dissemination, distribution or copying of this email or the information herein or taking any action in reliance
on the contents of this email or the information herein, by anyone other than the intended recipient, or an employee or agent responsible for delivering the message to the intended recipient, is strictly prohibited. If you are not the intended recipient, please
do not read, copy, use or disclose any part of this e-mail to others. Please notify the sender immediately and permanently delete this e-mail and any attachments if you received it in error. Internet communications cannot be guaranteed to be timely, secure,
error-free or virus-free. The sender does not accept liability for any errors or omissions.
本邮件及其附件具有保密性质，受法律保护不得泄露，仅发送给本邮件所指特定收件人。严禁非经授权使用、宣传、发布或复制本邮件或其内容。若非该特定收件人，请勿阅读、复制、
使用或披露本邮件的任何内容。若误收本邮件，请从系统中永久性删除本邮件及所有附件，并以回复邮件的方式即刻告知发件人。无法保证互联网通信及时、安全、无误或防毒。发件人对任何错漏均不承担责任。
To unsubscribe from the STDS-802-11-TGBN list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
To unsubscribe from the STDS-802-11-TGBN list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
To unsubscribe from the STDS-802-11-TGBN list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1