l
Regarding ACCEPTED comments, there should be no instructions to the editor within the table row. But it is suggested to also show the redline changes within the doc
after the table row or together with other proposed changes. It is also OK to write something like "NOTE to TGbn editor: redline change implementing
the changes proposed by the commenter can be seen in
http://...docx with CID tag xxxx if helpful to the editor." in the table row.
Note, however, that for an ACCEPTED comment it is the "proposed change"
from the commenter that is authoritative, not the redline. If there
is any difference between the "proposed change" and the redline, it is
the "proposed change" that must be effected by the Editor.
Thanks,
Mark
--
Mark RISON, Standards Architect, WLAN English/Esperanto/Français
Samsung Cambridge Solution Centre Tel: +44 1223 434600
1 Cambridge Square, Cambridge CB4 0AE Fax: +44 1223 434601
ROYAUME UNI WWW:
http://www.samsung.com/uk
From: Yujian (Ross Yu) <00001792b51ef4ea-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Thursday, 6 November 2025 10:09
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBN] Best practice for proposed changes when the resolution is “Accepted”
Hello all,
Some member gets to me and shows concern when the resolution is Accepted, if the proposed changes to the spec will be understood correctly by the editor and will be rolled into
the spec. Below is my understanding and suggested best practice:
l
When the resolution is Accepted, it should mean the proposed change by the commenter is very clear to the editor and everyone. If there is concern that the proposed change by the commenter is not clear. Then
the resolution should be Revised, and detailed instruction to the editor should be given. So the first concern should not exist.
l
Regarding ACCEPTED comments, there should be no instructions to the editor within the table row. But it is suggested to also show the redline changes within the doc
after the table row or together with other proposed changes. It is also OK to write something like "NOTE to TGbn editor: redline change implementing
the changes proposed by the commenter can be seen in
http://...docx with CID tag xxxx if helpful to the editor." in the table row.
An example is shown below:
|
8128 |
38.3.2.1 |
319.35 |
Change "...in an EHT PPDU. See36.3.2..." to "..in an EHT PPDU, see36.3.2..." |
As in comment. That is, continue the sentence with a comma not a full stop. |
ACCEPTED |
To TGbn editor:
Please make the following changes from P315.L27 to P315.L28:
In this way, it prevents the editor from overlooking the proposed changes by this comment. Especially in a CR document with many proposed changes and comments.
Regards
Ross Jian Yu
于健
Huawei Technologies
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