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
