Subject: [netmod] ab comments on draft-linowski-netmod-yang-abstract-02

From: Andy Bierman <[email-masked]>
Date: Fri, 26 Mar 2010 13:17:34 -0700

Hi,

I am interested in this sort of work, but as an Experimental RFC.
I don't have any comments on the specific mechanisms, because
I do not really agree with the focus and motivation in section 1.2.
I like the concept of constraining an instance-identifier
(instance-type extension), but not complex types.
It is too much like XSD and RelaxNG. 

My use-case is to create tools that allow Python programmers
to work with constructs they understand, which are classes.

There could be a 'standard' set of CRUD operations
with a mapping to HTTPS/REST, a mapping to NETCONF, etc.

Also, I think this should not be done as YANG extension
statements, but using a new module type instead.
Any YANG keyword is allowed and has the same meaning,
except rpc --> def and notification --> event.
There should be a 1-way mapping to convert the syntax to YANG.

The following is on-the-fly -- not documented yet (sorry).
It is just to give an idea of an abstraction layer on top of
plain YANG that would address my use case. 

  class YangNode {
   
    abstract true;
    leaf id {
      public true;
      type instance-identifier;
    }

    def get {
      input { ... }
      output { ... }
    }

    if-config {
      def create {
        input { ... }
      }

      def update {
        input { ... }
      }

      def delete {
        input { ... }
      }
    }
  }

  class ManagedHardware {

    parent-class YangNode;
    abstract true;  // not the default

    // add fault detected notification
    event fault { ... }

    if-config {
      // add config-changed notification
      event config-changed { ... }
    }

    def reset {
      // adding optional reset method for all managed hw
      mandatory false; // the default
    }

    leaf serial-number { ... }  // normal data

    if-defined reset {
      leaf last-reset-time {
        type yang:date-and-time;
      }
    }
  }

Andy