Subject: [netmod] Issue 2 - data-and-time canonicalization

From: Mark Ellison <[email-masked]>
Date: Wed, 29 Jul 2009 08:40:14 -0400

Hi,

Regarding UTC time:  There appeared to me an issue regarding the time-zone
location of a device if only UTC date-and-time is deployed.  My comment
earlier today in the NETMOD WG concerned whether operators would be able to
know in which timezone a device resides.

For a configuration that depends on the notion of local time an operator
would be required to know the timezone for the target device in order to
work with the canonical UTC.  In reviewing the date-and-time typedef
contained in draft-ietf-netmod-yang-types-03 it is clear that a zone offset
is part of this typedef definition.

So, the presence of the time offset eliminates my concern regarding the
timezone in which a device resides.

Regarding the canonicalization of the "...Z+02:00" portion of the UTC, I am
in favor.  In other words, I think all servers should respond with a
canonical UTC date-and-time. I also think it would be okay for devices with
only a notion of local time to report a string that omits the 'Z suffix'.

FYI- the issue slide should reference WG email-
http://www.ietf.org/mail-archive/web/netmod/current/msg03200.html (...not
03201...)

Others' thoughts?

Regards,

Mark

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 29 Jul 2009 15:03:00 +0200

On Wed, Jul 29, 2009 at 02:40:14PM +0200, Mark Ellison wrote:
 
> Regarding UTC time: There appeared to me an issue regarding the
> time-zone location of a device if only UTC date-and-time is
> deployed.  My comment earlier today in the NETMOD WG concerned
> whether operators would be able to know in which timezone a device
> resides.

This is a data model issue; there should ideally be a standard core
configuration data model that allows to read and configure the
time-zone. But that is future work...
 
> For a configuration that depends on the notion of local time an
> operator would be required to know the timezone for the target
> device in order to work with the canonical UTC.  In reviewing the
> date-and-time typedef contained in draft-ietf-netmod-yang-types-03
> it is clear that a zone offset is part of this typedef definition.

There is an offset - so I can configure +02:00 but the box will return
the configure value back to me in UTC.

> So, the presence of the time offset eliminates my concern regarding
> the timezone in which a device resides.

See above, this would be a config leaf to be standardized.

> Regarding the canonicalization of the "...Z+02:00" portion of the
> UTC, I am in favor.  In other words, I think all servers should
> respond with a canonical UTC date-and-time. I also think it would be
> okay for devices with only a notion of local time to report a string
> that omits the 'Z suffix'.

May be needed - I will take a look at this.

/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: Phil Shafer <[email-masked]>
Date: Wed, 29 Jul 2009 10:40:34 -0400

>the configure value back to me in UTC.

I thought UTC means the offset returned will always be "+0:00".

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 29 Jul 2009 08:18:13 -0700

> I thought UTC means the offset returned will always be "+0:00".

not every operational problem can or should be solved
with the YANG language.

there needs to be 2 or 3 standards leafs:

   utc-time  (type yang:date-and-time)

   local-time  (type ???, maybe just "HH:MM:SS")

   utc-offset  (type ???, maybe just ('+'|'-')"HH:MM")

Then, authors of time-based-ACLs, or whatever feature, can decide
which version of the current time to use in their YANG statements.

IMO, it would be a bad idea to encode all these objects
with a single (complicated) syntax.  The yang:date-and-time
data type should just be an absolute time-stamp.

>  Phil

Andy

---

From: Mark Ellison <[email-masked]>
Date: Wed, 29 Jul 2009 17:01:30 -0400

>   utc-offset  (type ???, maybe just ('+'|'-')"HH:MM")

I can see something like this to config/initialize the current time on a
device...but alternatively I can see some devices using an NTP server
instead for this information and that would be a different set of config
leaves.

- Mark

---

From: Andy Bierman <[email-masked]>
Date: Wed, 29 Jul 2009 14:48:00 -0700

Mark Ellison wrote:
> On Wed, Jul 29, 2009 at 11:18 AM, Andy Bierman <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> 

These are read-only leafs, but I can see that the config side
would be more complicated.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 30 Jul 2009 20:55:00 +0200

> I thought UTC means the offset returned will always be "+0:00".

Yes.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 30 Jul 2009 21:03:46 +0200

On Wed, Jul 29, 2009 at 11:01:30PM +0200, Mark Ellison wrote:

> I can see something like this to config/initialize the current time
> on a device...but alternatively I can see some devices using an NTP
> server instead for this information and that would be a different
> set of config leaves.

NTP does not tell a device which time zone it is in - how should an
NTP server know. When you unpack a computer, you once have to say
which time zone you are in - there is no way around this.

So there should be a standard object to configure the time zone. And
yes, it would be cool to have standard objects to configure NTP and a
standard operation to set the time (I am saying operation since the
current time clearly is not config data).

We will sooner or later need a core data model - also standard
operations to reboot/shutdown a device would be cool to have as these
are the most basic operations you operationally need.

But we first need to get YANG out of the door and this includes
agreement on the date-and-time canonicalization.

/js

---

From: Mark Ellison <[email-masked]>
Date: Fri, 31 Jul 2009 13:17:28 -0400

> which time zone you are in - there is no way around this.

okay.

> current time clearly is not config data).

okay.

> are the most basic operations you operationally need.

yes, agreed- maybe these actions are best addressed in a new thread?

> agreement on the date-and-time canonicalization.

This thread has helped me gain a better understanding of the date-and-time
canonicalization issue.  The following summarizes my understanding:

There is a date-and-time typedef contained in
draft-ietf-netmod-yang-types-03 that has an /architectural space/
allowing for a offset from UTC.

What is being proposed by NETMOD is a canonicalization of date-and-time
information in rpc exchanges with a NETCONF server to follow the
date-and-time typdef with the additional constraint that the offset is
always Z+00:00 thereby conforming to the notion of UTC.

For a NETCONF client to understand the 'local time' for a NETCONF served
device a need exists for a configuration leaf that contains the timezone or
offset from UTC for the device.

The form of the value for the timezone/utc-offset configuration leaf remains
a subject for further discussion- Andy has made a suggestion:

Standardizing the format of the value for the above NETMOD configuration
leaf will improve the interoperability of NETCONF clients and servers.

-- 
Mark Ellison                           Ellison Software Consulting, Inc.
voice:  +1 (603) 362-9270        38 Salem Road
skype: ellison.software            Atkinson, NH  03811, USA
web:    http://EllisonSoftware.com/