Jürgen - I'm not sure how you could extrapolate the basic requirement for IPv6 link-local addresses to support for YANG configuration support of link-local addresses with zone indexes...
Acee On 4/12/22, 11:06 AM, "Jürgen Schönwälder" <[email protected]> wrote: Acee, if you believe link local addresses do not exist or do not need to be supported, then you may want to bring the news to other WGs. /js On Tue, Apr 12, 2022 at 02:54:16PM +0000, Acee Lindem (acee) wrote: > That was a hypothetical example based on IPv6 Link Local addresses - not one anyone has implemented or deployed. > Thanks, > Acee > > On 4/12/22, 10:47 AM, "Joel M. Halpern" <[email protected]> wrote: > > Juergen posted an example of where ip-address is used and zones are > expected. > > Yours, > Joel > > On 4/12/2022 9:24 AM, Acee Lindem (acee) wrote: > > Joel, > > > > There are plenty of examples of where the ip-address types are used and a zone is not accepted. Show me the examples where it is expected? I do have reason to believe there aren't any significant usages of the ip-address types where zone is accepted. Show me the models!!!! > > > > Acee > > > > On 4/11/22, 1:44 PM, "Lsr on behalf of Joel M. Halpern" <[email protected] on behalf of [email protected]> wrote: > > > > Do we have reason to believe that no one outside the IETF has used > > ip-address as we published in ways that need a zone? > > > > It seems to me that the first step in the plan below is reasonable. But > > changing ip-address itself seems a bad idea. If one means no-zone, use > > the -no-zone typedef. > > > > Yours, > > Joel > > > > On 4/11/2022 1:28 PM, Andy Bierman wrote: > > > > > > > > > On Mon, Apr 11, 2022 at 10:07 AM Rob Wilton (rwilton) > > > <[email protected] <mailto:[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. > > > > > > > > > > > > This is a very thoughtful proposal. Looks good to me. > > > > > > It does introduce a window in which some new modules might start using > > > 'ip-address-no-zone'. > > > Should they wait for the real 'ip-address' in 2 more years or just use > > > 'ip-address-no-zone'? > > > > > > The leaf description-stmt using 'ip-address' should specify if any zone > > > support is required. > > > The default could be 'none' so no mention is needed most of the time. > > > > > > > > > > > > > > > Regards, > > > Rob > > > > > > > > > > > > Andy > > > > > > > > > > -----Original Message----- > > > > From: netmod <[email protected] > > > <mailto:[email protected]>> On Behalf Of Randy Presuhn > > > > Sent: 08 April 2022 18:59 > > > > To: Christian Hopps <[email protected] <mailto:[email protected]>> > > > > Cc: [email protected] <mailto:[email protected]>; [email protected] > > > <mailto:[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 > > > <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] <mailto:[email protected]> > > > > https://www.ietf.org/mailman/listinfo/netmod > > > <https://www.ietf.org/mailman/listinfo/netmod> > > > > > > _______________________________________________ > > > netmod mailing list > > > [email protected] <mailto:[email protected]> > > > https://www.ietf.org/mailman/listinfo/netmod > > > <https://www.ietf.org/mailman/listinfo/netmod> > > > > > > > > > _______________________________________________ > > > netmod mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > > Lsr mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/lsr > > > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Jürgen Schönwälder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
