[netmod] Re: YANG Versioning question - namespace version?

[Andy Bierman <[e-mail]>]

On Tue, Jun 18, 2024 at 1:53 AM Jürgen Schönwälder
<[e-mail]> wrote:

> The YANG naming scheme is (module, path). The XML namespaces are an
> XML serialization artifact.
>
> By promising backwards compatibility, the (module, path) naming scheme
> was sufficient (non-backwards compatible changes require to change either
> the module, the path, or both).
>
> The versioning effort proposes to evolve the current naming scheme
> to (module, path, version). This requires that in _all_ places where
> YANG-defined data is stored and processed, the version context needs
> to be made available, which essentially implies availability of the
> YANG library of the originating server plus code to process the same
> at all places where YANG-defined data is stored or processed and where
> robustness matters.
>
>

Versioning the namespace may be appropriate for a monolithic WEB API,
but YANG is modular, with lots of cross-references.  While it may be
trivial to
support GET or POST for many versions of a single WEB page, this is not the
case
for an API composed of 100s of modules.


/js
>

Andy


>
> On 18.06.24 08:22, Jan Lindblad (jlindbla) wrote:
> >
> > Kent,
> >
> >
> > I was recently asked why YANG module namespaces aren’t versioned.  For
> > example, the “1.0” at the end of this URI
> > "urn:ietf:params:xml:ns:yang:ietf-crypto-types:1.0”. The stated
> > concern was "because without this, then management of backward
> > compatibility becomes a nightmare.”
> >
> > In the very early days of YANG, we actually had a brief while when the
> > NS strings were composed just like that, with a sort of version number
> > at the end.
> >
> > To know that something is a new/different version of something else
> > you need two information elements. Something that indicates “sameness”
> > and something that indicates “newness”.
> >
> > When tracking files in git, the “sameness” typically comes from
> > keeping the same filename (even if git can handle file renames if
> > registered properly). In YANG, we didn’t want to rely on the filename,
> > since the module filenames are not necessarily globally unique, as the
> > thinking went. So the NS string serves as the sameness factor, and
> > must therefore not change. Basically, modules with different NS
> > strings are (considered) completely unrelated.
> >
> > To indicate “newness”, we depend on the revision statement in YANG. In
> > the Versioning Design Team, we have also been toying around with a
> > checksum to indicate newness, but that has not taken root.
> >
> > Theoretically, it would of course be possible to indicate both things
> > in the NS string by appending a version number at the end, but then
> > all clients and servers would have to agree on the convention/rule
> > that the characters after the last colon in the NS string need to be
> > processed differently. That ship has probably crossed the ocean by
> > now, but we could bring it up for YANG next.
> >
> > But I fail to see why our non-choice of this particular solution would
> > necessarily drive us into a nightmare. The necessary information is
> > available in the modules, just not in the NS string alone.
> >
> > Best Regards,
> >
> > /jan
> >
> >
> >
> > This convention was established prior to my becoming active in the
> > IETF, but my guess is that the reason is because the YANG-module
> > update rules in RFC 7950 Section 11 ensure backwards compatibility,
> > and hence the versioning the namespace would have no value. That said,
> > the YANG Versioning effort introduces the possibility of NBC changes,
> > which makes me wonder if this is something that should be discussed.
> >
> > Thoughts?
> >
> > Kent
> >
> >
> >
> > _______________________________________________
> > netmod mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> >
> >
> > _______________________________________________
> > netmod mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
> --
> Jürgen Schönwälder              Constructor University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>
> _______________________________________________
> netmod mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>