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

[Jürgen Schönwälder <[e-mail]>]

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 -- [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