Subject: [netmod] data-and-time canonicalization

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 27 Jul 2009 14:05:35 +0200

Hi,

during the WG meeting, the date-and-time canonicalization rules 
came up and it was not clear whether the text forces all canonical
date-and-time values to be in UTC. Here is the relevant text:

  The canonical format for date-and-time values mandates the UTC
  time format with the time-offset is indicated by the letter "Z".
  This is consistent with the canonical format used by the
  dateTime XML schema type.

Since YANG requires to send data in canonical format (section 9.1 of
the YANG document), this essentially means date-and-time values are
pretty much always in UTC when you get them from a device. This is
likely not what operationally is always wanted.

If we allow non UTC time zones, then of course we allow for multiple
different representations for the same value. According to section 9.1
of the YANG document, this is actually allowed. Should date-and-time
make use of this special rule?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Brent Chapman <[email-masked]>
Date: Mon, 27 Jul 2009 14:59:33 +0200

A related issue...  How do I specify times that are in the local timezone,
regardless of date?  And how do I specify day-of-week?
For example, some firewalls enable you to configure rules to block certain
traffic during certain hours of the day, perhaps further limited to certain
days of the week.  For instance, a business might set a firewall rule of
"block all HTTP traffic to www.facebook.com between 8am and 5pm local time,
Monday through Friday", or parents (or someone offering an "Internet for
families" service) might set two firewall rules of the form "block all HTTP
traffic except to www.wikipedia.com by default" (so that the kids can use it
to do their homework) and "allow all HTTP traffic between 6pm and 10pm
weekdays and all day on weekends" (so that the kids can surf the Internet
freely in the evenings and on weekends).

How would the time-of-day and day-of-week aspects of those rules be
expressed in YANG?  Don't forget daylight savings time changes...

-Brent
-- 
Brent Chapman <[email-masked]>
Netomata, Inc. -- www.netomata.com
Making networks more cost-effective, reliable, and flexible by automating
network configuration

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 27 Jul 2009 16:15:04 +0200

On Mon, Jul 27, 2009 at 02:59:33PM +0200, Brent Chapman wrote:

> A related issue...  How do I specify times that are in the local
> timezone, regardless of date?

This is handled by following RFC 3339. In particular, the time-offset
-00:00 indicates an unknown time zone.

> And how do I specify day-of-week?

Not with date-and-time.
 
> For example, some firewalls enable you to configure rules to block
> certain traffic during certain hours of the day, perhaps further
> limited to certain days of the week.  For instance, a business might
> set a firewall rule of "block all HTTP traffic to
> www.facebook.com<http://www.facebook.com> between 8am and 5pm local
> time, Monday through Friday", or parents (or someone offering an
> "Internet for families" service) might set two firewall rules of the
> form "block all HTTP traffic except to
> www.wikipedia.com<http://www.wikipedia.com> by default" (so that the
> kids can use it to do their homework) and "allow all HTTP traffic
> between 6pm and 10pm weekdays and all day on weekends" (so that the
> kids can surf the Internet freely in the evenings and on weekends).
> 

I agree that this will have to be sorted out sooner or later, but I am
not sure it is critical to solve this to get YANG out of the door. The
idea is to add types to the types document over time.

In SNMP land, we have the DISMAN-SCHEDULE-MIB (RFC3231) and this
document uses a collection of objects to do what I think you want.
You want a data type with a single "atomic" representation, likely in
a format that is similar to some cron formats.

While surely interesting, I would not want to hold off the YANG work
for this; I would be in favour adding it once we have a clear use case
and a decent solution proposal.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 28 Jul 2009 10:48:43 +0200

> make use of this special rule?

Let me try to add an example. Currently, the specs say that it is fine
to send 

    2009-07-28T10:40:46+02:00

to a NETCONF server but the server has to return the date as

    2009-07-28T08:40:46Z

and it might be that this behaviour is surprising to some NETCONF
users. On the other hand, this canonicalization makes it easier to
compare the textual representation of values since you do not have to
do time zone delta calculations.

If we change rules, then we might want to require that the server
returns the data in exactly the format it was entered into the
configuration. But this of course requires that implementations
maintain information about the format that was used next to the value
itself and a device may generate date-and-time values in different
leafs that look different but are actualy the same.

Since I am scheduled to discuss this again tomorrow, it would really
help to have some discussion here on the list where the whole WG can
easily participate.

/js

---

From: Phil Shafer <[email-masked]>
Date: Tue, 28 Jul 2009 05:15:29 -0400

Juergen Schoenwaelder writes:
>configuration.

I'm less concerned with maintaining the exact text than I am about
losing timezone information.  Should we keep the canonicalization,
but require the timezone (if any) be kept in the +hh:mm suffix?
(And what about timezones that don't allow +hh:mm (suntime)?)

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 28 Jul 2009 12:24:21 +0200

> but require the timezone (if any) be kept in the +hh:mm suffix?

This is one option. The question then is of course which offset
date-and-time values use that are generated locally. So there probably
needs to be text that says a server should use the local timezone
offset and fall back to UTC if that is available or just unknown
timezone offset if the server really has no clue about timezone
information.

> (And what about timezones that don't allow +hh:mm (suntime)?)

I think this is not really an issue; boxes can change their time
zone. If you have daylight saving time, you essentially change
periodically your timezone offset - in value space that is in 
UTC time nothing really happens.

/js

---

From: David Partain <[email-masked]>
Date: Tue, 28 Jul 2009 17:00:12 +0200

Hi all,

Again, this is an issue that needs to be concluded.  We will conclude this 
discussion tomorrow in the WG meeting if at all possible.  Given the 
following choices:

1. keep UTC as canonical, meaning the server will always  return UTC
2. make the server return whatever it received

I believe from my conversations with several people here this week that we'll 
find that there are more people who will fall on the side of keeping UTC as 
the canonical form.  In the end, we have to choose.

We'll discuss this tomorrow.

Thanks.

David