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

From: Martin Bjorklund <[email-masked]>
Date: Thu, 05 Nov 2009 21:43:22 +0100 (CET)

Juergen Schoenwaelder <[email-masked]> wrote:
> On Thu, Oct 22, 2009 at 10:46:52PM +0200, Martin Bjorklund wrote:
>  
> > 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?
> 
> 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.

When a client creates say a list entry, it may choose to not give
values for leafs with defaults for the following reasons:

  1. it doesn't care about the leaf; it trusts the server to use a
     good default value.
  2. the default specified in the data model is the value it wants, so
     there is no need to send it.

If we just want to support case 1, but not 2, then we can allow any
changes to defaults.  If we want to support 2, we have threea options:

  a. do not allow addition or change of default
  b. do not allow changes to default, but allow addition
  c. require revision on all modules and submodules, and also require
     import and include by revision.

I think we have already discussed (c) and decided that it won't work.
(a) is what is in -08, but is probably too restrictive, and (b) is
the proposed text above.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Nov 2009 22:08:55 +0100

> (a) is what is in -08, but is probably too restrictive, and (b) is

So the argument is that adding a default is OK since there was none
before and fielded client applications thus can't rely on a specific
value. But even then, if a new client is written for the module
version that includes the default and it talks to an old server
predating the module revision with the default, things might break.
You will likely response that a client must be aware of the different
versions of a data model.

>From a practical perspective, I am concerned that we will see objects
that have a default that turns out to be a bad choice after a few
years and there is no way to fix this. And I also fear that we will
have clients that won't track all changes of data model revisions.

/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: Thu, 05 Nov 2009 22:15:36 +0100 (CET)

> versions of a data model.

This was never a use case we tried to handle.  If the client only
knows about the new data model, it might try to set leafs which don't
even exist on the server (since you are allowed to add leafs and other
nodes), (and more...)

> years and there is no way to fix this.

To solve this, it seems we need to require revisions, and
import/include by revision, but then...

> And I also fear that we will

... clients that don't track revisions won't work well.

So what is your suggestion?

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Nov 2009 23:18:52 +0100

> even exist on the server (since you are allowed to add leafs and other

OK, I admit to be undecided. But then, an attempt to create a leaf
that is not supported results in an error. Assuming a default that is
not known by the server causes surprises, and surprises are bad.

> So what is your suggestion?

I have no good answer. Perhaps all we can do are explicit warnings
that relying on defaults that get added after the publication of an
initial revision of a YANG module requires to do proper version
checking and if an application is not able to do that, to not rely on
the default being present. And perhaps guidelines^Hwarnings to data
model designer as well that defaults are final, you won't be able to
change them ever since applications are allowed to rely on it.

The only alternative would be to go back to the SMIv2 semantics where
defaults are not binding - which means you better set them expicitely
unless you trust the device to pick something reasonable (means I do
not care what is picked).

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 06 Nov 2009 17:26:45 +0100

> not known by the server causes surprises, and surprises are bad.

But the fact that there was no default in the old version can mean three
things:

1. The leaf was mandatory in the old version, so an error will be
reported if the client doesn't set the value.

2. The value is not used at all by the old server version, so it doesn't
matter what the client does to it.

3. The value is system-created by the old server version. Only this case
can lead to an undetected mismatch between the server and client.

IMO the only scenario for a reliable module evolution is 1. The
questions that have to be asked when the data model is being designed
are (i) whether the given parameter is operational or configuration, and
(ii) whether it is needed for server operation or not. If the answer to
either of these questions changes, it is not the same data model
anymore.

Lada
   
-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 Nov 2009 17:43:31 +0100

On Fri, Nov 06, 2009 at 05:26:45PM +0100, Ladislav Lhotka wrote:
> Juergen Schoenwaelder p????e v ??t 05. 11. 2009 v 23:18 +0100: 

But we are not discussing config true/false here - I think I do not
understand your answer. A default on config false has little value,
except for those who like to filter default values from config false
objects, which is not my concern.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 06 Nov 2009 18:05:53 +0100

> objects, which is not my concern.

I am just trying to understand what the acceptable (and likely) paths
are for module evolution, perhaps without the need for giving an exact
revision number.

The change of a leaf definition from mandatory=true to (mandatory=false
& new default definition) seems a natural way for establishing a data
model default based on operational experience, and it shouldn't cause
any serious interoperability problems. The change of the existing
default value is a different story though.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Fri, 06 Nov 2009 09:16:03 -0800

> either of these questions changes, it is not the same data model

The server most likely knows 1 revision of the module.
It will enforce the rules in that module.  If the leaf is
mandatory in the supported version, that is all that matters.

SMIv2-like CLRs to preserve backward compatibility don't
work very well in YANG.  IMO, a better implementation
strategy for the client is to construct the server's
view of the schema tree from the <hello> and avoid any
heuristics based on the CLRs in Sec. 10.  If the client
supports deviations, then the change-control rules are
totally irrelevant, since deviations don't follow any rules.

(It would help if revisions were mandatory to use.
The CLRs do not help at all for revision-less modules.
Nothing does.)

I prefer new option (d):

  d. require revision on all modules and submodules, and think about
     import-by-revision very carefully. The WG should understand how it will
     function within the IETF wrt/ all processes.  After there are specific
     recommendations for module reuse practices, then rules for import-by-revision
     may be appropriate.

> Lada

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 Nov 2009 20:05:47 +0100

> default value is a different story though.

There will be defaults created with the best intentions that will be
wrong when the underlying protocol evolves. There will be must
expressions created with the best intentions that will wrong when the
underlying technology evolves. This is all fine and the answer to such
situations is to obsolete definitions and to create new ones.

The original question was why adding a default is OK while changing a
default is not.

Martin took the position that changing a default might break a
contract between a client and a server. In the case where you add a
default, you can't break a contract since there was no defined
default. This is a reasonable position.

Andy argues that clients have to know the exact version of the data
model used by a given server (and its deviations) in order to do the
right thing. And yes, this is also a defendable position - but it
means that clients have to be pretty smart and be able to deal with
many different revisions (even in a single vendor product line). This
sets the bar of relying on defaults from the client side pretty
high. So if my client happens to care of the value (means it needs a
certain value - not that it is fine with whatever default value the
server will pick), it better sets the value even if the data model
promises the same default value in its data model. In other words, I
would very likely not take any advantage of the knowledge of a default
value on a client side since doing it correctly is way more effort
that is the saving's gain.

/js

---

From: Phil Shafer <[email-masked]>
Date: Fri, 6 Nov 2009 14:51:41 -0500

>that is the saving's gain.

Both are reasonable goals.  Is there a conflict?  If the previous
revision had no default, then the old client will always send a
value if it needs/wants to.  The default can move from unknown
to known, but not from known to known.

The primary issue with the "just make a new knob" is if the knob
is mandatory or referenced by must or when expressions, then it
must be set, even if ignored.

Perhaps what is really needed is two levels of revisions, the
compatible ones and the incompatible ones.  If you change the
default, the new revision is not compatible with the old one,
and clients (and users) should be warned.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Fri, 06 Nov 2009 13:02:21 -0800

> that is the saving's gain.

I don't really care about this CLR, except...

What about defaults in shared typedefs?
It seems like these can never be added,
because it will set the default for any leaf
already using that typedef (if the leaf does
not yet have one.)

So even if the leaf is 'protected' by import-by-revision,
a default cannot be added to the leaf without
cut-and-pasting the 'old' typedef contents into
the leaf, replacing the typedef usage.
I want to discourage cut-and-paste reuse.

The client will get confused if the shared
typedef adds a default, and the client ignores
the revisions advertised by the server.

The client will get confused if the shared
typedef adds a default, and the client ignores
the import-revision-dates in the modules
advertised by the server.

Is there a CLR that says a default can never be
added to a typedef?  I don't think so.
If not, then the CLR for the leaf-stmt seems pointless.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 07 Nov 2009 14:02:55 +0100 (CET)

> It seems like these can never be added,

Correct.  This has never been allowed in the draft.

> added to a typedef?  I don't think so.

The section "Updating a Module" lists all allowed changes.  Adding
default to typedef is not listed.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 09 Nov 2009 12:47:17 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> any serious interoperability problems.

This is also covered by the proposed update, repeated here again:

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

We already have:

- A "mandatory" statement may be removed or changed from "true" to
  "false".

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 09 Nov 2009 12:54:27 +0100 (CET)

Andy Bierman <[email-masked]> wrote:
> work very well in YANG.

That's exactly what Section 10 "Updating a module" specifies.  Are you
suggesting we remove that section?

I think these rules work (and FWIW, at our company we have some
implementation experience from using them).

> IMO, a better implementation

I think it would be ok to change the SHOULD in section 10 to MUST:

OLD:

  For any published change, a new "revision" statement (^revision^)
  SHOULD be included

NEW:

  For any published change, a new "revision" statement (^revision^)
  MUST be included

>      recommendations for module reuse practices, then rules for

I think text about import / include by revision should go into the
usage guidelines document.  At least some text that says "think
carefully about it!", preferably with some guidelines on what impact
an import-by revision has. 

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 09 Nov 2009 22:50:40 +0900

> - A "mandatory" statement may be removed or changed from "true" to

My point was rather that these two should mostly be used together -
otherwise, an optional leaf without any default that gets a default in
the next version looks suspicious and probably indicates the server used
some value behind the scenes in the old version, which should be banned.
Or is there any use case for such a situation?

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 09 Nov 2009 15:03:50 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:

> [...] the server used

I don't think this should be banned.  I hope I don't re-open the
endless discussions we already had, but I think we agreed that this is
perferctly legal:

   leaf destinationPort {
      type inet:port-number;
      description "If not configured, the device uses the default port
        number for IPFIX, which is 4739 without transport layer
        security and 4740 if transport layer security is activated.";
    }

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 09 Nov 2009 23:45:39 +0900

>         security and 4740 if transport layer security is activated.";

Yes, but in this case I'd require that the server write the value to the
configuration. If this happens, we can consider the destinationPort leaf
mandatory - it must always exist in a valid configuration, either
provided by the client or server.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C