On Wed, Dec 7, 2022 at 11:42 PM Jürgen Schönwälder <
j.schoenwael...@jacobs-university.de> wrote:

> On Thu, Dec 08, 2022 at 03:02:39AM +0000, Kent Watsen wrote:
> >
> > We are addressing the current/existing confusion, as discussed in the
> last 9 months and in a virtual interim.  Not doing anything would be truly
> unhelpful.
> >
> > The strategy is to gradually move towards having only explicit names.
>  The first step is to introduce a new explicit name, while deprecating the
> legacy ambiguous name.  This provides time for modules to slowly migrate to
> the new name.  The second step, to be done only after the "versioning" work
> lands, is to remove the legacy deprecated name, while marking the module
> revision as having an NBC change.
> >
>
> 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?
>
> - ...
>
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). And in 2023 we go and deprecate ip-address
> and introduce an identical ip-address-with-zone type and start a
> possible infinite conversion process?
>

+1

I am also concerned about the notion that a YANG designer
(a writer, not just a reader) should be able to pick a data type to use
based entirely on its name, without the need to read any of the typedef
content.

IMO this is a really bad idea because it solves no operational problems
but it does cause lots of unnecessary changes to YANG modules.

YANG supports type aliases:

typedef ip-address-zone {
    type ip-address;
}

1) no deprecation of ip-address
2) absolutely no cut-and-paste reuse



> This all seems to be a bike-shed discussion.
> <https://en.wikipedia.org/wiki/Parkinson%27s_law_of_triviality>
>
> /js
>
>

Andy


> --
> Jürgen Schönwälder              Constructor University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to