Hi Andy, I like this suggestion.
From: Andy Bierman <[email protected]> Date: Wednesday, April 20, 2022 at 9:19 PM To: Acee Lindem <[email protected]> Cc: Juergen Schoenwaelder <[email protected]>, NetMod WG <[email protected]> Subject: Re: [netmod] usage of ip-address in openconfig On Wed, Apr 20, 2022 at 4:02 PM Acee Lindem (acee) <[email protected]<mailto:[email protected]>> wrote: On 4/20/22, 6:35 PM, "netmod on behalf of Jürgen Schönwälder" <[email protected]<mailto:[email protected]> on behalf of [email protected]<mailto:[email protected]>> wrote: On Wed, Apr 20, 2022 at 02:51:35PM -0700, Andy Bierman wrote: > On Wed, Apr 20, 2022 at 2:34 PM Jürgen Schönwälder < > [email protected]<mailto:[email protected]>> wrote: > > > I am not sure it helps to look at individual data models but since > > openconfig is often presented as getting things right, here is what I > > find in openconfig-system-logging.yang > > > Not sure why this missing feature is relevant. I suggest that people questioning the need to support scoped IPv6 addresses in IETF YANG data models write an I-D explaining why IETF YANG data models do not need to support scoped IPv6 addresses and pass the I-D through the IPv6 working group. The question is not whether there is a single use case for IPv6 link local addresses with a zone. The question is whether the base pattern for IPv6 addresses should include a zone and whether one was expected for all the existing YANG model usages of inet:ipv6-address. I think that given the very narrow scope, the answer is clearly no. Additionally, the zone is only applicable to IPv6 link-local addresses yet the pattern in RFC 6991 allows the zone for ALL IPv6 addresses. This is also clearly wrong. I think Martin's original comment about 0.0.0.0 applies here as well. The pattern cannot be trusted to validate a client-provided IP address. It accepts all possible variants, including some invalid variants. It is always the server responsibility to validate the client input for the specific data node. Just reject all zone index variants from the client and ip-address == ip-address-no-zone. As Martin suggested, this could fixed in RFC 6991BIS with an update to the descriptions that says, in effect, that zone index is not necessarily valid and will be rejected by most servers. However, it is a shame that it can’t be removed for IPv4 since there are no known use cases or usages. If the argument is that a zone index is always allowed (even if the usage is limited) then why does the ip-address-no-zone typedef exist at all? There are no YANG guidelines for picking between them. Totally agree. In fact, we should cease with the discussion that we use the obscure ip-address-no-zone, ipv4-address-no-zone, and ipv6-address-no-zone types in our IETF YANG models rather than the well-known types. Thanks, Acee Andy Do you at least admit that IPv4 link-scoped addresses with zone have no useful purpose? Or are you going to try and argue that the ever-popular 169.254.0.0/16<http://169.254.0.0/16> addresses are an absolute requirement for YANG models and expected for every usage of inet:ipv4-address? Acee P.S. I would add that it is a good thing that syslog server can't be mapped to a link-local address with a zone in the Open-Config model. In general, IPv6 services such as syslog servers should be mapped to global IPv6 addresses. /js -- Jürgen Schönwälder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
