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

[Martin Björklund <[e-mail]>]

Andy Bierman <[e-mail]> wrote:
> On Mon, Dec 5, 2022 at 2:37 PM Jürgen Schönwälder <
> [e-mail]> wrote:
> 
> > On Mon, Dec 05, 2022 at 08:19:12PM +0000, Kent Watsen wrote:
> > >
> > >
> > > Hi Juergen,
> > >
> > >
> > >
> > > >> 3) There are two "time-with-zone-offset" typedefs (one should be
> > "time-without-zone-offset"?)
> > > >
> > > > No, I only see one.
> > >
> > > My bad, I didn't see the subtype.
> > >
> > > But I may've been thrown off by the following "no-zone" types...should
> > they be named consistently?
> > >
> > >    - date-no-zone  -->  date-no-zone-offset  or  date-without-zone-offset
> > >    - time-no-zone  -->  time-no-zone-offset  or  time-without-zone-offset
> >
> > The 'no-zone' indicates no zone information, neither by offset nor by zone
> > name.
> >
> > >
> > > >> 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.
> > >
> > >
> > > "Offsets" are good (regional names would be too involved, IMO)
> >
> > Zone offsets change for certain locations regularly (daylight saving
> > times) and this is why many user facing interfaces configure time zone
> > locations by letting the user select a zone name like Europe/London
> > that then maps via the IANA timezone database rules to the specific
> > zone offsets.
> >
> > > My thought is only to shorten the names.  e.g., time-with-zone-offset
> > --> time-with-offset?  If it doesn't make sense, semantically, then no
> > worries keeping as is.
> >
> > Some what descriptive names, some want names to be future proof,
> > others want names that match names used elsewhere, then some prefer
> > short names, its obviously difficult. Initially we had date (with an
> > optional zone offset) plus date-no-zone without it. This matchedthe
> > good old date-and-time (which also has an optional zone offset).
> >
> > > >> 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.
> > >
> > >
> > > This was discussed at 115, on slide #8 here:
> > https://datatracker.ietf.org/meeting/115/materials/slides-115-netmod-1-session-intro-wg-status-00
> > .
> > >
> > > Lou and I are trying to break the logjam, and no one objected, so it's
> > fine to proceed now.  What I'd do:
> > >
> > >    1) rename the existing definitions to the new name.
> > >    2) recreate the old definitions as having the "type" of the new
> > definitions and "status deprecated".
> > >
> >
> > Consensus is determined on the mailing list, no?
> >
> > I am sorry that I missed decisions taken in London by not reading the
> > slides. So I should also remove the language-tag type I guess.
> >
> > And then I write that ip-address was deprecated because some were
> > confused by the name? Well, if this is how we make progress...
> >
> >
> 
> Deprecating ip-address (and ipv4-address and ipv6-address?) is probably the
> most disruptive
> change to YANG that one could make.  I am not sure there are real
> operational problems
> that warrant this change.

I fully agree.

> 
> A type name cannot be changed.
> A new name can be introduced so there are 2 types that do the same thing.
> IMO this will increase the overall confusion, and not help in any way.

+1


/martin


> 
> Making this worse is the fact that status "deprecated" is incorrectly
> defined in YANG 1.1
> because it means the same as "obsolete".  It also adds to the perception
> that the IETF
> cannot provide stable YANG modules to the world.
> 
> 
> /js
> >
> >
> Andy
> 
> 
> > --
> > Jürgen Schönwälder              Constructor University Bremen gGmbH
> > Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   [phone]         <https://www.jacobs-university.de/>
> >
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
> >