Subject: [netmod] YANG conformance idea

From: Andy Bierman <[email-masked]>
Date: Wed, 06 Aug 2008 13:24:20 -0700

Hi,

This is a synthesis of the various proposals so far,
which avoids the complexity and unintended consequences
of Xpath and the redundancy of the SMIv2 conformance macros.

module acme {

   ...

   import if { prefix if; }

   ...

   feature acme1 {
     status current;
     description "";
     reference "";
   }

   ...

   conformance little-feature-set {
     status current;
     description "";
     reference "";

     uses-feature acme1;
     uses-feature acme2;
   }

   conformance big-feature-set {
     description "";

     uses-feature acme1;
     uses-feature acme2;
     uses-feature acme3;
     uses-feature if:if-basic;
   }
}

Instead of adding arbitrarily nested 'if-feature'
meta-containers, a new 'for-feature' sub-statement for the basic
objects declaring which feature is associated
with the entire subtree.   Just like SMIv2,
it is debatable whether or not an object has to be
part of a feature or is there a default.  Also,
are child nodes allowed to be in different features? (IMO, no)

module if {

  container interfaces {
    list interface {
      for-feature if-basic;
      ...
    }
    leaf ifNumber {
      // not part of any feature package
    }
    list ifStackTable {
       for-feature if-stack;
       ...
    }
  }

  feature if-basic {
    description "Basic interface parameters";
  }

  feature if-stack {
    description "Interface stack table support.";
  }

  conformance full-if {
    uses-feature if-basic;
    uses-feature if-stack;
  }

  conformance readonly-if {
    uses-feature if-basic {
      refine "/if:interfaces/if:interface/if:mtu" {
         config false;
      }
    }
  }

}

IMO, this builds on our SMIv2 experience without creating
a free-for-all in flexibility.

Andy

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

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 07 Aug 2008 23:08:40 +0200 (CEST)

Hi,

Andy Bierman <[email-masked]> wrote:
> with the entire subtree.

This is also how the if-feature statement me and Phil suggested in Dublin
would work.  Or did I misunderstand something?

> Just like SMIv2,

No.  I think a flat partitioning of the module into features covers
the magic 80% of the use cases.

>       refine "/if:interfaces/if:interface/if:mtu" {

I suggested three different types of variations of a module:

  1. variations defined in the module itself
    - e.g. partition the module into "features"
  2. sane implementation-specific variations
    - e.g. limits on max-elements due to hw limitations or
  3. insane implementation-specific variations
    - changing a leaf into a container

I think the discussion would benefit from concentrating on which
variations we would like to support (if any) in the different
categories.

It seems we agree that partitioning the module falls into category 1,
and that it is useful.  We also discussed having server-specific
defaults in category 1, but having "access-restricions" (changing from
config true to false) in category 2.  Is there a use case when this
clearly falls into category 1?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 07 Aug 2008 14:18:35 -0700

> would work.  Or did I misunderstand something?

I do not want if-feature to be nested.
I prefer to consider it a property I attach to
a container, list, leaf, etc., rather than adding
another unnamed meta-containment layer to the YANG 'tree'.

> clearly falls into category 1?

IMO, it should be up to the data modelers to decide what
the conformance levels for the module should be.

My conformance macro proposal allows features from other modules
to be included in the conformance requirements, which is
important in the IETF.  It also allows the DM writer
to decide how features relate to conformance requirements.
It allows the same feature (with different refinements)
to be included in different conformance levels.

Andy