Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Andy Bierman <[e-mail]>]

On Mon, Apr 11, 2022 at 11:09 AM Randy Presuhn <
[e-mail]> 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=[e-mail]
> >> <mailto:[e-mail]>> 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 <[e-mail]
> >>     <mailto:[e-mail]>> On Behalf Of Randy Presuhn
> >>      > Sent: 08 April 2022 18:59
> >>      > To: Christian Hopps <[e-mail] <mailto:[e-mail]
> >>
> >>      > Cc: [e-mail] <mailto:[e-mail]>; [e-mail]
> >>     <mailto:[e-mail]>
> >>      > 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
> >>      > [e-mail] <mailto:[e-mail]>
> >>      > https://www.ietf.org/mailman/listinfo/netmod
> >>     <https://www.ietf.org/mailman/listinfo/netmod>
> >>
> >>     _______________________________________________
> >>     netmod mailing list
> >>     [e-mail] <mailto:[e-mail]>
> >>     https://www.ietf.org/mailman/listinfo/netmod
> >>     <https://www.ietf.org/mailman/listinfo/netmod>
> >>
> >>
> >> _______________________________________________
> >> netmod mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/netmod
> >
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>