Subject: Re: [Netconf] [netmod] date-and-time vs. dateTime

From: Andy Bierman <[email-masked]>
Date: Mon, 08 Jun 2009 22:51:25 -0700

Juergen Schoenwaelder wrote:
> On Tue, Jun 09, 2009 at 05:17:48AM +0200, Andy Bierman wrote:
> 
>> I propose that RFC 5277 be "clarified" to indicate
>> that YANG date-and-time encoding rules SHOULD be
>> used instead of XSD dateTime.  The only differences
>> are pathological corner-cases that have no utility
>> in the <create-subscription> operation.
> 
> I think RFC 5277 is a product of the NETCONF WG and thus your message
> should have gone to the NETCONF mailing list and not to the NETMOD
> mailing list.
> 

OK -- another possible solution is to remove (or change)
any YANG data type that is not exactly like its XSD counterpart.
That would affect YANG, not NETCONF.

> /js

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 9 Jun 2009 08:38:43 +0200

> That would affect YANG, not NETCONF.

Is that a serious proposal or just noise?

/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, 09 Jun 2009 03:27:00 -0700

> Is that a serious proposal or just noise?

Quite serious.
The NETCONF WG is writing data models in XSD
and the NETMOD WG is writing YANG as if XSD did not
really exist.

Why do we need 2 sets of almost-compatible data types?

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 9 Jun 2009 12:52:11 +0200

> and the NETMOD WG is writing YANG as if XSD did not

The NETCONF WG is producing a protocol, the NETMOD WG is producing a
data modeling language used to model configuration and state data
manipulated by the NETCONF protocol, NETCONF remote procedure calls,
and NETCONF notifications. So there is a difference, even though the
use of XML for everything makes it hard to see the border.

> Why do we need 2 sets of almost-compatible data types?

This question can't answered in the abstract because you have to pay
attention to the reasons for any differences there are. What concerns
the ietf-yang-types module, I tried to document where the differences
are. Wrt data-and-time, the concensus so far was to follow RFC 3339
(Proposed Standard) in some corner cases instead of XSD. While I
personally do not care much about negative years and what they might
mean, I think the distinction between -00:00 and +00:00 and Z made in
RFC 3339 is actually a very useful one.

If you have further issues with any of the ietf-yang-types data types,
please start separate threads so we can work them out and see what the
concensus is.

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 09 Jun 2009 08:28:22 -0700

> use of XML for everything makes it hard to see the border.

The NETCONF WG is producing content.
In fact, the ONLY standard content for NETCONF
that exists has been done by the NETCONF WG.

    - notification monitoring and create-subscription operation
    - ietf-netconf-state anf get-schema operation
    - partial-lock and partial unlock operations
    - with-defaults parameter extension to some operations

All of these documents have content at the layers that
YANG is intended to cover.

> please start separate threads so we can work them out and see what the

The subject line says date-and-time and that is the issue here.
Remove it, change it, or change ALL of the NETCONF content
that uses dateTime to perfectly align with the YANG language.

I was hoping we were going to avoid the same sort of compartmental
politics that plagued EOS/SMIng.  I guess not.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 9 Jun 2009 17:59:15 +0200

> politics that plagued EOS/SMIng.  I guess not.

YANG started late and some data models were started before and this
explains the situation (and this particularly applies to RFC 5277,
published in July 2008). I do not see compartmental politics - just
the IETF working as it is.

Concerning RFC 5277, I like to quote section 2.2.1:

   Parameters:

      eventTime

         The time the event was generated by the event source.  This
         parameter is of type dateTime and compliant to [RFC3339].
         Implementations must support time zones.

This says eventTime is compliant to RFC3339 and thus I believe it is
actually compliant with date-and-time (but perhaps the WG was not
aware of the corner case differences between XSD dateTime and RFC3339
ietf-yang-types is pointing out).

The more interesting question for me is whether eventTime is part of
the content or part of the protocol. For me, it seems to be more part
of the protocol as it is hardwired to the <notification> message but
I understand that this piece of the design can be debated.

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 09 Jun 2009 09:13:08 -0700

>          Implementations must support time zones.

This text is why I proposed an RFC Errata to fix the problem.
I do not think the NETCONF WG understood the differences
at the time.  However, the XSD clearly uses dateTime as
the data type, not string.

RFC 5277 does not say what to do with startTime and/or stopTime
with negative dateTime. Is -2010-06-09T12:00:00Z before 'now'?
(What were the XSD designers thinking!?!)

So problem solved.  The text you quoted above is correct
and the XSD is wrong, and an RFC Erratta note is needed
for RFC 5277 after all. From now on, all time values
in NETCONF/YANG MUST be date-and-time.

> I understand that this piece of the design can be debated.

eventTime is another problem, but at least it is
read-only and the agent generates only canonical
format, so the differences never show up.

Andy