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

[Andy Bierman <[e-mail]>]

On Thu, Apr 7, 2022 at 10:01 AM Martin Björklund <[e-mail]> wrote:

> Andy Bierman <[e-mail]> wrote:
> > On Thu, Apr 7, 2022 at 9:11 AM tom petch <[e-mail]> wrote:
> >
> > > From: Lsr <[e-mail]> on behalf of Rob Wilton (rwilton)
> > > <rwilton=[e-mail]>
> > > 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 <[e-mail]> On Behalf Of Jürgen Schönwälder
> > > Sent: 07 April 2022 08:35
> > > To: Acee Lindem (acee) <[e-mail]>
> > > Cc: [e-mail]; The IESG <[e-mail]>; [e-mail]
> > > 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 <[e-mail]>
> > > > Date: Tuesday, April 5, 2022 at 3:21 PM
> > > > To: Juergen Schoenwaelder <[e-mail]>,
> Andy
> > > Bierman <[e-mail]>, Acee Lindem <[e-mail]>, "
> [e-mail]"
> > > <[e-mail]>, "[e-mail]" <[e-mail]>
> > > > 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 <
> > > [e-mail]<mailto:
> > > [e-mail]>> 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: [phone]         Campus Ring 1 | 28759 Bremen |
> Germany
> > > > Fax:   [phone]         <https://www.jacobs-university.de/>
> > >
> > > --
> > > Jürgen Schönwälder              Jacobs University Bremen gGmbH
> > > Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> > > Fax:   [phone]         <https://www.jacobs-university.de/>
> > >
> > > _______________________________________________
> > > Lsr mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/lsr
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/netmod
> > >
>