Subject: [netmod] various defaults discussions (was Re: leaf encoding rules)

From: David Partain <[email-masked]>
Date: Fri, 22 Aug 2008 10:49:59 +0200

Hi,

(sorry if you get this more than once.  it keeps bouncing...)

This thread's morphed beyond "leaf encoding rules", so I changed the subject.

Andy objected to:

    A NETCONF server that replies to a <get> or <get-config> request MAY
    choose not to send the leaf element if its value is the default
    value.  Thus, a client that receives an <rpc-reply> for a <get> or
    <get-config> request, must be prepared to handle the case that a leaf
    node with a default value is not present in the XML.  In this case,
    the value used by the server is known to be the default value.

saying that this is a NETCONF affair, not a NETMOD affair.

This has subsequently turned into a discussion of 
- whether we're changing NETCONF operations or not,
- whether leafs with defaults are part of the configuration datastore or not,
- whether we could start standardizing with-defaults or not, 
- agent-selected defaults ('system-created')

So, I'm confused again and am having trouble digesting all the various 
questions.

Will it cover enough if we answer the following questions:

1. Should we have the paragraph above in the YANG spec or not?  That is, 
should the YANG spec say anything at all about what a server might or might 
not send?
2. Should we try to get with-defaults taken up as a work item in NETCONF?
3. Should we add system-created?

If these are the right questions, let's break them into separate threads, 
please.  Are there other questions in this thread that need answering?

Cheers,

David

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

---

From: Phil Shafer <[email-masked]>
Date: Fri, 22 Aug 2008 08:42:13 -0400

>3. Should we add system-created?

There was also Balazs' question about complex defaults, where the
default value exists but can't be statically known.  And "write
once" data, where the value can be assigned by not changed.

Thanks,
 Phil

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 22 Aug 2008 22:12:27 +0200

> should the YANG spec say anything at all about what a server might or might 
BALAZS: Netmod should state whether a leaf not set but having a YANG default is or os not part 
of the conceptual data-store. Once we have this settled we can start answering questions like:
- should defaults come back in get/get-config - use with-defaults
- should must consider defaults - usually yes, but what if we are testing for the existence of 
the leaf in a must? will it give back true or false
- should a conditional augment (when) consider defaults (yes)
- how should existence tests for edit-config delete, create handle a default leaf - depends on 
the answer to the main question
> 2. Should we try to get with-defaults taken up as a work item in NETCONF?
BALAZS: Yes

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 23 Aug 2008 11:55:01 +0200 (CEST)

Balazs Lengyel <[email-masked]> wrote:
> > This has subsequently turned into a discussion of - whether we're
> > changing NETCONF operations or not, 
> > - whether we could start standardizing with-defaults or not, -
> >   agent-selected defaults ('system-created') 
> > So, I'm confused again and am having trouble digesting all the
> > various questions. 
> > 1. Should we have the paragraph above in the YANG spec or not?
> >    That is, should the YANG spec say anything at all about what a
> >    server might or might not send? 
>
> BALAZS: Netmod should state whether a leaf not set but having a YANG
> default is or os not part of the conceptual data-store.

Currently the spec specifies that defaults are not part of the
conceptual data store.  But not the word conceptual.  This does *not*
preclude an implementation to store the default in their database.

> Once we have
> this settled we can start answering questions like: 

The current text allows for a capability like with-defaults, and also
it allows for implementations to have different values for
'with-default-default'.

> - should must consider defaults - usually yes,

Yes.

>   but what if we are
>   testing for the existence of the leaf in a must? will it give back
>   true or false 

true.

> - should a conditional augment (when) consider defaults (yes)

yes.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sat, 23 Aug 2008 06:36:39 -0700

> Balazs Lengyel <[email-masked]> wrote:

7.5.2.  The must Statement

    The "must" statement, which is optional, takes as an argument a
    string which contains an XPath expression.  It is used to formally
    declare a constraint on the configuration data.  When a configuration
    datastore is validated, all "must" constraints are conceptually
    evaluated once for each corresponding instance in the datastore's
    data tree, and for all leafs with default values in effect.

This text clearly says the defaults exist for the purpose of
must-stmt evaluation.  IMO, this text should be clarified
to say 'all agent-created configuration nodes'.

OLD:

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

NEW:

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

7.6.5.  XML Encoding Rules

    A leaf node is encoded as an XML element.  The element's name is the
    leaf's identifier, and its XML namespace is the module's XML
    namespace.

    The value of the leaf node is encoded to XML according to the type,
    and sent as character data in the element.

As I noted before, I strongly object para 3 above, because it
changes NETCONF protocol behavior.  Also, the last sentence
is wrong.  A missing node could mean it was filtered by
access control.  It could mean there is no node at all.
It could mean there is an agent-supplied value.

It will be harmful to interoperability to assume a missing
node has a YANG specified default value.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 23 Aug 2008 08:38:09 -0700

> once" data, where the value can be assigned by not changed.

There is also the issue I brought up wrt/ min-access read-only.
The old SMI way is to allow vendors to leave holes in the config
by implementing some config knobs within table entries as
read-only.

