Subject: Re: [netmod] ietf-yang-smiv2

From: David Reid <[email-masked]>
Date: Thu, 05 Jan 2012 17:17:12 -0500

> > Hi,
> > 
> > Martin Bjorklund <[email-masked]> wrote:
> > > This makes me wonder what the 2119 language tries to convey in this
> > > document.  What does interoperability mean for this spec?  The text
> > > says that it is used for:
> > > 
> > >    enabling read-only access to data objects defined in SMIv2 MIB
> > >    modules via NETCONF
> > 
> > The document says that all nodes MUST be config false, which is
> > natural since the interoperability goal is read-only access.  But I
> > think we should allow implementations to mark nodes as config true, in
> > an implementation dependent manner.  This would not affect our
> > read-only interoperability goal.
> > 
> > We already know from this ML that some vendors (including myself) will
> > provide config true access to parts of the MIBs.  (We're using a bunch
> > of directives to the compiler to control which parts).  As the
> > document is written today, the output from my tool is non-compliant,
> > but I do not think this is necessary.
> > 
> 
> Our tool also allows config true under some conditions.

I don't think we ever reached a conclusion on this topic. I don't have a
good answer, but my current implementation uses config true for some objects,
which is non-compliant. Is there a way we can soften the MUST be config false
statement such that config false is all that is required, but config true is
not considered non-compliant?

-David Reid

---

From: Andy Bierman <[email-masked]>
Date: Thu, 05 Jan 2012 14:27:51 -0800

On 01/05/2012 02:17 PM, David Reid wrote:
>>> Hi,
>>>
>>> Martin Bjorklund<[email-masked]>  wrote:

Unless you can define a standard algorithm for deciding when to generate config true
instead of config false, I don't think this can go into the draft.   IMO, if a user adds special
extensions to the SMIv2 file (or the translator config), then it is implicitly requesting a
non-standard translation, so it is OK if it does not follow the 'config false' rule all the time.

> -David Reid

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 05 Jan 2012 23:48:31 +0100 (CET)

Andy Bierman <[email-masked]> wrote:
> instead of config false, I don't think this can go into the draft.

Can you elaborate on why it would be a problem to allow this?

Earlier in this thread I wrote:

  A client can only rely on config false for full interoperability,
  just like today, I don't want to change that.  So if a client that
  knows a module w/ config false gets a capability with the right
  namespace and revision, it knows how to <get/> from the server,
  regardless of how many config trues that server is using.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 05 Jan 2012 15:04:43 -0800

On 01/05/2012 02:48 PM, Martin Bjorklund wrote:
> Andy Bierman<[email-masked]>  wrote:
>    namespace and revision, it knows how to<get/>  from the server,

I do want to allow this.  So you want to punt on the issue of a user
knowing what a 'standard' translator will generate?

IMO, a plain, default translation is all config false.

All YANG tools have to deal with config true or false, so there is no reason
to restrict the SMIv2 translation output to config false.  Perhaps the draft
can mention somehow that 'plain SMIv2' always generates config false,
and it is outside scope of doc, but tool may allow proprietary mechanisms
to generate config true for some or all objects.

Andy

---

From: David Spakes <[email-masked]>
Date: Thu, 5 Jan 2012 19:16:25 -0500 (EST)

On Thu, 5 Jan 2012, Andy Bierman wrote:

> Unless you can define a standard algorithm for deciding when to generate
> config true instead of config false, I don't think this can go into the
> draft.  IMO, if a user adds special extensions to the SMIv2 file (or the
> translator config), then it is implicitly requesting a non-standard
> translation, so it is OK if it does not follow the 'config false' rule
> all the time.

At one time, the task of coming up with such an algorithm seemed daunting.
However, now that we have collapsed the containment down to a single level
(and maybe no levels for scalars), shouldn't it be much easier?  e.g.,

   1. If the SMIv2 OBJECT-TYPE macro invocation has a SYNTAX of
      "TestAndIncr", do not translate it to a YANG data tree leaf;

   2. Otherwise, if the SMIv2 OBJECT-TYPE macro invocation has a
      MAX-ACCESS of "read-only", it MUST be translated to a YANG data
      tree leaf with a "config false" substatement;

   3. Otherwise, if the SMIv2 OBJECT-TYPE macro invocation is
      translated as a YANG data tree leaf, it MUST have a
      "config true" substatement.

There may be some other corner cases besides the TestAndIncr TC that
may need special consideration, but that's the only one I can think of
at the moment.

I believe the RowStatus TC does not need to have special consideration in
the translation.  However, the spec should note the following about
RowStatus:

  (a) the state machine is meaningless to a NETCONF client; and,

  (b) a NETCONF server interacting with an SNMP engine should be
      prepared to handle the transitions properly in order to apply a
      correct configuration.

-dss

-------------------------------------------------------------
 David Spakes                       email:   [email-masked]
 SNMP Research                      voice:   +1 865 573 1434
 3001 Kimberlin Heights Road          fax:   +1 865 573 9197
 Knoxville, TN  37920-9716  USA      http://www.snmp.com
-------------------------------------------------------------

---

From: David Reid <[email-masked]>
Date: Fri, 06 Jan 2012 00:00:23 -0500

> > translation, so it is OK if it does not follow the 'config false' rule

Does that mean my non-standard translation would need to use a different
namespace? I really want to produce a translation that is interoperable
with other translations for read-only operations, but also allows config
true for clients using the same translated module.

> (and maybe no levels for scalars), shouldn't it be much easier?  e.g.,

I don't care if we come up with a standard algorithm or not. All I want
is a way for my implementation to have writable objects without the
entire translation being considered non-compliant because it has some config 
true nodes.

-David Reid

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 Jan 2012 08:24:43 +0100

>       prepared to handle the transitions properly in order to apply a

My understanding is that the NETCONF and SNMP persistency models are
fundamentally different. With SNMP, you have lots of writable knobs
and whether changes are persistent or not is either not specified or
hidden in DESCRIPTION clauses or implied by the usage of storage type
conventions. With today's NETCONF operations, writing always means
editing a configuration datastore and not some operational state.
Note also that YANG has config true/false which is not the same as
writable true/false.

To do a single data model that can drive both NETCONF and SNMP
properly, I believe one needs several extensions to YANG that go well
beyond what we have (and it would likely also require to work out how
to deal with operational state and in particular writable operational
state in NETCONF properly).

/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: Fri, 06 Jan 2012 22:03:39 +0100 (CET)

> true for clients using the same translated module.

The way we do this now (not yet released) is that we generate the
config false module, and an additional module (with another namespace)
with deviation statements, changing config from false to true on the
proper nodes.  Then the deviation module is advertised as specified in
6020.

A client that uses the same translated module + the same deviation
module, will be able to use the config true nodes.

A client that uses the same translated module, maybe from another
compliant implementation, but without the deviations, will be able to
<get/> the nodes that he thinks is config false.  The only potential
problem is what the client does when it sees the deviation module it
doesn't know about... my guess it will just work since most clients
won't care about the deviations ;)

/martin

---

From: David Spakes <[email-masked]>
Date: Fri, 6 Jan 2012 17:29:44 -0500 (EST)

> won't care about the deviations ;)

I have been thinking about a solution similar to yours, Martin, but
one that does not require that the creation of an additional module of
deviations.

What I propose is that
  if a NETCONF client and server both understand smiv2:max-access,
  then for any object that is "config false" and either
     "smiv2:max-access read-write" or
     "smiv2:max-access read-create",

  1. the NETCONF server can decide at run time to deliver the
     object in response to a <get> or <get-config> operation; and,

  2. for any object that is returned for a <get-config>, the
     NETCONF client can configure that object in an <edit-config>
     operation.

Essentially, this is a protocol change between two capable and
consenting NETCONF communication partners.  There is a precedent
for this in the RFCs:

  RFC 6241 describes a base NETCONF capability,
  "urn:ietf:params:netconf:base:1.1" (Section 8.1 on Page 50).

  RFC 6242 describes a use-case of the NETCONF agreeing to use a
  common capability that results in a protocol change
  (Section 4.1, on Page 5).

What I propose is that we should define a new NETCONF capability
to be used in conjunction with smiv2:max-access.  The document
should describe its use-case as I have outlined above.

There are some other benefits to this approach:

  1. If either NETCONF client or NETCONF server does not support
     the max-access capability, then the protocol works the "normal"
     way with respect to "config false"; i.e., the server will only
     return these objects in response to a <get>, and the server
     will not accept these objects as part of an <edit-config>.

  2. When a NETCONF server that understands smiv2:max-access
     communicates with two clients--one that does understand
     smiv2:max-access and one that does not understand
     smiv2:max-access--it negotiates the common set of features
     separately for each communication session.  The server can
     behave differently (appropriately) for each client.

  3. The server does not need to send a bunch of deviations in
     the <hello> message that some clients would not care about.

  4. Some implementations may implement read-write objects as
     read-only.  That's okay, because when the NETCONF client
     and NETCONF server both understand smiv2:max-access, the
     NETCONF server has the freedom to determine at run time
     whether it will return the "read-write" object in response
     to a <get> or <get-config>.  The 'max' in 'max-access'
     becomes a true upper limit rather than a hard requirement
     of the server's capabilites.

  5. The differences between NETCONF and SNMP persistency models
     only matter to applications that care about them and are
     prepared to deal with them.

-dss

---

From: David Reid <[email-masked]>
Date: Mon, 09 Jan 2012 10:14:53 -0500

>      prepared to deal with them.

Could we put something in the document to indicate that proprietary mechanisms
to allow config true for some objects is OK so that things like what Martin
is doing or what David Spakes is thinking about are not considered 
non-compliant?

-David Reid

---

From: Andy Bierman <[email-masked]>
Date: Mon, 09 Jan 2012 07:56:14 -0800

On 01/09/2012 07:14 AM, David Reid wrote:
>>> David Reid<[email-masked]>  wrote:
>>       object in response to a<get>  or<get-config>  operation; and,
>>
>>    2. for any object that is returned for a<get-config>, the
>>       NETCONF client can configure that object in an<edit-config>
>>       operation.
>>
>>
>>       return these objects in response to a<get>, and the server
>>       will not accept these objects as part of an<edit-config>.
>>
>>       the<hello>  message that some clients would not care about.
>>
>>       to a<get>  or<get-config>.  The 'max' in 'max-access'

I do not support this change.
I do not see a lot of value in this standard if every 'compliant' implementation can
produce a different outcome for a core YANG statements like config-stmt.

The argument "a client can only count on read-only" doesn't really make sense to me.
What client?  A YANG-aware client will just use the valid YANG it is given
and may know nothing about the source SMIv2.  An SMIv2-aware client will expect
the NETCONF translation of its SNMP operations to work, and read-only does not help.

The config-stmt cannot be ignored by the server, even if a client can "just use <get>".

It seems to me the most interesting use-case is a device which provides SNMP
access or NETCONF access to the same data model.  Key word: 'same'.
Converting the MAX-ACCESS incorrectly is pointless for this use-case.

So what is the use-case for blanket read-only?
Is it supposed to be "NETCONF access to SNMP monitoring data"?
Is anybody implementing that?

Andy

---

From: David Spakes <[email-masked]>
Date: Mon, 9 Jan 2012 11:56:19 -0500 (EST)

On Mon, 9 Jan 2012, Andy Bierman wrote:

> > Could we put something in the document to indicate that proprietary
> > mechanisms to allow config true for some objects is OK so that things
> > like what Martin is doing or what David Spakes is thinking about are
> I do not see a lot of value in this standard if every 'compliant'
> implementation can produce a different outcome for a core YANG
> statements like config-stmt.
>
> The argument "a client can only count on read-only" doesn't really make
> sense to me. What client?  A YANG-aware client will just use the valid
> YANG it is given and may know nothing about the source SMIv2.  An
> SMIv2-aware client will expect the NETCONF translation of its SNMP
> operations to work, and read-only does not help.
>
> It seems to me the most interesting use-case is a device which provides
> SNMP access or NETCONF access to the same data model.  Key word: 'same'.
> So what is the use-case for blanket read-only? Is it supposed to be
> "NETCONF access to SNMP monitoring data"? Is anybody implementing that?

The situation is actually "NETCONF access to SNMP state data and SNMP
configuration data".

The blanket read-only is intended for applications that are YANG-aware
but not SMIv2-aware.  Like Juergen pointed out, with today's NETCONF
operations, writing always means editing a configuration datastore and
not some operational state.

Applications that are SMIv2-aware are going to attempt to do something
useful with the smiv2: extensions.  I don't want to see application
developers needing to do something proprietary in this case.  I would
much rather see this document open the door on a standards-based approach.

I think having the smiv2:max-access extension is a superb design because
applications that are only YANG-aware can ignore it.  My proposal that
this document also define a NETCONF "capability" is a logical extension
of this same thread of compromise.  NETCONF clients that do not support
the capability never see the SNMP configuration data as anything other
than "config false".

-dss

---

From: Andy Bierman <[email-masked]>
Date: Mon, 09 Jan 2012 09:56:00 -0800

On 01/09/2012 08:56 AM, David Spakes wrote:
...
> the capability never see the SNMP configuration data as anything other

I don't think any capability is needed.  The client can use the same source YANG
file as the server (with the smiv2:max-access statements in it).  The standard translation
can always generate 'config false' (with no exceptions).  An application that chooses
to pay attention to smiv2:max-access will work.  The conceptual config-stmt
can always be correctly derived by the application, since the translator tool must put the the smiv2
extensions in the output YANG file.

Andy

---

From: David Spakes <[email-masked]>
Date: Mon, 9 Jan 2012 15:24:53 -0500 (EST)

On Mon, 9 Jan 2012, Andy Bierman wrote:

> I don't think any capability is needed.  The client can use the same
> source YANG file as the server (with the smiv2:max-access statements in
> it).  The standard translation can always generate 'config false' (with
> no exceptions).  An application that chooses to pay attention to
> smiv2:max-access will work.  The conceptual config-stmt can always be
> correctly derived by the application, since the translator tool must put
> the the smiv2 extensions in the output YANG file.

What do you mean by the application "will work"?

A NETCONF-centric SMIv2-aware application is going to be expected to
modify SNMP configuration data.  The question that several of us are
asking is, how does such an application edit "config false" values
and do it in a way that is compliant with the spec?

Are you suggesting that it is compliant for a NETCONF client and server
with knowledge of smiv2:max-acccess to treat some "config false" leaf
objects as though they are "config true" without exercising some other
mechanism like a deviation or NETCONF capability?

-dss

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 09 Jan 2012 22:36:57 +0100 (CET)

Hi,

>      NETCONF client can configure that object in an <edit-config>

[...]

> should describe its use-case as I have outlined above.

I have two concerns with this idea.

1.  The client has to do a <get-config> in order to know which nodes
    are config; data model information only is not enough.

    Suppose there's a list that a server treats as config, but it is
    currently empty.  It won't be part of <get-config>, so the client
    doesn't know it is config, and cannot create anything in it.

2.  It is weird if client A advertises the new capability, sends a
    <get-config> and gets some data,
    but client B (assuming same access rules) gets a subset of this.

    This breaks the backup/restore use case.  The only safe way to get
    the complete config db is to advertise the new capability, so
    essentially if a server implements this capability, clients must
    also implement it to function properly.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 09 Jan 2012 22:41:56 +0100 (CET)

Hi,

> is doing or what David Spakes is thinking about are not considered 

My deviation-based solution does not require any changes to the
current document.  In fact, if we put in words that allowed a server
to implemnet some nodes as config, I wouldn't have to use my
deviations at all!

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 09 Jan 2012 13:53:11 -0800

> What do you mean by the application "will work"?

It can use the smiv2:max-access statement to figure out what the device will support,
or the server can use deviation statements to patch in the config true statements as needed.

> mechanism like a deviation or NETCONF capability?

The deviations would be needed in order for the server to advertise the
YANG module with altered config-stmts.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 09 Jan 2012 23:00:08 +0100 (CET)

> It can use the smiv2:max-access statement to figure out what the device will

The problem is that max-access >= read-write does not imply that it is
config.  Also, it is *max* access; an SNMP agent may implement some of
these objects read-only.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 09 Jan 2012 14:04:33 -0800

> to implemnet some nodes as config, I wouldn't have to use my

I think the deviations solution is fine.
Or a vendor can edit the file as needed, change the revision-date,
and advertise the 'update' instead of the direct translation.

I do not agree that simply allowing translators to ad-hoc generate config true instead
of config false is an inter-operable solution.  The output of this standard is the
YANG module, not the server implementation of the YANG module.  Two independent
implementations of the standard translator should produce equivalent results.

The deviations approach is a good start, and maybe in the future there can be additional
mechanisms for standard translators to produce config true.

Andy

---

From: David Spakes <[email-masked]>
Date: Mon, 9 Jan 2012 17:36:53 -0500 (EST)

> > to implemnet some nodes as config, I wouldn't have to use my

One of my concerns about the deviation-based solution is that software
that implements it is not considered to be compliant to the spec.

