"Acee Lindem (acee)" <a...@cisco.com> wrote: > Hi Martin, > > On 8/30/17, 6:28 AM, "Martin Bjorklund" <m...@tail-f.com> wrote: > > >Hi, > > > >Kent Watsen <kwat...@juniper.net> wrote: > >> 3. https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00 > > > >I found some trivial errors in this draft: > > > > o The revision for ietf-routing doesn't match the filename's date. > > > > o The filename for ietf-ipv6-router-advertisements is wrong (last > > "s" is missing) > > > > o All the old -state definitions are removed, rather than being > > marked as "deprecated". > > > 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. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
