Re: [netmod] two options for removing /foo-state trees?

[Martin Bjorklund <[e-mail]>]

Kent Watsen <[e-mail]> 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.
> 
> 
>