All changes to be submitted by the Working Group Chair (or designee) after approval by the working group.
The Change Request
sample (http://www.dmtf.org/members/zdata/CRTemplateSample.html)
contains more detailed
information on how to complete the template.
DMTF Change Request Number [CIMCoreCR006655] |
|
CR Owner Name, Email |
|
Alliance
Partner submitting CR request (if applicable) |
|
Alliance
Partner vote history (e.g. SNIA XYZ Approved on 8/12/06) |
|
Alliance
Partner identifier/tracking number (if available) |
|
Errata [Yes|No] |
|
Short Description |
|
Spec, Document or Model(s) Being Changed |
|
Spec, Document or Model Version Incorporating the Change [2.16.0 Experimental | Final] |
|
Filename(s) Incorporating the Change |
|
Date Originated [mm/dd/yyyy] |
|
Date of Last Revision of the Change Request [mm/dd/yyyy] |
|
Dependencies [CIMCoreCR00555,CIMCoreCR00600,...] |
Terminology
The terminology used in this CR should conform to the "Rules for the structure and drafting of International Standards", 5th Edition, 2005 available at:
Particular attention shall be paid to Annex H which lays out guidelines for the expression of provisions.
Background/Rationale (Explanation of the
background and reason(s) for the requested change, and supporting
documentation):
Alliance
Partner Status (tracking number, other key identifiers,
supporting documentation, etc.):
(insert text here)
Requested
Change (Change information such as details before/after the change
and/or references documents (other then MOF) if the changes are too
lengthy to include inline):
// Add the new
class CIM_PrintAlertRecord
MOF
Changes (The complete CIM Class (ASCII) using blue text for new, red
text for removed and black text for no change, only one CIM Class can
be changed per CR): |
|
Discussion Points (Summary of decisions and discussions of the WG in creating this CR) :
Comments from
Core ballot closing 2007/09/21:
Company | Person | Issue and Response |
Brocade |
John Crandall |
Why not use RecordData instead
of defining LocalizedDescription? [PWG] We will place a number of properties into RecordData. However, we want the most important information about an alert to be visible directly in a property: subunit (in ComponentClassName), instance within a subunit (in ComponentElementName), criticality (in SeverityLevel), and the manufacturer's description of the alert (in Localizeddescription). Alerts are considered the most important information about a printer in normal operation, and we want this data to be accessible. Why not associate to the actually element instead of defining ComponentClassName/ComponentElementName? [PWG] An alert record is a snapshot of the state of the device at the time a condition occurs. It is encoded in a form suitable for offline processing, when the state of the device may have changed or the device may not be available at all. Associations are not possible or not reliable in these circumstances. |
Change History (Mandatory after submission to the TC, May be used by the WGs):
Version |
Date |
Short description of changes |
00 |
09/12/2007 |
Original version. |
01 |
10/05/2007 |
Add comments to properties
required for static snapshot of Alert entries. Demote some SNMP-specific properties into RecordData. |
Note that this
document is labeled as "DMTF Confidential". It is intended only
for DMTF member companies and alliance partners.
This Change Request may be withdrawn or modified by subsequent Change
Requests.
All submissions MUST comply with the DMTF Patent and Technology policy (http://www.dmtf.org/about/policies/patent-10-18-01.pdf)
Template Version
2.0.1b
Copyright (C) 2007 Distributed Management Task Force,
Inc. (DMTF). All rights reserved.