Using the if-feature approach, there is no middle ground.
Either the agent implements the knob read-create as intended,
or the knob does not exist.

This is really not any different than the manager
providing a few knobs per list entry, and letting
the agent fill in the defaults for the rest of them.
The only difference is not every platform is going
to allow the manager to set an explicit value.

Maybe the old SMI way is broken.
Maybe standard configuration will only succeed
if it is an all-or-nothing contract, without
all the wiggle room that min-access provides.

I'm willing to toss min-access and start over with
module + feature based conformance.  It is simpler.
If there are no features, you must implement everything
in the module to claim conformance.  If there are features,
you must implement everything in the feature to return
the feature name in the new 'get-features' operation.

Agent variations would get punted to Martin's overlay solution
(still very TBD), but they will be needed sooner or later.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 24 Aug 2008 10:56:38 +0200 (CEST)

>        all leafs with agent-supplied values.

But if we add this, we make a distinction between agent-supplied
values and (I suppose) client-supplied values.  Then we have to make
sure that the rest of text follows this.   I'm not sure I see the
benefits of adding these terms.  Maybe we can clarify somewhere that
nodes in the data tree can be created by the server or client.

> changes NETCONF protocol behavior.

The idea is that this text will cover implementations that always send
all defaults, implementations that never send defaults, and
implementations the use the with-defaults capability.

> Also, the last sentence
> access control.

Right.

> It could mean there is no node at all.

No.  It means that the default is there.  You cannot completely remove
a leaf w/ default (unless you remove its parent of course).

> It could mean there is an agent-supplied value.

No, b/c in that case it would be present.  An agent must not suppress
agent-supplied values.

> node has a YANG specified default value.

This goes back to Randy's discussion of a strong contract for
defaults.  Without this strong contract, defaults will be more like
SMI's DEFVAL, which I think we agreed we do not want.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sun, 24 Aug 2008 09:10:14 -0700

Martin Bjorklund wrote:
>...

What if the optional leaf is really optional?
There might be other leafs (e.g, MTU) that work
the way you describe -- they are only optional
because there is a YANG default defined.

Suppose I have this leaf:

    leaf alternate-foo-server {
      type inet:ip-address;
    }

There is no default possible because it is an IP address.
However, the clever agent can find a 'foo' server using
other protocols or mechanisms.

How does the manager know if the agent is going to
setup and use an alternate 'foo' service or not?
If the primary 'foo' service fails, is there a backup
configured, or not? If so, which server is the backup?

If the manager must configure this knob by hand to find
out, then the auto-foo-discovery feature on the agent
is not used. The manager does not want to *ever* provide
a hard-wired value here, in order to use to auto-discovery
instead.

> SMI's DEFVAL, which I think we agreed we do not want.

The IETF is not likely to take full advantage of the
YANG default, which MUST be implemented exactly
as specified, no exceptions.

And there are plenty of use cases where no default is even
possible, let alone agreed upon by the WG.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 24 Aug 2008 20:49:54 +0200

> configured, or not? If so, which server is the backup?

There is likely a config setting that enables the magic protocol to
obtain operational state with a backup server configuration. Note that
the 'alternate-foo-server' is not config data anymore but operational
state.

> a hard-wired value here, in order to use to auto-discovery

If alternate-foo-server is configured, then it is configured. This
does not imply by itself that there can't be an auto-foo-discovery
that configures alternate servers with a higher priority; so the
config data would serve as a backup in case auto-foo-discovery
fails. All this boils down to what the description clauses say.

/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/>
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Sun, 24 Aug 2008 12:37:05 -0700

> the 'alternate-foo-server' is not config data anymore but operational

It is not operational config unless the manager chooses that.

> fails. All this boils down to what the description clauses say.

Right.  And this is up the DM designer, not the YANG language.
What if the 'enable-alternate-foo-service' knob said:

  "This knob is ignored if the alternate-foo-server knob is
   set by the manager.  Otherwise, if equal to 'true', then
   the alternate-foo-service knob will contain the address
   of the alternate foo server selected by the agent."

Does YANG force the DM designer to use more objects,
and use the ifAdminStatus/ifOperStatus design instead
of overloading one object?

If so, then the rules need to be spelled out clearly
in the draft, and say that optional leafs without
YANG defaults MUST NOT exist, or be used in any fashion
by the agent.  Also, optional leafs with YANG defaults
MUST exist and be used by the agent (if its parent exists).

I don't mind throwing out the SNMP way of mixing
config and operational state.  The rules and consequences
of using YANG default-stmt and mandatory-stmt need to be
more clear.

   default | mandatory | rule
   --------+-----------+---------------------------------
    no     |   false   |  node MUST NOT exist or be used
   --------+-----------+---------------------------------
    yes    |   true    |  not allowed in YANG
   --------+-----------+---------------------------------
    yes    |   false   |  node MUST exist and be used (if parent exists)
   --------+-----------+---------------------------------
    no     |   true    |  node MUST be set by manager and be used
   --------+-----------+---------------------------------

This does not allow for any agent created config nodes that
do not have YANG defaults.  IMO, this category must be
supported somehow (5th state somehow).

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 24 Aug 2008 22:43:30 +0200 (CEST)

