Subject: [netmod] Issue: interpretation of 'default'

From: David Partain <[email-masked]>
Date: Tue, 1 Sep 2009 10:09:16 +0200

Greetings,

Another discussion that's been ... um... lively has been around the meaning 
of 'default'.  Martin has written some text (a new section) that he has sent 
to the list, but it may have gotten lost in the middle of everything else.  
As such, here it is again:

------------------------------------------------------------------------------------------------------------------
7.6.1.  The leaf's default value

   The default value of a leaf is the value that the server uses if no
   value has been explicitly set.  The usage of the default value
   depends on the type of the leaf's closest ancestor node in the schema
   tree which is not a non-presence container:

   o  If no such ancestor exists in the schema tree, the default value
      MUST be used.

   o  Otherwise, if this ancestor is a case node, the default value MUST
      be used if any node from the case exists in the data tree, or if
      the case node is the choice's default case, and no nodes from any
      other case exist in the data tree.

   o  Otherwise, the default value MUST be used if the ancestor node
      exists in the data tree.

   In the cases where the default value MUST be used, the server MUST
   operationally behave as is if the leaf was present in the data tree
   with the default value as its value.

   If a leaf has a "default" statement, the leaf's default value is the
   value of the "default" statement.  Otherwise, if the leaf's type has
   a default value, and the leaf is not mandatory, then the leaf's
   default value is the type's default value.  In all other cases, the
   leaf does not have a default value.
------------------------------------------------------------------------------------------------------------------

If possible, I want to reach consensus on whether this text is what the WG 
wants this text or what changes we need to make to it.  Please focus on this 
text...

Cheers,

David

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 01 Sep 2009 09:31:19 -0400

Unfortunately, while I like this case, it does not, as far as I can 
tell, solve the problem at hand.

A number of folks have argued that either
a) the managed device is free to set the node to some other value, even 
if it has a default definition, and to still treat that as a default 
valued node
b) the managed device is free to set nodes without default to some 
value, and not report that value in response to get requests of any kind.

Both of those are not directly addressed by the text, but are clearly 
within the topic of the text.  We need to resolve those behaviors somehow.
Personally, I find the reading that (a) is allowed to be a distortion of 
the plain meaning of the existing text, but at least one person has 
argued vocally that it is not only allowed but desirable.

I do want to try to write text to address these.
I am happy to assume the text below from Martin as a starting point, and 
to determine whether the additional text goes in 7.6 or 7.6.1.

As a minor clarification, there apparently has been some confusion about 
the managed device treating leaf-lists as if they have values, and 
whether those need to be reported.

Yours,
Joel

David Partain wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 01 Sep 2009 15:51:27 +0200 (CEST)

"Joel M. Halpern" <[email-masked]> wrote:
> Unfortunately, while I like this case, it does not, as far as I can tell, solve
> the problem at hand.
> 
> a) the managed device is free to set the node to some other value, even if it
> has a default definition, and to still treat that as a default valued node

When you say "set the node" do you mean actually create the instance?
If so, the assigned-by system statement supposedly covers this - if
the node is assigned-by user, the server MUST NOT create it.

Or do you mean "operationally use"?  If so, you are saying that it
would be ok to simply ignore the default statement and use any other
value.  My text does not allow this.  It says that the value from the
default statement MUST be used.

> b) the managed device is free to set nodes without default to some value, and
> not report that value in response to get requests of any kind.

Here I assume you mean "operationally use".  I think the proposed text
is clear when it says: "In all other cases, the leaf does not have a
default value."  So from a YANG perspective, this would not be a
default value.

> Both of those are not directly addressed by the text, but are clearly within
> the topic of the text.  We need to resolve those behaviors somehow.
> Personally, I find the reading that (a) is allowed to be a distortion of the
> plain meaning of the existing text, but at least one person has argued vocally
> that it is not only allowed but desirable.
> 
> I am happy to assume the text below from Martin as a starting point, and to
> determine whether the additional text goes in 7.6 or 7.6.1.

This would be very welcome!

/martin

---

From: WashamFan <[email-masked]>
Date: Tue, 01 Sep 2009 22:08:01 +0800

Hi,
 
> value, and

IMO, in this case, the value assigned by the server should be
reported, since the client has no clue to deduce it.

And to my knowledge, the server might not be free to set any nodes
without default but those mandatory ones for the valid config.

washam

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 01 Sep 2009 18:05:33 +0200

> value, and not report that value in response to get requests of any kind.

The text now specifies that under certain conditions the configuration
without the leaf is equivalent to one in which the leaf is present and
set to the default value. However, formulations like "server MUST use
the default" value may be understood as if the server is not allowed to
assign a value unilaterally. So it might be actually better to talk
about equivalence of configurations, also because it can be easily
applied to datastores other than running.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 01 Sep 2009 19:19:43 +0200

Joel M. Halpern píše v Út 01. 09. 2009 v 12:20 -0400:
> Sorry, I have no idea what you are getting at / asking for.
> (I can provide two possible interpretations, one of which would be fine 
> and one of which I would completely disagree with.  And what you meant 
> is probably neither one.)
> Would you please clarify to the list?

My point simply is that the "server MUST use" language misled me into
thinking that the 'default' statement prevents the device from doing a),
which is not the case, so I am suggesting another formulation expressed
solely in terms of datastore content.

Lada

> Thank you,
> Ladislav Lhotka wrote:
-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "tom.petch" <[email-masked]>
Date: Tue, 1 Sep 2009 18:21:46 +0200

David

I find it less than clear; see inline.

Tom Petch

----- Original Message -----
From: "David Partain" <[email-masked]>
To: "NETMOD Working Group" <[email-masked]>
Sent: Tuesday, September 01, 2009 10:09 AM
Subject: [netmod] Issue: interpretation of 'default'

> As such, here it is again:

When are we talking about? Note we have no terminology for what
is in the data tree, presume instances with values, in which case are
we talking about an instance being created?  But then we have no
definition of when an instance is created.  With an SNMP background,
this is academic, there is always a 1.3.6.1.2.1.1.1 with a 'value', it is
just a question of being a valid value or not, but with YANG, we have
not nailed this down, and so some posts have implied that a data node
leaf does not exist in the data tree unless and until eg its ancestor
node becomes part of the data tree, or perhaps when the server, if
it has permission, just decides to create it and ancestor anyway.
And is there a difference, as Lada asked, between doing an <edit>
specifying <element/> as opposed to <element>42</element>?
All this needs nailing down otherwise discussions of default,
assigned by all/user/system....  can end up with each person having
a different view.

And 'explicitly set'; to me, that MUST be set by anyone, CLI, SNMP,
Netconf, ....  It is no use having a Netconf/YANG that pretends that
nothing else in the world exists as far as configuration management
is concerned and so can be ignored.  Again, an issue touched on but not
resolved.

We have the gory details but lack the big picture.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 01 Sep 2009 15:13:52 -0400

Then I must restate my disagreement with you.
The point of the wording is that if the model has a default value
specified then the managed device is not free to arbitrarily treat the
node as having some other value.
And it is most especially not permitted to treat that node as if it were
being validly defaulted.  It is not.

To change that meaning makes the agree MUST in teh default wording
meaningless.

I understand you want a different meaning.  But please argue explicitly
for that.  Arguing for wording that allows multiple incompatible 
interpretations is actually counter-productive.

Yours,
Joel

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 01 Sep 2009 21:54:57 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> which is not the case,

Well, that was the intention.  If there is a 'default' statement, it
prevents the server from ignoring it. 

Why do say that this is not the case?

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 01 Sep 2009 22:19:18 +0200 (CEST)

"tom.petch" <[email-masked]> wrote:
> When are we talking about?

In this case, one must read the entire section in order to understand
the what, when, and how.   If you have a suggestion for some text that
explains this better, I am more than happy to include it.

> Note we have no terminology for what
> just a question of being a valid value or not

I don't understand this.  In SNMP, ifStackStatus.1.4 may or may not
exist.  You might have to create it.  In NETCONF, there are protocol
operations that create instances.

> but with YANG, we have
> node becomes part of the data tree

Right, the leaf /foo/bar can never exist in the data tree unless /foo
exists.

> or perhaps when the server, if

Sure this can happen; the server can even run a local NETCONF-client
script if it wants to.  Does that mean it is server created.

> specifying <element/> as opposed to <element>42</element>?

I haven't seen that question, but the first one tries to set the
'element' leaf (assuming it is a leaf) to the empty string, and the
second to the value 42, so yes, there is a difference.

> is concerned and so can be ignored. 

Absolutely.  

> Again, an issue touched on but not
> resolved.

I am not sure what sort of text you expect, if any.

/martin

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 31 Aug 2009 17:53:51 -0700

Hi -

> From: "Joel M. Halpern" <[email-masked]>
> To: "David Partain" <[email-masked]>
> Cc: "NETMOD Working Group" <[email-masked]>
> Sent: Tuesday, September 01, 2009 6:31 AM
> Subject: Re: [netmod] Issue: interpretation of 'default'
...
> if it has a default definition,

undesirable - it means that if a client wants to be sure something has
the "default" value, the client must explicitly assign that value to it

> and to still treat that as a default 
> valued node

intolerable - this would mean that the client would not readily see that
the server was not adhering to the interface contract established by
the use of "default"

> value,

this is ok

> and not report that value in response to get requests of any kind.

intolerable -  this would prevent configuration backup / restore

Randy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 02 Sep 2009 08:52:25 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> Martin Bjorklund píše v Út 01. 09. 2009 v 21:54 +0200:
> Hmm, this is getting really confusing, so let me state clearly my
> position:
> 
> 1. The 'default' statement says that certain precisely specified 
>    changes to the datastore infoset do not change the meaning of the 
>    configuration.
> 
> 2. In principle, this does not prevent the server from setting such a 
>    configuration parameter to any valid value, e.g. in an initial 
>    configuration. However, if this value is different from the default 
>    specified by the data model, it must always be shown in the 
>    configuration.
> 
> I understood Joel's item a) means the same as 2.

But he wrote "and still treat that as a default valued node", which is
not what you (and me) are saying.  Just as you say, if it has a value
it must be returned.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 02 Sep 2009 09:07:11 +0200

> not what you (and me) are saying.  Just as you say, if it has a value

These are the perils of shortcut formulations. My interpretation of "and
still treat that as a default valued node" was that the 'default'
statement for that node still applies, i.e. the 'default' statement that
the data model specifies for this node is not suddenly nullified by the
action.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "tom.petch" <[email-masked]>
Date: Wed, 2 Sep 2009 11:30:42 +0200

Randy

Good to hear from you; see inline

Tom Petch

----- Original Message ----- 
From: "Randy Presuhn" <[email-masked]>
Sent: Tuesday, September 01, 2009 2:53 AM

> intolerable -  this would prevent configuration backup / restore

Crunch; yes, there MUST be an option (preferrably a mandatory 
one) to get back such data.

Tom Petch

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 02 Sep 2009 08:23:00 +0200

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "tom.petch" <[email-masked]>
Date: Wed, 2 Sep 2009 16:20:19 +0200

---- Original Message ----- 
From: "Martin Bjorklund" <[email-masked]>
Sent: Tuesday, September 01, 2009 10:19 PM

> "tom.petch" <[email-masked]> wrote:
<snip>
> > Again, an issue touched on but not resolved.
> 

I am thinking of eg with-defaults which currently says 

"Explicitly set default data: Data that is explicitly set by the
      NETCONF client to its default value. " 

where I want the reference to 'the NETCONF client' excised or
replaced by something more generic (CLI, SNMP..).

I get a sense from this and from some posts that this is another issue
that needs more work, that for configuration management to
work, then there is a category of data that is set by anyone
which needs to be identified in NETCONF, perhaps in YANG.

And I read this as an implicit requirement in RFC3535.

And I see Phil arguing 
"I strongly oppose mixing default values into the configuration
database.  If I get configuration data, I do not want default values."

Well no and yes.  I want to be able to get only set values, but
I do not want a 'configuration database' to be limited to that alone.
I want the configuration part of the data tree to be closer to
everything writable.

Tom Petch

---

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

Hi,

> I am not sure what sort of text you expect, if any.

I think it would be helpful if those who write mail about the suggested text 
at the beginning of the thread and do _not_ think it's sufficient please 
offer suggestions of text to cover things they don't think are covered or 
offer corrections to the suggested text to correct what they think is wrong.

It'll make the discussion easier.

Thanks.

David