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

[Jürgen Schönwälder <[e-mail]>]

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" <[e-mail]> 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" <[e-mail] on behalf of [e-mail]> 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)
>     >      > <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
>     > 
>     >      _______________________________________________
>     >      Lsr mailing list
>     >      [e-mail]
>     >      https://www.ietf.org/mailman/listinfo/lsr
>     > 
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Jürgen Schönwälder              Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>