Andy Bierman <[email-masked]> wrote:
> by the agent. 

No, I don't think we want to do that.  YANG clearly separates between
config and non-config, but an optional config leaf can get an inital
(not default!) value by the agent.  The problem is how a client can
know if a leaf is truly optional or will get a value by the agent.
This is where 'created-by system;' would be useful.  For such leafs,
the client knows that it doesn't have to provide a value, but the
agent will assign a reasonable value.  This is still config, so the
client can choose to override.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sun, 24 Aug 2008 14:09:41 -0700

> client can choose to override.

Where is 'created-by-system' defined?
I do not know the details this proposal.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Sun, 24 Aug 2008 22:37:35 -0400

>other protocols or mechanisms.

I think you are confusing config data with state data.  The "foo
server I will use" and "the foo server I was told to use" are not
the same thing.  The "list of users who are currently logged in"
and "the list of users who are allowed to login" are different.
The "list of currently known routes" and "the list of configured
static routes" are different.

All of these need data models for the operational state that are
distinct from the data model for the configured state.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Sun, 24 Aug 2008 22:39:50 -0400

>by implementing some config knobs within table entries as

If the device doesn't allow it to be configured, there should be a
specific way of saying that.  It's not read-only, it's just not
configurable:

    deviation some/knob {
        config false;
    }

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Sun, 24 Aug 2008 22:41:36 -0400

>to say 'all agent-created configuration nodes'.

"agent-created" and "agent-supplied" are misleading names, since
there's no requirement for the agent to ever created these nodes.
Would "implicit nodes" be an acceptable term?

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 25 Aug 2008 08:55:40 +0200

> preclude an implementation to store the default in their database.

I am not sure whether "conceptual datastore" means the same thing as
what I called "conceptual data tree" in Dublin. By the latter I meant
essentially the reply to <get> without any filters, i.e., XML. If YANG
models are interpreted as contracts between the agent and manager then
it is IMO the only thing that really matters. Whether the agent has the
default value in its database or whether it is hardwired etc. doesn't
seem important.

In this context, with respect to defaults it is only necessary to decide
under what circumstances a leaf element that would normally contain the
default value may be omitted in the <get> or <get-config> reply.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "Peter Loborg" <[email-masked]>
Date: Mon, 25 Aug 2008 09:40:25 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Ladislav Lhotka
> Sent: den 25 augusti 2008 08:56
> To: NETMOD Working Group
> Subject: Re: [netmod] various defaults discussions
> 

I fully agree to this statement. In order to support simplistic (cheaper and easier to verify) implementations of agents/managers, any mechanism to omit leafs with default values should as a default be OFF. If both sides exchange a capability "defaults-omitted" (or similar) then the function is turned on. This is also quite usable for debugging purposes.

If we desperately want to reduce the amount of data sent over the wire (is there any other reason for omitting defaults?) then omitting the defaults won't really do the trick. We must also go outside YANG/NETMOD to solve that problem, e.g. with a different encoding for NETCONF such as ASN.1 PER or by sending a compressed XML stream.

IMHO
/Peter

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 25 Aug 2008 10:04:20 +0200

On Mon, Aug 25, 2008 at 09:40:25AM +0200, Peter Loborg wrote:
 
> I fully agree to this statement. In order to support simplistic
> (cheaper and easier to verify) implementations of agents/managers,
> any mechanism to omit leafs with default values should as a default
> be OFF. If both sides exchange a capability "defaults-omitted" (or
> similar) then the function is turned on. This is also quite usable
> for debugging purposes.

I like to be able to turn on/off the inclusion of "defaults" on an
operation base. Having to start a new session to enable/disable this
filter seems odd to me.
 
> If we desperately want to reduce the amount of data sent over the
> wire (is there any other reason for omitting defaults?) then
> omitting the defaults won't really do the trick. We must also go
> outside YANG/NETMOD to solve that problem, e.g. with a different
> encoding for NETCONF such as ASN.1 PER or by sending a compressed
> XML stream.

The main motivation (as I understand it) is to ask NETCONF servers to
help in hiding noise from human operators; things I did not set are
not part of what I consider a device's configuration. Still, in some
debugging situations, I like to see all config knobs and their
"default" values - adding a with-defaults extension to get-config
nicely gives me that functionality. (Or adding a new capability
introducing a get-config-without-defaults operation; I don't really
care much.)

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 25 Aug 2008 10:39:02 +0200

> not part of what I consider a device's configuration. Still, in some

But assume that in one NETCONF session you explicitly set a knob to a
value that happens to be its default value. Then, if you or someone else
opens another session, should the value be sent in this new session?

I think the handling of defaults must be defined in terms of comparing
the actual value with the default defined in the data model, not in
terms of the previous events that may not be known anymore. For example:
"If the value of a leaf element is equal (in the value space) to the
default value of this leaf as defined by the DM, the agent
MAY/SHOULD/MUST suppress this leaf in the <get> output."

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 25 Aug 2008 10:47:02 +0200

On Mon, Aug 25, 2008 at 10:39:02AM +0200, Ladislav Lhotka wrote:
> Juergen Schoenwaelder p????e v Po 25. 08. 2008 v 10:04 +0200:
> 

I would say yes. The knob was explicitely set by a management
operation, so this becomes part of the configuration.

> terms of the previous events that may not be known anymore.

You don't need to remember previous events; all you need is a bit
indicating "this value was set by an explicit operation and is part of
the config". The more important question really is how to clear this
bit. But I believe recording this bit on the NETCONF server is pretty
important operationally.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 25 Aug 2008 10:57:52 +0200 (CEST)

> bit. But I believe recording this bit on the NETCONF server is pretty

The way to "clear this bit" is to delete the leaf element:

1. The db is empty.  Leaf 'foo' which has a default of 42 is not
   there in the db.  The server internal applications use the value
   42.

2. A client sends an edit-config which sets 'foo' to 4668.  This
   value is stored in the db.  The server internal applications use
   the value 4668.

3. A client deletes 'foo' in an edit-config.  'foo' is deleted from
   the db.  Goto step 1.

This is simple, cheap, and memory efficient.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 25 Aug 2008 11:02:52 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:

> If YANG models are interpreted as contracts between the agent and
> manager then it is IMO the only thing that really matters. Whether
> the agent has the default value in its database or whether it is
> hardwired etc. doesn't seem important.

Exactly.  That's what I meant.

And the contract says that if a value is for a leaf w/ a default is
not present when its parent is present in a PDU, then it means that
the default value is used (modulo access rights).  You are free to
implement this any way you want - store the defaults in the db but
don't send them; store the defaults in the db and always send them;
don't store defaults in the db but always send them, ...

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 25 Aug 2008 11:18:42 +0200 (CEST)

> I do not know the details this proposal.

See:

http://www.ietf.org/mail-archive/web/netmod/current/msg00692.html
http://www.ietf.org/mail-archive/web/netmod/current/msg00749.html

There is no finished proposal with all details filled in yet.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 25 Aug 2008 11:20:15 +0200

> don't store defaults in the db but always send them, ...

Sounds good. This idea of a conceptual datastore (expressed in XML)
actually also gives more sense to the DSDL stuff: Rather than being a
translation of a YANG data model for managers, it is a formal
representation of constraints that the conceptual datastore (and,
consequently, the NETCONF PDUs) must satisfy in order to be compliant
with the YANG data model.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 25 Aug 2008 12:22:56 +0200

On Mon, Aug 25, 2008 at 11:45:07AM +0200, Peter Loborg wrote:
 
> Hmmm - you seem to consider machine-human interaction with one node with
> a fairly long session time. That's rather opposite to our experience of
> management tool operations - it's a machine-machine interaction (no
> problems with "noise") and the human sits on the other end of a
> configuration tool. The tool will do the information filtering/hiding
> based on user preferences.

If there is such a tool, great. However, there are many operational
environments without such tools and I believe we make a mistake if we
ignore them.

> Summary - My view is that we should keep the modelling language simple
> and clear, features to simplify for man-machine communication over
> netconf are probably wasted (who will manually "talk" Netconf over ssh
> with a node?). Optionalities and agent choices will complicate the
> implementation of tool support. It's more important to provide managers
> the possibility to catch up with changes on a node than to hide default
> values - multiple users tend to contact the node at various times with
> separate instances or variants of the management tool, and sometimes
> there are site visits with reconfigurations as result.

I believe we have to support both scenarios. (Note that for me the
filtering of defaults is a protocol issue, not a modelling language
issue so I am not sure I agree with your text above.) I agree that
protocol capabilities will complicate implementations but ignoring the
complexity of the real world and the different requirements of NETCONF
users will also not work at the end.

Right now, NETCONF implementations show different behaviour in a
number of places and we need to work through this or you will end up
with a vague standard that everybody implements in his own way - this
is IMHO worse for interoperability than a bunch of capabilities.

/js

---

From: "Peter Loborg" <[email-masked]>
Date: Mon, 25 Aug 2008 11:45:07 +0200

> From: Juergen Schoenwaelder
[mailto:[email-masked]]
> Sent: den 25 augusti 2008 10:04
> To: Peter Loborg
> Cc: Ladislav Lhotka; NETMOD Working Group

The "normal" interaction cycle is that the manager connects to multiple
nodes, and reads out the whole or a substantial part of the config in
one chunk, then releases the connections and lets the user re-configure
and consistency check this multi-node data set (containing both data
from Netconf-managed nodes and from other nodes). The result is a set of
suggested config changes for one or several nodes, and when this is
applied all nodes that need to be changed are connected to and the
change is sent over. This process may be as fast as 10 minutes but may
also be 24 hours (some telecom operators require a manger to check the
planned reconfig done by a team of planners before the change can be
applied, and we have seen situations where we have more than 100 planned
reconfigurations waiting for approval in their system).

So I would say that the needs for a single element manger tool used for
debugging a node is quite different from the needs of a network
management and planning tool. O&M interface designers in a node
organisation tend to think foremost on the single element
poking/debugging scenario rather than what is needed to plan and execute
a change on 10 nodes in a network of 10000 nodes and while maintaining
consistency in this operation.

