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

[Andy Bierman <andy at netconfcentral.com>]

Juergen Schoenwaelder wrote:
> On Tue, Jun 09, 2009 at 12:27:00PM +0200, Andy Bierman wrote:
>  
> > 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.
>
> 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.

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.


> > 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.

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.


> /js

Andy