On Thu, Apr 7, 2022 at 10:01 AM Martin Björklund <mbj+i...@4668.se> wrote:
> Andy Bierman <a...@yumaworks.com> wrote: > > On Thu, Apr 7, 2022 at 9:11 AM tom petch <ie...@btconnect.com> wrote: > > > > > From: Lsr <lsr-boun...@ietf.org> on behalf of Rob Wilton (rwilton) > > > <rwilton=40cisco....@dmarc.ietf.org> > > > Sent: 07 April 2022 10:25 > > > > > > I basically agree with Acee, and I think that we should do (b): > > > > > > b) Change the types as suggested and accept that doing so > breaks > > > modules where zone indexes are meaningful. > > > > > > <tp> > > > > > > I am concerned that such behaviour will damage the standing of the > IETF at > > > large. > > > > > > > > MAY for the client means MUST for the server. > > I'm not sure what you mean here. > > But I'm also not sure I understand what the real problem is. Just b/c > the type allows a zone doesn't mean that all leafs that use this type > MUST support a zone. Compare with the value "0.0.0.0". It is a legal > value according to the pattern, but it will not be valid in all places > where this type is used. And even when an implementation supports > zones, it will not accept all legal (according to the pattern) values > for the zone index. Perhaps the solution is to explain this > better in the description? > > > > But if no servers actually support it, because the YANG does not match > > the operational requirements, then is it really a MUST requirement? > > > > This seems like a bugfix, and the worst thing the IETF could do wrt/ > > standing > > is to force the world to change every module that imports the typedef. > > Since many people were not aware of the full syntax, it is not clear that > > the WG intent was to include a zone. > > It is pretty clear IMO that this was not a mistake. The text > explicitly says: > > The IPv4 address may include a zone > index, separated by a % sign. > > > > > Seems like a bugfix to a pattern, like we have done several times > already. > > I don't think this is a bugfix. > > So no change is needed? Is it an 'invalid-value' if the pattern accepts the string? The server can return 'operation-failed' or 'operation-not-supported' at any time already. The server is not supposed to ignore the extra characters though. > /martin > > Andy > > > > > Andy > > > > > > > > > We clearly laid down rules as to what updates were regarded as > compatible > > > so that authors of software could be confident that their work was > robust > > > and future-proof. We did it with SNMP, inter alia, and we have carried > > > that forward with YANG. To tear up that understanding , creating who > knows > > > how much disruption, can only harm the standing of IETF. > > > > > > Much has been said about how implementations have assumed that the > address > > > types do not include a zone but no evidence has been put forward for > that > > > assertion. > > > > > > I have always assumed that software uses libraries and that the > libraries > > > have been written with an understanding of the specifications such > that if > > > a zone is received over the wire in conformance with the specification > but > > > where the display, field or such like does not allow for a zone, then, > > > tolerant of what to accept, the zone is silently discarded and the > address > > > is used without the zone. But, like the assertion that keeping the > zone > > > will cause who knows what damage, I have not done the research to > > > substantiate that assumption. > > > > > > Tom Petch > > > > > > I appreciate that this is an NBC change, but I believe that this is the > > > most intuitive definition and is the best choice longer term. I also > note > > > that the base ipv4-address/ipv6-address types in OpenConfig (where > they use > > > the OC copy/version of inet-types and not ietf-inet-types) don't allow > a > > > zone to be specified and assumes the default zone. They have separate > > > types in cases where a zone is allowed to be specified, i.e., aligned > to > > > what (b) proposes. > > > > > > For modules that are using/wanting zones (if any), then they can > migrate > > > to the new explicit zone type. > draft-ietf-netmod-yang-module-versioning, > > > if it keeps its import "revision-or-derived" extension, would also > allow > > > such modules to indicate the dependency on the updated > revision/definition > > > of ietf-inet-types.yang. > > > > > > Of course, the description associated with the updated > > > ietf-inet-types.yang revision should clearly highly the > > > non-backwards-compatible change to the types. > > > > > > Rob > > > > > > > > > -----Original Message----- > > > From: iesg <iesg-boun...@ietf.org> On Behalf Of Jürgen Schönwälder > > > Sent: 07 April 2022 08:35 > > > To: Acee Lindem (acee) <a...@cisco.com> > > > Cc: l...@ietf.org; The IESG <i...@ietf.org>; netmod@ietf.org > > > Subject: Re: [netmod] [Lsr] I-D Action: > > > draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt > > > > > > Here is roughly what happened: > > > > > > - RFC 6020 (published ~12 years ago) introduced the ip-address > > > type. It included an optional zone index part since zone indexes > > > are necessary in certain situations (e.g., configuring services > > > listening on link-local addresses or clients connecting to services > > > listening on link-local addresses). > > > > > > - RFC 6991 (published ~9 years ago) added the ip-address-no-zone types > > > since people felt that it is useful to also an ip address type > > > without the optional zone part for situations where a zone is not > > > applicable. The name 'ip-address-no-zone' was picked since the name > > > ip-address was already taken. > > > > > > I understand that the names resulting from this evolution of the YANG > > > module confuse people not looking up the type definitions. Let me note > > > that using a type allowing for an optional zone for a leaf that never > > > needs a zone is not a fatal error (its like using an int where a short > > > is sufficient) while using a type not allowing for a zone for a leaf > > > that may need zones is a fatal error (using a short where an int is > > > required) requiring an update of the definition of the leaf to fix. > > > > > > What are our options? > > > > > > a) Do nothing and accept that types are called as they are. > > > b) Change the types as suggested and accept that doing so breaks > > > modules where zone indexes are meaningful. > > > c) Deprecate the types and create a new module defining new types > > > so that modules can opt-in to use better names. > > > d) Deprecate the -no-zone types and move back to have a single > > > type for IP addresses. > > > > > > Any other options? > > > > > > How are we going to pick between them? > > > > > > /js > > > > > > On Wed, Apr 06, 2022 at 09:02:23PM +0000, Acee Lindem (acee) wrote: > > > > Jürgen and netmod WG, +IESG, > > > > > > > > It is not just the IETF models that are using the inet:ip-address for > > > the standard IPv4/IPv6 addresses without zones. Every vendor’s native > > > models and the OpenConfig models use the base types and expect the > standard > > > IP address notation. If we don’t fix this, it is something that people > can > > > point to as another example of the IETF being out of touch with > reality. > > > > > > > > I thought about more, and it might make the backward compatibility > > > easier if we just leave the existing ip-address-no-zone, > > > ipv4-address-no-zone, and ipv6-address-no-zone types and add *-zone > types > > > for the remote possibility that someone actually wants to include the > > > zone. In the existing RFC 6991 BIS document, we could merely remove > the > > > zone from the ip-address, ipv4-address, and ipv6-address types and > classify > > > this as we would any other bug fix. While including the zone was the > > > original intent of the base types, this is what those of us who work on > > > software products would classify as a requirements bug. > > > > > > > > Thanks, > > > > Acee > > > > > > > > From: Andy Bierman <a...@yumaworks.com> > > > > Date: Tuesday, April 5, 2022 at 3:21 PM > > > > To: Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de>, > Andy > > > Bierman <a...@yumaworks.com>, Acee Lindem <a...@cisco.com>, " > l...@ietf.org" > > > <l...@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 Tue, Apr 5, 2022 at 12:02 PM Jürgen Schönwälder < > > > j.schoenwael...@jacobs-university.de<mailto: > > > j.schoenwael...@jacobs-university.de>> wrote: > > > > On Tue, Apr 05, 2022 at 10:03:25AM -0700, Andy Bierman wrote: > > > > > > > > > > > > The best outcome would be to fix ip-address to not include the > zone, > > > > > > introduce ip-address-zone, and deprecate ip-address-no-zone. My > take > > > all > > > > > > the is that all the existing usages do not require zone and this > > > would be a > > > > > > fix as opposed to a change. > > > > > > > > > > > > > > > > > I don't think this will harm our implementations. > > > > > The type is still string. The pattern will change but that is > handled > > > by a > > > > > library. > > > > > Whatever pattern is used will get handled the same way. > > > > > > > > Either a zone is allowed to be present or it is not, this does make a > > > > difference, its not a cosmetic change. > > > > > > > > > > > > True. The code will probably accept the pattern then fail trying to > use > > > the string. > > > > If the client sends the form with a zone. > > > > > > > > > > > > > > > > > > > > > The same problem exists for 'date' and 'date-no-zone' types, > > > > > but they are not used very much. > > > > > > > > Perhaps we should call types a, b, c, and so on - this may force > > > > people to read the descriptions. ;-) > > > > > > > > For some reason, the smarter the person, the less likely they are to > > > > read any of the documentation before using some software. > > > > I call it the "it should work the way I would design it" phenomenon > :-) > > > > > > > > You have to admit that Acee's suggestion is more intuitive than the > > > current > > > > definitions. > > > > > > > > Clearly an NBC change. > > > > IMO it is more useful to put some YANG extension magic in these > specific > > > typedefs > > > > than just bumping a major revision number. This is a great use-case > for > > > the version DT. > > > > > > > > There probably is no solution path where nobody has to change any > YANG > > > or any code > > > > and everything still works. > > > > > > > > > > > > > > > > /js > > > > > > > > Andy > > > > > > > > -- > > > > Jürgen Schönwälder Jacobs University Bremen gGmbH > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > Germany > > > > Fax: +49 421 200 3103 <https://www.jacobs-university.de/> > > > > > > -- > > > Jürgen Schönwälder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > Fax: +49 421 200 3103 <https://www.jacobs-university.de/> > > > > > > _______________________________________________ > > > Lsr mailing list > > > l...@ietf.org > > > https://www.ietf.org/mailman/listinfo/lsr > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
