Hi all,
Thanks for the comments on this thread so far. It would be nice if we are able
to come to some sort of rough consensus to a solution.
I think that there is consensus that the YANG type ip-address (and the v4/v6
versions) are badly named as the prominent default type name has been given to
the unusual variant of including zone information.
Based on the comments on this thread, it also seems likely to me that most of
the usages of ip-address in YANG RFCs is likely to be wrong, and the intention
was that IP addresses without zones was intended. At a rough count, of the
published RFC YANG models at github YangModels/standard/ietf/RFC/ to be:
86 uses of ip-address
68 uses of ipv4-address
66 uses of ipv6-address
1 use of ip-address-no-zone
4 uses of ipv4-address-no-zone
4 uses of ipv6-address-no-zone
These types appear in 49 out of the 141 YANG modules published in RFCs. At a
quick guess/check it looks like these 49 YANG modules may appear in 40-50 RFCs.
As mentioned previously, it is also worth comparing this to the OpenConfig YANG
modules:
They have redefined ip-address (and v4/v6 variants) to exclude zone information
and have defined separate types include zone information.
There are no explicit uses of the "-zoned" variants of OpenConfig IP addresses
in the latest OpenConfig github repository. However, approximately a third of
the IP address types are still to the ietf-inet-types.yang rather than
openconfig-inet-types.yang, so in theory some of those 58 entries could still
intentionally be supporting zoned IP addresses, but I would expect that the
vast majority would not.
I do see some strong benefit if this basic type being defined in the same way
in both IETF and OC YANG, and I believe that the OC folks have got the
definition right.
I see that some are arguing that the zone in the ip-address definition is
effectively optional, and implementations are not really obliged to implement
it. I don't find that argument compelling, at least not with the current
definition of ip-address in RFC 6991. I see a clear difference between a type
defined with an incomplete regex that may allow some invalid values and a type
that is explicitly defined to included additional values in the allowable value
space. Further, I believe that a client just looking at the YANG module could
reasonably expect a server that implements a data node using ip-address would
be expected to support IP zones, where they are meaningful, or otherwise they
should deviate that data node to indicate that they don't conform to the model.
We also need to be realistic as to what implementations will do. They are not
going to start writing code to support zones just because they are in the
model. They will mostly reject IP addresses with zone information. Perhaps
some will deviate the type to ip-address-no-zone, but probably most won't.
The option of respinning approx. 40-50 RFCs to fix this doesn't feel at all
appealing. This would take a significant amount of time/effort and I think
that we will struggle to find folks who are willing to do this. Although
errata could be used to point out the bug, then can't be used to fix it, all
the errata would be "hold for document update" at best. Further, during the
time that it would take us to fix it, it is plausible that more incorrect
usages of ip-address will likely occur (but perhaps could be policed via
scripted checks/warnings).
I still feel the right long-term solution here is to get to a state where the
"ip-address" type means what 99% of people expect it to mean, i.e., excluding
zone information.
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
> -----Original Message-----
> From: netmod <[email protected]> On Behalf Of Randy Presuhn
> Sent: 08 April 2022 18:59
> To: Christian Hopps <[email protected]>
> Cc: [email protected]; [email protected]
> Subject: Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-
> yang-10.txt
>
> Hi -
>
> On 2022-04-08 5:11 AM, Christian Hopps wrote:
> ..
> > Instead, Acee (I'm not sure I'd call him WG B :) is asserting that
> > *nobody* actually wanted the current type, and it has been misused
> > everywhere and all over. The vast majority of implementations in
> > operation probably can't even handle the actual type (Andy's point). So,
> > Acee is just the messenger of bad news here. Please note that the AD in
> > charge of all this agreed with Acee as well.
>
> That's not the impression one gets from modules like
> https://www.ietf.org/archive/id/draft-ietf-mpls-mldp-yang-10.txt
> which employs both types. So, regardless of whether one is willing
> to respect YANG's compatibility rules, it's no longer a matter of
> speculation whether a name change would cause actual damage -
> it clearly would. Furthermore, my recollection is that the
> WG *did* discuss whether the "zonable" property was needed, so
> any argument based on the assertion that "*nobody* actually
> wanted the current type" seems to me to based on a false premise.
>
> Randy
>
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
