![[SPA Home Page]](/img/return.gif)
From: Shalom Bresticker (Shalom.Bresticker@motorola.com)
Date: Mon Aug 26 2002 - 08:18:02 PDT
-------- Original Message --------
Subject: Part 6, IEEE Standards Companion
Date: Mon, 26 Aug 2002 18:16:24 +0300
From: Shalom Bresticker<Shalom.Bresticker@motorola.com>
Organization: Motorola Semiconductor Israel, Ltd.
http://standards.ieee.org/guides/companion/part6.html#pub
-- Shalom Bresticker Shalom.Bresticker@motorola.com Design & Reuse Methodology Tel: +972 9 9522268 Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478"The devil is in the details."
Approval of an IEEE standard is achieved by submitting the document and supporting material to RevCom, which issues a recommendation that is ratified by the IEEE Standards Board. There is a Standards Board Review Kit from the IEEE that tells you what you need to supply to RevCom. Crucial things to remember at this stage are to supply all the necessary documentation, such as rebuttals to unresolved negative ballots and coordination ballots. You should also examine your PAR to ensure that the final document you have produced is still within the scope defined by the PAR. You should check that the PAR title and final title match. RevCom will check over all the documentation and make sure that you have followed the procedures. RevCom will not determine anything concerning the technical nature of your document. That is the role of the balloting group.
What RevCom Typically Looks For
- Was the balloting group balanced?
- If the ballot was delegated to a subordinate committee, is there a record of that delegation?
- Was the ballot valid with at least a 75% return and less than 30% abstentions?
- Did the ballot pass by at least 75%?
- Does the document match the title/scope/purpose of the PAR authorizing the work? (Note that title changes that are still within the PAR's scope and purpose are acceptable.)
- Was coordination with the required organizations achieved? Was coordination accomplished via the required method?
- Were all members of the balloting group given an opportunity to see all the outstanding negatives and reasons why they could not be resolved?
- Were all members of the balloting group given an opportunity to change their vote as a result of changes made to resolve negative ballots?
- If there are patent or copyright issues involved, are there patent or copyright letters included in the submission package and has IEEE staff reviewed and approved such letters?
- Are there any major technical or procedural oversights?
RevCom examines whether or not you have followed the principles of consensus, due process, openness, and balance throughout your project development. RevCom will carefully examine your receipt of coordination and your resolution of negative votes to ensure that this has been done.
All packages submitted to RevCom must be received by a certain deadline, which is set for each meeting. However, the earlier it can be received, the better its chances that it will receive a thorough review from IEEE staff in order to catch any errors or problems with the submittal package that could be fixed prior to RevCom review. Last-minute arrivals can't be guaranteed this service. Also, make sure your materials are carefully and clearly organized so there is no confusion at RevCom.
Finally, keep in mind that RevCom and NesCom merely make recommendations to the IEEE Standards Board for approval or disapproval of a project via a consent agenda. Projects can, and often have been, pulled off this consent agenda for further discussion or a recommended change of action. Final approval of all documents and PARs ultimately rests with the IEEE Standards Board. And remember, all IEEE Standards Board and committee meetings are open for you to attend.
What to send to RevCom
- Form for Submittal of Proposed Standards
- Balloting authority (if delegated)
- Ballot summary
- Copies of unresolved negative comments and sponsor rebuttal; if negative is resolved, need signature of balloter to verify resolution
- PAR and PAR approval letter
- Coordination responses
- Permission release(s) if applicable
- Working group roster (if not in draft)
- 30 copies of draft
- A copy of the electronic file that produced the draft with the software used identified
Sometimes a standard doesn't follow this development path quite as smoothly as it should. Perhaps your working group isn't able to come to immediate agreement, or perhaps the technology being standardized is evolving rapidly. When you feel you need to receive input from a broad base in your technical community or if you're having difficulty resolving certain negative ballots, you might want to consider the option of distributing your standard as a trial-use standard.
Trial-use standards are valid for a two-year period. They are distributed in the same broad manner as full-status standards, but they may not yet be at a final stage of development. At the end of the two-year period, the standard can either be accepted as a full-status standard (if no comments were received) if the sponsor recommends this, or it can be returned to the working group for further development and balloting. (No ballot is required to upgrade a standard from trial use to full status if no comments were received.) A cut-off date for comments is included in the published standard to allow the working group time to revise and reballot the standard prior to the end of the trial-use period should that be needed.
The trial-use method has proven to be very effective for some sponsors. It does allow broad use and adoption of a standard over which there is general agreement but still some uncertainty. If you have reached an impasse in your standards development activity, think of exploring the benefits of the trial-use standard.
Some working groups know they want to receive the broad input from a trial-use period right from the beginning of their work; that's why there's a category for trial use on the PAR form.
The final imperative principle behind standardization is that of the right of appeal.
Right of Appeal--an imperative principle
In the IEEE, there are two types of appeals: procedural and technical. Appeals can be made by anyone at any point in the process, but prior to standards approval they will automatically be given, via the sponsor, to the working group to be addressed. Once the standard is approved, if there is still a concern an appeal can be addressed to the IEEE Standards Board. Appeals of approved standards are automatically given to the sponsor. Appeals are handled by the IEEE Standards Board after processes within the sponsor are exhausted.
Lesson Learned: Many appeals that have been presented to the Board have been technical in nature. If your appeal has already been heard and denied at the sponsor level, going to the IEEE Standards Board with it will not be beneficial. The Board will remand it to the sponsor, which will probably not change an earlier opinion. The Board will examine a procedural appeal, but many merely mask technical issues. Make sure your issue is truly procedural if you wish to use this method of appeal.
Appeals must be filed within a certain time limit as specified by the IEEE Standards Operations Manual, and there is a timetable for responses as well. The IEEE Standards Board usually handles appeals by setting up a special appeals committee, which will determine whether or not there's a need for a hearing on the issue and make a recommendation based on its consensus judgment. The appeals committee is made up of Board members who were not actively involved in the standard's development.
So once your standard has been developed, balloted, and approved, your work is done, right? Well, not quite. Publication, interpretations, and other future developments need to be considered.
When your standard has been approved, it is not yet complete. It will receive a thorough, detailed edit from a professional IEEE standards editor. The role of an editor is to ensure that the standard is grammatically and syntactically correct using American English. It is not an editor's role to make any changes that affect the technical meaning of the standard--indeed, this is not allowed. The editor can, however, make rewordings, editorial changes, and formatting changes to assist in publication of the standard. The editor also ensures that the document meets the rules for IEEE standards style as outlined in the IEEE Standards Style Manual.
The editor normally works with a primary contact point for the working group (usually the chair or technical editor). The editor will discuss any questions or potentially problematic changes with this contact. The contact will also receive pages of the final standard to review and approve prior to publication.
The editorial process is quite painstaking--there are very few people who read the standard in as detailed a manner as the editor. Depending on the length of the document, this can take some time to complete. Therefore, working groups should be patient when it comes to receiving their edited standard.
Sometimes during the process of review the editor or the working group will find errors in the approved standard. Glaringly obvious typographical errors are fixed, but sometimes these errors consist of things like incorrect numbers in an equation, an incorrectly drawn figure, or a major misstatement in a paragraph. It is the IEEE editor's job to determine if these changes are editorial and can be made straightforwardly. By the very nature of their job, the editors are conservative in their acknowledgment of these requests for technical changes or corrections. In many cases, the action taken will be to go to the next RevCom meeting that occurs during publication preparation and ask for RevCom's review and opinion of the technical change. If RevCom will approve the technical change, it can be made. If not, it has to be saved for a supplement or a future revision. (Keep in mind that if more straightforward typos are found after publication, an errata sheet can be issued at that time.)
The working group chair or a delegate is responsible for reviewing the edited and formatted pages from which the published standard will be printed. This thorough review should ensure that no glaring errors have crept into the document during the editorial and publishing process. This review is usually made in a timely fashion to facilitate publication of the standard. After review and inclusion of any changes, the document can be published and disseminated as an IEEE standard.
Many draft standards today are being developed in various electronic word processing programs. The IEEE Standards Department also uses such programs, and it's crucial that you contact and work with the IEEE standards staff throughout your standard's development to ensure that the program you are using is compatible with the IEEE's. The IEEE Standards Style Manual details many of the types of electronic forms that are acceptable, but you should always double-check with the department first.
Lesson Learned: Some ground rules do apply to preparing electronic files of draft standards: always keep the art in a separate file from the text, try to keep use of special fonts and styles to a minimum, and avoid complex formatting. This will reduce translation problems. If you wish to format your document to match the published style for IEEE standards, contact your project editor or the IEEE Standards Publishing Manager first.
Lesson Learned: Art files are often the most difficult for the IEEE Standards Department to work with. Make sure you contact the department early in your development process to avoid any difficulties in using figures.
Some groups may want to produce an electronic product along with their standard, such as a diskette of computer code that the standard requires you to implement. In these cases, the groups should let their IEEE project editor know as soon as possible what it is they would like to do so that work on that can begin promptly.
Once your standard has been approved and published, your primary task is completed. In many cases, working groups are dissolved, or they may move on to developing other standards. However, there are reasons to maintain some contact with working group members over the years. One of these is interpretations.
Once a standard is approved, its major technical development is complete. However, questions may arise concerning the language used in the standard, the intention or result meant by a particular action, etc. When a question of meaning like this arises, an individual can write to the Secretary of the IEEE Standards Board asking for interpretation of the passage in question. This request is then forwarded to the working group chair and sponsor for action. It is expected that a group will develop a response to the interpretation request and send it to the requestor (with a copy sent to the IEEE). Completed interpretations are published with standards, either bound in on the next printing or rolled into a collection of standards. In some cases, the volume of interpretations being generated by a committee may be great enough to merit publication of a separate interpretations volume.
Interpretations are a unique form of commentary on the standard. They are not explanations of what the standard should have done or meant to say. Interpretations cannot change the meaning of a standard as it currently stands. Even if the request points out an error in the standard, the interpretation cannot fix that error. The interpretation can suggest that this will be brought up for consideration in a revision or supplement (or, depending on the nature of the error, an errata sheet might be issued). However, an interpretation has no authority to do any of this. It can only discuss, address, and clarify what the standard currently says. The challenge for the interpreters is to distinguish between their expertise on what "should be," their interests in what they "would like the standard to be," and what the standard says. Interpretations are often valuable, though, because the request will point out problems that might otherwise have gone unaddressed.
Some Guidelines for Interpretations
- The standard is what it says. If the words are substantively wrong, then a corrective supplement via the balloting process is the correct response.
- If the standard is ambiguous, then the interpretation must favor a looser requirement rather than a more restrictive one. Again, a corrective supplement can be initiated if needed.
- If two parts of the standard contradict one another, then a rationale should be created and the IEEE errata process should be applied to correct the contradiction.
One of the reasons interpretations cannot change the standard is that they are not developed through an officially balanced consensus process, that is, a ballot. The interpretation request is handled by the sponsor through an interpretations committee. This committee can be the standing working group that developed the standard or it can be any of the members of the working group or balloting group who have expressed an interest in participating in the interpretations process, depending on the rules of the sponsor. There is no requirement for balance in membership. Many interpretations groups, however, do follow the principle of consensus in their development. But because this process doesn't meet the rules for approval of changes that are applied to an IEEE ballot, an interpretation cannot change the meaning of a document.
All working groups should be aware that they may be called upon to handle interpretations and come up with a process for doing so while they are still developing their standard. Level of participation in a working group is usually highest at this point, and it is important for working group members to be aware of this responsibility and prepare for their potential involvement. Remember, some groups receive no interpretations requests at all, while others receive many, so the group may have nothing to do or a great deal to do. The interpretations process you develop should be well known within your technical community so that anyone who wants to can participate. The procedure for submitting interpretations requests is published in the front of every IEEE standard.
Many interpretations groups meet via phone or electronic mail, which avoids any travel requirements or significant time away from work.
Some possible answers to requests are shown in annex C to give guidance on how to handle requests without altering the meaning of the standard. Interpretations are useful in indicating when a revision or an errata sheet might be necessary as well.
![[Back to Table
of Contents]](/img/backup.gif)
![[Next section]](/img/next.gif)
This archive was generated by hypermail 2.1.4
: Thu Oct 10 2002 - 09:24:28 PDT
and
sponsored by Boyd Technology, Inc.