Subject: [netmod] Should deviations be deprecated and a real conformance statement replace it?

From: Andy Bierman <[email-masked]>
Date: Tue, 03 Apr 2012 04:03:37 -0700

Hi,

At the time they were done, I was very opposed to YANG deviations.
I think the YANG conformance model is way too simplistic, and
the total refusal to use deviations in actual deployments
only makes it worse.

SMIv2 has the ability for 1 module to create new and customized
conformance statements, for data in that module or other modules.
The concept of "the subset of the FOO-MIB required by the BAR-MIB"
is well understood in SNMP, but appears to be an unsolvable mystery
to the NETCONF WG.

Perhaps deviation-stmts are way too complicated for something that doesn't get used.
They also convey the completely wrong message "This module is incomplete".
The use case above is not supported.  Implementing them in yuma has
been a total waste of time.

YANG features are not suitable for this purpose.  They are transparent to
the language unless corresponding if-feature statements are used.
(Just like a #define in C has no affect unless it is used in a conditional
statement.)  Cloning a module so if-feature-stmts could be added
is not a good practice.

Conformance requirements can also change over time. (e.g. add IPv6 features).
New use cases and new consensus about optionality can occur.  There can actually
be 1 conformance statement per use-case, not per module.

NETCONF for Constrained Devices is a conformance issue.  We need a way to
specify particular subsets of ietf-netconf.yang that align with CM use cases:

    - conformance for read-only server (get-config)
    - conformance for full CRUD but only all at once (copy-config)
    - conformance for full CRUD but partial edits allowed (edit-config)

IMO, NETCONF Light is the wrong approach.  It is a spot solution
for 1 module to the general problem of module compliance.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 03 Apr 2012 14:27:36 +0200 (CEST)

Hi,

> is well understood in SNMP, but appears to be an unsolvable mystery

If you compare YANG and SMIv2, deviations should be compared with
AGENT-CAPABILITIES.  It was well recognized when we designed YANG that
AGENT-CAPABILITIES were not widely used.  Nevertheless, the WG felt
that it is better to clearly specify how implementations differ from a
standard, than to simply ignore the problem.

It is true that SMIv2 has a more flexible mechanism to specify
conformance levels, with its MODULE-COMPLIANCE macro.  In YANG, we
have if-feature.

> Perhaps deviation-stmts are way too complicated for something that

As long as there are few complicated standard models published, it
should be no surprise that deviations are not used.  Most devices use
vendor-specific models, and normally you don't deviate from your own
model.  

> YANG features are not suitable for this purpose.

I assume you now are talking about using features like the
netconf-light module use them?  If so I agree with you - it is a
misuse to use features like this.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 03 Apr 2012 05:59:40 -0700

On 04/03/2012 05:27 AM, Martin Bjorklund wrote:
> Hi,
>
> Andy Bierman<[email-masked]>  wrote:

You are right -- they are ACs, but advertised in-band in the <hello>.
That was supposed to be a feature, not a reason to never use them.

> conformance levels, with its MODULE-COMPLIANCE macro.  In YANG, we

YANG features are good for a small number of use-cases within a module.
Once you get lots of features, interactions between features, and refined use-cases,
they turn the module into a bowl of boolean spaghetti.

> misuse to use features like this.

yes

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 4 Apr 2012 18:32:22 +0200

> misuse to use features like this.

Would an augment if-feature address your concerns?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 04 Apr 2012 21:41:47 +0200 (CEST)

> Would an augment if-feature address your concerns?

No you can't add an if-feature to an existing node through
augmentation.  If you have an if-feature statement in an augmentation,
it affects the *augmented* nodes.

Since this would be a new protocol, I'd simply define a new URI with
query parameters in text, and send something like:

  <capability>
      urn:...:constrained-netconf?locking,subtree-filtering
  </capability>

/martin