Subject: [Netconf] with-defaults terminology conflict

From: Andy Bierman <[email-masked]>
Date: Wed, 26 Aug 2009 09:33:03 -0700

Hi,

This section in with-defaults-03 is a problem:

1.1.2.  NETCONF Terms

   o  Default data: Data that is set or used by the NETCONF server
      whenever the NETCONF client does not provide a specific value for
      the relevant data item.  Default values SHOULD be specified in
      documents describing the data models supported by the NETCONF
      server.

   o  Explicitly set default data: Data that is explicitly set by the
      NETCONF client to its default value.  Some servers MAY treat
      explicitly set default data as simple default data, as they may
      not be able to differentiate between them.

And in 1.2:

   o  trim: Values are not reported if they match the default.
                                                      ^^^^^^^

IMO, this draft MUST NOT redefine the meaning of a default,
as it is specified in YANG.  If this draft waits for YANG
so it can have a normative YANG module, then the term 'default'
must be imported from the YANG RFC.  If not, then a
consistent definition is needed here.

We should have the term 'server-assigned' to mean what the
first bullet in 1.1.2 calls 'default data'.

   o  Default data: Data that is set or used by the NETCONF server
      which contains the schema-specified default value.

   o  Server assigned data:  Data that is set or used by the NETCONF server
      whenever the NETCONF client does not provide a specific value for
      the relevant data item.  These values SHOULD be specified in
      documents describing the data models supported by the NETCONF
      server.

   o  Explicitly set default data: Data that is explicitly set by the
      NETCONF client to its default value.  Some servers MAY treat
      explicitly set default data as simple default data, as they may
      not be able to differentiate between them.

All default data is server-assigned data, but not vice-versa.

Andy

---

From: WashamFan <[email-masked]>
Date: Sat, 29 Aug 2009 22:52:56 +0800

Hi,
 
>        documents describing the data models supported by the NETCONF

I am sorry, that seems not what I infer from discussions in this mailist.
server assigned data has no relevant defauts specified in module, it
should be set explicitly by server for valid config.

washam

>  _______________________________________________
>  Netconf mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Andy Bierman <[email-masked]>
Date: Sat, 29 Aug 2009 08:01:37 -0700

> should be set explicitly by server for valid config.

I don't care what the terms are called
as long as they align perfectly with
the definition of the terms in the YANG draft.

Right now "Default data' definition is unacceptable.

The with-defaults='trim' behavior MUST be limited to
leafs which contain the YANG default-stmt value.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 29 Aug 2009 08:18:06 -0700

> should be set explicitly by server for valid config.

I'm not sure I really understand your question, but maybe you
are pointing out that if the leaf has no default-stmt, then
it is never eligible for being trimmed.

The NETCONF WG deferred the content layer to the NETMOD WG.
The NETMOD WG is now defining the content layer for ALL OF NETCONF.
After YANG is published, there will be non-standard NETCONF
data and YANG NETCONF data, and nothing in between.

The mechanisms defined in NETCONF MUST align perfectly
with the definitions of the content model defined by YANG.

It is absolutely unacceptable for a NETCONF server vendor to
be able to say "oh, those rules don't apply to my YANG modules,
because I follow my own 'FUBAR' capability,
and I have my own definition of a 'default' (or 'mandatory',
or whatever).  It's OK because the :with-defaults standard
does it too."

This is NOT what a default is in YANG, so therefore
this definition is incorrect for all YANG content.

Andy

---

From: WashamFan <[email-masked]>
Date: Sat, 29 Aug 2009 23:23:19 +0800

>  >>     o  Server assigned data:  Data that is set or used by the 
> NETCONF 
>  >> server

Is server assigned data (bullet 2) with or without default-stmt?
And how should server return data in <reply> when with-defaults
is set to 'trim' 'explicit' 'report-all' respectively?

washam

---

From: Andy Bierman <[email-masked]>
Date: Sat, 29 Aug 2009 08:43:16 -0700

