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)" <[email protected]> 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
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
