Subject: RE: time period syntax: draft-ietf-policy-core-info-model-03.txt

From: [email-masked]
Date: Wed, 9 Feb 2000 13:51:28 -0500

John,

After poking around in RFC 2445 a little, I can sort of see the
appeal of using its format for time intervals, but I also have
quite a few questions that we'd have to answer.

1. First, my take is that RFC 2445's basic format for a time
   interval is neither better nor worse than ours -- just different:

   Interval: January 1, 1999, 0800 through January 31, 1999, noon

   PCIM:
      19990101080000:19990131120000
    RFC 2445:
       19990101T080000/19990131T120000

2. The PCIM has three "special" formats for a time interval:  omit
   the end time, omit the start time, and omit both.  Are you
   suggesting that we get rid of these (I think they have value),
   or that we tweak the RFC 2445 format to allow them.  Of course
   once it's been tweaked, then it's not the RFC 2445 format any
   more, so what have we gained?

3. As I read RFC 2445, the only way to do an offset from UTC is to
   embed it in each of the time strings.  Since the PCIM needs to
   apply a UTC offset to the mask properties as well as to the
   time interval, we represent the UTC offset for the whole
   PTP Condition object in a separate property.  Once again, we
   need to understand exactly how you're proposing for us to
   handle the offsets.

4. What task(s) would we simplify if we switched to the RFC 2445
   format for time intervals?  Asking it another way, where are
   implementations of RFC 2445 deployed (or going to be deployed),
   and for what purpose?  In support of the existing PCIM format,
   I can certainly envision cases where Policy Monitoring might
   need to be turned on/off via the Schedule MIB, at the same
   times that a Policy Rule became active/inactive.  So there
   might be value in sharing a common time format between these
   two activities.

Until we have answers to these questions, I'm planning to leave
the encoding for time intervals unchanged in the PCIM.

Thanks.

Regards,
Bob

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

---

From: John Schnizlein <[email-masked]>
Date: Wed, 09 Feb 2000 15:46:50 -0500

Bob,
answers embedded:

>   interval is neither better nor worse than ours -- just different:

Different from an existing Internet Standard is bad.
RFC 1598 says this:
   3.2 If there are several ways of doing the same thing, choose one.
   If a previous design, in the Internet context or elsewhere, has
   successfully solved the same problem, choose the same solution unless
   there is a good technical reason not to. 

>   more, so what have we gained?

I dislike formats that imply "special" meaning to omitted items.
The THISANDPRIOR and THISANDFUTURE values for time in a range in 
section 4.2.13 of RFC 2445 seem to cover the same territory without
attributing meaning to empty fields.

The [from now] semantics in the draft implies an interpretation
when "now" is that is at least problematic for a distributed policy
system. 

>   need to understand exactly how you're proposing for us to

I see no problem defining the time zone for local time in a separate
property. Section 4.3.5 of RFC 2445 specifies local time as follows:
   The date with local time form is simply a date-time value that does
   not contain the UTC designator nor does it reference a time zone. For
   example, the following represents Janurary 18, 1998, at 11 PM:

     DTSTART:19980118T230000

   Date-time values of this type are said to be "floating" and are not
   bound to any time zone in particular. 

>   and for what purpose?

Since RFC 2445 is Standards Track, it is reasonable to expect its
deployment even if I cannot describe (or predict) its deployment.

>                    In support of the existing PCIM format,

Since RFC 2591 (Schedule MIB) does not specify a time format, it
is reasonable for applications using it to use the format specified
in RFC 2445 (or NTP). The need for another format is not clear.

>the encoding for time intervals unchanged in the PCIM.

I hope these answers are sufficient.
Changing the draft can avoid creating conflict between it and
the Standards Track RFC. What is the reason not to change it?
Is there some other standard or tradition the proposed format follows?

>Thanks.

You are welcome.

John