I basically agree with Acee, and I think that we should do (b):
b) Change the types as suggested and accept that doing so breaks
modules where zone indexes are meaningful.
I appreciate that this is an NBC change, but I believe that this is the most
intuitive definition and is the best choice longer term. I also note that the
base ipv4-address/ipv6-address types in OpenConfig (where they use the OC
copy/version of inet-types and not ietf-inet-types) don't allow a zone to be
specified and assumes the default zone. They have separate types in cases
where a zone is allowed to be specified, i.e., aligned to what (b) proposes.
For modules that are using/wanting zones (if any), then they can migrate to the
new explicit zone type. draft-ietf-netmod-yang-module-versioning, if it keeps
its import "revision-or-derived" extension, would also allow such modules to
indicate the dependency on the updated revision/definition of
ietf-inet-types.yang.
Of course, the description associated with the updated ietf-inet-types.yang
revision should clearly highly the non-backwards-compatible change to the types.
Rob
-----Original Message-----
From: iesg <[email protected]> On Behalf Of Jürgen Schönwälder
Sent: 07 April 2022 08:35
To: Acee Lindem (acee) <[email protected]>
Cc: [email protected]; The IESG <[email protected]>; [email protected]
Subject: Re: [netmod] [Lsr] I-D Action:
draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
Here is roughly what happened:
- RFC 6020 (published ~12 years ago) introduced the ip-address
type. It included an optional zone index part since zone indexes
are necessary in certain situations (e.g., configuring services
listening on link-local addresses or clients connecting to services
listening on link-local addresses).
- RFC 6991 (published ~9 years ago) added the ip-address-no-zone types
since people felt that it is useful to also an ip address type
without the optional zone part for situations where a zone is not
applicable. The name 'ip-address-no-zone' was picked since the name
ip-address was already taken.
I understand that the names resulting from this evolution of the YANG
module confuse people not looking up the type definitions. Let me note
that using a type allowing for an optional zone for a leaf that never
needs a zone is not a fatal error (its like using an int where a short
is sufficient) while using a type not allowing for a zone for a leaf
that may need zones is a fatal error (using a short where an int is
required) requiring an update of the definition of the leaf to fix.
What are our options?
a) Do nothing and accept that types are called as they are.
b) Change the types as suggested and accept that doing so breaks
modules where zone indexes are meaningful.
c) Deprecate the types and create a new module defining new types
so that modules can opt-in to use better names.
d) Deprecate the -no-zone types and move back to have a single
type for IP addresses.
Any other options?
How are we going to pick between them?
/js
On Wed, Apr 06, 2022 at 09:02:23PM +0000, Acee Lindem (acee) wrote:
> Jürgen and netmod WG, +IESG,
>
> It is not just the IETF models that are using the inet:ip-address for the
> standard IPv4/IPv6 addresses without zones. Every vendor’s native models and
> the OpenConfig models use the base types and expect the standard IP address
> notation. If we don’t fix this, it is something that people can point to as
> another example of the IETF being out of touch with reality.
>
> I thought about more, and it might make the backward compatibility easier if
> we just leave the existing ip-address-no-zone, ipv4-address-no-zone, and
> ipv6-address-no-zone types and add *-zone types for the remote possibility
> that someone actually wants to include the zone. In the existing RFC 6991
> BIS document, we could merely remove the zone from the ip-address,
> ipv4-address, and ipv6-address types and classify this as we would any other
> bug fix. While including the zone was the original intent of the base types,
> this is what those of us who work on software products would classify as a
> requirements bug.
>
> Thanks,
> Acee
>
> From: Andy Bierman <[email protected]>
> Date: Tuesday, April 5, 2022 at 3:21 PM
> To: Juergen Schoenwaelder <[email protected]>, Andy
> Bierman <[email protected]>, Acee Lindem <[email protected]>, "[email protected]"
> <[email protected]>, "[email protected]" <[email protected]>
> Subject: Re: [netmod] [Lsr] I-D Action:
> draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
>
>
>
> On Tue, Apr 5, 2022 at 12:02 PM Jürgen Schönwälder
> <[email protected]<mailto:[email protected]>>
> wrote:
> On Tue, Apr 05, 2022 at 10:03:25AM -0700, Andy Bierman wrote:
> > >
> > > The best outcome would be to fix ip-address to not include the zone,
> > > introduce ip-address-zone, and deprecate ip-address-no-zone. My take all
> > > the is that all the existing usages do not require zone and this would be
> > > a
> > > fix as opposed to a change.
> > >
> > >
> > I don't think this will harm our implementations.
> > The type is still string. The pattern will change but that is handled by a
> > library.
> > Whatever pattern is used will get handled the same way.
>
> Either a zone is allowed to be present or it is not, this does make a
> difference, its not a cosmetic change.
>
>
> True. The code will probably accept the pattern then fail trying to use the
> string.
> If the client sends the form with a zone.
>
>
>
>
> > The same problem exists for 'date' and 'date-no-zone' types,
> > but they are not used very much.
>
> Perhaps we should call types a, b, c, and so on - this may force
> people to read the descriptions. ;-)
>
> For some reason, the smarter the person, the less likely they are to
> read any of the documentation before using some software.
> I call it the "it should work the way I would design it" phenomenon :-)
>
> You have to admit that Acee's suggestion is more intuitive than the current
> definitions.
>
> Clearly an NBC change.
> IMO it is more useful to put some YANG extension magic in these specific
> typedefs
> than just bumping a major revision number. This is a great use-case for the
> version DT.
>
> There probably is no solution path where nobody has to change any YANG or any
> code
> and everything still works.
>
>
>
> /js
>
> Andy
>
> --
> Jürgen Schönwälder Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
--
Jürgen Schönwälder Jacobs 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
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
