Re: [netmod] <running> vs <intended>

[Martin Bjorklund <[e-mail]>]

Robert Wilton <[e-mail]> wrote:
> 
> 
> On 18/09/2017 19:25, Andy Bierman wrote:
> >
> >
> > On Mon, Sep 18, 2017 at 11:07 AM, Martin Bjorklund <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     Juergen Schoenwaelder <[e-mail]
> >     <mailto:[e-mail]>> 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