Hi,
(Note: Some or all of these issues may have been raised before.)
This is another aspect of YANG database behavior that
is very broken. Consider this old MIB design translation:
container toaster {
...
leaf toasterControl {
type enumeration {
enum up {
value 1;
description
"Abort toasting (perhaps in the event of
an emergency)";
}
enum down {
value 2;
description
"Begin toasting.";
}
}
// config true;
mandatory true;
description
"This variable controls the current state of
the toaster.";
}
}
Will YANG support operational knobs like this? (IMO, no.)
Clearly there is no intent to make the value 'sticky',
or to save it across reboots. MIBs are full of operational
knobs like this 'toasterControl' leaf.
One solution that is not optimal is
to create ad-hoc RPC verbs for every knob:
rpc make-toast { ... }
rpc cancel-toast { .. }
A better approach is an inline 'action-stmt' extension,
replacing the 'toasterControl' leaf with 'make-toast'
and 'cancel-toast' actions.
This is certainly not a system-created leaf.
The dual-leaf (admin/oper status) approach does not apply either,
because, in this case, the writable leaf is an operational button,
not persistent configuration.
How should YANG deal with this sort of leaf?
Andy
_______________________________________________
netmod mailing list
netmod at ietf.org
https://www.ietf.org/mailman/listinfo/netmod
