Re: [netmod] I-D Action: draft-ietf-netmod-rfc6991-bis-14.txt

[Jürgen Schönwälder <[e-mail]>]

On Mon, Dec 05, 2022 at 01:24:03PM +0000, Kent Watsen wrote:
> Thanks for this update Juergen.  I was just thinking this morning to ping you on it.
> 
> 
> ietf-yang-types:
> 
> 1) The table in the "Overview" section needs to reflect new names (e.g., s/date/date-with-zone-offset/)

Fixed.

> 2) The "revision" statement needs to reflect new names (e.g., s/with-zone/with-zone-offset/)

I think the correct names are listed in the revision statement.

> 3) There are two "time-with-zone-offset" typedefs (one should be "time-without-zone-offset"?)

No, I only see one.

> 4) Is the "-offset" postfix needed?  Or maybe remove the "-zone" part and only have "-offset"?

As noted on a private communication, I looked at what some of the more
modern programming language libraries do. So let me shre this here:

* Python (datetime)

  They distinguish 'aware' and 'naive' dates.

    Date and time objects may be categorized as "aware" or "naive"
    depending on whether or not they include timezone information.
    [...]
    An aware object represents a specific moment in time that is not
    open to interpretation.
    [...]
    For applications requiring aware objects, datetime and time
    objects have an optional time zone information attribute, tzinfo,
    that can be set to an instance of a subclass of the abstract
    tzinfo class. These tzinfo objects capture information about the
    offset from UTC time, the time zone name, and whether daylight
    saving time is in effect.

  Note that there is both a zone offset and a zone name. Note that a
  zone name may resolve to different offsets depending on the timezone
  rules in effect at a given point in time.

* Rust (chrono)

  They also distinguish between aware and naive:

    Chrono is timezone-aware by default, with separate timezone-naive
    types.
    [...]
    DateTime is timezone-aware and must be constructed from the
    TimeZone object, which defines how the local date is converted to
    and back from the UTC date. There are three well-known TimeZone
    implementations [...].

  My reading of their documentation is that their TimeZone object
  essentially resolves to an offset, not a timezone name.

In some contexts, it may be useful to think in terms of
2022-12-05@[Europe/Berlin] rather than 2022-12-05+01:00 (in particular
if you keep daylight saving times in your mind or changes of offsets)
and to be clear that we currently only model offsets, I decided for
the longer and more explicit name date-with-zone-offset (as there was
some push towards longer and more precise type names).

For interested parties, there is also work in the IETF on adding
names to the RFC3339 format:

https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/

They discuss formats like 2022-07-08T00:14:07+01:00[Europe/Paris] and
then go into the details if the name and offset are inconsistent etc.
 
> Ietf-inet-types:
> 
> 1) "*-address-and-prefix" instead of "*-address-with-zone"?

He?

> 2) no deprecation of the legacy "*-address" types?

Since there was no consensus to change (and break) definitions, I
thought we agreed to simply make no changes and to keep what we have.

/js
 
> PS: Diff2 shows nearly everything changed.  Diff1 is correct:
>        https://www.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-netmod-rfc6991-bis-14.txt
> 
> 
> Kent // as Shepherd
> 
> 
> 
> > On Dec 5, 2022, at 6:28 AM, [e-mail] wrote:
> > 
> > 
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > This draft is a work item of the Network Modeling WG of the IETF.
> > 
> >        Title           : Common YANG Data Types
> >        Author          : Jürgen Schönwälder
> >  Filename        : draft-ietf-netmod-rfc6991-bis-14.txt
> >  Pages           : 43
> >  Date            : 2022-12-05
> > 
> > Abstract:
> >   This document defines a collection of common data types to be used
> >   with the YANG data modeling language.  This version of the document
> >   adds several new type definitions and obsoletes RFC 6991.
> > 
> > 
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6991-bis/
> > 
> > There is also an HTML version available at:
> > https://www.ietf.org/archive/id/draft-ietf-netmod-rfc6991-bis-14.html
> > 
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6991-bis-14
> > 
> > 
> > Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
> > 
> > 
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
> 

-- 
Jürgen Schönwälder              Constructor University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>