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

On Mon, Dec 12, 2022 at 7:11 AM Ladislav Lhotka <ladislav.lhotka@nic.cz>
wrote:

> Andy Bierman <andy@yumaworks.com> writes:
>
> > On Fri, Dec 9, 2022 at 8:29 AM Acee Lindem (acee) <acee@cisco.com>
> 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 <netmod-bounces@ietf.org> on behalf of Andy Bierman <
> >> andy@yumaworks.com>
> >> *Date: *Friday, December 9, 2022 at 11:19 AM
> >> *To: *Kent Watsen <kent+ietf@watsen.net>
> >> *Cc: *"netmod@ietf.org" <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 <kent+ietf@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
>
> --
> Ladislav Lhotka, CZ.NIC
> PGP Key ID: 0xB8F92B08A9F76C67
>