Subject: [netmod] operational knobs

From: Andy Bierman <[email-masked]>
Date: Sat, 31 Oct 2009 12:49:04 -0700

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 31 Oct 2009 16:40:22 -0400

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.

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

Yours,
Joel

Andy Bierman wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Andy Bierman <[email-masked]>
Date: Sat, 31 Oct 2009 14:57:12 -0700

> 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

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.

Andy