DMTF Process for Working Bodies

1 Scope

This document defines DMTF processes governing the formation, structure, and activities of DMTF Bodies and the DMTF Release Process for DMTF documents including:

· Documents that are intended to become DMTF standard Documents

· Documents that are intended to become DMTF Informational Documents

· Schemas

· Source codes

2 Normative references

The following documents, in whole or in part, are normatively referenced in this document and are indispensable for its application. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

DMTF Bylaws

DMTF DSP0004 – Common Information Model (CIM) Metamodel

Change Request Template (CR)

Charter Template

Document Request Template (DR)

Uniform Resource Identifiers (URIs) – IETF RFC 3986 - http://www.ietf.org/rfc/rfc3986.txt

ISO/IEC Directives Part 2 – Rules for the structure and drafting of International Standards

3 Terms and definitions

In this document, some terms have a specific meaning beyond the normal English meaning. Those terms are defined in this section.

The terms "shall" ("required"), "shall not", "should" ("recommended"), "should not" ("not recommended"), "may," "need not" ("not required"), "can" and "cannot" in this document are to be interpreted as described in ISO/IEC Directives, Part 2, Annex H. The terms in parenthesis are alternatives for the preceding term, for use in exceptional cases when the preceding term cannot be used for linguistic reasons. Note that ISO/IEC Directives, Part 2, Annex H specifies additional alternatives. Occurrences of such additional alternatives shall be interpreted in their normal English meaning.

3.1

Alternate Voter

Any person eligible to vote in a particular Body who is not identified in the roster of that Body as the Primary Voter.

3.2

Ballot

A vote by any means

3.3

Board of Directors
Board

A group of persons, as defined in the DMTF Bylaws, chosen to govern the affairs of the corporation.

3.4

Body

A substitution for Committee, Subcommittee, Forum, Chapter, or Working Group.

3.5

Change Request
CR

The form used to request a change to the CIM schema or a DMTF Document.

3.6

DMTF Document

Any published material released by the DMTF except for press releases, web page material, or marketing collateral.

3.7

DMTF Draft Standard

Any normative DMTF document that has not been approved by the DMTF Board for publication

3.8

DMTF Informational Document

Any non-normative DMTF document.

3.9

DMTF Informational Specification

An Informational document produced by a DMTF Incubator that may become a DMTF standard after the incubator transitions to a regular DMTF working group.
These documents proceed through a process similar to DMTF Specifications rather than DMTF Informational documents; however, they are not DMTF Standards.

3.10

DMTF Member Review

The period that precedes release as a DMTF Standard.
This period is used to meet intellectual property review requirements and to allow time to receive any final input from the DMTF members at large.

3.11

DMTF Standard Publication Identifier
DSP identifier

An identifier assigned to all DMTF documents.

3.12

DMTF Standard

A DMTF document of a normative nature that addresses a specific problem domain and has been released by the DMTF.

3.13

Document Request
DR

The template that is used to obtain, take ownership or return DSP identifiers.

3.14

Document State

The state of the document, which is kept external to the document, such as in metadata on the website

3.15

Document Status

The status of the document, which is kept internal to the document. This is usually on the first page and limited to the status values defined in section 6.1.3.

3.16

Document Type

The type of the document which is kept internal to the document. This is usually on the first page and limited to the status values defined in section 6.1.5.

3.17

Editing Body

The Committee, Subcommittee, or Working Group assigned editorial responsibility for any given document.

3.18

Electronic Ballot

A Ballot conducted electronically following the procedures defined herein.

3.19

In Development

The period during which a document is being crafted by the Editing Body.

3.20

Mantis

A comment-tracking tool provided by the DMTF for the use of its members in tracking changes to specific documents

3.21

Model

A set of conceptual elements and the relationships between them that collectively define the semantics, behavior, and state of some thing.

3.22

CIM schema

A formal language representation of a model, conformant to the CIM meta-model defined in DSP0004, which is created by the DMTF or Alliance Partners.
Disambiguation: CIM Schema [uppercase Schema] is a CIM schema with schema name “CIM” that defines a management ontology.

3.23

Managed Object Format
MOF

A schema description language used for specifying the interface of managed resources (storage, networking, compute, software) conformant with the CIM meta-model defined in DSP0004.

3.24

MOF file

A file containing the representation of a schema element written in the MOF language.

3.25

Parent Body

DMTF Body immediately above the current body in the hierarchy of DMTF Bodies.

3.26

Primary Voter

The person eligible to vote in a Body that has been identified in the roster of that Body as the primary voter. There may only be one Primary Voter representing any Member. A Member may elect to identify different persons as the Primary Voter in each Body in which it may vote.

3.27

Process Document

Any document produced by the DMTF that defines the policies and procedures that apply to the DMTF.

3.28

Schema

A formal language representation of a model. For example, a MOF representation of the CIM model defines a CIM Schema.

4 Symbols and abbreviated terms

The following abbreviations are used in this document.

4.1

DMTF

Distributed Management Task Force

4.2

MIB

Management Information Base

4.3

URI

Uniform Resource Identifier

5 DMTF Committees, Subcommittees, Working Groups, Forums, and Chapters

5.1 Structure and introduction

Bodies in the DMTF are arranged in a hierarchical structure rooted at the Board. Bodies reporting to the Board are called Committees and operate as Other Committees in accordance with the DMTF Bylaws. Subcommittees and Chapters report to Committees. Working Groups report to Subcommittees. Forums may report to any Body. The Body to which a Body reports is referred to as its Parent Body.

Every Body has a Board-approved charter that defines its scope. Chapters and Forums may have procedural or financial addenda to their charters that must also be approved by the Board.

Procedures common to all Bodies are described in Section 5.8 and apply unless more specific guidance is provided in this section.

5.2 Membership levels, roles, voting, and participation

As determined by Board resolution and documented herein, membership is divided into various levels that determine permissible roles, participation and voting rights within Bodies. Additional requirements may be documented in a specific Body’s Rules of Procedure.

Role or right	Leadership	Participation	Designated Alliance-Partner representative	Academic Alliance-Partner representative
Chair Committees	Yes	No	No	No
Vote in Committees	Yes	No	No	No
Participate in Committees	Yes	No	Yes	No
Chair Subcommittees	Yes	No	No	No
Vote in Subcommittees	Yes	No	No	No
Participate in Subcommittees	Yes	Yes	Yes	Yes
Chair Work Groups	Yes	No	No	No
Vote in Workgroups	Yes	Yes	No	No
Participate in Work Groups	Yes	Yes	Yes	Yes
Serve as a Forum Officer	Yes	No	No	No
Vote in Forums	Yes	Yes	No	No
Participate in Forums	Yes	Yes	Yes	Yes
Vote in Chapters	Yes	Yes	No	No
Participate in Chapters	Yes	Yes	No	No

Member representatives are eligible for the role or right in any particular Body provided that the Member is of a suitable membership level, meets the requirements of a Body’s Rules of Procedure, if any, and the representative has been admitted to the membership roll of that Body.

Alliance Partner and Academic Alliance Partner level members may apply to participate in specific Subcommittees, Working Groups, or Forums in their application. The Board establishes specific participation at the time of application approval.

DMTF Fellows may act in any role in any Body as designated by the Board.

DMTF expects as much continuity in representation as possible.

Members are encouraged to participate in as many Bodies to which they can actively contribute.

5.3 Committees

The Board of Directors is responsible for the creation and termination of Committees. Committees focus on specific aspects of the work and mission of the DMTF and are responsible for the development of DMTF marketing programs, technologies, and initiatives

5.3.1 Membership and participation

Chairs of Committees and Subcommittees (see “Subcommittees,” section 5.4) may participate in any Committee but may not vote unless they are otherwise eligible.

5.3.2 Committee chair

Committee chairs are appointed by the Board of Directors.

5.3.2.1 Committee vice-chair

All Committees must have a vice-chair. It is the vice-chair’s responsibility to serve in the place of the chair should the chair be temporarily unable to fulfill the duties and responsibilities required of the chair. Committee vice-chairs are elected by the Committee according to the process in section 5.8.2, with the clarification that both the Parent Body and the Body referenced in that section are the Committee (thus the Board of Directors is not directly involved). The vice-chair must be a voting participant of the committee prior to the election.

5.4 Subcommittees

The Committees can form Subcommittees. The Subcommittees focus on issues in specific areas of the Committee's charter.

To exist, a Subcommittee must have current unfulfilled goals and a charter. A Subcommittee can be considered active regardless of whether scheduled teleconferences occur or Ballots are requested of the parent Committee. A Subcommittee is considered to have current unfulfilled goals if at least one of its Working Groups has current unfulfilled goals. Additional requirements for submissions and participation can be defined by a Subcommittee by extending its charter. If this is done, it must be approved by the Subcommittee members and documented on the Subcommittee's main web page.

5.4.1 Subcommittee chair

Eligible Member representatives may be elected chair a Subcommittee.

1) The Subcommittee chair is a member of the parent Committee, but may not vote unless otherwise eligible. A Member may chair at most one Subcommittee of any given Committee.

2) All Subcommittees must have a vice-chair. It is the vice-chair’s responsibility to serve in the place of the chair should the chair be temporarily unable to fulfill the duties and responsibilities required of the chair. There are no restrictions on the number of Subcommittees that a person may vice-chair.

3) In the event that a Subcommittee chair is unable to fulfill the responsibilities of the position and has not resigned, Subcommittee participants from three separate Leadership Members may submit a request to the parent Committee that a new election be held. The request must be submitted in writing. Prior to initiating the request, Subcommittee members are strongly encouraged to attempt to resolve their concerns directly with the Subcommittee chair.

5.4.2 Subcommittee subteams

The formation of a subteam within a Subcommittee is not allowed.

5.4.3 Quiescing a Subcommittee

Subcommittees cannot be quiesced.

5.4.4 Dissolving a Subcommittee

The process to dissolve a Subcommittee is as follows:

1) A Subcommittee chair or Committee chair may make a request to the appropriate Committee chair that a Subcommittee be dissolved. This move is justified when no Subcommittee goals and deliverables remain; there are no Working Groups supported by the Subcommittee; or the Subcommittee is inactive. This information is then conveyed to the Committee by the appropriate Committee chair. If anyone takes issue with the move to dissolve, a discussion between the Committees and the Subcommittee chair is scheduled. Following the discussion, a report to the Subcommittee is made and another vote is held. Upon approval, the request is forwarded to the Board for approval.

2) After Board approval, an announcement is sent to all the DMTF members indicating that the Subcommittee is dissolved and providing the web location of its archived information. Questions regarding the work and deliverables of the Subcommittee can continue to be mailed to the DMTF list through the Contact page.

5.5 Working Groups

Subcommittees form Working Groups, consistent with the Subcommittee’s charter

To exist, a Working Group must have current unfulfilled goals and a charter. A Working Group can be considered active regardless of whether scheduled teleconferences occur or change requests are submitted. Additional requirements for submissions and participation can be defined by a Working Group by extending its charter. If this is done, it must be approved by the Working Group members and documented on the Working Group's main web page.

5.5.1 Working Group chair

Eligible Member representatives may chair a Working Group.

1) The Working Group chair is a member of the parent Subcommittee, but may not vote unless otherwise eligible. A person may chair or co-chair more than one Working Group.

2) Working Groups that do not have co-chairs are encouraged to have vice-chairs. If a Working Group has a vice-chair, it is the vice-chair’s responsibility to serve in the place of the chair should the chair be temporarily unable to fulfill the duties and responsibilities required of the chair. There are no restrictions on the number of Working Groups that a person may vice-chair.