RFC 6020, Section 7.18.3, Page 103:

   Device deviations are strongly discouraged and MUST only be used as a
   last resort.  Telling the application how a device fails to follow a
   standard is no substitute for implementing the standard correctly.  A
   device that deviates from a module is not fully compliant with the
   module.

I believe this text was written for the case that an implementation can't
meet the minimum requirements of the YANG contract.  However, Martin's
implementation goes beyond the contract to provide additional abilities
that are not specified in the contract.  It seems unfair to Martin that
his approach might be considered by some to be non-compliant according
to RFC 6020.

Now, if the ietf-yang-smiv2 included a paragraph that states explicitly
that going beyond the contract in this case is not considered to be
non-compliant, then all is well.  Is everyone comfortable adding such
a paragraph?

> and advertise the 'update' instead of the direct translation.

You are suggesting that a leaf can be changed from "config false" to
"config true" in a subsequent revision?  I didn't think that was allowed
by the YANG spec...

> I do not agree that simply allowing translators to ad-hoc generate
> config true instead of config false is an inter-operable solution.

The solution I proposed would allow the translation to always be
"config false".  The document would define the NETCONF capability
in order to leave the door open for implementations to do <edit-config>
on objects that are "smiv2:max-access read-write" or
"smiv2:max-access read-create".

> The output of this standard is the YANG module, not the server
> implementation of the YANG module.

Right.  The mechanism that NETCONF clients and servers use to accomplish
edits on "config false" leaf objects need not be spelled out in this
document.  Adding the aforementioned paragraph and/or defining the NETCONF
capability just leaves the door open for this eventuality.

> Two independent implementations of the standard translator should
> produce equivalent results.

Two independent implementations of the standard translator should
produce the equivalent YANG document from the same SMIv2 document.

> The deviations approach is a good start, and maybe in the future there
> can be additional mechanisms for standard translators to produce config
> true.

Which is where my compromise proposal comes in.  This document just
props the door open with regard to this point.

-dss

---

From: Andy Bierman <[email-masked]>
Date: Mon, 09 Jan 2012 15:25:20 -0800

> On Mon, 9 Jan 2012, Andy Bierman wrote:

I think YANG deviations already provides a solution.
I think the original charter scope (read-only translation) is still appropriate.
IMO, the standard says the translation is read-only.  That is what a compliant
translator must produce.

As for editing the file, I meant that a vendor would never advertise
the original, so there would not really be a 2nd revision.  But deviations
are the standard approach.

Andy

> in order to leave the door open for implementations to do<edit-config>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Jan 2012 16:12:48 +0100

> non-compliant, then all is well.  Is everyone comfortable adding such

I would be comfortable with that.

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 10 Jan 2012 08:12:59 -0800

> I would be comfortable with that.

I strongly oppose this approach.
The config-stmt is a rather important detail in the YANG translation.
Implementations of the standard translation algorithm need to generate
the same YANG module for a given input SMIv2 module.

The standard has no value to users if there is no chance of a replacing one implementation
of the standard with a different one.

If the WG thinks read-write and read-create access needs to be covered in the
standard, then come up with a standard solution.  IMO, read-only + deviations
is a good first step.

IMO, tool vendors do not need this 'free pass' text added.
An implementation must be capable of producing the all-read-only translation.
That doesn't mean it cannot also be capable of generating a custom non-standard translation
using proprietary mechanisms.

There is no value whatsoever in the 'conceptual' translated version of the FOO-MIB if there is no
agreement on the config-stmt values within FOO-MIB.yang.  There needs to be a canonical, correct
translation for every possible SMIv2 module.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Jan 2012 17:18:04 +0100

> the same YANG module for a given input SMIv2 module.

It does.

> of the standard with a different one.

This works.

> standard, then come up with a standard solution.  IMO, read-only + deviations

This is what this was about.

> using proprietary mechanisms.

Either I am confused or you are.

> translation for every possible SMIv2 module.

There is.

/js

---

From: David Spakes <[email-masked]>
Date: Tue, 10 Jan 2012 11:26:09 -0500 (EST)

> the same YANG module for a given input SMIv2 module.

Andy, no one is suggesting that the YANG module needs to be generated
any differently.

The topic being discussed is simply about adding a paragraph to the
ietf-yang-smiv2 document that states Martin's use of deviation is
considered to be compliant.

> The standard has no value to users if there is no chance of a replacing
> one implementation of the standard with a different one.
>
> If the WG thinks read-write and read-create access needs to be covered
> in the standard, then come up with a standard solution.  IMO, read-only
> + deviations is a good first step.

You just said that the deviation approach is good in this case.  So
let's put that language in a paragraph and add it to the document and
I think we're done here.

-dss

> IMO, tool vendors do not need this 'free pass' text added. An
> implementation must be capable of producing the all-read-only
> translation. That doesn't mean it cannot also be capable of generating a
> custom non-standard translation using proprietary mechanisms.
>
> There is no value whatsoever in the 'conceptual' translated version of
> the FOO-MIB if there is no agreement on the config-stmt values within
> FOO-MIB.yang.  There needs to be a canonical, correct translation for
> every possible SMIv2 module.
>
> >
> > /js
> >
>
> Andy
>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 10 Jan 2012 08:35:07 -0800

On 01/10/2012 08:18 AM, Juergen Schoenwaelder wrote:
...

> Either I am confused or you are.

It must be me.

So you want a paragraph that says that the SMIv2 translation to YANG MAY include deviation statements
for config statements, and that a compliant translator is allowed to generate these deviation statements?

OK -- that is fine with me.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 10 Jan 2012 08:40:20 -0800

> On Tue, 10 Jan 2012, Andy Bierman wrote:

sorry -- I misunderstood your comment about going beyond the contract to mean
the contract to generate all-read-only.  In general, standard-output + deviations
is the correct YANG solution, and implementors may find more than 'config true/false'
that needs to change sometimes.

Andy

---

From: David Spakes <[email-masked]>
Date: Tue, 10 Jan 2012 12:56:47 -0500 (EST)

On Tue, 10 Jan 2012, Andy Bierman wrote:

> sorry -- I misunderstood your comment about going beyond the contract to
> mean the contract to generate all-read-only.  In general,
> standard-output + deviations is the correct YANG solution, and
> implementors may find more than 'config true/false' that needs to change
> sometimes.
>
> So you want a paragraph that says that the SMIv2 translation to YANG MAY
> include deviation statements for config statements, and that a compliant
> translator is allowed to generate these deviation statements?
>

With the addition of the paragraph, then I am in agreement as well.
I withdraw my previous suggestion about adding a NETCONF capability.

Re-reading everyone's previous comments, I think we are in rough
concensus.

Are there any details that need to be discussed from Martin's message
on Friday (below)?

There is an issue that I would like clarity on.  According to the
current draft, in Section 4.1 (Page 8), "A top-level YANG container is
generated...and the container MUST be config false."  And in RFC 6020,
Section 7.19.1 (Page 105), "If a node has 'config' set to 'false', no
node underneath it can have 'config' set to 'true'.  Martin, does your
deviation module change the top-level YANG container from 'config false'
to 'config true'?

-dss

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 10 Jan 2012 20:57:03 +0100 (CET)

Andy Bierman <[email-masked]> wrote:
> include deviation statements

Just a note here - the correct way to do this is to generate the
deviation statements in another module, so that the server can
advertise the proper translated module with the deviation.  It must
not be legal to generate the deviation statements in the translated
module itself.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 10 Jan 2012 21:04:32 +0100 (CET)

Hi,

> deviation module change the top-level YANG container from 'config false'

Yes.  It generates 'config true' up in the hierarchy as needed.

(I found a bug or two in the handling of deviations in pyang in the
process, but I guess that's expected ;)

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 11 Jan 2012 10:04:58 +0100

> process, but I guess that's expected ;)

Martin,

if you deviate the top-level node to config true, you will in turn
have to add config false to all leafs that remain config false, no?
If this is the case, would we then perhaps make life simpler by having
explicit config false statements generated for the leafs, either in
addition to the top-level config false or as a replacement of the
top-level config false?

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 11 Jan 2012 11:18:14 +0100 (CET)

> have to add config false to all leafs that remain config false, no?

I don't think I have to do that, but unfortunately the rfc is a bit
unclear in this case.

The config statement sets the "config" property on the node, and this
property is inherited by child nodes.  The deviate statement modifies
the config property on the specified node only.

By example:

  container a {
    config false;
    container b;
    container c;
  }

gives the tree:

  a  { config=false }
  |
  +- b  { config=false }
  |
  +- c  { config=false }
 
and applying a deviation:

  deviation /a {
    deviate replace {
      config true;
  }
  deviation /a/b {
    deviate replace {
      config true;
  }

gives the tree:

  a  { config=true }
  |
  +- b  { config=true }
  |
  +- c  { config=false }

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 11 Jan 2012 11:35:00 +0100

> and applying a deviation:

Not sure how I read that out of RFC 6020. But even if this is what RFC
6020 intends to mean in this case, you would have to create
config=true deviations all the way from the top-level down to the
affected leaf in the schema tree (and I guess that is what you are
doing).

Since RFC 6020 seems unclear and this is kind of a subtle point, we
might need explicit text explaining how this would work. It is likely
difficult to find a good example...

/js

---

From: David Spakes <[email-masked]>
Date: Wed, 11 Jan 2012 10:02:08 -0500 (EST)

> addition to the top-level config false or as a replacement of the

I was also going to make this suggestion.  I think for clarity with
the deviations, it would be better to move the config false statements
to the leaf statements.  The text for bullet 6 in Section 4.1 would need
to change.

> affected leaf in the schema tree (and I guess that is what you are

I was thinking about this topic when I composed my message on
January 5th (below).  I equated collapsed hierarchy with a simpler
algorithm because there are fewer levels of config inheritance.

-dss

On Thu, 5 Jan 2012, David Spakes wrote:

> > Unless you can define a standard algorithm for deciding when to
> > generate config true instead of config false, I don't think this
> > can go into the draft.
...
>
> At one time, the task of coming up with such an algorithm seemed
> daunting. However, now that we have collapsed the containment down to a
> single level (and maybe no levels for scalars), shouldn't it be much
> easier?  e.g.,
>

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 11 Jan 2012 16:15:22 +0100 (CET)

Juergen Schoenwaelder <[email-masked]> wrote:
> Not sure how I read that out of RFC 6020.

That's what I meant; the RFC is unclear...

> But even if this is what RFC

Here's an example output from our tool that makes the
addressMapControlTable from RMON2-MIB configuration:

module RMON2-MIB-deviations {
  namespace "http://tail-f.com/yang/deviations/RMON2-MIB";
  prefix "rmon2-mib-dev";

  import RMON2-MIB {
    prefix "rmon2-mib";
    revision-date 2006-05-02;
  }

  revision 2012-01-11 {
    description
      "First version.";
  }

  deviation "/rmon2-mib:RMON2-MIB" {
    deviate replace {
      config true;
    }
  }
  deviation "/rmon2-mib:RMON2-MIB/rmon2-mib:addressMapControlTable" {
    deviate replace {
      config true;
    }
  }
  deviation "/rmon2-mib:RMON2-MIB/rmon2-mib:addressMapControlTable/rmon2-mib:addressMapControlEntry" {
    deviate replace {
      config true;
    }
  }
  deviation "/rmon2-mib:RMON2-MIB/rmon2-mib:addressMapControlTable/rmon2-mib:addressMapControlEntry/rmon2-mib:addressMapControlIndex" {
    deviate replace {
      config true;
    }
  }
  deviation "/rmon2-mib:RMON2-MIB/rmon2-mib:addressMapControlTable/rmon2-mib:addressMapControlEntry/rmon2-mib:addressMapControlDataSource" {
    deviate replace {
      config true;
    }
  }
  deviation "/rmon2-mib:RMON2-MIB/rmon2-mib:addressMapControlTable/rmon2-mib:addressMapControlEntry/rmon2-mib:addressMapControlOwner" {
    deviate replace {
      config true;
    }
  }
  deviation "/rmon2-mib:RMON2-MIB/rmon2-mib:addressMapControlTable/rmon2-mib:addressMapControlEntry/rmon2-mib:addressMapControlStatus" {
    deviate replace {
      config true;
    }
  }
}

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 12 Jan 2012 10:09:29 +0100

[...] 

>   deviation "/rmon2-mib:RMON2-MIB/rmon2-mib:addressMapControlTable/rmon2-mib:addressMapControlEntry/rmon2-mib:addressMapControlStatus" {

Does it really make sense to consider a RowStatus object a config true
YANG object? The values you can write in SNMP land are createAndGo,
createAndWait, and destroy. I would assume that NETCONF's edit-config
takes care of creating/deleting the list entry. Note that notInService
is a temporary state and such rows are garbage collected according to
the RowStatus TC definition. 

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 12 Jan 2012 12:11:29 +0100 (CET)

Juergen Schoenwaelder <[email-masked]> wrote:
> YANG object?

No, you're absolutely right.  It should *not* be deviated.

/martin