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.
/js
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
