Hi, I agree with Jan -- NACM already exists to prevent clients from accessing specific data nodes.
Andy On Tue, Nov 29, 2016 at 8:18 AM, Jan Lindblad <[email protected]> wrote: > Bart, > > Jürgen et al are of course right in what they say, but if you really want > to use YANG to enable a manager to know a priori what values are possible > for a particular leaf somewhere, that's easy too -- if you see the addition > of a new proprietary YANG module as a possibility. > > module device-limitations { > ... > container limitations { > must "not(/if:interfaces/if:interface[not(if:type='ianaift:fastdsl')])" > { > error-message "There must not be any interfaces that are not of > fastdsl interface type"; > } > } > } > > There are also ways to do similar things without hardcoding the value(s) > in the YANG, e.g. in factory default data or controlled by licenses. The > acceptable values would sit in a system controlled list (i.e. operator > writes prevented by NACM). > > /jan > > > On 29 nov. 2016, at 16:54, Juergen Schoenwaelder <j.schoenwaelder@jacobs- > university.de> 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. > > /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 > > > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
