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 <[email protected]> on behalf of Andy Bierman <[email protected]> Date: Saturday, April 9, 2022 at 1:38 PM To: Randy Presuhn <[email protected]> Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]> 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 <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
