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
> <[email protected]> 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/
> <http://www.jacobs-university.de/>>
>
> _______________________________________________
> netmod mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/netmod
> <https://www.ietf.org/mailman/listinfo/netmod>
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
