We ran into a version of this in the SUPA model. Every grouping has a
leaf with a default value (entity-class). That entity-lass value is
correct by default, and must not be changed.
However, it is also over-ridden in refines statements and its primary
use is in MUST clauses.
As such, it can not be config-false.
So we settled for a comment telling folks not to change it.
If there is a better answer, I would be happy to hear it.
Yours,
Joel
On 11/29/16 9:58 AM, 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 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
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
