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

[Andy Bierman <[e-mail]>]

On Fri, Apr 15, 2022 at 12:25 PM Randy Presuhn <
[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>