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

[Christian Hopps <[e-mail]>]

Nice. I think this a fine way forward with or without step 2. I say leave out the 2 years (or any) deadline, and let people argue over how and when to do step 2 for however long it takes.

Given the questions already raised on this thread, we should probably add explicit guidance to RFC6991-bis for new modules.

All new modules should:

   - Use `X` in place of `X-no-zone`
   - Use `X-zone` in place of `X` if zone info wanted
   - In the module description indicate that `{ip,ipv4,ipv6}-address` use conforms to the guidance in RFC (6991-bis)

Thanks,
Chris.

"Rob Wilton (rwilton)" <rwilton=[e-mail]> writes:

> Hi all,

....

> Given the pushback on making a single non-backwards compatible change to the new definition, I want to ask whether the following might be a possible path that gains wider consensus:
>
> (1) In RFC 6991 bis, I propose that we:
> (i) define new ip-address-with-zone types (and v4 and v6 versions) and keep the -no-zone versions.
> (ii) we change the description of "ip-address" to indicate:
> - Although the type allows for zone information, many implementations are
> unlikely to accept zone information in most scenarios (i.e., so the description
> of the type more accurately reflects reality).
> - A new ip-address-with-zone type has been introduced to use where zoned IP
> addresses are required/useful, and models that use ip-address with the intention
> of supporting zoned IP addresses MUST migrate to ip-address-with-zone.
> - In the future (at least 2 years after RFC 6991 bis is published), the expectation is that the definition of ip-address will change to match that of ip-address-no-zone.
>
> (2) Then in 2 years time, we publish RFC 6991-bis-bis to change the definition of ip-address to match ip-address-no-zone and deprecate the "-no-zone" version at the same time.
>
> My reasoning as to why to take this path is:
> (1) It is a phased migration, nothing breaks, 3rd parties have time to migrate.
> (2) It ends up with the right definition (with the added bonus that it aligns to the OC definition).
> (3) It doesn't require us republishing 40+ RFCs.
> (4) it hopefully allows us to use YANG versioning to flag this as an NBC change,
> along with the other standards to help mitigate this change (import
> revision-or-derived, YANG packages, schema comparison).
>
> I would be keen to hear thoughts on whether this could be a workable consensus solution - i.e., specifically, you would be able to live with it.
>
> Regards,
> Rob