On Thu, Jul 13, 2017 at 7:28 AM, Kent Watsen <[email protected]> wrote:
> > > > >> Could all the presenters please have a slide on their module's NMDA > >> compatibility status? Things to consider: > >> > >> - is the operational state of configured values important? > >> - is there is a need to support system generated entries? > >> - note: if yes to either, the module SHOULD be NMDA-compatible. > >> is it? - is there a "-state" tree in the Appendix? > >> > > > >I find this confusing. I think modules should be default be > >NMDA-compatible. I also think -state trees should be avoided > >as much as possible. So the questions should be something like > >this: > If the module contains any config=false top-level subtrees (like the /foo-state container and nested config=false nodes) then the foo-state tree is needed. If all the config=false nodes are child nodes of a config node, then the foo-state stree should not be needed. It would be nice if the term "NMDA-compatible" was widely understood. There should be simple tests to determine if /foo-state is needed. > > > - Is the module NMDA-compatible? If not, why not? > > - Does the appendix include a -state tree? If so, why is > > it necessary and how to transition away from it? > > Yes, by all means, this is even more to the point. > > I thought the foo-state modules were supposed to be generated by tools, not defined in RFCs. Isn't the migration strategy the same for everybody? Remove the foo-state module and stop advertising it to the client (which is expected to use the operational datastore). Isn't it up to vendors and operators, not the IETF, when the foo-state module should be removed from a server implementation? Thanks, > Kent > > Andy > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
