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

["Acee Lindem (acee)" <[e-mail]>]

Kent, 

On 4/7/22, 4:39 AM, "Kent Watsen" <[e-mail]> 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. 


We already a large number of models that use the existing inet:ip-address types whose implementations don't support the zone. Why should we start using this esoteric "no-zone" types in new models? Note you have RFC 9127 BIS going to through IESG right now... Better to fix it in one place (actually three, since there is ipv4-address, ipv6-address, and ip-address) then in who knows how many since many vendors import ietf-inet-types in their native models. 

Thanks,
Acee

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



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


    Kent (hatless)