On Sat, Apr 9, 2022 at 9:51 AM Randy Presuhn < [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. > 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. > 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. > 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] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
