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