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

[Andy Bierman <[e-mail]>]

On Fri, Dec 9, 2022 at 8:29 AM Acee Lindem (acee) <[e-mail]> 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 <[e-mail]> on behalf of Andy Bierman <
> [e-mail]>
> *Date: *Friday, December 9, 2022 at 11:19 AM
> *To: *Kent Watsen <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>
> *Subject: *Re: [netmod] I-D Action: draft-ietf-netmod-rfc6991-bis-14.txt
>
>
>
>
>
>
>
> On Fri, Dec 9, 2022 at 7:41 AM Kent Watsen <[e-mail]> 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
>
>
>