3) Subsequent elections for a Working Group chair follow the process defined in section 5.8.2.

4) In the unlikely event that a Working Group chair is unable to fulfill the responsibilities of the position and has not resigned, Working Group participants from three separate Leadership Members may submit a request to the parent Subcommittee that a new election be held. The request must be submitted in writing, either via email or hard copy. The request is then voted in the Parent Body. Prior to initiating the request, Working Group members are strongly encouraged to attempt to resolve their concerns directly with the Working Group chair.

5.5.2 Working Group subteams

The formation of a subteam is sometimes necessary within a Working Group to focus the members. Subteams must use the Working Groups web page and reflector for all communications, documents, and meetings and shall not create their own. Subteams are meant to be informal working arrangements to get work items accomplished, such as investigations or specification authorship. As such, they shall not have any formal standing.

5.5.3 Quiescing a Working Group

Should a Working Group become inactive for a period of time, the Working Group may be quiesced as follows:

1) The Working Group chair or Subcommittee chair may make a request to the appropriate Subcommittee chair that a Working Group be quiesced. This move is justified when no deliverables remain but the group may need to become active again to work on a new revision. It may also be justified if the group lacks the resources to complete the assigned work, but expects to be able to continue it in the future (perhaps when other pending work is complete). A motion is made to quiesce the Working Group and a vote is held. If anyone takes issue with the move to quiesce, a discussion between the Subcommittees and the Working Group chair is scheduled. Following the discussion, a report to the Subcommittee is made and another vote is held. Upon approval, the request is forwarded to the Committee and then (upon successful Committee vote) to the Board for approval.

2) After Board approval, an announcement is sent to all the DMTF members indicating that the Working Group is quiesced and providing the web location of its archived information. Questions regarding the work and deliverables of the Working Group can continue to be mailed to the DMTF list through the Contact page.

5.5.4 Dissolving a Working Group

The process to dissolve a Working Group is as follows:

1) A Working Group chair or Subcommittee chair may make a request to the appropriate Subcommittee chair that a Working Group be dissolved. This move is justified when no Working Group goals and deliverables remain or the Working Group is inactive. This information is then conveyed to the Subcommittee by the appropriate Subcommittee chair. If anyone takes issue with the move to dissolve, a discussion between the Subcommittees and the Working Group chair is scheduled. Following the discussion, a report to the Subcommittee is made and another vote is held. Upon approval, the request is forwarded to the Committee and then (upon successful Committee vote) to the Board for approval.

2) After Board approval, an announcement is sent to all the DMTF members indicating that the Working Group is dissolved and providing the web location of its archived information. Questions regarding the work and deliverables of the Working Group can continue to be mailed to the DMTF list through the Contact page.

5.6 Forums

A Body may create Forums. Forums focus on issues in specific areas of the Body’s charter. Forums are different from Subcommittees and Working Groups in that Forums pursue work that is interesting to a subset of DMTF members and may collect and disperse monies, within the rules and regulations of the DMTF Bylaws, from this subset of the DMTF membership to succeed at their stated mission. As such, membership in a Forum may be restricted to DMTF members who fulfill key requirements like paying special dues or a Forum membership fee. Forums may exist for any purpose within these guidelines and the DMTF Bylaws. Forums are intended to be self-funding (that is they are responsible for collecting monies to pay for programs or initiatives they seek to deliver), but may request funds from their Parent Body.

Forums may still be considered active regardless of whether scheduled teleconferences occur or change requests are submitted. It is necessary that Forums have current unfulfilled goals and charter to exist. Additional requirements for submissions and participation can be defined by a Forum that extend the charter and deliverables of the team. If this is done, this must be approved by the Forum members and documented on the Forum's main web page

5.6.1 Forum officers

Forums may establish the cadre of officer positions needed to govern; however, each Forum must at least have a chair. Officer positions may include but are not limited to chair, vice-chair, treasurer, or secretary. Leadership Members who pay applicable Forum dues are eligible to be an officer in a Forum. No other categories of membership have the right to be an officer in a Forum. The Forum chair is a member of the sponsoring Committee, but may not vote unless otherwise eligible. The chair is responsible leading other officers that are elected to the Forum. Officers in a Forum should be elected every two years. In the event that an officer in a Forum resigns or can no longer fulfill the obligations of the office, a new officer is selected according to the process defined in section 5.8.2

5.6.2 Forum structure and subteams

It is sometimes necessary to form subteams within a Forum to focus the members. When this occurs, the work of the subteam must fall within the charter of the "parent" Forum−and the Forum's goals and charter must be updated to reflect the activities of the subteam. The formation, leadership, and termination of a subteam is a prerogative of the Forum. Also, the Forum may be organized into different classes of membership, each of which has different voting rights and membership fee or dues requirements.

5.6.3 Collection of membership dues and fees; accounting services

Collection of dues and fees, banking services, and other accounting services are provided to the Forum from DMTF central services. All Forum memberships will align with the DMTF's membership cycle and fiscal year, and follow DMTF's established practices.

5.6.4 Technical specifications and standards

The Technical Committee shall ultimately govern and manage all standards or specifications that a Forum may require.

5.6.5 Interoperability services

The Interoperability Committee may choose to oversee or govern all conformance testing and certification programs required by a Forum. It may also choose to be the sole supplier of tools and infrastructure needed to carry out conformance testing and certification programs. As such, the Interoperability Committee may assess a fee to the Forum for these services or tools. These fees will be jointly agreed to by the Interoperability Committee and the Forum(s).

5.6.6 Marketing and PR activities

Marketing and PR needed to carry out the Forums objectives are supplied to the Forum through the DMTF Marketing Committee.

5.6.7 Quiescing a Forum

Forums cannot be quiesced.

5.6.8 Dissolving a Forum

The process to dissolve a Forum is as follows:

5.6.8.1 Voluntary dissolution of a Forum

When there are no remaining Forum goals and deliverables or the Forum is inactive the Forum chair should prepare a proposal to dissolve and then obtain Board approval.

The Forum shall settle all accounts, current contracts, business obligations, and outstanding debts of the Forum before a motion to dissolve the Forum is accepted. Current contracts may be cancelled, or may be transferred to the DMTF Board, at the discretion of the Board.

If the Forum has established ongoing programs that it wishes to continue after the Forum is dissolved, the Forum must develop a plan with the Parent Body chair for the continuation of such programs and then obtain Board approval.

Any funds remaining in the Forum’s treasury after all debts and obligations are settled shall be transferred to the general fund of the DMTF.

5.6.8.2 Involuntary dissolution of a Forum

A Forum may be involuntarily dissolved if its membership drops or other factors make it impossible for the Forum to operate within the rules and policies of the DMTF.

Having determined that a Forum is operating outside the rules and policies of the DMTF, the Parent Body chair shall notify the Forum through the group’s email alias of such nonconformance. The Forum then has a period of 60 days to restore operation of the Forum to the terms of DMTF rules and policies. If, after 60 days, the Forum remains out of conformance with DMTF rules and policies, the Parent Body chair obtains Board approval for dissolution.

After the DMTF Board dissolves a Forum, all funds remaining in the Forum’s treasury shall be transferred to the general fund of the DMTF.

Ongoing conformance programs or other programs being run by the Forum may be continued or cancelled, at the discretion of the DMTF Board.

The DMTF Treasurer shall settle remaining accounts and debts owed by the Forum with money from the DMTF general fund. The Treasurer will cancel or continue current Forum contracts with outside vendors, at the discretion of the DMTF Board in keeping with DMTF policies.

5.6.8.3 Announcement of dissolution

Within twenty business days after the Board approves dissolution, a notice is sent to all DMTF members containing the Forum dissolution announcement, and the web location of its archived information. At this time, the membership roster of the dissolved Forum is cleared. Questions regarding the work and deliverables of the Forum can continue to be mailed to the DMTF list, through the Contact page.

5.7 Chapters

The Regional Chapter Committee (RCC) forms Chapters. Chapters focus on issues in specific areas of the RCC's charter. Chapters are different from Subcommittees and Working Groups in that Chapters pursue work that is interesting to a subset of DMTF members and they collect and disperse monies, within the rules and regulations of the DMTF Bylaws, from this subset of the DMTF membership to succeed at their stated mission. As such, membership in a Chapter may be restricted to DMTF members who fulfill key requirements like paying special dues or a membership fee. Chapters may exist for any purpose within these guidelines and the DMTF Bylaws. Chapters are intended to be self-funding (that is they are responsible for collecting monies to pay for programs or initiatives they seek to deliver) but they may request funds from their governing Committees.

Chapters may still be considered active regardless of whether teleconferences occur or change requests are submitted. It is necessary that Chapters have current unfulfilled goals and charter to exist. Additional requirements for submissions and participation can be defined by a Chapter extending the charter and deliverables of the team. If this is done, this must be approved by the Chapter members and documented on the Chapter's main web page.

5.7.1 Chapter officers

Chapters may establish the cadre of officer positions needed to govern; however, each Chapter must at least have a chair. Officer positions may include but are not limited to chair, vice-chair, treasurer, or secretary. Leadership Members who pay applicable Chapter dues are eligible to be an officer in a Chapter. A Member may hold only one officer position in any given Chapter. No other categories of membership have the right to be an officer in a Chapter. The Chapter chair is a member of the sponsoring Committee, but may not vote unless otherwise eligible. The chair is responsible for leading other officers that are elected to the Chapter. Officers in a Chapter should be elected every two years. In the event that an officer in a Chapter resigns or can no longer fulfill the obligations of the office, a new officer is selected according to the process defined in section 5.8.2.

5.7.2 Chapter structure and subteams

It is sometimes necessary to form subteams within a Chapter to focus the members. When this occurs, the work of the subteam must fall within the charter of the "parent" Chapter−and the Chapter's goals and charter must be updated to reflect the activities of the subteam. The formation, leadership, and termination of a subteam is a prerogative of the Chapter. Also, the Chapter may be organized into different classes of membership, each of which has different voting rights and membership fee or dues requirements.

5.7.3 Collecting membership dues and fees; accounting services

Collection of dues and fees, banking services, and accounting services are provided to the Chapter from DMTF central services. All Chapter memberships will align with the DMTF's membership cycle and fiscal year, and follow DMTF's established practices.

5.7.4 Technical specifications or standards

The Technical Committee shall ultimately govern, manage, and approve all standards or specifications that a Chapter may require.

5.7.5 Interoperability services

The Interoperability Committee may choose to oversee or govern all conformance testing and certification programs required by a Chapter. It may also choose to be the sole supplier of tools and infrastructure needed to carry out conformance testing and certification programs. As such, the Interoperability Committee may assess a fee to the Chapter for these services or tools. These fees will be jointly agreed to by the Interoperability Committee and the Chapter(s).

5.7.6 Marketing and PR activities

Marketing and PR needed to carry out the Charter’s objectives will be developed in conjunction with the DMTF Marketing Committee.

5.7.7 Quiescing a Chapter

Chapters cannot be quiesced.

5.7.8 Dissolving a Chapter

The process to dissolve a Chapter is as follows:

5.7.8.1 Voluntary dissolution of a Chapter

A Chapter chair may request the RCC chair that a Chapter be dissolved. This move is justified when there are no remaining Chapter goals and deliverables or the Chapter is inactive. This request is then conveyed to the DMTF Board by the RCC chair. If there are issues with the move to dissolve, a discussion between the RCC chair and the Chapter’s representative is scheduled to negotiate a solution. If there are no issues or discussion, a request to dissolve the Chapter is sent to the Board for approval.

