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

[Andy Bierman]

On Mon, Dec 12, 2022 at 7:11 AM Ladislav Lhotka 
wrote:

> Andy Bierman  writes:
>
> > On Fri, Dec 9, 2022 at 8:29 AM Acee Lindem (acee) 
> wrote:
> >
> >> Top posting to assure everyone reads:
> >>
> >>
> >>
> >> I don’t think I could of come up with a better strategy to guarantee
> that
> >> IETF YANG models aren’t used if I tried. We’ll still specify them in
> IETF
> >> document and they’ll provide a useful reference model for other SDOs and
> >> vendor native models, but no one is going to implement and deploy them.
> >>
> >>
> >>
> >
> > This is already happening. e.g.
> >
> https://github.com/openconfig/public/blob/master/release/models/types/openconfig-inet-types.yang
> >
> > After all the churn and complexity introduced by the "NMDA redo", we
> should
> > be extra careful
> > not to do that again.  SDOs and vendors need a stable foundation on which
> > to build their
> > domain-specific data models.
>
> It is interesting that the same three-phase doom scenario for schema
> languages happens over and over again (it happened e.g. to W3C Schema,
> DSDL, XPath/XQuery):
>
> 1. A small group produces version X, it has some flaws and nobody cares.
>
> 2. The same group produces version Y that becomes quite (or wildly)
> popular;
>the number of stakeholders increases, and new features start to creep
> in.
>
> 3. A much larger group embarks on developing version Z, sometimes they
>even succeed, but the final result is a kitchen sink of features so
>complicated that nobody cares about it again.
>
> For YANG Y = 1.1, and phase 3 is well underway.
>
>
This issue is about unnecessary changes to a critical YANG data type.
There are over 1000 modules using the data type.

Changing the name to something else should be done in the early stages of
development.
Changing a type name after 14 years of use just to "teach people a lesson"
and save them from the "dangers" of a little-used optional feature is not
helpful.


Lada
>
>
Andy


> >
> >
> > Thanks,
> >> Acee
> >>
> >
> >
> > Andy
> >
> >
> >>
> >>
> >> *From: *netmod  on behalf of Andy Bierman <
> >> a...@yumaworks.com>
> >> *Date: *Friday, December 9, 2022 at 11:19 AM
> >> *To: *Kent Watsen 
> >> *Cc: *"netmod@ietf.org" 
> >> *Subject: *Re: [netmod] I-D Action: draft-ietf-netmod-rfc6991-bis-14.txt
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Fri, Dec 9, 2022 at 7:41 AM Kent Watsen 
> wrote:
> >>
> >>
> >>
> >>
> >>
> >> The idea to encode all relevant semantics of a type in a type's name
> >> has far-reaching consequences:
> >>
> >> - Are we going to deprecate counter32 and introduce
> >>   non-zero-based-counter32 because we have also zero-based-counter32?
> >>
> >> - Do we introduce date-and-time-with-optional-zone-offset and
> >>   deprecate date-and-time?
> >>
> >>
> >>
> >> I wish we had guiding principles for such naming decisions or, perhaps,
> it
> >> is a matter of the type's definition.
> >>
> >>
> >>
> >> The current date-and-time is not ambiguous because it asserts that
> either
> >> a 'Z' or an offset is present, making impossible for implementations to
> >> assume a zoneless form.  Whereas the current ip-address is ambiguous
> >> because it silently accepts the "without" form, leading to surprise in
> some
> >> implementations when the expanded form is "unexpectedly" passed.
> >>
> >>
> >>
> >> Having well-defined guidance could prevent future missteps.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> The definition of ip-address (published in 2010) was the right thing
> >> to do since the optional zone index can disambiguate IP addresses in
> >> situations where this is needed. In 2013, we also provided the
> >> ip-address-no-zone definition to be used in situations where there is
> >> never a need to disambiguate IP addresses (e.g., when the zone is
> >> known from the context).
> >>
> >>
> >>
> >>
> >>
> >> Trying to focus just on this proposal, not extrapolate the trend...
> >>
> >>
> >>
> >> For 10 years we have had 2 typedefs for IP addres

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

[Ladislav Lhotka]

Andy Bierman  writes:

> On Fri, Dec 9, 2022 at 8:29 AM Acee Lindem (acee)  wrote:
>
>> Top posting to assure everyone reads:
>>
>>
>>
>> I don’t think I could of come up with a better strategy to guarantee that
>> IETF YANG models aren’t used if I tried. We’ll still specify them in IETF
>> document and they’ll provide a useful reference model for other SDOs and
>> vendor native models, but no one is going to implement and deploy them.
>>
>>
>>
>
> This is already happening. e.g.
> https://github.com/openconfig/public/blob/master/release/models/types/openconfig-inet-types.yang
>
> After all the churn and complexity introduced by the "NMDA redo", we should
> be extra careful
> not to do that again.  SDOs and vendors need a stable foundation on which
> to build their
> domain-specific data models.

It is interesting that the same three-phase doom scenario for schema languages 
happens over and over again (it happened e.g. to W3C Schema, DSDL, 
XPath/XQuery):

1. A small group produces version X, it has some flaws and nobody cares.

2. The same group produces version Y that becomes quite (or wildly) popular;
   the number of stakeholders increases, and new features start to creep in.

3. A much larger group embarks on developing version Z, sometimes they
   even succeed, but the final result is a kitchen sink of features so
   complicated that nobody cares about it again.

For YANG Y = 1.1, and phase 3 is well underway.

Lada

>
>
> Thanks,
>> Acee
>>
>
>
> Andy
>
>
>>
>>
>> *From: *netmod  on behalf of Andy Bierman <
>> a...@yumaworks.com>
>> *Date: *Friday, December 9, 2022 at 11:19 AM
>> *To: *Kent Watsen 
>> *Cc: *"netmod@ietf.org" 
>> *Subject: *Re: [netmod] I-D Action: draft-ietf-netmod-rfc6991-bis-14.txt
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Dec 9, 2022 at 7:41 AM Kent Watsen  wrote:
>>
>>
>>
>>
>>
>> The idea to encode all relevant semantics of a type in a type's name
>> has far-reaching consequences:
>>
>> - Are we going to deprecate counter32 and introduce
>>   non-zero-based-counter32 because we have also zero-based-counter32?
>>
>> - Do we introduce date-and-time-with-optional-zone-offset and
>>   deprecate date-and-time?
>>
>>
>>
>> I wish we had guiding principles for such naming decisions or, perhaps, it
>> is a matter of the type's definition.
>>
>>
>>
>> The current date-and-time is not ambiguous because it asserts that either
>> a 'Z' or an offset is present, making impossible for implementations to
>> assume a zoneless form.  Whereas the current ip-address is ambiguous
>> because it silently accepts the "without" form, leading to surprise in some
>> implementations when the expanded form is "unexpectedly" passed.
>>
>>
>>
>> Having well-defined guidance could prevent future missteps.
>>
>>
>>
>>
>>
>>
>>
>> The definition of ip-address (published in 2010) was the right thing
>> to do since the optional zone index can disambiguate IP addresses in
>> situations where this is needed. In 2013, we also provided the
>> ip-address-no-zone definition to be used in situations where there is
>> never a need to disambiguate IP addresses (e.g., when the zone is
>> known from the context).
>>
>>
>>
>>
>>
>> Trying to focus just on this proposal, not extrapolate the trend...
>>
>>
>>
>> For 10 years we have had 2 typedefs for IP address:
>>
>>
>>
>>   - ip-address
>>
>>   - ip-address-no-zone
>>
>>
>>
>> This should be enough (even without reading the module!) to determine
>>
>> 1 form has a zone, and 1 does not.
>>
>>
>>
>> But nobody reads the YANG module so they didn't know about
>> ip-address-no-zone.
>>
>> So how will they know about ip-address-zone either?
>>
>>
>>
>> Because tooling would flag "ip-address" as deprecated and the description
>> statement would say to use the "with-zone" form?
>>
>>
>>
>>
>>
>> There is no reason to deprecate something to replace it with the exact
>> same semantics, but a different name.
>>
>> The only reason to deprecate something is because it will be removed in
>> the future,
>>
>> Deprecating and obsoleting such a critical data type would be highly
>> disruptive.
>>
>> Many vendors and SDOs may refuse to do it.
>>
&

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

[Kent Watsen]

> Nobody has asked for a 'name' version yet. I just wanted to use this
> example that demonstrate that it is hard to future proof name
> choices.

Fine.  The intended pattern wasn't clear.  Knowing that there is a pattern, 
it's fine to not have a "name" version.  Should the draft capture the intended 
pattern, and/or an explanation for why a "name" version isn't defined?


> (And we also do not distinguish between mandatory and
> optional components, our date-and-time type really should be named
> date-and-time-with-optional-zone-offset.)

True, but good luck with that!  ;)


Kent // co-chair and shepherd

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Kent Watsen]

