> On 29 Nov 2016, at 16:37, Bogaert, Bart (Nokia - BE) <[email protected]> > 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
It's not hidden from the client, and the descriptions in YANG modules are normative. Yes, I understand you want a machine-readable rule but YANG simply cannot have a formalism for capturing all possible semantic constraints. One thing that might help a bit (at least make it more explicit) is to derive an identity from "interface-type", say "physical-interface", and state that interface types derived from it are read-only. Lada > 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. > > Bart > > Lada > >> sense any more. Is there a way to express in YANG that this type of change >> is not allowed rather than having some SW application in the device >> interacting with the NC server and responding with an error to avoid this >> change? The server just can’t ignore this change and leave the type as it >> was since then the client and the server are no longer aligned. >> >> Best regards - Vriendelijke groeten, >> Bart Bogaert >> Broadband-Access System Architect Data Contact number +32 3 2408310 >> (+32 477 673952) >> >> NOKIA >> Copernicuslaan 50, 2018 Antwerp, Belgium Fortis 220-0002334-42 VAT BE >> 0404 621 642 Register of Legal Entities Antwerp >> >> << >> This message (including any attachments) contains confidential information >> intended for a specific individual and purpose, and is protected by law. If >> you are not the intended recipient, you should delete this message. Any >> disclosure, copying, or distribution of this message, or the taking of any >> action based on it, is strictly prohibited without the prior consent of its >> author. >>>> >> >> _______________________________________________ >> netmod mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
