[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
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
