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

[tom petch <[e-mail]>]

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

On Thu, Apr 14, 2022 at 1:41 PM Randy Presuhn <[e-mail]<mailto:[e-mail]>> 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
> <[e-mail]<mailto:[e-mail]>
> <mailto:[e-mail]<mailto:[e-mail]>>> 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.

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

Tom Petch

Tom Petch

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



Randy

Andy


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