Subject: [netmod] yang-08: changing a default

From: Andy Bierman <[email-masked]>
Date: Thu, 22 Oct 2009 08:47:08 -0700

Hi,

The rules for updating a module changed in -08.

It is unrealistic to forbid the addition of
a default-stmt.  The likely usage in standards
will be to add a default after a few years.

YANG forces every data modeler to know every appropriate
default on Day One of version -00.  This is absurd.
Why is YANG making this CLR?  It seems to me that
the price for letting the server hide YANG defaults
is way too high.

Server implementation of with-defaults removes the need
for saturating the language with all these CLRs.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 22 Oct 2009 22:46:52 +0200 (CEST)

> The rules for updating a module changed in -08.

This was based on your comments.  I thought we agreed that this was
necessary, b/c of typedef defaults and import w/o revision.

> will be to add a default after a few years.

Ok, so an alternative could be this:

  A "default" statement can be added to a leaf that does not have a
  default value (either directly or indirectly through its type).

Do we agree that a default cannot be modified?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 22 Oct 2009 14:07:18 -0700

>   default value (either directly or indirectly through its type).

A default can always be added to a leaf,
regardless of the default in the type-stmt.
It takes precedence over the typedef.

> Do we agree that a default cannot be modified?

yes

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 22 Oct 2009 23:12:43 +0200 (CEST)

> It takes precedence over the typedef.

Right, but the problem is, as you pointed out, if we have this:

  typedef foo {
    type int32; 
    default 42;
  }

  leaf bar {
    type foo;
  }

Now, bar has '42' as default value.

In the next rev we do:

  leaf bar {
    type foo;
    default 4711;  // we were allowed to add a default stmt
  }

The effect is that we modified the default value of bar, and we agreed
that you're not allowed to modify a default value.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 22 Oct 2009 18:25:33 -0700

>>>   default value (either directly or indirectly through its type).

OK -- this text is fine.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 23 Oct 2009 16:30:24 +0200

> Do we agree that a default cannot be modified?

Can someone remind me what the rationale is? Adding a default
statement causes an implementation that happens not to use the default
value to be non-compliant. We get the same effect if someone changes a
default value.

Note that adding a default statement to something that has already an
implicit default does not hurt if the value is the same...

/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: Andy Bierman <[email-masked]>
Date: Fri, 23 Oct 2009 07:51:08 -0700

> value to be non-compliant. We get the same effect if someone changes a

The server is compliant to the version
with the same revision-date that is advertised
in the <hello>.  There may be 50 new versions
of the data model that the server is not compliant with.  So what?

Let's say the ipfix leafs that end up with vendor-defaults
get implemented by several vendors.  After a few years,
the IPFIX WG notices that consensus has developed for
a particular default value.  It increases interoperability
to add a MUST requirement to the standard, such as a default.

Clients have to deal with micro-versioning in YANG.
If you assume the current revision that
you happen to implement is the only version
that could ever exist, your code may not work all the time.

A CLR preventing the addition of a default is not going to
lower client complexity 1 bit.  It will just raise
complexity for YANG writers.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 23 Oct 2009 17:00:08 +0200

> complexity for YANG writers.

I guess I did not express my question well. Trying again: If we allow
adding defaults (because version matters), why is it then forbidden to
modify a default?

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 23 Oct 2009 08:18:36 -0700

> adding defaults (because version matters), why is it then forbidden to

Oh -- I agree with you.
One open issue is whether modules MUST use revision-stmt.
If not, then *any* change made to a module is going to
potentially break the client.  The default-stmt is special
because YANG chooses to make it special, not because it is.

Andy