> Is server assigned data (bullet 2) with or without default-stmt?

with -- it is intended to be everything filtered out for 'explicit'.

So, here is the simplified version of what if filtered out (not returned):

  trim == leafs set to their YANG default-stmt value
  explicit == leafs that match the 'server-assigned data' definition
  report-all == nothing. nada. zip.  every leaf is returned. nothing
                is filtered out.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 29 Aug 2009 17:58:32 +0200

>   report-all == nothing. nada. zip.  every leaf is returned. nothing

Still wrong. Explicit does simply not have config leafes where there
is no config. There is no filtering with explicit. See also Phil's
email. We are going in circles. I guess we need help from the chairs
to move forward.

/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: "Joel M. Halpern" <[email-masked]>
Date: Sat, 29 Aug 2009 12:18:57 -0400

From reading the model, how am I supposed to tell which of the nodes 
that do not have config leaves, but for which the server is using 
values, will be filtered?

And why are those values not being set in the config structure.
For values which have no meaning past when they are used, I can 
understand wanting to filter them.
For values which are a simple reference to some other variable, and 
which change with that variable, I can understand not representing the 
value, although I am not sure whether that is right.
For other values, I can not see any justification for not representing 
them.  They need to be accessible to the management system.  Otherwise, 
the system is liable to set them, in order to avoid pathologies.  And 
the odds are those values will be worse than the ones the system would 
choose.

The length issue seems to turn on who is processing this information. 
Machinery can deal with the length we are discussing.

Yours,
Joel

---

From: WashamFan <[email-masked]>
Date: Sun, 30 Aug 2009 00:20:48 +0800

>  >>  >>        whenever the NETCONF client does not provide a specific 
> 
>  >> value for

I think this is where we disagree. If a leaf with a default-stmt, it is either
set explicitly by the client or set to the value
specified in default-stmt when it is "used internally by the server". 
In the latter case, it is the data
that would be filtered out by trim. In the former case, if the value is set
to the value defined in default-stmt, then it is the data that would
be filtered by explicit, otherwise, it should not be filtered out in any cases
and would be reported always.

Any leaf without a default-stmt should be reported always if it exists in
data tree.

washam

---

From: Andy Bierman <[email-masked]>
Date: Sat, 29 Aug 2009 09:27:43 -0700

> email. We are going in circles. I guess we need help from the chairs

I never said that, but I should have put 'instance of a leaf' everywhere.

A 'leaf' is an object when referring to the schema tree.

Since only instances of a leaf can possibly be retrieved
with <get>, <get-config>, and <copy-config>, I thought it was
obvious I was referring to instances of a leaf.  Obviously not.

Andy

---

From: WashamFan <[email-masked]>
Date: Sun, 30 Aug 2009 00:30:42 +0800

Hi,

Do correction. See inline.

washam

>  that would be filtered out by trim. 

s/trim/trim and explicit/

> In the former case, if the value 
> is set
>  be filtered by explicit, 

s/explicit/trim/

> otherwise, it should not be filtered out in 
> any cases

---

From: Andy Bierman <[email-masked]>
Date: Sat, 29 Aug 2009 09:40:20 -0700

> values, will be filtered?

The official answer is that the appropriate documentation will
contain this information.

The unofficial answer: you do what application developers have
always done trying to manage networking devices.   You hire
lots of engineers to do trial-and-error data-silo construction.

> understand wanting to filter them.

They are in the configuration, otherwise they could
not possibly cause an error during database validation.

There is nothing whatsoever in YANG (except the YANG default-stmt)
that would give you any definitive value as a substitute
for a leaf instance the server is using, which is not available for retrieval.

> Machinery can deal with the length we are discussing.

Back in SNMP days, we thought it was a good idea that a dumb
MIB walker could show you the data from any SNMP agent in the world,
without knowing about even 1 MIB object definition on that agent.

That's what we thought true decoupling of the
protocol and the data definition language meant.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 29 Aug 2009 20:20:17 +0200

On Sat, Aug 29, 2009 at 06:18:57PM +0200, Joel M. Halpern wrote:

> them.  They need to be accessible to the management system.

Accessible yes, but they are not part of the configuration.

> The length issue seems to turn on who is processing this
> information.  Machinery can deal with the length we are discussing.

Making operational state by default is broken. It is wrong in most
cases to treat the MTU as config since what you want is likely the
value the kernel figured out for the piece of hardware you are
currently using. We are caught in circles.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 29 Aug 2009 20:23:07 +0200

> lots of engineers to do trial-and-error data-silo construction.

Both your answers. Both wrong. Explicit means no filtering. Explicit
means config is config and operational state is operational state.  If
you want config, you do a get-config. If you want operational state,
you do get or something specific for retrieving operational state.

> protocol and the data definition language meant.

Read RFC 3535 to find out why the lack of separation of config data
from state and statistics was a mistake.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 29 Aug 2009 20:29:00 +0200

> obvious I was referring to instances of a leaf.  Obviously not.

As I said, we obviously need help from the chairs - we seem to talk
past each other for a while now and this is not effective.

/js

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 29 Aug 2009 14:32:31 -0400

I have, in previous notes, said that representing the "currently used 
mtu" as operational data would be a reasonable approach.  I can even 
live with the fact that the coupling between the configured value and 
the operational value is weak / description based.

But, every time I have suggested that, Phil (who is the most vocal 
proponent of the view that such information should not appear in the 
config), has vehemently asserted that he does not want to represent it 
as operational data.

I readily admit that there are multiple ways to solve the problem.
What I am not prepared to admit is that "read the documentation and 
attempt to recreate the document device calculation in the manager" is 
even vaguely appropriate as a solution.
Nor am I prepared to agree that there is not a problem.

Yours,
Joel

PS: I copied netmod, because I thought that was where this was being 
discussed for the most part.  It clearly crosses the boundaries between 
the two.

---

From: Andy Bierman <[email-masked]>
Date: Sat, 29 Aug 2009 11:52:50 -0700

> currently using. We are caught in circles.

Here's the part I don't get.

If the ifMtu is not config (i.e., config-stmt set to false),
then you must be suggesting a YANG data modeler SHOULD use 2 objects,
-- the ifOperMtu object and the ifAdminMtu object.

That is a data model design issue.
Even if that were the design choice,
it seems to me that value of *both* leafs in the pair
are required for the client to utilize the data model.

If you want just 1 leaf, that is not part of the configuration,
then you want a leaf that the client can never change.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 29 Aug 2009 12:02:45 -0700

> past each other for a while now and this is not effective.

maybe the co-Chairs are on vacation.

Leafs omitted in <rpc-reply> PDUs:

   trim == leaf instances set to their YANG default-stmt value
   explicit == leaf instances that match the 'server-assigned data' definition
   report-all == none

Is that clear enough?

NETCONF capabilities cannot conflict with each other.
One capability cannot change another one.
If a server advertises the YANG module capability
for the 'foo' module, then it MUST follow all the
definitions for NETCONF content that the YANG language contains.
We all agree on that.

So advertisement of the 'with-defaults' or the 'acme-yang' capabilities
is fine, but not if the server ALSO wants to advertise the
YANG module capability.  Pick one or the other.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 29 Aug 2009 23:14:18 +0200

>    explicit == leaf instances that match the 'server-assigned data' definition

No, we need to wait that vacation ends.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 30 Aug 2009 20:27:05 +0200 (CEST)

>   explicit == leafs that match the 'server-assigned data' definition

server-assigned leafs would be returned in the explicit mode.  The
explicit mode returns all instances in the data store.

>   report-all == nothing. nada. zip.  every leaf is returned. nothing

One way of viewing this is that it returns everything that have been
set, and also all default values in effect, even though they do not
really exist as instances in the data store.

/martin