Subject: [netmod] Proposed consensus on yang-01281: conformance

From: David Partain <[email-masked]>
Date: Wed, 29 Oct 2008 09:51:42 +0100

Greetings,

This is a call for consensus about issue
'yang-1281: conformance'.  See the wiki at
http://wiki.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang#issue-01281
for an introduction.

PLEASE speak up if you favor the changes or object to the text
(including people who attended the interim).

On Oct 3, Martin Björklund and Phil Shafer proposed how YANG
should handle conformance.  That proposal was published as a
delta of the current YANG draft.  Mail about the proposal can be
found at
http://www.ietf.org/mail-archive/web/netmod/current/msg01281.html

The discussion at the interim focused very heavily on so-called
deviations and (1) if they should be documented in a standardized
way and (2) if so, whether the proposal should be used.  (For
those familiar with SNMP, this is much like AGENT-CAPABILITIES
for SNMP.)

Do we want to be able to document where there are deviations
or not?  Discussion:

 * David Harrington: what is the economic incentive for vendors
   to document their deviations?  Andy agrees that this is not
   going to happen.
 * Jürgen Schönwälder: by the time we got to AGENT-CAPABILITIES
   in SNMP, the battle was already lost.
 * Martin Björklund: we want to make it possible to get the
   variations from the box.  Martin's tools actually can use
   the deviations to drive what their tools do.
 * David Partain: could the deviations be useful even if
   vendors don't produce the document?   e.g., user
   communities?
 * David Harrington: What about conditional compliance?  How do
   we handle that?
 * Andy Bierman: if this is done, wants to see it in a separate
   document, rather than as part of the YANG language
   specification.
 * David Harrington: the deviations might not be something
   within the charter.  Ladislav Lhotka said that we are the
   ones defining what's in the language, so we can make it in
   charter by making it part of the language.
 * David Partain: we're trying to provide three sets of input
   to the configuration management application - the module
   itself, the conformance level to which they conform, and the
   deviation files written by a vendor or by the user
   community, all to be able to drive the application better.
   "When we've run our applications against device foo, we've
   seen the following behavior" and document it formally as a
   deviation.  I would argue that this deviation fills exactly
   the same role as the AGENT-CAPABILITIES was supposed to
   fill.
 * David Reid: that's in theory a good thing and something that
   we still want, even if it hasn't been successful in SNMP.
 * David Harrington: the AGENT-CAPABILITIES has been shown not
   to work.  If you want to design something that does work,
   it's going to be difficult.  Maybe this should be done where
   benchmarking work can be done rather than in this working
   group.  Not our job to describe how they report how well
   something does work.  Mehmet Ersue: it's a report that you
   can't really verify.
 * David Partain: I think the deviations would be something
   built up internally within an operator.  Andy Bierman: yes,
   for internal documentation.  Phil Shafer: or the network
   service provider lists could exchange information about
   deviations on the list.
 * Mehmet Ersue: would this be optional?  Martin Björklund: yes.
 * Andy Bierman: this is at the level of release notes.  If
   there's a mandatory node in a data model, the deviation says
   it's not there, how will the application (client) actually
   continue to work?  Martin Björklund: mandatory isn't any
   different from any other deviation.  The client application
   can adapt to the fact of that deviation.
 * Andy Bierman : The text must state that deviations in no way
   state a level of conformance.  In fact, they mean you are
   NOT conformant.  Phil Shafer: I disagree.  If I have a node
   that doesn't have an upper bound and I advertise that I'm
   limited, that doesn't make me non-conformant.  There are
   going to be things that you can deviate on that do not
   automatically make yourself non-conformant.  Martin
   Björklund: we need to work out the details.
 * Ladislav Lhotka: why can't you define your model to deal
   with the deviations?  Andy Bierman: sometimes you should
   model things in the module itself that reflect the deviation
   (i.e., how to show what the current resource possibilities
   are for a table).  Martin Björklund: there might be hardware
   limits for a resource that should be reflected in the
   deviations.

Questions posed regarding this issue:

 1. Should there be a formal way of describing the deviations of
 a particular device?  There was rough consensus that we should
 have a formal syntax for documenting deviations.

 2. Should this work be done in this working group?  There was
 almost complete consensus that it should (David Harrington
 opposed.)

 3. Should the document say anything about how to organize these
 statements in a module?  A long discussion about whether to
 intermingle these statements with other language constructs.
 David Partain recommended that we state that one SHOULD put the
 deviations in a separate module.  Should we have a statement
 that says whether this should be in a separate module or not?
 Juergen: this is organizational; we shouldn't go there.  Editor:
 There is no documented consensus on this question.

 4. Are we reasonably happy with the syntax (with caveat that
 there is tweaking and clarification to be done)?  There was
 rough consensus that we start with the syntax as it currently
 is.

Cheers,

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 29 Oct 2008 10:35:33 +0100

Contributor opinions:

> -----Original Message-----
> From: [email-masked] 

...

>  1. Should there be a formal way of describing the deviations 
> of  a particular device?  There was rough consensus that we 
> should  have a formal syntax for documenting deviations.

I support this. 

> 
>  2. Should this work be done in this working group?  There 
> was  almost complete consensus that it should (David Harrington
>  opposed.)

I support doing it in this WG as part of NETMOD definition. 
 
> 
>  3. Should the document say anything about how to organize 
> these  statements in a module?  A long discussion about 
> whether to  intermingle these statements with other language 
> constructs.
>  David Partain recommended that we state that one SHOULD put 
> the  deviations in a separate module.  Should we have a 
> statement  that says whether this should be in a separate 
> module or not?

Having missed the 'long discussion' I am not sure I understand all the
details and arguments, but putting deviations in a separate module makes
more sense to me. 

> rough consensus that we start with the syntax as it currently  is.

Good starting point. 

Dan

---

From: David Reid <[email-masked]>
Date: Wed, 29 Oct 2008 15:58:48 -0400

>  a particular device?  

Yes.

> 
>  2. Should this work be done in this working group?

Yes.

>  statements in a module?  

I like David Partain's recommendation to say one SHOULD put the
deviations in a separate module.

>  there is tweaking and clarification to be done)?  

This is a good starting point.

-David Reid