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" <j...@joelhalpern.com> 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"
<lsr-boun...@ietf.org on behalf of j...@joelhalpern.com> 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=40cisco....@dmarc.ietf.org
<mailto:40cisco....@dmarc.ietf.org>>
> > 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 <netmod-boun...@ietf.org
> > <mailto:netmod-boun...@ietf.org>> On Behalf Of Randy Presuhn
> > > Sent: 08 April 2022 18:59
> > > To: Christian Hopps <cho...@chopps.org
<mailto:cho...@chopps.org>>
> > > Cc: l...@ietf.org <mailto:l...@ietf.org>; netmod@ietf.org
> > <mailto:netmod@ietf.org>
> > > 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
> > > netmod@ietf.org <mailto:netmod@ietf.org>
> > > https://www.ietf.org/mailman/listinfo/netmod
> > <https://www.ietf.org/mailman/listinfo/netmod>
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org <mailto:netmod@ietf.org>
> > https://www.ietf.org/mailman/listinfo/netmod
> > <https://www.ietf.org/mailman/listinfo/netmod>
> >
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
> _______________________________________________
> Lsr mailing list
> l...@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
