On Mon, Dec 12, 2022 at 7:11 AM Ladislav Lhotka <[email protected]> wrote:
> Andy Bierman <[email protected]> writes: > > > 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. > > 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 <[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 > > -- > Ladislav Lhotka, CZ.NIC > PGP Key ID: 0xB8F92B08A9F76C67 >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
