On Wed, Apr 13, 2022 at 10:44:33AM +0200, Martin Björklund wrote: > Jürgen Schönwälder <[email protected]> wrote: > > On Tue, Apr 12, 2022 at 04:52:41PM +0200, Martin Björklund wrote: > > > Jürgen Schönwälder <[email protected]> wrote: > > > > > > [...] > > > > > > > For me, the only sensible option (other than accepting that types are > > > > named the way they are) is to introduce ip-address-with-zone and to > > > > deprecate ip-address and stop there. Yes, this means coexistance of > > > > inet:ip-address and ip-address-with-zone until YANG is getting > > > > replaced. > > > > > > But then what would you do with inet:host? > > > > > > > I would define ip-address-with-zone to be the same as ip-address > > (i.e., with an optional zone index) and then I would then use > > ip-address-with-zone instead of ip-address in inet:host (like we are > > all going to replace the deprecated ip-address with either > > ip-address-with-zone or ip-address-no-zone in all modules in the > > future to avoid depending on a deprecated definition). > > But if people believe that we have a big problem that ip-address may > contain a zone index, don't we have the same problem w/ inet:host? > Don't we have to deprecate also inet:host for the same reason?
The problem is with the name of the ip-address type. I assume people might even be happy that a (host, port-number) tupe behaves as many applications around us do. > (To be clear: Personally, I do not think that deprecating these > typedefs is the best solution) > > > It does not make sense to me to have a type mandating a zone since on > > all systems I know of the zone index shows up only when needed (and > > creating yet another union seems overkill). > > Did anyone suggest this? I thought ip-address-with-zone was supposed to be > exactly what ip-address is today. This is how I understood Kent. /js -- 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
