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

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Tom,

Please see inline ...

> -----Original Message-----
> From: tom petch <[e-mail]>
> Sent: 13 April 2022 10:22
> To: Rob Wilton (rwilton) <[e-mail]>; [e-mail];
> [e-mail]
> Subject: Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-
> yang-10.txt
> 
> From: netmod <[e-mail]> on behalf of Rob Wilton
> (rwilton) <rwilton=[e-mail]>
> Sent: 11 April 2022 18:06
> 
> 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.
> 
> 
> <tp>
> 
> As is sometimes the case with the processes of the IETF, this ignores any
> issues of transition.  I have pointed out a significant number of WG that have
> modules in I-D which include no-zone, in various states, perhaps increasing
> your figures by an order of magnitude.  What are you going to do with I-D
> e.g. in the RFC Editor queue?  Haul them back?

I think that depends on what consensus is reached.

I have no desire of trying to republish existing RFCs to either change "ip-address" to "ip-address-no-zone" or to change "ip-address-no-zone" to "ip-address".  I think the pragmatic thing to do would be to potentially flag these as errata so that they are hopefully fixed if/when the YANG module is eventually updated.

Entirely separately from this specific discussion, it would be good if we (the IETF) could come up with a better long-term plan for maintaining and evolving IETF YANG modules.


> 
> I think that the plan below is a bad one.  I would introduce types with zone -
> that is a no-brainer - but would deprecate the existing types.

Why is deprecating an existing type a problem?  It is deprecated, not obsolete.

It does not mean that modules can't use "ip-address-no-zone", it would just indicate that "ip-address" is the recommended type, if we get to a consensus where ip-address should migrate to meaning exactly the same as ip-address-no-zone.

There are APIs in Java that have been deprecated for 10+ years that are still available for use, but where the recommended is to not use them, or use a replacement API instead.

Regards,
Rob


> 
> Tom Petch
> 
> 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 <[e-mail]> On Behalf Of Randy Presuhn
> > Sent: 08 April 2022 18:59
> > To: Christian Hopps <[e-mail]>
> > Cc: [e-mail]; [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
> > 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]
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod