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

From: Kent Watsen <[email-masked]>
Date: Wed, 6 Sep 2017 17:34:30 +0000

[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.

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 06 Sep 2017 20:05:45 +0200 (CEST)

>     to chase down the submodule when trying to understand the

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.

>     importing it (e.g., to resolve XPaths), that otherwise may

This is a major drawback!

> 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

---

From: Lou Berger <[email-masked]>
Date: Thu, 7 Sep 2017 10:40:48 -0400

On 9/6/2017 2:05 PM, Martin Bjorklund wrote:
>> ...

> This is a major drawback!
I think this is a compelling consideration.

>>     the 'module' statement, so what else can we do?

I think a pro is that for models that are not widely implemented or
referenced, they are more aligned with how we expect new NMDA-compatible
models to be structured.

> approach in some cases, but in the majority of cases not.
I'd go the other way on this: the deprecate/obsolete/update approach
should be followed for the few modules that are widely referenced.  All
other modules should be replaced (via a name change) with NMDA
structured modules.

> For the routing modules, I don't think a new name is worth it.
Do you see it as widely implemented?  Do others agree?

>> often it's been imported by other drafts, etc.  Thoughts?
...

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 7 Sep 2017 14:54:18 +0000

Ok - it is less painful if we only have to deprecate the *-state nodes.
However, what about secondary and tertiary implications of moving to NDMA?
If we change a path from “interface-state-ref” to “interface-ref” to
reference an interface, I’d hope no one would expect the old statement to
be kept around… 

Thanks,
Acee 

On 9/7/17, 10:40 AM, "netmod on behalf of Lou Berger"
<[email-masked] on behalf of [email-masked]> wrote:

>_______________________________________________
>netmod mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netmod

---

From: Kent Watsen <[email-masked]>
Date: Thu, 7 Sep 2017 19:30:44 +0000

Hi Acee,

> Ok - it is less painful if we only have to deprecate the *-state nodes.

Does this mean you're okay reposting your ID similar to Martin's?
I ask as a chair interested in starting the adoption process on
these nmda-update drafts.

> However, what about secondary and tertiary implications of moving to
> NDMA? If we change a path from “interface-state-ref” to “interface-ref”
> to reference an interface, I’d hope no one would expect the old
> statement to be kept around… 

But the old statement would be kept around, in its deprecated form.
Of course, the nmda-guidelines should cause those downstream modules
to be updated to NMDA as well, so hopefully just a short-lived issue.

Kent

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 7 Sep 2017 19:43:47 +0000

Hi Kent, 

>these nmda-update drafts.

I would hope this is not a prerequisite? We are evaluating how bad this
will be. I’d ask how many implementations there are of ietf-routing?
>to be updated to NMDA as well, so hopefully just a short-lived issue.

This could be really ugly and cascade if we are just using a different
path for a reference. Hopefully, all the old references are in deprecated
trees. Otherwise, I guess the new data leaf would need a unique name.

Thanks,
Acee

---

From: Kent Watsen <[email-masked]>
Date: Thu, 7 Sep 2017 23:28:26 +0000

> will be. I’d ask how many implementations there are of ietf-routing?

Yes, please provide this info when you have it.

> trees. Otherwise, I guess the new data leaf would need a unique name.

Indeed.  Let's see what the analysis reveals.

Kent

---

From: "Xufeng Liu" <[email-masked]>
Date: Fri, 8 Sep 2017 16:12:53 -0400

A consequence of this discussion, I have a question about writing a model to augment RFC8022bis or RFC7223bis:

The new augmentation model is NMDA compliant, but also requires immediate support for "in use" and "system created" information, as described in Sec 1.3 of the guidelines (https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01). 

In such a case, the relevant suggestions in the guidelines are:

(b) Write a non-NMDA module that mirror the NMDA module. 
    -- This cannot be done because we are augmenting RFC8022bis or RFC7233bis, which do not have the non-NMDA modules.

(d) It is RECOMMENDED to augment only the "/foo" hierarchy of the base model. Where this recommendation cannot be followed, then any new "state" elements SHOULD be included in their own module.

The question is about the (d) above. We seem have to augment the deprecated "/foo-state" branch, right? We would also have to use the deprecated “interface-state-ref”? 

Thanks,
- Xufeng

> -----Original Message-----
> From: netmod [mailto:[email-masked]] On Behalf Of Kent Watsen
> Sent: Thursday, September 7, 2017 7:28 PM
> To: Acee Lindem (acee) <[email-masked]>; Lou Berger <[email-masked]>;
> Martin Bjorklund <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [netmod] two options for removing /foo-state trees?
> 
> 
> >>I ask as a chair interested in starting the adoption process on these
> >>nmda-update drafts.
> >
> > I would hope this is not a prerequisite? We are evaluating how bad
> > this will be. I’d ask how many implementations there are of ietf-routing?
> 
> > path for a reference. Hopefully, all the old references are in
> > deprecated trees. Otherwise, I guess the new data leaf would need a unique
> name.
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 8 Sep 2017 20:17:59 +0000

Hi Xufeng, 

I’m hoping all our references to “interface-state-ref” will be in schema
nodes that are themselves being deprecated. Yingzhen is investigating.

Thanks,
Acee 

On 9/8/17, 4:12 PM, "Xufeng Liu" <[email-masked]> wrote:

>The new augmentation model is NMDA compliant, but also requires immediate
>support for "in use" and "system created" information, as described in
>Sec 1.3 of the guidelines
>(https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01).
>
>    -- This cannot be done because we are augmenting RFC8022bis or
>RFC7233bis, which do not have the non-NMDA modules.
>
>(d) It is RECOMMENDED to augment only the "/foo" hierarchy of the base
>model. Where this recommendation cannot be followed, then any new "state"
>elements SHOULD be included in their own module.
>
>The question is about the (d) above. We seem have to augment the
>deprecated "/foo-state" branch, right? We would also have to use the
>deprecated “interface-state-ref”?
>
>Thanks,
>- Xufeng
>