Hi, First of all, I agree that if we were to design this from scratch, I think we should have a type for just an ip address, and use a second leaf for the zone (or interface).
"Rob Wilton (rwilton)" <[email protected]> wrote: > Hi Martin, > > I have several concerns with this approach: > > (1) I still think that the ip-address type name still ends up being > non-intuitive Agreed. > (especially for zoned IPv4 addresses - I would be > surprised to find that there is any deployment for these at all). Maybe, I have no idea. What I *do* know is that lots of users (probably most users) of YANG modules are not active in the IETF. > I.e., the evidence seems to suggest that when engineers think of IP > addresses, they don't seem to generally think of zoned IP addresses. > I doubt that any fiddling of the type description is going to change > that perception, not least when the definition is different for > OpenConfig and in vendors models and ip-address is widely used in many > published YANG models. > > (2) It means that clients of YANG models using the ip-address type > have no idea whether the server will support zones without either > trying the configuration (which could subsequently become unsupported > in the future) or requiring an out-of-band discussion with the device > vendor. For such as basic type this doesn't seem great. But this is what we have had for 12 years, and from what I know we haven't seen any real issues with this. > (3) For IETF models, does that mean that new models should use > ip-address-no-zone, and that we should change the approx. 200 usages > in 40-50 published RFCs? As mentioned previously, this doesn't seem > pragmatic, or it will take the best part of a decade to happen. > During that time the difference between ip-address , > ip-address-with-zone, and ip-address-no-zone will probably cause even > further confusion due to the ambiguity, and differences in > implementations. No, the pragmatic solution I propose is to only change the description of ip-address (and v4/v6) to match current implementations; i.e., make it clear that an implementation doesn't have to support the optional zone index. Not ideal, but this is what is implemented and it seems to work. /martin > (4) For NMDA models, it means that clients could (but probably never > will) receive zoned ip addresses back from <operational>. Further, if > zoned IP addresses are returned, then they are expected to use > numerical IDs for the zones, which seem to be effectively opaque to > the client (other than uniqueness). Clients seem to have a few > choices: ignore (error?) on zoned IP addresses, ignore the zone (does > that make sense), or have additional code to handle a case that for > 99% of users will probably never happen. My point being that these is > also a cost to keeping support for zones in the base ip-address types. > > Regards, > Rob > > > > > -----Original Message----- > > From: Martin Björklund <[email protected]> > > Sent: 12 April 2022 08:26 > > To: Rob Wilton (rwilton) <[email protected]> > > Cc: [email protected]; [email protected] > > Subject: Re: [netmod] [Lsr] I-D Action: > > draft-ietf-lsr-ospfv3-extended-lsa-yang- > > 10.txt > > > > Hi, > > > > Here's another suggestion. We keep the ip-address pattern as is, but > > document in the description that implementations do not have to > > support the optional zone index. This would essentially document the > > behavior of most current implementations. (This is actually what I > > suggested in the earliest thread on this topic that I could find: > > https://mailarchive.ietf.org/arch/msg/netmod/KjHGtPqm9D4Q- > > fRb2hVsf4sPuCU) > > > > > > > > /martin > > > > > > "Rob Wilton \(rwilton\)" <[email protected]> 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 <[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 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
