| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Xiangxin, Zhenpeng Sorry, I missed this discussion completely! >[// 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? 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 …”
Could you explain the rationale to keep it? I may have missed something.
Best regards, Gaius From:
顾祥新 (Xiangxin Gu) <Xiangxin.Gu@xxxxxxxxxx>
Hi Zhenpeng, Thanks for the mail discussion. Please see in line responses. From: Shizhenpeng
<shizhenpeng1@xxxxxxxxxx> 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 |