Re: [netmod] usage of ip-address in openconfig

["Acee Lindem (acee)" <[e-mail]>]

Hi Andy,

I like this suggestion.

From: Andy Bierman <[e-mail]>
Date: Wednesday, April 20, 2022 at 9:19 PM
To: Acee Lindem <[e-mail]>
Cc: Juergen Schoenwaelder <[e-mail]>, NetMod WG <[e-mail]>
Subject: Re: [netmod] usage of ip-address in openconfig



On Wed, Apr 20, 2022 at 4:02 PM Acee Lindem (acee) <[e-mail]<mailto:[e-mail]>> wrote:


On 4/20/22, 6:35 PM, "netmod on behalf of Jürgen Schönwälder" <[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> 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 <
    > [e-mail]<mailto:[e-mail]>> 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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
    Fax:   [phone]         <https://www.jacobs-university.de/>

    _______________________________________________
    netmod mailing list
    [e-mail]<mailto:[e-mail]>
    https://www.ietf.org/mailman/listinfo/netmod