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

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.

Lada

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