DMTF
Process for Working Bodies
This document defines DMTF processes governing the
formation, structure, and activities of DMTF bodies and the DMTF Release
Process for DMTF documents. This includes documents that are intended to become
standards, known as DMTF Standard Documents, as well as informational and
procedural documents, known as DMTF Informational Documents.
2 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.
2.1
Academic Alliance Member
An individual belonging to an accredited institution
of higher learning that has been assigned by the DMTF Board of Directors to a
single Working Group or Subcommittee as a non-voting member.
2.2
Alliance Partner Member
A not-for-profit association that has been offered and
has accepted a membership in the DMTF. The designated Alliance Partner Member
representatives may participate in designated DMTF Working Groups and
designated Committees as non-voting members. Alliance Partner Members may also
subscribe to the email lists, participate in list discussions, attend and
participate in meetings, and make contributions to the DMTF.
2.3
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.
2.4
Ballot
In this document, Ballot is defined as a vote by any
means
2.5
Board Member
Member Companies who are Voting Members and are
elected by Voting Members to serve on the Board of Directors. Board Member
companies appoint persons as representative directors to the Board.
2.6
Board of Directors
All corporate powers are exercised by and under the
authority of the Board of Directors, and the affairs of the corporation are
managed under its direction. Also referred to as the Board.
2.7
Body
This term is used as a substitution for Committee, Subcommittee,
Forum, Chapter, or Working Group that is the focus of the text in question.
2.8
Change Request
CR
The form used to request a change to the MOF Schema or
a DMTF Document
2.9
DMTF Document
Any specification, presentation, white paper, schema,
process document, policy, or other material released by the DMTF. This term does
not include press releases, Web page material, or marketing collateral.
2.10
DMTF Informational Document
A document released by the DMTF of an informative
nature that is meant to explain an aspect of the DMTF or its standards,
policies, procedures, or mechanisms.
2.11
DMTF Informational Specification
A specification of an informative nature produced by
DMTF incubators.
These documents proceed through the process similar to DMTF Specifications
rather than DMTF Informational documents; however, they are not DMTF Standards.
2.12
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.
2.13
DMTF Specification
DSP
Originally an abbreviation for “DMTF Specification”, a
DSP is now a synonym for DMTF Document. Each DSP has a number associated with
it.
2.14
DMTF Standard
A DMTF document status as well as a document phase. As
a document status, it indicates a document of a normative nature that addresses
a specific problem domain and has been released by the DMTF. As a document
phase, it indicates that the document has been approved by the DMTF Board for
publication.
2.15
Document Request
DR
The form that is used to request DSPs or change
editorial responsibility.
2.16
Document State
The state of the document, which is kept external to
the document, such as in metadata on the website
2.17
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 5.1.3.
2.18
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 5.1.5.
2.19
Editing Body
The Committee, Subcommittee, or Working Group assigned
editorial responsibility for any given document.
2.20
Electronic Ballot
A Ballot conducted electronically following the
procedures defined herein.
2.21
In Development
The period during which a document is being crafted by
the Editing Body.
2.22
Leadership Member
Member Company that has full voting privileges, has
full access to DMTF specifications and standards, and may chair a Body.
Leadership Members may join,
participate in, and vote in multiple Bodies.
2.23
Mantis
A comment-tracking tool provided by the DMTF for the
use of its members in tracking changes to specific documents
2.24
Member Company
A corporation or association that allows its employees
or representatives to subscribe to the email lists, participate in list discussions,
attend and participate in meetings, and make contributions to the DMTF. The
process for becoming a Member Company can be found at http://www.dmtf.org/join/company.
2.25
Model
A set of conceptual elements and the relationships
between them that collectively define the semantics, behavior, and state of
some thing.
2.26
MOF Schema
A Schema based or derived from a MOF definition. This
includes the CIM Schema, PRS Schema, and any additional Schema based or derived
from MOF created by the DMTF or Alliance Partners.
2.27
Monitoring Member
Member Company that has access to content and
communications on the member-only section of the DMTF website but does not
participate on any Committees, Subcommittees, or Working Groups.
2.28
Parent Body
DMTF body immediately above the current body. The
Parent Body for a Working Group is a Subcommittee. The Parent Body of a
Subcommittee or Forum is a Committee. The Parent Body for a Committee is the
Board.
2.29
Participating Member
Member Company that has full access to DMTF specifications
and standards. Participating Members may join and participate in multiple
Bodies except Committees. Participating Members may vote in Working Groups,
Forums and Chapters in which they have joined and participate.
2.30
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 voting entity. A voting entity may elect to
identify different persons as the Primary Voter in each Body in which it may
vote.
2.31
Process Document
Any document produced by the DMTF that defines the
policies and procedures that apply to the DMTF.
2.32
Schema
A formal language representation of a model. For
example, a MOF representation of the CIM model defines a CIM Schema.
2.33
Sponsored Member
An individual who is not an employee of a Member
Company, but who is sponsored to participate by a Member Company and
participates at the membership level of that Member Company.
2.34
Two Business Days
Two non-holiday eight hour work day periods or the
prior conference call or meeting of the Body, whichever period is shorter. For
a group that meets once a week on Wednesdays at noon, this would be 48 hours
prior. For a group that meets once a week on Mondays at noon, this would be
noon the previous Thursday. For a group that meets twice a week on Wednesday
and Thursday at noon, this would mean that the agenda for Thursday is published
immediately after or as part of the Wednesday meeting.
2.35
Voting Member
Member Company that has full voting privileges. This
is synonymous with Board and Leadership Member companies.
2.36
Work in Progress
A DMTF Document release mechanism, DMTF document
status, and a document phase. As a process, it is a method whereby a document
can be made available to the public, industry partners, and other interested
parties. The purpose of this mechanism is to garner feedback before the DMTF
Standard phase. As a document status, it indicates a snapshot of work that has yet
to be released by the DMTF. As a document phase, it indicates that the document
has been approved by a Committee, but not the DMTF Board for publication only
as a document of an informative nature.
The following abbreviations are used in this document.
3.1
CR
Change Request
3.2
DMTF
Distributed Management Task Force
3.3
DR
Document Request
3.4
DSP
DMTF Specification
3.5
IETF
Internet Engineering Task Force
3.6
MIB
Management Information Base
3.7
MOF
Managed Object Format
3.8
RONR
Robert's Rules of Order Newly Revised
3.9
URI
Universal Resource Identifier
3.10
URL
Uniform Resource Identifier
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. Each Committee has a DMTF
Board-approved charter that defines the scope of work to be undertaken by the
Committee in alignment with the direction of the DMTF.
A Committee consists of a representative from each of the
Voting Member companies that are interested in participating, non-voting
chairpersons of Subcommittees (see “Subcommittees,” section 4.2), non-voting Chairs
and vice-chairs of Committees, and a non-voting designated representative from
each of the Alliance Partner Members that are interested in participating. DMTF
expects as much continuity in representation as possible, subject to the contingencies
of the Member Company’s business.
Notice of meetings must be posted on the DMTF Event
calendar. Meeting agendas should be included in the Event calendar and must be
sent to the Committee email list by the Committee Chair at least two business
days before the meeting or the agenda may be set in the previous meeting,
whichever is less. Meeting agenda may be modified by a vote of the Committee
members in attendance. 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 scheduled meeting. Meetings can be face-to-face events or teleconferences.
Committees determine the frequency of their meetings.
A Committee Chair is responsible for informing the Board of
the progress and status of the specific work under development. Board companies
should provide sufficient staffing of the right experience so that a Committee
can complete its tasks on schedule. Committee Chairs are appointed by the Board
of Directors.
4.1.3.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 4.6.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). No two Vice Chair candidates can be from the same company. The Vice
Chair must be a voting member of the committee prior to the election. The Vice
Chair cannot be from the same company as the Chair.
The Committees can form Subcommittees. The Subcommittees
focus on issues in specific areas of the Committee's charter. As goals, charter, timeline, and deliverables evolve, the Subcommittee Chair is responsible for updating this information and
notifying the Chair of the parent Committee. In turn, the Chair notifies the
Chairs of the other Committees. If there are issues with the changes, a
discussion among the Committee, the Subcommittee’s Chair, and the Subcommittee’s members is scheduled. After all issues are resolved, the updated
charter, list of goals and deliverables, and timeline are Balloted by the
Committee, which must in turn be approved by the Board of Directors.
To exist, a Subcommittee must have "active" goals,
deliverables, timelines, 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 active goals if
at least one of its Working Groups has active goals. Additional requirements
for submissions and participation can be defined by a Subcommittee by extending
its charter and deliverables. If this is done, it must be approved by the
Subcommittee members and documented on the Subcommittee's main web page.
Changes to a Subcommittee charter must be
approved by the parent Committee and the Board of Directors.
The process to propose and form a new Subcommittee is
specified in section 4.6.1 with the Subcommittee being the Body referenced in
that section.
Subcommittees are open to DMTF Board and Leadership Members,
Participating and Sponsored Members and designated Academic Alliance and
Alliance Partner Members. Board and Leadership Members are encouraged to
participate in as many Subcommittees as they can actively contribute to.
Participating and Sponsored Members are non-voting members of Subcommittees. Academic
Alliance and Alliance Partner Members are non-voting members of Subcommittees,
as approved by the DMTF Board. Academic Alliance and Alliance Partner Members
are assigned to specific Subcommittees as non‑voting members when the board
approves their application. Monitoring Members do not participate in
Subcommittees.
Meeting notices are posted on the DMTF Event calendar.
Meeting agendas should be included in the Event calendar and must be sent to
the Subcommittee email list by the Subcommittee Chair at least two business
days before the meeting. Meetings can be face-to-face events or
teleconferences. Subcommittees determine the frequency of their meetings.
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 scheduled meeting.
Voting Members are eligible to chair a Subcommittee. No
other categories of membership have the right to chair a Subcommittee.
1)
The Subcommittee Chair is a non-voting member of the parent
Committee, unless voting as the Voting Member representative. A member company
may chair at most one Subcommittee of any given Committee.
2)
The Chair must adhere to the responsibilities as stated in
section 4.6.3.
3)
There is no fixed term for a Subcommittee Chair. Once elected, a
Subcommittee Chair serves until they resign or a new election is mandated by
the parent Committee.
4)
Subsequent elections for a Subcommittee Chair follow the process
for chair selection used in the Subcommittee Formation section.
5)
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 an individual may
vice-chair.
6)
In the unlikely circumstances that a Subcommittee Chair is unable
to fulfill the responsibilities of the position and has not resigned, three
Voting Member Subcommittee participants from three separate companies 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.
The formation of a subteam within a Subcommittee is not
allowed.
From time to time, it is necessary for Subcommittees to
update their charter. This could be an expansion or reduction in scope, change
in deliverables, timelines, Chairs or other information in the charter. The
process to update a Subcommittee charter is as follows:
1)
When a Subcommittee has approved an updated charter, they must
forward it to the Committee. The Committee is then responsible for approving
the changes to the charter.
2)
The Committee Chair then notifies the Board of the changes to the
charter. If the changes involve changes in scope, the charter must be approved
by the Board. Changes in the first three sections of the charter are considered
changes in scope (Management Problem(s) and Environment, Subcommittee Charter,
Alliance Partnerships). If the changes do not involve changes in scope, the
charter does not need formal approval by the Board. The charter can be
considered to be approved after the following board meeting unless the Board
chooses to take action and formally rejects the changes.
Subcommittees cannot be quiesced.
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 Us page.
The Subcommittees form Work Groups, which are commonly known
as Working Groups. The Working Groups focus on issues in specific areas of the
Subcommittee's charter. As goals, charter, timeline, and deliverables evolve, the Working Group Chair is responsible for updating this
information and notifying the Chair of the parent Subcommittee. In turn, the
Chair notifies the Chairs of the other Working Group under the Subcommittees.
To exist, a Working Group must
have "active" goals, deliverables, timelines, 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 and deliverables. If this is done, it must be approved by
the Working Group members and documented on the Working Group's main web page.
Changes to a Working Group charter must be approved by the parent
Subcommittee, Committee, and the Board of Directors.
The process to propose and form a new Working Group is
specified in section 4.6.1 with the Working Group being the Body referenced in
that section.
Working Groups are open to
DMTF Board, Leadership, Participating, and Sponsored Members and designated
Academic Alliance and Alliance Partner Members. Board, Leadership,
Participating, and Sponsored Members are encouraged to participate in as many
Working Groups as they can actively contribute to. Academic Alliance and
Alliance Partner Members are members of Working Groups but do not have the
right to vote, as approved by the DMTF Board. Academic Alliance and Alliance
Partner Members are assigned to specific Working Groups as members that do not
have the right to vote when the Board approves their application. Monitoring
Members do not participate in Working Groups.
Meeting notices are posted on the DMTF Event calendar.
Meeting agendas should be included in the Event calendar and must be sent to
the Working Group email list by the Working Group Chair at least two business
days before the meeting. Meetings can be face-to-face events or
teleconferences. Working Groups determine the frequency of their meetings.
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 scheduled meeting.
Voting Members are eligible to chair a Working Group.
Chairing a Working Group includes being a co‑chair or vice-chair of a Working
Group. Sponsored Members can chair a Working Group with Board approval. No
other categories of membership have the right to chair a Working Group.
1)
The Working Group Chair is a non-voting member of the parent
Subcommittee, unless voting as the Voting Member representative. An individual
may chair/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 Group that an individual may
vice-chair.
3)
There is no fixed term for a Working Group Chair. Once elected, a
Working Group Chair serves until they resign or a new election is mandated by
the parent Subcommittee.
4)
Subsequent elections for a Working Group Chair follow the process
for Chair selection used in section 4.3.1.
5) In
the unlikely circumstances that a Working Group Chair is unable to fulfill the
responsibilities of the position and has not resigned, three Voting Member
Working Group participants from three separate companies 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.
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.
From time to time, it is necessary for Working Groups to
update their charter. This could be an expansion or reduction in scope, change
in deliverables, timelines, chairs, or other information in the charter. The
process to update a Working Group charter is as follows:
1)
When a Working Group has prepared an updated charter, they must
forward it to the Subcommittee. The Subcommittee is then responsible for
approving the changes to the charter.
2)
The Subcommittee Chair then notifies the Board of the changes to
the charter. If the changes involve changes in scope, the charter must be
approved by the Board. Changes in the first three sections of the charter are
considered changes in scope (Management Problem(s) and Environment, Working
Group Charter, Alliance Partnerships). If the changes do not involve changes in
scope, the charter does not need formal approval by the Board. The charter can
be considered to be approved after the following Board meeting unless the Board
chooses to take action and formally rejects the changes.
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 Us page.
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 Us page.
The Interoperability Committee forms Forums. Forums focus
on issues in specific areas of the Interoperability Committee'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 they collect/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 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 governing Committees.
As goals, charters, timelines, and deliverables evolve, the Forum Chair is
responsible for updating this information, and notifying the Chair of the
Committee. In turn, the Chair will notify the Chairs of the other Committees.
If there are issues with the changes, a discussion between the Committees, the
Forum Chair, and members is scheduled. After all issues are resolved, the
updated charter, list of goals and deliverables, and timeline are Balloted by
the Board of Directors.
Forums may still be considered active regardless of
whether scheduled teleconferences occur, and/or change requests are submitted.
It is necessary that Forums have "active" goals, deliverables,
timelines, and charter in order to exist. Additional requirements for
submissions and participation can be defined by a Forum basically extending 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. Changes to a
Forum charter MUST be approved by the Interoperability Committee and the Board
of Directors.
The process to propose and form a new Forum is specified
in section 4.6.1 with the Forum being the Body referenced in that section.
Forums are open to DMTF Board, Leadership, Participation,
and Sponsored Members and designated Academic Alliance and Alliance Partner
representatives that pay any additional fees/dues established by the Forum. Academic
Alliance and Alliance Partner representatives are non-voting members of Forums,
as approved by the DMTF Board. Academic Alliance and Alliance Partner Members
are assigned to specific Forums as non-voting members when the Board approves
their application. Monitoring membership does not include Forum access.
Notice of meetings shall be posted on the DMTF Event
calendar. Meeting agendas should be included in the Event calendar and must be
sent to the Forum email list by the Forum Chair 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 scheduled meeting. Meetings may be face-to-face events or teleconferences.
Forums may decide on the frequency of their meetings.
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. Voting
Members who pay applicable Forum dues are eligible to be an officer in a Forum.
A DMTF member company may hold only one officer position in any given Forum. Sponsored
members can be an officer in a Forum with Board approval unless otherwise
prohibited by the Forum charter. No other categories of membership have the
right to be an officer in a Forum. The Forum Chair is a non-voting member of
the sponsoring Committee, unless voting as the Voting Member representative.
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 for Chair selection used in section 4.4.1.
The Chair/co-chair must
adhere to the responsibilities as stated in section 4.6.3.
It is sometimes necessary to form subteams within a Forum
in order 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, charter, deliverables, and timeline 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/dues requirements.
Dues/fee
collection, banking services, and 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.
The
Technical Committee shall ultimately govern/manage all standards or
specifications that a Forum may require.
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).
Marketing and PR needed to carry out the Forums objectives
are supplied to the Forum through the DMTF Marketing Committee.
From
time to time, it may be necessary for a Forum to update their charter, dues,
membership privileges, or other characteristics of the Forum’s operation.
4.4.10.1 Modifying
the Forum charter
When
the Forum proposes an expansion or reduction in scope, change in deliverables,
timelines, Chairs or other information in the Forum charter, the charter must
be modified. The process to update a Forum charter is as follows:
When the Forum has prepared and accepted an updated
charter, they must forward it to the Committee. The Committee is then
responsible for reviewing changes to the charter and providing comments and
recommendations back to the Forum as information.
The Committee Chair then notifies the Board of the changes
to the charter. If the change involves changes in scope, the charter must be
approved by the Board. Changes in the first three sections of the charter are
considered changes in scope (Management Problem(s) and the Environment, Working
Group Charter, Alliance Partnerships). If the changes do not involve changes in
scope, the charter does not need formal approval of the Board. The charter can
then be considered to be approved after the following Board meeting unless the
Board chooses to take action and formally rejects the changes.
4.4.10.2 Other
changes in group practices and procedures
When the Forum proposes changes that are not changes to
the charter, but change operating practices or procedures that include Forum
dues, membership classes, or changes in membership entitlements, the process is
as follows.
When the Forum has prepared and accepted these changes,
they must forward the proposed changes to the Committee. The Committee is then
responsible for reviewing the changes and providing comments and
recommendations back to the Forum as information.
The Committee Chair then notifies the Board of the
changes. These changes do not need the formal approval of the Board. The
changes can then be considered to be approved after the following Board meeting
unless the Board chooses to take action and formally rejects the changes.
Forums cannot be quiesced.
The process to dissolve a Forum is as follows:
4.4.12.1 Voluntary
dissolution of a Forum
A Forum
Chair may request the Interoperability Committee Chair that a Forum be
dissolved. This move is justified when there are no remaining Forum goals and
deliverables or the Forum is inactive. This request is then conveyed to the
DMTF Board by the Interoperability Committee Chair. If there are issues with
the move to dissolve, a discussion between the Interoperability Committee Chair
and the Forum’s representative is scheduled to negotiate a solution. If there
are no issues or discussion, a request to dissolve the Forum is sent to the
Board for 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 they
wish to continue after the Forum is dissolved, the Forum must develop a plan
with the Interoperability Committee Chair for the continuation of such
programs, and obtain the approval of the DMTF Board for the programs to
continue.
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.
4.4.12.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 discovered that a Forum is operating outside the
rules and policies of the DMTF, the Interoperability Committee 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 Interoperability Committee Chair notifies
the DMTF Board, and the Board votes to dissolve the Forum.
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.
4.4.12.3 Announcement
of dissolution
After the Board vote to dissolve the Forum passes, an
announcement is sent to all DMTF members within 20 business days indicating
that the Forum is dissolved, and providing 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 Us page.
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/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. As goals, charter, timeline, and deliverables evolve, the
Chapter Chair is responsible for updating this information, and notifying the
Chair of the Committee. In turn, the Chair will notify the Chairs of the other
Committees. If there are issues with the changes, a discussion between the
Committees, the Chapter Chair, and members is scheduled. After all issues are
resolved, the updated charter, list of goals and deliverables, and timeline are
Balloted by the Board of Directors.
Chapters may still be considered active regardless of
whether teleconferences occur, and/or change requests are submitted. It is
necessary that Chapters have "active" goals, deliverables, timeline,
and charter in order 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. Changes to a Chapter
charter MUST be approved by the RCC and the Board of Directors.
The process to propose and form a new Chapter is specified
in section 4.6.1 with the Chapter being the Body referenced in that section.
Chapters are open to DMTF Board, Leadership,
Participation, and Sponsored Members and designated Academic Alliance and
Alliance Partner representatives that pay any additional fees/dues established
by the Chapter. Academic Alliance and Alliance Partner representatives are
non-voting members of Chapters, as approved by the DMTF Board. Academic
Alliance and Alliance Partner Members are assigned to specific Chapters as
non-voting members when the Board approves their application. Monitoring
membership does not include Chapter access.
Notice of meetings shall be posted on the DMTF Event
calendar. Meeting agendas should be included in the Event calendar and must be
sent to the Chapter email list by the Chapter Chair 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 scheduled meeting. Meetings may be face‑to‑face events or teleconferences.
Chapters may decide on the frequency of their meetings.
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. Voting
Members who pay applicable Chapter dues are eligible to be an officer in a
Chapter. A DMTF member company may hold only one officer position in any given
Chapter. Sponsored members can be an officer in a Chapter with Board approval
unless otherwise prohibited by the Chapter charter. No other categories of
membership have the right to be an officer in a Chapter. The Chapter Chair is a
non-voting member of the sponsoring Committee, unless voting as the Voting
Member representative. The Chair is responsible 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 for Chair selection used in section 4.5.1.
The Chair/co-chair must adhere to the responsibilities as
stated in section 4.6.3.
It is sometimes necessary to form subteams within a Chapter
in order 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, charter, deliverables, and timeline 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/dues requirements.
Dues/fee collection, 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.
The Technical Committee shall ultimately govern, manage, and
approve all standards or specifications that a Chapter may require.
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).
Marketing and PR needed to carry out the Charter’s
objectives will be developed in conjunction with the DMTF Marketing Committee.
From time to time, it may be necessary for a Chapter to
update their charter, dues, membership privileges, or other characteristics of
the Chapter’s operation.
4.5.10.1 Modifying
the Chapter charter
When the Chapter proposes an expansion or reduction in
scope, change in deliverables, timelines, Chairs or other information in the
Chapter charter, the charter must be modified. The process to update a Chapter
charter is as follows:
1)
When the Chapter has prepared and accepted an updated charter,
they must forward it to the Committee. The RCC is then responsible for
reviewing changes to the charter and providing comments and recommendations
back to the Chapter as information.
2)
The RCC Chair then notifies the Board of the changes to the
charter. If the change involves changes in scope, the charter must be approved
by the Board. Changes in the first three sections of the charter are considered
changes in scope (Management Problem(s) and the Environment, Working Group
Charter, Alliance Partnerships). If the changes do not involve changes in
scope, the charter does not need formal approval of the Board. The charter can
then be considered to be approved after the following Board meeting unless the
Board chooses to take action and formally rejects the changes.
4.5.10.2 Other
changes in group practices and procedures
When the Chapter proposes changes that are not changes to
the charter, but change operating practices or procedures that include Chapter
dues, membership classes, or changes in membership entitlements, the process is
as follows.
1)
When the Chapter has prepared and accepted these changes, they
must forward the proposed changes to the RCC. The RCC is then responsible for
reviewing the changes and providing comments and recommendations back to the
Chapter as information.
2)
The RCC Chair then notifies the Board of the changes. These
changes do not need the formal approval of the Board. The changes can then be
considered to be approved after the following Board meeting unless the Board
chooses to take action and formally rejects the changes.
Chapters cannot be quiesced.
The process to dissolve a Chapter is as follows:
4.5.12.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.
4.5.12.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.
4.5.12.3 Announcement
of dissolution
After the Board vote to dissolve the Chapter passes, an
announcement is sent to all DMTF members within 20 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 Us page.
This section contains information supporting the prior
sections.
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 Voting
Member companies 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 from a Board or Leadership Member company. 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 Voting Member companies 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, a list of goals and deliverables, and a proposed
timeline. At least three Voting Member companies must express interest in order
to continue to the next step.
3)
After at least three Board or Leadership Member companies have
expressed interest in forming the new Body, representatives from these
companies 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 an
initial charter, a list of goals and deliverables, and a timeline to the Chair
of the appropriate Parent Body. In addition, the interim Chair must identify at
least three member companies that are committed to the ongoing work. The Parent
Body Chair then verifies the submitted information. If no issues exist, the
charter, timeline, and lists 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 goals, charter,
deliverables, committed companies, and timeline should be raised in the initial
Ballot and then worked to closure.
5)
After Board approval of the initial Working Group 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, goals, deliverables, list
of committed companies, and timeline are reviewed (and possibly amended); the
chairing method for the Body is decided (single chair, chair/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 Working Group formation meeting, any Chairs, vice-chairs,
co-chairs or other officers that are elected are elected according to the
procedure in section 4.6.2.
The following section applies to the selection of Chairs, Co-Chairs,
Vice Chairs and other officers. While this section mentions Chairs, Co-Chairs and
Vice Chairs specifically, the procedure applies to any elected position where
there is a primary role (Chair), secondary or assistant role (Vice Chair) or
shared role (Co‑Chairs). Each candidate for any position must be from a
singular company.
1)
The presiding Parent Body Chair accepts nominations for the Chair
of the Body. Nominations can be submitted at the meeting or by email to the
appropriate Parent Body Chair alias.
2)
At the next meeting, the appropriate Parent Body Chair announces
the list of nominees. Each nominee describes his or her background and interest
in the Chair role. If multiple candidates for Chair exist, the Chair is
selected through an email Ballot to the appropriate Parent Body Chair alias. If
only one Chair candidate exists, members may voice objections to the candidate
to the appropriate Parent Body Chair alias within seven days of the candidate
announcement.
3)
If the group has decided that a Vice Chair should be selected,
the Vice Chair is elected after the Chair has been selected and the process
follows the Chair selection process. Candidates for Vice Chair must not be from
the same company as the Chair.
4)
If the group has decided that Co-Chairs should be selected, the
election process is different if multiple candidates exist. For Co-Chair Ballots,
each company gets two votes for Working Group Chair but each vote must be for
different individuals. If there are two candidates with a majority of votes,
they are elected Co-Chairs. If there is one winner with a simple majority (50%)
votes, there will be a run-off vote for the other Co-Chair between the two
candidates that receive the most votes besides the candidate with a majority. In
the event that the prior methods do not result in Chair selection, Co-Chairs will
be selected one at a time (similar to the process of voting Chair and then Vice
Chair). Should no candidate receive a majority of votes at this point, a
plurality will suffice.
This section covers the responsibilities of a Chair, Vice Chair
or Co-Chair. The terms “Body”, “Parent Body” and “subordinate Body” are used
here to make this section apply equally to all levels of the organization.
·
The Chair is responsible for acting as the chair for all meetings
and ensuring that all DMTF policies and procedures are followed.
·
The Chair is responsible for attendance in and reports to
meetings of the Body and 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.
·
The Chair is responsible for bringing Body issues to the Parent Body
for resolution and Body output 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 web site, together with pertinent
documents. If a Body chooses to rotate responsibility for recording minutes
amongst its participants, each participating company is required to participate
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
Body charters are up to date and operating within their charter.
·
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 that the DMTF Recording
Policy is adhered to.
·
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.
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 handled:
1)
When the Chair, Co-Chair or Vice Chair leaves or changes
companies (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 4.6.5
require that an election be held.
3)
When a member company is purchased by, or merged, with another
company and the Co-Chairs and/or the Chair and Vice Chair now report to the
same company, 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.
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 group 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 group 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 group 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 group 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 group 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 group 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.
4.6.6 Rules
of Order
The rules contained in the current edition of Robert's Rules
of Order Newly Revised shall govern the DMTF (including Committees,
Subcommittees, Working Groups, Forums, and Chapters) in all cases to which they
are applicable and in which they are not inconsistent with the DMTF Bylaws and
any special rules or processes that are defined in this document.
From time to time, in the course of DMTF activities a situation
may arise where action taken or not taken by a group or member is alleged to be
in violation of the policies, processes, and procedures set forth by the DMTF. Members
involved in a disagreement should attempt to resolve the disagreement within the
group. If this attempt is unsuccessful, the issue should be documented in the
group minutes. When this situation occurs, an eligible member may appeal this
with an escalation. The creation of an escalation results in review of the
situation and resolution by the parent group. “Group” may represent a Working
Group, Committee, Board, Forum, or any other DMTF grouping structure.
4.6.7.1
Eligibility
Any DMTF member may raise an escalation.
4.6.7.2
Responsibilities
When a member raises an escalation, it is the responsibility
of the Chair of the parent group to place the issue on the agenda for
discussion within the next 3 regular meetings or 30 days, whichever is smaller.
·
The parent group Chair must inform the originating group 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 group Chair
are invited to attend regardless of normal participation rights.
4.6.7.3
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.
4.6.7.4
Timeline
An escalation must be raised within 30 days of the contested
action.
4.6.7.5
Further escalation
If the member escalating an issue is dissatisfied by the
resolution of the parent group or committee, the escalation may be raised to
the next level in the organization. For example, an escalation starting in a
Working Group would move to the Subcommittee, the Technical Committee, and then
the Board.
4.6.7.6
Final decisions
Escalations that reach and are resolved by the Board of
Directors are considered final within the DMTF.
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.
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 Participating Member or Voting Member may cast
only one vote in any DMTF Ballot conducted by any means. If a Participating Member
or Voting 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 Participating Member or Voting Member.
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.
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
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.
Because RONR discusses but does not specify the procedures
for Electronic Ballots, the rules governing Electronic Ballots are described
herein.
4.6.13.1 Validity
Electronic Ballots have equal weight and validity to other
voting mechanisms described in Roberts Rules of Order Newly Revised.
4.6.13.2 Electronic Ballot lifecycle
·
A motion is made, discussed, and potentially amended that will be
decided by Electronic Ballot.
·
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 for the duration that the Electronic
Ballot is open and 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, and
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.
4.6.13.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.
4.6.13.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 Voting or Participating Members may do so by means of an
abstention with comment.
4.6.13.5 Incorporation
of comments
Although comments are encouraged in order 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.
4.6.13.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.
4.6.13.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.
·
Any member of the voting Body may either cast or
change his 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.
4.6.13.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.
4.6.13.9 Responsibility to manage
Electronic Ballots
shall be opened, managed, and closed by the Chair or designee.
4.6.13.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.
DMTF meetings of any Body may, at the discretion of the
designated recording secretary, may be audio-recorded, 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."
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.
The phases in the release process for a DMTF Standard are as
follows:
·
DSP number acquisition
·
In Development
·
Work in Progress (optional)
·
Member Review
·
DMTF Standard
The phases in the release process for a DMTF document that
is not a DMTF Standard are as follows:
·
DSP number 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 5.2.3 for versioning requirements. In addition, Work in
Progress documents must contain the expiration date on the title page.
The CIM (or other MOF-type Schema) standard is specified in
Management Object Format (MOF). DMTF MOF Schema consists of 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
member companies and organizations for document review and editing varies.
Items submitted to the DMTF must be in an acceptable format, as described in
section 5.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 6.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.
The first step of the process is for the Subcommittee, Forum,
or Working Group to obtain editorial responsibility for the document. In the
case of new works, this means acquiring a DSP number (see Figure A‑1).
In the case of prior works, this means acquiring editorial responsibility for
the appropriate document, in whole or in part. For MOF Schema, editorial
responsibility is decided according to Subcommittee, Forum, and/or Working
Group charter and the section of the MOF being modified. The form used to
obtain the DSP number is a Document Request (DR) as described below. This is
also the form used to request development of a new schema.
5.1.2.1
Document Requests (DR)
The purpose of a DR is to request ownership (either for a
new or for an existing document), name change, or transition to the DMTF
historical documents page. Such requests are included in DR format for
convenience because the template has the appropriate front matter, an area to describe
and justify what is needed, and a Body for the request form.
Document Requests shall be submitted only by Chairs, though
the document owner can be any member of an Editing Body. The DR should be
approved by the DMTF Parent Committee before any work begins in an Editing Body.
5.1.2.2
DR content and format
Document Requests are used for DMTF document acquisition,
such as when requesting a DSP number or approval of a new schema (for example,
a MOF prefix). DRs must be created by using the DR template, which is very
similar to the CR template. The content of this template includes:
·
Chair(s) of the Body requesting the DSP number
·
Document Type being requested (DMTF Standard, white paper, etc.)
·
name of the associated document
·
name of the Editing Body
·
date the request began
·
background rationale for the accompanying document
·
intention to publish or submit to (see section 5.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
DRs must be submitted by using the current version of the
DMTF DR Template (see ANNEX B). A 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 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.
5.1.2.3
DR Balloting
In order for a DR to be approved, the Editing Body must vote
to approve the DR. After it is approved by the Editing Body, the DR document
proceeds to the Parent Subcommittee (if any). After approval by the Parent
Subcommittee, it must be approved by the Parent Committee. After the Parent
Committee approves the DR, the Committee Secretary notifies the Editing Body
that the DR has passed, the name of the document that was approved, and the DSP
number to be associated with that document.
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
5.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.
A Body that has Editorial Responsibility (the Editing Body)
for a document may vote to release a Work in Progress for review to one or more
recipients, including the general DMTF membership, an Alliance Partner
organization, or 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 number, all DMTF
copyright notices, and their expiration date. 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 5.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 the stated expiration date.”
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.
Occasionally, it is necessary to release an individual
Change Request as a Work in Progress. This may be needed in order to obtain
feedback on an individual change (Schema or otherwise) from non-DMTF members,
such as Alliance Partners. In the case where 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, as well as an expiration date.
All Work in Progress documents approved by the Parent
Committee must contain an expiration date that is one to six months from the
date of approval by the Parent Committee. After the expiration date has been
reached, the Parent Committee is responsible for ensuring that the document is
no longer shared with the recipients. Before the document expires, the
originating Editing Body may submit an update to the document with a new
expiration date (which is essentially a new Work in Progress). The period of
time that a Work in Progress is shared, including extensions, must not exceed
six months from the date of approval by the Parent Committee.
Any feedback from Alliance Partner organizations, the
general public, or a company or individual 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.
After the Parent Committee has approved sharing a Work in
Progress document, the owning Editing Body may decide to have the document
withdrawn prior to the expiration date. The Editing Body may submit a request that
the document be withdrawn.
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.
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 number, 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 5.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 5.1.3.5).
5.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 5.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 companies that must
be members of DMTF 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.
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 number, all DMTF
copyright notices, and all required disclaimers including a notice that they
are subject to change. They must not contain an expiration date. 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
5.1.6).
Corrections to a DMTF Standard must be handled as Errata.
Errata are released using the process defined in 5.1.3.3 and 5.1.3.5.
Documents with the status of DMTF Informational consist of
presentations, white papers, process documents 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
and white papers 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 number. 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 number, but they do not go through the
DMTF Draft Standard and DMTF Standard phases described in 5.1.3.3 and 5.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 5.1.6).
See Figure A‑2
for the approval process for Informational documents.
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 number
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 5.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.
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)
|
Not more than six months
|
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
|
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 time publication with any press release material.
If no delay is requested, disposition 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 5.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)
|
|
Tech Note
|
DMTF Informational
|
Informational Documents (see Figure A‑2)
|
|
Presentation
|
DMTF Informational
|
Informational Documents (see Figure A‑2)
|
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.
5.1.6.1
DMTF web site publication
Documents approved for publication are released on the DMTF
web site. The changes required for that 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
5.1.3.2, 5.1.3.5, 5.1.3.6, and 5.1.3.7). The document is then published on the
web site.
Specifications are published and a URL 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. URLs
may also be generated or updated at the major revision and major.minor.revision
level. These URLs are used for reference by DMTF and other standards so that
the latest revision is always incorporated by reference in the referencing
document.
5.1.6.2
Submission and transfer
In the case where 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.
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.
For a given version of a DMTF Standard, at most one revision
may be shared as a Work in Progress, released as a DMTF Draft Standard, or
released as a DMTF Standard. For example, it is not permissible for version
1.0.0f of a document to be shared outside of DMTF Working Groups as a Work in
Progress simultaneous with the release of version 1.0.0 as a DMTF Standard. Nor
is it permissible for versions 1.0.0a and 1.0.0b of a document to be released
as a Work In Progress simultaneously. It is possible to have version 2.0.0 of a
DMTF Standard specification published at the same time as version 1.6.2 of a DMTF
Standard specification, as well as version 1.7.0.
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.
DMTF documents, with the exception of the CIM and other MOF
Schema, are given a DMTF Specification (DSP) number. The version information
for the document is inserted following this DSP number. 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 5.3.
DSP numbers 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 numbers 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.
The title page material required for DMTF documents differs
from the header material required for DMTF MOF Schemas.
5.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 number was obtained.
·
DSP number
This must be the DSP number
obtained according to the policy described in 5.1.2.
·
Version number
This version number must
comply with the guidelines in 5.2.3.
·
Date
This must be the effective
date of the specification.
·
Expiration date
The expiration date is needed
only for Work in Progress documents. It should be in the same format as the
date.
·
Logo
A DMTF logo should be included
on the title page.
·
Document Type
This must be one of the type
designations described in 5.1.5.
·
Document Status
This must be one of the status
designations described in 5.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
5.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
·
Expiration date (if the document is a Work in Progress)
The format of these items depends on the file type and must
be consistent across files of the same type.
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.
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.
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 CIM MOF. 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.
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
|
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 in order to make changes to the
document. Documents shall not be Balloted at Committees until the documents are
stored in the DMTF CVS repository.
A Subcommittee or Working Group developing a document (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
|
|
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 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 5.2.3. Additionally, this information must be
embedded inside the specification itself. When specifying the document number
for DMTF specifications numbered less than 1000, the leading zero must be
specified. For example, "DSP0825_1.0.0.pdf" is correct, while
"DSP825_1.0.0.pdf" is not.
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
handle comment resolutions.
Several mechanisms are available to DMTF Editing Bodies to
handle 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.
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 that are approved
by WGs that have the change in it imply the change has been approved.
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 6.2. For MOF Schema, Change
Requests are the only comment-resolution method that is allowed.
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.
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.
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.
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.
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.
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 ore metadata, if approved
by the Editing Body and Parent Body and Parent Committee.
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.
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.
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.
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 company
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
4.6.10). 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.
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.
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.
The DMTF may create Management Initiatives for purposes of
consolidating messaging and promotion around technical or interoperability
deliverables.
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.
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.
It must have messaging components:
·
It must have requirements for messaging or technical evangelism
to promote the Management Initiative for the mutual benefit of membership
companies. 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.
It should have compliance and/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.
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 the compliance
and/or interoperability components are appropriate.
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.
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 4.2.1. The charter of the Subcommittee is
to manage the messaging of the Management Initiative.
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.
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.
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.
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.
Failure to participate can result in an individual 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.
If a member wants to disseminate unreleased DMTF information
within their company for internal review, it is permitted as long as the information
is marked as "DMTF Confidential." Confidential information should not
be redistributed to any employee of a non-DMTF member company without the
permission of the DMTF Board of Directors.
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.
When a document is approved by the Board as a Preliminary
Document, a request is made by the appropriate Vice President, after approval
from the Executive Committee, to Member Companies to disclose any essential
patent rights that might be infringed by an implementation of the technology described
in the posted document, as required in the DMTF Patent Policy.
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
|
|
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
|
|
BOD-Pending
|
|
Conditional
|
CMTE – Approved-Pending
|
|
No
|
CMTE – Update-needed
|
|
CMTE – EditorialReview
|
The document or request has been approved but requires the
document state/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
|
|
CMTE – Pending
|
|
Conditional
|
SC – Approved-Pending
|
|
No
|
SC – Update-needed
|
|
SC – EditorialReview
|
The document or request has been approved, but requires
the document state/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
|
|
SC – Pending
|
|
Conditional
|
WG – Approved-Pending
|
|
No
|
WG – Update-needed
|
|
WG – EditorialReview
|
The document or request has been approved, but requires
the document state/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 number 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)
DR template
|
TO
|
DMTF VP of Technology
|
|
FROM
|
j.doe@example.com
|
|
GROUP
|
WIP WG, J.Doe Chair
|
|
DATE OF ORIGIN
|
|
Document Information
Document Name:
Document Type:
Editing Body:
Transfer: No (if Yes, provide DSP#)
Publication Disposition: Publish on DMTF Website
Synopsis and Rationale:
ANNEX C
(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”
|