> On Dec 9, 2022, at 11:27 AM, Jürgen Schönwälder 
>  wrote:
> 
> On Fri, Dec 09, 2022 at 03:41:05PM +, Kent Watsen wrote:
>> 
>> The current date-and-time is not ambiguous because it asserts that either a 
>> 'Z' or an offset is present, making impossible for implementations to assume 
>> a zoneless form.  Whereas the current ip-address is ambiguous because it 
>> silently accepts the "without" form, leading to surprise in some 
>> implementations when the expanded form is "unexpectedly" passed.
>> 
> 
> The value '2022-12-09-01:02:03' is a valid date-and-time value.

Indeed, if it weren't missing a 'T'  ;)


> Where
> in the description of the type does it say that this date and time is
> in UTC?? I believe '2022-12-09-01:02:03' is a date-and-time value
> without a known timezone.

I forgot that the 'Z' wasn't required in such cases.  Disregard.


> And similarly, '::1' is a valid ipv6-address. The problem seems to be
> implementations that do not support '::1%lo' because either the module
> author picked the wrong type or the implementer did not implement the
> type correctly. The ip-address type is _not_ 'ambiguous' nor does it
> 'silently accept' something.

Thanks for the clarification.


K.


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Andy Bierman]

On Fri, Dec 9, 2022 at 8:29 AM Acee Lindem (acee)  wrote:

> Top posting to assure everyone reads:
>
>
>
> I don’t think I could of come up with a better strategy to guarantee that
> IETF YANG models aren’t used if I tried. We’ll still specify them in IETF
> document and they’ll provide a useful reference model for other SDOs and
> vendor native models, but no one is going to implement and deploy them.
>
>
>

This is already happening. e.g.
https://github.com/openconfig/public/blob/master/release/models/types/openconfig-inet-types.yang

After all the churn and complexity introduced by the "NMDA redo", we should
be extra careful
not to do that again.  SDOs and vendors need a stable foundation on which
to build their
domain-specific data models.


Thanks,
> Acee
>


Andy


>
>
> *From: *netmod  on behalf of Andy Bierman <
> a...@yumaworks.com>
> *Date: *Friday, December 9, 2022 at 11:19 AM
> *To: *Kent Watsen 
> *Cc: *"netmod@ietf.org" 
> *Subject: *Re: [netmod] I-D Action: draft-ietf-netmod-rfc6991-bis-14.txt
>
>
>
>
>
>
>
> On Fri, Dec 9, 2022 at 7:41 AM Kent Watsen  wrote:
>
>
>
>
>
> The idea to encode all relevant semantics of a type in a type's name
> has far-reaching consequences:
>
> - Are we going to deprecate counter32 and introduce
>   non-zero-based-counter32 because we have also zero-based-counter32?
>
> - Do we introduce date-and-time-with-optional-zone-offset and
>   deprecate date-and-time?
>
>
>
> I wish we had guiding principles for such naming decisions or, perhaps, it
> is a matter of the type's definition.
>
>
>
> The current date-and-time is not ambiguous because it asserts that either
> a 'Z' or an offset is present, making impossible for implementations to
> assume a zoneless form.  Whereas the current ip-address is ambiguous
> because it silently accepts the "without" form, leading to surprise in some
> implementations when the expanded form is "unexpectedly" passed.
>
>
>
> Having well-defined guidance could prevent future missteps.
>
>
>
>
>
>
>
> The definition of ip-address (published in 2010) was the right thing
> to do since the optional zone index can disambiguate IP addresses in
> situations where this is needed. In 2013, we also provided the
> ip-address-no-zone definition to be used in situations where there is
> never a need to disambiguate IP addresses (e.g., when the zone is
> known from the context).
>
>
>
>
>
> Trying to focus just on this proposal, not extrapolate the trend...
>
>
>
> For 10 years we have had 2 typedefs for IP address:
>
>
>
>   - ip-address
>
>   - ip-address-no-zone
>
>
>
> This should be enough (even without reading the module!) to determine
>
> 1 form has a zone, and 1 does not.
>
>
>
> But nobody reads the YANG module so they didn't know about
> ip-address-no-zone.
>
> So how will they know about ip-address-zone either?
>
>
>
> Because tooling would flag "ip-address" as deprecated and the description
> statement would say to use the "with-zone" form?
>
>
>
>
>
> There is no reason to deprecate something to replace it with the exact
> same semantics, but a different name.
>
> The only reason to deprecate something is because it will be removed in
> the future,
>
> Deprecating and obsoleting such a critical data type would be highly
> disruptive.
>
> Many vendors and SDOs may refuse to do it.
>
>
>
>
>
>
>
> YANG Catalog search shows 1486 modules import the ip-address typedef.
>
> I suspect the number is about twice that.
>
>
>
> So we want to tell the world:
>
>
>
> "You have to stop using ip-address and use this new type instead".
>
>
>
> "Why? What's wrong with it?"
>
>
>
> "Nothing. We decided after 13 years we like this name better."
>
>
>
> A number of issues were raised (misconfigurations, OpenConfig, etc.).
>
>
>
>
>
> What are these operational problems that are caused because of the name
> ip-address?
>
> IMO it would be far worse to take away the most important typedef in YANG.
>
>
>
> We have never heard any issues at all from customers about problems
> implementing ip-address.
>
> As Martin pointed out, the server MUST check for values such as 0.0.0.0
> that are
>
> accepted by the typedef pattern but not the leaf semantics. Checking for a
> zone index
>
> is no different.  The ip-address typedef has been clarified in the draft
> update.  That is sufficient.
>
>
>
>
>
>
>
>
>
>
>
> Kent // contributor
>
>
>
>
>
>
>
> Andy
>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Acee Lindem (acee)]

Top posting to assure everyone reads:

I don’t think I could of come up with a better strategy to guarantee that IETF 
YANG models aren’t used if I tried. We’ll still specify them in IETF document 
and they’ll provide a useful reference model for other SDOs and vendor native 
models, but no one is going to implement and deploy them.

Thanks,
Acee

From: netmod  on behalf of Andy Bierman 

Date: Friday, December 9, 2022 at 11:19 AM
To: Kent Watsen 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6991-bis-14.txt



On Fri, Dec 9, 2022 at 7:41 AM Kent Watsen 
mailto:kent%2bi...@watsen.net>> wrote:



The idea to encode all relevant semantics of a type in a type's name
has far-reaching consequences:

- Are we going to deprecate counter32 and introduce
  non-zero-based-counter32 because we have also zero-based-counter32?

- Do we introduce date-and-time-with-optional-zone-offset and
  deprecate date-and-time?

I wish we had guiding principles for such naming decisions or, perhaps, it is a 
matter of the type's definition.

The current date-and-time is not ambiguous because it asserts that either a 'Z' 
or an offset is present, making impossible for implementations to assume a 
zoneless form.  Whereas the current ip-address is ambiguous because it silently 
accepts the "without" form, leading to surprise in some implementations when 
the expanded form is "unexpectedly" passed.

Having well-defined guidance could prevent future missteps.




The definition of ip-address (published in 2010) was the right thing
to do since the optional zone index can disambiguate IP addresses in
situations where this is needed. In 2013, we also provided the
ip-address-no-zone definition to be used in situations where there is
never a need to disambiguate IP addresses (e.g., when the zone is
known from the context).


Trying to focus just on this proposal, not extrapolate the trend...

For 10 years we have had 2 typedefs for IP address:

  - ip-address
  - ip-address-no-zone

This should be enough (even without reading the module!) to determine
1 form has a zone, and 1 does not.

But nobody reads the YANG module so they didn't know about ip-address-no-zone.
So how will they know about ip-address-zone either?

Because tooling would flag "ip-address" as deprecated and the description 
statement would say to use the "with-zone" form?


There is no reason to deprecate something to replace it with the exact same 
semantics, but a different name.
The only reason to deprecate something is because it will be removed in the 
future,
Deprecating and obsoleting such a critical data type would be highly disruptive.
Many vendors and SDOs may refuse to do it.




YANG Catalog search shows 1486 modules import the ip-address typedef.
I suspect the number is about twice that.

So we want to tell the world:

"You have to stop using ip-address and use this new type instead".

"Why? What's wrong with it?"

"Nothing. We decided after 13 years we like this name better."

A number of issues were raised (misconfigurations, OpenConfig, etc.).


What are these operational problems that are caused because of the name 
ip-address?
IMO it would be far worse to take away the most important typedef in YANG.

We have never heard any issues at all from customers about problems 
implementing ip-address.
As Martin pointed out, the server MUST check for values such as 0.0.0.0 that are
accepted by the typedef pattern but not the leaf semantics. Checking for a zone 
index
is no different.  The ip-address typedef has been clarified in the draft 
update.  That is sufficient.





Kent // contributor



Andy

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Jürgen Schönwälder]

On Fri, Dec 09, 2022 at 03:41:05PM +, Kent Watsen wrote:
> 
> The current date-and-time is not ambiguous because it asserts that either a 
> 'Z' or an offset is present, making impossible for implementations to assume 
> a zoneless form.  Whereas the current ip-address is ambiguous because it 
> silently accepts the "without" form, leading to surprise in some 
> implementations when the expanded form is "unexpectedly" passed.
>

The value '2022-12-09-01:02:03' is a valid date-and-time value. Where
in the description of the type does it say that this date and time is
in UTC?? I believe '2022-12-09-01:02:03' is a date-and-time value
without a known timezone.

