Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Martin Björklund <[e-mail]>]

Jürgen Schönwälder <[e-mail]> wrote:
> On Tue, Apr 12, 2022 at 04:52:41PM +0200, Martin Björklund wrote:
> > Jürgen Schönwälder <[e-mail]> 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?

(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.



/martin


> 
> /js
> 
> PS: I guess someone will propose to use ip-address-opt-zone instead
>     ip-address-with-zone. ;-)
> 
> -- 
> Jürgen Schönwälder              Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>