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

Hi Andy,

My opinion remains the same that RFC 4001 got it right with types including the zone specification being the exception rather than the default. I know that when people think IP address, they think the dotted 4 octet without “%ZZZZ” appended. I’d still like to know if there are products that actually make use of the zone?

See inline responses in the unsnipped email below.

From: netmod <netmod-bounces@ietf.org> on behalf of Andy Bierman <andy@yumaworks.com>
Date: Saturday, April 9, 2022 at 1:38 PM
To: Randy Presuhn <randy_presuhn@alumni.stanford.edu>
Cc: "lsr@ietf.org" <lsr@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

On Sat, Apr 9, 2022 at 9:51 AM Randy Presuhn <randy_presuhn@alumni.stanford.edu<mailto:randy_presuhn@alumni.stanford.edu>> wrote:
Hi -

On 2022-04-09 4:36 AM, Christian Hopps wrote:
...
> FWIW, I'm not arguing for this change; however, to be fair, isn't this
> also about the existing published modules that are using the incorrect
> type?

No.  "Incorrect type" is a bit of a mischaracterization.  It's like
saying using "int32" is incorrect if all that is needed is "uint16".
One might say its a little sloppy or mutter "RTFM" under one's breath,
but it's not "incorrect."

You and Martin convinced me the ip-address type cannot be changed.
There are other options.

If a YANG module is using ip-address, and the WG intent was really to
use ip-address-no-zone, then that module can be fixed with an Errata.
The modules should not need to be updated just for this incorrect typedef usage.

The type names are unfortunate but in the future this will not happen again.

Well, these are probably some of the most ubiquitous types in the YANG and forcing everyone to use the -no-zone types is more a tragedy than merely unfortunate.

Some modules have used a type that potentially can represent more
values than are needed for the intended purpose.  Whether those
implementations will ever accept or produce those values will
depend on whether the code, whether library, generated, or hand-
crafted, enforces the tighter constraints appropriate to the usage
or only the looser constraints appropriate to the type's specification.

But this is also true of every usage of any type where the use
can only exhibit a subset of the possible values of the type,
whether that subsetting is obvious from the description or not,
so I find it really hard to get excited about it.  The more nuanced
a repertoire of types becomes, the more likely developers won't
use exactly the right one, though one would hope that these foibles
are caught during the review process, at least until developers
start reading the documentation for the libraries they employ.

There are many examples where the pattern allows more strings
than the intended usage.  Also, a server can reject any request for any reason.

That does not address the conformance problem that Acee may be concerned about.
What is a server required to support for a leaf with type ip-address?
The text does not look like the zone index is optional for the server to accept.

Even in these cases of "incorrect" usage, as Andy and others
have pointed out, stuff still works, because those cases only
require a subset of the values supported by the type.  If the
proposed change is made, usages requiring the full value space of
the original type definition will break, and those formerly
"incorrect" usages will exhibit no change in their behavior.

It works because clients are not sending addresses with a zone index.
I agree with Martin that the NC/RC server is always obligated to reject a request
it cannot fulfill, regardless of the typedef.

I thought Martin said a server not supporting zone could accept the IP address and simply ignore the zone? This would seem to be a better options than using the -no-zone types.

That is, the proposed change does not improve operation of
anything, and it breaks some things.

yes -- too many years out in the wild this way to switch type names around now.

I know I may be being too pragmatic, but does anyone support zone via %zzzz?

Thanks,
Acee

For me, it's more important for stuff to work (and to not break
stuff) than it is to align perfectly with the underlying aesthetics
of some naming system attributed post hoc to a set of types.

Randy

Andy

_______________________________________________
netmod mailing list
netmod@ietf.org<mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod