On Wed, Oct 25, 2017 at 4:08 AM, Juergen Schoenwaelder < [email protected]> wrote:
> It seems we are jumping between topics. I will skip over comments > concerning the YANG library and whether it is OK or not OK that YANG > library allows different schemas in different datastores. > \ \ Actually, this is the only issue that matters. I decided that no special text is needed because the YANG library is violating a MUST requirement in RFC 7950 and needs to be changed. There can only be one implementation of a module per server, not per datastore. Therefore a module MAY appear in multiple module-sets, but it MUST NOT be different. The exact same revision, features, and deviations MUST be present in each instance. Andy > On Tue, Oct 24, 2017 at 11:21:54AM -0700, Andy Bierman wrote: > > On Tue, Oct 24, 2017 at 10:21 AM, Juergen Schoenwaelder < > > [email protected]> wrote: > > > > > On Tue, Oct 24, 2017 at 10:13:35AM -0700, Andy Bierman wrote: > > > > > > > > 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. > > > > > > There is nothing machine readable today that tells you which argument > > > of get-config identifies the datastore that is being accessed by > > > get-config. Our reasoning is that for most actions that default is > > > going to do the right thing. If there is a need to have further > > > language support to handle the cases where operations may relate to > > > datastores different than operational, then this should be taken up by > > > a future version of YANG. > > > > > > > > There is only 1 schema tree now in pre-NMDA so it is easy to parse > > instance data against the one and only set of modules. > > > > > > > > > > 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. > > > > > > I am not sure I parse this correctly. > > > > > > > The new YANG library requires the implementation to know the datastore > > to pick the correct set of modules for the datastore used in the > operation. > > Module sets are allowed to overlap, so the same module can be different > > in <running> vs. <operational>. > > > > Developers unaware of the new NMDA complexities should read the drafts > > again. > > > > > > > > > > > > > (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. > > > > > > Not sure I understand this either. > > > > > > If you have a concrete change proposal, perhaps the discussion becomes > > > more concrete and productive. > > > > > > > > > I already said to declare that <action> is invoked in <operational>. > Period. > > No description-stmt exceptions. > > > > If another datastore is needed, use rpc-stmt instead of action-stmt. > > So you are fine if for RPCs description statements can define which > datastores are affected by an RPC? I probably did not get that you > make a distinction between actions and RPCs here. > > /js > > -- > 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 list [email protected] https://www.ietf.org/mailman/listinfo/netmod
