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