DMTF Change Request

DMTF Confidential

All changes to be submitted by the Working Group Chair (or designee) after approval by the working group.    

Terminology

The key phrases and words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY and OPTIONAL in this document are to be interpreted as described in RFC 2119.

"Key words for use in RFCs to Indicate Requirement Levels", IETF RFC 2119, March 1997 (http://www.ietf.org/rfc/rfc2119.txt)

Background/Rationale

This CR addresses the need to normatively define a value meaning Unknown for the MessageTimestamp Key property of the LogRecord class.  The need for a way to represent that a message timestamp is unknown for an instance of LogRecord has developed as a result of trying to represent hardware logs that have non-timestamped entries with the LogRecord class.  Since the Message Timestamp property is a Key property for the LogRecord class, the usual method of interpreting Null to mean Unknown cannot be used.  As there is concern that defining an “Unknown” value for the datetime data type is not the appropriate resolution, this CR attempts to resolve the situation in a “lesser of evils” fashion by placing the definition of a value for “Unknown” in the description of the specific Key property where this issue arises.

The request for this CR came specifically from the May 11, 2005 Architecture WG con call and is the result of a long running discussion about the acknowledged problem with the MessageTimestamp property design in the LogRecord class.  The resolution proposed in this CR is meant to be a fix for CIM 2.11+ and the intention is to resolve the class design problem in a more appropriate fashion in CIM 3.0.

Requested Change

In the System_Logs.mof:

Change the Description of the MessageTimestamp property in the CIM_LogRecord class to include a valid value definition for an unknown time stamp that is highly unlikely to be generated naturally:

Original:

      [Key, Description (

          "A LogRecord's key structure includes a timestamp for the "

          "entry.")]

   datetime MessageTimestamp;

Modified:

      [Key, Description (

          "A LogRecord's key structure includes a timestamp for the "

          "entry.  If the timestamp for the entry is unknown, the "

          "value 99990101000000.000000+000 SHOULD be used.")]

   datetime MessageTimestamp;        

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

EMC:

Will the RecordID property be a key by itself? What happens if there are other Unknown timestamp entries with the same RecordID?

- Response:  RecordID is already a KEY in the LogRecord class.  Multple unknown timestamped records would require unique RecordIDs.
Where does an entry with this timestamp go when sorted? Is there an assumption that a Log has an implicit ordering because it is implemented by appending to a stream?
- Response:  Unknown timestamped records would go to the end of the sort if the sort was solely by Timestamp.  No assumption of implicit ordering, but the implementation can order all log entries by RecordID if desired.
If these questions can be answered reasonably, I would vote 'yes'.

- Response:  According to discussion and emails, these responses were adequate.

Please also add this value to Arch-56 as explicit value to be used for "Unknown" DateTime.

- Response: Arch-56 already describes this case and the Arch WG currently is declining to add this value to the special values defined.

Intel:

Why is the Unknown value not 00000000000000.000000+000 (instead of 00000101000000.555555+720 as proposed). All zeros are more intuitive.
- Response: It turns out that values before the year 1601 are not valid in the WMI CIMOM implementation.  Therefore a value of Midnite Jan 1, 9999 has been chosen.
Also, could you also use Unknown value qualifier (in addition to putting it in description).

- Response:  This was discussed in CIM Core and it was decided that this was not the right situation to use the qualifier.

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

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)