And similarly, '::1' is a valid ipv6-address. The problem seems to be
implementations that do not support '::1%lo' because either the module
author picked the wrong type or the implementer did not implement the
type correctly. The ip-address type is _not_ 'ambiguous' nor does it
'silently accept' something.

/js

-- 
Jürgen Schönwälder  Constructor University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Jürgen Schönwälder]

On Fri, Dec 09, 2022 at 04:00:08PM +, Kent Watsen wrote:
> 
> Hi Juergen,
> 
> 
> >> 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.
> 
> I see.  Then there are three variants?
> 
>   foo-no-zone
>   foo-zone-with-zone-offset
>   foo-zone-with-zone-name
> 
> Where "foo" is "date" and "time".  To complete the set, are these two 
> definitions missing?
> 
>   yang:date-with-zone-name   
>   yang:time-with-zone-name

Nobody has asked for a 'name' version yet. I just wanted to use this
example that demonstrate that it is hard to future proof name
choices. (And we also do not distinguish between mandatory and
optional components, our date-and-time type really should be named
date-and-time-with-optional-zone-offset.)

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

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

[Kent Watsen]

Hi Juergen,


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

I see.  Then there are three variants?

foo-no-zone
foo-zone-with-zone-offset
foo-zone-with-zone-name

Where "foo" is "date" and "time".  To complete the set, are these two 
definitions missing?

yang:date-with-zone-name   
yang:time-with-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).

Fine.


 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?

And here we are.  It appears the one side is being vocal, and the other side 
not at all.  I have no appetite to delay this the draft any longer.  Disregard.


> I am sorry that I missed decisions taken in London by not reading 

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

[Kent Watsen]

> The idea to encode all relevant semantics of a type in a type's name
> has far-reaching consequences:
> 
> - Are we going to deprecate counter32 and introduce
>   non-zero-based-counter32 because we have also zero-based-counter32?
> 
> - Do we introduce date-and-time-with-optional-zone-offset and
>   deprecate date-and-time?

I wish we had guiding principles for such naming decisions or, perhaps, it is a 
matter of the type's definition.  

The current date-and-time is not ambiguous because it asserts that either a 'Z' 
or an offset is present, making impossible for implementations to assume a 
zoneless form.  Whereas the current ip-address is ambiguous because it silently 
accepts the "without" form, leading to surprise in some implementations when 
the expanded form is "unexpectedly" passed.

Having well-defined guidance could prevent future missteps.



> The definition of ip-address (published in 2010) was the right thing
> to do since the optional zone index can disambiguate IP addresses in
> situations where this is needed. In 2013, we also provided the
> ip-address-no-zone definition to be used in situations where there is
> never a need to disambiguate IP addresses (e.g., when the zone is
> known from the context).
> 
> 
> Trying to focus just on this proposal, not extrapolate the trend...
> 
> For 10 years we have had 2 typedefs for IP address:
> 
>   - ip-address
>   - ip-address-no-zone
> 
> This should be enough (even without reading the module!) to determine
> 1 form has a zone, and 1 does not.
> 
> But nobody reads the YANG module so they didn't know about ip-address-no-zone.
> So how will they know about ip-address-zone either?

Because tooling would flag "ip-address" as deprecated and the description 
statement would say to use the "with-zone" form?


> YANG Catalog search shows 1486 modules import the ip-address typedef.
> I suspect the number is about twice that.
> 
> So we want to tell the world:
> 
> "You have to stop using ip-address and use this new type instead". 
> 
> "Why? What's wrong with it?"
> 
> "Nothing. We decided after 13 years we like this name better."

A number of issues were raised (misconfigurations, OpenConfig, etc.). 



Kent // contributor








___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Andy Bierman]

On Wed, Dec 7, 2022 at 11:42 PM Jürgen Schönwälder <
j.schoenwael...@jacobs-university.de> wrote:

> On Thu, Dec 08, 2022 at 03:02:39AM +, Kent Watsen wrote:
> >
> > We are addressing the current/existing confusion, as discussed in the
> last 9 months and in a virtual interim.  Not doing anything would be truly
> unhelpful.
> >
> > The strategy is to gradually move towards having only explicit names.
>  The first step is to introduce a new explicit name, while deprecating the
> legacy ambiguous name.  This provides time for modules to slowly migrate to
> the new name.  The second step, to be done only after the "versioning" work
> lands, is to remove the legacy deprecated name, while marking the module
> revision as having an NBC change.
> >
>
> The idea to encode all relevant semantics of a type in a type's name
> has far-reaching consequences:
>
> - Are we going to deprecate counter32 and introduce
>   non-zero-based-counter32 because we have also zero-based-counter32?
>
> - Do we introduce date-and-time-with-optional-zone-offset and
>   deprecate date-and-time?
>
> - ...
>
> The definition of ip-address (published in 2010) was the right thing
> to do since the optional zone index can disambiguate IP addresses in
> situations where this is needed. In 2013, we also provided the
> ip-address-no-zone definition to be used in situations where there is
> never a need to disambiguate IP addresses (e.g., when the zone is
> known from the context).



