Rob, I think your suggestion is a good compromise.
I don't see the issue with deprecating no-zone since it can still be used.
Regards,Reshad.
On Monday, April 11, 2022, 02:43:53 PM EDT, Andy Bierman
<[email protected]> wrote:
On Mon, Apr 11, 2022 at 11:09 AM Randy Presuhn
<[email protected]> 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-addressand
wanted zones, or supported it.
There isn't any YANG statement (yet) that could warn the userthat 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 changesonce 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)
>> <[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
>
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
