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