1) The Chapter shall settle all accounts, current contracts, business obligations, and outstanding debts of the Chapter before a motion to dissolve the Chapter is accepted. Current contracts may be cancelled, or may be transferred to the DMTF Board, at the discretion of the Board.

2) If the Chapter has established ongoing programs that they wish to continue after the Chapter is dissolved, the Chapter must develop a plan with the RCC chair for the continuation of such programs, and obtain the approval of the DMTF Board for the programs to continue.

3) Any funds remaining in the Chapter’s treasury after all debts and obligations are settled shall be transferred to the general fund of the DMTF.

5.7.8.2 Involuntary dissolution of a Chapter

A Chapter may be involuntarily dissolved if its membership drops or other factors make it impossible for the Chapter to operate within the rules and policies of the DMTF.

1) Having discovered that a Chapter is operating outside the rules and policies of the DMTF, the RCC chair shall notify the Chapter through the group’s email alias of such nonconformance. The Chapter then has a period of 60 days to restore operation of the Chapter to the terms of DMTF rules and policies. If, after 60 days, the Chapter remains out of conformance with DMTF rules and policies, the RCC chair notifies the DMTF Board, and the Board votes to dissolve the Chapter.

2) After the DMTF Board dissolves a Chapter, all funds remaining in the Chapter’s treasury shall be transferred to the general fund of the DMTF.

3) Ongoing programs being run by the Chapter may be continued or cancelled, at the discretion of the DMTF Board.

4) The DMTF Treasurer shall settle remaining accounts and debts owed by the Chapter with money from the DMTF general fund. The Treasurer will cancel or continue current Chapter contracts with outside vendors, at the discretion of the DMTF Board in keeping with DMTF policies.

5.7.8.3 Announcement of dissolution

After the Board vote to dissolve the Chapter passes, an announcement is sent to all DMTF members within twenty business days indicating that the Chapter is dissolved, and providing the web location of its archived information. At this time, the membership roster of the dissolved Chapter is cleared. Questions regarding the work and deliverables of the Chapter can continue to be mailed to the DMTF list, through the Contact page.

5.8 Common rules and procedures

This section contains information supporting the prior sections.

5.8.1 Body formation

This section covers the formation of bodies such as Subcommittees, Working Groups, and Forums, referred to in this section as Body and Parent Body.

1) Proposals for a new Body can be proposed by any three Leadership Members of the DMTF. They are brought to the chair of the appropriate Parent Body. A proposal to form the new Body must be submitted and an interim chair or co-chairs identified (hereafter referred to as “interim chair”). The interim chair must be a Leadership Member representative. The Parent Body chair then hosts a discussion with the interim Body chair(s) and the appropriate Parent Body. The goals of the discussion are to determine whether the work aligns with the strategy and focus of the DMTF; what existing work is available in the industry; whether cooperative relationships with standards outside the DMTF might be necessary; and so on. No binding vote need be held. If the Parent Body is a Subcommittee, a similar discussion must be held at the Committee. No binding vote need be held. The proposal goes to the Board for approval.

2) After the proposal for the new Body is approved by the Board, an announcement is sent to all Leadership Members by the Committee chair, soliciting interested participants to attend one or more teleconferences or face-to-face meetings. The purpose of these meetings is to craft an initial charter for the Body, (see charter content 5.8.6.1). At least three Leadership Members must express interest to continue to the next step.

3) After at least three Leadership Members have expressed interest in forming the new Body, representatives from these members meet to discuss goals, a charter, deliverables, and a timeline. An interim group page may be created on the DMTF web site at this point to facilitate discussion and coordinate meetings. The chair of the appropriate Parent Body is responsible for providing insight and observations about the DMTF, any requested help in anticipating Committee, Subcommittee, and Board questions and responses, and answers to procedural questions.

4) At the conclusion of the meetings, the interim chair submits the proposed initial charter to the chair of the appropriate Parent Body along with proposed goals and an initial timeline. In addition, the interim chair must identify at least three Leadership Members that are committed to the ongoing work. The Parent Body chair then verifies the submitted information. If no issues exist, the charter and list of committed Leadership Members are sent to the Parent Body for Ballot following the normal Ballot process. If the Parent Body is a Subcommittee, a similar discussion and vote must be held at the Committee. The charter goes to the Board for approval. Issues with the Working Group’s proposed charter and list of committed members should be raised in the initial Ballot and then worked to closure.

5) After Board approval of the Body’s initial charter, the appropriate Committee chair sends a second announcement to all DMTF members indicating the formation of the new Body and the timing of its first meeting. At the formation meeting for the Body, the charter and list of committed members are reviewed (and possibly amended); the chairing method for the Body is decided (single chair, chair and vice chair or co-chairs); the official chair nomination process is started; and work on the deliverables commences. Meeting times for the new Body should also be discussed and Balloted if agreement during the meeting is not reached.

If the Body is a Forum or Chapter, any fees and officer positions, such as treasurer, are decided and the nomination process for these positions is started. Note that the process for deciding on these positions is the same as for deciding on chairs.

6) At the Body’s formation meeting, any chairs, vice-chairs, co-chairs or other officers are elected according to the procedure in section 5.8.2.

5.8.2 Chair and officer elections

The following section applies to the selection of chairs, co-chairs, vice-chairs and other officers. No Member may hold more than one chair or officer position in a particular Body.

5.8.2.1 Electing Officer

The Electing Officer shall be the Parent Committee’s presiding officer for chair, vice-chair, and co-chair elections. The Electing Officer for other officers shall be the Body’s presiding officer.

5.8.2.2 Order of Elections

If the Body’s chairing model is single chair or chair and vice-chair, then the election for chair shall occur before any other election. If the Body’s chairing model is co-chair, then the co-chair election shall occur before any other election.

5.8.2.3 Election Procedure

· The Electing Officer announces by email to the Body’s mailing list that nominations for the vacant position(s) are being solicited. Nominations can be submitted at a meeting or by email to the Electing Officer’s alias. Nominations shall be open for a minimum of five business days after announcement to the Body’s email list.

· At the meeting following the close of the nomination period, the Electing Officer announces the list of candidates nominated for each vacancy. Candidates may describe their background and interest in the role. If multiple nominees for a vacancy exist, the winning candidate is selected through an email Ballot to the Electing Officer’s alias. Each Member may vote once for each vacancy on the ballot provided that each vote is for different persons.

· If only one candidate exists for a vacancy, a default selection is made and announced. Members may voice objections to the default selection by email to the Electing Officer’s alias within five business days of the announcement. Should an objection be received, an attempt shall be made to resolve it. If resolution is not possible, then an election shall be held after another five business day call for nominations. Such election shall be held even though only one candidate stands. A simple majority of the votes is sufficient to elect the candidate.

· If multiple candidates exist for a vacancy then the candidate with a simple majority of the votes is selected. If no candidate has obtained a simple majority, then there shall be a run-off election between the two candidates with the most votes. The Electing Officer at the conclusion of each round of voting shall disclose the total number of votes cast for each vacancy as well as the number of votes achieved by each candidate.

· In the case of the simultaneous election of two co-chairs each Member shall have the opportunity to cast two votes each of which must be cast for different persons. Any candidate that receives a number of votes greater than 50% of the number of Members that cast votes is elected. If one position remains unfilled, then there shall be a run-off election between the remaining two candidates that had received the most votes. Should there then remain unfilled positions then each co-chair shall be voted sequentially and the candidate with a plurality of votes shall be elected.

5.8.3 Chair responsibilities

This section covers the responsibilities of a chair, vice-chair, or co-chair.

· The chair is responsible for acting as the presiding officer for all meetings and ensuring that all DMTF policies and procedures are followed.

· The chair is responsible to attend meetings of the Body and to provide reports to the Parent Body.

· The chair is responsible for informing the Parent Body of the progress, schedule, and status of the specific technologies or programs under development by the Body and its subordinate bodies on a monthly basis.

· As goals, schedules, and deliverables change, the chair is responsible for providing that data for publication on the Body’s public web page by sending the request with all necessary information through the approvals required of an Informational Document (6.1.3.6) and ultimately to tc-support@dmtf.org for publication.

· The chair is responsible for bringing Body issues to the Parent Body for resolution and Body deliverables to the Parent Body for forwarding to the DMTF Board through the organization for publication.

· The chair is responsible for maintaining email lists and rosters for the Body.

· The chair is responsible for ensuring that accurate minutes of each meeting are taken and posted on the “Members Only” web site, together with pertinent documents. If a Body chooses to rotate responsibility for recording minutes amongst its participants, each such Member is required to join in the rotation.

· The chair is also responsible for seeing that meeting attendance is tracked by using the tracking tool in the Body’s area of the web site.

· The chair is responsible for ensuring that an accurate record of the status of all specifications owned by the Body is maintained.

· The chair is responsible for ensuring the Body and all subordinate Bodies are operating within their charters and those charters are up to date.

· The chair is responsible for publishing the agenda two business days prior to meetings and ensuring that all collateral material for discussions are published two business days prior to meetings.

· The chair is responsible for declaration of voting results.

· The chair is responsible for Alliance Partner Work Register responsibilities and milestones as declared in the Work Registers.

· The chair is responsible for ensuring adherence to the DMTF Recording Policy.

· The chair is responsible for ensuring that the Body and all subordinate Bodies have a vice-chair or co-chair that can assume the role of chair upon a vacancy or absence of the chair.

5.8.4 Chair vacancy

From time to time certain events may result in the necessity for the chair, co-chair or vice-chair of a DMTF Body to vacate. The following section indicates circumstances when chair changes are warranted and how they should be managed:

1) When the chair, co-chair or vice-chair leaves or changes their relationship with the Leadership Member that they represent (other than through a merger or buyout), the position held by that person must be vacated and a new election held; or in the case of a Committee, a new Board appointment is made.

2) When a Body changes chairing model, the rules in section 5.8.5 require that an election be held.

3) When a Leadership Member is purchased by, or merged, with another Leadership Member and the co-chairs or the chair and vice-chair now represent the same Leadership Member, one of the positions must be vacated and a new election held for that position; or in the case of a Committee, a new Board appointment is made.

4) If no vice-chair or co-chair has been elected at the time of the vacancy, the chair of the Parent Body assumes the responsibility until a new election can be completed; or in the case of a Committee, a new Board appointment is made.

5.8.5 Chairing model changes

Should a DMTF Body deem it necessary to change its chairing model (which can be done any time by motion in the DMTF Body), the following procedures shall be followed:

· When a Body with a single chair changes to a model with a chair and a vice-chair, the current chair maintains the position and an election is held for vice-chair.

· When a Body with a single chair changes to a model with co-chairs, the current chair maintains the position and an election is held for the other co-chair.

· When a Body with a chair and vice-chair changes to a model with a single chair, the current chair maintains the position and the vice-chair position is eliminated.

· When a Body with a chair and vice-chair changes to a model with co-chairs, the current chair maintains the positions, the vice-chair position is eliminated and an election is held for the other chair.

· When a Body with co-chairs changes to a model with a single chair, the process is more complex. If one chair resigns, the other chair maintains the position. Otherwise, the chairs become interim chairs until an election is held for the single chair seat.

· When a Body with co-chairs changes to a model with a chair and vice-chair, the process is more complex. If one chair resigns, the other chair maintains the position. Otherwise, the chairs become interim chairs until an election is held for the single chair seat. The vice-chair position is then filled through the normal election process.

5.8.6 Charters

All Bodies must have a Board-approved charter that defines the scope of work to be performed by the Body.

5.8.6.1 Charter content

Charter scope includes the following:

· Purpose, technology area, problems to be solved, and anticipated work to be performed.

· General nature of anticipated deliverables such as specifications, test code, example source code, schemas or other materials.

· Parent Body.

· Disambiguate the nature of the Body from any other DMTF Body.

Charter scope does not include the following:

· Specifically named deliverables

· Chairs

· Schedule or time-line

5.8.6.2 Initial charter creation

· Committee charters are set by the Board

· The initial charters for other bodies are formed according to the initial charter procedures described in Body formation (5.8.1).

5.8.6.3 Charter modification

· Bodies wishing to change their charters may do so by preparing the proposed new charter and then obtaining Board approval (5.8.11).

5.8.7 Meeting notices, agenda, and materials

Meeting notices shall be posted on the DMTF event calendar. Meeting agenda should be included in the DMTF event calendar and must be sent to the Body’s email list at least two business days before the meeting. Collateral material, or the material that is the subject of discussion, shall be posted at least two business days prior to the start of the meeting. Bodies may decide on the frequency and nature (teleconference or face to face) of their meetings.

5.8.8 Rules of Order

DMTF Bodies shall operate according to the rules contained in the current edition of Robert's Rules of Order Newly Revised (RONR) unless those rules are inconsistent with the DMTF Bylaws or any rules or processes that are defined in this document.

5.8.9 Rules of Procedure

Bodies may establish additional Rules of Procedure that may apply to themselves, to their child Bodies, or to both. Rules of Procedure may include specific additional processes that must not be inconsistent with DMTF Bylaws, policies, or this document. Although Board approval is not required for Rules of Procedure, any Member may escalate a Rules of Procedure that they believe contradict DMTF Bylaws, policies, or this document by means of the Escalation Procedure (5.8.10). All effective Rules of Procedure for any Body must be accessible from the Body’s public facing web page.

5.8.9.1 Financial rules

Forums and Chapters may establish additional fees for the purpose of funding their activities. Participation in such Bodies may be subject to payment of the fees described their Rules of Procedure.

5.8.9.2 Other rules

The following is a non-exclusive list of the types of items that might be contained in a Body’s Rules of Procedure

· Procedures for submitting items for consideration and the forms attendant thereto.

· Specification of tools to be used for test, document generation, or otherwise in the pursuit of the Body’s Charter.

· Naming conventions, or other sorts of conventions necessary for the orderly pursuit of the Body’s Charter.

5.8.9.3 Prohibited rules

No Rules of Procedure document may:

· Violate any provision of the DMTF Bylaws, policies, or this document.

· Diminish any Member’s rights as defined in DMTF Bylaws, policies, or this document including those rights that accrue based on their membership level.

· Any provision disapproved by the Board through escalation or prior escalation.

5.8.9.4 Rules of Procedure approval

The proposing Body’s Parent Committee approves Rules of Procedure.

Committee-approved Rules of Procedure go into effect 31 days past approval to permit potential escalations by objecting Members.

Once a Member notifies the chair that an objection to a Rules of Procedure document not currently in effect is being escalated, the proposed Rules of Procedure shall be stayed until the escalation completes.

5.8.10 Escalations

When an action taken or not taken by a Body or Member is alleged to be in violation of the policies, processes, and procedures set forth by the DMTF Members should attempt to resolve the disagreement within the Body. If resolution is unsuccessful, the dispute must be documented in the Body’s minutes. Any Member may appeal by means of an escalation. The creation of an escalation results in review of the situation and resolution by the Parent Body.

5.8.10.1 Responsibilities

When a Member raises an escalation, it is the responsibility of the chair of the Parent Body to place the issue on the agenda for discussion within the earlier of the next 3 regular meetings or 30 days.

· The Parent Body chair must inform the originating Body chair and the escalating Member of the escalation as to when it will be on an agenda for discussion. During that agenda slot, the originator and origin Body’s chair are invited to attend regardless of normal participation rights.

5.8.10.2 Escalation requirements

The complaint should state the nature of the objection(s) in writing, including any direct and material adverse effects upon the appellants; the relevant section(s) of the DMTF policies, procedures, or processes at issue; the actions or inactions at issue; and the specific remedial action(s) that would satisfy the appellants’ concerns.

5.8.10.3 Timeline

An escalation must be raised within 30 days of the contested action.

5.8.10.4 Further escalation

If the Member escalating an issue is dissatisfied by the decision of the Parent Body, the escalation may be raised to the next level in the organization.

5.8.10.5 Final decisions

Escalations that reach and are decided by the Board of Directors are final.

5.8.11 Obtaining Board approval

Certain proposals (e.g. charters, documents, or events) require approval of the Board and are indicated herein as “obtain Board approval” or similar forms. The procedure for obtaining this approval is:

· The proposal is approved by the originating Body

· The proposal is forwarded to the Parent Body for approval

· Any issues, negotiations, clarifications, modifications are resolved between the Parent Body and the submitting Body until the Parent Body approves the proposal.

· If the Parent Body is the Board, the approval process is complete. If not, the Parent Body takes responsibility for the proposal and then submits the proposal to its Parent Body.

5.8.12 Voting

The voting processes are designed to be adaptable to the size of the Body, the nature of the question, and efficiency of operation. In the case where there is a manageable number of voters and the chair is satisfied that the minimum number of voters necessary for the type of Body are present, a call for unanimous consent is in order and may be used as determined by the chair. If there exists an objection, a vote is taken.

5.8.13 Vote counting

Vote counting may be by any means that the chair determines will yield an accurate count unless an incidental motion specifying a particular type of counting has been passed. In no case are abstentions counted or recorded.

Each voting Participation Member or Leadership Member may cast only one vote in any DMTF Ballot conducted by any means. If a Participation Member or Leadership Member casts more than one vote, the chair shall select the vote cast by the Primary Voter. If the Primary Voter has abstained and there exists conflict amongst the votes cast by Alternate Voters, the chair shall discard all votes by the Participation Member or Leadership Member.

5.8.14 DMTF majority rules

All motions in the DMTF, unless specified herein, require a 2/3 majority of votes cast to pass. In addition, there shall be a minimum of four votes cast by votes taken by a Committee unless specified by the Board; all other bodies shall have a minimum of three votes cast. A Body may decide to reduce this majority rule to those majorities stipulated in RONR by means of a motion to waive the 2/3 rule, which shall pass with a minimum of a 75% majority.

5.8.15 Motions related to methods of voting

Any member may make an incidental motion to specify a voting mechanism during debate on a question or at anytime until but not after the question on another motion has been stated. This incidental motion shall require a simple majority to pass (RONR §30).

Typical incidental motions include:

· Motion for an Electronic Ballot q.v.

· Motion for a standing vote (or show of hands)

· Motion for a roll-call vote

5.8.16 Requesting another Body to Ballot

Should a vote be solicited of a Body other than the originating Body, such as a Ballot request to a Parent Body, an email containing all the particulars shall be sent to Ballot-request@dmtf.org requesting that a Ballot be opened to implement that request.

5.8.17 Electronic Ballots

Because RONR discusses but does not specify the procedures for Electronic Ballots, the rules governing Electronic Ballots are described herein.

5.8.17.1 Validity

Electronic Ballots have equal weight and validity to other voting mechanisms described in Roberts Rules of Order Newly Revised.

5.8.17.2 Electronic Ballot lifecycle

· A motion that will be decided by Electronic Ballot is made, discussed, and potentially amended.

· An Electronic Ballot is opened by the chair during, or subsequent to, the meeting.

· The Electronic Ballot remains open for the time agreed unless extended.

· Votes may be made or changed until the result is declared.

· In the meeting in which the Electronic Ballot is scheduled to close, or subsequent to the scheduled closure of an Electronic Ballot, but before it is declared, comments may be discussed and voters may change their votes.

· After all vote changes have been made, the chair declares the result.

5.8.17.3 Amendments

Motions that are to be decided by Electronic Ballot may only be amended until the question has been called. The question, as well as any associated references or documents, shall remain static for the duration of the Electronic Ballot and shall be documented therein.

5.8.17.4 Comments

Comments, when appropriate, may be considered at the discretion of the chair whether or not the vote associated with the comment was counted or if the comment is associated with an abstention. Those wishing to comment who are not Leadership or Participation Members may do so by means of an abstention with comment.

5.8.17.5 Incorporation of comments

Although comments are encouraged to receive the widest possible review, the question, including attachments and associated documents, shall not be altered during comment disposition. A new Ballot by any permitted means is required to approve a question or document with changes that are the result of comments received during the process of an Electronic Ballot.

5.8.17.6 Duration

Electronic Ballots shall be open for a period of no less than 152 hours (six days plus eight hours). An incidental motion made prior to declaration by any member and agreed to by simple majority may extend the duration. Implicitly, Electronic Ballots are open until the results are declared in the next meeting of the Body after the agreed closure time has expired or a meeting scheduled for an interval that includes the scheduled closure time occurs.

5.8.17.7 Closure and declaration

If an Electronic Ballot closes between meetings of the voting Body, the declaration of the Ballot must be part of the next meeting of that Body. It is recommended that chairs set up the Electronic Ballot to close during the meeting itself. The following procedures are for closing and declaring the results of the Electronic Ballot:

· The early part of the agenda for the voting Body must include an item for closing Electronic Ballots.

· The voting Body may discuss any comments made during the Balloting period.

· Members of the voting Body may either cast or change their existing vote. The responsibility for recording this change falls upon the chair. The votes shall be recorded in the Electronic Ballot.

· The chair of the voting Body closes the Electronic Ballot and declares the results.

5.8.17.8 Recording of Electronic Ballots

· Motions subject to Electronic Ballot are recorded in the minutes of each meeting in which an action is taken with respect to that Electronic Ballot.

· The question, as well as the decision to perform an Electronic Ballot, are recorded in the minutes of the meeting in which they are made.

· Incidental motions to extend the closure of an Electronic Ballot are recorded in the minutes of the meeting in which they are made.

· The results of an Electronic Ballot are recorded in the minutes of the meeting in which they are declared.

5.8.17.9 Responsibility to manage

Electronic Ballots shall be opened, managed, and closed by the chair or designee.

5.8.17.10 Identification of Electronic Ballots

Electronic Ballots shall be distinguished from other forms of information gathering, such as preference polls, requests for comments, or other informal polls, by starting the text of the question with “Motion to”; shall state the question upon which the Body is voting; and shall have voting options of yes, no, and abstain. Any other use of electronic voting facilities shall not be considered Electronic Ballots under this section.

5.8.18 DMTF recording policy

DMTF meetings of any Body may be audio-recorded at the discretion of the designated recording secretary, provided the following rules are followed:

· The purpose of recording is only to ensure accurate meeting notes.

· Only the recording secretary may perform the recording.

· The recordings may not be shared, or played back, by the recording secretary with any other member.

· The recordings must be destroyed after the minutes are approved by the group.

· Participation in DMTF calls gives implicit permission for the recording secretary to record according to these rules.

· The chair or secretary shall announce that the meeting is being recorded at the beginning of the meeting, prior to the approval of the meeting agenda.

· The following text should be placed in the meeting agenda template:

"DMTF PHONE CONFERENCES MAY BE RECORDED FOR QUALITY PURPOSES TO ENSURE ACCURACY IN RECORD-KEEPING."

6 DMTF release process, document information, and file formats

6.1 DMTF release process

