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

[Randy Presuhn <[e-mail]>]

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