MecReviewDocument < P1076

P1076 Web>MecReviewDocument (2018-07-12, JimLewis) (raw view)EditAttach
---+ MEC Review Document

---++ About the Review

Section I: Items/issues that shall be resolved before the ballot begins
   The draft cannot be balloted or recirculated until these issues are resolved. Your Staff Liaison will review the updated draft for compliance prior to upload of the PDF for ballot.

NOTE—Fonts shall be embedded in the draft PDF. Instructions on creating a PDF with embedded fonts can be
 found at: http://standards.ieee.org/develop/stdswritten.html

Section II: Items/issues that shall be resolved before the final recirculation
These issues have to be resolved and viewed by balloters. The items will be checked for completion by the Project Editor during the Sponsor ballot, then checked by the Review Committee (RevCom) of the IEEE-SA Standards Board (IEEE-SASB), and will impact approval unless rectified.

Please note that professional editing takes place once the document has been approved and, as such, this MEC does not address all of the editorial items that will be reviewed then (i.e., punctuation, grammar, formatting).

The following comments are derived from the IEEE Standards Style Manual. The complete IEEE Standards Style Manual, in viewable/downloadable format, can be found at:

https://development.standards.ieee.org/myproject/Public/mytools/draft/styleman.pdf

---++ SECTION I: Items/issues that shall be resolved before the ballot begins:
   * icon:checked This section was completed before ballot started.

Copyright

•   If applicable, all copyright permission for excerpted text, tables, and figures shall be submitted to the IEEE prior to the start of ballot. If there are missing permission response letters, please submit them immediately to me Michelle Turner

Sample permission letters can be found in Annex A of the IEEE Standards Style Manual or http://standards.ieee.org/develop/stdsreview.html. More information on the IEEE SA Copyright Policy can be found at: http://standards.ieee.org/ipr/copyright.html

•   The correct copyright statement shall appear on the first page of the standard. The statement can be found in 9.1.2 or Annex C of the IEEE Standards Style Manual

•   The correct copyright line shall appear on the bottom of every page, including the body of the standard:

Copyright © 2018 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.

Standards designation
•   The correct standard designation and date shall appear on the top of every page, including the body of the standard.
IEEE P1076/D5, June 2018

---++ SECTION II: Items/issues that shall be resolved before the final recirculation

---+++ Legal: “Absolute” verbiage

   * Please review the text for any explicit or implicit guarantees made within the document, especially those that are safety-related. Avoid making guarantees if there is a possibility of unforeseen situations or circumstances altering an outcome. For example, words such as “ensure,” “guarantee,” “maximize,” minimize,” etc., should be modified, if they are inaccurate. Substitutions might include “reduce” or “improve.” For example, “to ensure safety” might be changed to “to improve safety” or “to prevent” might be changed to “to reduce.”

   * icon:checked Review for "ensure". See [[https://gitlab.com/IEEE-P1076/LRM/issues/192][GitLab Issue 192]]
Addressed the following items as part of the review of ensure (but not necessarily as shown since some of the examples are normative and required shall):

NOTE—Some string property values may include special characters (for example, the character \ in an extended identifier). VHPI programs that use such property values should <strike>ensure</strike> verify that special characters are not inadvertently misinterpreted, for example, as escape characters, in subsequent operations.

If the standard or specification describing the encoding method specifies a fixed or maximum number of characters per line, the tool <strike>shall</strike> should ensure that each line contains the fixed number, or no more than the maximum number, of characters. in this case, an encoding line length description has no effect.

—If a protect encoding directive in an encryption envelope contains an encoding line length description, the tool <strike>shall</strike> should ensure that each line contains no more than the specified number of characters.

   * icon:checked Review for guarantee see [[https://gitlab.com/IEEE-P1076/LRM/issues/194][GitLab Issue 194]]

   * icon:checked Review for maximize - None Found
   * icon:checked Review for maximize - None Found

---+++ Trademarks or service marks

&#xF0A7;   Please review the use of trademarks in the draft, if applicable. References to commercial equipment or products in a standard shall be generic and shall not include trademarks or other proprietary designations. Where a sole source exists for essential equipment or materials, it is permissible to supply the name of the trademark owner in a footnote. The proper use guidelines for trademarks shall be determined by the trademark owner. Trademark owners must grant written permission before their trademarks may be referenced in a standard.

&#xF0A7;   Trademarks or other proprietary designations that are not commercial equipment or products should be avoided in standards. If used however, all trademarks shall be credited to the trademark owner in the front matter of the standard. The following text shall introduce any mention of specific trademark information:

The following information is given for the convenience of users of this standard and does not constitute
an endorsement by the IEEE of these products. Equivalent products may be used if they can be shown
to lead to the same results.

For more information on commercial terms and conditions see the IEEE-SA Policy on commercial terms set forth in 6.2 of the IEEE-SA Standards Board Operations Manual.

---+++ Registration objects

•   If the draft contains a registration of objects (for additional information, visit the IEEE Standards Web site &lt;http://standards.ieee.org/regauth/index.html&gt;), the working group shall submit the document to the IEEE Registration Authority (IEEE-RA) for mandatory coordination (submit to a.n.thomas@ieee.org for review). The text containing the registration information should be highlighted in the draft and the clause should be noted in the email. If the working group believes that the draft may potentially contain a registration of objects or if the working group would like information about setting up a registration, contact the IEEE-RA as early as possible to prevent a delay in approval by the IEEE-SA Standards Board. Search on the following words: object identifier, unique identifier, and assignment of unique numbers.

---+++ Front matter
   * icon:checked Update IEEE Font Matter - See [[https://gitlab.com/IEEE-P1076/LRM/issues/198][GitHub Issue 198]]

•   Make sure updated information has been included in the frontmatter (in the Notice to users section, the following information, shall be included). Information can be found in the latest templates at:  The most recent Notice to users section can be found in the latest templates at: http://standards.ieee.org/resources/development/writing/writinginfo.html

---+++ Verbs

•   Review use of will/must in all standards; use of shall/should/may/can for recommended practices and guides.  
•   The use of “must” is deprecated, except in cases where a statement of absolute fact is being made.  Please review each usage of “must.” Please change to “shall” in cases where it is not appropriate for use.  

More information on use of shall/ should/may/ and can is found in 10.2.2 of the IEEE Standards Style Manual.

   * icon:checked Review for must (it is deprecated) - see [[https://gitlab.com/IEEE-P1076/LRM/issues/195][GitLab Issue 195]]
   * icon:checked Review for shall in notes - see [[https://gitlab.com/IEEE-P1076/LRM/issues/197][GitLab Issue 197]]
   * icon:checked Review for should in text - terse review, no uses of should convey requirements.

There were four notes cited in the MEC review.  Two of them were already addressed in draft 6.  The other two have
the following edits planned:

NOTE—Because of the relative precedence of signs + and – in the grammar for expressions, a signed operand shall not follow a multiplying operator, the exponentiating operator **, or the operators abs and not. For example, the syntax does not allow the following expressions:

-- note: changed "shall" to "will"

NOTE—A VHPI program shall not use a format for which not all values of the object’s type can be represented (see Clause 22.2), even if the value with which the object is to be updated can be represented using that format. For example, it would be an error to update an object of a physical type whose position numbers exceeded the bounds of 32-bit representation using the vhpiSmallPhysVal format.

-- note: changed "shall" to "will"

---+++ Metrication
   * icon:checked Review for Metrication and enter changes to GitLab see [[https://gitlab.com/IEEE-P1076/LRM/issues/193][GitLab Issue 193]]

•   Please note, I’ve included a page with highlighted text that is not compatible with IEEE Policy 9.16 and my recommendation is that you should consider removing the text. However, should you want to keep the text please note the following. “Necessary exceptions to this policy, such as where a conflicting world industry practice exists, must be evaluated on an individual basis and approved by the responsible Major Board of the IEEE for a specific period of time. The cognizant Board responsible for the publication or activity will be responsible for monitoring compliance.”

**Also there may be some areas I may have missed during my review. Please review the document to help ensure that there are other areas that are in violation of the policy.

The remedy in the IEEE-SASB Implementation plan for IEEE Policy 9.16 is the Waiver, should you not want to delete the text.

---+++ Graphics

•   Point out instances where the quality of line art and photos do not comply with the requirements outlined in Clause 14 of the IEEE Standards Style Manual.
•   Separate electronic files of figures shall be supplied (unless created in Word or Framemaker)

---+++ Next steps for this project.

---++++ Before Ballot 1

a) After you have implemented this review, create the pdf that will be used for ballot (remember that the draft number shall be rolled to reflect that changes have been made to this document, e.g., P1234™/Dx+1).

b) Upon completion of the invitation to ballot please follow the next steps:
Instructions:
1.        Login to myProject and click the Balloting tab
2.        Click  Initiate Sponsor Ballot   
3.        Select  your project from the PAR drop down list
4.        Enter the Ballot Open Date
5.        Enter the Ballot Close Date (should be minimum of 30 days)
6.        Enter the Draft #: (must match the draft number in the draft )
7.        Select File for Uploading:  Click the Browse button to find your draft file. The file must be in pdf.

NOTE—Fonts shall be embedded in the draft PDF. Instructions on creating a PDF with embedded fonts can be
 found at: http://standards.ieee.org/develop/stdswritten.html

8.        Review the system generated text.  If you would like to add additional instruction or information, use the Sponsor Text Area.
9.        Click Initiate Ballot.

---++++ Ballot MEC Review is During Ballot 1

c) Note that compliance with items in Section I will be reviewed by the Staff Liaison when you upload the pdf to the URL in item b). The Project Editor will not review your draft until the Ballot MEC, which occurs during the Sponsor ballot.

---++++ RevCom MEC review is after final balloted draft is submitted to RevCom

d) The RevCom MEC will occur after you submit the final balloted draft to RevCom. At that time you will also be required to submit the document source file. If the figures are not native Word or Framemaker graphics, each graphic shall be submitted as a separate file following the requirements outlined in Clause 14 of the IEEE Standards Style Manual.
Topic revision: r8 - 2018-07-12 - 21:59:56 - JimLewis
P1076