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