Subject: [netmod] database + defaults = broken

From: Andy Bierman <[email-masked]>
Date: Tue, 01 Sep 2009 09:03:28 -0700

Hi,

There are several places in the draft where special
definitions of the database are given for XPath:

  o  The accessible tree is made up of all nodes in the data tree, and
      all leafs with default values.

-------------------------

module X {
   namespace "http://example.com/ns/X";
   prefix X;

   leaf x {
     type int32;
   }
}

1 year later ...

module X {
   namespace "http://example.com/ns/X";
   prefix X;

   leaf x {
     type int32;
     default 10;
   }
}

-------------------------

This is legal YANG.
Revisions are optional, and a default can
be added over time.

The client needs to manage old servers and new servers.

Client retrieves /x:

  <get>
    <filter type="xpath"
     xmlns:x="http://example.com/ns/X"
     select="/x:x" />
  </get>

The server responds with no data:

  <data/>

So -- is the client talking to an old server
that just doesn't have this leaf, or a new
server that is using the YANG default?
It could be either, and that is broken.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Tue, 1 Sep 2009 15:20:29 -0400

>Revisions are optional, and a default can

The overriding rule is:

   ... However, changes are not allowed if they have any potential
   to cause interoperability problems between a client using an
   original specification and a server using an updated specification.

Proposals:

(a) Default statements cannot be added in new revisions of a module.

(b) Default statements cannot be added in new revisions of a module
unless that module contains a revision statement.

(c) No changes can be made to a module unless it contains a revision
statement.

(b) and (c) could be done with by changing:

   For any published change, a new "revision" statement (^revision^)
-  SHOULD be included in front of the existing revision statements.
+  MUST be included in front of the existing revision statements.

or making two classes of ways a module can be changed, and requiring
revisions for any changes with a potential to cause interoperability
problems.

Thanks,
 Phil

---

From: David Partain <[email-masked]>
Date: Wed, 2 Sep 2009 16:28:04 +0200

> +  MUST be included in front of the existing revision statements.

Greetings,

I would be in favor of this change (SHOULD to MUST).  I like clarity about 
revision history.

David

---

From: Andy Bierman <[email-masked]>
Date: Wed, 02 Sep 2009 08:09:11 -0700

> I would be in favor of this change (SHOULD to MUST).  I like clarity about 

I agree -- I wanted it to be MUST at the interim meeting.

The complete list of accurate module capabilities in the <hello>
is also a MUST, or none of this actually works.
The name 'foo' in deviations=foo or import foo
is useless without a namespace URI to go with it.

If we are going to tightly couple the YANG language
to the NETCONF protocol, let's at least do it right.

Andy