Subject: Summary of changes in -04 draft of the PCIM

From: [email-masked]
Date: Fri, 10 Mar 2000 12:31:38 -0500

An updated draft (-04) of the PCIM is now available in the
Internet-Drafts repository.  The following changes were made
between the -03 and -04 drafts:

1. Discussion of "declarative" vs. "procedural" updated.

2. General discussion of roles (and their roles in the Policy
   Framework:-) updated.

3. New PolicyRoles property added to PolicyRule.

4. UCS-2 encoding for CIM strings explained more fully.

5. Character set & encoding for CIM class names clarified.

6. Changed encodings for PolicyTimePeriodCondition mask
   properties from strings to octet strings.

7. Clarified encoding of OIDs for ConstraintEncoding and
   ActionEncoding properties.

8. Expanded the names for several of the association classes
   and their reference properties.

9. Updated Acknowledgments section.

10. Updated Security Considerations section.

11. Updated References section.

12. Made various minor editorial fixes.

Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
[email-masked]

---

From: John Schnizlein <[email-masked]>
Date: Mon, 13 Mar 2000 09:25:22 -0500

Am I the only person who sees a problem in that the Policy Framework
draft is proposing a format for time-dates and periods of them that is
incompatible with Standard-track RFC 2445?

I expected that my answers to Bob's questions last month regarding
changing the draft would lead to compatibility. What is the compelling
reason to introduce time format translations for any attempt to
interoperate between Internet-standard scheduling and Policy?

John 

draft-ietf-policy-core-info-model-04.txt
 6.5.1. The Property "TimePeriod"

   This property identifies an overall range of calendar dates and times
   over which a policy rule is valid.  It is formatted as a string
   consisting of a start date and time, then a colon (':'), and followed
   by an end date and time.  The first date indicates the beginning of
   the range, while the second date indicates the end.  Thus, the second
   date and time must be later than the first.  Dates are expressed as
   substrings of the form "yyyymmddhhmmss".  For example:

     19990101080000:19990131120000

RFC 2445:
   The iCalendar format is suitable as an exchange format between
   applications or systems. The format is defined in terms of a MIME
   content type. This will enable the object to be exchanged using
   several transports, including but not limited to SMTP, HTTP, ...

4.3.4 Date
   Example: The following represents July 14, 1997:
     19970714
4.3.5 Date-Time
   For example, the following represents January 19, 1998, at 0700 UTC:
     DTSTART:19980119T070000Z
4.3.9 Period of Time
   Example: The period starting at 18:00:00 UTC, on January 1, 1997 and
   ending at 07:00:00 UTC on January 2, 1997 would be:
     19970101T180000Z/19970102T070000Z

---

From: John Schnizlein <[email-masked]>
Date: Mon, 13 Mar 2000 09:25:22 -0500

John 

RFC 2445:

4.3.4 Date