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

From: "David Lowndes" <[email-masked]>
Date: Mon, 13 Mar 2000 10:42:27 -0000

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

Can I suggest that the example in 6.5.2 The Property "MonthOfYearMask", is
changed from May & August, to something less ambiguous?

Dave Lowndes

---

From: "David Lowndes" <[email-masked]>
Date: Mon, 13 Mar 2000 14:04:10 -0000

All these changes have a common format with a 4-octet length field
specifying the overall length of the attribute value.

I can't envisage there being any future requirement to change the length of
these items, or to evaluate them by some common code that would benefit from
this structure. Therefore it seems superfluous to include the length.

Is there a valid reason for the 4-octet length fields?

Dave Lowndes

---

From: [email-masked]
Date: Mon, 13 Mar 2000 10:50:28 -0500

John,

Let me explain what happened.

Since there has been no suggestion that the current encodings
for these fields don't work, the authors of the draft decided
that their lack of alignment with the RFC 2445 encodings is a
second-order problem.  If the WG as a whole thinks this
alignment is important, we can certainly change the draft.
But so far I haven't heard even one other person second your
motion to make this change.

Regards,
Bob

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

John Schnizlein <[email-masked]>@raleigh.ibm.com on 03/13/2000 09:25:22
AM

Please respond to John Schnizlein <[email-masked]>

Sent by:  [email-masked]

To:   Robert Moore/Raleigh/IBM@IBMUS, [email-masked]
cc:
Subject:  Re: Summary of changes in -04 draft of the PCIM

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: "David Lowndes" <[email-masked]>
Date: Mon, 13 Mar 2000 17:12:55 -0000

While I'm not personally concerned with incompatibility with other
specifications, I did raise an issue last week regarding the interpretation
for times spanning midnight. I feel that this facility gives rise to
something that is counter-intuitive to implement in a user interface - see
the thread "Confusion regarding user interpretations for times spanning
midnight".

If the specification of time periods in the calendar group gives a more
flexible and intuitive interface, then I'd say use it. For example, does it
have the ability to represent something like the first (or last) weekday
(Mon-Fri) of a month? Does it cater more intuitively with times spanning
midnight?

Dave Lowndes

---

From: [email-masked]
Date: Mon, 13 Mar 2000 15:48:09 -0500

OK, how about this?

  0x000000060830 ==> May, November, and December

Regards,
Bob

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

"David Lowndes" <[email-masked]>@raleigh.ibm.com on 03/13/2000
05:42:27 AM

Please respond to "David Lowndes" <[email-masked]>

To:   [email-masked]
cc:
Subject:  RE: Summary of changes in -04 draft of the PCIM

Dave Lowndes

---

From: [email-masked]
Date: Mon, 13 Mar 2000 16:04:51 -0500

David,

There *is* a reason, but people are undoubtedly going to
disagree about whether it's a valid one.

The PCIM draft really represents two slightly different things:

  - a technology-independent model for the IETF
  - a CIM model developed in the DMTF.

For whatever reason (good programming practice, a lack of
imagination, whatever), the DMTF has specified that in CIM,
Octetstrings always start with a four-octet length field.
So in order to faithfully reflect the CIM model, the PCIM
draft says this as well.

But notice that this does *not* constrain technology-specific
realizations of the PCIM to encoding their Octetstrings in
this way.  So when we next rev the Policy Core LDAP Schema.
we'll have the opportunity to decide whether or not to include
the length fields in these specific attributes.  Including
them would presumably simplify implementations that need to
map between LDAP and CIM(*).  But this would be at a cost (as
you point out) of making the attributes carry around some
unnecessary "baggage".

Regards,
Bob

(*) Unlike the IETF model, which serves only as a set of guidelines
    for "real" specifications/implementations such as an LDAP
    schema, the CIM model is actually implementable/implemented.
    Consequently, issues of mapping between the CIM model and,
    say, an LDAP schema must be considered.

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

09:04:10 AM

I can't envisage there being any future requirement to change the length of
these items, or to evaluate them by some common code that would benefit
from this structure. Therefore it seems superfluous to include the length.

Dave Lowndes

---

From: "David Lowndes" <[email-masked]>
Date: Tue, 14 Mar 2000 09:39:04 -0000

Yes, that'll do fine.

Cheers
Dave