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

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:netmod-bounces@ietf.org] On Behalf Of Kent Watsen
> Sent: Thursday, September 7, 2017 7:28 PM
> To: Acee Lindem (acee) <acee@cisco.com>; Lou Berger <lberger@labn.net>;
> Martin Bjorklund <mbj@tail-f.com>
> Cc: netmod@ietf.org
> Subject: Re: [netmod] two options for removing /foo-state trees?
> 
> 
> >>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.
> >
> > 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?
> 
> Yes, please provide this info when you have it.
> 
> 
> >>> 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.
> >
> > 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.
> 
> Indeed.  Let's see what the analysis reveals.
> 
> Kent
> 
> 
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod