Subject: [Netconf] LL review of -with-defaults

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 02 Jun 2010 16:37:32 +0200

Hi,

I read the entire document, including the appendices.

General comments:

- I am not happy with the fact that the server reaction to edit-config
  depends on its basic with-defaults mode. This means that a NETCONF
  operation (or a series of operations) that succeeds on one server
  may fail on another, even if their _conceptual_ configuration is
  identical and they only differ in the basic with-defaults mode.

- The details of responses to get/get-config with filters (subtree or
  XPath) should IMO also be specified. For example, what if a filter
  explicitly specifies a node that has a default value?

- The wd:default attribute seems underspecified, especially when used
  in edit-config messages. Questions:
  1. Is it permitted to attach wd:default to non-leaf nodes?
  2. What if a (leaf) node with wd:default="true" specifies a value in
     its text that is different from the default?

Specific comments:

** Sec. 1.1
   - term "Default data": The last sentence "Default data is not kept
     in a configuration datastore." is not true for a report-all style
     database.
** Sec. 2.1.2
   To a casual reader, it may not be entirely clear what the title
   means. Martin already suggested some improvements, but perhaps it
   would be simpler to say at the beginning of Sec. 2 that the
   effective mode for a given data retrieval operation is selected
   either by the <wd:with-defaults> element (with a reference to
   Sec. 4.6.1) or, if <wd:with-defaults> is not present, by the   
   server's basic mode.
** Sec. 2.3.1
   What does it exactly mean that "the server set a data node"? Does
   it apply to an "embedded NETCONF client" that runs on the server?
** Sec. 3, second paragraph
   OLD
   "The server must accept the <with-defaults> parameter ..."
   NEW
   "A server which implements this specification must accept the
   <with-defaults> parameter ..."
** Sec. 3.1, third paragraph
   s/it is present/if it is present/
** App. A.2
   Does everybody agree that the "conceptual contents" has ALL data,
   including those that have not been set but have default values, as
   the example shows? If so, I don't understand why the edit-config
   behaviour has to differ.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Wed, 02 Jun 2010 08:05:24 -0700

>   identical and they only differ in the basic with-defaults mode.

The reason we have this draft is
because there are differences in the way
servers treat defaults.

According to the YANG spec, schema-default leaves
do not exist.  Only the 'trim' basic mode actually works
this way.  It seems odd to set a leaf to a value,
yet it still doesn't exist.

The 'explicit' and 'report-all' basic modes completely
ignore what YANG has to say about schema-default leafs.
Should we make them illegal in NETCONF?

This is like the <candidate> vs <writable-running> debate.
We could not convince all vendors to re-think their SW designs
so they matched just 1 vendor.  The with-defaults capability
limits the behavior to a small set of variants.

>    it apply to an "embedded NETCONF client" that runs on the server?

Any node created within the server implementation
that is not a schema-default leaf.

>    the example shows? If so, I don't understand why the edit-config

Because explicit and report-all basic modes ignore what YANG
calls a default and have their own definitions of a database.
SQL database implementations do the same thing.

> Lada

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 02 Jun 2010 17:25:53 +0200

> because there are differences in the way

So if somebody builds up a large set of automatic configuration scripts,
a switch from one platform to another, both supporting NETCONF and the
same modules but using different basic with-defaults mode, can easily
become a nightmare.

> do not exist.  Only the 'trim' basic mode actually works

Where does the YANG spec say so? I can't find it.

> limits the behavior to a small set of variants.

...

> that is not a schema-default leaf.

According to the definition of the term in 4741bis (that this draft
refers to), "server" is the entire device, not just the NETCONF
software.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 2 Jun 2010 17:37:52 +0200

> Should we make them illegal in NETCONF?

Can you point me to the section(s) in the YANG spec please?

/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: Wed, 02 Jun 2010 09:38:01 -0700

> same modules but using different basic with-defaults mode, can easily

not if the client deals with with-defaults, taken from
the <hello>.  This is no different than adjusting the
database 'target' and 'save' meta-command based on
the candidate, confirmed-commit, startup, and
writable-running capabilities.  (yangcli does this already).

> Where does the YANG spec say so? I can't find it.

7.6.1.  The leaf's default value

   The default value of a leaf is the value that the server uses if the
   leaf does not exist in the data tree. 

What part of 'does not exist' is unclear?

> refers to), "server" is the entire device, not just the NETCONF

This is an implementation detail.
If I implement an auto-generated WEB UI from YANG modules,
is this a client or part of the server?  If the WEB UI initiates
a NETCONF session over the loopback interface, then it is
clearly an client.  It is uses library calls or some other
mechanism than a NETCONF session, then it is not a client.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 02 Jun 2010 18:45:22 +0200 (CEST)

> What part of 'does not exist' is unclear?

This part is clear.  But your statement that only trim actually works
this way is not correct.

If the leaf has a value, regardless of how it was set, then the server
does not use the default value for that leaf.  This is true for all
modes.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 02 Jun 2010 09:48:10 -0700

This text is carefully worded to allow explicit and report-all modes
to exist.  Obviously, I did not really mean we should make them illegal.

If the leaf does not exist, then the schema-default has significance.
Big 'if'.  The server decides if the leaf exists or not.  If the
leaf does exist, the schema default is irrelevant.  The leaf
is just not a default leaf.

The 'trim' mode is the only one that uses the same definition
of default as described in 7.6.1.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 2 Jun 2010 12:44:59 -0400

>limits the behavior to a small set of variants.

I really don't think this is that hard.  A client can generally
treat all servers identically.  If the model defines a list with
one key, one mandatory leaf, and one leaf with a default value,
then a client can know that it must send the key and mandatory
leafs, and not sending the defaulting leaf will tell the server
that it should be using the default value.  The client can send
this same data to any conformant server and The Right Thing will
happen.

>of default as described in 7.6.1.

Couldn't disagree more.  Any server implemenation that fails to
grok that "The default value of a leaf is the value that the server
uses if the leaf does not exist in the data tree" is not likely to
survive.

But can we please stop ourselves from descending into "Return of
the Defaults XXV"?

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 02 Jun 2010 10:36:56 -0700

> this same data to any conformant server and The Right Thing will

good point

> uses if the leaf does not exist in the data tree" is not likely to

this definition is fine -- the YANG spec is silent on
whether the node exists or not.  Lada (and others)
will want the schema default to indicate how NETCONF
operations will behave.  It may be hard to always explain
that the YANG schema does not help an application
use the create/delete operations.

It is only partly true that a client can ignore defaults.
Many corner-cases exist where 'replace-with-nothing'
is either cumbersome or doesn't work.  The 'delete'
operation is needed in these cases.

That's why we need the 'destroy' operation.
The 'merge' and 'destroy' operation will work the
same on every server, every time.  Problem solved.
(Now we can stop talking about defaults ;-)

> But can we please stop ourselves from descending into "Return of

The with-defaults draft is in WGLC, so it is unavoidable.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 02 Jun 2010 20:50:16 +0200

> What part of 'does not exist' is unclear?

But what about the tiny "if"? This sentence - as any implication - says
nothing about whether the premise is true or not.

> mechanism than a NETCONF session, then it is not a client.

I am just saying that it should be absolutely clear what the meaning of
"set by server" is, otherwise that "MUST NOT" is very problematic.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 3 Jun 2010 08:23:14 +0200

> of default as described in 7.6.1.

I very much disagree with your last sentence.

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 02 Jun 2010 23:25:38 -0700

> I very much disagree with your last sentence.

Why?

In trim mode, the nodes left out are exactly
the schema-default nodes.  Which other mode
does that?  None.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 3 Jun 2010 08:36:02 +0200

> the schema-default nodes.  Which other mode

The text says:

   if there is no leaf, the default is used

This is not the same as (nor does it imply):

   if there is a leaf with a default value, it should be removed

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 03 Jun 2010 08:36:55 +0200

> the schema-default nodes.  Which other mode

I still fail to see the connection with the cited sentence from 7.6.1.
For me that sentence defines the relationship between the actual data
tree (where some leafs may be missing, depending on the "with-defaults
style" of the datastore) and the conceptual configuration that
influences the server operations.

Lada 

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Thu, 03 Jun 2010 01:53:47 -0700

> influences the server operations.

Sorry I brought up this topic.
It is not relevant to any particular text in any draft
so let's drop it.

Andy