Robert Wilton <[email protected]> wrote: > > > On 18/09/2017 19:25, Andy Bierman wrote: > > > > > > On Mon, Sep 18, 2017 at 11:07 AM, Martin Bjorklund <[email protected] > > <mailto:[email protected]>> wrote: > > > > Juergen Schoenwaelder <[email protected] > > <mailto:[email protected]>> wrote: > > > On Mon, Sep 18, 2017 at 05:17:46PM +0100, Robert Wilton wrote: > > > > > > > > > No. I do not agree that the MUST in RFC 7950 can be removed. > > > > > I do not agree the architecture should update YANG at all. > > > > OK. > > > > > > I am with Andy here. <running> has always had the requirement to be > > > valid and we are not supposed to change that. Mechanisms for > > inactive > > > configuration or templating must be designed to be backwards > > compatible > > > I think. > > > > Ok. If we keep the requirement that <running> in itself must be > > valid, it just restricts the usefulness/expressiveness of inactive and > > template mechanisms, but it might be ok. > > > > I think that even w/o this requirement, the observable behavior for a > > client can be backwards compatible. For example, suppose we have an > > inactive access control rule that refers to a non-existing > > interface in > > <running>. If a client that doesn't know anything about inactive asks > > for the contents of <running>, our implementation removes the inactive > > nodes from the reply to the client. Only a client that opts-in to > > inactive will receive a reply with things that looks invalid if you > > don't take the inactive annotation into account. > > > > > > > > There are many ways that validation can fail because inactive nodes > > are present, > > and considered part of the validation. > > > > e,g, min-elements, max-elements, mandatory, unique. > > > > I think we all agree that validation on the enabled nodes is supposed > > to continue to work.
Yes. > > Here is an attempt at a backwards-compatible solution: > > > > 1) current <get-config> and <get> responses only include enabled > > nodes. > > 2) old-style <edit-config> operations do not alter inactive nodes > > 3) NMDA clients use <get-data>, not <get-config> or <get>. These > > responses > > include enabled and disabled nodes, so validation does not apply > > for <running> > > 4) new style <edit-config> (i.e. <datastore> parameter used) can alter > > any type of data node > //I think that inactive should always be an optional extension. Not > everything needs the additional complexity. > > Hence rather than tying this function to specific NETCONF operations, > I would suggest that there should be an extra parameter (like for > with-defaults) to allow a client to indicate to the server that a get > or edit request is using the "with-inactive" extension. > 1) The server should also have a capability (or perhaps a leaf defined > in YANG library) to indicate that it supports inactive configuration. > 2) If a client doesn't use the extra "with-inactive" parameter during > a get request then only active nodes are returned. > 3) If a client doesn't use the extra "with-inactive" parameter during > an edit-data request then the request cannot include an extra inactive > meta-data. The request is processed in a way that is equivalent to an > existing NETCONF implementation, but it may unknowingly remove some > inactive configuration (e.g. via a replace or remove operation on an > inactive node). Operations like create, delete, none, replace should > all treat an inactive target node the same way as in the node doesn't > exist (e.g. delete on an inactive node would return a "data-missing" > error), this ensures that the behaviour that an unaware client > observes is the same as the existing behaviour that it would expect > from a regular 6241 compliant NETCONF implementation. > 4) It a client makes a get request including the "with-inactive" > parameter then they also get the inactive nodes as well, marked with a > meta-data annotation. > 5) If a client makes an edit request including the "with-inactive" > parameter, then the inactive meta-data annotation can be used to label > inactive nodes. Inactive nodes are regarded as regular data nodes for > create/delete/replace/none operation error checking. > > I think that this approach is similar (perhaps even the same) as > Martin described. This is indeed how our implementation works (except I think we don't do 5; if the client sends an "inactive" attribute it doesn't have to also send with-inactive). > > Note that the YANG MUST rule still applies, because validation is only > > done on enabled nodes. > > It is only the response message representations that cannot be > > validated, not the contents > > of <running> on a server. So the question is how we can make sure that the text in the NMDA draft covers this yet-to-be-defined feature w/o having to define it now? We thought that the current text was sufficient, but do we have to make any changes to it? /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
