Kent Watsen <[email protected]> wrote: > [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.
Well, the module with the include will be exactly as readable as a new module, with the addition of one line: include ietf-deprecated-routing-definitions; You can even add a comment to further explain teh deprecation. > 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. This is a major drawback! > 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 In general I'd say no. An entirely new module might be the right approach in some cases, but in the majority of cases not. For the routing modules, I don't think a new name is worth it. /martin > (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 [email protected] https://www.ietf.org/mailman/listinfo/netmod
