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]

The change request number in the format used by the working group where it is created. Each workgroup shall use a format that ensures uniqueness across the DMTF.

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

Name of the person who owns the change request, and their email address.

Alliance Partner submitting CR request (if applicable)

Name of Alliance Partner (ex.  SNIA) submitting request

Alliance Partner vote history (e.g. SNIA XYZ Approved on 8/12/06)

Details about the approval process/history for this request within requesting organization, including approval date if available.

Alliance Partner identifier/tracking number (if available)

Any available identifiers that could help track down balloting records within submitting organization - organization's internal change request number, resolution number, etc.

Errata   [Yes/No]

Errata are serious errors in a released, final specification.  This can be a document or CIM schema.  Errata change requests MUST not be combined with non-errata content in the same change request.  If an erratum applies to multiple versions of a released specification or schema, they MUST be listed in incorporating change section below.

Short Description

A short description of the change.  In the case of change requests for the CIM schema, this description MAY be used when the change is applied in CVS or in the header of the MOF. The description SHOULD clearly describe the change(s) made and be suitable for inclusion in a “readme” about the changes.

Spec, Document or Model(s) Being Changed   [Device Model]

For specifications, the DSP number of the specification, e.g. DSP004.  If this is a new submission, the name of the specification.  For documents, the name of the document, e.g. CIM Technical Note.  For models, the name of the model, e.g. Device, System, Core, Database, Application, Policy, Support.

Spec, Document or Model Version Incorporating the Change  [V2.9 Final]

The version where the change will appear.  For CIM schemas, changes incorporated into the preliminary CIM release are designated as Vx.x preliminary, e.g. V2.10 preliminary. Changes incorporated into a final CIM release are designated as Vx.x final, e.g. V2.10 final. Changes to final CIM schema versions MUST also be tagged as errata.

Filename(s) Incorporating the Change [Device\CIM_USB.mof]

List the actual file name(s) where the change will be made.

Date Originated  [mm/dd/yyyy]

The date when the change request was originally created by the owner.

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

The date when change request is revised by the owner.

Dependencies   [smwgCR00567,sysdevCR00555]

List any dependencies that the change request requires for implementation (other CRs, specifications, etc.)

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

The purpose of this section is to provide the background information for the reader as well as any additional documentation that is useful for understanding the rationale for the change.  For example:

This CR fills a gap from Name Binding (CR 1348) and other interfaces that change SCSI configurations - a method to ask the host to scan for changes. OS drivers discover connected SCSI devices at boot time and provide interfaces for administrators to ask that the SCSI configuration be re-discovered without rebooting.  This CR adds a new method to expose this capability in CIM, and also updates capabilities to allow a client to determine whether this method is supported.

Alliance Partner Status (tracking number, other key identifiers, supporting documentation, etc.):

SNIA Tracking Number, requesting group and voting information is in the header.  This is expected to be included in the SMI-S spec due out 12/1/2048.

Requested Change (Change information such as details before/after the change, readable/indented MOF, and/or references to "Uploaded" MOF and other documents if the changes are too lengthy to include inline):

In addition, if there are any conditions or constraints, they should be clearly identified in this section.  It is helpful to the mof editors if you color text to be added to the MOF in red and old text to be deleted in the MOF in blue with overstrike.

Add a new method to CIM_StorageConfigurationService.mof:

        [Experimental, Description (          
           "This method requests that the system rescan SCSI devices "
           "for changes in their configuration. If called on a "     
           "general-purpose host, the changes are reflected in the "          
           "list of devices available to applications (for example, "          
           "the UNIX 'device tree'. This method may also be used "          
           "on a storage appliance to force rescanning of attached "          
           "SCSI devices. \n"
           "\n"
           "This operation can be disruptive; optional parameters "
           "allow the caller to limit the scan to a single or set of "
           "SCSI device elements. All parameters are optional; if "
           "parameters other Job are passed in as null, a full scan "
           "is invoked." ),
        ValueMap { "0", "1", "2", "3", "4", "5", "..",
                   "4096", 4097", "4098", "4099", "4100",
                   "..", "32768..65535" },
        Values { "Success", "Not Supported", "Unknown", "Timeout",
           "Failed", "Invalid Parameter", "DMTF Reserved",
           "Invalid connection type", "Invalid Initiator",
           "No matching target found", "No matching LUs found",
           "Prohibited by name binding configuration",
           "Vendor Specific" }]
    uint32 ScsiScan (
          [IN, OUT, Description (
              "Reference to the job (may be null if job completed).")]
       CIM_ConcreteJob REF Job,

Discussion Points (Summary of decisions and discussions of the WG in creating this CR) :

Any additional discussion points for the change request that were discussed in email or during a TC call SHOULD also be captured in this section.

This section MAY include email discussions to close out discussion points, or feedback from a ballot, comments, and content on how the comments were addressed.  Each set of ballot comments SHOULD be separately designated.

For Example,

   Core Ballot Feedback from First Ballot:

    Company:   FRU, Inc.

    Comment:   Please change the name of the method from “StorageScan” to “SCSIScan

    Resolution: Changed

Change History (Mandatory after submission to the TC, May be used by the WGs):

Version

Date 

Short description of changes

.000  

9/02/06  

initial submission

.001

9/25/06

revised to address WG ballot comments

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 Sample Version 2.0.0.e