On Tue, Oct 24, 2017 at 8:34 AM, Robert Wilton <[email protected]> wrote:
> Hi Andy, > > To try and formally close this issue: We propose that no changes are made > to the NMDA draft. > > I think that you have raised two issues in this thread: > > > (1) All YANG actions in an NMDA server are invoked against <operational>. > > We generally agree that module defined actions, and module defined RPCs > and notifications, will generally apply to the operational state of a > system, but this won't necessarily universally hold. In particular it may > not hold for any YANG modules that are defining generic behaviour (e.g. > inactive configuration, templating solutions, I2RS, etc). We don't think > that this needs to be specified in the NMDA datastores draft, but would be > better documented in a future revision of YANG. > > > IMO the more complex NMDA is to implement, the less likely it will be implemented. If you want the tools to figure out the correct datastore(s) from description-stmts instead of something deterministic and machine-usable, NMDA is less likely to be implemented. Given that the same objects can be defined differently in each datastore in NMDA, it is especially useful to know which set of YANG modules applies, before parsing instance data against those modules. (2) Define <action2>: > > I'm not convinced that this is really required/helpful, given that most > actions are likely to only apply to operational. If it turns out that this > is particularly useful then I would propose that this is deferred until a > future revision of NETCONF, particularly because we are trying to keep the > NETCONF NMDA and RESTCONF NMDA drafts as small as possible. > > Is this OK? > The NMDA theme has been to declare things that are possible in pre-NMDA but not supported in post-NMDA to be not useful, so this can be left to vendors I guess. > Thanks, > Rob > > > Andy > On 18/10/2017 23:16, Andy Bierman wrote: > > > > On Wed, Oct 18, 2017 at 2:36 PM, Juergen Schoenwaelder < > [email protected]> wrote: > >> On Wed, Oct 18, 2017 at 01:26:30PM -0700, Andy Bierman wrote: >> > On Wed, Oct 18, 2017 at 7:36 AM, Juergen Schoenwaelder < >> > [email protected]> wrote: >> > >> > > On Sun, Oct 15, 2017 at 12:56:42PM -0700, Andy Bierman wrote: >> > > > > > >> > > > > > augment "/if:interfaces-state/if:interface" { >> > > > > > action reset { >> > > > > > description "Reset this interface"; >> > > > > > } >> > > > >> > > > Can you spot the NMDA problem above? >> > > > Actually, it exists for in-line definitions, not just augment. >> > > > >> > > > Once you collapse the interfaces-state tree into /interfaces, there >> > > > is no way to specify whether an action is intended for <operational> >> > > > or a configuration datastore, or all datastores. >> > > >> > > I think operations (both RPCs and actions) by default always execute >> > > in the context of the operational state datastore. This is consistent >> > > with the way we define the xpath context. An operation that operates >> > > on other datastores needs to carry this information in its semantics >> > > and typically requires special arguments to select the datastores >> > > affected. This is how <get-config> and <edit-config> work. Hence, a >> > > reset action defined for an interface by default applies to the >> > > operational state datastore. And this default makes likely sense for >> > > most actions and RPCs. >> > > >> > > If an action or RPC is expected to operate on a different datastore, >> > > the description must explain this and there may be a need to pass a >> > > datastore identifier to the operation. [Yes, in retrospect, one might >> > > have designed the protocol differently so that there would always be a >> > > datastore parameter at the protocol level but its too late for that.] >> > > >> > > >> > >> > IMO this needs to be simple and deterministic. >> > All YANG actions in an NMDA server are invoked against <operational>. >> > >> >> Well, yes, like all RPC operations - except that we have RPC >> operations that do act on other datastores. ;-) But the generic >> mechanism including any xpath contexts is against operational. If the >> semantics of the operation that say 'interpret parameter 5 as a >> datastore name and act on that datastore', well then this is what the >> designer wanted. This is how edit-config and friends work today. >> >> > > Except this approach is ad-hoc and sub-optimal. > That's why NMDA <get-data> is better (because it is extensible yet not > ad-hoc). > IMO an <action2> wrapper would be a good addition for a YANG update > > <action2> > <datastore>rd:running</datastore> > <top> > <foo> > <test-action> > ... > </test-action> > </foo> > </top> > </action2> > > It is better to keep the YANG model decoupled from datastores, > and use a protocol parameter to make it explicit. > > > /js >> > > > Andy > > >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> Fax: +49 421 200 3103 <http://www.jacobs-university.de/> >> > > > > _______________________________________________ > netmod mailing [email protected]https://www.ietf.org/mailman/listinfo/netmod > > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