As an example of useful functionality on a node, it would be extremely
valuable to be able to get a time stamp from the node telling when any
config was last changed, and/or to ask for all changes since a certain
point in time. Quite useful to check this info prior to applying a
reconfig of a set of nodes. NETCONF does give us a similar solution if
all nodes support the possibility to reconfig in a special area, then
validate and finally apply - but how many node types will implement this
capability?

IMH?O,

Peter Loborg, Systems Manager/Architect,
Ericsson GSM Radio Access Network OSS.

---

From: "Peter Loborg" <[email-masked]>
Date: Mon, 25 Aug 2008 15:10:37 +0200

> environments without such tools and I believe we make a mistake if we

I think it would be a mistake to think that any serious usage of Netconf
will happen without the usage of at least some "dumb" tool support, a
tool that given the yang models will actually present what's there and
allow you to see and turn all knobs. And obviously, whatever we decide
about e.g. sending or not sending defaults over the wire, even this type
of tool will manage to fill in such blanks. As for SNMP there will
probably exist a bunch of freeware Netmod/Yang tools with this basic
capability... (possibly student projects from some university...)

> is IMHO worse for interoperability than a bunch of capabilities.

Agree completely!

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 25 Aug 2008 15:40:15 +0200

> capability... (possibly student projects from some university...)

I agree with the "dumb" tool support. Given the experience of SNMP, I
do not agree with the general availability of "smarter than dump" tool
support.

And the question on the table is not anymore how defaults can be
suppressed; the question has meanwhile become what _is_ configuration.
I am in the camp of those who believe a device needs to distinguish
between what has been "configured" by an explicit action from the
outside world and what exists implicitely as part of the devices
"default" settings or generated by the device based on other settings.

/js

---

From: Phil Shafer <[email-masked]>
Date: Mon, 25 Aug 2008 11:28:50 -0400

"Peter Loborg" writes:
>will happen without the usage of at least some "dumb" tool support...

But even with tools, human users do not immediately disappear.  The
configuration on the box will continue to be something users look
at.  Throwing in uninteresting defaults is a non-starter.

Consider Simon's case of a dynamic default.  It's a more interesting
value than a static default, but you cannot (MUST NOT) confuse the
current value with configuration.  (Imagine running rancid on that
ever-changing config.)

Thanks,
 Phil

---

From: "David Harrington" <[email-masked]>
Date: Tue, 26 Aug 2008 13:44:48 -0400

I think "implicit" is far less understandable than agent-created or
agent-aupplied.

dbh 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Phil Shafer
> Sent: Sunday, August 24, 2008 10:42 PM
> To: Andy Bierman
> Cc: [email-masked]

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 26 Aug 2008 21:39:09 +0200

>       all leafs with agent-supplied values.

What is the difference between a default value and an agent-supplied value? Can an agent supply 
a value if there is no default? I though the YANG contract states that if no value is given by 
the manager, no YANG default is specified, then the leaf does not exist. Am I wrong? What do we 
know about a leaf with no default if it is not explicitly set? Nothing?

Or do we have 4 types of leafs?

1) mandatory-to-set: Always exist. Mandatory, has no YANG defined default. The manager must 
always set a value.
2) public-default: Always has some value. Not mandatory, has YANG defined default. If the 
manager does not set it a YANG defined default will be used.
3) hidden-default: Always has some value. Not mandatory, has no YANG defined default. If the 
manager does not set it the a agent defined default will be  used, its value must be read to 
know it.
4) optional: May or may not exists/have a value. Not mandatory, has no default. If the manager 
does not set it it does not exist/does not have a value

For 3 we should use something like system-created/set to at least indicate there will be a value.
Balazs
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 26 Aug 2008 21:41:01 +0200

As written earlier the existence of a node impacts the following:
1) get, get-config, copy-config
2) the success or failure of the edit-config create/delete/none commands

For edit-config we need to know whether a leaf exists or not, it is not enough to say what you 
get in get-config.

Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 26 Aug 2008 21:41:07 +0200

> bit. But I believe recording this bit on the NETCONF server is pretty

There are implementations that do not have this bit in their existing datastore 
implementations, so this bit should be a SHOULD, not a MUST.

Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 26 Aug 2008 21:40:09 +0200

> node has a YANG specified default value.
leaf foo {
   type int8;
   default 5;
}

Manager issues a get request with-defaults=false and does not receive foo. This can mean:
1) foo is set to default so I don't get it
2) foo exist but I don't have the read rights to see it
3) leaf foo exists because it was explicitly set to 5, but I do not have the read rights to see it

How can you separate 1) 2) and 3) ?

Balazs

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 26 Aug 2008 22:22:00 +0200 (CEST)

Balazs Lengyel <[email-masked]> wrote:
> 
> What is the difference between a default value and an agent-supplied
> value?

The agent-supplied value is present in the data tree.  It cannot be
filtered w/ with-defaults.

> Can an agent supply a value if there is no default?

The spec currently does not say if an agent can or cannot do this.
Users of YANG have interpreted it as if it is allowed:

       leaf observationPointId {
         description "If omitted, the Observation Point ID is assigned
           by the monitoring device.";

(from the ipfix model).

If we add the statement "assigned-by system" then we should have more
strict rules.

/martin

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 27 Aug 2008 00:38:08 +0200

I like systemCreated more and more. Could we have a systemCreated with a value as well? :-)
Balazs

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 26 Aug 2008 19:25:29 -0400

Hi

Implementation-specific default values must not show up in the data
specification but they will show up in the implementation via some form
of a get with defaults command. The only reason to even bring them up in
this discussion would be if we wanted to indicate which elements we
expect implementations to provide default values for (but again, not the
values themselves). I'm trying to see this if this makes sense.  I
suppose it would help backwards compatibility since then you can add
mandatory elements with some sort of tag that says a default value needs
to be provided by the implementation.

Sharon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Balazs Lengyel
Sent: Tuesday, August 26, 2008 6:38 PM
To: Martin Bjorklund
Cc: [email-masked]
Subject: Re: [netmod] various defaults discussions

I like systemCreated more and more. Could we have a systemCreated with a
value as well? :-) Balazs

---

From: Andy Bierman <[email-masked]>
Date: Tue, 26 Aug 2008 19:04:37 -0700

> There is no finished proposal with all details filled in yet.

I like it.  Here's my table, updated with created-by:

(1) default by data type just ignored, not an error if mandatory=true
(2) the default for created-by is 'user' if not specified

   default | mandatory | cr-by |  rule
   --------+-----------+-------+-------------------------
    no     |   false   |  user |  node MAY be created by user (a)
   --------+-----------+-------+-------------------------
    no     |   false   |  sys  |  node MUST be created by system (b)
   --------+-----------+-------+-------------------------
    no     |   true    |  user |  node MUST be created by user
   --------+-----------+-------+-------------------------
    no     |   true    |  sys  |  invalid YANG
   --------+-----------+-------+-------------------------
    yes    |   false   |  user |  node MAY be created by user (c)
   --------+-----------+-------+-------------------------
    yes    |   false   |  sys  |  node MUST be created by system (d)
   --------+-----------+-------+-------------------------
    yes    |   true    |  user |  invalid YANG
   --------+-----------+-------+-------------------------
    yes    |   true    |  sys  |  invalid YANG
   --------+-----------+-------+-------------------------

(a) if not created by user, then agent will not use this leaf at all
(b) beyond the scope of YANG what value will be picked by the agent
(c) if not created by user, than agent MUST use the specified default
(d) the agent MUST use the specified default value

Andy

---

From: Phil Shafer <[email-masked]>
Date: Tue, 26 Aug 2008 22:21:45 -0400

>   default | mandatory | cr-by |  rule

In order to save and restore configuration datasets, a "created-by
system" node must be allowed to be created by the user when the
instance is first created.

>    yes    |   false   |  sys  |  node MUST be created by system (d)

Why would you have a default on a "created-by system" node?  If the
node has a fixed default value, why would the system need to create
it?

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 27 Aug 2008 09:54:53 +0200

> For edit-config we need to know whether a leaf exists or not, it is not enough to say what you 

