DMTF Change Request

DMTF Confidential

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]

CIMCoreCR01002

CR Owner Name, Email 
[My Name, my.name@company.com]

Richard Landau, Richard_Landau@dell.com
Alliance Partner submitting CR request (if applicable)
Printer Working Group, www.pwg.org
Alliance Partner vote history
(e.g. SNIA XYZ Approved on 8/12/06)
n/a
Alliance Partner identifier/tracking number (if available)
CIMCoreCR_PrintAlerRecord_00.htm

Errata   [Yes|No]

No

Short Description

Add class CIM_PrintAlertRecord to enhanced printer device model. 

Spec, Document or Model(s) Being Changed
[Application|Core|Database|Device|Event|Interop|
Network|Physical|Policy|Support|System|User ]

Device

Spec, Document or Model Version Incorporating the Change  [2.16.0 Experimental | Final]

2.17 Experimental

Filename(s) Incorporating the Change
[Core/CIM_Container.mof, DSP0204.pdf]

CIM_PrintAlertRecord.mof

Date Originated  [mm/dd/yyyy]

09/12/2007

Date of Last Revision of the Change Request [mm/dd/yyyy]

10/05/2007

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:

http://isotc.iso.org/livelink/livelink.exe/fetch/2000/2122/3146825/4229629/4230450/4230456/ISO_IEC_Directives__Part_2__Rules_for_the_structure_and_drafting_of_International_Standards__2004__5th_edition___pdf_format_.pdf?nodeid=4230517&vernum=0

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):

As part of the PWG/DMTF Work Register, PWG is updating the printing-related classes in the CIM data model.  The PWG models for printing related devices and services include many properties that need to be managed but are not currently represented in CIM at all.  The CIM model is being extended to include these important management objects.  This requires extensions to the CIM_Printer class and the addition of other CIM classes to represent the capabilities, settings, and counters required.  

Many early implementers of this class are expected to be proxy providers for SNMP-capable printers.  A few properties in this class are included to permit software and users to correlate status and event information between CIM and legacy SNMP access paths.  It is expected that such properties will be deprecated when they are no longer needed for this purpose.  

The current new class, CIM_PrintAlertRecord, is one of the several classes to be added. 

The class CIM_PrintAlertRecord is designed to meet the requirements of the DMTF Record Log Profile (DSP1010) and the requirements of the printer model of a persistent alert log, as embodied in the prtAlert section of the IETF Printer MIB (RFCs 1759 and 3805).  The CIM_PrintAlertRecord class includes a number of properties that are present in the existing native printer alerts and are used by client applications to locate alert conditions within the mechanism of the printer. 

A printer alert log is a snapshot of the state of the device at the time an alert condition occurs.  It is preserved in a format that is suitable for offline processing, when the device may have changed or may not be available for immediate interrogation.  A few important properties from the alert record are included directly as properties; other less important data from the alert is captured in the RecordData property. 


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):

// Copyright (c) 2007 DMTF.  All rights reserved.
// ==================================================================
// CIM_PrintAlertRecord
// ==================================================================

[Experimental, Version ( "2.17.0" ),
UMLPackagePath ( "CIM::Device::Printing" ), Description (
"This class represents an alert (warning or critical event) on "
"a Printer (print device). A critical alert is one that stops "
"the Printer from printing immediately and printing cannot "
"continue until the critical alert condition is eliminated. "
"Non-critical alerts are those alerts that do not stop printing "
"immediately, but may do so at some future time. A "
"PrintAlertRecord shall be associated with exactly one Printer "
"via an instance of the PrintAlertLog class. See: Model in "
"section 2 of Printer MIB (RFC 3805) and section 3 of Finisher "
"MIB (RFC 3806)."),
MappingStrings { "MIB.IETF|Printer-MIB.prtAlertEntry" }]
class CIM_PrintAlertRecord : CIM_LogEntry {

[Override ( "CreationTimeStamp" ), Description (
"The time that this PrintAlertRecord was generated."),
MappingStrings { "MIB.IETF|Printer-MIB.prtAlertTime",
"MIB.IETF|SNMPv2-MIB.sysUpTime",
"MIB.IETF|HOST-RESOURCES-MIB.hrSystemUptime",
"MIB.IETF|HOST-RESOURCES-MIB.hrSystemDate" },
ModelCorrespondence { "CIM_OperatingSystem.LocalDateTime" }]
datetime CreationTimeStamp;

[Override ( "RecordData" ), Description (
"Note: For SNMP Proxy implementations, this property shall "
"contain every integer object defined in the prtAlertEntry "
"row in the Printer MIB v2 (RFC 3805), using a delimiter of "
"semi-colon ';' as 'keyword=value' tuples, where each "
"keyword is the label from the Printer MIB object (e.g., "
"prtAlertIndex) and each value is the decimal string "
"encoding of the original MIB integer value. For example, \n"
"prtAlertIndex=34;...;prtAlertTime=34567; \n"
"Note: The only string object defined in the prtAlertEntry "
"row (prtAlertDescription) shall not be encoded in this "
"RecordData property, but shall instead be transcoded (if "
"necessary) into Unicode and stored in the "
"LocalizedDescription property below."),
MappingStrings { "MIB.IETF|Printer-MIB.prtAlertEntry" }]
string RecordData;

[Description (
"A free-form text description of this alert in the "
"localization specified by "
"CIM_Printer.CurrentNaturalLanguage."),
MinLen ( 0 ), MaxLen ( 255 ),
MappingStrings { "MIB.IETF|Printer-MIB.prtAlertDescription",
"MIB.IETF|Printer-MIB.PrtLocalizedDescriptionStringTC" }]
string LocalizedDescription;

[Description (
"The code name that describes the type of alert. The code "
"name shall be the IANA-registered label for this alert, "
"taken from the PrtAlertCodeTC textual convention in the "
"IANA Printer MIB (originally published in RFC 3805), e.g., "
"'coverOpen' or 'inputMediaSupplyLow'. A binary change alert "
"describes the state of the component, while a unary change "
"alert describes a single event. The same code name can be "
"used for a binary change alert or a unary change alert, "
"depending on implementation. Also, the same code name can "
"be used to indicate a critical or non-critical (warning) "
"alert, depending on implementation. The value of the "
"SeverityLevel property specifies binary versus unary and "
"critical versus non-critical for each alert for this "
"particular Printer implementation."),
MinLen ( 0 ), MaxLen ( 255 ),
MappingStrings { "MIB.IETF|Printer-MIB.prtAlertCode",
"MIB.IETF|IANA-PRINTER-MIB.PrtAlertCodeTC" },
ModelCorrespondence { "CIM_PrintAlertRecord.OtherCodeName",
"CIM_PrintAlertRecord.SeverityLevel" }]
string CodeName;

[Description (
"A free-form string that describes the type of alert when "
"the value of the CodeName property is equal to 'other'."),
MinLen ( 0 ), MaxLen ( 255 ),
ModelCorrespondence { "CIM_PrintAlertRecord.CodeName" }]
string OtherCodeName;

[Description (
"The level of severity of this alert in this Printer "
"implementation as follows: 1 (Other) means a non-standard "
"severity level is present in OtherSeverityLevel property. 2 "
"(Unknown) means severity level is unknown for this alert. 3 "
"(Critical) means that this alert on this component has "
"stopped printing on this Printer. 4 (Warning) means that "
"this alert has not stopped printing on this Printer. 5 "
"(WarningBinaryChangeEvent) means that a previous critical "
"alert condition has been cleared."),
ValueMap { "1", "2", "3", "4", "5", ".." },
Values { "Other", "Unknown", "Critical", "Warning",
"WarningBinaryChangeEvent", "DMTF Reserved" },
MappingStrings { "MIB.IETF|Printer-MIB.prtAlertSeverityLevel",
"MIB.IETF|Printer-MIB.PrtAlertSeverityLevelTC" },
ModelCorrespondence { "CIM_PrintAlertRecord.CodeName" }]
uint32 SeverityLevel;

[Description (
"A free-form string that describes the severity level when "
"the value of the SeverityLevel property is equal to 1 "
"(Other)."),
MinLen ( 0 ), MaxLen ( 255 ),
ModelCorrespondence { "CIM_PrintAlertRecord.SeverityLevel" }]
string OtherSeverityLevel;

[Description (
"The lowest inheritance class name with a schema name of "
"'CIM' (e.g., 'CIM_PrintMarker') of the particular component "
"of a Printer with which this alert is associated. When used "
"with the value of ComponentElementName, this property "
"allows all instances of this component to be uniquely "
"identified. If the component class name is unknown or not "
"applicable, then this property shall be null. Note: This "
"property is necessary (rather than the use of an "
"association class), because this log entry is static and "
"records a past event for offline processing. See: Section 2 "
"of the Printer MIB v2 (RFC 3805) and section 3 of Finisher "
"MIB (RFC 3806). Note: This property is necessary to "
"correlate status and event (alert) information between CIM "
"and SNMP interfaces."),
MinLen ( 0 ), MaxLen ( 255 ),
MappingStrings { "MIB.IETF|Printer-MIB.prtAlertGroup",
"MIB.IETF|IANA-PRINTER-MIB.PrtAlertGroupTC" },
ModelCorrespondence {
"CIM_PrintAlertRecord.ComponentElementName" }]
string ComponentClassName;

[Description (
"The value of the ManagedSystemElement.Name property of the "
"particular component of a Printer with which this alert is "
"associated. When used with the value of ComponentClassName, "
"this property allows all instances of this component to be "
"uniquely identified. If the component element name is "
"unknown or not applicable, then this property shall be "
"null. Note: This property is necessary (rather than the use "
"of an association class), because this log entry is static "
"and records a past event for offline processing. See: "
"Section 2 of the Printer MIB v2 (RFC 3805) and section 3 of "
"Finisher MIB (RFC 3806). Note: This property is necessary "
"to correlate status and event (alert) information between "
"CIM and SNMP interfaces."),
MinLen ( 0 ), MaxLen ( 255 ),
MappingStrings { "MIB.IETF|Printer-MIB.prtAlertGroupIndex" },
ModelCorrespondence { "CIM_ManagedSystemElement.Name",
"CIM_PrintAlertRecord.ComponentClassName" }]
string ComponentElementName;
};


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.