Subject: [netmod] Consensus call on yang-00750: add a "feature" feature

From: David Partain <[email-masked]>
Date: Fri, 17 Oct 2008 15:07:12 +0200

Greetings,

This is a call for consensus about issue 'yang-00750: add a
"feature" feature'.  See the wiki at
http://wiki.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang#issue-00750

This mail and other consensus calls after the interim will follow
a similar pattern.  First, we have the question and the proposed
consensus, then details.  The details include examples, followed
by a summary of the interim discussion on the issues.  Please
read the whole message.

PLEASE speak up if you favor or object to the proposed change,
including people who attended the interim.

A very simple high-level overview is below.  Note that this issue
was then split into two decisions:

1. Add 'if-feature', used to include nodes conditionally

   Rough consensus of the interim meeting: yes

2. Allow 'if-feature' to affect types conditionally (e.g.,
   conditionally include an enumeration).

   Rough consensus of the interim meeting: no

Details...

Feature clause with subclauses defines a feature to be used...

feature name {
 description
 references
 status
 if-feature
}

Conditional inclusion of a leaf based on a feature...

leaf f {
  if-feature name;
  .
  .
}

Conditional change of a type based on a feature....

typedef x {
  type enumeration;
    enum foo { if-feature name; }
}

Advertisement of a feature.  Given features n1,n2,n3:

<hello>
  <cap>uri?features=n1,n2,n3</cap>
</hello>

Features are connected to a module: One feature, one module.
However, 'if-feature' can refer to a feature defined in a
different module.

Ron Bonica asked: what if we don't have any of this?

Phil Shafer:  The problem is that the module is a contract and if
we don't have finer granularity, we cannot follow that contract.
That means we have to have a single module with separate modules
to augment that module in order to add the conditionality.

Furthermore, we (NETMOD) have a couple of groups using YANG that
want something like this in order to partition a module into
parts that are relevant for different implementations.  The
question is how we're going to meet that "market requirement"?

Andy Bierman thinks this will be useful in the context of the
IETF to allow them to define conditional parts of the module.

With respect to the question where can one use 'if-feature' for
altering types, the answer would be that it's all of the types
that are OR'd: unions, bits, enumerations.

Some concerns:

 - Andy Bierman is concerned that this looks good for simple
   things, but it might be complicated in the context of all of
   our conditional statements.

 - Martin Björklund is, on the other hand, worried that it might
   be too simple since it's not an expression (with ORs, for
   example).

 - Jürgen Schönwälder is concerned about propogation of features.
   For example:

   feature X {
   ...
   }

   typedef F {
     type enumeration {
       enum g { if-feature X; }
     }
   }

   Then, in a different module...

   import F {...}

     leaf a { type F; }  // dependent on Feature X!
     leaf b {
       when "a = g";
       ...
     }

 - Ladislav Lhotka proposed emulating this feature with existing
   functionality in the language rather than introducing a new
   language feature.

   container features {
     container foo {
       presense ...;'
       leaf enable {type boolean;}
     }

     container bar {
     }
   }

   and then use 'when' to introduced the conditionality.  The
   problem is that 'when' cannot refer to non-config data, which
   is what this is.  It is also the case that you won't be able
   to conditionally include enumerations, union parts, etc.

 - David Harrington thinks there are cleaner ways to do this and
   doesn't like that it looks like there are #ifdefs spread
   throughout the module.  He is concerned we're adding
   complexity to the language.  Instead, he thinks (1) use
   different modules (do things like they are now), (2) do
   something like what's in the SMI.

 - Andy Bierman thinks something like this will be useful in the
   context of the IETF to allow them to define conditional parts
   of the module.  He, however, was not convinced that this
   proposal is the right solution.

Conclusions:

 - There was rough consensus to include if-feature for
   conditional inclusion of data definitions.

 - There was NO consensus to include if-feature within data types
   (unions, enumerations,...).  This remains open.

 - Andy Bierman is going to work on a proposal to deal with more
   expressive conformance declarations as a complement to
   if-feature for conditional inclusion of data definitions.  He
   has the skeleton of a proposal that he will be send to the
   list.  There are things we want to be able to reflect about
   conformance for a data definition:

   * config
   * type restrictions
   * not supported
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 17 Oct 2008 21:27:28 +0200

Hi,

I think it would be better to make the info about available features a
part of the  configuration database:

1. It is simpler, no new features in both YANG and NETCONF are needed, 
   just minor changes of YANG rules (for instance, allow non-config 
   nodes in when expressions).
2. The existence of an feature can be checked at any time, not only    
   from the hello message. (What if a feature appears during a session, 
   e.g., via hot swap?)

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 17 Oct 2008 21:38:54 +0200 (CEST)

Hi,

I support this change.

/martin

---

From: Balazs Lengyel <[email-masked]>
Date: Sat, 18 Oct 2008 10:28:26 +0200

>    conditional inclusion of data definitions.
I support this.
>    (unions, enumerations,...).  This remains open.
I  support this. It could be useful when making backward compatible updates to my models.
I support both as presented by the diff-draft.
Balazs
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod