On Sat, Apr 9, 2022 at 11:00 AM Acee Lindem (acee) <a...@cisco.com> wrote:
> 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? > > > I agree the YANG types should have been named differently, but it was not flagged as a problem 12 years ago.. > See inline responses in the unsnipped email below. > > > > *From: *netmod <netmod-boun...@ietf.org> on behalf of Andy Bierman < > a...@yumaworks.com> > *Date: *Saturday, April 9, 2022 at 1:38 PM > *To: *Randy Presuhn <randy_pres...@alumni.stanford.edu> > *Cc: *"lsr@ietf.org" <lsr@ietf.org>, "net...@ietf.org" <net...@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_pres...@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. > It must not be a real problem or it would not have taken 12 years to surface. The typedef is silent about ignoring an explicit zone index in an ipv4-address value. If that is allowed, then maybe existing modules do not need to change. IMO they do not need to change anyway, since a server can just reject an address with a zone index in it. I don't think the YANG author or reader is that burdened if '-no-zone' is added to the type name. > > > > > > 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. > Maybe. There is no text in the typedefs but descriptions in the leaf or other data node could specify this behavior, or it could be an implementation decision. > > > > 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? > We cannot get the full picture on this mailing list, after so many years. Maybe just a clarification in the typedef is needed - A server MAY ignore a zone index specified in an ip-address IMO a module SHOULD use ip-address-no-zone going forward, if the intent is to disallow a zone index. Some modules have already done so. > > > Thanks, > > Acee > Andy > > > > > 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 > net...@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