The DMTF release process defined herein is intended to provide the procedures and processes for release of material outside of the DMTF. Specifically, the intent is to specify the process for documents of a normative nature (such as those produced by the Technical and Interoperability Committees), process nature (such as those produced by the Process and Alliance Committees) or an informative nature (such as those produced by any of the above Committees). It is not intended to address marketing documents or other material produced by the Marketing Committee.

6.1.1 Overview

The phases in the release process for a DMTF Standard are as follows:

· DSP identifier acquisition

· In Development

· Work in Progress (recommended)

· Member Review

· DMTF Standard

The phases in the release process for a DMTF document that is not a DMTF Standard are as follows:

· DSP identifier acquisition

· In Development

· Informational

Examples of DMTF Standards include profiles, mapping specifications, registries, MOF Schema, schema definitions, wrapper specifications, and assorted WBEM specifications.

In addition to DMTF Standards, a Committee may release white papers, process documents, or technical notes that provide supplemental content on the work produced by the Committee (which is restricted by charter). These documents are released with a status of Informational. Collectively, these documents and DMTF Standards are referred to as “documents."

As DMTF Standards progress through the DMTF release process, their status, as documented in the document, changes from In Development, to Draft Standard, and finally to DMTF Standard. This process applies to all DMTF Standard documents.

Every DMTF document must have its date, status, and version on the title page, as well as the required DMTF copyright notice and disclaimers. See 6.2.3 for versioning requirements.

The CIM, or other DMTF CIM metamodel conformant model, is represented using MOF files, UML diagrams, white papers, and other supporting documentation (for example, supporting examples). The contents of the MOF files and the documentation are updated as they progress through the DMTF release process.

DMTF documents are developed collaboratively by Working Groups, and then reviewed and approved by the larger organization. Acceptable formats for DMTF artifacts have been defined because the software used across Members for document review and editing varies. Items submitted to the DMTF must be in an acceptable format, as described in section 6.3. Items submitted to the DMTF after July 1, 2004, must use this format.

Proposals or rough drafts for new documents and additions or changes to any type of DMTF Standard document, including updates, are made available to the originating Working Groups by posting this information to the Working Groups’ web page(s). Additions and changes to DMTF Standard documents must be described by using a DMTF Change Request (CR), or by submitting an update to the document. Procedures defining the use of the DMTF CR are provided in section 7.2. If the proposal is written in collaboration with another standards organization, it may also be posted to the membership of that standards organization, using the guidelines of that standards organization.

6.1.2 DSP identifier, acquisition, transfer, disposal

DSP identifiers are used to identify all DMTF documents. At most one editing body may have ownership of any DSP identifier at a time. A document request (DR 6.1.2.1) is used to acquire a new DSP identifier, dispose of one previously acquired but unused, obtain ownership for the document associated with a DSP identifier, obtain approval of a new schema name, or to change the document’s name or disposition. The Body’s Parent Committee must approve DRs before any work begins in an Editing Body.

6.1.2.1 Document Request (DR) content and format

DRs must be created by using the DR template. The content of this template includes:

· chair(s) of the Body requesting the DSP identifier

· Document Type being requested (DMTF Standard, Schema, white paper, etc.)

· Name of the associated document

· DSP identifier if previously issued

· Name of the Editing Body

· Date the request began

· Action requested: Issue DSP identifier | Transfer Ownership | Return DSP identifier

· Background rationale for the accompanying document

· Intention to publish or submit to (see section 6.1.6)

For MOF Schema, the following additional information is required:

· Schema Prefix being requested

· Long description of the model

· Short description for the model

· Qualifiers to be used for this model

· Dependencies to other models

6.1.2.2 DR preparation and submittal

The Editing Body prepares the DR clearly indicating the action proposed. Once prepared, the DR should be added to the appropriate group’s Document Request folder by the DR owner with a state of Draft. Documents added to the Document Request folder are automatically named with the following format: wgabbrevDR$docnum.$revnum.$extension. Groups can use their CR folder, following this format, if deemed appropriate.

DRs shall only be submitted by chairs.

DRs shall be shared with the Parent Body prior to voting in the Parent Body. It is best to set up the DR folder with automatic sharing to the Parent Body and Parent Committee.

6.1.2.3 DR approval

The Editing Body must vote to approve the DR. After it is approved by the Editing Body, the DR document proceeds for approval by the Parent Subcommittee (if any) and then by the Parent Committee in order. After the Parent Committee approves the DR, the Committee Secretary notifies the Editing Body that the DR is approved, the name of the document that was approved, and the action taken.

6.1.3 DMTF Document Status

This section describes the DMTF Document Status and the procedures required to transition a document through the development process.

Allowable DMTF Document Status types for DMTF Documents are as follows:

· In Development

· Work in Progress

· DMTF Draft Standard

· DMTF Standard

· DMTF Informational

· DMTF Informational Specification

6.1.3.1 In Development

When a Body is in the process of editing and developing a document, the document shall have a document status of “In Development” and a confidentiality of "DMTF Confidential", to clearly delineate the document's approval phase.

Such documents shall show their document status and confidentiality on the first page and in the footer of all remaining pages, unless they are in a non-page-oriented format (such as XML) where a footer is not possible, in which case they shall have some file header showing their document status and confidentiality.

Such documents shall contain any required copyright and other notices.

6.1.3.2 DMTF Work in Progress

The Editing Body for a document may vote to release a Work in Progress (a preliminary or draft version of the document) for review to the general public. Such documents shall have a document status of "Work in Progress – Not a DMTF Standard" and a confidentiality of "DMTF Confidential" labels prior to being Balloted for release by the Editing Body. All such documents must be within the Working Group’s charter scope. Any type of document can be released as a Work in Progress, including those intended to have a final document status of "DMTF Informational", "DMTF Standard", or "DMTF Informational Specification".

Work in Progress documents shall show their document status on the first page and in the footer of all remaining pages, unless they are in a non-page-oriented format (such as XML) where a footer is not possible, in which case they shall have some file header showing their document status and no confidentiality.

Work in Progress documents shall contain the required DMTF Confidentiality notices during the approval process. Upon final approval by the Parent Committee, any DMTF Confidentiality notices are to be removed.

All such documents must contain a DSP identifier, and all DMTF copyright notices. A DMTF Document shared as a Work in Progress must include a version number that identifies the version targeted for release as a DMTF Documents, as specified in 6.2.3.

Work in Progress documents must also contain the following disclaimer on the title page:

“IMPORTANT: This specification is not a standard. It does not necessarily reflect the views of the DMTF or all of its members. Because this document is a Work in Progress, this specification may still change, perhaps profoundly. This document is available for public review and comment until superseded.”

Work in Progress documents in development (?) must have the following footer: “DMTF Work in Progress - Not a DMTF Standard – DMTF Confidential” unless they are in a format such as XML where a footer is not possible.

In order for a document to be released as a Work in Progress document outside of the Editing Body and shared with one or more recipients, the Editing Body must vote to approve the release. After it is approved by the Editing Body, the proposed Work in Progress document proceeds to the Parent Committee, bypassing any Parent Subcommittee. The Parent Committee must approve a Work in Progress document before it is released to ensure that it is within the Working Group’s chartered scope.

Any material that is required to reproduce the document (such as drawings) must be checked into CVS prior to Committee vote.

An individual Change Request can be released as a Work in Progress to obtain feedback on an individual change (Schema or otherwise) from non-DMTF members, such as Alliance Partners. When an individual CR (Change Request) is the subject of a Work in Progress, the CR shall contain a DMTF copyright, patent policy and disclaimer notices.

Working Groups are encouraged to publish Work in Progress documents early and often. An interval between publication of Work in Progress documents of three months is considered usual.

Any feedback from Alliance Partner organizations, the general public, or a company or person who is not a member of the DMTF is accepted only through the DMTF Feedback Portal to ensure that the DMTF has the copyright to the material and that the feedback adheres to the DMTF Patent Policy.

When the Working Group considers the Work in Progress ready to move to the next phase, the document is released using the approval process listed in Table 2, dependent on document type and desired final document status.

6.1.3.3 DMTF Draft Standard

An Editing Body may vote to release a Document as a candidate for DMTF Standard. Such documents shall have a document status of “DMTF Draft Standard” and a confidentiality of "DMTF Confidential", prior to being Balloted for release by the Editing Body. Such documents shall show their document status and confidentiality on the first page and in the footer of all remaining pages, unless they are in a non-page-oriented format (such as XML) where a footer is not possible, in which case they shall have some file header showing their document status and confidentiality. All such documents must be within the Editing Body’s charter scope. All such documents must contain a DSP identifier, all DMTF copyright notices, and required disclaimers including a notice that they are subject to change. All normative references in the specification must be published before the specification can be released as DMTF Standard, or, in the case of interdependent documents, they must be released simultaneously. All normative references shall be published and references shall be persistent (that is, they should be published in a location that will not change over time).

The Parent Subcommittee (if any) must approve all DMTF Draft Standard documents before they proceed to the Parent Committee for approval, in accordance with the Committee Voting Process. The Parent Subcommittee also determines if a Member Review phase is needed. All new major versions of a specification (1.0, 2.0) require a Member Review. In the case of minor changes, such as in errata versions or in simple modifications that require a minor revision number change, a Member Review may not be needed. It is the purview of the Parent Subcommittee to make the determination of Member Review. If there is no Parent Subcommittee, the Parent Committee shall make the determination.

After the Parent Subcommittee approves the document, it and any material (such as drawings) required to reproduce the document must be checked into CVS.

Before the Parent Committee approves the document for release as "DMTF Standard", the chair of the Parent Committee sends the document and a notice asking for claims of essential patent rights to the DMTF Membership. DMTF Member comments are invited during this Member Review phase. The DMTF Membership review comment-and-claim period closes 30 days after the notification is sent to the DMTF Membership. This period is also known as “DMTF Member Review”. The Parent Committee does not vote on the approval of the document until the Member Review period ends.

Comments, questions, and feedback on the DMTF Draft Standard during Member Review are addressed by the Editing Body. Feedback may generate changes to the DMTF Draft Standard, which must be approved by the Editing Body. Any changes appear in a new version of the DMTF Draft Standard (see the exception for simplification of the editing process, below). This new DMTF Draft Standard must be approved by any Parent Subcommittee before the document proceeds to the “DMTF Standard” approval phase (see 6.1.3.5).

The Parent Subcommittee, as part of the comment resolution process, shall determine if an additional DMTF Member Review is needed. (For example, an additional Member Review might be needed if comments result in new text that warrants an additional call for essential patent rights.)

If no comments or claims are received, the document proceeds directly to the “DMTF Standard” approval phase (see 6.1.3.5).

6.1.3.4 MOF Schema

In the case of the CIM and other MOF Schema, individual Working Groups or Subcommittees create Change Requests to take the MOF Schema to the DMTF Standard phase (through a CR to remove the “Experimental” qualifier) or to add to the next DMTF Standard release. All such Change Requests must be approved by the Working Group or Subcommittee whose charter owns that part of the Schema. At the discretion of the Working Group or Subcommittee owning that part of the Schema, parts of a Schema may be removed. MOF Schemas and their changes do not have DSPs and do not follow the DSP acquisition and release process, except when requesting the Schema Prefix for a new MOF Schema.

For the DMTF MOF Schema to reach the DMTF Standard status it must contain one or more Managed Object Format (MOF) files and UML diagrams that are provided in an acceptable format, as described in section 6.3. The MOF files must not contain any elements that are qualified as Experimental. A white paper or profile should also be released that includes a description of the circumstances under which the classes can be subclassed, the expected usage of the classes, and at least two sample use cases. For a change to the MOF Schema to remove the Experimental qualifier, implementation experience from two independent implementations is required by a minimum of two Members or Alliance Partners. Implementation experience within an Alliance Partner organization may be substituted with approval of the Parent Committee if the MOF Schema changes are representative of the model developed by the external organization. For example, if an IETF MIB is modeled in CIM, implementation experience for the MIB may be used to make the CIM changes to remove the Experimental qualifier.

