[changing subject line, was "upcoming adoptions"] We've been primarily focused on updating modules by deprecating the /foo-state tree in situ. This is what the nmda-guidelines draft said to do and is much of what the "status statement needed on every node" thread regards.
However, the RTG YANG DT put forward an alternate approach. The idea is simply, rather than deprecate the /foo-state tree, create a new module that leaves it out altogether. I'm assuming that rfc8022bis-00 reusing the same module name was an oversite, as it otherwise breaks YANG module update rules. And, to be complete about it, I'm assuming that rfc8022bis-00 should also republish the old module with *all* nodes marked deprecated, so that there's no confusion like that seen with the SMIv2 update. PROs: 1) the new module is more readable, as it doesn't have to carry-forward the deprecated (and later obsoleted) nodes forever. [rant: I don't understand why obsolete nodes can't be dropped after some amount of time - how does some future use of an old node name matter?]. Yes, the deprecated /foo-state tree could be put into a submodule, but that doesn't change the readability much, and actually might make readability worse, because the reader then has to chase down the submodule when trying to understand the 'include' statement. CONs: 1) a new module name may confuse those who have grown accustom to the old name. To help with this, the new name could follow some convention (e.g. *-2 or *-ex), but such conventions always seem hokey to me. 2) a new module name forces an update to other modules that importing it (e.g., to resolve XPaths), that otherwise may not need to be updated. 3) the approach doesn't follow what draft-dsdt-nmda-guidelines says in guideline (c), but this seems to be a minor point. 4) republishing the old module with all nodes deprecated seems off, but 7950 doesn't list 'status' as a substatement to the 'module' statement, so what else can we do? Any other pros or cons? Another question is if all the modules have to be updated the same way (which could block adoption of these drafts until we settled on an approach), or do we let each module update in a way that suites it best base on, e.g., how deployed it is, how often it's been imported by other drafts, etc. Thoughts? Kent // contributor >>>> Kent writes: >>>> 3. https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00 >>> >>> Martin writes: >>> o All the old -state definitions are removed, rather than being >>> marked as "deprecated". >> >> Acee writes: >> I’m glad you brought this up. We discussed this in the Routing >> YANG Design Team and were planning to discuss it on a wide scale. >> One of the advantages of the NMDA is that it makes the models >> easier to read and consume. This is somewhat negated if we have >> to retain all these data nodes in the associated modules and mark >> them as “deprecated”. What is the consequence of not including >> them? They are available in the previous version of the model >> if they are need for compatibility. > > It is fairly common that instead of removing functions from a > published API, you mark them as deprecated for some time, and then, > later, remove them (*). > > Note that since a server cannot implement two versions of a given > module, it has to decide which version to implement. There might be > other modules that use / augment the -state tree; if the server > implements the latest version w/o the -state tree, it cannot at the > same time implement these augmenting modules. > > (*) YANG inherits the deprecation model from SMIv2. We actually have > three states: current -> deprecated -> obsolete. And even when > something is obsolete, it is not removed. I guess in SMIv2 this was > necessary b/c of OID assignments; maybe this could be revisited for > YANG. But this would require an update to RFC 7950. > > If we think that a module becomes cluttered with all the deprecated > definitions, we can actually move them all to a separate submodule. _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod