Hi Rob, Thanks for the thoughtful proposal, and I support it.
One thing to confirm, for models that may become RFCs in the next two years and where the IP address doesn’t support zones, "ip-address” should still be used. Correct? Thanks, Yingzhen > On Apr 11, 2022, at 10:06 AM, Rob Wilton (rwilton) > <rwilton=40cisco....@dmarc.ietf.org> wrote: > > 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 <netmod-boun...@ietf.org <mailto:netmod-boun...@ietf.org>> On >> Behalf Of Randy Presuhn >> Sent: 08 April 2022 18:59 >> To: Christian Hopps <cho...@chopps.org <mailto:cho...@chopps.org>> >> Cc: l...@ietf.org <mailto:l...@ietf.org>; netmod@ietf.org >> <mailto:netmod@ietf.org> >> 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 >> netmod@ietf.org <mailto:netmod@ietf.org> >> https://www.ietf.org/mailman/listinfo/netmod >> <https://www.ietf.org/mailman/listinfo/netmod> > > _______________________________________________ > Lsr mailing list > l...@ietf.org <mailto:l...@ietf.org> > https://www.ietf.org/mailman/listinfo/lsr > <https://www.ietf.org/mailman/listinfo/lsr>
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