Implementation experience for the MOF Schema includes using the server for experimental elements in prototypes, internal systems, or product development. Implementation experience does not have to be restricted to released products to be applicable. The goal is to validate that additions and changes to the MOF Schema can be implemented and are complete.

6.1.3.5 DMTF Standard

After the DMTF Member Review has been completed (or if no Member Review was needed), and after the document intended to be released as "DMTF Standard" has been approved by the Editing Body and any Parent Subcommittee, the Parent Committee may vote to release the document to the general public. All such documents must contain a DSP identifier, all DMTF copyright notices, and all required disclaimers including a notice that they are subject to change. All normative references in the specification must be published before the specification can be approved, or, in the case of interdependent documents, the normative references must be released simultaneously. All normative references shall be published and references shall be persistent (that is, they should be published in a location that will not change over time).

The Parent Committee must approve any DMTF Standard document in accordance with the Committee Voting Rules before it can be brought to the DMTF Board for approval. The DMTF Board must also approve the public release of all versions and releases of the DMTF Standards, in accordance with the DMTF Board Voting Rules.

After the DMTF Board has approved a document, the document is changed to have a document status of “DMTF Standard” and no confidentiality (that is, no "DMTF Confidential" labels). Such documents shall show their document status and no confidentiality on the first page and in the footer of all remaining pages, unless they are in a non-page-oriented format (such as XML) where a footer is not possible, in which case they shall have some file header showing their document status and no confidentiality. All documents are then archived and may be published (see section 6.1.6).

Corrections to a DMTF Standard must be handled as Errata. Errata are released using the process defined in 6.1.3.3 and 6.1.3.5.

6.1.3.6 DMTF Informational

Documents with the status of DMTF Informational consist of presentations, white papers, process documents, source codes, external web site material, or any other non-DMTF Standard document. DMTF Standard documents must not be marked as Informational. Informational documents may not be marked DMTF Draft Standard or DMTF Standard. Presentations, white papers, and external web site material may be released with only Committee approval and do not require DMTF Board approval. All such documents must be within the Editing Body’s charter scope and be clearly marked with the status of “DMTF Informational” on every page. All white papers must contain a DSP identifier. All documents must contain all DMTF copyright notices, all required disclaimers, including a notice that they are subject to change.

Documents marked as Informational follow a shorter process than DMTF Standard documents because DMTF Member Review is not required. Informational documents must acquire a DSP identifier, but they do not go through the DMTF Draft Standard and DMTF Standard phases described in 6.1.3.3 and 6.1.3.5. Instead, they must be approved by the Editing Body and Parent Subcommittee, be checked into CVS, and be approved by the Parent Committee. If the document is not a presentation or white paper, it must also be approved by the Board. After completion of this process, the document may be published (see section 6.1.6).

See Figure A‑2 for the approval process for Informational documents.

6.1.3.7 DMTF Informational Specification

Documents with a status of DMTF Informational Specifications consist of specifications developed by DMTF Incubators. As such, they are treated procedurally as DMTF Standards with respect to obtaining a DSP identifier and the need for a 30-day Member Review (during which they are marked as DMTF Draft Informational Specification). They must be checked into CVS prior to the 30-day Member Review. They must be Balloted in their Parent Committee and must also be approved by the DMTF Board. After completion of this process, the document may be published (see section 6.1.6).

All DMTF Informational Specifications must contain all DMTF copyright notices, all required disclaimers, including a notice that they are subject to change.

See Figure A‑3 for the approval process for DMTF Standard documents, including DMTF Informational Specifications.

6.1.4 Review phases

The length and posting of each phase varies as shown in Table 1.

Table 1 – Phase length, status, confidentiality, and posting location

Phase	Length of Phase	Document Status	Confidentiality	Web Posting Location
Request for DSP	Indeterminate	N/A	N/A	N/A
Working Group	Indeterminate	In Development	DMTF Confidential	DMTF Internal Web Site – Working Group Web Page
Work in Progress (Optional)	Until superseded	DMTF Work in Progress	DMTF Confidential until approved; then none	DMTF Public Web Site – Work-in-Progress Page
Draft Standard	Not less than 30 days	DMTF Draft Standard	DMTF Confidential	DMTF Internal Web Site – Draft Standard page
Standard	Less than five years	DMTF Standard	(none)	DMTF Public Web Site – Published Documents Page
Standard	Greater than five years with approval	DMTF Standard	(none)	DMTF Public Web Site – Historical section
Informational	Indeterminate	DMTF Informational	DMTF Confidential until approved; then none	DMTF Public Web Site
Informational Specification	Indeterminate	DMTF Informational Specification	(DMTF Confidential until approved; then none	DMTF Public Web Site

6.1.5 Document type, final status, and approval process

The date and time of the publication of all Committee‑ and Board‑approved specifications (but not white papers, process documents, schemas, or presentations) is determined by the Board with guidance from the Marketing Committee. This is intended to coordinate the publication with any press release material. If no delay is requested, release is assumed to be immediate.

Table 2 defines the allowable document types, the allowable combinations of document types and final document status, and the approval process to be used for each combination.

The motion at each level in the approval process shall indicate the document disposition (see section 6.1.6) as well as the intended Final Document Status. Example motions are:

"Motion to approve DSPxxxx for publication as a DMTF Standard"
"Motion to approve Collection x for providing it to INCITS"
"Motion to approve <Document | Diagram | Presentation> for external use"
“Motion to approve DR <DR name> for internal use”

Table 2 – Document type, final status, and approval process

Document Type	Final Document Status	Approval Process
Specification	DMTF Standard	Standard Documents (see Figure A‑3)
Specification	DMTF Informational Specification	Standard Documents (see Figure A‑3)
White Paper	DMTF Informational	Informational Documents (see Figure A‑2)
Process	DMTF Informational	Informational Documents (see Figure A‑2)
Source code	DMTF Informational	Informational Documents (see Figure A – 2)
Tech Note	DMTF Informational	Informational Documents (see Figure A‑2)
Presentation	DMTF Informational	Informational Documents (see Figure A‑2)

6.1.6 Document disposition

DMTF documents, after reaching their final approval at either the Board or the Committee levels, are usually published through the DMTF web site. Some circumstances require that DMTF documents be released in an alternate manner instead of, or in addition to, publication on the DMTF web site, for example when a document is released to another entity. This section describes the requirements and methods for the dispensation of documents.

6.1.6.1 DMTF web site publication

Documents approved for publication are released on the DMTF web site. The changes required for the given Document Type are performed after the DMTF Board vote. These changes include steps, such as an editorial pass, change in Final Document Status (such as from “DMTF Draft Standard” to “DMTF Standard”) and generation of the final document that is to be published (see sections 6.1.3.2, 6.1.3.5, 6.1.3.6, and 6.1.3.7). The document is then published on the web site.

Specifications are published and a URI is generated for the document according to the document name. The document is then published on the “published documents” page and added to the appropriate document directory. URIs may also be generated or updated at the major revision and major.minor.revision level. These URIs are used for reference by DMTF and other standards so that the latest revision is always incorporated by reference in the referencing document.

6.1.6.2 Submission and transfer

When the document is intended to be either transferred or submitted to another organization, the document needs to have a statement regarding the nature of the submission or transfer and a statement about copyright grant. This statement can be either a part of the document or a separate document, such as a cover letter. An IP disclaimer should be included if the document is a specification. If included, the document is subject to approval by DMTF legal counsel before release.

Documents intended to be submitted or transferred to another organization are subject to DMTF Board approval regardless of Document Type and Final Document Status.

6.1.7 Availability of document versions and obsolescence

The release of a new version of a specification, white paper, or document does not make previous versions obsolete. Versions become obsolete when the market no longer requires them. The underlying goal is upward compatibility between versions. This goal should be approached with caution because maintaining upward compatibility between versions may not always be possible.

Updates to a specification, white paper, or document are submitted to the Editing Body. Each specification must contain a change history. (For graphical documents, such as UML diagrams, that are not conducive to including a change history, this history is included in the MOF file.) The status of these documents must be indicated as “Work in Progress,” “Informational”, “DMTF Draft Standard,” or “DMTF Standard.” A change log and completed Change Request forms must be maintained for all specifications, white papers, and documents.

Specifications and other documents that have reached a level of maturity where they are no longer actively being updated should be posted to a section of the DMTF web site dedicated to “historical” documents. The web site must contain information indicating that this specification is still relevant to the industry but new versions should not be expected. Specifications that are greater than five years old and are DMTF Standard should be reviewed by the owning Parent Committee annually to see if they should be moved to this portion of the web site, but the URL to the document should not change. Previous versions of MOF Schema that are greater than two years old may fall into the “historical” category and should be treated appropriately. Note that the URI of the document should remain persistent (remain the same over time) to allow other specifications to reference DMTF Standards.

6.2 Numbering, versioning and title page material for DMTF documents

6.2.1 Document numbers

DMTF documents, with the exception of the CIM and other MOF Schema, are given a DMTF Standard identifier (DSP). The version information for the document is inserted following this DSP identifier. MOF Schemas are released as versioned MOF files with associated graphical representations that are rendered using UML diagrams (provided in an acceptable format), as described in 6.3.

DSP identifiers associated with DMTF documents fall into the following ranges:

· 0001-0999 – Technical Specifications

· 1000-1999 – Profiles

· 2000-2999 – White Papers, Technical Notes, and other informational documents

· 3000-3999 – Working Group Charters

· 4000-4999 – DMTF Process documents

· 5000-5999 – Conformance Specifications, test scenarios, and other test related artifacts.

· 6000-6999 – Machine Readable Profiles

· 8000-8999 – XML/XSD Schema Representations

· IS-0000 - IS-9999 – Informational Specifications

DMTF documents that were approved before December 31, 2004 may have DSP identifiers that are outside of the preceding ranges. When these documents are revised, they must be changed to conform to these ranges. However, documents should not be revised only for the purpose of placing them in the appropriate number range.

6.2.2 Required information for title pages or file headers

The title page material required for DMTF documents differs from the header material required for DMTF MOF Schemas.

6.2.2.1 DMTF documents

This category of documents consists of all DMTF documents that are not MOF Schemas, regardless of their status in the release process. Use of a standardized title page and format is strongly encouraged, but not technically required.

DMTF documents must contain the following information, which is based on the document's status. These items are included in the document template.

· Title

The title of the document as registered when the DSP identifier was obtained.

· DSP identifier

This must be the DSP identifier obtained according to the policy described in 6.1.2.

· Version number

This version number must comply with the guidelines in 6.2.3.

· Date

This must be the effective date of the specification.

· Logo

A DMTF logo should be included on the title page.

· Document Type

This must be one of the type designations described in 6.1.5.

· Document Status

This must be one of the status designations described in 6.1.3.

· Document Language

· "DMTF Confidential" label for all DMTF documents prior to public release by DMTF

Page 2 of the document must contain the following information:

· DMTF Copyright Notice

· DMTF Patent Policy notice

6.2.2.2 DMTF MOF Schemas

Because schemas have headers rather than title pages, DMTF MOF Schemas have different requirements for the information typically found on the title page of a DMTF document.

Any DMTF document without a title page must have the following material in its header:

· DMTF copyright notice and disclaimers

· Version

· Release date

· Abstract description

· Status

The format of these items depends on the file type and must be consistent across files of the same type.

6.2.3 Specification, white paper, and document numbering process

Versioning of DMTF specifications, white papers, and documents takes the form m.n.u[d[d]], where:

m represents the major version identifier in numeric form. This number starts at 1 for new documents. A change in this number representing an update to the document indicates that the document contains changes that are not compatible with prior versions.

n represents the minor version identifier in numeric form. This number starts at 0 for new documents. A change in this number representing an update to the document indicates that the document contains changes that are compatible with prior versions.

u represents the update (errata or coordination changes) in numeric form. This number starts at 0 for new documents. A change in this number representing an update to the document indicates that the document contains changes that are corrections to errors in prior versions or changes in coordination with other documents. This digit may not be changed for Work in Progress documents.

dd represents the draft level in alphabetic form. This indicator is required for DMTF Draft Standard and Work in Progress releases.

Updated versions of documents must have one of these digits or letters changed from prior versions in increasing order; gaps in the order are allowed.

Non-Work-in-Progress documents are represented using only numeric entries (for example, 2.1.0 or 2.2.1).

Any DMTF specification that has not been approved as DMTF Standard, but is shared outside of DMTF must have the draft level identified. Any references to the specification version must include the alpha identifier (dd) appended to the identifying version number. Drafts are denoted starting with a single alpha character and, if necessary, progressing to two-letter notation: a, b, c … x, y, z, aa, ab….zz.

For example, a Work in Progress with version 2.2.0f will be released as DMTF Standard version 2.2.0.

6.2.4 Schema numbering process

A new MOF Schema is released using MOF and follows a version naming convention similar to the convention used for specifications, white papers, and documents (that is, using the format m.n.u, major.minor.update version). Version information is included in the header of the MOF file after the title and filename. (These are the first comment lines in the MOF file.)

Starting with version 2.10, the CIM Schema includes both Experimental and non-Experimental types of MOF files. Experimental MOF files include new classes or changes that require implementation feedback. MOF changes that require implementation feedback must be tagged with the Experimental qualifier.

When a class is changed, the version of the class is updated to the version of the Schema in which the change has been made.

Approved Change Requests to correct MOF syntax errors, such as cardinality mismatch or other updates for standards coordination, are indicated using a third numeric value. For example, correcting a cardinality problem in version 2.2.0 would result in a new version that is identified as 2.2.1. These are known as Errata versions.

If the DMTF defines a new MOF Schema that is not backward compatible with a previous release (such as one that reorders or changes the existing key or inheritance structure), that Schema becomes a new major version (that is, Schema version 3.0.0).

Each MOF Schema release combines all of the Working Group changes to produce a self-consistent, commonly labeled version.

6.2.5 Versioning of the CIM Infrastructure Specification

Updating the minor version number of the CIM Infrastructure Specification indicates that the changes do not require a change to the parsers, browsers, and other tools that process the MOF language. For example, version 2.2 may be updated to become version 2.3.

However, if there is a specification change that adds new data types (or otherwise affects existing MOF tools), this change is incompatible with existing tools and must carry a new major version. As a result, version 2.n would become CIM Infrastructure Specification version 3.0.

6.3 Accepted file formats

DMTF sources must be in one of the formats shown in Table 3.

Table 3 – Accepted source formats

Source Type	Approved Formats
MOF	UTF-8 text format
UML	XMI
Diagrams	Visio or ODF
Presentations	PowerPoint, Visio, or ODF
Specifications	Word (.doc, .docx), ODF, HTML, UTF-8 text format, or Visio
Source Code	UTF-8 text format

Note that source for graphical representations of UML or for class or instance diagrams can be either XMI or Visio.

Source files for DMTF documents that are made available outside of DMTF Working Groups must be stored in the DMTF CVS repository. Source files are any files that are needed to make changes to the document. Documents shall not be Balloted at Committees until the documents are stored in the DMTF CVS repository.

The Editing Body must submit DMTF specifications in PDF format to the appropriate Parent Body for approval. PDF is a common document publication format within the industry, and PDF readers are free and available on the Internet. DMTF specifications are published in PDF format. The Editing Body may also include the specification's source file in Word or HTML format. This format is useful when change tracking is enabled. Any CR that describes the changes should also accompany the document.

Originating Bodies may choose, by vote, to use a different source format during the development process. However, this source format must be converted to an acceptable format before it is released outside of the Editing Body.

DMTF published artifacts must be in one of the formats shown in Table 4.

Table 4 – Permitted published formats

Artifact Type	Approved Formats
MOF	UTF-8 text format
XML such as XSLT,WSDL,XMI	UTF-8 text format
Source Code	UTF-8 text
UML	PDF
Specifications, DMTF Standards, White Papers, Technical Notes	PDF and HTML

Supplemental information may be provided in HTML (for example, hyperlinked MOF documentation), UTF-8 text format (for example, XML MOF rendering), PDF, or Visio, as appropriate.

Published artifacts or collections of artifacts, may be provided in compressed (.zip) format for download convenience.

The filename for DMTF documents that are made available outside of a DMTF Working Group should use this format:

"DSP"<4 digit document number>"_"<m>"."<n>"."<u>"."<file extension>

Versioning information, release date, etc., are conveyed by the filename as defined in 6.2.3. Additionally, this information must be embedded inside the specification itself. When specifying the document number for DMTF specifications numbered below 1000, the leading zero must be specified. For example, "DSP0825_1.0.0.pdf" is correct, while "DSP825_1.0.0.pdf" is not.

7 Comment resolutions and Change Requests

7.1 Comment resolution process

During the normal course of document development, it is expected that comments will be made to documents in both the Editing Body and any Parent organization. This section describes the processes each Body uses to manage comment resolutions.

7.1.1 Comment resolution methods for Editing Bodies

Several mechanisms are available to DMTF Editing Bodies to manage comment resolution. Only the methods listed below are approved mechanisms for Editing Bodies to track comments and their resolutions. Any other method is not allowed by the DMTF. It is the purview of the Editing Body to decide which mechanism to use. This method can be decided by the group on a per document basis, but it is encouraged that a group follow only one of the methodologies below for every document for which they have editorial responsibility. The methodology shall be decided prior to the first Ballot for a document and shall be consistent during the lifetime of that document unless the Editing Body changes the methodology through a vote.

7.1.1.1 Mantis

The DMTF has access to the Mantis tracking tool. Mantis can be used to track changes and include them in the specifications. Mantis entries can be voted on individually or in groups by the Editing Body.

Any voting result associated with a Mantis entry should be recorded in the Mantis entry. This can be done by referencing minutes, referencing Ballots, or copying the voting record into the Mantis entry. In general, directly voting on a Mantis entry should not be necessary as documents incorporating proposals to resolve Mantis entries approved by Working Groups imply the changes have been approved.

7.1.1.2 Change Requests

Change Requests (CRs) can be used by editing bodies to track individual changes or errata associated with any individual document. CRs are described in section 7.2. For MOF Schema, Change Requests are the only comment-resolution method that is allowed.

7.1.1.3 Spreadsheets

Editing bodies can use spreadsheets to track individual changes to documents. The Editing Body should use the approved DMTF spreadsheet template for such purposes. Spreadsheet entries can be voted on individually or in groups by the Editing Body.

Any voting result associated with an individual spreadsheet entry should be recorded in the entry using the status field or a pointer to the Ballot or minutes recording the vote. If the whole spreadsheet has been approved, it shall be reflected in the document state of the spreadsheet. In general, voting on individual spreadsheet entries should not be necessary as documents that are approved by WGs that have the change in it imply the change has been approved.

7.1.1.4 Kavi document comments

Kavi Document Comments are those associated with documents using the current DMTF Web tool, in which you can select the “add Comment” option for a given document. This comment type is required for certain Ballot types tracked by the Web tool. While it is possible to use this method to track comment resolutions, there is a scalability limit with the current version of the Kavi tools, particularly when trying to share each comment to Parent groups. Therefore, this method of tracking comments is discouraged.

7.1.2 Comment resolution methods for parent bodies

Parent bodies are expected to register comments against the documents of Editing Bodies. Any substantive or editorial comments must be resolved by the Editing Body. Parent bodies may not make any substantive or editorial changes, except those that affect the document state, status or draft level in alphabetic form since modifying these is part of the DMTF release process.

If a document fails to pass a Ballot or vote for approval, the Parent Body sends the document to the Editing Body for resolution of comments. A document may pass a Ballot or vote for approval, but still have comments registered against it. In this case, the document is approved and shall continue on through the approval process. The registered comments shall be sent to the Editing Body to decide on a future course of action, but that course of action does not affect the current document against which the comments were registered.

7.2 Change Requests

Change Requests (CRs) are one of the mechanisms a Body can use to track and approve changes to specifications. They can be used to track individual changes or groups of changes, approve requests, or track any number of items as the Body deems necessary. Some DMTF processes require CRs at various steps of the approval process, which is dictated by DMTF governance documents or by procedure.

7.2.1 CR classification

The following categories of Change Requests are subject to the following rules:

· MOF Schema Change Requests

Changes to the CIM and other MOF Schema shall be made using the CR process and submitted to the Body that owns that particular section of the Schema. Bodies chartered to modify the Schema may place additional requirements on CRs, such as the use of a CR‑generation tool.

· Machine Readable Document Change Requests

Changes to the MOF, XML, XSD, or other typically machine readable documents may be made using the CR process when submitted to the Body that owns that document. Bodies chartered to modify a document may place additional requirements on such CRs (for instance, use of a CR‑generation tool or a changed-document checking tool).

· Document Change Requests

Document Change Requests may be used within a Body that has editorial responsibility to gain agreement on specific changes to a specification. This CR approach is particularly useful for tracking complicated, granular additions or modifications to existing specifications or groups of changes that need to be tightly coupled.

7.2.2 CR content

CRs must be created using the CR template. An approved CR template is available in the Technical Committee Template folder, which is shared with all members.

The content of this template includes:

· CR number

· name of the associated document or schema

· name of the Editing Body

· date the request began

· background rationale for the accompanying change request

· detailed list of changes

This can take the form of XML or metadata, if approved by the Editing Body and Parent Body and Parent Committee.

7.2.3 CR creation

Change Requests must use the current version of the DMTF CR template and must be filled out per the instructions in the template. The description of the CR must identify the version of the specification impacted by the CR, provide a summary of the changes, and, in the case of MOF Schema changes, identify the model or models impacted by the change (for example, CIM 2.9.1 Preliminary, Addition of SoftwareIdentityResource in core model).

A CR is added to the appropriate group’s Change Request folder by the CR owner with a state of Draft. Documents added to the Change Request folder are automatically named with the following format: wgabbrevCR$docnum.$revnum.$extension.

7.2.4 CR sharing

CRs should be shared with the Subcommittee and any Working Groups or Subcommittees that might be interested in the change. Attempts should be made to ensure that input from interested Bodies is incorporated into the CR.

7.2.5 CR owner

Each CR must have an owner defined within the owner section of the CR header. The owner of the CR may be the chair of the Working Group or a designate. The owner of the CR is responsible for collecting Ballot comments, updating the discussion point section of the CR, and facilitating the Balloting between Bodies for CRs that span Bodies.

7.2.6 CR Ballots

When an owner is ready to request that a CR be Balloted, its status is changed to WG ‑ Pending or SC ‑ Pending, as needed. The CR is then Balloted (sometimes referred to as “open for Ballot”). When the CR is being Balloted by the Working Group or Subcommittee, its status is changed to WG‑Balloting or SC ‑ Balloting respectively. CR Ballots are subject to the following rules:

· CRs that have unanimous YES votes without comments are accepted accordingly.

· CRs that have unanimous YES votes with comments are accepted pending the changes identified in the comments. Comments included with a YES vote must be minor (for example, pointing out typographical errors or mistakes in punctuation). Comments included with a YES vote must not suggest a change in semantics or identify major problems with the CR.

· Any NO votes on a CR Ballot must be responded to by the CR owner. Any NO votes on a Ballot must include comments that are clear and actionable. The Working Group may ask for additional clarification from the Member representative who voted NO. The owner’s options in responding to the NO votes are as follows:

– ACCEPT the comments associated with any NO votes.

– DEFER the CR with a specific closure date.

– WITHDRAW the CR (perhaps consolidating the content with another CR).

– RESOLVE the comments by working out an alternative solution.

– REJECT the comments and state why they cannot be accommodated.

All Ballot comments and the owner’s responses must be included in the next Balloted version of the CR.

· A comment can be actionable either in terms of specific elements of the CR that need to be changed or because a relevant area of analysis or investigation has not been sufficiently explored in the production of the CR. When specific elements of the CR require change, the elements and the changes need to be included in the CR Ballot comment. These changes should be sufficiently detailed so that the owner of the CR can implement them without conferring with the commenter. When the comment refers to an area of analysis or investigation, the comment must explain in what way the area of study cited calls into doubt the conclusions or assumptions that form the basis of the CR. The suggested action resulting from this comment may be either revision or withdrawal of the CR. The area of analysis and investigation must already be familiar to the Working Group that put forth the CR, or the comment must sufficiently introduce the area of analysis and investigation so that the Working Group can take action.

· The resolution must be accepted by the Body either as part of the meeting of the Body (as is commonly the case with trivial changes) or through a re-Ballot of the CR after the issues have been resolved. Comments from each Ballot of the CR, along with their resolution, must be documented in the CR.

· At any time after the initial Ballot is closed and notice is sent to the Body, a CR owner may request that the next Ballot be a final Ballot. In this case, DMTF Majority rules apply to determine if the CR succeeds (see section 5.8.14). Any member of the Body may request that a final Ballot be held by motion in accordance to RONR.

· If the Body cannot reach a resolution, the Body chair may request that the CR be discussed at the Parent Body level by notifying the appropriate Parent Body chair. Any CR issue that cannot be resolved in the discussion of the vote must be documented in the CR comments section prior to Balloting.

7.2.7 Additional CR approval

After the CR has been approved at the Working Group level and if Subcommittee approval is required, the status of the CR is changed to SC – Pending and the CR is shared with the Subcommittee. The Subcommittee then votes on the document referenced by the DR.

After the CR has been approved at the Subcommittee level, the status of the CR is changed to CMTE – Pending and the DR and all referenced documents are shared with the Committee.

7.2.8 CR adoption

After all required parties have approved a CR and the CR needs no further approval, its state is changed to SC – Adopted or WG – Adopted, as appropriate. When the Board has approved the associated document, the state can be changed to DMTF – Adopted.

8 DMTF Management Initiatives

The DMTF may create Management Initiatives for purposes of consolidating messaging and promotion around technical or interoperability deliverables.

8.1 Management Initiative

A Management Initiative is a DMTF-protected term applied to a set of specifications, documents, and activities that address a specific resource domain (e.g., Server Management, Storage Management, Desktop Management, etc.) that meet the following conditions.

8.1.1 Technical components

It must have technical components:

· It must have a top-level specification that normatively defines the technical content of the Management Initiative. That specification must reference one or more Management Profiles and one or more WBEM Protocols or other specifications within the management domain.

· It must reference white papers that describe the specifications and how they apply to the management domain.

8.1.2 Messaging components

It must have messaging components:

· It must have requirements for messaging or technical evangelism to promote the Management Initiative for the mutual benefit of the DMTF membership. This may include, but is not limited to, press releases, tech notes, presentations, and coordination of events with the Marketing Committee. This may be as simple as a web page presence and press release or presentation and does not require a significant marketing effort.

8.1.3 Compliance and interoperability components

It should have compliance or interoperability components:

· It may have requirements for compliance and interoperability. This may include, but is not limited to, any of the following: formation of DMTF Forums, plug-fests, development of compliance specifications, and test suites. This may be as simple as plug-fests or compliance specifications and is not meant to imply DMTF enablement of this activity.

8.2 Management Initiative responsibility

The Technical Committee is responsible for approving that the technical aspects of the Management Initiatives as appropriate. The Marketing Committee is responsible for approving that the messaging components of the Management Initiative are appropriate. The Compliance and Interoperability Committee is responsible for ensuring that compliance or interoperability components are appropriate.

8.3 Management Initiative formation

For a Management Initiative to be formed, the following steps must take place.

1) A Management Initiative proposal must be prepared.

2) The Technical Committee must approve the technical content of the proposal. It is assumed that the technical content, in form of DSP(s) and white paper(s), is already on the roadmap for the Technical Committee to approve

3) The Marketing Committee must approve the marketing content of the proposal. It is assumed that the messaging content is already on the Marketing Committee roadmap

4) The Compliance and Interoperability Committee must approve any compliance and interoperability content of the proposal.

After these steps are completed, DMTF Board approval is required for the Management Initiative to be created.

8.4 Management Initiative coordination

Subcommittees should be formed under the Marketing Committee to manage the messaging of the Management Initiative and facilitate coordination across Committees as needed. This is done using the Subcommittee creation process, indicated in section 5.4. The charter of the Subcommittee is to manage the messaging of the Management Initiative.

9 Information access

A policy of the DMTF is to have stable information available to its members. Committee and Working Group members are entitled to have access to any pertinent data related to the decisions and operations of the team.

9.1 Web posting

It is the responsibility of the chairs to ensure that all of the data required for the work of the team is made available to all participants. chairs accomplish this by posting to the Working Group web page in the "Members Only" section of the DMTF web site.

9.2 Email lists

The DMTF maintains email lists for each Working Group for distributing information to its members. The email lists are for participants of Committees, Subcommittees, and Working Groups. Committee and Working Group email lists are for the internal use of the teams in support of their development or marketing activities. These lists are not for general dissemination of information.

9.3 Information restriction

The restriction of information to a Committee or Working Group (until approved by that team and passed to the next group in the DMTF organizational hierarchy) is to protect the DMTF and all its members from partial ideas or incomplete or inaccurate information taken out of context. Participants understand the history and context of this internal information.

9.4 Access removal

Failure to participate can result in a person being dropped from a Committee, Subcommittee, or Working Group, at the discretion of the chair. This step is not taken hastily. Additions to, and removals from, the Committee, Subcommittee, and Working Group rosters are the responsibility of the chairs who have that access right. Member access IDs and passwords are the responsibility of the DMTF.

9.5 Information dissemination

Members are permitted to disseminate unreleased DMTF information within their organization as long as the information is marked as "DMTF Confidential." Confidential information should not be redistributed to any non-member without the permission of the DMTF Board of Directors.

9.6 Document information

Document information is generally disseminated through the DMTF specification web pages and the members are informed of specification updates through the DMTF newsletter. Access to the specification web pages is open to anyone.

10 Approval process state transition table

Table 5 represents the DMTF DR, CR, and document states, their description and new state based on transition or event.

Table 5 – Process state transitions and events

State	Description	Transition	New State
DMTF – Adopted	The document or change request has been approved.
BOD – ApprovedForPublication	The document or request has been approved for publication, but requires state and status change, specific disclaimers removed, and a document file name change to meet publishing requirements. The document is then checked into CVS.	Confirm	DMTF – Adopted
BOD – Balloting	The request is being Balloted by the Board.	Yes	DMTF – Adopted
		Conditional	BOD – Approved-Pending
		No	BOD – Update-needed
		No	CMTE – Update-needed
BOD – Pending	The document has been forwarded to the Board and is waiting for Ballot (initial state for Board).	Voting	BOD – Balloting
CMTE – Adopted	The document or request has been approved at the Committee level and no approval is needed by any Parent Body.
CMTE – ApprovedForPublication	The document or request has been approved for publication, but requires state and status change, specific disclaimers removed, and a document file name change to meet publication requirements. The document is then checked into CVS.	Confirm	DMTF - Adopted
CMTE – Balloting	The document or change request is being Balloted by the Committee.	Yes	CMTE – Adopted
		Yes	BOD-Pending
		Conditional	CMTE – Approved-Pending
		No	CMTE – Update-needed
CMTE – EditorialReview	The document or request has been approved but requires the document state or status changed, directives applied and some disclaimers added prior to beginning the approval process for publication.	Confirm	BOD - Pending
CMTE – Pending	The document or change request has been forwarded to the Committee and is waiting for Ballot.	Voting	CMTE – Balloting
CMTE – Update-needed	This document was presented to a Parent Body and it is being returned for update or further work. Only used when the CMTE is the EB.	Ready	CMTE – Pending
SC – Adopted	The document or change request has been approved at the Subcommittee level and no approval is needed by any Parent Body.
SC – Balloting	The change request is being Balloted by the Subcommittee.	Yes	SC – Adopted
		Yes	CMTE – Pending
		Conditional	SC – Approved-Pending
		No	SC – Update-needed
SC – EditorialReview	The document or request has been approved, but requires the document state or status changed, directives applied, and some disclaimers added prior to beginning the approval process for publication.	Confirm	CMTE - Pending
SC – Pending	The document or change request has been forwarded to the Subcommittee and is waiting for Ballot.	Voting	SC – Balloting
SC – Update-needed	This document was presented to a Parent Body and it is being returned for update or further work. This state is only used when the SC is the EB.	Ready	SC – Pending
WG – Adopted	The change request has been approved by the WG, and it does not need approval from a higher authority (Technical Committee, Board, etc.).
WG – Balloting	The change request is being Balloted by the WG.	Yes	WG – Adopted
		Yes	SC – Pending
		Conditional	WG – Approved-Pending
		No	WG – Update-needed
WG – EditorialReview	The document or request has been approved, but requires the document state or status changed, directives applied, and some disclaimers added prior to beginning the approval process for publication.	Confirm	SC - Pending
WG – Pending	The document is waiting for Ballot at the WG level. This is the default for Change Request creation.	Voting	WG – Balloting
WG – Update-needed	This document was presented to a Parent Body and it is being returned for update or further work.	Ready	WG – Pending
Draft	This state is used to begin a document at any level.
Withdrawn	The document or Change Request has been withdrawn.	Withdraw from any state	Withdrawn

ANNEX A
(informative)

Process flowcharts

Figure A‑1 through Figure A‑4 were developed to help the reader understand the processes. These flowcharts are for informational purposes to represent the processes in the DMTF and are not intended to be the canonical source for DMTF processes.

Figure A‑1 – Document approval process: DSP identifier acquisition

Figure A‑2 – Document approval process: Informational documents

Figure A‑3 – Document approval process: DMTF Standard documents

Figure A‑4 – Document and CR approval states

ANNEX B
(informative)

Change log

Version	Date	Description
1.0.0	2013-10-22	Consolidated DSP4002 and DSP4004, normalized some duplicate language, re-wrote electronic voting rules to tighten, clarify, and bring into conformance with RONR
1.0.1	2013-10-29	Corrected vote counting to “votes cast”
1.1.0	2014-03-20	Policy change on publication and expiration of WIP documents Forums may be formed by any Body Process defined for returning DSP identifiers DR form removed from DSP4014 Member level roles and rights clarified. Eliminated Sponsored Member