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. /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
