Subject: Re: [netmod] conformance

From: Gerhard Muenz <[email-masked]>
Date: Sat, 04 Oct 2008 19:45:00 +0200

Martin, Phil,

I've read your proposal. From my point of view, both, features and
deviations are useful. However, I'm not an expert regarding possible
implications and resulting interoperability problems. Maybe, YANG cannot
prevent data model writer or implementor from doing stupid things anyway.

In the context of the IPFIX configuration data model, deviations allow
devices to report resource restrictions to the manager, for example the
maximum number of Selection Process instances as mentioned in
http://www.ietf.org/mail-archive/web/netmod/current/msg00792.html.
A common usage will be the addition of a max-elements statement to a
certain node.

I assume that resource restrictions lead to device-specific
configuration restrictions in other contexts as well. Deviations
provide a simple and flexible solution addressing this problem. Maybe
there are good reasons for not allowing deviations. But then alternative
mechanisms are needed to report resource restrictions.

Does YANG dictate that a manager application must adopt and respect all
deviations received in the hello message?
Understanding and interpreting arbitrary deviations may largely increase
the complexity of the application. So, you could specify:
- a device MUST report deviations but MUST NOT expect that the
deviations are adopted by the manager
- a manager MAY respect deviations
Then, the fallback option is that the device returns an error message
indicating that a certain configuration failed due to a deviation.

I see an overlap between features and deviations. Knowing that
deviations are possible anyway, module writers might become lazy and
"forget" to partition their module into reasonable features. But maybe
this falls into the category of "stupid things" that cannot be prevented.

Regards,
Gerhard

> Hi,
> 
> As input to the discussions next week, we have written down a proposal
> for how to handle conformance in YANG. 
> 
> Most of the proposal is included below.  For all the details,
> including new ABNF rules, see:
> 
> http://www.yang-central.org/tmp/draft-ietf-netmod-yang-01-with-conformance.txt
> 
> or the diff to the current version:
> 
> http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-netmod-yang-01.txt&url2=http://www.yang-central.org/tmp/draft-ietf-netmod-yang-01-with-conformance.txt
> 
> 
> Martin & Phil
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Phil Shafer <[email-masked]>
Date: Sat, 04 Oct 2008 21:47:05 -0400

Gerhard Muenz writes:
>Maybe, YANG cannot

Exactly.  You can't fix stupid, but deviations provides a means of
learning about implementation "short-comings", rather than telling
applications that it's fine to stay ignorant of these issues.

>deviations received in the hello message?

Nope.  I see these as advisory.  "Hello, my name is example.net and
here are my issues".  The application can "play thru" as though the
device never let it know and the result will be no worse than the
current state of affairs.

>this falls into the category of "stupid things" that cannot be prevented.

Features are part of the model and there's design and thought put
into them.  Deviations are the ugly little secrets that form the
negative side of engineering trade-offs.

Thanks,
 Phil