Subject: [netmod] Types document: inclusion of date type

From: David Partain <[email-masked]>
Date: Tue, 28 Jul 2009 16:52:35 +0200

Hi,

A number of people have expressed concerns about including this new type after 
the meeting on Monday (where the rough consensus in the room was to include 
it).  Because of this input, it would be very helpful if proponents of adding 
this type can provide use cases where this type would be useful.  We'll have 
a brief discussion about this tomorrow in the WG meeting.

Cheers,

David

---

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

On Tue, Jul 28, 2009 at 04:52:35PM +0200, David Partain wrote:
 
> A number of people have expressed concerns about including this new
> type after the meeting on Monday (where the rough consensus in the
> room was to include it).  Because of this input, it would be very
> helpful if proponents of adding this type can provide use cases
> where this type would be useful.  We'll have a brief discussion
> about this tomorrow in the WG meeting.

To add some more background from the discussion today:

The use case question came up after investigating XSD compatibility;
the XSD date type allows for an optional time zone qualifier. A date
value without a time zone qualifier actually indicates a time interval
of 48 hours while a date value with a time zone qualifier indicates a
24 hour time interval. Whether the difference matters depends on the
use case (and if there is a time zone, we must not normalize the time
zone away because that changes the 24 hour time interval expressed
with a date value).

The yang types document editor is not sure how to get this seemingly
simple date type right - what I do understand now is that the simple
format YYYY-MM-DD indicates a 48 hours time interval unless we attach
additional rules (e.g. a date value is always in UTC - but that might
be bad for some potential use cases of such a data type since the 24
hour intervals you can represent are somewhat restricted).

/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: Andy Bierman <[email-masked]>
Date: Tue, 28 Jul 2009 08:46:02 -0700

> hour intervals you can represent are somewhat restricted).

It's OK with me to leave out this data type and let it be
defined as needed in vendor or standard data models.

> /js

Andy

---

From: Brent Chapman <[email-masked]>
Date: Tue, 28 Jul 2009 17:49:00 +0200

> a brief discussion about this tomorrow in the WG meeting.

How about SSL certificate management for load balancers, VPN concentrators,
and the like, where particular certificates are valid only before or only
after certain dates?  I suppose that there's a time (midnight?) implicit in
those certificate dates, so perhaps this is a less-than-ideal use case.

-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: Tue, 28 Jul 2009 18:22:43 +0200

On Tue, Jul 28, 2009 at 05:49:00PM +0200, Brent Chapman wrote:
> On Tue, Jul 28, 2009 at 4:52 PM, David Partain <[email-masked]<mailto:[email-masked]>> wrote:
> Hi,
> 
> How about SSL certificate management for load balancers, VPN
> concentrators, and the like, where particular certificates are valid
> only before or only after certain dates?  I suppose that there's a
> time (midnight?) implicit in those certificate dates, so perhaps
> this is a less-than-ideal use case.

Once again, our principle has been to not define types because they
_might_ be useful but to only include types where we are sure they
_are_ useful in a number of YANG modules and where we know how to get
the definition right so that the type works in a reusable way without
surprises. We can add types incrementally - once we understand the
requirements of concrete use cases.

/js