On Mon, Apr 11, 2022 at 11:09 AM Randy Presuhn <
randy_pres...@alumni.stanford.edu> wrote:
> Hi -
>
> On 2022-04-11 10:43 AM, Joel M. Halpern 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 like wishful thinking. There's really no way to verify that
> no one anywhere has used the specification as it was intended.
>
> > It seems to me that the first step in the plan below is reasonable. But
>
> Agreed.
>
> > changing ip-address itself seems a bad idea. If one means no-zone, use
> > the -no-zone typedef.
>
> I'd go further. There are at least two bad ideas in the second step:
> (1) the incompatible change to ip-address
>
IMO this change aligns with the operational expectations and actual usage.
To Acee's point, nobody has said (on this list) that they used ip-address
and wanted zones, or supported it.
There isn't any YANG statement (yet) that could warn the user
that a typedef is going to have an NBC-change in 2 years,
and then another (in 2 years) stating the NBC change occurred.
Real code (and YANG is just more source code) needs incompatible changes
once in a while. Some languages have deprecation warnings.
YANG needs that, and hopefully the versioning work will address it.
(2) the deprecation of ip-address-no-zone, which would trigger
> maintenance headaches for everyone who used that type
> correctly in the first place.
>
agreed that this does not need to be deprecated
>
> Hoping that Yang versioning would be able to paper over the
> resulting mess strikes me as overly optimistic.
>
>
The NBC issues are real (as this thread clearly demonstrates).
There are corner-cases where an incompatible change is the least worst
solution.
> Randy
>
>
Andy
> > Yours,
> > Joel
> >
> > On 4/11/2022 1:28 PM, Andy Bierman wrote:
> >>
> >>
> >> On Mon, Apr 11, 2022 at 10:07 AM Rob Wilton (rwilton)
> >> <rwilton=40cisco....@dmarc.ietf.org
> >> <mailto: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.
> >>
> >>
> >>
> >> 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 <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
> >> <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>
> >>
> >> _______________________________________________
> >> netmod mailing list
> >> netmod@ietf.org <mailto:netmod@ietf.org>
> >> https://www.ietf.org/mailman/listinfo/netmod
> >> <https://www.ietf.org/mailman/listinfo/netmod>
> >>
> >>
> >> _______________________________________________
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
