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

[Jürgen Schönwälder <[e-mail]>]

On Mon, Apr 11, 2022 at 01:43:56PM -0400, Joel M. Halpern wrote:
> Do we have reason to believe that no one outside the IETF has used
> ip-address as we published in ways that need a zone?
> 
> It seems to me that the first step in the plan below is reasonable.  But
> changing ip-address itself seems a bad idea.  If one means no-zone, use the
> -no-zone typedef.
>

I agree. What do we gain by breaking things in two years given that
there is no effective way to tell people that they will have a problem
in two years? Even in the IETF, I am not sure whether we are ready to
republish relevant RFCs during this two year window. And since we are
at it, ietf-inet-types also has this definition:

  typedef host {
    type union {
      type inet:ip-address;
      type inet:host-name;
    }
    // ..
  }

This host type is used in other places in combination with a port
number to denote transport endpoints and it should be clear why having
zone indexes in here is necessary to work with link-local transport
endpoints. Sure, we can change this to use inet:ip-address-with-zone,
but it is no unlikely that there are other places we do not have
control over and where a 2 year time window does effectively mean a
big surprise two years later.

Apparently, people do not read the description of types. Why would
they read scheduled deprecation warnings?

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.

/js

-- 
Jürgen Schönwälder              Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>