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

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

On Thu, Apr 07, 2022 at 08:39:01AM +0000, Kent Watsen wrote:
> 
> Juergen et. al. ,
> 
> > 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.
> 
> What’s the value of (d)?  Seems like keeping is better, if only to guide readers towards knowing the base types include zones.  And, besides, any module-designer wishing to restrict zones would then have to create their own “no-zone” types. 
>

I added d) for completeness.
 
> > Any other options?
> 
> e) define new types “*-with-zone”
>  and deprecate existing “ip*-address” types and recast the “*-no-zone” types as derived from the *-with-zone types?  This way it is always a conscious decision. 

Yes, looks like a valid 5th option.

My understanding is that we currently enumerate the options, not their
pros and cons and whether we like them or not.

> > How are we going to pick between them?
> 
> I don’t think Errata works, since 6991 defining the *-no-zone types makes it clear what intended. 

Yes, my understanding is that the type definitions are clear and
unambiguous. The issue is that the names tend to mislead people.

/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/>