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

From: tom petch <[email-masked]>
Date: Mon, 4 Apr 2022 11:10:05 +0000

I assume that this is a refresh while waiting for ospf.yang to wind its way through the system

I wonder if the ip address should be the no-zone variant from RFC6991 - I never know the answer to that so keep asking.

Some time the contact needs updating to https://datatracker and the TLP to 'Revised'

Tom Petch

________________________________________
From: Lsr <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: 07 March 2022 03:14
To: [email-masked]
Cc: [email-masked]
Subject: [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.

        Title           : YANG Model for OSPFv3 Extended LSAs
        Authors         : Acee Lindem
                          Sharmila Palani
                          Yingzhen Qu
        Filename        : draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
        Pages           : 29
        Date            : 2022-03-06

Abstract:
   This document defines a YANG data model augmenting the IETF OSPF YANG
   model to provide support for OSPFv3 Link State Advertisement (LSA)
   Extensibility as defined in RFC 8362.  OSPFv3 Extended LSAs provide
   extensible TLV-based LSAs for the base LSA types defined in RFC 5340.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-extended-lsa-yang-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospfv3-extended-lsa-yang-10

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts

_______________________________________________
Lsr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lsr

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 4 Apr 2022 14:58:50 +0000

Hi Tom, +Juergen, netmod WG,  

I think the question you ought to be asking is whether the base IPv4 and IPv6 address types should be modified to NOT include the zone and the zone versions should be added as a separate YANG type. 

The RFC 6991 is under revision now:

https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6991-bis/

However, I'm not sure if the painful backward compatibility discussions could be overcome.  We'd also have to admit that it was a big mistake to include the zone in the base addresses. In any case, I don't think we just start using the no-zone types when the base addresses types are used everywhere. 

Thanks,
Acee

On 4/4/22, 7:11 AM, "Lsr on behalf of tom petch" <[email-masked] on behalf of [email-masked]> wrote:

    Tom Petch

    Abstract:

---

From: tom petch <[email-masked]>
Date: Mon, 4 Apr 2022 15:54:52 +0000

From: Acee Lindem (acee) <[email-masked]>
Sent: 04 April 2022 15:58

<tp>

Well, there are plenty of uses of the no-zone types as well, so some authors, some YANG doctors, have made the conscious choice to use them.  I cannot do a search just now but I see no-zone in the dhc and I2NSF WG I-Ds, and there are others.

Also, some authors want the zone information as part of their leaf.

Tom Petch

Thanks,
Acee

    Tom Petch

    Abstract:

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 4 Apr 2022 16:30:33 +0000

In the MIB,  the base types don't include the zone - https://www.ietf.org/rfc/rfc4001.txt

It was very unfortunate that the YANG IP addresses included the zone in the base types. 

Tom - I think it would be hard to find an author where including the zone was a conscious decision. 

Thanks,
Acee

On 4/4/22, 11:55 AM, "tom petch" <[email-masked]> wrote:

    <tp>

    Tom Petch

    Thanks,
    Acee

        Tom Petch

        Abstract:

---

From: Christian Hopps <[email-masked]>
Date: Tue, 5 Apr 2022 09:32:46 -0400

If they are new leaf values why not use the correct no-zone variant, what's the harm in doing it right? It has a nice side effect of basically restricting the base spec zone values to no-zone only. :)

Thanks,
Chris.
[wg member]

> On Apr 4, 2022, at 12:30, Acee Lindem (acee) <acee=[email-masked]> wrote:
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 5 Apr 2022 13:48:25 +0000

[wg-member]

The thing is that most of the existing RFCs use inet:ip-address rather inet:ip-address-no-zone. It would be better to if we could fix inet:ip-address in RFC 6991 BIS to not include the zone similar to what was done in the MIB (RFC 4001). However, we're getting the passive aggressive treatment on this point. 

If the netmod WG doesn't have the integrity and strength to fix RFC 6991 in the BIS version, we should consider changing the OSPF and IS-IS base specifications before publication to use inet:ip-address-no-zone. 

Thanks,
Acee 

On 4/5/22, 9:33 AM, "Christian Hopps" <[email-masked]> wrote:

    Thanks,
    Chris.
    [wg member]

---

From: Christian Hopps <[email-masked]>
Date: Tue, 5 Apr 2022 10:47:17 -0400

> On Apr 5, 2022, at 09:48, Acee Lindem (acee) <[email-masked]> wrote:
> 
> [wg-member]
> 

[as wg-member]

I think we should do the right thing in our (LSR) modules no matter what, again, what harm does it do to get it right in the modules under LSR WGs direct control?

The netmod change is a much larger action with a large blast radius (not saying it's wrong), and perhaps most importantly is also outside of LSR WG control. :)

Thanks,
Chris.
[wg-member]

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 5 Apr 2022 14:56:51 +0000

Hi Chris, 

    [as wg-member]

I agree and sent an Email to the authors of RFC 9127 BIS which is in the IESG right now. 

This is the way it should be fixed, irrespective YANG backward compatibility. It is a bug and it ought to be fixed in RFC 6991 BIS. No products that I know of allow a zone via the textual convention in IP address configuration. This is just wrong... 

Thanks,
Acee

    Thanks,
    Chris.
    [wg-member]

---

From: Jürgen Schönwälder <[email-masked]>
Date: Tue, 5 Apr 2022 17:36:44 +0200

> The thing is that most of the existing RFCs use inet:ip-address rather inet:ip-address-no-zone. It would be better to if we could fix inet:ip-address in RFC 6991 BIS to not include the zone similar…

You either assume that all existing uses of inet:ip-address (inside
the IETF and outside the IETF) are wrong or you are willing to break
all the existing correct uses of inet:ip-address so that the type
matches your expectations.

The existing YANG update rules are pretty clear that changing the
semantics of definitions is not allowed. Hence, all the WG could do
is to deprecate ip-address and to introduce ip-address-zone.

/js

-- 
Jürgen Schönwälder              Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 5 Apr 2022 15:44:27 +0000

On 4/5/22, 11:37 AM, "Lsr on behalf of Jürgen Schönwälder" <[email-masked] on behalf of [email-masked]> wrote:

The best outcome would be to fix ip-address to not include the zone, introduce ip-address-zone, and deprecate ip-address-no-zone. My take all the is that all the existing usages do not require zone and this would be a fix as opposed to a change. 

Acee

    /js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 5 Apr 2022 10:03:25 -0700

On Tue, Apr 5, 2022 at 8:45 AM Acee Lindem (acee) <acee=
[email-masked]> wrote:

>
>
> On 4/5/22, 11:37 AM, "Lsr on behalf of Jürgen Schönwälder" <
> [email-masked] on behalf of [email-masked]>
> wrote:
>
>     > The thing is that most of the existing RFCs use inet:ip-address
> rather inet:ip-address-no-zone. It would be better to if we could fix
> inet:ip-address in RFC 6991 BIS to not include the zone similar to what was
> done in the MIB (RFC 4001). However, we're getting the passive aggressive
> treatment on this point.
>     >
>
> The best outcome would be to fix ip-address to not include the zone,
> introduce ip-address-zone, and deprecate ip-address-no-zone. My take all
> the is that all the existing usages do not require zone and this would be a
> fix as opposed to a change.
>
>
I don't think this will harm our implementations.
The type is still string. The pattern will change but that is handled by a
library.
Whatever pattern is used will get handled the same way.

The same problem exists for 'date' and 'date-no-zone' types,
but they are not used very much.

But...

Since import-without-revision is used most of the time,
a module importing ietf-inet-types will get what?
Very implementation-specific, that's what.
Maybe both versions of ip-address present in the same server, maybe not.

Acee
>     /js

Andy

> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Jürgen Schönwälder <[email-masked]>
Date: Tue, 5 Apr 2022 21:02:49 +0200

> Whatever pattern is used will get handled the same way.

Either a zone is allowed to be present or it is not, this does make a
difference, its not a cosmetic change.
 
> but they are not used very much.

Perhaps we should call types a, b, c, and so on - this may force
people to read the descriptions. ;-)

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 5 Apr 2022 12:20:36 -0700

> difference, its not a cosmetic change.

True. The code will probably accept the pattern then fail trying to use the
string.
If the client sends the form with a zone.

> people to read the descriptions. ;-)

For some reason, the smarter the person, the less likely they are to
read any of the documentation before using some software.
I call it the "it should work the way I would design it" phenomenon :-)

You have to admit that Acee's suggestion is more intuitive than the current
definitions.

Clearly an NBC change.
IMO it is more useful to put some YANG extension magic in these specific
typedefs
than just bumping a major revision number. This is a great use-case for the
version DT.

There probably is no solution path where nobody has to change any YANG or
any code
and everything still works.

Andy

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 6 Apr 2022 21:02:23 +0000

Jürgen and netmod WG,  +IESG,

It is not just the IETF models that are using the inet:ip-address for the standard IPv4/IPv6 addresses without zones. Every vendor’s native models and the OpenConfig models use the base types and expect the standard IP address notation. If we don’t fix this, it is something that people can point to as another example of the IETF being out of touch with reality.

I thought about more, and it might make the backward compatibility easier if we just leave the existing ip-address-no-zone, ipv4-address-no-zone, and ipv6-address-no-zone types and add *-zone types for the remote possibility that someone actually wants to include the zone.  In the existing RFC 6991 BIS document, we could merely remove the zone from the ip-address, ipv4-address, and ipv6-address types and classify this as we would any other bug fix. While including the zone was the original intent of the base types, this is what those of us who work on software products would classify as a requirements bug.

Thanks,
Acee

From: Andy Bierman <[email-masked]>
Date: Tuesday, April 5, 2022 at 3:21 PM
To: Juergen Schoenwaelder <[email-masked]>, Andy Bierman <[email-masked]>, Acee Lindem <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

On Tue, Apr 5, 2022 at 12:02 PM Jürgen Schönwälder <[email-masked]<mailto:[email-masked]>> wrote:

True. The code will probably accept the pattern then fail trying to use the string.
If the client sends the form with a zone.

Clearly an NBC change.
IMO it is more useful to put some YANG extension magic in these specific typedefs
than just bumping a major revision number. This is a great use-case for the version DT.

There probably is no solution path where nobody has to change any YANG or any code
and everything still works.

/js

Andy

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 6 Apr 2022 22:04:02 +0000

Hi Chris (as WG member),

    [as wg-member]

Actually this is a very bad idea. We don't want to endorse the error in RFC 6991 that could be fixed in the BIS document. I'm certainly not going to change the documents I authored when the world expects an IP address to not include a zone. I sent an Email to the RFC 9127 BIS (which is currently in IESG review) authors about this issue and apparently they agree with me as they chose not to respond. 

Thanks,
Acee

    Thanks,
    Chris.
    [wg-member]

---

From: Jürgen Schönwälder <[email-masked]>
Date: Thu, 7 Apr 2022 09:34:52 +0200

Here is roughly what happened:

- RFC 6020 (published ~12 years ago) introduced the ip-address
  type. It included an optional zone index part since zone indexes
  are necessary in certain situations (e.g., configuring services
  listening on link-local addresses or clients connecting to services
  listening on link-local addresses).

- RFC 6991 (published ~9 years ago) added the ip-address-no-zone types
  since people felt that it is useful to also an ip address type
  without the optional zone part for situations where a zone is not
  applicable. The name 'ip-address-no-zone' was picked since the name
  ip-address was already taken.

I understand that the names resulting from this evolution of the YANG
module confuse people not looking up the type definitions. Let me note
that using a type allowing for an optional zone for a leaf that never
needs a zone is not a fatal error (its like using an int where a short
is sufficient) while using a type not allowing for a zone for a leaf
that may need zones is a fatal error (using a short where an int is
required) requiring an update of the definition of the leaf to fix.

What are our options?

a) Do nothing and accept that types are called as they are.
b) Change the types as suggested and accept that doing so breaks
   modules where zone indexes are meaningful.
c) Deprecate the types and create a new module defining new types
   so that modules can opt-in to use better names.
d) Deprecate the -no-zone types and move back to have a single
   type for IP addresses.

Any other options?

How are we going to pick between them?

/js

---

From: Kent Watsen <[email-masked]>
Date: Thu, 7 Apr 2022 08:39:01 +0000

Juergen et. al. ,

> d) Deprecate the -no-zone types and move back to have a single

What’s the value of (d)?  Seems like keeping is better, if only to guide readers towards knowing the base types include zones.  And, besides, any module-designer wishing to restrict zones would then have to create their own “no-zone” types. 

> Any other options?

e) define new types “*-with-zone”
 and deprecate existing “ip*-address” types and recast the “*-no-zone” types as derived from the *-with-zone types?  This way it is always a conscious decision. 

> How are we going to pick between them?

I don’t think Errata works, since 6991 defining the *-no-zone types makes it clear what intended. 

Kent (hatless)

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 7 Apr 2022 09:25:03 +0000

I basically agree with Acee, and I think that we should do (b):

I appreciate that this is an NBC change, but I believe that this is the most intuitive definition and is the best choice longer term.  I also note that the base ipv4-address/ipv6-address types in OpenConfig (where they use the OC copy/version of inet-types and not ietf-inet-types) don't allow a zone to be specified and assumes the default zone.  They have separate types in cases where a zone is allowed to be specified, i.e., aligned to what (b) proposes.

For modules that are using/wanting zones (if any), then they can migrate to the new explicit zone type.   draft-ietf-netmod-yang-module-versioning, if it keeps its import "revision-or-derived" extension, would also allow such modules to indicate the dependency on the updated revision/definition of ietf-inet-types.yang.

Of course, the description associated with the updated ietf-inet-types.yang revision should clearly highly the non-backwards-compatible change to the types.

Rob

-----Original Message-----
From: iesg <[email-masked]> On Behalf Of Jürgen Schönwälder
Sent: 07 April 2022 08:35
To: Acee Lindem (acee) <[email-masked]>
Cc: [email-masked]; The IESG <[email-masked]>; [email-masked]
Subject: Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

What are our options?

Any other options?

/js

---

From: Jürgen Schönwälder <[email-masked]>
Date: Thu, 7 Apr 2022 14:42:48 +0200

> What’s the value of (d)?  Seems like keeping is better, if only to guide readers towards knowing the base types include zones.  And, besides, any module-designer wishing to restrict zones would the…

I added d) for completeness.
 
>  and deprecate existing “ip*-address” types and recast the “*-no-zone” types as derived from the *-with-zone types?  This way it is always a conscious decision. 

Yes, looks like a valid 5th option.

My understanding is that we currently enumerate the options, not their
pros and cons and whether we like them or not.

> I don’t think Errata works, since 6991 defining the *-no-zone types makes it clear what intended. 

Yes, my understanding is that the type definitions are clear and
unambiguous. The issue is that the names tend to mislead people.

/js

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 7 Apr 2022 14:35:03 +0000

Kent, 

On 4/7/22, 4:39 AM, "Kent Watsen" <[email-masked]> wrote:

    Juergen et. al. ,

We already a large number of models that use the existing inet:ip-address types whose implementations don't support the zone. Why should we start using this esoteric "no-zone" types in new models? Note you have RFC 9127 BIS going to through IESG right now... Better to fix it in one place (actually three, since there is ipv4-address, ipv6-address, and ip-address) then in who knows how many since many vendors import ietf-inet-types in their native models. 

Thanks,
Acee

    Kent (hatless)

---

From: Jürgen Schönwälder <[email-masked]>
Date: Thu, 7 Apr 2022 18:08:12 +0200

> We already a large number of models that use the existing inet:ip-address types whose implementations don't support the zone. Why should we start using this esoteric "no-zone" types in new models?…

I can't tell how many usages of ip-address are out there where the
optional zone never applies and how many usages of ip-address are out
there where dropping the optional zone breaks models for deployments
where link-local addresses are used. What we see may be biased by the
kind of data models we look at, routing related data models may show
different properties than application layer related data models.

/js

---

From: tom petch <[email-masked]>
Date: Thu, 7 Apr 2022 16:11:12 +0000

From: Lsr <[email-masked]> on behalf of Rob Wilton (rwilton) <rwilton=[email-masked]>
Sent: 07 April 2022 10:25

<tp>

I am concerned that such behaviour will damage the standing of the IETF at large.

We clearly laid down rules as to what updates were regarded as compatible so that authors of software could be confident that their work was robust and future-proof.  We did it with SNMP, inter alia, and we have carried that forward with YANG.  To tear up that understanding , creating who knows how much disruption, can only harm the standing of IETF.

Much has been said about how implementations have assumed that the address types do not include a zone but no evidence has been put forward for that assertion.

I have always assumed that software uses libraries and that the libraries have been written with an understanding of the specifications such that if a zone is received over the wire in conformance with the specification but where the display, field or such like does not allow for a zone, then, tolerant of what to accept, the zone is silently discarded and the address is used without the zone.  But, like the assertion that keeping the zone will cause who knows what damage, I have not done the research to substantiate that assumption.

Tom Petch 

Rob

-----Original Message-----
From: iesg <[email-masked]> On Behalf Of Jürgen Schönwälder
Sent: 07 April 2022 08:35
To: Acee Lindem (acee) <[email-masked]>
Cc: [email-masked]; The IESG <[email-masked]>; [email-masked]
Subject: Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

What are our options?

Any other options?

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 7 Apr 2022 09:31:26 -0700

> I am concerned that such behaviour will damage the standing of the IETF at
MAY for the client means MUST for the server.
But if no servers actually support it, because the YANG does not match
the operational requirements, then is it really a MUST requirement?

This seems like a bugfix, and the worst thing the IETF could do wrt/
standing
is to force the world to change every module that imports the typedef.
Since many people were not aware of the full syntax, it is not clear that
the WG intent was to include a zone.

Seems like a bugfix to a pattern, like we have done several times already.

Andy

> We clearly laid down rules as to what updates were regarded as compatible
> so that authors of software could be confident that their work was robust
> and future-proof.  We did it with SNMP, inter alia, and we have carried
> that forward with YANG.  To tear up that understanding , creating who knows
> how much disruption, can only harm the standing of IETF.
>
> Much has been said about how implementations have assumed that the address
> types do not include a zone but no evidence has been put forward for that
> assertion.
>
> I have always assumed that software uses libraries and that the libraries
> have been written with an understanding of the specifications such that if
> a zone is received over the wire in conformance with the specification but
> where the display, field or such like does not allow for a zone, then,
> tolerant of what to accept, the zone is silently discarded and the address
> is used without the zone.  But, like the assertion that keeping the zone
> will cause who knows what damage, I have not done the research to
> substantiate that assumption.
>
> Tom Petch
>
> I appreciate that this is an NBC change, but I believe that this is the
> most intuitive definition and is the best choice longer term.  I also note
> that the base ipv4-address/ipv6-address types in OpenConfig (where they use
> the OC copy/version of inet-types and not ietf-inet-types) don't allow a
> zone to be specified and assumes the default zone.  They have separate
> types in cases where a zone is allowed to be specified, i.e., aligned to
> what (b) proposes.
>
> For modules that are using/wanting zones (if any), then they can migrate
> to the new explicit zone type.   draft-ietf-netmod-yang-module-versioning,
> if it keeps its import "revision-or-derived" extension, would also allow
> such modules to indicate the dependency on the updated revision/definition
> of ietf-inet-types.yang.
>
> Of course, the description associated with the updated
> ietf-inet-types.yang revision should clearly highly the
> non-backwards-compatible change to the types.
>
> Rob
>
>
> Subject: Re: [netmod] [Lsr] I-D Action:
> draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
>
> > It is not just the IETF models that are using the inet:ip-address for
> the standard IPv4/IPv6 addresses without zones. Every vendor’s native
> models and the OpenConfig models use the base types and expect the standard
> IP address notation. If we don’t fix this, it is something that people can
> point to as another example of the IETF being out of touch with reality.
> >
> > I thought about more, and it might make the backward compatibility
> easier if we just leave the existing ip-address-no-zone,
> ipv4-address-no-zone, and ipv6-address-no-zone types and add *-zone types
> for the remote possibility that someone actually wants to include the
> zone.  In the existing RFC 6991 BIS document, we could merely remove the
> zone from the ip-address, ipv4-address, and ipv6-address types and classify
> this as we would any other bug fix. While including the zone was the
> original intent of the base types, this is what those of us who work on
> software products would classify as a requirements bug.
> >
> > Thanks,
> > Acee
> >
> > To: Juergen Schoenwaelder <[email-masked]>, Andy
> Bierman <[email-masked]>, Acee Lindem <[email-masked]>, "[email-masked]"
> <[email-masked]>, "[email-masked]" <[email-masked]>
> > Subject: Re: [netmod] [Lsr] I-D Action:
> draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
> >
> >
> >
> [email-masked]<mailto:
> [email-masked]>> wrote:

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 7 Apr 2022 17:04:46 +0000

Hi Martin, 

On 4/7/22, 1:02 PM, "netmod on behalf of Martin Björklund" <[email-masked] on behalf of [email-masked]> wrote:

    > MAY for the client means MUST for the server.

    I'm not sure what you mean here.

    But I'm also not sure I understand what the real problem is.  Just b/c
    the type allows a zone doesn't mean that all leafs that use this type
    MUST support a zone.  Compare with the value "0.0.0.0".  It is a legal
    value according to the pattern, but it will not be valid in all places
    where this type is used.  And even when an implementation supports
    zones, it will not accept all legal (according to the pattern) values
    for the zone index.  Perhaps the solution is to explain this
    better in the description?

    > the WG intent was to include a zone.

    It is pretty clear IMO that this was not a mistake.  The text
    explicitly says:

              The IPv4 address may include a zone
              index, separated by a % sign.

    > Seems like a bugfix to a pattern, like we have done several times already.

    I don't think this is a bugfix.

A bugfix for the requirements for the base types that requires fixing the pattern and description. 

Acee

    /martin

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 7 Apr 2022 13:17:44 -0400

Acee, I am missing something basic.
It seems to me that it would be very wrong for the LSR YANG module to 
demand a change to an important type because it turns out that type 
doesn't mean what LSR thought it meant.  Such an error is LSR's problem, 
not the underlying modules.

There seem to be two fixes.  If it is for some reason imperitive to us 
the same typedef we have been using, then put in text / patterns / 
restrictions saying that this model MUST NOT use the scope field.

More reasonably, use a different typedef in this model.

Yours,
Joel

---

From: Andy Bierman <[email-masked]>
Date: Thu, 7 Apr 2022 10:17:59 -0700

On Thu, Apr 7, 2022 at 10:01 AM Martin Björklund <[email-masked]> wrote:

> > > I am concerned that such behaviour will damage the standing of the
> IETF at
> > > large.
> > >
> > >
So no change is needed?
Is it an 'invalid-value' if the pattern accepts the string?
The server can return 'operation-failed' or 'operation-not-supported' at
any time already.
The server is not supposed to ignore the extra characters though.

Andy

> > > to the new explicit zone type.
>  draft-ietf-netmod-yang-module-versioning,
> > > > > > introduce ip-address-zone, and deprecate ip-address-no-zone. My
> take
> > > all
> > > > > The type is still string. The pattern will change but that is
> handled
> > > by a
> > > > > library.
> > > > True. The code will probably accept the pattern then fail trying to
> use
> > > the string.
> > > > than just bumping a major revision number. This is a great use-case
> for
> > > the version DT.
> > > >
> > > > There probably is no solution path where nobody has to change any
> YANG
> > > or any code

---

From: Martin Björklund <[email-masked]>
Date: Thu, 07 Apr 2022 19:01:02 +0200 (CEST)

/martin

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 7 Apr 2022 17:22:35 +0000

Hi Joel,

On 4/7/22, 1:18 PM, "Joel M. Halpern" <[email-masked]> wrote:

Point me to a usages where the zone is actually desired and supported? 

Acee

    Yours,
    Joel

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 7 Apr 2022 17:47:59 +0000

Jürgen, 

On 4/7/22, 12:08 PM, "Jürgen Schönwälder" <[email-masked]> wrote:

Point me to one prevalent implementation that supports the textual convention for zone for IPv6 link-local addresses? I suspect this would be akin to Abraham finding a righteous man...  

Acee

    /js

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 7 Apr 2022 13:51:44 -0400

Given that you are asking for an incompatible change to an existing 
module, the shoe would seem to be on the other foot.

If you could show it was necessary to make such an incompatible change, 
then there would be a difficult argument to be had.  But you simply have 
not shown it.  (And showing that no one uses the zone field would seem 
the reasonable and impossible bar for doing such.)

Yours,
Joel

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 7 Apr 2022 11:38:47 -0700

Hi -

Let me get this straight.  WG A standardized types X and Y years ago,
and support for these has presumably been implemented in some number
of tools, which in turn have been used to develop some unknowable
number of products, whose deployment is even more unknowable.

WG B comes along, and wants to use X, but dislikes the name, preferring
to call it Y instead.  WG B then demands that A rename X to Y, with
no regard to the process for managing changes to types nor to the
collateral damage resulting from the changed definition of Y.

That we should even be bothering with this discussion is the kind of
thing that gives standards organizations a bad name.

Randy

---

From: Christian Hopps <[email-masked]>
Date: Fri, 08 Apr 2022 08:11:29 -0400

> collateral damage resulting from the changed definition of Y.

Hi Randy,

It's not really like this.

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.

Thanks,
Chris.

---

From: tom petch <[email-masked]>
Date: Fri, 8 Apr 2022 16:32:13 +0000

From: Lsr <[email-masked]> on behalf of Joel M. Halpern <[email-masked]>
Sent: 07 April 2022 18:51

<tp>

I said previously that I saw the DHC and I2NSF WG consciously using no-zone but was not able to check for others.  I now can check, in part, and see detnet, MPLS and rtgwg using no-zone.  It may be that nvo3, sacm and intarea are other such WGs.

Interestingly, I recall one author saying that yes, they needed the zone format and I see that mldp uses a mix of zone and no-zone so that may have been the one I was remembering and it may be a case where a zone is required.  I would make sense for that protocol, as it would for other 'local' protocols, such as printing, problem determination and so on.

Tom Petch

Yours,
Joel

---

From: Randy Presuhn <[email-masked]>
Date: Fri, 8 Apr 2022 10:59:13 -0700

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 8 Apr 2022 19:25:16 +0000

See inline. 

On 4/8/22, 1:59 PM, "netmod on behalf of Randy Presuhn" <[email-masked] on behalf of [email-masked]> wrote:

    Hi -

If you look at the existing YANG RFCs rather than drafts that are confirming to the error, you'll notice that they don't use the no-zone types:

https://datatracker.ietf.org/doc/rfc8344/
https://datatracker.ietf.org/doc/rfc8349/
https://datatracker.ietf.org/doc/rfc8519/
https://datatracker.ietf.org/doc/rfc9067/

Also, if you look at the SNMP RFC 4001, you'll note that the base types do not include the zone index and RFC8344 references the MIB types using the base types (see snippet below). Clearly, it was wrong to make the IP addresses including the zone the default and I'm not sure why there is all this effort not to just admit, fix the RFC 6991 BIS version, and be done with it. 

InetAddressIPv4 ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "1d.1d.1d.1d"
    STATUS       current
    DESCRIPTION
        "Represents an IPv4 network address:
           Octets   Contents         Encoding
            1-4     IPv4 address     network-byte order

         The corresponding InetAddressType value is ipv4(1).

         This textual convention SHOULD NOT be used directly in object
         definitions, as it restricts addresses to a specific format.
         However, if it is used, it MAY be used either on its own or in
         conjunction with InetAddressType, as a pair."
    SYNTAX       OCTET STRING (SIZE (4))

InetAddressIPv6 ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x"
    STATUS       current
    DESCRIPTION
        "Represents an IPv6 network address:

           Octets   Contents         Encoding
            1-16    IPv6 address     network-byte order

         The corresponding InetAddressType value is ipv6(2).

         This textual convention SHOULD NOT be used directly in object
         definitions, as it restricts addresses to a specific format.
         However, if it is used, it MAY be used either on its own or in
         conjunction with InetAddressType, as a pair."
    SYNTAX       OCTET STRING (SIZE (16))

InetAddressIPv4z ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "1d.1d.1d.1d%4d"
    STATUS       current
    DESCRIPTION
        "Represents a non-global IPv4 network address, together
         with its zone index:

           Octets   Contents         Encoding
            1-4     IPv4 address     network-byte order
            5-8     zone index       network-byte order

         The corresponding InetAddressType value is ipv4z(3).

         The zone index (bytes 5-8) is used to disambiguate identical
         address values on nodes that have interfaces attached to
         different zones of the same scope.  The zone index may contain
         the special value 0, which refers to the default zone for each
         scope.

         This textual convention SHOULD NOT be used directly in object
         definitions, as it restricts addresses to a specific format.
         However, if it is used, it MAY be used either on its own or in
         conjunction with InetAddressType, as a pair."
    SYNTAX       OCTET STRING (SIZE (8))

InetAddressIPv6z ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x%4d"
    STATUS       current
    DESCRIPTION
        "Represents a non-global IPv6 network address, together
         with its zone index:

           Octets   Contents         Encoding
            1-16    IPv6 address     network-byte order
           17-20    zone index       network-byte order

         The corresponding InetAddressType value is ipv6z(4).

         The zone index (bytes 17-20) is used to disambiguate
         identical address values on nodes that have interfaces
         attached to different zones of the same scope.  The zone index
         may contain the special value 0, which refers to the default
         zone for each scope.

         This textual convention SHOULD NOT be used directly in object
         definitions, as it restricts addresses to a specific format.
         However, if it is used, it MAY be used either on its own or in
         conjunction with InetAddressType, as a pair."
    SYNTAX       OCTET STRING (SIZE (20))

Acee

    Randy

---

From: Randy Presuhn <[email-masked]>
Date: Fri, 8 Apr 2022 13:45:02 -0700

Hi -

On 2022-04-08 12:25 PM, Acee Lindem (acee) wrote:
...
> https://datatracker.ietf.org/doc/rfc8344/
...

Huh?  RFC 8344 *does* use inet:ipv4-address-no-zone
and inet:ipv6-address-no-zone.

> Also, if you look at the SNMP RFC 4001, you'll note that the base types do not include the zone index and RFC8344 references the MIB types using the base types (see snippet below).

RFC 4001 addresses the limitation of the IpAddress SMIv2 base type,
which is inherently unsuitable for IPv6 addresses.  The new address
types defined in RFC 4001 have OCTET STRING as their base type. The
"base type" relationship you seem to be inferring reads too
much into the labels, which are merely mnemonic.  One might argue
about the suitability of any particular (non)system of mnemonics,
but the nature of these beasts is that we can't significantly change
them once their published.

> Clearly, it was wrong to make the IP addresses including the zone the default

How is it a "default"?  Both zonable and zoneless types are available
to the model developer.  Nothing makes one or the other a default.

> and I'm not sure why there is all this effort not to just admit, fix the RFC 6991 BIS version, and be done with it.

30+ years of tradition (and BCP) not permitting types to be changed
after they've been published, I suppose, motivated by our total lack
of control over unpublished usage of these types after their definitions
have been published.

If there were actually something wrong with the semantics or syntax,
I'm sure there would be more sympathy for the argument.  But the heart
of the argument is that the types label's mnemonicity is poor.  That,
coupled with the collateral damage resulting from a "fix", makes
the whole argument terribly unpersuasive to me, particularly
when the definition in question was been published, implemented, and
deployed years ago.

Randy

---

From: tom petch <[email-masked]>
Date: Sat, 9 Apr 2022 11:09:25 +0000

From: tom petch <[email-masked]>
Sent: 08 April 2022 17:32

<tp>

<tp2>
I see another use of no-zone in 
  draft-ietf-lsr-ospf-srv6-yang-01

so the LSR WG is, at times, a user of no-zone.

Tom Petch

Yours,
Joel

---

From: Christian Hopps <[email-masked]>
Date: Sat, 09 Apr 2022 07:36:42 -0400

> when the definition in question was been published, implemented, and

FWIW, I'm not arguing for this change; however, to be fair, isn't this also about the existing published modules that are using the incorrect type?

Thanks,
Chris.

---

From: Randy Presuhn <[email-masked]>
Date: Sat, 9 Apr 2022 09:50:46 -0700

Hi -

On 2022-04-09 4:36 AM, Christian Hopps wrote:
...
> FWIW, I'm not arguing for this change; however, to be fair, isn't this 
> also about the existing published modules that are using the incorrect 
> type?

No.  "Incorrect type" is a bit of a mischaracterization.  It's like
saying using "int32" is incorrect if all that is needed is "uint16".
One might say its a little sloppy or mutter "RTFM" under one's breath,
but it's not "incorrect."

Some modules have used a type that potentially can represent more
values than are needed for the intended purpose.  Whether those
implementations will ever accept or produce those values will
depend on whether the code, whether library, generated, or hand-
crafted, enforces the tighter constraints appropriate to the usage
or only the looser constraints appropriate to the type's specification.

But this is also true of every usage of any type where the use
can only exhibit a subset of the possible values of the type,
whether that subsetting is obvious from the description or not,
so I find it really hard to get excited about it.  The more nuanced
a repertoire of types becomes, the more likely developers won't
use exactly the right one, though one would hope that these foibles
are caught during the review process, at least until developers
start reading the documentation for the libraries they employ.

Even in these cases of "incorrect" usage, as Andy and others
have pointed out, stuff still works, because those cases only
require a subset of the values supported by the type.  If the
proposed change is made, usages requiring the full value space of
the original type definition will break, and those formerly
"incorrect" usages will exhibit no change in their behavior.

That is, the proposed change does not improve operation of
anything, and it breaks some things.

For me, it's more important for stuff to work (and to not break
stuff) than it is to align perfectly with the underlying aesthetics
of some naming system attributed post hoc to a set of types.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 9 Apr 2022 10:37:57 -0700

> but it's not "incorrect."
You and Martin convinced me the ip-address type cannot be changed.
There are other options.

If a YANG module is using ip-address, and the WG intent was really to
use ip-address-no-zone, then that module can be fixed with an Errata.
The modules should not need to be updated just for this incorrect typedef
usage.

The type names are unfortunate but in the future this will not happen again.

> start reading the documentation for the libraries they employ.
There are many examples where the pattern allows more strings
than the intended usage.  Also, a server can reject any request for any
reason.

That does not address the conformance problem that Acee may be concerned
about.
What is a server required to support for a leaf with type ip-address?
The text does not look like the zone index is optional for the server to
accept.

> "incorrect" usages will exhibit no change in their behavior.

It works because clients are not sending addresses with a zone index.
I agree with Martin that the NC/RC server is always obligated to reject a
request
it cannot fulfill, regardless of the typedef.

> anything, and it breaks some things.
yes -- too many years out in the wild this way to switch type names around
now.

Andy

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 9 Apr 2022 17:47:32 +0000

I hate when people selectively snip my Emails and respond out of context. Please don't do that in the future! I'll reply to the more constructive thread. 
Acee

On 4/8/22, 4:45 PM, "Lsr on behalf of Randy Presuhn" <[email-masked] on behalf of [email-masked]> wrote:

    Hi -

    ...

    Randy

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 9 Apr 2022 17:59:53 +0000

Hi Andy,

My opinion remains the same that RFC 4001 got it right with types including the zone specification being the exception rather than the default. I know that when people think IP address, they think the dotted 4 octet without “%ZZZZ” appended. I’d still like to know if there are products that actually make use of the zone?

See inline responses in the unsnipped email below.

From: netmod <[email-masked]> on behalf of Andy Bierman <[email-masked]>
Date: Saturday, April 9, 2022 at 1:38 PM
To: Randy Presuhn <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

On Sat, Apr 9, 2022 at 9:51 AM Randy Presuhn <[email-masked]<mailto:[email-masked]>> wrote:
Hi -

If a YANG module is using ip-address, and the WG intent was really to
use ip-address-no-zone, then that module can be fixed with an Errata.
The modules should not need to be updated just for this incorrect typedef usage.

Well, these are probably some of the most ubiquitous types in the YANG and forcing everyone to use the -no-zone types is more a tragedy than merely unfortunate.

There are many examples where the pattern allows more strings
than the intended usage.  Also, a server can reject any request for any reason.

That does not address the conformance problem that Acee may be concerned about.
What is a server required to support for a leaf with type ip-address?
The text does not look like the zone index is optional for the server to accept.

It works because clients are not sending addresses with a zone index.
I agree with Martin that the NC/RC server is always obligated to reject a request
it cannot fulfill, regardless of the typedef.

I thought Martin said a server not supporting zone could accept the IP address and simply ignore the zone? This would seem to be a better options than using the -no-zone types.

yes -- too many years out in the wild this way to switch type names around now.

I know I may be being too pragmatic, but does anyone support zone via %zzzz?

Thanks,
Acee

Randy

Andy

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Sat, 9 Apr 2022 11:28:26 -0700

On Sat, Apr 9, 2022 at 11:00 AM Acee Lindem (acee) <[email-masked]> wrote:

> Hi Andy,
>
>
>
> My opinion remains the same that RFC 4001 got it right with types
> including the zone specification being the exception rather than the
> default. I know that when people think IP address, they think the dotted 4
> octet without “%ZZZZ” appended. I’d still like to know if there are
> products that actually make use of the zone?
>
>
>

I agree the YANG types should have been named differently,
but it was not flagged as a problem 12 years ago..

> *From: *netmod <[email-masked]> on behalf of Andy Bierman <
> [email-masked]>
> *Date: *Saturday, April 9, 2022 at 1:38 PM
> *To: *Randy Presuhn <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *Re: [netmod] [Lsr] I-D Action:
> Well, these are probably some of the most ubiquitous types in the YANG and
> forcing everyone to use the -no-zone types is more a tragedy than merely
> unfortunate.
>

It must not be a real problem or it would not have taken 12 years to
surface.
The typedef is silent about ignoring an explicit zone index in an
ipv4-address value.
If that is allowed, then maybe existing modules do not need to change.
IMO they do not need to change anyway, since a server can just reject an
address with a zone index in it.

I don't think the YANG author or reader is that burdened if '-no-zone' is
added to the type name.

> I thought Martin said a server not supporting zone could accept the IP
> address and simply ignore the zone? This would seem to be a better options
> than using the -no-zone types.
>

Maybe. There is no text in the typedefs but descriptions in the leaf or
other
data node could specify this behavior, or it could be an implementation
decision.

> I know I may be being too pragmatic, but does anyone support zone via

 We cannot get the full picture on this mailing list, after so many years.

Maybe just a clarification in the typedef is needed

  - A server MAY ignore a zone index specified in an ip-address

IMO a module SHOULD use ip-address-no-zone going forward,
if the intent is to disallow a zone index. Some modules have already done
so.

Andy

---

From: Reshad Rahman <[email-masked]>
Date: Sun, 10 Apr 2022 20:42:53 +0000 (UTC)

Inline.
On Wednesday, April 6, 2022, 06:04:42 PM EDT, Acee Lindem (acee) <acee=[email-masked]> wrote:

 Hi Chris (as WG member),

    > On Apr 5, 2022, at 09:48, Acee Lindem (acee) <[email-masked]> wrote:
    > 
    > [wg-member]
    > 
    > The thing is that most of the existing RFCs use inet:ip-address rather inet:ip-address-no-zone. It would be better to if we could fix inet:ip-address in RFC 6991 BIS to not include the zone similar to what was done in the MIB (RFC 4001). However, we're getting the passive aggressive treatment on this point. 
    > 
    > If the netmod WG doesn't have the integrity and strength to fix RFC 6991 in the BIS version, we should consider changing the OSPF and IS-IS base specifications before publication to use inet:ip-address-no-zone. 

    [as wg-member]

Actually this is a very bad idea. We don't want to endorse the error in RFC 6991 that could be fixed in the BIS document. I'm certainly not going to change the documents I authored when the world expects an IP address to not include a zone. I sent an Email to the RFC 9127 BIS (which is currently in IESG review) authors about this issue and apparently they agree with me as they chose not to respond. <RR> Just way behind on IETF emails. I can't speak for the other authors but I don't agree (too late). But I think we should make the change in 9127-bis. And follow current guidelines, as others have mentioned, to tackle what's in 6991-bis.
Regards,Reshad.
Thanks,
Acee

    Thanks,
    Chris.
    [wg-member]

    > Thanks,
    > Acee 
    > 
    > On 4/5/22, 9:33 AM, "Christian Hopps" <[email-masked]> wrote:
    > 
    >    If they are new leaf values why not use the correct no-zone variant, what's the harm in doing it right? It has a nice side effect of basically restricting the base spec zone values to no-zone only. :)
    > 
    >    Thanks,
    >    Chris.
    >    [wg member]
    > 
    >> On Apr 4, 2022, at 12:30, Acee Lindem (acee) <acee=[email-masked]> wrote:
    >> 
    >> In the MIB,  the base types don't include the zone - https://www.ietf.org/rfc/rfc4001.txt
    >> 
    >> It was very unfortunate that the YANG IP addresses included the zone in the base types. 
    >> 
    >> Tom - I think it would be hard to find an author where including the zone was a conscious decision. 
    >> 
    >> Thanks,
    >> Acee
    >> 
    >> On 4/4/22, 11:55 AM, "tom petch" <[email-masked]> wrote:
    >> 
    >>  From: Acee Lindem (acee) <[email-masked]>
    >>  Sent: 04 April 2022 15:58
    >> 
    >>  Hi Tom, +Juergen, netmod WG,
    >> 
    >>  I think the question you ought to be asking is whether the base IPv4 and IPv6 address types should be modified to NOT include the zone and the zone versions should be added as a separate YANG type.
    >> 
    >>  The RFC 6991 is under revision now:
    >> 
    >>  https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6991-bis/
    >> 
    >>  However, I'm not sure if the painful backward compatibility discussions could be overcome.  We'd also have to admit that it was a big mistake to include the zone in the base addresses. In any case, I don't think we just start using the no-zone types when the base addresses types are used everywhere.
    >> 
    >>  <tp>
    >> 
    >>  Well, there are plenty of uses of the no-zone types as well, so some authors, some YANG doctors, have made the conscious choice to use them.  I cannot do a search just now but I see no-zone in the dhc and I2NSF WG I-Ds, and there are others.
    >> 
    >>  Also, some authors want the zone information as part of their leaf.
    >> 
    >>  Tom Petch
    >> 
    >>  Thanks,
    >>  Acee
    >> 
    >> 
    >> 
    >>  On 4/4/22, 7:11 AM, "Lsr on behalf of tom petch" <[email-masked] on behalf of [email-masked]> wrote:
    >> 
    >>      I assume that this is a refresh while waiting for ospf.yang to wind its way through the system
    >> 
    >>      I wonder if the ip address should be the no-zone variant from RFC6991 - I never know the answer to that so keep asking.
    >> 
    >>      Some time the contact needs updating to https://datatracker and the TLP to 'Revised'
    >> 
    >>      Tom Petch
    >> 
    >>      ________________________________________
    >>      From: Lsr <[email-masked]> on behalf of [email-masked] <[email-masked]>
    >>      Sent: 07 March 2022 03:14
    >>      To: [email-masked]
    >>      Cc: [email-masked]
    >>      Subject: [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
    >> 
    >> 
    >>      A New Internet-Draft is available from the on-line Internet-Drafts directories.
    >>      This draft is a work item of the Link State Routing WG of the IETF.
    >> 
    >>              Title          : YANG Model for OSPFv3 Extended LSAs
    >>              Authors        : Acee Lindem
    >>                                Sharmila Palani
    >>                                Yingzhen Qu
    >>              Filename        : draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
    >>              Pages          : 29
    >>              Date            : 2022-03-06
    >> 
    >>      Abstract:
    >>          This document defines a YANG data model augmenting the IETF OSPF YANG
    >>          model to provide support for OSPFv3 Link State Advertisement (LSA)
    >>          Extensibility as defined in RFC 8362.  OSPFv3 Extended LSAs provide
    >>          extensible TLV-based LSAs for the base LSA types defined in RFC 5340.
    >> 
    >> 
    >>      The IETF datatracker status page for this draft is:
    >>      https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/
    >> 
    >>      There is also an htmlized version available at:
    >>      https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-extended-lsa-yang-10
    >> 
    >>      A diff from the previous version is available at:
    >>      https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospfv3-extended-lsa-yang-10
    >> 
    >> 
    >>      Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
    >> 
    >> 
    >>      _______________________________________________
    >>      Lsr mailing list
    >>      [email-masked]
    >>      https://www.ietf.org/mailman/listinfo/lsr
    >> 
    >>      _______________________________________________
    >>      Lsr mailing list
    >>      [email-masked]
    >>      https://www.ietf.org/mailman/listinfo/lsr
    >> 
    >> 
    >> _______________________________________________
    >> Lsr mailing list
    >> [email-masked]
    >> https://www.ietf.org/mailman/listinfo/lsr
    > 
    >

---

From: tom petch <[email-masked]>
Date: Mon, 11 Apr 2022 09:13:26 +0000

From: Lsr <[email-masked]> on behalf of Reshad Rahman <reshad=[email-masked]>
Sent: 10 April 2022 21:42

Inline.

Hi Chris (as WG member),

On 4/5/22, 10:47 AM, "Christian Hopps" <[email-masked]<mailto:[email-masked]>> wrote:

    > On Apr 5, 2022, at 09:48, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
    >
    > [wg-member]
    >

    [as wg-member]

Actually this is a very bad idea. We don't want to endorse the error in RFC 6991 that could be fixed in the BIS document. I'm certainly not going to change the documents I authored when the world expects an IP address to not include a zone. I sent an Email to the RFC 9127 BIS (which is currently in IESG review) authors about this issue and apparently they agree with me as they chose not to respond.
<RR>
Just way behind on IETF emails. I can't speak for the other authors but I don't agree (too late). But I think we should make the change in 9127-bis. And follow current guidelines, as others have mentioned, to tackle what's in 6991-bis.

<tp>

That is the I-D that has just been approved by the IESG!

I do wonder about BFD.  Single hop IPv6 would seem to be a case for link local even if RFC5881 has a SHOULD NOT for using link local; and IPv6 link local is where the zone may be needed to identify the interface. RFC5881 does not mention zones.

Tom Petch

Regards,
Reshad.

Thanks,

Acee

    Thanks,
    Chris.
    [wg-member]

    > Thanks,
    > Acee
    >
    > On 4/5/22, 9:33 AM, "Christian Hopps" <[email-masked]<mailto:[email-masked]>> wrote:
    >
    >> On Apr 4, 2022, at 12:30, Acee Lindem (acee) <acee=[email-masked]<mailto:[email-masked]>> wrote:
    >>
    >> On 4/4/22, 11:55 AM, "tom petch" <[email-masked]<mailto:[email-masked]>> wrote:
    >>
    >>  From: Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>
    >>  On 4/4/22, 7:11 AM, "Lsr on behalf of tom petch" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:
    >>
    >>      From: Lsr <[email-masked]<mailto:[email-masked]>> on behalf of [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
    >>      To: [email-masked]<mailto:[email-masked]>
    >>      Cc: [email-masked]<mailto:[email-masked]>
    >>      [email-masked]<mailto:[email-masked]>
    >>      [email-masked]<mailto:[email-masked]>
    >> [email-masked]<mailto:[email-masked]>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 11 Apr 2022 15:03:55 +0000

See inline. 

On 4/11/22, 5:13 AM, "tom petch" <[email-masked]> wrote:

    Inline.

    Hi Chris (as WG member),

        [as wg-member]

    <tp>

[Acee]
This is probably better discussed on the BFD list but since single-hop BFD is by YANG definition scoped to a single interface, there is no use for zone index independent of the usage of link-local addresses. In fact, no one has been able to point to an implementation of textual convention usage in product configuration. The introduction of zones in RFC 4007 is an interesting but unused esoteric feature. The incorporation of zone in the base RFC 6991 IP address types and the reluctance to fix it is a travesty.  

Acee
[Acee] 

    Tom Petch

    Regards,
    Reshad.

    Thanks,

    Acee

        Thanks,
        Chris.
        [wg-member]

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 11 Apr 2022 17:06:47 +0000

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.

Regards,
Rob

> From: netmod <[email-masked]> On Behalf Of Randy Presuhn
> Sent: 08 April 2022 18:59
> To: Christian Hopps <[email-masked]>
> Cc: [email-masked]; [email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Mon, 11 Apr 2022 10:28:14 -0700

On Mon, Apr 11, 2022 at 10:07 AM Rob Wilton (rwilton) <rwilton=
[email-masked]> 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
>
> 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.
>
> 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:
>
> - 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.
>
> (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.

Andy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 11 Apr 2022 13:43:56 -0400

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=[email-masked] <mailto:[email-masked]>> 
> 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
> 
>     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.
> 
>     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:
> 
>     - 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.
> 
>     definition of ip-address to match ip-address-no-zone and deprecate
>     the "-no-zone" version at the same time.
> 
>     (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).
> 
>      > From: netmod <[email-masked]
>     <mailto:[email-masked]>> On Behalf Of Randy Presuhn
>      > To: Christian Hopps <[email-masked] <mailto:[email-masked]>>
>      > Cc: [email-masked] <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>
>     <https://www.ietf.org/archive/id/draft-ietf-mpls-mldp-yang-10.txt>
>      > [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/netmod>
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/netmod>
> 
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 12 Apr 2022 00:53:35 +0000

Speaking as WG member inline.

From: netmod <[email-masked]> on behalf of Andy Bierman <[email-masked]>
Date: Monday, April 11, 2022 at 1:28 PM
To: "Rob Wilton (rwilton)" <rwilton=[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

On Mon, Apr 11, 2022 at 10:07 AM Rob Wilton (rwilton) <rwilton=[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

I agree. I think waiting two years is a good compromise.

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'?

Given that clients aren’t sending zones, I’d just use the real ip-address types. At least for Cisco IOS-XE (which is very widely deployed and uses the inet:ip-address, inet:ipv4-address, and inet:ipv6-address types), we don’t support zone index and haven’t had complaints.

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.

This is a good suggestion.

Thanks,
Acee

Regards,
Rob

Andy

> From: netmod <[email-masked]<mailto:[email-masked]>> On Behalf Of Randy Presuhn
> To: Christian Hopps <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

---

From: Yingzhen Qu <[email-masked]>
Date: Mon, 11 Apr 2022 22:25:58 -0700

Hi Rob,

Thanks for the thoughtful proposal, and I support it.

One thing to confirm, for models that may become RFCs in the next two years and where the IP address doesn’t support zones, "ip-address” should still be used. Correct?

Thanks,
Yingzhen

> On Apr 11, 2022, at 10:06 AM, Rob Wilton (rwilton) <rwilton=[email-masked]> wrote:
> 
> Hi all,
> 
>> From: netmod <[email-masked] <mailto:[email-masked]>> On Behalf Of Randy Presuhn
>> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/lsr <https://www.ietf.org/mailman/listinfo/lsr>

---

From: Christian Hopps <[email-masked]>
Date: Tue, 12 Apr 2022 01:44:30 -0400

Nice. I think this a fine way forward with or without step 2. I say leave out the 2 years (or any) deadline, and let people argue over how and when to do step 2 for however long it takes.

Given the questions already raised on this thread, we should probably add explicit guidance to RFC6991-bis for new modules.

All new modules should:

   - Use `X` in place of `X-no-zone`
   - Use `X-zone` in place of `X` if zone info wanted
   - In the module description indicate that `{ip,ipv4,ipv6}-address` use conforms to the guidance in RFC (6991-bis)

Thanks,
Chris.

> Hi all,

....

> 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.
> (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

---

From: Jürgen Schönwälder <[email-masked]>
Date: Tue, 12 Apr 2022 09:02:22 +0200

On Mon, Apr 11, 2022 at 01:43:56PM -0400, Joel M. Halpern wrote:
> changing ip-address itself seems a bad idea.  If one means no-zone, use the
> -no-zone typedef.
>

I agree. What do we gain by breaking things in two years given that
there is no effective way to tell people that they will have a problem
in two years? Even in the IETF, I am not sure whether we are ready to
republish relevant RFCs during this two year window. And since we are
at it, ietf-inet-types also has this definition:

  typedef host {
    type union {
      type inet:ip-address;
      type inet:host-name;
    }
    // ..
  }

This host type is used in other places in combination with a port
number to denote transport endpoints and it should be clear why having
zone indexes in here is necessary to work with link-local transport
endpoints. Sure, we can change this to use inet:ip-address-with-zone,
but it is no unlikely that there are other places we do not have
control over and where a 2 year time window does effectively mean a
big surprise two years later.

Apparently, people do not read the description of types. Why would
they read scheduled deprecation warnings?

For me, the only sensible option (other than accepting that types are
named the way they are) is to introduce ip-address-with-zone and to
deprecate ip-address and stop there. Yes, this means coexistance of
inet:ip-address and ip-address-with-zone until YANG is getting
replaced.

/js

---

From: Martin Björklund <[email-masked]>
Date: Tue, 12 Apr 2022 09:25:37 +0200 (CEST)

Hi,

Here's another suggestion.  We keep the ip-address pattern as is, but
document in the description that implementations do not have to
support the optional zone index.  This would essentially document the
behavior of most current implementations.  (This is actually what I
suggested in the earliest thread on this topic that I could find:
https://mailarchive.ietf.org/arch/msg/netmod/KjHGtPqm9D4Q-fRb2hVsf4sPuCU)

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 12 Apr 2022 01:54:14 -0700

> https://mailarchive.ietf.org/arch/msg/netmod/KjHGtPqm9D4Q-fRb2hVsf4sPuCU)

The point of the 2 year warning is to allow anybody using ip-address
and really wants a zone index to move to the (new)
ip-address-with-zone typedef instead.
It has yet to be shown that this subset is not empty.

This is better than making an NBC change with no warning.
If people did not bother to read the typedef, why would they read the
warning?
This is also true, but no different than C programmers who ignore gcc
warnings.

Is the NBC change needed at all? Maybe not.
It would be better in the long term to align with OpenConfig and with 99 -
100%
of the implementations. The standards are a means to an end. Nothing more.
If 99 - 100% of the implementations are already doing what is needed,
then it would be a bad idea to disrupt that for the sake of standards
purity.

Andy

> > 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.
> >
> > 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
> 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
> > 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.
> where the "ip-address" type means what 99% of people expect it to mean,
> i.e., excluding zone information.
> >
> > - Although the type allows for zone information, many implementations
> are unlikely to accept zone information in most scenarios (i.e., so the

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 12 Apr 2022 10:43:39 +0000

From: netmod <[email-masked]> on behalf of Andy Bierman <[email-masked]>
Date: Tuesday, April 12, 2022 at 4:54 AM
To: Martin Björklund <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, NetMod WG <[email-masked]>, Robert Wilton <rwilton=[email-masked]>
Subject: Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

On Tue, Apr 12, 2022 at 12:26 AM Martin Björklund <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

The point of the 2 year warning is to allow anybody using ip-address
and really wants a zone index to move to the (new) ip-address-with-zone typedef instead.
It has yet to be shown that this subset is not empty.

This is better than making an NBC change with no warning.
If people did not bother to read the typedef, why would they read the warning?
This is also true, but no different than C programmers who ignore gcc warnings.

Is the NBC change needed at all? Maybe not.
It would be better in the long term to align with OpenConfig and with 99 - 100%
of the implementations. The standards are a means to an end. Nothing more.
If 99 - 100% of the implementations are already doing what is needed,
then it would be a bad idea to disrupt that for the sake of standards purity.

I agree totally. What advantage do we gain but not making the pattern correct other than not having to admit it was wrong in the first place?

Thanks,
Acee

/martin

Andy

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 12 Apr 2022 13:24:29 +0000

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-masked] on behalf of [email-masked]> wrote:

    Yours,
    Joel

---

From: Kent Watsen <[email-masked]>
Date: Tue, 12 Apr 2022 14:44:38 +0000

> inet:ip-address and ip-address-with-zone until YANG is getting

As a contributor, this seems to be the most reasonable "by the rules" option.  There's nothing wrong with introducing a more-explicit label and deprecating a less-explicit label.   Having more explicit labels seems to be general goodness (e.g., more readable tree-diagrams) while not impacting CLI usability.  Deprecating less-explicit labels enables tooling to move existing non-explicit label uses to the more-explicit labels.  

It is easy to empathize with those seeing this as a bug-fix, but there's no clean way to assume a particular definition is what was universally intended and used.  It's additionally difficult to support an approach that breaks the rules that we are charged to defend.

Level-upping, is there any takeaway modeling advice coming out of this?  There's a historical trend to define base types with a broad value-space assuming uses will refine the value space as needed.  This trend seems well-reasoned, and yet here we are. Should there be advice indicating that if a value space is faceted, a union of more-explicit types is better (e.g., inet:host)?  If there is a type that is the union of "-with-zone" and "-without-zone", would it better to call it "ip-address-with-or-without-zone" or just "ip-address"?  [PS: I'm assuming that -with-zone" requires a zone, i.e., it's not optional]

PS: As a chair, consensus seems elusive.   Roughly 10 people have provided opinions with a nearly 50/50 split between the "follow the rules" and "do what's 'right'" camps.

K.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 12 Apr 2022 10:47:21 -0400

Juergen posted an example of where ip-address is used and zones are 
expected.

Yours,
Joel

---

From: Martin Björklund <[email-masked]>
Date: Tue, 12 Apr 2022 16:52:41 +0200 (CEST)

Jürgen Schönwälder <[email-masked]> wrote:

[...]

> inet:ip-address and ip-address-with-zone until YANG is getting

But then what would you do with inet:host?

/martin

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 12 Apr 2022 14:54:16 +0000

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" <[email-masked]> wrote:

    Yours,
    Joel

---

From: Jürgen Schönwälder <[email-masked]>
Date: Tue, 12 Apr 2022 17:05:58 +0200

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 12 Apr 2022 15:10:12 +0000

Jürgen - I'm not sure how you could extrapolate the basic requirement for IPv6 link-local addresses to support for YANG configuration support of link-local addresses with zone indexes... 

Acee

On 4/12/22, 11:06 AM, "Jürgen Schönwälder" <[email-masked]> wrote:

    Acee,

    /js

---

From: Jürgen Schönwälder <[email-masked]>
Date: Tue, 12 Apr 2022 17:18:22 +0200

> But then what would you do with inet:host?

I would define ip-address-with-zone to be the same as ip-address
(i.e., with an optional zone index) and then I would then use
ip-address-with-zone instead of ip-address in inet:host (like we are
all going to replace the deprecated ip-address with either
ip-address-with-zone or ip-address-no-zone in all modules in the
future to avoid depending on a deprecated definition).

It does not make sense to me to have a type mandating a zone since on
all systems I know of the zone index shows up only when needed (and
creating yet another union seems overkill).

/js

PS: I guess someone will propose to use ip-address-opt-zone instead
    ip-address-with-zone. ;-)

---

From: Jürgen Schönwälder <[email-masked]>
Date: Tue, 12 Apr 2022 17:53:03 +0200

> Jürgen - I'm not sure how you could extrapolate the basic requirement for IPv6 link-local addresses to support for YANG configuration support of link-local addresses with zone indexes... 

I would be surprised if the IETF decides to produce data models that
by design do not work with link-local addresses.

System level tools these days do this well as do an increasing number
of server configurations files. On Debian 11.3, you can ping, ssh, nc,
... to 'fe80::c101:c4e0:aab5:5a04%vlan5'. You can put a link-local IP
address with a zone index into your /etc/resolv.conf. In YANG, the
equivalent is in RFC 7317:

      +--rw system
         +--rw dns-resolver
            +--rw search*    inet:domain-name
            +--rw server* [name]
            |  +--rw name    string
            |  +--rw (transport)
            |     +--:(udp-and-tcp)
            |        +--udp-and-tcp
            |           +--rw address    inet:ip-address
            |           +--rw port?      inet:port-number
            +--rw options
               +--rw timeout?    uint8
               +--rw attempts?   uint8

The intention 10+ years ago was to provide a type that enables authors
to write YANG data models that can be used with addresses that require
a zone index. At that time, system level tools hardly got this done
right or consistently. System level tools have improved. Perhaps it
takes some additional tim for YANG implementations to follow on.

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 12 Apr 2022 11:18:39 -0700

On Tue, Apr 12, 2022 at 7:45 AM Kent Watsen <[email-masked]> wrote:

> As a contributor, this seems to be the most reasonable "by the rules"
> option.  There's nothing wrong with introducing a more-explicit label and
> deprecating a less-explicit label.   Having more explicit labels seems to
> be general goodness (e.g., more readable tree-diagrams) while not impacting
> CLI usability.  Deprecating less-explicit labels enables tooling to move
> existing non-explicit label uses to the more-explicit labels.
>
> It is easy to empathize with those seeing this as a bug-fix, but there's
> no clean way to assume a particular definition is what was universally
> intended and used.  It's additionally difficult to support an approach
> that breaks the rules that we are charged to defend.
>
> Level-upping, is there any takeaway modeling advice coming out of this?
> There's a historical trend to define base types with a
> broad value-space assuming uses will refine the value space as needed.
> This trend seems well-reasoned, and yet here we are. Should there be advice
> indicating that if a value space is faceted, a union of more-explicit types
> is better (e.g., inet:host)?  If there is a type that is the union of
> "-with-zone" and "-without-zone", would it better to call it
> "ip-address-with-or-without-zone" or just "ip-address"?  [PS: I'm assuming
> that -with-zone" requires a zone, i.e., it's not optional]
>
> PS: As a chair, consensus seems elusive.   Roughly 10 people have provided
> opinions with a nearly 50/50 split between the "follow the rules" and "do
> what's 'right'" camps.
>
>
One extreme is to say "the typedef says what it is. Too bad you have to
rewrite 100s of YANG modules."

The other extreme is to say "Nobody supports the zone index, so change the
typedef to match
what the users actually want, right now."

The middle ground is to say "Nobody is reporting a bug that their client is
setting a zone index
and our server is doing the wrong thing, so there is no real problem to
solve here".

The compromise is to say "You have 2 years to change to a new typedef if you
really need a zone index."

Perhaps nobody is right.
Perhaps there is only a least worst solution and no good solution.
There is not enough objective criteria to pick the best one.

 Andy

---

From: Martin Björklund <[email-masked]>
Date: Wed, 13 Apr 2022 10:44:33 +0200 (CEST)

> future to avoid depending on a deprecated definition).

But if people believe that we have a big problem that ip-address may
contain a zone index, don't we have the same problem w/ inet:host?
Don't we have to deprecate also inet:host for the same reason?

(To be clear: Personally, I do not think that deprecating these
typedefs is the best solution)
 
> creating yet another union seems overkill).

Did anyone suggest this?  I thought ip-address-with-zone was supposed to be
exactly what ip-address is today.

/martin

---

From: tom petch <[email-masked]>
Date: Wed, 13 Apr 2022 09:22:03 +0000

From: netmod <[email-masked]> on behalf of Rob Wilton (rwilton) <rwilton=[email-masked]>
Sent: 11 April 2022 18:06

Hi all,

<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 the plan below is a bad one.  I would introduce types with zone - that is a no-brainer - but would deprecate the existing types.

Tom Petch

Regards,
Rob

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 13 Apr 2022 09:44:34 +0000

Hi Tom,

Please see inline ...

> Sent: 13 April 2022 10:22
> To: Rob Wilton (rwilton) <[email-masked]>; [email-masked];
> [email-masked]
> From: netmod <[email-masked]> on behalf of Rob Wilton
> (rwilton) <rwilton=[email-masked]>
> 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
> 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

> 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.
> 
> 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.
> 
> 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.
> 
> intention of supporting zoned IP addresses MUST migrate to ip-address-with-
> zone.
> 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.
>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 13 Apr 2022 09:41:08 -0700

> given to the unusual variant of including zone information.

The core issue: how important is it to have the typedefs align with user
expectations?
The reason the ip-address typedef has been misused is because most people
thought they knew
what an IP address was already.  They thought the 1000s of examples of IP
addresses they had seen
were enough. They copied "inet:ip-address" from another YANG module they
found, never even reading ietf-inet-types.yang.

There are lots of different SDOs creating YANG modules. Not just IETF and
OpenConfig.
Vendors need to deal with the integration themselves.
Misalignment at the data type level, especially something as important as
ip-address, is causing problems.

Pretending the data types are aligned is not an optimal solution.
Churning 100 or so YANG modules to use ip-address-no-zone is easier said
than done.
IMO this is the hardest proposal to execute.

Andy

> 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 the plan below is a bad one.  I would introduce types with
> zone - that is a no-brainer - but would deprecate the existing types.
>
> Tom Petch
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 13 Apr 2022 22:02:32 +0000

From: netmod <[email-masked]> on behalf of Andy Bierman <[email-masked]>
Date: Wednesday, April 13, 2022 at 12:43 PM
To: tom petch <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "Rob Wilton (rwilton)" <rwilton=[email-masked]>
Subject: Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

On Wed, Apr 13, 2022 at 2:22 AM tom petch <[email-masked]<mailto:[email-masked]>> wrote:
From: netmod <[email-masked]<mailto:[email-masked]>> on behalf of Rob Wilton (rwilton) <rwilton=[email-masked]<mailto:[email-masked]>>
Sent: 11 April 2022 18:06

Hi all,

The core issue: how important is it to have the typedefs align with user expectations?
The reason the ip-address typedef has been misused is because most people thought they knew
what an IP address was already.  They thought the 1000s of examples of IP addresses they had seen
were enough. They copied "inet:ip-address" from another YANG module they found, never even reading ietf-inet-types.yang.

There are lots of different SDOs creating YANG modules. Not just IETF and OpenConfig.
Vendors need to deal with the integration themselves.
Misalignment at the data type level, especially something as important as ip-address, is causing problems.

Pretending the data types are aligned is not an optimal solution.
Churning 100 or so YANG modules to use ip-address-no-zone is easier said than done.
IMO this is the hardest proposal to execute.

I totally agree. It is 2022 now and the world has evolved to be all about experiences. The NETMOD WG should be more concerned about the IETF YANG experience than our pedantic backward compatibility rules. Don’t get me wrong, these have their place but as Andy has articulated, in this case everyone expects the ip-address types to be the ip-addresses we all know and love. Are we going to let them down? I certainly hope not!!!

Thanks,
Acee

Andy

<tp>

Tom Petch

Regards,
Rob

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 13 Apr 2022 22:30:59 +0000

On Apr 13, 2022, at 3:02 PM, Acee Lindem (acee) <acee=[email-masked]<mailto:acee=[email-masked]>> wrote:

From: netmod <[email-masked]<mailto:[email-masked]>> on behalf of Andy Bierman <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, April 13, 2022 at 12:43 PM
To: tom petch <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Rob Wilton (rwilton)" <rwilton=[email-masked]<mailto:rwilton=[email-masked]>>
Subject: Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

Hi all,

I support this approach. It is not ideal, and I am sure we all wish we did not find ourselves in this situation, but the aligning with user expectations and common practice seems the best way forward to me. I would also like to see liaisons statements summarizing the plan sent to the other standards orgs and industry consortiums and use IETF YANG models.

Cheers,
Charles

Thanks,
Acee

Andy

<tp>

Tom Petch

Regards,
Rob

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 14 Apr 2022 12:48:25 +0000

Hi Martin,

I have several concerns with this approach:

(1) I still think that the ip-address type name still ends up being non-intuitive (especially for zoned IPv4 addresses - I would be surprised to find that there is any deployment for these at all).  I.e., the evidence seems to suggest that when engineers think of IP addresses, they don't seem to generally think of zoned IP addresses.  I doubt that any fiddling of the type description is going to change that perception, not least when the definition is different for OpenConfig and in vendors models and ip-address is widely used in many published YANG models.

(2) It means that clients of YANG models using the ip-address type have no idea whether the server will support zones without either trying the configuration (which could subsequently become unsupported in the future) or requiring an out-of-band discussion with the device vendor.  For such as basic type this doesn't seem great.

(3) For IETF models, does that mean that new models should use ip-address-no-zone, and that we should change the approx. 200 usages in 40-50 published RFCs?  As mentioned previously, this doesn't seem pragmatic, or it will take the best part of a decade to happen.  During that time the difference between ip-address , ip-address-with-zone, and ip-address-no-zone will probably cause even further confusion due to the ambiguity, and differences in implementations.

(4) For NMDA models, it means that clients could (but probably never will) receive zoned ip addresses back from <operational>.  Further, if zoned IP addresses are returned, then they are expected to use numerical IDs for the zones, which seem to be effectively opaque to the client (other than uniqueness).  Clients seem to have a few choices: ignore (error?) on zoned IP addresses, ignore the zone (does that make sense), or have additional code to handle a case that for 99% of users will probably never happen.  My point being that these is also a cost to keeping support for zones in the base ip-address types.

Regards,
Rob

> From: Martin Björklund <[email-masked]>
> Sent: 12 April 2022 08:26
> To: Rob Wilton (rwilton) <[email-masked]>
> Cc: [email-masked]; [email-masked]
> At a quick guess/check it looks like these 49 YANG modules may appear in 40-
> 50 RFCs.
> >
> 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.
> 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.
> >
> > 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
> definition of ip-address to match ip-address-no-zone and deprecate the "-no-
> zone" version at the same time.
> >

---

From: Jürgen Schönwälder <[email-masked]>
Date: Thu, 14 Apr 2022 15:22:00 +0200

> Don't we have to deprecate also inet:host for the same reason?

The problem is with the name of the ip-address type. I assume people
might even be happy that a (host, port-number) tupe behaves as many
applications around us do.
 
> exactly what ip-address is today.

This is how I understood Kent.

/js

---

From: Martin Björklund <[email-masked]>
Date: Thu, 14 Apr 2022 15:23:31 +0200 (CEST)

Hi,

First of all, I agree that if we were to design this from scratch, I
think we should have a type for just an ip address, and use a second
leaf for the zone (or interface).

"Rob Wilton (rwilton)" <[email-masked]> wrote:
> (1) I still think that the ip-address type name still ends up being
> non-intuitive

Agreed.

> (especially for zoned IPv4 addresses - I would be
> surprised to find that there is any deployment for these at all).

Maybe, I have no idea.  What I *do* know is that lots of users
(probably most users) of YANG modules are not active in the IETF.

> I.e., the evidence seems to suggest that when engineers think of IP
> addresses, they don't seem to generally think of zoned IP addresses.
> I doubt that any fiddling of the type description is going to change
> that perception, not least when the definition is different for
> OpenConfig and in vendors models and ip-address is widely used in many
> published YANG models.
> 
> (2) It means that clients of YANG models using the ip-address type
> have no idea whether the server will support zones without either
> trying the configuration (which could subsequently become unsupported
> in the future) or requiring an out-of-band discussion with the device
> vendor.  For such as basic type this doesn't seem great.

But this is what we have had for 12 years, and from what I know we
haven't seen any real issues with this.

> (3) For IETF models, does that mean that new models should use
> ip-address-no-zone, and that we should change the approx. 200 usages
> in 40-50 published RFCs?  As mentioned previously, this doesn't seem
> pragmatic, or it will take the best part of a decade to happen.
> During that time the difference between ip-address ,
> ip-address-with-zone, and ip-address-no-zone will probably cause even
> further confusion due to the ambiguity, and differences in
> implementations.

No, the pragmatic solution I propose is to only change the description
of ip-address (and v4/v6) to match current implementations; i.e., make
it clear that an implementation doesn't have to support the optional
zone index.

Not ideal, but this is what is implemented and it seems to work.

/martin

> (4) For NMDA models, it means that clients could (but probably never
> will) receive zoned ip addresses back from <operational>.  Further, if
> zoned IP addresses are returned, then they are expected to use
> numerical IDs for the zones, which seem to be effectively opaque to
> the client (other than uniqueness).  Clients seem to have a few
> choices: ignore (error?) on zoned IP addresses, ignore the zone (does
> that make sense), or have additional code to handle a case that for
> 99% of users will probably never happen.  My point being that these is
> also a cost to keeping support for zones in the base ip-address types.
> 
> Regards,
> Rob
> 
> 
> 
> > > are
> > > v4/v6
> > > most
> > > As mentioned previously, it is also worth comparing this to the
> > > OpenConfig
> > YANG modules:
> > ietf-inet-
> > > same way
> > > is
> > implement
> > > are
> > > at all
> > > where the "ip-
> > > (i) define new ip-address-with-zone types (and v4 and v6 versions) and
> > > keep
> > the -no-zone versions.
> > > - are
> > description
> > ip-address-with-
> > > (2) It ends up with the right definition (with the added bonus that it
> > > aligns
> > to the OC definition).
> > > NBC

---

From: Jürgen Schönwälder <[email-masked]>
Date: Thu, 14 Apr 2022 15:47:30 +0200

> leaf for the zone (or interface).

The notation 'fe80::4d9:ff04:4fa6:7980%en0' is widely supported in
application space. The IPv6 working group has a recurring debate on
the usage of zoned IPv6 address in URLs [1], where the debate is about
the question whether the % needs to be escaped or not. I do not know
where the latest iteration stopped, but details can be found in RFC
6874 and draft-carpenter-6man-rfc6874bis-03.

Philip Homburg's RIPE Labs note [2] might also be an interesting
read. According to this, getaddrinfo() actually deals with zoned
addresses (and hence even data model implementation that pass data to
getaddrinfo() to obtain socket addresses may do the right thing.)

My view is that down in the network layer models, you often know the
interface by context and ipv6-address-no-zone is sufficient. If you go
to application space, you really want "ipv6-address-with-zone" by
default in order to support link-local addresses.

/js

[1] http://[fe80::4d9:ff04:4fa6:7980%en0]/

[2] https://labs.ripe.net/author/philip_homburg/whats-the-deal-with-ipv6-link-local-addresses/

---

From: Martin Björklund <[email-masked]>
Date: Thu, 14 Apr 2022 16:03:45 +0200 (CEST)

I thought the discussion was only about ipv4?

/martin

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 14 Apr 2022 15:00:03 +0000

While RFC 4001 really didn't need to extend the zone index to IPv4, the conversation also pertains to IPv6 address types. At least RFC 4001 got it right by not making the zone index part of the default types and defining ipv4z and ipv6z. 

Thanks,
Acee

On 4/14/22, 10:04 AM, "Lsr on behalf of Martin Björklund" <[email-masked] on behalf of [email-masked]> wrote:

    /martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 14 Apr 2022 09:23:38 -0700

On Thu, Apr 14, 2022 at 8:01 AM Acee Lindem (acee) <acee=
[email-masked]> wrote:

> While RFC 4001 really didn't need to extend the zone index to IPv4, the
> conversation also pertains to IPv6 address types. At least RFC 4001 got it
> right by not making the zone index part of the default types and defining
> ipv4z and ipv6z.
>
>
So is this a correct summary:

 - zone index is not used in IPv4 at all
 - zone index is not configured by a client in IPv6 at all
 - zone index is assigned by the system (as needed) to IPv6 link-local
addresses

I want to add a server option in our code to always reject (or alter)
an edit that contains a zone index.  I need to know the consensus on
whether it is OK to ignore a zone index from a client.
Nothing in RFC 6241 suggests that this is OK for <edit-config>.

Thanks,
Andy

> On 4/14/22, 10:04 AM, "Lsr on behalf of Martin Björklund" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>     > [2]
> https://labs.ripe.net/author/philip_homburg/whats-the-deal-with-ipv6-link-local-addresses/
>     >
>     > --

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 14 Apr 2022 17:04:49 +0000

Hi Andy,

From: Andy Bierman <[email-masked]>
Date: Thursday, April 14, 2022 at 12:24 PM
To: Acee Lindem <[email-masked]>
Cc: Martin Björklund <[email-masked]>, Juergen Schoenwaelder <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

On Thu, Apr 14, 2022 at 8:01 AM Acee Lindem (acee) <acee=[email-masked]<mailto:[email-masked]>> wrote:
While RFC 4001 really didn't need to extend the zone index to IPv4, the conversation also pertains to IPv6 address types. At least RFC 4001 got it right by not making the zone index part of the default types and defining ipv4z and ipv6z.

I’d be fairly certain that this is the case.

Nobody can point to any clients. However, Jürgen has pointed out that there are Linux files and commands that accept a link-local addresses with a zone. Conceivably, one could extrapolate this to a YANG model.

Thanks,
Acee

 - zone index is assigned by the system (as needed) to IPv6 link-local addresses

Thanks,
Acee

Andy

On 4/14/22, 10:04 AM, "Lsr on behalf of Martin Björklund" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

    /martin

---

From: Jürgen Schönwälder <[email-masked]>
Date: Thu, 14 Apr 2022 21:38:36 +0200

>  - zone index is not used in IPv4 at all

There are link-local IPv4 addresses, they are less wide-spread since
IPv4 stacks generally do not auto-configure IPv4 link-local addresses.
Nobody will be able to confirm "not used at all", this questions is
somewhat rhetoric since nobody can answer it.

>  - zone index is not configured by a client in IPv6 at all

Configuring zone indexes is required in many cases to reach services
that are only reachable via link-local addresses. I mentioned the DNS
resolver example and this applies to pretty much any transport layer
endpoint. This is why by design (and not by accident) the with zone
version of ip-address is used in the inet:host typedef.

>  - zone index is assigned by the system (as needed) to IPv6 link-local

A link-local address exists on a link and as such does not need a zone
index as long it is used on the link. However, when you want to refer
to a link-local address on a system with more than one link, then the
link-local address is ambiguous and to disambiguate things you either
specify in adding the interface to be used or you embed the zone index
in the address. Since application code usually assumes that a
transport address is an (ip-address, port) tuple, people converged on
adding the zone to the ip address (instead of rewriting all APIs to
use (ip-address, port, interface) tuples. The zoned IP address
notation is meanwhile widely supported. This is why we have, for
example, RFC 6874 (but the IPv6 folks have a reoccuring debate about
the question whether the % needs to be percent encoded or not,
draft-carpenter-6man-rfc6874bis-03).

> whether it is OK to ignore a zone index from a client.

It is your choice to design a product that will not work with
link-local addresses. For IETF data models, I expect that the bar is
higher and that people can expect that IETF data models are written to
also work with link-local addresses. If implementers than decide that
their users do not need to work with link-local addresses, so be it,
you can make your server reject the optional zone index. But others
can decide that they customers can also work with link-local
addresses. If we blindly remove the zone index from ip-address, then
the IETF would break data models for those who consider link-local
addresses a first class citizen.

> Nothing in RFC 6241 suggests that this is OK for <edit-config>.

I have no clue what you mean. If your server recceives a value that
your server does not support, you reject the value.

/js

PS: I recall the side meetings with IPv6 people to sort out how we add
    proper IPv6 support to MIB modules, which led to RFC 4001, which
    later influenced the YANG typedefs. Almost 20 years later (and
    IPv6 deployed at a much larger scale) I find myself in a
    discussion where people question that we need to support
    link-local addresses. This is very irritating.

    Apparently, getaddrinfo() implementations tend to handle zoned
    link-local addresses just fine and any code that passes a zoned ip
    address string to getaddrinfo() will likely return you a socket
    address with the sin6_scope_id filled in properly. You actually
    have to do extra work to prevent the right thing to happen if your
    code passes strings on to getaddinfo(). I am puzzled why people
    want to do this.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 14 Apr 2022 15:46:44 -0400

That does summary below does not match what others have said on this thread.

Yours,
Joel

On 4/14/2022 12:23 PM, Andy Bierman wrote:
> 
> 
> On Thu, Apr 14, 2022 at 8:01 AM Acee Lindem (acee) 
> <acee=[email-masked] <mailto:[email-masked]>> wrote:
> 
>     While RFC 4001 really didn't need to extend the zone index to IPv4,
>     the conversation also pertains to IPv6 address types. At least RFC
>     4001 got it right by not making the zone index part of the default
>     types and defining ipv4z and ipv6z.
> 
> 
>     On 4/14/22, 10:04 AM, "Lsr on behalf of Martin Björklund"
>     <[email-masked] <mailto:[email-masked]> on behalf of
>     [email-masked] <mailto:[email-masked]>> wrote:
> 
>          Jürgen Schönwälder <[email-masked]
>     <mailto:[email-masked]>> wrote:
>          > On Thu, Apr 14, 2022 at 03:23:31PM +0200, Martin Björklund wrote:
>          > > Hi,
>          > >
>          > > First of all, I agree that if we were to design this from
>     scratch, I
>          > > think we should have a type for just an ip address, and use
>     a second
>          > > leaf for the zone (or interface).
>          > >
>          >
>          > The notation 'fe80::4d9:ff04:4fa6:7980%en0' is widely
>     supported in
>          > application space. The IPv6 working group has a recurring
>     debate on
>          > the usage of zoned IPv6 address in URLs [1], where the debate
>     is about
>          > the question whether the % needs to be escaped or not. I do
>     not know
>          > where the latest iteration stopped, but details can be found
>     in RFC
>          > 6874 and draft-carpenter-6man-rfc6874bis-03.
>          >
>          > Philip Homburg's RIPE Labs note [2] might also be an interesting
>          > read. According to this, getaddrinfo() actually deals with zoned
>          > addresses (and hence even data model implementation that pass
>     data to
>          > getaddrinfo() to obtain socket addresses may do the right thing.)
>          >
>          > My view is that down in the network layer models, you often
>     know the
>          > interface by context and ipv6-address-no-zone is sufficient.
>     If you go
>          > to application space, you really want "ipv6-address-with-zone" by
>          > default in order to support link-local addresses.
>          >
>          > /js
>          >
>          > [1] http://[fe80::4d9:ff04:4fa6:7980%en0]/
>          >
>          > [2]
>     <https://labs.ripe.net/author/philip_homburg/whats-the-deal-with-ipv6-link-local-addresses/>
>          >
>          > --
>          > Jürgen Schönwälder              Jacobs University Bremen gGmbH
>          > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen
>     | Germany
>          > Fax:   +49 421 200 3103       
>       <https://www.jacobs-university.de/
>     <https://www.jacobs-university.de/>>
> 
>     <https://www.ietf.org/mailman/listinfo/lsr>
>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 14 Apr 2022 12:48:18 -0700

> addresses a first class citizen.
A server option is useful for an implementation that does not
support zone index configuration. It is an implementation detail so out of
scope.

The proposal is for a 2 year phase to change modules
that really do want a zone index.  It is not blindly removing the zone
index.

Andy

---

From: Jürgen Schönwälder <[email-masked]>
Date: Thu, 14 Apr 2022 22:13:04 +0200

> that really do want a zone index.  It is not blindly removing the zone

People not reading type definitions will also not read a warning
signs. This is blindly removing the zone index in two years, I hardly
see a difference from doing the same (damage) today.

Lets start with one of the oldest modules affected, RFC 7317. The
ietf-system module is using ip-address correctly (allowing DNS servers
to be reachable via link-local addresses). So who is going to revise
RFC 7317 in the two years? It would be strange to file an errata
addressing a problem that will break the module in two years from
now. In fact, there is no problem in RFC 7317, the problem is that we
break the YANG module update rules that protect YANG modules from
getting broken by updates to other YANG modules.

And we do all of this because the name ip-address in hindsight is
confusing?

As you pointed out, an implementer can choose to ignore the optional
zone index. However, if we remove the optional zone index, then
implementors have no choice anymore since the data model by design
prevents a meaningful implementation that works with link-local
addresses. The key is that we have to trust data model writers to pick
the right type. The assumption that every author who used ip-address
really wanted ip-address-no-zone is very wild idea.

/js (feeling lost in the modern software world)

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 14 Apr 2022 13:24:58 -0700

Hi -

> /js (feeling lost in the modern software world)

Total agreement.  I share your bewilderment that a standardization
organization would even consider deliberately breaking compatibility
to "fix" a non-problem, particularly a non-problem that has been widely
deployed for over a decade.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 14 Apr 2022 13:33:43 -0700

> see a difference from doing the same (damage) today.
A 2 year advance notice is way more than normal in the open source world.

There does not seem to be any consensus on the general issues or the
specific typedef,
or even agreement that OpenConfig (and RFC 4001) got it right and IETF got
it wrong.

One set of data models treats a zone index as the normal case, not the
exception,
and the other treats a zone index as the exception.

Spinning all the YANG modules that use these typedefs is not going to
happen,
and not even clear that would help with multi-SDO integration, given the
disconnect
on the design of the typedefs.

Andy

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 14 Apr 2022 13:41:10 -0700

Hi -

On 2022-04-14 1:33 PM, Andy Bierman wrote:
> 
> 
> On Thu, Apr 14, 2022 at 1:13 PM Jürgen Schönwälder 
> <[email-masked] 
> or even agreement that OpenConfig (and RFC 4001) got it right and IETF 
> got it wrong.
> 
...

Why do you believe it is necessary to revise all the YANG modules that
use the current typedefs?  Have any interoperability problems resulted
from the use of the current definitions?  The argument that not changing
the substance of the current definitions would somehow result in the
need to modify the modules that have used the current definitions is
a paper tiger, I think.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 14 Apr 2022 14:25:58 -0700

> need to modify the modules that have used the current definitions is

There seems to be many modules where ip-address was used
when the intention of the WG was to use ip-address-no-zone.

The easiest solution is to do nothing, and force the server implementers to
deal with it.
A server is obligated to check all client input.
Any request with a zone index can be rejected instead of accepted.
This solution is compatible with the OpenConfig typedef (unless zone index
actually used).

Andy

---

From: tom petch <[email-masked]>
Date: Fri, 15 Apr 2022 16:44:45 +0000

From: netmod <[email-masked]> on behalf of Andy Bierman <[email-masked]>
Sent: 14 April 2022 22:25

On Thu, Apr 14, 2022 at 1:41 PM Randy Presuhn <[email-masked]<mailto:[email-masked]>> wrote:
Hi -

On 2022-04-14 1:33 PM, Andy Bierman wrote:
> <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
...

<tp>
Well, we really do not know.  We do know that in the past two years or so, when the meaning of ip-address has been pointed out to YANG module authors, most, but not all, have changed to the no-zone format, suggesting that they were unfamiliar with the use of zones in IPv6.  But they may have got it wrong,  The flavour of RFC4007 is that from now on, all IPv6 addresses will include a zone in their representation but since that is mostly the default zone and the default zone can be omitted then we do not often see zones in the representation.  To quote RFC4007
' This is accomplished by assigning, within the node,
   a distinct "zone index" to each zone of the same scope to which that
   node is attached, and by allowing all internal uses of an address to
   be qualified by a zone index.
'
All internal uses! that is what an implementer should be doing with YANG or with anything else.

Tom Petch

Tom Petch

The easiest solution is to do nothing, and force the server implementers to deal with it.
A server is obligated to check all client input.
Any request with a zone index can be rejected instead of accepted.
This solution is compatible with the OpenConfig typedef (unless zone index actually used).

Randy

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 15 Apr 2022 11:12:41 -0700

On Fri, Apr 15, 2022 at 9:44 AM tom petch <[email-masked]> wrote:

> [email-masked]<mailto:[email-masked]>>
> wrote:
> Hi -
>
> > <mailto:[email-masked]<mailto:
> [email-masked]>>> wrote:
> >
> Well, we really do not know.  We do know that in the past two years or so,
> when the meaning of ip-address has been pointed out to YANG module authors,
> most, but not all, have changed to the no-zone format, suggesting that they
> were unfamiliar with the use of zones in IPv6.  But they may have got it
> wrong,  The flavour of RFC4007 is that from now on, all IPv6 addresses will
> include a zone in their representation but since that is mostly the default
> zone and the default zone can be omitted then we do not often see zones in
> the representation.  To quote RFC4007

I can support just "part 1" of the proposal.

Total solution:

 - provide guidelines for YANG authors and developers
    - base + options approach vs. full + without-options approach
    - ip-address vs. ip-address-no-zone

I retract support for my own previous suggestion of allowing the zone index
to be ignored. (!)
There should not be any special exceptions for a few typedefs.
RFC 6241 is very clear about the server requirements for returning <ok> for
an <edit-config>
request. No further comment in ietf-inet-types is needed.

Andy

---

From: Randy Presuhn <[email-masked]>
Date: Fri, 15 Apr 2022 12:25:12 -0700

Hi -

I took a fresh look at RFC 6991, and a couple of things that have
already been mentioned in this thread bear repetition.

(1) in both the ipv4-address and ipv6-address typdefs, the zone
is only optionally present.  This is made clear both in the
string patterns as well as the descriptions, which state that
it "may" be present, and clearly specify how its absence is
to be understood.  Thus it's no surprise that their use has not
caused any problems.  If the definitions go unchanged, there's
no demonstrated need for any of the existing uses of these typedefs
to be revised to employ something else, even if other typedefs
are available that are more precisely targeted.

(2) since both the ipv4-address and ipv6-address typdefs are
used in the ip-address typedef, which is in turn used in the
host typedef, any proposal changing the syntax or semantics
of ipv4-address or ipv6-address  needs to deal with the potential
collateral damage to any module (IETF or otherwise) employing
ip-address or host.

(3) since the proposed change is to narrow the syntax / semantics
of a typedef (along with any other typdefs that directly or indirectly
incorporate that typedef), the consequence for interoperability is
that some values go from "MAY reject" (such is the nature of Netconf
servers - well-formedness is not sufficient to guarantee that a server
will accept an attempt to apply a particular value to a configuration)
to "MUST reject" (due to the narrowed pattern and description).  This is
where stuff breaks.

(4) since ipv4-address-no-zone is derived from ipv4-address (by
narrowing the pattern), and ipv6-address-no-zone is likewise
derived from ipv6-address, the proposed change will also require
these typedefs to be changed, which will in turn bubble up to
ip-address-no-zone.

It still makes no sense to me to engage in making such wide-ranging
changes affecting both specifications and implementations with a real
risk to interoperability in order to "fix" a non-problem.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 15 Apr 2022 13:01:47 -0700

> these typedefs to be changed, which will in turn bubble up to
I have been using the term 'ip-address' for simplification.
I understand the actual edits are quite messy and apparently, not even
understood yet.

> risk to interoperability in order to "fix" a non-problem.
I agree that the current YANG standards do not allow for any significant
NBC change
to be introduced.  There is only "deprecate and start over with a new
identifier".
There are many components (YANG conformance, YANG import, YANG versioning,
etc.)
that need a lot more work to support "smart tooling" to fix (or at least
warn) users.

Randy

Andy