On 18/09/2017 19:25, Andy Bierman wrote:
On Mon, Sep 18, 2017 at 11:07 AM, Martin Bjorklund <m...@tail-f.com
<mailto:m...@tail-f.com>> wrote:
Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de
<mailto:j.schoenwael...@jacobs-university.de>> 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.
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.
Thanks,
Rob
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.
/martin
Andy
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
