On Tue, Jun 18, 2024 at 1:53 AM Jürgen Schönwälder <jschoenwaelder@constructor.university> 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 -- netmod@ietf.org > > To unsubscribe send an email to netmod-le...@ietf.org > > > > > > _______________________________________________ > > netmod mailing list -- netmod@ietf.org > > To unsubscribe send an email to netmod-le...@ietf.org > > -- > Jürgen Schönwälder Constructor University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > _______________________________________________ > netmod mailing list -- netmod@ietf.org > To unsubscribe send an email to netmod-le...@ietf.org >
_______________________________________________ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
