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 protected]] On Behalf Of Kent Watsen
> Sent: Thursday, September 7, 2017 7:28 PM
> To: Acee Lindem (acee) <[email protected]>; Lou Berger <[email protected]>;
> Martin Bjorklund <[email protected]>
> Cc: [email protected]
> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod

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

Reply via email to