Re: [netmod] operational knobs

[Andy Bierman <andy at netconfcentral.com>]

Joel M. Halpern wrote:
> While I do not know what the right answer is for YANG, let's not get too
> distracted by the SNMP answer.  The mechanism used for this sort of
> thing by SNMP is a kludge designed to work around the limitaiton where
> the only operations were get and set.
> 

Agreed -- but I view the IETF SNMP experience as more than
a distraction.  We are theoretically asking IETF WGs to stop
using SMIv2 and start using YANG to design data models.
I think the differences, and guidelines wrt/ those differences, are
relevant to a significant portion of the IETF community.

> Some sort of action semantics would seem the appropriate mecahnism for
> YANG / Netconf rpc.
> 

Agreed -- so a config=true leaf like this would be the wrong
YANG construct to use.  The description-stmt does not
override the N/Y meaning of config=true for commit/NV-save operations.

BTW, I don't see any real implementation barriers
to allowing actions (==inline rpc-stmt) or events
(-- inline notification-stmt) but everybody
has a different idea how this is supposed to work,
so we should leave it out of 1.0.


> Yours,
> Joel


Andy


> 
> Andy Bierman wrote:
>> 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
>>
>