What are the limitations for edit-config? IMO the agent must be always
prepared to behave as if the knob is there and has the default value,
with the exception that it needn't send it in the get/get-config output
and may also declare it as read-only (e.g., hardwired MTU). I think it's
really important to limit the notion of compliance wrt a given data
model to the communication between the agent and manager and allow for
different implementations (one agent may have the default values in its
database while another doesn't).

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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 27 Aug 2008 13:25:53 -0700

> instance is first created.

OK

> node has a fixed default value, why would the system need to create

So this should be illegal YANG?
It is just redundant.  Seems like a harsh CLR.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 28 Aug 2008 00:17:57 -0400

>It is just redundant.  Seems like a harsh CLR.

If it doesn't make sense, disallowing isn't a CLR.  It's avoiding
a situation that doesn't make sense so we don't need to make code
for a scenario that should not occur.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 28 Aug 2008 09:10:41 +0200 (CEST)

> It is just redundant.  Seems like a harsh CLR.

IMO it's not redundant, it's confusing.  Which one takes precedence?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 28 Aug 2008 05:46:08 -0700

> IMO it's not redundant, it's confusing.  Which one takes precedence?

The YANG definition of mandatory making 'default' illegal
is also confusing people.  This CLR would be
consistent with that one.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 28 Aug 2008 14:53:41 +0200

Hello,
This is actually how many of our nodes work. For us all leafs with default values are actually 
created, so please don't make this forbidden !!!
Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 28 Aug 2008 15:11:22 +0200

> instance is first created.
created by should just mean: the leaf is created by the system, if it is not crated by the 
manager, when its containing container/list-item is created.

So system created should not mean the user can not create it.
system-created has two values true/false false being the default. Using the values user/system 
would seem to imply that a system created leaf can not be created by the user, which is not our 
(my) intention.
Balazs
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Thu, 28 Aug 2008 08:49:49 -0700

Balazs Lengyel wrote:
> Hello,
> This is actually how many of our nodes work. For us all leafs with 
> default values are actually created, so please don't make this forbidden 
> !!!

Phil is saying that default-stmt within the same leaf
as created-by is illegal, just like default-stmt and
mandatory=true on any leaf.

IMO, these are CLRs which reflect one vendors implementation
of the config database.

If 2 clauses overlap in semantics (and they do),
then setting both knobs to indicate the same semantics
is just a little redundant, not an error.
If you have default=3, then it is redundant to
say the agent will create a value if none is provided
(created-by system), since default=stmt does the same thing.

Since the default for created-by is 'system', then it is
implicitly set anytime default-stmt is present.  But if you
explicitly state 'created-by system', that turns it into
a fatal error.

This is barely worth a warning message, let alone a fatal error.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 28 Aug 2008 09:42:37 -0700

> explicitly state 'created-by system', that turns it into

oops -- the default is 'user' not 'system',
but 'created-by system' and 'default 7' in the
same leaf are not contradictory.

I agree with Phil (after 2 years trying not to)
that mandatory means the user must provide a value.
Period. So default and mandatory together contradict,
because one says the agent will never provide a value,
and the other says here's the value the agent will provide.

Created-by and default together is not the same situation.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 28 Aug 2008 19:18:06 +0200

Phil Shafer wrote:
> I disagree.  These are two rules that when combined make behavior
> I don't find attractive.  If a leaf is "created-by system" and has
> a default, then the system is responsible for making it if the
> client does not set it, but the server must must make it with a
> fixed value.   Instantiating a fixed default value has little
> positive value and I'm happy to make a CLR that help data modelers
> avoid this pitfall.

Balazs: Some of our major systems already do this, so you are asking us to redesign the 
database behind the Netconf implementation. I don't like that. If we only need to implement a 
new interface (NETCONF) for our existing configuration database thats MUCH cheaper then 
redesigning the database as well.

Our customers have a few more important requests then changing the handling of defaults. Even 
if you think ,this is not the best solution, we don't get complaints about it. It is simple 
understandable, and a tool can filter the defaults if needed.
So don't make the CLR.

Balazs

---

From: Phil Shafer <[email-masked]>
Date: Thu, 28 Aug 2008 13:06:52 -0400

>explicitly state 'created-by system', that turns it into

Leafs with default values are _not_ automatically created by the
system.  The default value is implicit.  Since both client and
server know the value, it need not appear in the config database.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Thu, 28 Aug 2008 11:40:45 -0700

> server know the value, it need not appear in the config database.

Maybe inside your system it works that way.
We need to focus on the impact of YANG statements
on NETCONF PDU exchanges, and not worry about
various implementation details within an agent.

If I store the leaf instance-identifier,
leaf type, leaf default inside the agent,
or if I create a real node inside the database containing
the default value, it is just an implementation detail.

What difference does it make how I construct
the <rpc-reply>, as long as the correct behavior
for the <get-config> operation is observed?

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 28 Aug 2008 20:59:50 +0200 (CEST)

> > IMO, these are CLRs which reflect one vendors implementation

The YANG spec does not say anything about how to implement the config
database.  In fact, we're trying hard to make sure that the rules we
define are flexible enough to work with more than one implementation.
With the addition of the with-defaults capability, I think we have
managed to do that.

> > (created-by system), since default=stmt does the same thing.

No, they do *not* do the same thing.  If a leaf is marked as
created-by system, it will not be a "default" value, and thus cannot
be filtered out if with-defaults=false.

So having both statements is confusing.  Should the server use the
fixed default value in the data model and mark it as a default, or can
it provide any value it wants to and not mark it as default?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 28 Aug 2008 12:12:28 -0700

> With the addition of the with-defaults capability, I think we have

I don't.
The YANG spec does not yet have a clear and contained mapping
to the NETCONF protocol PDUs.

> it provide any value it wants to and not mark it as default?

Created-by system just means it is created by the agent
if the manager does not provide a value.  It should mean
that the agent is free to choose a value based on the
semantics of the leaf.  If the leaf has a default,
that's just another restriction, like 'uint8 (1..100)' for
the data type.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 28 Aug 2008 21:13:45 +0200 (CEST)

Balazs Lengyel <[email-masked]> wrote:
> Balazs: Some of our major systems already do this, so you are asking
> us to redesign the database behind the Netconf implementation.

IMO, you will still be able to instantiate default values if you want
to.  Nowhere do we say that an implementation MUST or MUST NOT store
default values.  What we *do* say is that if your device supports the
new :with-defaults capability, it should be able to filter out leafs
w/ default values.  If your device cannot do this, don't advertise
:with-defaults.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 28 Aug 2008 21:19:01 +0200 (CEST)

> to the NETCONF protocol PDUs.

Please raise your concerns about this.  What should be improved?

> that's just another restriction, like 'uint8 (1..100)' for

Hmm.  Are you saying that if the default statement is present and
created-by system is present, then the default value is more like
DEFVAL from SMIv2?  I.e. the server must create a value, and the
default valus is a hint.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 28 Aug 2008 12:37:35 -0700

> Please raise your concerns about this.  What should be improved?

There are bits as small as single sentences scattered throughout
the document which say how NETCONF works for a YANG data model.
I would prefer them all collected in one section, that
made it very clear what NETCONF PDU behavior is expected.

> DEFVAL from SMIv2?  I.e. the server must create a value, and the

no -- I am saying that created-by system is just
a redundant field if a default-stmt is present.
We do not make the following YANG illegal (I hope!)

    leaf foo {
      type uint8 { range "0..255"; }
    }

The draft should just suggest that DM designers not
use extra YANG statements when they are not really needed.
It should not be an error.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 28 Aug 2008 21:49:35 +0200 (CEST)

> a redundant field if a default-stmt is present.

Do you agree that if I have this:

  leaf foo {
     type int32;
     created-by system;
  }
  leaf bar {
     type int32;
     default 42;
  }

and a server replies to a <get> with with-defaults=false, then the
auto-created value of 'foo' is present in the rpc-reply, but the default
value of 'bar' is not present?

Assuming you do agree, it means that system created values are not
marked as defaults.  What happens if I have 

  leaf foobar {
     type int32;
     default 42;
     created-by system;
  }
   
will it be present in the rpc-reply or not?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 28 Aug 2008 13:09:16 -0700

> value of 'bar' is not present?

no - I much prefer Phil's interpretation of with-defaults:

   true == I want everything regardless of how it got there
  false == I want only the stuff explicitly set by operators
           or the startup config

I think the other interpretation is also valid,
but needs more clarification.

> will it be present in the rpc-reply or not?

no

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 29 Aug 2008 11:18:29 +0200

> w/ default values.  If your device cannot do this, don't advertise

1) Currently the with default draft allows you to filter data that was (explicitly) set to its 
default value as default data. It might not be best practice but it is existing practice in 
some systems, so it is is allowed.
I don't want to loose that.

2) If a leaf is system-created but we known a priori the specific value that the system will 
use (unless the manager sets something else), we should be able to include this information in 
YANG, is there any reason to force hiding this information? This was the case I wanted to 
handle with default and systemCreated=true. Do you agree with the idea?

Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 29 Aug 2008 11:19:25 +0200

> DEFVAL from SMIv2?  I.e. the server must create a value, and the
I would argue it is not a HINT, it is a strict definition. The system MUST create the leaf 
using the value in the default statement. If you don't know or if you are just hinting, put 
that into the description.
Balazs
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 29 Aug 2008 11:28:30 +0200 (CEST)

Balazs Lengyel <[email-masked]> wrote:
> 
> 1) Currently the with default draft allows you to filter data that
> was (explicitly) set to its default value as default data. It might
> not be best practice but it is existing practice in some systems, so
> it is is allowed. 

Sure.

> 2) If a leaf is system-created but we known a priori the specific
> value that the system will use (unless the manager sets something
> else), we should be able to include this information in YANG, is
> there any reason to force hiding this information? This was the case
> I wanted to handle with default and systemCreated=true. Do you agree
> with the idea? 

If the value is static, why would you mark it as system-created true
when 'default' does what you want?

Assume you're in a WG, defining a data model for some technology.  You
know that there's a static value (42) that should be used for the leaf
'foo' if the client does not specify one.  Currently, you would do:

   leaf foo {
      type { int32; }
      default 42;
   }

With your proposal, you can also do:

   leaf foo {
      type { int32; }
      default 42;
      system-created true;
   }

How will a DM designer know which one of these to use?

With just a 'default', my implementation will not store this in the
db, but your implementation will.  With both system-created and
default, you force all implementations to store the value.

(*if* we were to do this, which I don't want to, I'd rather not reuse
the statement 'default' for this, b/c default means something else.
I'd rather do:

   system-created true {
       value 42;
   }

or somthing)

/martin

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 29 Aug 2008 11:32:38 +0200

> but needs more clarification.
This will mean we already have at least 3 types of data:
- real data set by the manager
- data set by the agent, that is there in the datastore, but still should not be returned for 
with-defaults=false
- data that is no there, it's value is used as a default

This is getting too complicated for me. It would be a more simple solution to say:
- system-created only means that the data will be created unless the manager sets it
- once it is created it is handled just the same way as data set by the manager
- if you don't want to see it in your config, don't mark it system-created, make it just default
- for normal default allow an unspecified value, for the case where you don't know the value a 
priori or where the value is not just a simple literal

This way you only have 2 types of data: real data, default data.

Balazs

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 29 Aug 2008 11:39:10 +0200 (CEST)

Balazs Lengyel <[email-masked]> wrote:
> - data set by the agent, that is there in the datastore, but still
>   should not be returned for with-defaults=false 
> - for normal default allow an unspecified value, for the case where
>   you don't know the value a priori or where the value is not just a
>   simple literal 
> 

No you still have three type of data:

  - real data set by the manager
  - known defaults
  - unknown defaults (must be read with with-defaults=true)

If you want to keep it simple, stick to:

  - real data set (by the manager or agent; always returned)
  - known defaults (not returned in with-defaults=false)

/martin