Trying to focus just on this proposal, not extrapolate the trend...

For 10 years we have had 2 typedefs for IP address:

  - ip-address
  - ip-address-no-zone

This should be enough (even without reading the module!) to determine
1 form has a zone, and 1 does not.

But nobody reads the YANG module so they didn't know about
ip-address-no-zone.
So how will they know about ip-address-zone either?

YANG Catalog search shows 1486 modules import the ip-address typedef.
I suspect the number is about twice that.

So we want to tell the world:

"You have to stop using ip-address and use this new type instead".

"Why? What's wrong with it?"

"Nothing. We decided after 13 years we like this name better."




> And in 2023 we go and deprecate ip-address
> and introduce an identical ip-address-with-zone type and start a
> possible infinite conversion process?
>
> This all seems to be a bike-shed discussion.
> 
>
> /js
>
>

Andy



> --
> Jürgen Schönwälder  Constructor University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[tom petch]

>

From: netmod  on behalf of Acee Lindem (acee) 
Sent: 08 December 2022 10:55

From: netmod  on behalf of Andy Bierman 

Date: Wednesday, December 7, 2022 at 10:48 PM

On Wed, Dec 7, 2022 at 7:02 PM Kent Watsen  wrote:

>> Deprecating ip-address (and ipv4-address and ipv6-address?) is probably the
>> most disruptive
>> change to YANG that one could make.

No, the most disruptive thing would be to do what roughly 1/2 of the WG was 
proposing before, which is to introduce now a non-backwards compatible change 
in the existing definitions, which would immediately break all legacy uses.


>> A type name cannot be changed.

Nothing of the sort is being proposed here.


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

We are addressing the current/existing confusion, as discussed in the last 9 
months and in a virtual interim.  Not doing anything would be truly unhelpful.

The strategy is to gradually move towards having only explicit names.   The 
first step is to introduce a new explicit name, while deprecating the legacy 
ambiguous name.  This provides time for modules to slowly migrate to the new 
name.  The second step, to be done only after the "versioning" work lands, is 
to remove the legacy deprecated name, while marking the module revision as 
having an NBC change.

IMO there is no operational problem to fix.
It is too late to change the names of the IP addresses with zones.
It is not a real problem because the server is still responsible for
accepting or sending the zone index (just like address 0.0.0.0).

For data types where the zone is never supposed to be allowed may need to
change to the no-zone variant.

Redoing all YANG modules that use the (proposed) deprecated ip-address
to some other type name is very disruptive and not needed.

I agree – this is the “cut the baby in half” option.



The wisdom of Solomon.

With hindsight we could have done better but we are where we are and I do not 
see reports of problems arising because a module writer did not read the 
specification before assuming he knew what was meant.
The idea of making an identifier carry the semantics of an identity is not just 
one of my pet hates but an approach that leads to mistakes.  (Happily most YANG 
Doctors appreciate this so we rarely end up with XPath such as
/link/link-interface/link-interface-msd/link-interface-msd-erd etc )

On the other hand I was just looking at the IANA registries for LSR and trying 
to find which one contains a more detailed  set of TLV - the choice of 
identifiers has grown with time and does not make it easy.

Tom Petch
Acee


Andy

Between the two steps is when there may be confusion but even then, not really, 
if tooling properly warns about deprecated nodes.


Kent // contributor


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Acee Lindem (acee)]

From: netmod  on behalf of Andy Bierman 

Date: Wednesday, December 7, 2022 at 10:48 PM
To: Kent Watsen 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6991-bis-14.txt



On Wed, Dec 7, 2022 at 7:02 PM Kent Watsen 
mailto:kent%2bi...@watsen.net>> wrote:

>> Deprecating ip-address (and ipv4-address and ipv6-address?) is probably the
>> most disruptive
>> change to YANG that one could make.

No, the most disruptive thing would be to do what roughly 1/2 of the WG was 
proposing before, which is to introduce now a non-backwards compatible change 
in the existing definitions, which would immediately break all legacy uses.


>> A type name cannot be changed.

Nothing of the sort is being proposed here.


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

We are addressing the current/existing confusion, as discussed in the last 9 
months and in a virtual interim.  Not doing anything would be truly unhelpful.

The strategy is to gradually move towards having only explicit names.   The 
first step is to introduce a new explicit name, while deprecating the legacy 
ambiguous name.  This provides time for modules to slowly migrate to the new 
name.  The second step, to be done only after the "versioning" work lands, is 
to remove the legacy deprecated name, while marking the module revision as 
having an NBC change.

IMO there is no operational problem to fix.
It is too late to change the names of the IP addresses with zones.
It is not a real problem because the server is still responsible for
accepting or sending the zone index (just like address 0.0.0.0).

For data types where the zone is never supposed to be allowed may need to
change to the no-zone variant.

Redoing all YANG modules that use the (proposed) deprecated ip-address
to some other type name is very disruptive and not needed.

I agree – this is the “cut the baby in half” option.

Acee


Andy

Between the two steps is when there may be confusion but even then, not really, 
if tooling properly warns about deprecated nodes.


Kent // contributor

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Andy Bierman]

On Wed, Dec 7, 2022 at 11:42 PM Jürgen Schönwälder <
j.schoenwael...@jacobs-university.de> wrote:

> On Thu, Dec 08, 2022 at 03:02:39AM +, Kent Watsen wrote:
> >
> > We are addressing the current/existing confusion, as discussed in the
> last 9 months and in a virtual interim.  Not doing anything would be truly
> unhelpful.
> >
> > The strategy is to gradually move towards having only explicit names.
>  The first step is to introduce a new explicit name, while deprecating the
> legacy ambiguous name.  This provides time for modules to slowly migrate to
> the new name.  The second step, to be done only after the "versioning" work
> lands, is to remove the legacy deprecated name, while marking the module
> revision as having an NBC change.
> >
>
> The idea to encode all relevant semantics of a type in a type's name
> has far-reaching consequences:
>
> - Are we going to deprecate counter32 and introduce
>   non-zero-based-counter32 because we have also zero-based-counter32?
>
> - Do we introduce date-and-time-with-optional-zone-offset and
>   deprecate date-and-time?
>
> - ...
>
The definition of ip-address (published in 2010) was the right thing
> to do since the optional zone index can disambiguate IP addresses in
> situations where this is needed. In 2013, we also provided the
> ip-address-no-zone definition to be used in situations where there is
> never a need to disambiguate IP addresses (e.g., when the zone is
> known from the context). And in 2023 we go and deprecate ip-address
> and introduce an identical ip-address-with-zone type and start a
> possible infinite conversion process?
>

+1

I am also concerned about the notion that a YANG designer
(a writer, not just a reader) should be able to pick a data type to use
based entirely on its name, without the need to read any of the typedef
content.

IMO this is a really bad idea because it solves no operational problems
but it does cause lots of unnecessary changes to YANG modules.

YANG supports type aliases:

typedef ip-address-zone {
type ip-address;
}

1) no deprecation of ip-address
2) absolutely no cut-and-paste reuse



> This all seems to be a bike-shed discussion.
> 
>
> /js
>
>

Andy


> --
> Jürgen Schönwälder  Constructor University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Jürgen Schönwälder]

On Thu, Dec 08, 2022 at 03:02:39AM +, Kent Watsen wrote:
> 
> We are addressing the current/existing confusion, as discussed in the last 9 
> months and in a virtual interim.  Not doing anything would be truly unhelpful.
>
> The strategy is to gradually move towards having only explicit names.   The 
> first step is to introduce a new explicit name, while deprecating the legacy 
> ambiguous name.  This provides time for modules to slowly migrate to the new 
> name.  The second step, to be done only after the "versioning" work lands, is 
> to remove the legacy deprecated name, while marking the module revision as 
> having an NBC change.  
>

The idea to encode all relevant semantics of a type in a type's name
has far-reaching consequences:

- Are we going to deprecate counter32 and introduce
  non-zero-based-counter32 because we have also zero-based-counter32?

- Do we introduce date-and-time-with-optional-zone-offset and
  deprecate date-and-time?

- ...

The definition of ip-address (published in 2010) was the right thing
to do since the optional zone index can disambiguate IP addresses in
situations where this is needed. In 2013, we also provided the
ip-address-no-zone definition to be used in situations where there is
never a need to disambiguate IP addresses (e.g., when the zone is
known from the context). And in 2023 we go and deprecate ip-address
and introduce an identical ip-address-with-zone type and start a
possible infinite conversion process?

This all seems to be a bike-shed discussion.


/js

-- 
Jürgen Schönwälder  Constructor University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Andy Bierman]

On Wed, Dec 7, 2022 at 7:02 PM Kent Watsen  wrote:

>
> >> Deprecating ip-address (and ipv4-address and ipv6-address?) is probably
> the
> >> most disruptive
> >> change to YANG that one could make.
>
> No, the most disruptive thing would be to do what roughly 1/2 of the WG
> was proposing before, which is to introduce now a non-backwards compatible
> change in the existing definitions, which would immediately break all
> legacy uses.
>
>
> >> A type name cannot be changed.
>
> Nothing of the sort is being proposed here.
>
>
> >> 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.
>
> We are addressing the current/existing confusion, as discussed in the last
> 9 months and in a virtual interim.  Not doing anything would be truly
> unhelpful.
>
> The strategy is to gradually move towards having only explicit names.
>  The first step is to introduce a new explicit name, while deprecating the
> legacy ambiguous name.  This provides time for modules to slowly migrate to
> the new name.  The second step, to be done only after the "versioning" work
> lands, is to remove the legacy deprecated name, while marking the module
> revision as having an NBC change.
>
>
IMO there is no operational problem to fix.
It is too late to change the names of the IP addresses with zones.
It is not a real problem because the server is still responsible for
accepting or sending the zone index (just like address 0.0.0.0).

For data types where the zone is never supposed to be allowed may need to
change to the no-zone variant.

Redoing all YANG modules that use the (proposed) deprecated ip-address
to some other type name is very disruptive and not needed.


Andy

Between the two steps is when there may be confusion but even then, not
> really, if tooling properly warns about deprecated nodes.
>
>
> Kent // contributor
>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Kent Watsen]

>> Deprecating ip-address (and ipv4-address and ipv6-address?) is probably the
>> most disruptive
>> change to YANG that one could make.  

No, the most disruptive thing would be to do what roughly 1/2 of the WG was 
proposing before, which is to introduce now a non-backwards compatible change 
in the existing definitions, which would immediately break all legacy uses.


>> A type name cannot be changed.

Nothing of the sort is being proposed here.


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

We are addressing the current/existing confusion, as discussed in the last 9 
months and in a virtual interim.  Not doing anything would be truly unhelpful.

The strategy is to gradually move towards having only explicit names.   The 
first step is to introduce a new explicit name, while deprecating the legacy 
ambiguous name.  This provides time for modules to slowly migrate to the new 
name.  The second step, to be done only after the "versioning" work lands, is 
to remove the legacy deprecated name, while marking the module revision as 
having an NBC change.  

Between the two steps is when there may be confusion but even then, not really, 
if tooling properly warns about deprecated nodes. 


Kent // contributor


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Martin Björklund]

Andy Bierman  wrote:
> On Mon, Dec 5, 2022 at 2:37 PM Jürgen Schönwälder <
> j.schoenwael...@jacobs-university.de> wrote:
> 
> > On Mon, Dec 05, 2022 at 08:19:12PM +, 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:
> > >
> > >  

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

[Andy Bierman]

On Mon, Dec 5, 2022 at 2:37 PM Jürgen Schönwälder <
j.schoenwael...@jacobs-university.de> wrote:

> On Mon, Dec 05, 2022 at 08:19:12PM +, 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 

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

[Jürgen Schönwälder]

On Mon, Dec 05, 2022 at 08:19:12PM +, 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...

/js

-- 
Jürgen Schönwälder

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

[Kent Watsen]

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



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

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.




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



K.



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Jürgen Schönwälder]

On Mon, Dec 05, 2022 at 01:24:03PM +, 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=draft-ietf-netmod-rfc6991-bis-14.txt
> 
> 
> Kent // as Shepherd
> 
> 
> 
> > On Dec 5, 2022, at 6:28 AM, internet-dra...@ietf.org 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
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 

-- 
Jürgen Schönwälder  Constructor University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod 

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

[Kent Watsen]

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/)
2) The "revision" statement needs to reflect new names (e.g., 
s/with-zone/with-zone-offset/)
3) There are two "time-with-zone-offset" typedefs (one should be 
"time-without-zone-offset"?)
4) Is the "-offset" postfix needed?  Or maybe remove the "-zone" part and only 
have "-offset"?


Ietf-inet-types:

1) "*-address-and-prefix" instead of "*-address-with-zone"?
2) no deprecation of the legacy "*-address" types?


PS: Diff2 shows nearly everything changed.  Diff1 is correct:
   
https://www.ietf.org/rfcdiff?difftype=--hwdiff=draft-ietf-netmod-rfc6991-bis-14.txt


Kent // as Shepherd



> On Dec 5, 2022, at 6:28 AM, internet-dra...@ietf.org 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
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[internet-drafts]

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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod