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

[Andy Bierman]

On Wed, Apr 27, 2022 at 11:04 AM Randy Presuhn <
randy_pres...@alumni.stanford.edu> wrote:

> Hi -
>
> I think you've just made the argument for taking no action at all.
> I do think that argument is more persuasive than the ones advanced so
> far for changing deployed typedefs, and think the "no action" proposal
> would be a reasonable compromise.
>
>

I think some clarifications in the typedefs count as a change.

It does not appear that a zone index for IPv4 exists anywhere.
If it does then that reference should be added to the typedef.

Almost none of the points found during this email discussion are
documented in the YANG module (e.g, use-cases for ip-address-no-zone).

It seems that ip-address is enough, and represents all possible
variants of an IP address.   Users do not care about typedefs, only
the data nodes that use them.  If the leaf is implemented correctly,
then there is no problem with the typedef.  The "no action" proposal
acknowledges that the typedef pattern is not useful for validation
in all possible scenarios, and the server must insure that the value is
valid for the specific leaf or leaf-list.





> Randy
>

Andy


>
> On 2022-04-27 4:51 AM, Christian Hopps wrote:
> >
> > Speaking as someone who at one point worked for an operator trying to
> > use YANG to actuall configure a large network (services and devices),
> > and also having interacted with the openconfig folks over the years. I
> > find your perspective, if I understand it, that being too "loose" with
> > things will stop actual industry use, contradicts my experience.
> >
> > My experience is that users just want to get work done and don't
> > actually "give a crap" (they often used more colorful language :) about
> > things being 100% perfect when 95% gets the job done. I believe that
> > drove many of the choices that openconfig made in fact. It also drove
> > operators away from the netmod WG as people argued endlessly over things
> > like not changing a typedef to match the actual deployed real world
> > situation, b/c it's theoretically wrong even if it was operationally
> > correct.
> >
> > Personally I think a balance must be struck. I think openconfig went too
> > far down the "just do whatever works" path, and that IETF/netmod has
> > gotten better about being less about something that professors would
> > love, and more about something industry actually finds useful, today.
> >
> > I think Rob is trying to strike that balance (and has been for a while
> > now with his work in this area), and I support him.
> >
> > Thanks,
> > Chris.
> >
> >
> > Randy Presuhn  writes:
> >
> >> Hi -
> >>
> >> If one accepts your arguments, you've made the case for defining
> >> a new module with typedefs for ipv6-address, etc. with modified
> >> syntax, semantics, and behavioral constraints to fit what has been
> >> deployed, and that modules requiring those perhaps more felicitously-
> >> named typdefs (because at its heart this kerfuffle is about the names)
> >> should import the definitions from there, rather than the existing
> >> module.
> >> That would seem the least disruptive path forward.
> >>
> >> But I get the feeling that you may envision a world of Yang / Netconf
> >> conformance testing that is far more rigorous than current reality,
> >> at least as reported by those actively involved in tool development.
> >> I'm no fan of the laissez-faire spirit of Netconf, but I fear that
> >> tugging a loose strings like this will unravel the whole wad of yarn,
> >> particularly if any expectations remain that it might support
> >> what has traditionally been called configuration management.  What
> >> happens when the next typedef is found that has been implemented
> >> in a manner not totally consistent with its definition?  This seems
> >> a really really really bad precedent to set.
> >>
> >> Randy
> >>
> >> On 2022-04-20 6:18 AM, Rob Wilton (rwilton) wrote:
> >>> Hi Randy,
> >>> Thanks for summarizing, but I don't really agree with your
> >>> categorization for
> >>> (1) or (3).
> >>> My interpretation of ip-address and the related v4/v6 types, based on
> >>> RFC
> >>> 7950, is that implementations MUST allow clients to configure zoned IP
> >>> addresses to be fully complaint with the module definition.  If a
> server
> >>> implementation does not support zoned ip-addresses then it is
> >>> expected to use
> >>> a deviation (e.g., to replace the type with ip-address-no-zone) to
> >>> indicate
> >>> how it does not conform to the model.  I don’t see that is being any
> >>> different
> >>> than an integer datatype with a range “1..255” and the server only
> >>> supporting
> >>> the client configuring values in the range “1..100”.
> >>> The "may include a zone index" in the ip-address definitions relates
> >>> to the
> >>> client when writing a value (or server when returning a value), i.e.,
> >>> they
> >>> don't have to always provide zones for all IP addresses.  They can
> >>> leave them
> >>> out, and when the zone is 

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

[Randy Presuhn]

Hi -

I think you've just made the argument for taking no action at all.
I do think that argument is more persuasive than the ones advanced so
far for changing deployed typedefs, and think the "no action" proposal
would be a reasonable compromise.

Randy

On 2022-04-27 4:51 AM, Christian Hopps wrote:


Speaking as someone who at one point worked for an operator trying to 
use YANG to actuall configure a large network (services and devices), 
and also having interacted with the openconfig folks over the years. I 
find your perspective, if I understand it, that being too "loose" with 
things will stop actual industry use, contradicts my experience.


My experience is that users just want to get work done and don't 
actually "give a crap" (they often used more colorful language :) about 
things being 100% perfect when 95% gets the job done. I believe that 
drove many of the choices that openconfig made in fact. It also drove 
operators away from the netmod WG as people argued endlessly over things 
like not changing a typedef to match the actual deployed real world 
situation, b/c it's theoretically wrong even if it was operationally 
correct.


Personally I think a balance must be struck. I think openconfig went too 
far down the "just do whatever works" path, and that IETF/netmod has 
gotten better about being less about something that professors would 
love, and more about something industry actually finds useful, today.


I think Rob is trying to strike that balance (and has been for a while 
now with his work in this area), and I support him.


Thanks,
Chris.


Randy Presuhn  writes:


Hi -

If one accepts your arguments, you've made the case for defining
a new module with typedefs for ipv6-address, etc. with modified
syntax, semantics, and behavioral constraints to fit what has been
deployed, and that modules requiring those perhaps more felicitously-
named typdefs (because at its heart this kerfuffle is about the names)
should import the definitions from there, rather than the existing 
module.

That would seem the least disruptive path forward.

But I get the feeling that you may envision a world of Yang / Netconf
conformance testing that is far more rigorous than current reality,
at least as reported by those actively involved in tool development.
I'm no fan of the laissez-faire spirit of Netconf, but I fear that
tugging a loose strings like this will unravel the whole wad of yarn,
particularly if any expectations remain that it might support
what has traditionally been called configuration management.  What
happens when the next typedef is found that has been implemented
in a manner not totally consistent with its definition?  This seems
a really really really bad precedent to set.

Randy

On 2022-04-20 6:18 AM, Rob Wilton (rwilton) wrote:

Hi Randy,
Thanks for summarizing, but I don't really agree with your 
categorization for

(1) or (3).
My interpretation of ip-address and the related v4/v6 types, based on 
RFC

7950, is that implementations MUST allow clients to configure zoned IP
addresses to be fully complaint with the module definition.  If a server
implementation does not support zoned ip-addresses then it is 
expected to use
a deviation (e.g., to replace the type with ip-address-no-zone) to 
indicate
how it does not conform to the model.  I don’t see that is being any 
different
than an integer datatype with a range “1..255” and the server only 
supporting

the client configuring values in the range “1..100”.
The "may include a zone index" in the ip-address definitions relates 
to the
client when writing a value (or server when returning a value), i.e., 
they
don't have to always provide zones for all IP addresses.  They can 
leave them
out, and when the zone is left out the "default zone of the device 
will be

used".
E.g., considering the RFC 6991 and the IP RIB YANG model,
  typedef ipv6-address {
    type string {
  pattern '…’
    }
    description
 "The ipv6-address type represents an IPv6 address in full,
  mixed, shortened, and shortened-mixed notation.  The IPv6
  address may include a zone index, separated by a % sign.
  The zone index is used to disambiguate identical address
  values.  For link-local addresses, the zone index will
  typically be the interface index number or the name of an
  interface. *If the zone index is not present, the default*
* zone of the device will be used.*
  The canonical format of IPv6 addresses uses the textual
  representation defined in Section 4 of RFC 5952
. *The*
* canonical format for the zone index is the numerical*
* format as described in Section 11.2 of RFC 4007
.";*
  |  |    +--rw v6ur:ipv6
  |  |   +--rw v6ur:route* [destination-prefix]
  |  |  +--rw v6ur:destination-prefix
  

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

[Christian Hopps]

Speaking as someone who at one point worked for an operator trying to use YANG to actuall 
configure a large network (services and devices), and also having interacted with the 
openconfig folks over the years. I find your perspective, if I understand it, that being 
too "loose" with things will stop actual industry use, contradicts my 
experience.

My experience is that users just want to get work done and don't actually "give a 
crap" (they often used more colorful language :) about things being 100% perfect 
when 95% gets the job done. I believe that drove many of the choices that openconfig made 
in fact. It also drove operators away from the netmod WG as people argued endlessly over 
things like not changing a typedef to match the actual deployed real world situation, b/c 
it's theoretically wrong even if it was operationally correct.

Personally I think a balance must be struck. I think openconfig went too far down the 
"just do whatever works" path, and that IETF/netmod has gotten better about 
being less about something that professors would love, and more about something industry 
actually finds useful, today.

I think Rob is trying to strike that balance (and has been for a while now with 
his work in this area), and I support him.

Thanks,
Chris.


Randy Presuhn  writes:


Hi -

If one accepts your arguments, you've made the case for defining
a new module with typedefs for ipv6-address, etc. with modified
syntax, semantics, and behavioral constraints to fit what has been
deployed, and that modules requiring those perhaps more felicitously-
named typdefs (because at its heart this kerfuffle is about the names)
should import the definitions from there, rather than the existing module.
That would seem the least disruptive path forward.

But I get the feeling that you may envision a world of Yang / Netconf
conformance testing that is far more rigorous than current reality,
at least as reported by those actively involved in tool development.
I'm no fan of the laissez-faire spirit of Netconf, but I fear that
tugging a loose strings like this will unravel the whole wad of yarn,
particularly if any expectations remain that it might support
what has traditionally been called configuration management.  What
happens when the next typedef is found that has been implemented
in a manner not totally consistent with its definition?  This seems
a really really really bad precedent to set.

Randy

On 2022-04-20 6:18 AM, Rob Wilton (rwilton) wrote:

Hi Randy,
Thanks for summarizing, but I don't really agree with your categorization for
(1) or (3).
My interpretation of ip-address and the related v4/v6 types, based on RFC
7950, is that implementations MUST allow clients to configure zoned IP
addresses to be fully complaint with the module definition.  If a server
implementation does not support zoned ip-addresses then it is expected to use
a deviation (e.g., to replace the type with ip-address-no-zone) to indicate
how it does not conform to the model.  I don’t see that is being any different
than an integer datatype with a range “1..255” and the server only supporting
the client configuring values in the range “1..100”.
The "may include a zone index" in the ip-address definitions relates to the
client when writing a value (or server when returning a value), i.e., they
don't have to always provide zones for all IP addresses.  They can leave them
out, and when the zone is left out the "default zone of the device will be
used".
E.g., considering the RFC 6991 and the IP RIB YANG model,
  typedef ipv6-address {
    type string {
  pattern '…’
    }
    description
     "The ipv6-address type represents an IPv6 address in full,
  mixed, shortened, and shortened-mixed notation.  The IPv6
  address may include a zone index, separated by a % sign.
  The zone index is used to disambiguate identical address
  values.  For link-local addresses, the zone index will
  typically be the interface index number or the name of an
  interface. *If the zone index is not present, the default*
* zone of the device will be used.*
  The canonical format of IPv6 addresses uses the textual
  representation defined in Section 4 of RFC 5952
. *The*
* canonical format for the zone index is the numerical*
* format as described in Section 11.2 of RFC 4007
.";*
  |  |    +--rw v6ur:ipv6
  |  |   +--rw v6ur:route* [destination-prefix]
  |  |  +--rw v6ur:destination-prefix
  |  |  |   inet:ipv6-prefix
  |  |  +--rw v6ur:description?  string
  |  |  +--rw v6ur:next-hop
  |  | +--rw (v6ur:next-hop-options)
  |  |    +--:(v6ur:simple-next-hop)
* |  |    |  +--rw 

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

[Randy Presuhn]

Hi -

If one accepts your arguments, you've made the case for defining
a new module with typedefs for ipv6-address, etc. with modified
syntax, semantics, and behavioral constraints to fit what has been
deployed, and that modules requiring those perhaps more felicitously-
named typdefs (because at its heart this kerfuffle is about the names)
should import the definitions from there, rather than the existing 
module.   That would seem the least disruptive path forward.


But I get the feeling that you may envision a world of Yang / Netconf
conformance testing that is far more rigorous than current reality,
at least as reported by those actively involved in tool development.
I'm no fan of the laissez-faire spirit of Netconf, but I fear that
tugging a loose strings like this will unravel the whole wad of yarn,
particularly if any expectations remain that it might support
what has traditionally been called configuration management.  What
happens when the next typedef is found that has been implemented
in a manner not totally consistent with its definition?  This seems
a really really really bad precedent to set.

Randy

On 2022-04-20 6:18 AM, Rob Wilton (rwilton) wrote:

Hi Randy,

Thanks for summarizing, but I don't really agree with your 
categorization for (1) or (3).


My interpretation of ip-address and the related v4/v6 types, based on 
RFC 7950, is that implementations MUST allow clients to configure zoned 
IP addresses to be fully complaint with the module definition.  If a 
server implementation does not support zoned ip-addresses then it is 
expected to use a deviation (e.g., to replace the type with 
ip-address-no-zone) to indicate how it does not conform to the model.  I 
don’t see that is being any different than an integer datatype with a 
range “1..255” and the server only supporting the client configuring 
values in the range “1..100”.


The "may include a zone index" in the ip-address definitions relates to 
the client when writing a value (or server when returning a value), 
i.e., they don't have to always provide zones for all IP addresses.  
They can leave them out, and when the zone is left out the "default zone 
of the device will be used".


E.g., considering the RFC 6991 and the IP RIB YANG model,

  typedef ipv6-address {

    type string {

  pattern '…’

    }

    description

     "The ipv6-address type represents an IPv6 address in full,

  mixed, shortened, and shortened-mixed notation.  The IPv6

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

  The zone index is used to disambiguate identical address

  values.  For link-local addresses, the zone index will

  typically be the interface index number or the name of an

  interface. *If the zone index is not present, the default*

* zone of the device will be used.*

  The canonical format of IPv6 addresses uses the textual

  representation defined in Section 4 of RFC 5952 
. *The*


* canonical format for the zone index is the numerical*

* format as described in Section 11.2 of RFC 4007 
.";*


  |  |    +--rw v6ur:ipv6

  |  |   +--rw v6ur:route* [destination-prefix]

  |  |  +--rw v6ur:destination-prefix

  |  |  |   inet:ipv6-prefix

  |  |  +--rw v6ur:description?  string

  |  |  +--rw v6ur:next-hop

  |  | +--rw (v6ur:next-hop-options)

  |  |    +--:(v6ur:simple-next-hop)

* |  |    |  +--rw v6ur:outgoing-interface?*

* |  |    |  |   if:interface-ref*

* |  |    |  +--rw v6ur:next-hop-address?*

* |  |    |  inet:ipv6-address*

So, considering the model above, if a link local IP address was provided 
as the next-hop-address without a zone, then according to the type 
definition, that link-local IP address is associated with the default 
zone of the device, not the “outgoing interface” for the next hop!  If a 
zone is returned with a link-local address (e.g., for a get request) 
then my expectation is that servers return the data using the “interface 
index number” (since that is the canonical form, this should be returned 
even if it was configured using an interface name to identify the 
zone).  Further, as far as I can tell, “interface index number” isn’t 
really well specified in a YANG management API and is probably far less 
meaningful that the interface name in a YANG context. I presume that 
this is if-index in RFC 8343 but that doesn’t need to be supported if 
the server doesn’t also support SNMP’s if-mib.


I suspect that the reason why ip-address (and the v4/v6) variants 
haven’t caused any problems in practice is because implementations are 
mostly wrongly 

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

[Rob Wilton (rwilton)]

Hi Randy,



Thanks for summarizing, but I don't really agree with your categorization for 
(1) or (3).



My interpretation of ip-address and the related v4/v6 types, based on RFC 7950, 
is that implementations MUST allow clients to configure zoned IP addresses to 
be fully complaint with the module definition.  If a server implementation does 
not support zoned ip-addresses then it is expected to use a deviation (e.g., to 
replace the type with ip-address-no-zone) to indicate how it does not conform 
to the model.  I don't see that is being any different than an integer datatype 
with a range "1..255" and the server only supporting the client configuring 
values in the range "1..100".



The "may include a zone index" in the ip-address definitions relates to the 
client when writing a value (or server when returning a value), i.e., they 
don't have to always provide zones for all IP addresses.  They can leave them 
out, and when the zone is left out the "default zone of the device will be 
used".



E.g., considering the RFC 6991 and the IP RIB YANG model,


 typedef ipv6-address {
   type string {
 pattern '...'
   }
   description
"The ipv6-address type represents an IPv6 address in full,
 mixed, shortened, and shortened-mixed notation.  The IPv6
 address may include a zone index, separated by a % sign.

 The zone index is used to disambiguate identical address
 values.  For link-local addresses, the zone index will
 typically be the interface index number or the name of an
 interface.  If the zone index is not present, the default
 zone of the device will be used.



 The canonical format of IPv6 addresses uses the textual

 representation defined in Section 4 of RFC 
5952.  The

 canonical format for the zone index is the numerical

 format as described in Section 11.2 of RFC 
4007.";




 |  |+--rw v6ur:ipv6
 |  |   +--rw v6ur:route* [destination-prefix]
 |  |  +--rw v6ur:destination-prefix
 |  |  |   inet:ipv6-prefix
 |  |  +--rw v6ur:description?  string
 |  |  +--rw v6ur:next-hop
 |  | +--rw (v6ur:next-hop-options)
 |  |+--:(v6ur:simple-next-hop)
 |  ||  +--rw v6ur:outgoing-interface?
 |  ||  |   if:interface-ref
 |  ||  +--rw v6ur:next-hop-address?
 |  ||  inet:ipv6-address



So, considering the model above, if a link local IP address was provided as the 
next-hop-address without a zone, then according to the type definition, that 
link-local IP address is associated with the default zone of the device, not 
the "outgoing interface" for the next hop!  If a zone is returned with a 
link-local address (e.g., for a get request) then my expectation is that 
servers return the data using the "interface index number" (since that is the 
canonical form, this should be returned even if it was configured using an 
interface name to identify the zone).  Further, as far as I can tell, 
"interface index number" isn't really well specified in a YANG management API 
and is probably far less meaningful that the interface name in a YANG context.  
I presume that this is if-index in RFC 8343 but that doesn't need to be 
supported if the server doesn't also support SNMP's if-mib.



I suspect that the reason why ip-address (and the v4/v6) variants haven't 
caused any problems in practice is because implementations are mostly wrongly 
treating them as ip-address-no-zone, and assuming that the scope information is 
being provided by other context (e.g., outgoing-interface in the example 
above), or perhaps most operators just configure their devices using global IP 
addresses.



Some further comments inline ...



> -Original Message-

> From: netmod  On Behalf Of Randy Presuhn

> Sent: 15 April 2022 20:25

> To: lsr@ietf.org; net...@ietf.org

> Subject: Re: [netmod] [Lsr] I-D Action: 
> draft-ietf-lsr-ospfv3-extended-lsa-yang-

> 10.txt

>

> 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 

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

[Andy Bierman]

On Fri, Apr 15, 2022 at 12:25 PM Randy Presuhn <
randy_pres...@alumni.stanford.edu> wrote:

> 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.
>
>
I have been using the term 'ip-address' for simplification.
I understand the actual edits are quite messy and apparently, not even
understood yet.


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


>
> ___
> netmod mailing list
> net...@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Randy Presuhn]

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

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Andy Bierman]

On Fri, Apr 15, 2022 at 9:44 AM tom petch  wrote:

> From: netmod  on behalf of Andy Bierman <
> a...@yumaworks.com>
> Sent: 14 April 2022 22:25
>
> On Thu, Apr 14, 2022 at 1:41 PM Randy Presuhn <
> randy_pres...@alumni.stanford.edu>
> wrote:
> 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
> >  j.schoenwael...@jacobs-university.de>
> > >> wrote:
> >
> > On Thu, Apr 14, 2022 at 12:48:18PM -0700, Andy Bierman wrote:
> >
> >  > 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.
> >
> > 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.
> >
> >
> > 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.
> ...
>
> 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.
>
> There seems to be many modules where ip-address was used
> when the intention of the WG was to use ip-address-no-zone.
>
> 
> 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.
>
>

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  for
an 
request. No further comment in ietf-inet-types is needed.



> Tom Petch
>
>

Andy


> 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
>
>
> ___
> netmod mailing list
> net...@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[tom petch]

From: netmod  on behalf of Andy Bierman 

Sent: 14 April 2022 22:25

On Thu, Apr 14, 2022 at 1:41 PM Randy Presuhn 
mailto:randy_pres...@alumni.stanford.edu>> 
wrote:
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
> mailto:j.schoenwael...@jacobs-university.de>
> >>
>  wrote:
>
> On Thu, Apr 14, 2022 at 12:48:18PM -0700, Andy Bierman wrote:
>
>  > 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.
>
> 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.
>
>
> 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.
...

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.

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


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


___
netmod mailing list
net...@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Andy Bierman]

On Thu, Apr 14, 2022 at 1:41 PM Randy Presuhn <
randy_pres...@alumni.stanford.edu> wrote:

> 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
> >  > > wrote:
> >
> > On Thu, Apr 14, 2022 at 12:48:18PM -0700, Andy Bierman wrote:
> >
> >  > 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.
> >
> > 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.
> >
> >
> > 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.
> ...
>
> 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.
>

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



> Randy
>

Andy


>
> ___
> netmod mailing list
> net...@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Randy Presuhn]

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 
> wrote:


On Thu, Apr 14, 2022 at 12:48:18PM -0700, Andy Bierman wrote:

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

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.


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.

...

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

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Andy Bierman]

On Thu, Apr 14, 2022 at 1:13 PM Jürgen Schönwälder <
j.schoenwael...@jacobs-university.de> wrote:

> On Thu, Apr 14, 2022 at 12:48:18PM -0700, Andy Bierman wrote:
>
> > 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.
>
> 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.
>
>
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




> 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)
>
> --
> 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 
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Randy Presuhn]

Hi -

On 2022-04-14 1:13 PM, Jürgen Schönwälder wrote:

On Thu, Apr 14, 2022 at 12:48:18PM -0700, Andy Bierman wrote:


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.


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)


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

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Jürgen Schönwälder]

On Thu, Apr 14, 2022 at 12:48:18PM -0700, Andy Bierman wrote:

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

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)

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

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Andy Bierman]

On Thu, Apr 14, 2022 at 12:38 PM Jürgen Schönwälder <
j.schoenwael...@jacobs-university.de> wrote:

> On Thu, Apr 14, 2022 at 09:23:38AM -0700, Andy Bierman wrote:
> > >
> > So is this a correct summary:
> >
> >  - 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
> > addresses
>
> 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).
>
> > 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.
>
> 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.
>
>
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.


> Nothing in RFC 6241 suggests that this is OK for .
>
> I have no clue what you mean. If your server recceives a value that
> your server does not support, you reject the value.
>
> /js
>

Andy



>
> 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.
>
> --
> 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 
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Joel M. Halpern]

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) 
mailto:40cisco@dmarc.ietf.org>> 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 .


Thanks,
Acee


Andy

On 4/14/22, 10:04 AM, "Lsr on behalf of Martin Björklund"
mailto:lsr-boun...@ietf.org> on behalf of
mbj+i...@4668.se > wrote:

     I thought the discussion was only about ipv4?


     /martin


     Jürgen Schönwälder mailto:j.schoenwael...@jacobs-university.de>> 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   
  >

     ___
     Lsr mailing list
Lsr@ietf.org 
https://www.ietf.org/mailman/listinfo/lsr


___
netmod mailing list
net...@ietf.org 
https://www.ietf.org/mailman/listinfo/netmod



___
netmod mailing list
net...@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Jürgen Schönwälder]

On Thu, Apr 14, 2022 at 09:23:38AM -0700, Andy Bierman wrote:
> >
> So is this a correct summary:
> 
>  - 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
> addresses

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

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

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 .

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.

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

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Acee Lindem (acee)]

Hi Andy,

From: Andy Bierman 
Date: Thursday, April 14, 2022 at 12:24 PM
To: Acee Lindem 
Cc: Martin Björklund , Juergen Schoenwaelder 
, "lsr@ietf.org" , 
"net...@ietf.org" 
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) 
mailto:40cisco@dmarc.ietf.org>> 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

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

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

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

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 .


Thanks,
Acee

Andy

On 4/14/22, 10:04 AM, "Lsr on behalf of Martin Björklund" 
mailto:lsr-boun...@ietf.org> on behalf of 
mbj+i...@4668.se> wrote:

I thought the discussion was only about ipv4?


/martin


Jürgen Schönwälder 
mailto:j.schoenwael...@jacobs-university.de>>
 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 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

___
netmod mailing list
net...@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Andy Bierman]

On Thu, Apr 14, 2022 at 8:01 AM Acee Lindem (acee)  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 .


Thanks,
> Acee
>
>
Andy


> On 4/14/22, 10:04 AM, "Lsr on behalf of Martin Björklund" <
> lsr-boun...@ietf.org on behalf of mbj+i...@4668.se> wrote:
>
> I thought the discussion was only about ipv4?
>
>
> /martin
>
>
> Jürgen Schönwälder  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 
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
> ___
> netmod mailing list
> net...@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Acee Lindem (acee)]

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" 
 wrote:

I thought the discussion was only about ipv4?


/martin


Jürgen Schönwälder  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 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Martin Björklund]

I thought the discussion was only about ipv4?


/martin


Jürgen Schönwälder  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 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Jürgen Schönwälder]

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 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Martin Björklund]

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)"  wrote:
> 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

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 .  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
> 
> 
> 
> > -Original Message-
> > From: Martin Björklund 
> > Sent: 12 April 2022 08:26
> > To: Rob Wilton (rwilton) 
> > Cc: net...@ietf.org; lsr@ietf.org
> > Subject: Re: [netmod] [Lsr] I-D Action:
> > draft-ietf-lsr-ospfv3-extended-lsa-yang-
> > 10.txt
> > 
> > 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
> > 
> > 
> > "Rob Wilton \(rwilton\)"  wrote:
> > > Hi all,
> > >
> > > Thanks for the comments on this thread so far.  It would be nice if we
> > > are
> > able to come to some sort of rough consensus to a solution.
> > >
> > > I think that there is consensus that the YANG type ip-address (and the
> > > v4/v6
> > versions) are badly named as the prominent default type name has been
> > given to the unusual variant of including zone information.
> > >
> > > Based on the comments on this thread, it also seems likely to me that
> > > most
> > of the usages of ip-address in YANG RFCs is likely to be wrong, and
> > the
> > intention was that IP addresses without zones was intended.  At a
> > rough
> > count, of the published RFC YANG models at github
> > YangModels/standard/ietf/RFC/ to be:
> > >   86 uses of ip-address
> > >   68 uses of ipv4-address
> > >   66 uses of ipv6-address
> > >
> > >   1 use of ip-address-no-zone
> > >   4 uses of ipv4-address-no-zone
> > >   4 uses of ipv6-address-no-zone
> > >
> > > These types appear in 49 out of the 141 YANG modules published in
> > > RFCs.
> > At a quick guess/check it looks like these 49 YANG modules may appear
> > in 40-
> > 50 RFCs.
> > >
> > > As mentioned previously, it is also worth comparing this to the
> > > OpenConfig
> > YANG modules:
> > > They have redefined ip-address (and v4/v6 variants) to 

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

[Jürgen Schönwälder]

On Wed, Apr 13, 2022 at 10:44:33AM +0200, Martin Björklund wrote:
> Jürgen Schönwälder  wrote:
> > On Tue, Apr 12, 2022 at 04:52:41PM +0200, Martin Björklund wrote:
> > > Jürgen Schönwälder  wrote:
> > > 
> > > [...]
> > > 
> > > > 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.
> > > 
> > > 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).
> 
> 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?

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.
 
> (To be clear: Personally, I do not think that deprecating these
> typedefs is the best solution)
>  
> > 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).
> 
> Did anyone suggest this?  I thought ip-address-with-zone was supposed to be
> exactly what ip-address is today.

This is how I understood Kent.

/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 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Rob Wilton (rwilton)]

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



> -Original Message-
> From: Martin Björklund 
> Sent: 12 April 2022 08:26
> To: Rob Wilton (rwilton) 
> Cc: net...@ietf.org; lsr@ietf.org
> Subject: Re: [netmod] [Lsr] I-D Action: 
> draft-ietf-lsr-ospfv3-extended-lsa-yang-
> 10.txt
> 
> 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
> 
> 
> "Rob Wilton \(rwilton\)"  wrote:
> > Hi all,
> >
> > Thanks for the comments on this thread so far.  It would be nice if we are
> able to come to some sort of rough consensus to a solution.
> >
> > I think that there is consensus that the YANG type ip-address (and the v4/v6
> versions) are badly named as the prominent default type name has been
> given to the unusual variant of including zone information.
> >
> > Based on the comments on this thread, it also seems likely to me that most
> of the usages of ip-address in YANG RFCs is likely to be wrong, and the
> intention was that IP addresses without zones was intended.  At a rough
> count, of the published RFC YANG models at github
> YangModels/standard/ietf/RFC/ to be:
> > 86 uses of ip-address
> > 68 uses of ipv4-address
> > 66 uses of ipv6-address
> >
> > 1 use of ip-address-no-zone
> > 4 uses of ipv4-address-no-zone
> > 4 uses of ipv6-address-no-zone
> >
> > These types appear in 49 out of the 141 YANG modules published in RFCs.
> At a quick guess/check it looks like these 49 YANG modules may appear in 40-
> 50 RFCs.
> >
> > As mentioned previously, it is also worth comparing this to the OpenConfig
> YANG modules:
> > They have redefined ip-address (and v4/v6 variants) to exclude zone
> information and have defined separate types include zone information.
> > There are no explicit uses of the "-zoned" variants of OpenConfig IP
> addresses in the latest OpenConfig github repository.  However,
> approximately a third of the IP address types are still to the ietf-inet-
> types.yang rather than openconfig-inet-types.yang, so in theory some of those
> 58 entries could still intentionally be supporting zoned IP addresses, but I
> would expect that the vast majority would not.
> > I do see some strong benefit if this basic type being defined in the same 
> > way
> in both IETF and OC YANG, and I believe that the OC folks have got the
> definition right.
> >
> > I see that some are arguing that the zone in the ip-address definition is
> effectively optional, and implementations are not really obliged to implement
> it.  I don't find that argument compelling, at least not with the current
> definition of ip-address in 

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

[Charles Eckel (eckelcu)]

On Apr 13, 2022, at 3:02 PM, Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>> wrote:



From: netmod mailto:netmod-boun...@ietf.org>> on 
behalf of Andy Bierman mailto:a...@yumaworks.com>>
Date: Wednesday, April 13, 2022 at 12:43 PM
To: tom petch mailto:ie...@btconnect.com>>
Cc: "lsr@ietf.org" mailto:lsr@ietf.org>>, 
"net...@ietf.org" 
mailto:net...@ietf.org>>, "Rob Wilton (rwilton)" 
mailto:rwilton=40cisco@dmarc.ietf.org>>
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 
mailto:ie...@btconnect.com>> wrote:
From: netmod mailto:netmod-boun...@ietf.org>> on 
behalf of Rob Wilton (rwilton) 
mailto:40cisco@dmarc.ietf.org>>
Sent: 11 April 2022 18:06

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.


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!!!

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


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

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 

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

[Acee Lindem (acee)]

From: netmod  on behalf of Andy Bierman 

Date: Wednesday, April 13, 2022 at 12:43 PM
To: tom petch 
Cc: "lsr@ietf.org" , "net...@ietf.org" , "Rob 
Wilton (rwilton)" 
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 
mailto:ie...@btconnect.com>> wrote:
From: netmod mailto:netmod-boun...@ietf.org>> on 
behalf of Rob Wilton (rwilton) 
mailto:40cisco@dmarc.ietf.org>>
Sent: 11 April 2022 18:06

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.


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


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

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 

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

[Andy Bierman]

On Wed, Apr 13, 2022 at 2:22 AM tom petch  wrote:

> From: netmod  on behalf of Rob Wilton (rwilton)
> 
> Sent: 11 April 2022 18:06
>
> 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.
>
>

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



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

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

[Rob Wilton (rwilton)]

Hi Tom,

Please see inline ...

> -Original Message-
> From: tom petch 
> Sent: 13 April 2022 10:22
> To: Rob Wilton (rwilton) ; net...@ietf.org;
> lsr@ietf.org
> Subject: Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-
> yang-10.txt
> 
> From: netmod  on behalf of Rob Wilton
> (rwilton) 
> Sent: 11 April 2022 18:06
> 
> 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 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


> 
> Tom Petch
> 
> 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 

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

[tom petch]

From: netmod  on behalf of Rob Wilton (rwilton) 

Sent: 11 April 2022 18:06

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

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 

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

[Martin Björklund]

Jürgen Schönwälder  wrote:
> On Tue, Apr 12, 2022 at 04:52:41PM +0200, Martin Björklund wrote:
> > Jürgen Schönwälder  wrote:
> > 
> > [...]
> > 
> > > 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.
> > 
> > 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).

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

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



/martin


> 
> /js
> 
> PS: I guess someone will propose to use ip-address-opt-zone instead
> ip-address-with-zone. ;-)
> 
> -- 
> 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 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Andy Bierman]

On Tue, Apr 12, 2022 at 7:45 AM Kent Watsen  wrote:

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




> K.
>

 Andy

___
> netmod mailing list
> net...@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Jürgen Schönwälder]

On Tue, Apr 12, 2022 at 03:10:12PM +, Acee Lindem (acee) wrote:
> 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 namestring
|  +--rw (transport)
| +--:(udp-and-tcp)
|+--udp-and-tcp
|   +--rw addressinet: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

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

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Jürgen Schönwälder]

On Tue, Apr 12, 2022 at 04:52:41PM +0200, Martin Björklund wrote:
> Jürgen Schönwälder  wrote:
> 
> [...]
> 
> > 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.
> 
> 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. ;-)

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

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Acee Lindem (acee)]

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" 
 wrote:

Acee,

if you believe link local addresses do not exist or do not need to be
supported, then you may want to bring the news to other WGs.

/js

On Tue, Apr 12, 2022 at 02:54:16PM +, Acee Lindem (acee) wrote:
> That was a hypothetical example based on IPv6 Link Local addresses - not 
one anyone has implemented or deployed. 
> Thanks,
> Acee
> 
> On 4/12/22, 10:47 AM, "Joel M. Halpern"  wrote:
> 
> Juergen posted an example of where ip-address is used and zones are 
> expected.
> 
> Yours,
> Joel
> 
> On 4/12/2022 9:24 AM, Acee Lindem (acee) wrote:
> > Joel,
> > 
> > There are plenty of examples of where the ip-address types are used 
and a zone is not accepted. Show me the examples where it is expected? I do 
have reason to believe there aren't any significant usages of the ip-address 
types where zone is accepted. Show me the models
> > 
> > Acee
> > 
> > On 4/11/22, 1:44 PM, "Lsr on behalf of Joel M. Halpern" 
 wrote:
> > 
> >  Do we have reason to believe that no one outside the IETF has 
used
> >  ip-address as we published in ways that need a zone?
> > 
> >  It seems to me that the first step in the plan below is 
reasonable.  But
> >  changing ip-address itself seems a bad idea.  If one means 
no-zone, use
> >  the -no-zone typedef.
> > 
> >  Yours,
> >  Joel
> > 
> >  On 4/11/2022 1:28 PM, Andy Bierman wrote:
> >  >
> >  >
> >  > On Mon, Apr 11, 2022 at 10:07 AM Rob Wilton (rwilton)
> >  > mailto:40cisco@dmarc.ietf.org>>
> >  > wrote:
> >  >
> >  > Hi all,
> >  >
> >  > Thanks for the comments on this thread so far.  It would 
be nice if
> >  > we are able to come to some sort of rough consensus to a 
solution.
> >  >
> >  > I think that there is consensus that the YANG type 
ip-address (and
> >  > the v4/v6 versions) are badly named as the prominent 
default type
> >  > name has been given to the unusual variant of including 
zone
> >  > information.
> >  >
> >  > Based on the comments on this thread, it also seems 
likely to me
> >  > that most of the usages of ip-address in YANG RFCs is 
likely to be
> >  > wrong, and the intention was that IP addresses without 
zones was
> >  > intended.  At a rough count, of the published RFC YANG 
models at
> >  > github YangModels/standard/ietf/RFC/ to be:
> >  >  86 uses of ip-address
> >  >  68 uses of ipv4-address
> >  >  66 uses of ipv6-address
> >  >
> >  >  1 use of ip-address-no-zone
> >  >  4 uses of ipv4-address-no-zone
> >  >  4 uses of ipv6-address-no-zone
> >  >
> >  > These types appear in 49 out of the 141 YANG modules 
published in
> >  > RFCs.  At a quick guess/check it looks like these 49 
YANG modules
> >  > may appear in 40-50 RFCs.
> >  >
> >  > As mentioned previously, it is also worth comparing this 
to the
> >  > OpenConfig YANG modules:
> >  > They have redefined ip-address (and v4/v6 variants) to 
exclude zone
> >  > information and have defined separate types include zone 
information.
> >  > There are no explicit uses of the "-zoned" variants of 
OpenConfig IP
> >  > addresses in the latest OpenConfig github repository.  
However,
> >  > approximately a third of the IP address types are still 
to the
> >  > ietf-inet-types.yang rather than 
openconfig-inet-types.yang, so in
> >  > theory some of those 58 entries could still 
intentionally be
> >  > supporting zoned IP addresses, but I would expect that 
the vast
> >  > majority would not.
> >  > I do see some strong benefit if this basic type being 
defined in the
> >  > same way in both IETF and OC YANG, and I believe that 
the OC folks
> >  > have got the definition right.
> >  >
> >  > I see that some are arguing that the zone in the 
ip-address
> >  > definition is 

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

[Jürgen Schönwälder]

Acee,

if you believe link local addresses do not exist or do not need to be
supported, then you may want to bring the news to other WGs.

/js

On Tue, Apr 12, 2022 at 02:54:16PM +, Acee Lindem (acee) wrote:
> That was a hypothetical example based on IPv6 Link Local addresses - not one 
> anyone has implemented or deployed. 
> Thanks,
> Acee
> 
> On 4/12/22, 10:47 AM, "Joel M. Halpern"  wrote:
> 
> Juergen posted an example of where ip-address is used and zones are 
> expected.
> 
> Yours,
> Joel
> 
> On 4/12/2022 9:24 AM, Acee Lindem (acee) wrote:
> > Joel,
> > 
> > There are plenty of examples of where the ip-address types are used and 
> a zone is not accepted. Show me the examples where it is expected? I do have 
> reason to believe there aren't any significant usages of the ip-address types 
> where zone is accepted. Show me the models
> > 
> > Acee
> > 
> > On 4/11/22, 1:44 PM, "Lsr on behalf of Joel M. Halpern" 
>  wrote:
> > 
> >  Do we have reason to believe that no one outside the IETF has used
> >  ip-address as we published in ways that need a zone?
> > 
> >  It seems to me that the first step in the plan below is 
> reasonable.  But
> >  changing ip-address itself seems a bad idea.  If one means 
> no-zone, use
> >  the -no-zone typedef.
> > 
> >  Yours,
> >  Joel
> > 
> >  On 4/11/2022 1:28 PM, Andy Bierman wrote:
> >  >
> >  >
> >  > On Mon, Apr 11, 2022 at 10:07 AM Rob Wilton (rwilton)
> >  >  >
> >  > wrote:
> >  >
> >  > Hi all,
> >  >
> >  > Thanks for the comments on this thread so far.  It would be 
> nice if
> >  > we are able to come to some sort of rough consensus to a 
> solution.
> >  >
> >  > I think that there is consensus that the YANG type 
> ip-address (and
> >  > the v4/v6 versions) are badly named as the prominent default 
> type
> >  > name has been given to the unusual variant of including zone
> >  > information.
> >  >
> >  > Based on the comments on this thread, it also seems likely 
> to me
> >  > that most of the usages of ip-address in YANG RFCs is likely 
> to be
> >  > wrong, and the intention was that IP addresses without zones 
> was
> >  > intended.  At a rough count, of the published RFC YANG 
> models at
> >  > github YangModels/standard/ietf/RFC/ to be:
> >  >  86 uses of ip-address
> >  >  68 uses of ipv4-address
> >  >  66 uses of ipv6-address
> >  >
> >  >  1 use of ip-address-no-zone
> >  >  4 uses of ipv4-address-no-zone
> >  >  4 uses of ipv6-address-no-zone
> >  >
> >  > These types appear in 49 out of the 141 YANG modules 
> published in
> >  > RFCs.  At a quick guess/check it looks like these 49 YANG 
> modules
> >  > may appear in 40-50 RFCs.
> >  >
> >  > As mentioned previously, it is also worth comparing this to 
> the
> >  > OpenConfig YANG modules:
> >  > They have redefined ip-address (and v4/v6 variants) to 
> exclude zone
> >  > information and have defined separate types include zone 
> information.
> >  > There are no explicit uses of the "-zoned" variants of 
> OpenConfig IP
> >  > addresses in the latest OpenConfig github repository.  
> However,
> >  > approximately a third of the IP address types are still to 
> the
> >  > ietf-inet-types.yang rather than openconfig-inet-types.yang, 
> so in
> >  > theory some of those 58 entries could still intentionally be
> >  > supporting zoned IP addresses, but I would expect that the 
> vast
> >  > majority would not.
> >  > I do see some strong benefit if this basic type being 
> defined in the
> >  > same way in both IETF and OC YANG, and I believe that the OC 
> folks
> >  > have got the definition right.
> >  >
> >  > I see that some are arguing that the zone in the ip-address
> >  > definition is effectively optional, and implementations are 
> not
> >  > really obliged to implement it.  I don't find that argument
> >  > compelling, at least not with the current definition of 
> ip-address
> >  > in RFC 6991.  I see a clear difference between a type 
> defined with
> >  > an incomplete regex that may allow some invalid values and a 
> type
> >  > that is explicitly defined to included additional values in 
> the
> >  > allowable value space.  Further, I believe that 

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

[Acee Lindem (acee)]

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"  wrote:

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

Yours,
Joel

On 4/12/2022 9:24 AM, Acee Lindem (acee) wrote:
> Joel,
> 
> There are plenty of examples of where the ip-address types are used and a 
zone is not accepted. Show me the examples where it is expected? I do have 
reason to believe there aren't any significant usages of the ip-address types 
where zone is accepted. Show me the models
> 
> Acee
> 
> On 4/11/22, 1:44 PM, "Lsr on behalf of Joel M. Halpern" 
 wrote:
> 
>  Do we have reason to believe that no one outside the IETF has used
>  ip-address as we published in ways that need a zone?
> 
>  It seems to me that the first step in the plan below is reasonable.  
But
>  changing ip-address itself seems a bad idea.  If one means no-zone, 
use
>  the -no-zone typedef.
> 
>  Yours,
>  Joel
> 
>  On 4/11/2022 1:28 PM, Andy Bierman wrote:
>  >
>  >
>  > On Mon, Apr 11, 2022 at 10:07 AM Rob Wilton (rwilton)
>  > mailto:40cisco@dmarc.ietf.org>>
>  > wrote:
>  >
>  > Hi all,
>  >
>  > Thanks for the comments on this thread so far.  It would be 
nice if
>  > we are able to come to some sort of rough consensus to a 
solution.
>  >
>  > I think that there is consensus that the YANG type ip-address 
(and
>  > the v4/v6 versions) are badly named as the prominent default 
type
>  > name has been given to the unusual variant of including zone
>  > information.
>  >
>  > Based on the comments on this thread, it also seems likely to 
me
>  > that most of the usages of ip-address in YANG RFCs is likely 
to be
>  > wrong, and the intention was that IP addresses without zones 
was
>  > intended.  At a rough count, of the published RFC YANG models 
at
>  > github YangModels/standard/ietf/RFC/ to be:
>  >  86 uses of ip-address
>  >  68 uses of ipv4-address
>  >  66 uses of ipv6-address
>  >
>  >  1 use of ip-address-no-zone
>  >  4 uses of ipv4-address-no-zone
>  >  4 uses of ipv6-address-no-zone
>  >
>  > These types appear in 49 out of the 141 YANG modules published 
in
>  > RFCs.  At a quick guess/check it looks like these 49 YANG 
modules
>  > may appear in 40-50 RFCs.
>  >
>  > As mentioned previously, it is also worth comparing this to the
>  > OpenConfig YANG modules:
>  > They have redefined ip-address (and v4/v6 variants) to exclude 
zone
>  > information and have defined separate types include zone 
information.
>  > There are no explicit uses of the "-zoned" variants of 
OpenConfig IP
>  > addresses in the latest OpenConfig github repository.  However,
>  > approximately a third of the IP address types are still to the
>  > ietf-inet-types.yang rather than openconfig-inet-types.yang, 
so in
>  > theory some of those 58 entries could still intentionally be
>  > supporting zoned IP addresses, but I would expect that the vast
>  > majority would not.
>  > I do see some strong benefit if this basic type being defined 
in the
>  > same way in both IETF and OC YANG, and I believe that the OC 
folks
>  > have got the definition right.
>  >
>  > I see that some are arguing that the zone in the ip-address
>  > definition is effectively optional, and implementations are not
>  > really obliged to implement it.  I don't find that argument
>  > compelling, at least not with the current definition of 
ip-address
>  > in RFC 6991.  I see a clear difference between a type defined 
with
>  > an incomplete regex that may allow some invalid values and a 
type
>  > that is explicitly defined to included additional values in the
>  > allowable value space.  Further, I believe that a client just
>  > looking at the YANG module could reasonably expect a server 
that
>  > implements a data node using ip-address would be expected to 
support
>  > IP zones, where they are meaningful, or otherwise they should
>  > deviate that data node to indicate that they don't conform to 
the model.
>  >
>  > We also need to be realistic as to what implementations will 
do.
> 

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

[Martin Björklund]

Jürgen Schönwälder  wrote:

[...]

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

But then what would you do with inet:host?


/martin

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Joel M. Halpern]

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


Yours,
Joel

On 4/12/2022 9:24 AM, Acee Lindem (acee) wrote:

Joel,

There are plenty of examples of where the ip-address types are used and a zone 
is not accepted. Show me the examples where it is expected? I do have reason to 
believe there aren't any significant usages of the ip-address types where zone 
is accepted. Show me the models

Acee

On 4/11/22, 1:44 PM, "Lsr on behalf of Joel M. Halpern"  wrote:

 Do we have reason to believe that no one outside the IETF has used
 ip-address as we published in ways that need a zone?

 It seems to me that the first step in the plan below is reasonable.  But
 changing ip-address itself seems a bad idea.  If one means no-zone, use
 the -no-zone typedef.

 Yours,
 Joel

 On 4/11/2022 1:28 PM, Andy Bierman wrote:
 >
 >
 > On Mon, Apr 11, 2022 at 10:07 AM Rob Wilton (rwilton)
 > mailto:40cisco@dmarc.ietf.org>>
 > wrote:
 >
 > Hi all,
 >
 > Thanks for the comments on this thread so far.  It would be nice if
 > we are able to come to some sort of rough consensus to a solution.
 >
 > I think that there is consensus that the YANG type ip-address (and
 > the v4/v6 versions) are badly named as the prominent default type
 > name has been given to the unusual variant of including zone
 > information.
 >
 > Based on the comments on this thread, it also seems likely to me
 > that most of the usages of ip-address in YANG RFCs is likely to be
 > wrong, and the intention was that IP addresses without zones was
 > intended.  At a rough count, of the published RFC YANG models at
 > github YangModels/standard/ietf/RFC/ to be:
 >  86 uses of ip-address
 >  68 uses of ipv4-address
 >  66 uses of ipv6-address
 >
 >  1 use of ip-address-no-zone
 >  4 uses of ipv4-address-no-zone
 >  4 uses of ipv6-address-no-zone
 >
 > These types appear in 49 out of the 141 YANG modules published in
 > RFCs.  At a quick guess/check it looks like these 49 YANG modules
 > may appear in 40-50 RFCs.
 >
 > As mentioned previously, it is also worth comparing this to the
 > OpenConfig YANG modules:
 > They have redefined ip-address (and v4/v6 variants) to exclude zone
 > information and have defined separate types include zone information.
 > There are no explicit uses of the "-zoned" variants of OpenConfig IP
 > addresses in the latest OpenConfig github repository.  However,
 > approximately a third of the IP address types are still to the
 > ietf-inet-types.yang rather than openconfig-inet-types.yang, so in
 > theory some of those 58 entries could still intentionally be
 > supporting zoned IP addresses, but I would expect that the vast
 > majority would not.
 > I do see some strong benefit if this basic type being defined in the
 > same way in both IETF and OC YANG, and I believe that the OC folks
 > have got the definition right.
 >
 > I see that some are arguing that the zone in the ip-address
 > definition is effectively optional, and implementations are not
 > really obliged to implement it.  I don't find that argument
 > compelling, at least not with the current definition of ip-address
 > in RFC 6991.  I see a clear difference between a type defined with
 > an incomplete regex that may allow some invalid values and a type
 > that is explicitly defined to included additional values in the
 > allowable value space.  Further, I believe that a client just
 > looking at the YANG module could reasonably expect a server that
 > implements a data node using ip-address would be expected to support
 > IP zones, where they are meaningful, or otherwise they should
 > deviate that data node to indicate that they don't conform to the 
model.
 >
 > We also need to be realistic as to what implementations will do.
 > They are not going to start writing code to support zones just
 > because they are in the model.  They will mostly reject IP addresses
 > with zone information.  Perhaps some will deviate the type to
 > ip-address-no-zone, but probably most won't.
 >
 > The option of respinning approx. 40-50 RFCs to fix this doesn't feel
 > at all appealing.  This would take a significant amount of
 > time/effort and I think that we will struggle to find folks who are
 > willing to do this.  Although errata could be used to point out the
 > bug, then can't be used to fix it, all the errata would be "hold for
 > document update" at best.  

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

[Kent Watsen]

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

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.___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Acee Lindem (acee)]

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"  wrote:

Do we have reason to believe that no one outside the IETF has used 
ip-address as we published in ways that need a zone?

It seems to me that the first step in the plan below is reasonable.  But 
changing ip-address itself seems a bad idea.  If one means no-zone, use 
the -no-zone typedef.

Yours,
Joel

On 4/11/2022 1:28 PM, Andy Bierman wrote:
> 
> 
> On Mon, Apr 11, 2022 at 10:07 AM Rob Wilton (rwilton) 
> mailto:40cisco@dmarc.ietf.org>> 
> wrote:
> 
> Hi all,
> 
> Thanks for the comments on this thread so far.  It would be nice if
> we are able to come to some sort of rough consensus to a solution.
> 
> I think that there is consensus that the YANG type ip-address (and
> the v4/v6 versions) are badly named as the prominent default type
> name has been given to the unusual variant of including zone
> information.
> 
> Based on the comments on this thread, it also seems likely to me
> that most of the usages of ip-address in YANG RFCs is likely to be
> wrong, and the intention was that IP addresses without zones was
> intended.  At a rough count, of the published RFC YANG models at
> github YangModels/standard/ietf/RFC/ to be:
>  86 uses of ip-address
>  68 uses of ipv4-address
>  66 uses of ipv6-address
> 
>  1 use of ip-address-no-zone
>  4 uses of ipv4-address-no-zone
>  4 uses of ipv6-address-no-zone
> 
> These types appear in 49 out of the 141 YANG modules published in
> RFCs.  At a quick guess/check it looks like these 49 YANG modules
> may appear in 40-50 RFCs.
> 
> As mentioned previously, it is also worth comparing this to the
> OpenConfig YANG modules:
> They have redefined ip-address (and v4/v6 variants) to exclude zone
> information and have defined separate types include zone information.
> There are no explicit uses of the "-zoned" variants of OpenConfig IP
> addresses in the latest OpenConfig github repository.  However,
> approximately a third of the IP address types are still to the
> ietf-inet-types.yang rather than openconfig-inet-types.yang, so in
> theory some of those 58 entries could still intentionally be
> supporting zoned IP addresses, but I would expect that the vast
> majority would not.
> I do see some strong benefit if this basic type being defined in the
> same way in both IETF and OC YANG, and I believe that the OC folks
> have got the definition right.
> 
> I see that some are arguing that the zone in the ip-address
> definition is effectively optional, and implementations are not
> really obliged to implement it.  I don't find that argument
> compelling, at least not with the current definition of ip-address
> in RFC 6991.  I see a clear difference between a type defined with
> an incomplete regex that may allow some invalid values and a type
> that is explicitly defined to included additional values in the
> allowable value space.  Further, I believe that a client just
> looking at the YANG module could reasonably expect a server that
> implements a data node using ip-address would be expected to support
> IP zones, where they are meaningful, or otherwise they should
> deviate that data node to indicate that they don't conform to the 
model.
> 
> We also need to be realistic as to what implementations will do. 
> They are not going to start writing code to support zones just
> because they are in the model.  They will mostly reject IP addresses
> with zone information.  Perhaps some will deviate the type to
> ip-address-no-zone, but probably most won't.
> 
> The option of respinning approx. 40-50 RFCs to fix this doesn't feel
> at all appealing.  This would take a significant amount of
> time/effort and I think that we will struggle to find folks who are
> willing to do this.  Although errata could be used to point out the
> bug, then can't be used to fix it, all the errata would be "hold for
> document update" at best.  Further, during the time that it would
> take us to fix it, it is plausible that more incorrect usages of
> ip-address will likely occur (but perhaps could be policed via
> 

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

[Acee Lindem (acee)]

From: netmod  on behalf of Andy Bierman 

Date: Tuesday, April 12, 2022 at 4:54 AM
To: Martin Björklund 
Cc: "lsr@ietf.org" , NetMod WG , Robert Wilton 

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 
mailto:mbj%2bi...@4668.se>> wrote:
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)



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



"Rob Wilton \(rwilton\)" 
mailto:40cisco@dmarc.ietf.org>> wrote:
> Hi all,
>
> Thanks for the comments on this thread so far.  It would be nice if we are 
> able to come to some sort of rough consensus to a solution.
>
> I think that there is consensus that the YANG type ip-address (and the v4/v6 
> versions) are badly named as the prominent default type name has been given 
> to the unusual variant of including zone information.
>
> Based on the comments on this thread, it also seems likely to me that most of 
> the usages of ip-address in YANG RFCs is likely to be wrong, and the 
> intention was that IP addresses without zones was intended.  At a rough 
> count, of the published RFC YANG models at github 
> YangModels/standard/ietf/RFC/ to be:
>   86 uses of ip-address
>   68 uses of ipv4-address
>   66 uses of ipv6-address
>
>   1 use of ip-address-no-zone
>   4 uses of ipv4-address-no-zone
>   4 uses of ipv6-address-no-zone
>
> These types appear in 49 out of the 141 YANG modules published in RFCs.  At a 
> quick guess/check it looks like these 49 YANG modules may appear in 40-50 
> RFCs.
>
> As mentioned previously, it is also worth comparing this to the OpenConfig 
> YANG modules:
> They have redefined ip-address (and v4/v6 variants) to exclude zone 
> information and have defined separate types include zone information.
> There are no explicit uses of the "-zoned" variants of OpenConfig IP 
> addresses in the latest OpenConfig github repository.  However, approximately 
> a third of the IP address types are still to the ietf-inet-types.yang rather 
> than openconfig-inet-types.yang, so in theory some of those 58 entries could 
> still intentionally be supporting zoned IP addresses, but I would expect that 
> the vast majority would not.
> I do see some strong benefit if this basic type being defined in the same way 
> in both IETF and OC YANG, and I believe that the OC folks have got the 
> definition right.
>
> I see that some are arguing that the zone in the ip-address definition is 
> effectively optional, and implementations are not really obliged to implement 
> it.  I don't find that argument compelling, at least not with the current 
> definition of ip-address in RFC 6991.  I see a clear difference between a 
> type defined with an incomplete regex that may allow some invalid values and 
> a type that is explicitly defined to included additional values in the 
> allowable value space.  Further, I believe that a client just looking at the 
> YANG module could reasonably expect a server that implements a data node 
> using ip-address would be expected to support IP zones, where they are 
> meaningful, or otherwise they should deviate that data node to indicate that 
> they don't conform to the model.
>
> We also need to be realistic as to what implementations will do.  They are 
> not going to start writing code to support zones just because they are in the 
> model.  They will mostly reject IP addresses with zone information.  Perhaps 
> some will deviate the type to ip-address-no-zone, but probably most won't.
>
> The option of respinning approx. 40-50 RFCs to fix this doesn't feel at all 
> appealing.  This would take a significant amount of time/effort and I think 
> that we will 

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

[Andy Bierman]

On Tue, Apr 12, 2022 at 12:26 AM Martin Björklund  wrote:

> 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)
>
>
>

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.



> /martin
>

Andy


>
>
> "Rob Wilton \(rwilton\)"  wrote:
> > Hi all,
> >
> > Thanks for the comments on this thread so far.  It would be nice if we
> are able to come to some sort of rough consensus to a solution.
> >
> > I think that there is consensus that the YANG type ip-address (and the
> v4/v6 versions) are badly named as the prominent default type name has been
> given to the unusual variant of including zone information.
> >
> > Based on the comments on this thread, it also seems likely to me that
> most of the usages of ip-address in YANG RFCs is likely to be wrong, and
> the intention was that IP addresses without zones was intended.  At a rough
> count, of the published RFC YANG models at github
> YangModels/standard/ietf/RFC/ to be:
> >   86 uses of ip-address
> >   68 uses of ipv4-address
> >   66 uses of ipv6-address
> >
> >   1 use of ip-address-no-zone
> >   4 uses of ipv4-address-no-zone
> >   4 uses of ipv6-address-no-zone
> >
> > These types appear in 49 out of the 141 YANG modules published in RFCs.
> At a quick guess/check it looks like these 49 YANG modules may appear in
> 40-50 RFCs.
> >
> > As mentioned previously, it is also worth comparing this to the
> OpenConfig YANG modules:
> > They have redefined ip-address (and v4/v6 variants) to exclude zone
> information and have defined separate types include zone information.
> > There are no explicit uses of the "-zoned" variants of OpenConfig IP
> addresses in the latest OpenConfig github repository.  However,
> approximately a third of the IP address types are still to the
> ietf-inet-types.yang rather than openconfig-inet-types.yang, so in theory
> some of those 58 entries could still intentionally be supporting zoned IP
> addresses, but I would expect that the vast majority would not.
> > I do see some strong benefit if this basic type being defined in the
> same way in both IETF and OC YANG, and I believe that the OC folks have got
> the definition right.
> >
> > I see that some are arguing that the zone in the ip-address definition
> is effectively optional, and implementations are not really obliged to
> implement it.  I don't find that argument compelling, at least not with the
> current definition of ip-address in RFC 6991.  I see a clear difference
> between a type defined with an incomplete regex that may allow some invalid
> values and a type that is explicitly defined to included additional values
> in the allowable value space.  Further, I believe that a client just
> looking at the YANG module could reasonably expect a server that implements
> a data node using ip-address would be expected to support IP zones, where
> they are meaningful, or otherwise they should deviate that data node to
> indicate that they don't conform to the model.
> >
> > We also need to be realistic as to what implementations will do.  They
> are not going to start writing code to support zones just because they are
> in the model.  They will mostly reject IP addresses with zone information.
> Perhaps some will deviate the type to ip-address-no-zone, but probably most
> won't.
> >
> > The option of respinning approx. 40-50 RFCs to fix this doesn't feel at
> all appealing.  This would take a significant amount of time/effort and I
> think that we will struggle to find folks who are willing to do this.
> Although errata could be used to point out the bug, then can't be used to
> fix it, all the errata would be "hold for document update" at best.
> Further, during the time that it would take us to fix it, it is plausible
> that more incorrect usages of ip-address will likely occur (but perhaps
> could be policed via scripted checks/warnings).
> >
> >
> > I still feel the 

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

[Martin Björklund]

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


"Rob Wilton \(rwilton\)"  wrote:
> Hi all,
> 
> Thanks for the comments on this thread so far.  It would be nice if we are 
> able to come to some sort of rough consensus to a solution.
> 
> I think that there is consensus that the YANG type ip-address (and the v4/v6 
> versions) are badly named as the prominent default type name has been given 
> to the unusual variant of including zone information.
> 
> Based on the comments on this thread, it also seems likely to me that most of 
> the usages of ip-address in YANG RFCs is likely to be wrong, and the 
> intention was that IP addresses without zones was intended.  At a rough 
> count, of the published RFC YANG models at github 
> YangModels/standard/ietf/RFC/ to be:
>   86 uses of ip-address
>   68 uses of ipv4-address
>   66 uses of ipv6-address
> 
>   1 use of ip-address-no-zone
>   4 uses of ipv4-address-no-zone
>   4 uses of ipv6-address-no-zone
> 
> These types appear in 49 out of the 141 YANG modules published in RFCs.  At a 
> quick guess/check it looks like these 49 YANG modules may appear in 40-50 
> RFCs.
> 
> As mentioned previously, it is also worth comparing this to the OpenConfig 
> YANG modules:
> They have redefined ip-address (and v4/v6 variants) to exclude zone 
> information and have defined separate types include zone information.
> There are no explicit uses of the "-zoned" variants of OpenConfig IP 
> addresses in the latest OpenConfig github repository.  However, approximately 
> a third of the IP address types are still to the ietf-inet-types.yang rather 
> than openconfig-inet-types.yang, so in theory some of those 58 entries could 
> still intentionally be supporting zoned IP addresses, but I would expect that 
> the vast majority would not.
> I do see some strong benefit if this basic type being defined in the same way 
> in both IETF and OC YANG, and I believe that the OC folks have got the 
> definition right.
> 
> I see that some are arguing that the zone in the ip-address definition is 
> effectively optional, and implementations are not really obliged to implement 
> it.  I don't find that argument compelling, at least not with the current 
> definition of ip-address in RFC 6991.  I see a clear difference between a 
> type defined with an incomplete regex that may allow some invalid values and 
> a type that is explicitly defined to included additional values in the 
> allowable value space.  Further, I believe that a client just looking at the 
> YANG module could reasonably expect a server that implements a data node 
> using ip-address would be expected to support IP zones, where they are 
> meaningful, or otherwise they should deviate that data node to indicate that 
> they don't conform to the model.
> 
> We also need to be realistic as to what implementations will do.  They are 
> not going to start writing code to support zones just because they are in the 
> model.  They will mostly reject IP addresses with zone information.  Perhaps 
> some will deviate the type to ip-address-no-zone, but probably most won't.
> 
> The option of respinning approx. 40-50 RFCs to fix this doesn't feel at all 
> appealing.  This would take a significant amount of time/effort and I think 
> that we will struggle to find folks who are willing to do this.  Although 
> errata could be used to point out the bug, then can't be used to fix it, all 
> the errata would be "hold for document update" at best.  Further, during the 
> time that it would take us to fix it, it is plausible that more incorrect 
> usages of ip-address will likely occur (but perhaps could be policed via 
> scripted checks/warnings).
> 
> 
> I still feel the right long-term solution here is to get to a state where the 
> "ip-address" type means what 99% of people expect it to mean, i.e., excluding 
> zone information.
> 
> Given the pushback on making a single non-backwards compatible change to the 
> new definition, I want to ask whether the following might be a possible path 
> that gains wider consensus:
> 
> (1) In RFC 6991 bis, I propose that we:
> (i) define new ip-address-with-zone types (and v4 and v6 versions) and keep 
> the -no-zone versions.
> (ii) we change the description of "ip-address" to indicate:
> - Although the type allows for zone information, many implementations are 
> unlikely to accept zone information in most scenarios (i.e., so the 
> description of the type more accurately reflects reality).
> - A new ip-address-with-zone type has been introduced to use where zoned IP 
> addresses are 

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

[Jürgen Schönwälder]

On Mon, Apr 11, 2022 at 01:43:56PM -0400, Joel M. Halpern wrote:
> Do we have reason to believe that no one outside the IETF has used
> ip-address as we published in ways that need a zone?
> 
> It seems 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.
>

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

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

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Christian Hopps]

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.

"Rob Wilton (rwilton)"  writes:


Hi all,





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


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Yingzhen Qu]

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) 
>  wrote:
> 
> Hi all,
> 
> Thanks for the comments on this thread so far.  It would be nice if we are 
> able to come to some sort of rough consensus to a solution.
> 
> I think that there is consensus that the YANG type ip-address (and the v4/v6 
> versions) are badly named as the prominent default type name has been given 
> to the unusual variant of including zone information.
> 
> Based on the comments on this thread, it also seems likely to me that most of 
> the usages of ip-address in YANG RFCs is likely to be wrong, and the 
> intention was that IP addresses without zones was intended.  At a rough 
> count, of the published RFC YANG models at github 
> YangModels/standard/ietf/RFC/ to be:
>   86 uses of ip-address
>   68 uses of ipv4-address
>   66 uses of ipv6-address
> 
>   1 use of ip-address-no-zone
>   4 uses of ipv4-address-no-zone
>   4 uses of ipv6-address-no-zone
> 
> These types appear in 49 out of the 141 YANG modules published in RFCs.  At a 
> quick guess/check it looks like these 49 YANG modules may appear in 40-50 
> RFCs.
> 
> As mentioned previously, it is also worth comparing this to the OpenConfig 
> YANG modules:
> They have redefined ip-address (and v4/v6 variants) to exclude zone 
> information and have defined separate types include zone information.
> There are no explicit uses of the "-zoned" variants of OpenConfig IP 
> addresses in the latest OpenConfig github repository.  However, approximately 
> a third of the IP address types are still to the ietf-inet-types.yang rather 
> than openconfig-inet-types.yang, so in theory some of those 58 entries could 
> still intentionally be supporting zoned IP addresses, but I would expect that 
> the vast majority would not.
> I do see some strong benefit if this basic type being defined in the same way 
> in both IETF and OC YANG, and I believe that the OC folks have got the 
> definition right.
> 
> I see that some are arguing that the zone in the ip-address definition is 
> effectively optional, and implementations are not really obliged to implement 
> it.  I don't find that argument compelling, at least not with the current 
> definition of ip-address in RFC 6991.  I see a clear difference between a 
> type defined with an incomplete regex that may allow some invalid values and 
> a type that is explicitly defined to included additional values in the 
> allowable value space.  Further, I believe that a client just looking at the 
> YANG module could reasonably expect a server that implements a data node 
> using ip-address would be expected to support IP zones, where they are 
> meaningful, or otherwise they should deviate that data node to indicate that 
> they don't conform to the model.
> 
> We also need to be realistic as to what implementations will do.  They are 
> not going to start writing code to support zones just because they are in the 
> model.  They will mostly reject IP addresses with zone information.  Perhaps 
> some will deviate the type to ip-address-no-zone, but probably most won't.
> 
> The option of respinning approx. 40-50 RFCs to fix this doesn't feel at all 
> appealing.  This would take a significant amount of time/effort and I think 
> that we will struggle to find folks who are willing to do this.  Although 
> errata could be used to point out the bug, then can't be used to fix it, all 
> the errata would be "hold for document update" at best.  Further, during the 
> time that it would take us to fix it, it is plausible that more incorrect 
> usages of ip-address will likely occur (but perhaps could be policed via 
> scripted checks/warnings).
> 
> 
> I still feel the right long-term solution here is to get to a state where the 
> "ip-address" type means what 99% of people expect it to mean, i.e., excluding 
> zone information.
> 
> Given the pushback on making a single non-backwards compatible change to the 
> new definition, I want to ask whether the following might be a possible path 
> that gains wider consensus:
> 
> (1) In RFC 6991 bis, I propose that we:
> (i) define new ip-address-with-zone types (and v4 and v6 versions) and keep 
> the -no-zone versions.
> (ii) we change the description of "ip-address" to indicate:
> - Although the type allows for zone information, many implementations are 
> unlikely to accept zone information in most scenarios (i.e., so the 
> description of the type more accurately reflects reality).
> - A new ip-address-with-zone type has been introduced to use where zoned IP 
> addresses are required/useful, and models that use ip-address with the 
> intention of supporting zoned IP addresses MUST migrate to 
> ip-address-with-zone.
> - In the 

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

[Acee Lindem (acee)]

Speaking as WG member inline.

From: netmod  on behalf of Andy Bierman 

Date: Monday, April 11, 2022 at 1:28 PM
To: "Rob Wilton (rwilton)" 
Cc: "lsr@ietf.org" , "net...@ietf.org" 
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) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Hi all,

Thanks for the comments on this thread so far.  It would be nice if we are able 
to come to some sort of rough consensus to a solution.

I think that there is consensus that the YANG type ip-address (and the v4/v6 
versions) are badly named as the prominent default type name has been given to 
the unusual variant of including zone information.

Based on the comments on this thread, it also seems likely to me that most of 
the usages of ip-address in YANG RFCs is likely to be wrong, and the intention 
was that IP addresses without zones was intended.  At a rough count, of the 
published RFC YANG models at github YangModels/standard/ietf/RFC/ to be:
86 uses of ip-address
68 uses of ipv4-address
66 uses of ipv6-address

1 use of ip-address-no-zone
4 uses of ipv4-address-no-zone
4 uses of ipv6-address-no-zone

These types appear in 49 out of the 141 YANG modules published in RFCs.  At a 
quick guess/check it looks like these 49 YANG modules may appear in 40-50 RFCs.

As mentioned previously, it is also worth comparing this to the OpenConfig YANG 
modules:
They have redefined ip-address (and v4/v6 variants) to exclude zone information 
and have defined separate types include zone information.
There are no explicit uses of the "-zoned" variants of OpenConfig IP addresses 
in the latest OpenConfig github repository.  However, approximately a third of 
the IP address types are still to the ietf-inet-types.yang rather than 
openconfig-inet-types.yang, so in theory some of those 58 entries could still 
intentionally be supporting zoned IP addresses, but I would expect that the 
vast majority would not.
I do see some strong benefit if this basic type being defined in the same way 
in both IETF and OC YANG, and I believe that the OC folks have got the 
definition right.

I see that some are arguing that the zone in the ip-address definition is 
effectively optional, and implementations are not really obliged to implement 
it.  I don't find that argument compelling, at least not with the current 
definition of ip-address in RFC 6991.  I see a clear difference between a type 
defined with an incomplete regex that may allow some invalid values and a type 
that is explicitly defined to included additional values in the allowable value 
space.  Further, I believe that a client just looking at the YANG module could 
reasonably expect a server that implements a data node using ip-address would 
be expected to support IP zones, where they are meaningful, or otherwise they 
should deviate that data node to indicate that they don't conform to the model.

We also need to be realistic as to what implementations will do.  They are not 
going to start writing code to support zones just because they are in the 
model.  They will mostly reject IP addresses with zone information.  Perhaps 
some will deviate the type to ip-address-no-zone, but probably most won't.

The option of respinning approx. 40-50 RFCs to fix this doesn't feel at all 
appealing.  This would take a significant amount of time/effort and I think 
that we will struggle to find folks who are willing to do this.  Although 
errata could be used to point out the bug, then can't be used to fix it, all 
the errata would be "hold for document update" at best.  Further, during the 
time that it would take us to fix it, it is plausible that more incorrect 
usages of ip-address will likely occur (but perhaps could be policed via 
scripted checks/warnings).


I still feel the right long-term solution here is to get to a state where the 
"ip-address" type means what 99% of people expect it to mean, i.e., excluding 
zone information.

Given the pushback on making a single non-backwards compatible change to the 
new definition, I want to ask whether the following might be a possible path 
that gains wider consensus:

(1) In RFC 6991 bis, I propose that we:
(i) define new ip-address-with-zone types (and v4 and v6 versions) and keep the 
-no-zone versions.
(ii) we change the description of "ip-address" to indicate:
- Although the type allows for zone information, many implementations are 
unlikely to accept zone information in most scenarios (i.e., so the description 
of the type more accurately reflects reality).
- A new ip-address-with-zone type has been introduced to use where zoned IP 
addresses are required/useful, and models that use ip-address with the 
intention of supporting zoned IP addresses MUST migrate to ip-address-with-zone.
- In the future (at least 2 years after RFC 6991 bis is published), the 
expectation is that the definition of ip-address 

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

[Joel M. Halpern]

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) 
mailto:40cisco@dmarc.ietf.org>> 
wrote:


Hi all,

Thanks for the comments on this thread so far.  It would be nice if
we are able to come to some sort of rough consensus to a solution.

I think that there is consensus that the YANG type ip-address (and
the v4/v6 versions) are badly named as the prominent default type
name has been given to the unusual variant of including zone
information.

Based on the comments on this thread, it also seems likely to me
that most of the usages of ip-address in YANG RFCs is likely to be
wrong, and the intention was that IP addresses without zones was
intended.  At a rough count, of the published RFC YANG models at
github YangModels/standard/ietf/RFC/ to be:
         86 uses of ip-address
         68 uses of ipv4-address
         66 uses of ipv6-address

         1 use of ip-address-no-zone
         4 uses of ipv4-address-no-zone
         4 uses of ipv6-address-no-zone

These types appear in 49 out of the 141 YANG modules published in
RFCs.  At a quick guess/check it looks like these 49 YANG modules
may appear in 40-50 RFCs.

As mentioned previously, it is also worth comparing this to the
OpenConfig YANG modules:
They have redefined ip-address (and v4/v6 variants) to exclude zone
information and have defined separate types include zone information.
There are no explicit uses of the "-zoned" variants of OpenConfig IP
addresses in the latest OpenConfig github repository.  However,
approximately a third of the IP address types are still to the
ietf-inet-types.yang rather than openconfig-inet-types.yang, so in
theory some of those 58 entries could still intentionally be
supporting zoned IP addresses, but I would expect that the vast
majority would not.
I do see some strong benefit if this basic type being defined in the
same way in both IETF and OC YANG, and I believe that the OC folks
have got the definition right.

I see that some are arguing that the zone in the ip-address
definition is effectively optional, and implementations are not
really obliged to implement it.  I don't find that argument
compelling, at least not with the current definition of ip-address
in RFC 6991.  I see a clear difference between a type defined with
an incomplete regex that may allow some invalid values and a type
that is explicitly defined to included additional values in the
allowable value space.  Further, I believe that a client just
looking at the YANG module could reasonably expect a server that
implements a data node using ip-address would be expected to support
IP zones, where they are meaningful, or otherwise they should
deviate that data node to indicate that they don't conform to the model.

We also need to be realistic as to what implementations will do. 
They are not going to start writing code to support zones just

because they are in the model.  They will mostly reject IP addresses
with zone information.  Perhaps some will deviate the type to
ip-address-no-zone, but probably most won't.

The option of respinning approx. 40-50 RFCs to fix this doesn't feel
at all appealing.  This would take a significant amount of
time/effort and I think that we will struggle to find folks who are
willing to do this.  Although errata could be used to point out the
bug, then can't be used to fix it, all the errata would be "hold for
document update" at best.  Further, during the time that it would
take us to fix it, it is plausible that more incorrect usages of
ip-address will likely occur (but perhaps could be policed via
scripted checks/warnings).


I still feel the right long-term solution here is to get to a state
where the "ip-address" type means what 99% of people expect it to
mean, i.e., excluding zone information.

Given the pushback on making a single non-backwards compatible
change to the new definition, I want to ask whether the following
might be a possible path that gains wider consensus:

(1) In RFC 6991 bis, I propose that we:
(i) define new ip-address-with-zone types (and v4 and v6 versions)
and keep the -no-zone versions.
(ii) we change the description of "ip-address" to indicate:
- Although the type allows for zone information, many
implementations are unlikely to accept zone information in most
scenarios (i.e., so the description of the type more accurately
reflects reality).
- A 

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

[Andy Bierman]

On Mon, Apr 11, 2022 at 10:07 AM Rob Wilton (rwilton)  wrote:

> Hi all,
>
> Thanks for the comments on this thread so far.  It would be nice if we are
> able to come to some sort of rough consensus to a solution.
>
> I think that there is consensus that the YANG type ip-address (and the
> v4/v6 versions) are badly named as the prominent default type name has been
> given to the unusual variant of including zone information.
>
> Based on the comments on this thread, it also seems likely to me that most
> of the usages of ip-address in YANG RFCs is likely to be wrong, and the
> intention was that IP addresses without zones was intended.  At a rough
> count, of the published RFC YANG models at github
> YangModels/standard/ietf/RFC/ to be:
> 86 uses of ip-address
> 68 uses of ipv4-address
> 66 uses of ipv6-address
>
> 1 use of ip-address-no-zone
> 4 uses of ipv4-address-no-zone
> 4 uses of ipv6-address-no-zone
>
> These types appear in 49 out of the 141 YANG modules published in RFCs.
> At a quick guess/check it looks like these 49 YANG modules may appear in
> 40-50 RFCs.
>
> As mentioned previously, it is also worth comparing this to the OpenConfig
> YANG modules:
> They have redefined ip-address (and v4/v6 variants) to exclude zone
> information and have defined separate types include zone information.
> There are no explicit uses of the "-zoned" variants of OpenConfig IP
> addresses in the latest OpenConfig github repository.  However,
> approximately a third of the IP address types are still to the
> ietf-inet-types.yang rather than openconfig-inet-types.yang, so in theory
> some of those 58 entries could still intentionally be supporting zoned IP
> addresses, but I would expect that the vast majority would not.
> I do see some strong benefit if this basic type being defined in the same
> way in both IETF and OC YANG, and I believe that the OC folks have got the
> definition right.
>
> I see that some are arguing that the zone in the ip-address definition is
> effectively optional, and implementations are not really obliged to
> implement it.  I don't find that argument compelling, at least not with the
> current definition of ip-address in RFC 6991.  I see a clear difference
> between a type defined with an incomplete regex that may allow some invalid
> values and a type that is explicitly defined to included additional values
> in the allowable value space.  Further, I believe that a client just
> looking at the YANG module could reasonably expect a server that implements
> a data node using ip-address would be expected to support IP zones, where
> they are meaningful, or otherwise they should deviate that data node to
> indicate that they don't conform to the model.
>
> We also need to be realistic as to what implementations will do.  They are
> not going to start writing code to support zones just because they are in
> the model.  They will mostly reject IP addresses with zone information.
> Perhaps some will deviate the type to ip-address-no-zone, but probably most
> won't.
>
> The option of respinning approx. 40-50 RFCs to fix this doesn't feel at
> all appealing.  This would take a significant amount of time/effort and I
> think that we will struggle to find folks who are willing to do this.
> Although errata could be used to point out the bug, then can't be used to
> fix it, all the errata would be "hold for document update" at best.
> Further, during the time that it would take us to fix it, it is plausible
> that more incorrect usages of ip-address will likely occur (but perhaps
> could be policed via scripted checks/warnings).
>
>
> I still feel the right long-term solution here is to get to a state where
> the "ip-address" type means what 99% of people expect it to mean, i.e.,
> excluding zone information.
>
> Given the pushback on making a single non-backwards compatible change to
> the new definition, I want to ask whether the following might be a possible
> path that gains wider consensus:
>
> (1) In RFC 6991 bis, I propose that we:
> (i) define new ip-address-with-zone types (and v4 and v6 versions) and
> keep the -no-zone versions.
> (ii) we change the description of "ip-address" to indicate:
> - Although the type allows for zone information, many implementations are
> unlikely to accept zone information in most scenarios (i.e., so the
> description of the type more accurately reflects reality).
> - A new ip-address-with-zone type has been introduced to use where zoned
> IP addresses are required/useful, and models that use ip-address with the
> intention of supporting zoned IP addresses MUST migrate to
> ip-address-with-zone.
> - In the future (at least 2 years after RFC 6991 bis is published), the
> expectation is that the definition of ip-address will change to match that
> of ip-address-no-zone.
>
> (2) Then in 2 years time, we publish RFC 6991-bis-bis to change the
> definition of ip-address to match ip-address-no-zone and deprecate 

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

[Rob Wilton (rwilton)]

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 

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

[Acee Lindem (acee)]

See inline. 

On 4/11/22, 5:13 AM, "tom petch"  wrote:

From: Lsr  on behalf of Reshad Rahman 

Sent: 10 April 2022 21:42

Inline.

On Wednesday, April 6, 2022, 06:04:42 PM EDT, Acee Lindem (acee) 
 wrote:


Hi Chris (as WG member),

On 4/5/22, 10:47 AM, "Christian Hopps" 
mailto:cho...@chopps.org>> wrote:



> On Apr 5, 2022, at 09:48, Acee Lindem (acee) 
mailto:a...@cisco.com>> 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]

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?

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.

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.



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.

[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

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]


> Thanks,
> Acee
>
> On 4/5/22, 9:33 AM, "Christian Hopps" 
mailto:cho...@chopps.org>> 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) 
mailto:40cisco@dmarc.ietf.org>> 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" 
mailto:ie...@btconnect.com>> wrote:
>>
>>  From: Acee Lindem (acee) mailto:a...@cisco.com>>
>>  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.
>>
>>  
>>
>>  Well, there are plenty of uses of 

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

[tom petch]

From: Lsr  on behalf of Reshad Rahman 

Sent: 10 April 2022 21:42

Inline.

On Wednesday, April 6, 2022, 06:04:42 PM EDT, Acee Lindem (acee) 
 wrote:


Hi Chris (as WG member),

On 4/5/22, 10:47 AM, "Christian Hopps" 
mailto:cho...@chopps.org>> wrote:



> On Apr 5, 2022, at 09:48, Acee Lindem (acee) 
mailto:a...@cisco.com>> 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]

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?

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.

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.



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

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]


> Thanks,
> Acee
>
> On 4/5/22, 9:33 AM, "Christian Hopps" 
mailto:cho...@chopps.org>> 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) 
mailto:40cisco@dmarc.ietf.org>> 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" 
mailto:ie...@btconnect.com>> wrote:
>>
>>  From: Acee Lindem (acee) mailto:a...@cisco.com>>
>>  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.
>>
>>  
>>
>>  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" 
mailto:lsr-boun...@ietf.org> on behalf of 
ie...@btconnect.com> 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 

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

[Reshad Rahman]

 Inline.
On Wednesday, April 6, 2022, 06:04:42 PM EDT, Acee Lindem (acee) 
 wrote:
 
 
 Hi Chris (as WG member),

On 4/5/22, 10:47 AM, "Christian Hopps"  wrote:



    > On Apr 5, 2022, at 09:48, Acee Lindem (acee)  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]

    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?

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

    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]


    > Thanks,
    > Acee 
    > 
    > On 4/5/22, 9:33 AM, "Christian Hopps"  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) 
 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"  wrote:
    >> 
    >>  From: Acee Lindem (acee) 
    >>  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.
    >> 
    >>  
    >> 
    >>  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"  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  on behalf of 
internet-dra...@ietf.org 
    >>      Sent: 07 March 2022 03:14
    >>      To: i-d-annou...@ietf.org
    >>      Cc: lsr@ietf.org
    >>      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 

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

[Andy Bierman]

On Sat, Apr 9, 2022 at 11:00 AM Acee Lindem (acee)  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 “%” 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..


> See inline responses in the unsnipped email below.
>
>
>
> *From: *netmod  on behalf of Andy Bierman <
> a...@yumaworks.com>
> *Date: *Saturday, April 9, 2022 at 1:38 PM
> *To: *Randy Presuhn 
> *Cc: *"lsr@ietf.org" , "net...@ietf.org" 
> *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 <
> randy_pres...@alumni.stanford.edu> wrote:
>
> 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."
>
>
>
> 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.
>
>
>
> 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.



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


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.




>
>
>
> That is, the proposed change does not improve operation of
> anything, and it breaks some things.
>
>
>
> yes -- too many years out in the wild this way to switch type names 

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

[Acee Lindem (acee)]

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 “%” 
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  on behalf of Andy Bierman 

Date: Saturday, April 9, 2022 at 1:38 PM
To: Randy Presuhn 
Cc: "lsr@ietf.org" , "net...@ietf.org" 
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 
mailto:randy_pres...@alumni.stanford.edu>> 
wrote:
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."

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.

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.



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.

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.


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.


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.


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

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

Thanks,
Acee


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

Andy


___
netmod mailing list
net...@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Acee Lindem (acee)]

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"  wrote:

Hi -

On 2022-04-08 12:25 PM, Acee Lindem (acee) wrote:
...
> 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/
...

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

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Andy Bierman]

On Sat, Apr 9, 2022 at 9:51 AM Randy Presuhn <
randy_pres...@alumni.stanford.edu> wrote:

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



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



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

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.



> That is, the proposed change does not improve operation of
> anything, and it breaks some things.
>
>
yes -- too many years out in the wild this way to switch type names around
now.



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

Andy


>
> ___
> netmod mailing list
> net...@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Randy Presuhn]

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

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Christian Hopps]

Randy Presuhn  writes:

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.


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.




Randy

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[tom petch]

From: tom petch 
Sent: 08 April 2022 17:32

From: Lsr  on behalf of Joel M. Halpern 

Sent: 07 April 2022 18:51

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



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.


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

On 4/7/2022 1:22 PM, Acee Lindem (acee) wrote:
> Hi Joel,
>
> On 4/7/22, 1:18 PM, "Joel M. Halpern"  wrote:
>
>  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.
>
> Point me to a usages where the zone is actually desired and supported?
>
> Acee
>
>
>
>
>  Yours,
>  Joel
>
>  On 4/7/2022 1:04 PM, Acee Lindem (acee) wrote:
>  > Hi Martin,
>  >
>  > On 4/7/22, 1:02 PM, "netmod on behalf of Martin Björklund" 
>  wrote:
>  >
>  >  Andy Bierman  wrote:
>  >  > On Thu, Apr 7, 2022 at 9:11 AM tom petch  
> wrote:
>  >  >
>  >  > > From: Lsr  on behalf of Rob Wilton 
> (rwilton)
>  >  > > 
>  >  > > Sent: 07 April 2022 10:25
>  >  > >
>  >  > > I basically agree with Acee, and I think that we should do 
> (b):
>  >  > >
>  >  > > b) Change the types as suggested and accept that 
> doing so breaks
>  >  > > modules where zone indexes are meaningful.
>  >  > >
>  >  > > 
>  >  > >
>  >  > > I am concerned that such behaviour will damage the standing 
> of the IETF at
>  >  > > large.
>  >  > >
>  >  > >
>  >  > 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?
>  >
>  >
>  >  > 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.
>  >
>  >  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
>  >
>  >
>  >  >
>  >  > Andy
>  >  >
>  

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

[Randy Presuhn]

Hi -

On 2022-04-08 12:25 PM, Acee Lindem (acee) wrote:
...

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/

...

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

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Acee Lindem (acee)]

See inline. 

On 4/8/22, 1:59 PM, "netmod on behalf of Randy Presuhn" 
 wrote:

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.

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-16IPv6 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-16IPv6 address network-byte order
   17-20zone 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 

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

[Randy Presuhn]

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

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[tom petch]

From: Lsr  on behalf of Joel M. Halpern 

Sent: 07 April 2022 18:51

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



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

On 4/7/2022 1:22 PM, Acee Lindem (acee) wrote:
> Hi Joel,
>
> On 4/7/22, 1:18 PM, "Joel M. Halpern"  wrote:
>
>  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.
>
> Point me to a usages where the zone is actually desired and supported?
>
> Acee
>
>
>
>
>  Yours,
>  Joel
>
>  On 4/7/2022 1:04 PM, Acee Lindem (acee) wrote:
>  > Hi Martin,
>  >
>  > On 4/7/22, 1:02 PM, "netmod on behalf of Martin Björklund" 
>  wrote:
>  >
>  >  Andy Bierman  wrote:
>  >  > On Thu, Apr 7, 2022 at 9:11 AM tom petch  
> wrote:
>  >  >
>  >  > > From: Lsr  on behalf of Rob Wilton 
> (rwilton)
>  >  > > 
>  >  > > Sent: 07 April 2022 10:25
>  >  > >
>  >  > > I basically agree with Acee, and I think that we should do 
> (b):
>  >  > >
>  >  > > b) Change the types as suggested and accept that 
> doing so breaks
>  >  > > modules where zone indexes are meaningful.
>  >  > >
>  >  > > 
>  >  > >
>  >  > > I am concerned that such behaviour will damage the standing 
> of the IETF at
>  >  > > large.
>  >  > >
>  >  > >
>  >  > 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?
>  >
>  >
>  >  > 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.
>  >
>  >  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
>  >
>  >
>  >  >
>  >  > Andy
>  >  >
>  >  >
>  >  >
>  >  > > We clearly laid down rules as to what updates were regarded 
> as compatible
>  >  > > so that authors of 

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

[Christian Hopps]

Randy Presuhn  writes:


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.


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.



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

Randy

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Randy Presuhn]

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

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Joel M. Halpern]

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

On 4/7/2022 1:22 PM, Acee Lindem (acee) wrote:

Hi Joel,

On 4/7/22, 1:18 PM, "Joel M. Halpern"  wrote:

 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.

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

Acee




 Yours,
 Joel

 On 4/7/2022 1:04 PM, Acee Lindem (acee) wrote:
 > Hi Martin,
 >
 > On 4/7/22, 1:02 PM, "netmod on behalf of Martin Björklund" 
 wrote:
 >
 >  Andy Bierman  wrote:
 >  > On Thu, Apr 7, 2022 at 9:11 AM tom petch  
wrote:
 >  >
 >  > > From: Lsr  on behalf of Rob Wilton 
(rwilton)
 >  > > 
 >  > > Sent: 07 April 2022 10:25
 >  > >
 >  > > I basically agree with Acee, and I think that we should do (b):
 >  > >
 >  > > b) Change the types as suggested and accept that doing 
so breaks
 >  > > modules where zone indexes are meaningful.
 >  > >
 >  > > 
 >  > >
 >  > > I am concerned that such behaviour will damage the standing of 
the IETF at
 >  > > large.
 >  > >
 >  > >
 >  > 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?
 >
 >
 >  > 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.
 >
 >  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
 >
 >
 >  >
 >  > 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, 

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

[Acee Lindem (acee)]

Jürgen, 

On 4/7/22, 12:08 PM, "Jürgen Schönwälder" 
 wrote:

On Thu, Apr 07, 2022 at 02:35:03PM +, Acee Lindem (acee) wrote:
> 
> 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. 
>

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.

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

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

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Acee Lindem (acee)]

Hi Joel,

On 4/7/22, 1:18 PM, "Joel M. Halpern"  wrote:

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.

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

Acee




Yours,
Joel

On 4/7/2022 1:04 PM, Acee Lindem (acee) wrote:
> Hi Martin,
> 
> On 4/7/22, 1:02 PM, "netmod on behalf of Martin Björklund" 
 wrote:
> 
>  Andy Bierman  wrote:
>  > On Thu, Apr 7, 2022 at 9:11 AM tom petch  
wrote:
>  >
>  > > From: Lsr  on behalf of Rob Wilton 
(rwilton)
>  > > 
>  > > Sent: 07 April 2022 10:25
>  > >
>  > > I basically agree with Acee, and I think that we should do (b):
>  > >
>  > > b) Change the types as suggested and accept that doing 
so breaks
>  > > modules where zone indexes are meaningful.
>  > >
>  > > 
>  > >
>  > > I am concerned that such behaviour will damage the standing of 
the IETF at
>  > > large.
>  > >
>  > >
>  > 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?
> 
> 
>  > 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.
> 
>  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
> 
> 
>  >
>  > 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 

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

[Martin Björklund]

Andy Bierman  wrote:
> On Thu, Apr 7, 2022 at 9:11 AM tom petch  wrote:
> 
> > From: Lsr  on behalf of Rob Wilton (rwilton)
> > 
> > Sent: 07 April 2022 10:25
> >
> > I basically agree with Acee, and I think that we should do (b):
> >
> > b) Change the types as suggested and accept that doing so breaks
> > modules where zone indexes are meaningful.
> >
> > 
> >
> > I am concerned that such behaviour will damage the standing of the IETF at
> > large.
> >
> >
> 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?


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

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.


/martin


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

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

[Andy Bierman]

On Thu, Apr 7, 2022 at 10:01 AM Martin Björklund  wrote:

> Andy Bierman  wrote:
> > On Thu, Apr 7, 2022 at 9:11 AM tom petch  wrote:
> >
> > > From: Lsr  on behalf of Rob Wilton (rwilton)
> > > 
> > > Sent: 07 April 2022 10:25
> > >
> > > I basically agree with Acee, and I think that we should do (b):
> > >
> > > b) Change the types as suggested and accept that doing so
> breaks
> > > modules where zone indexes are meaningful.
> > >
> > > 
> > >
> > > I am concerned that such behaviour will damage the standing of the
> IETF at
> > > large.
> > >
> > >
> > 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?
>
>
> > 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.
>
> 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.
>
>
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.



> /martin
>
>
Andy



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

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

[Joel M. Halpern]

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

On 4/7/2022 1:04 PM, Acee Lindem (acee) wrote:

Hi Martin,

On 4/7/22, 1:02 PM, "netmod on behalf of Martin Björklund" 
 wrote:

 Andy Bierman  wrote:
 > On Thu, Apr 7, 2022 at 9:11 AM tom petch  wrote:
 >
 > > From: Lsr  on behalf of Rob Wilton (rwilton)
 > > 
 > > Sent: 07 April 2022 10:25
 > >
 > > I basically agree with Acee, and I think that we should do (b):
 > >
 > > b) Change the types as suggested and accept that doing so 
breaks
 > > modules where zone indexes are meaningful.
 > >
 > > 
 > >
 > > I am concerned that such behaviour will damage the standing of the 
IETF at
 > > large.
 > >
 > >
 > 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?


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

 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


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

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

[Acee Lindem (acee)]

Hi Martin, 

On 4/7/22, 1:02 PM, "netmod on behalf of Martin Björklund" 
 wrote:

Andy Bierman  wrote:
> On Thu, Apr 7, 2022 at 9:11 AM tom petch  wrote:
> 
> > From: Lsr  on behalf of Rob Wilton (rwilton)
> > 
> > Sent: 07 April 2022 10:25
> >
> > I basically agree with Acee, and I think that we should do (b):
> >
> > b) Change the types as suggested and accept that doing so breaks
> > modules where zone indexes are meaningful.
> >
> > 
> >
> > I am concerned that such behaviour will damage the standing of the IETF 
at
> > large.
> >
> >
> 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?


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

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


> 
> 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
> >
> >
> > -Original Message-
> > From: iesg  On Behalf Of Jürgen Schönwälder
> > Sent: 07 April 2022 08:35
> > To: Acee Lindem (acee) 
> > Cc: lsr@ietf.org; The IESG ; net...@ietf.org
> > Subject: Re: [netmod] [Lsr] I-D Action:
> > draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
> >
> > Here is roughly what happened:
> >
> > - RFC 6020 (published ~12 years ago) introduced the ip-address
> >   type. It 

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

[Andy Bierman]

On Thu, Apr 7, 2022 at 9:11 AM tom petch  wrote:

> From: Lsr  on behalf of Rob Wilton (rwilton)
> 
> Sent: 07 April 2022 10:25
>
> I basically agree with Acee, and I think that we should do (b):
>
> b) Change the types as suggested and accept that doing so breaks
> modules where zone indexes are meaningful.
>
> 
>
> I am concerned that such behaviour will damage the standing of the IETF at
> large.
>
>
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
>
>
> -Original Message-
> From: iesg  On Behalf Of Jürgen Schönwälder
> Sent: 07 April 2022 08:35
> To: Acee Lindem (acee) 
> Cc: lsr@ietf.org; The IESG ; net...@ietf.org
> Subject: Re: [netmod] [Lsr] I-D Action:
> draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
>
> 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
>
> On Wed, Apr 06, 2022 

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

[tom petch]

From: Lsr  on behalf of Rob Wilton (rwilton) 

Sent: 07 April 2022 10:25

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

b) Change the types as suggested and accept that doing so breaks
modules where zone indexes are meaningful.



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 

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  On Behalf Of Jürgen Schönwälder
Sent: 07 April 2022 08:35
To: Acee Lindem (acee) 
Cc: lsr@ietf.org; The IESG ; net...@ietf.org
Subject: Re: [netmod] [Lsr] I-D Action: 
draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

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

On Wed, Apr 06, 2022 at 09:02:23PM +, Acee Lindem (acee) wrote:
> 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 

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

[Jürgen Schönwälder]

On Thu, Apr 07, 2022 at 02:35:03PM +, Acee Lindem (acee) wrote:
> 
> 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. 
>

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

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

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Acee Lindem (acee)]

Kent, 

On 4/7/22, 4:39 AM, "Kent Watsen"  wrote:


Juergen et. al. ,

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

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. 


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

> 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)




___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Jürgen Schönwälder]

On Thu, Apr 07, 2022 at 08:39:01AM +, Kent Watsen wrote:
> 
> Juergen et. al. ,
> 
> > 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.
> 
> 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. 
>

I added d) for completeness.
 
> > 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. 

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.

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

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

/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 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Rob Wilton (rwilton)]

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

b) Change the types as suggested and accept that doing so breaks
modules where zone indexes are meaningful.

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  On Behalf Of Jürgen Schönwälder
Sent: 07 April 2022 08:35
To: Acee Lindem (acee) 
Cc: lsr@ietf.org; The IESG ; net...@ietf.org
Subject: Re: [netmod] [Lsr] I-D Action: 
draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

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

On Wed, Apr 06, 2022 at 09:02:23PM +, Acee Lindem (acee) wrote:
> 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 
> Date: Tuesday, April 5, 2022 at 3:21 PM
> To: Juergen Schoenwaelder , Andy 
> Bierman , Acee Lindem , "lsr@ietf.org" 
> , "net...@ietf.org" 
> 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 
> mailto:j.schoenwael...@jacobs-university.de>>
>  wrote:
> On Tue, Apr 05, 2022 at 10:03:25AM -0700, Andy Bierman 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.
> > >
> > >
> > I don't think this will harm our implementations.
> > The type is still string. The pattern will change but 

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

[Kent Watsen]

Juergen et. al. ,

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

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)



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Jürgen Schönwälder]

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

On Wed, Apr 06, 2022 at 09:02:23PM +, Acee Lindem (acee) wrote:
> 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 
> Date: Tuesday, April 5, 2022 at 3:21 PM
> To: Juergen Schoenwaelder , Andy 
> Bierman , Acee Lindem , "lsr@ietf.org" 
> , "net...@ietf.org" 
> 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 
> mailto:j.schoenwael...@jacobs-university.de>>
>  wrote:
> On Tue, Apr 05, 2022 at 10:03:25AM -0700, Andy Bierman 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.
> > >
> > >
> > 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.
> 
> Either a zone is allowed to be present or it is not, this does make a
> 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.
> 
> 
> 
> 
> > The same problem exists for 'date' and 'date-no-zone' types,
> > 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. ;-)
> 
> 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.
> 
> 
> 
> /js
> 
> Andy
> 
> --
> 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

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

[Acee Lindem (acee)]

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 
Date: Tuesday, April 5, 2022 at 3:21 PM
To: Juergen Schoenwaelder , Andy Bierman 
, Acee Lindem , "lsr@ietf.org" 
, "net...@ietf.org" 
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 
mailto:j.schoenwael...@jacobs-university.de>>
 wrote:
On Tue, Apr 05, 2022 at 10:03:25AM -0700, Andy Bierman 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.
> >
> >
> 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.

Either a zone is allowed to be present or it is not, this does make a
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.




> The same problem exists for 'date' and 'date-no-zone' types,
> 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. ;-)

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.



/js

Andy

--
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 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Andy Bierman]

On Tue, Apr 5, 2022 at 12:02 PM Jürgen Schönwälder <
j.schoenwael...@jacobs-university.de> wrote:

> On Tue, Apr 05, 2022 at 10:03:25AM -0700, Andy Bierman 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.
> > >
> > >
> > 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.
>
> Either a zone is allowed to be present or it is not, this does make a
> 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.




>
> > The same problem exists for 'date' and 'date-no-zone' types,
> > 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. ;-)
>

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.



>
> /js
>
>
Andy


> --
> 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 
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Jürgen Schönwälder]

On Tue, Apr 05, 2022 at 10:03:25AM -0700, Andy Bierman 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.
> >
> >
> 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.

Either a zone is allowed to be present or it is not, this does make a
difference, its not a cosmetic change.
 
> The same problem exists for 'date' and 'date-no-zone' types,
> 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

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

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Andy Bierman]

On Tue, Apr 5, 2022 at 8:45 AM Acee Lindem (acee)  wrote:

>
>
> On 4/5/22, 11:37 AM, "Lsr on behalf of Jürgen Schönwälder" <
> lsr-boun...@ietf.org on behalf of j.schoenwael...@jacobs-university.de>
> wrote:
>
> On Tue, Apr 05, 2022 at 01:48:25PM +, Acee Lindem (acee) 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.
> >
>
> 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.
>
> 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


>
> --
> 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 
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
> ___
> netmod mailing list
> net...@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr