Hi,
On 29/11/2016 15:54, Juergen Schoenwaelder wrote:
On Tue, Nov 29, 2016 at 03:37:29PM +0000, Bogaert, Bart (Nokia - BE) wrote:
Hi,
We’re trying to figure out how to prevent a NC client from changing the type of an interface. Assume that we have an interface stack defined and the lowest layer of the stack (the physical interface) is of type fastdsl. In principle a NC client can send an edit-config to the server and change the type of that interface to something else. It is still a valid YANG model but it does not make any
The description for the "type" leaf in ietf-interfaces says:
If a client tries to set the type of an interface to a value that can never be
used by the system, e.g., if the type is not supported or if the type does not
match the name of the interface, the server MUST reject the request.
[Bart Bogaert] Ok. That is very clear but the NETCONF server can only reject
if 1. there are rules in the YANG model that allow this, 2. An external
application involved in the transaction tells the NC server in the box that
this change is not allowed. We are actually looking for a solution whereby the
client, by using the device YANG model, can know (from YANG rules) that this
change is not allowed. For now I have not found such a solution to express
this in YANG. Having these kind of checks hidden from the client actually
makes the device less programmable as the client needs to have a connection
with the device. For devices that are not always on and the client wants to
accept changes on behalf of the device (which get forwarded when the device is
powered up again) it would be good to have a great deal of certainty that the
already accepted configuration by the client will also be accepted by the
server.
There will always be errors possible - assuming a 'client' can
accurately predict all possible errors that can occure when a
configuration is applied on a server is somewhat hopeless. That said,
a server could perhaps announce a deviation that restricts the
possible set of values. But for anything more advanced than a simple
home router where you have hot swappable interfaces, this likely falls
apart quickly again.
Not every configuration that is valid according to YANG validation
rules and constraints is guaranteed to be applied successfully on a
given server with specific resources. With deviations, a server may
announce additional constraints that it has and client side tools may
make use of these deviations to do additional checks before attempting
an edit-config but the ultimate truth is when you send the edit-config
to the server and the change finally gets applied - or not.
There are other cases where values can be set, but once set they cannot
be changed.
Part of me would like to suggest a YANG extension that can be used on a
leaf to indicate that its value cannot be changed unless a specified
parent node is deleted. E.g. in this case the extension could indicate
that the configured interface itself must be deleted if the type is changed.
But perhaps the real judgement call here is whether the additional
complexity involved with adding such an extension is worth the benefit
that it brings over a well worded description.
Further, I'm not even sure that it is a given that for all interfaces on
all devices that the interface type can never change. So, I suspect that
most YANG clients will just end up being hard coded to know not to try
and change the type of interface (unless it is allowed). The simple
approach might also be the best ...
Rob
/js
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
