Subject: [YANG] mandatory & default

From: Andy Bierman <[email-masked]>
Date: Fri, 25 Jan 2008 07:17:35 -0800

Hi,

I don't think every vendor deals with agent-created defaults in the
same way, and there is zero chance every implementation will converge
on one interpretation.

The important thing to consider is:
   what is important for standards-based configuration?

Here is the bottom line:

  - RFC 4741 requires that *all* config database objects be returned
    in a <get-config> without any filters

  - All data nodes that exist in the configuration have some value
    (consider the value for 'empty' to be present/not-present)

  - An extension is needed (e.g., with-defaults=false) to change the
    behavior of RFC 4741 wrt/ returning a subset of all nodes without
    any filter defined

Phil seems to be arguing that nodes that contain the agent-specified
default value are not really there.   Yet, if the manager
sets a node explicitly to the default value, it is there.
IMO, this is rather confusing, and broken.

The idea of tracking down stacks of offline vendor documentation
to determine the theoretical values of these 'default nodes', instead of
simply asking the agent for the real values, is a non-starter.
That may be good enough for CLI, but not standards based configuration.

Andy

_______________________________________________
YANG mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/yang

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 25 Jan 2008 16:28:46 +0100

Hello,
I agree with Andy that a leaf either exists or not. I don't like half existing defaults.
Please also consider that defaults effect much more then just the get-config results. (See 
attachment.
I attached a file about an alternative (and I hope very understandable) solution. Please start 
to tell me why it is bad :-)
Balazs

PS.Sorry if my proposal is long.

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]
I think we try to cram too many different properties into just 2 YANG statements (mandatory and default). I think we should explicitly state these.
Things I see missing
- default value(effect the full life cycle) or initial value(only effect creation)
- mandatory at creation or mandatory in the datastore
- is the leaf's value seen in get-config

Also we risk muddying our concepts just to solve the default problem which I consider a VERY bad thing. Concept's we are endagering are:
- Do we specify the data-store or the XML on the wire. If we specify the datastore, we better state whether a default leaf exists or not.
- Do the default leafs exist or not. I hate half-existing leafs.

I fear unclear concepts even more then the feature-creep.

So I tried to think of an alternative notation:

Yang statements:
- mandatory: means it must be present in the datastore if the parent exists
- initial-value: Will be used at creation of the parent if no value for 
the leaf is specified. Anything that was created with an initial value 
will really exist in the configuration. Later it does not matter if it 
was created explicitly or with an initial value.
- default-value: means if the leaf does not exist, the server will use 
this value internally, but the leaf really does not exist. Can not be 
used with mandatory. "Must" statements consider the leaf not-existing but 
we introduce a special hasDefault() function. Or alternatively as a 
CLR "must" considers the leaf existing.)

Netconf options:
- with-defaults true/false. True means that get-config will return leafs 
that do not exist, but have a default. False means that only existing 
leafs are returned. (Leafs created with initial value included.)

So answer to the below questions are:
Q1) initials yes, defaults no
Q2) Derived fron Q1 (depens on whether they exist.)
Q3) Derived fron Q1. Leaves set with initial are just normal leaves. 
You cant delete a default, it does not exist.
Q4) No difference for intials, there is a difference for defaults
Q5) Yes for initials, see with-defaults for defaults
Q6) Derived from Q1 (the existence of a leaf), yes for initials, no for defaults
Q7) Derived from Q1, yes for initials, no for defaults but hasDefault() function added

DT1) mandatory, noinitial, nodefault
DT2) mandatory, noinitial, nodefault
DT3) nomandatory, noinitial, default
DT4) same as DT3 with defaultref or dynamicDefault 
DT5) nomandatory, initial, nodefault 
DT6) same as DT5 with initialref or dynamicInitial
DT7) createOnly is a separate issue, but it could be createOnly, mandatory, noinitial, nodefault
DT8) forget it

===============================================================================================================================
Questions about default values:

Let's not forget that the handling of defaults effect much more then the 
result of the get-config. IMHO the basic question is simply "does a leaf 
set only due to it's default exist?" (in the conceptual database).

This effects the following:
Q1) Does it exist?

Q2) How does edit-config create/delete work on it? E.g. can you create a 
leaf that already exists(?) due to a default value?

Q3) If you later explicitly delete a leaf with a default value what 
happens. Will it cease to exist? Will it automatically pop-up with the 
default value again?

Q4) Is there any difference between a leaf set by the default and a leaf 
explicitly (edit-config replace) set to the same value?
I really hope not.

Q5) Will get-config return such a leaf?
It may or may not depending on the implementation or the with-defaults 
option

Q6) Will a non-presence container exist if it has leafs set by default? 
This will effect how edit-config none is handled.

Q7) Does a "must" statement consider such leafs to exist.
I assume yes.

===============================================================================================================================

Different types of defaults: 

There seems to be quite a few ways to view the value of a single
leaf.  I have listed some of them below, and how YANG supports them.
It would be really good if YANG could support all these cases with
simple extensions.

What                                    How? (in YANG)
----                                    --------------

DT1) 
client must set                         mandatory = true

DT2) 
client may set, if not                  mandatory = false
set it means something.
if not set, the server
internally knows it's not there

DT3) 
client may set, if not set              default
there is a static default.
if not set, the default is
used internally by the server.

DT4) 
client may set, if not set              no formal support
there is another object whose           extension will work,
value is used (dynamic default or       with no default and
defaultref)                             mandatory = false
if not set, the other value is
used internally by the server.           

DT5) 
client may set, if not set              no formal support,
the server creates it with some         extension will work,
static value                            with no default and
                                        mandatory = false
                                        [is this really true??]

DT6) 
client may set, if not set              <same as above>
the server creates it with some
dynamic value

DT7) 
client MUST set at creation time,        no formal support,
but must not modify later.               extension will work,
                                         with mandtory = true
                                         (assuming that a client is
					 able to handle errors...)

DT8) 
client MUST NOT set at creation,         no formal support,
but may modify later                     extension will work,
[is there a use case for this?]          with mandatory = false
                                         (assuming that a client is
					 able to handle errors...)

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 25 Jan 2008 09:15:04 -0800

Balazs Lengyel wrote:
> Please also consider that defaults effect much more then just the 
> get-config results. (See attachment.
> I attached a file about an alternative (and I hope very understandable) 
> solution. Please start to tell me why it is bad :-)
> Balazs
> 

Here is just a snippet to discuss:

Yang statements:

------

IMO, this 'default-value' is unacceptable.
A manager application may need to retrieve all the nodes that
exist in the database.  Requiring complex analysis of multiple
external documents to determine the value of some of the nodes
seems like a huge burden on application developers.

How does the manager application know for sure whether
an implementation actually supports a node or not?

If some nodes are inaccessible under all conditions, but they
really exist with some value, then how can a manager application
know for sure if the agent really is using the specified default?

If the value of the default changes over time, or varies between
products or vendors, then how can a manager application know
for sure what exact version of the default value is being used by the agent?

I know of many operator horror stories in years past, caused by silent,
undocumented default value changes between releases, and different code
bases across product platforms.  A full diff of the config files
before and after the upgrade would have instantly revealed the
source of the problem, but of course, since nobody needs to
see these CLI defaults, that was not an option.

Assumption is the mother of all foul-ups, to paraphrase the B movie...

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 25 Jan 2008 20:30:22 +0100

Andy Bierman píše v Pá 25. 01. 2008 v 10:19 -0800:

> I am not objecting to anything a manager application wants
> to do with data it receives from NETCONF PDUs.  I do not
> think the IETF should standardize manager internals or agent internals,
> or assume a hierarchical manager architecture, or any architecture
> other than the peer-to-peer, session-based, connection-based, etc.
> requirements stated in RFC 4741.

I wouldn't object either if the server-side handling of defaults
(with-defaults=true) were an optional capability and the standard
behaviour at the level of the NETCONF protocol (RFC 4741) stays as it is
(send everything, no hidden parameters, no notion of default values).

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 25 Jan 2008 23:38:24 +0100 (CET)

Hi,

> same way, and there is zero chance every implementation will converge

Don't you think that we must have one, clear definition of how to
handle this?  How can anything else ever be interoperable?

>     in a <get-config> without any filters

Ok.

>     (consider the value for 'empty' to be present/not-present)

Ok.

>     behavior of RFC 4741 wrt/ returning a subset of all nodes without

Or, if you, for a moment, try to view thing from the other side, you
need an extension with-defaults=true to actually get the default
values, since they are not stored in the configuration data store.

> default value are not really there.

Right, since they are not there in his implementation.  Why would you
store stuff that's not even needed to store?  That's just a waste of
resources.

> Yet, if the manager

I think it makes perfect sense.  If you set it, it's there.  IMO it's
more confusing if you set it and it's sometimes _not_ there (b/c it
happened to be the default).  NOTE: I'm NOT saying that this is the
*only* way to do defaults, I'm just saying that this defintion is
consistent.

> to determine the theoretical values of these 'default nodes',

Did anyone suggest that?  The default value is part of the data model,
and you should be able to get the data model through schema discovery.
There are lots of other information you need from the data model
that's not in the instance document, like type, config true/false,
relationships etc.

> instead of

I don't agree.  I do agree that being able to get defaults from the
box is useful, that's why the with-defaults extension is good.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 25 Jan 2008 15:12:31 -0800

> values, since they are not stored in the configuration data store.

I disagree.

If I invoke an <edit-config> and set the leaf to this
default value, it is still not there?

If I invoke an <edit-config> and set the leaf to a
non-default value, it is clearly there.

Whether the manager or the agent sets the leaf to the default,
it is there from a NETCONF protocol PoV.

> store stuff that's not even needed to store?  That's just a waste of

Nobody said anything about storing the value.
It is an implementation-specific matter as to how
an agent generates a reply to a <get-config> request.
The defaults do not have to be stored -- they can
be generated on the fly.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 26 Jan 2008 00:26:18 +0100 (CET)

> default value, it is still not there?

Yes it's there.

> non-default value, it is clearly there.

Yes it's there.

> it is there from a NETCONF protocol PoV.

The crucial point is that - in this way of seeing things - the agent
does not set the leaf to the default.  Again, I do understand that
there are other ways to define how defaults work.  I'm just trying to
explain the rationale for this one.

> Nobody said anything about storing the value.

I just tried to explain why "nodes that contain the agent-specified
default value are not really there". 

> The defaults do not have to be stored -- they can

Agreed.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 25 Jan 2008 16:06:53 -0800

>> non-default value, it is clearly there.

Therefore this approach is broken.

   container interfaces {
     list interface {
       key name;

       leaf name { type InterfaceName; }

       leaf mtu {
         type uint32;
         default 1500;
       }
     }
   }

I start out with a get-config, and mtu is not there:

  <interfaces>
    <interface>
      <name>eth0</name>
      <mtu>1600</mtu>
    </interface>
    <interface>
      <name>eth1</name>
    </interface>
  </interfaces>

Does /interfaces/interface[name=eth1]/mtu exist or not?

If not, then I can do an edit-config to create it:

   <config>
     <interfaces>
       <interface>
         <name>eth1</eth1>
         <mtu nc:operation='create'>1500</mtu>
       </interface>
     </interfaces>
   </config>

Does this succeed?  NETCONF says it should, because the
leaf did not get returned in the previous <get-config>.

Now I do a get-config again and get back:

  <interfaces>
    <interface>
      <name>eth0</name>
      <mtu>1600</mtu>
    </interface>
    <interface>
      <name>eth1</name>
      <mtu>1500</mtu>
    </interface>
  </interfaces>

The leaf never really changed value, but you would never know
that from the NETCONF PDU responses.

After a system reboot, does the agent 'remember' that mtu
was set to 1500 by the manager, so the initial <running/>
config from NV-storage after the next reboot has an mtu leaf
for eth1?

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 26 Jan 2008 11:20:45 +0100 (CET)

Hi,

> Does /interfaces/interface[name=eth1]/mtu exist or not?

Not in the config datastore, no.

> Does this succeed? 

Yes.

> NETCONF says it should, because the

The value is stored in NV-storage, just like all other values set by
the manager.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sat, 26 Jan 2008 07:01:57 -0800

> Not in the config datastore, no.

But here is where this CLI-based design is broken.
If a manager sends jumbo packets on eth1, they will not be accepted.
There is a maximum transmission unit size in effect on eth1,
but the manager is told there is none in the <get-config>.

The response "oh no, there is an MTU value in effect, just not in the config"
is really broken.  It's not state data, and it's not config data, but if
the manager does not know the value, it cannot reliably configure other
devices that send packets to 'eth1' on this agent.

IMO, the mtu is clearly config data, and clearly in effect at
all times eth1 is accepting packets.  The config returned
in NETCONF PDUs should match.  Filtering out these defaults
is a separate issue from whether they exist or not.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Sun, 27 Jan 2008 22:22:52 -0500

[replying to multiple Andy-grams]

>it is there from a NETCONF protocol PoV.

NETCONF leaves all this to the data model, so there's no single
NETCONF POV on this issue.  This is designed to support existing
views of configuration issues, including defaults.

>The defaults do not have to be stored -- they can

If I'm using NETCONF to archive configurations, I don't
want them littered with defaults.  Similar for if I'm
viewing them in the equivalent of a mib browser.  I want
to see the statements that someone has explicitly configured,
not volumes of uninteresting defaults.

Part of putting these values into YANG modules is to allow
interested parties (applications, developers) to know these values
as they are helping the user create new instances.  To my mind, the
"with-defaults" is useless for this scenario, since I want to know
the defaults _before_ I make the config, not after.

The KISS view of config is used for CLIs because is keeps the
noise to a minimum.  This need doesn't disappear when the
config moves into the application/automation world.

>Message-ID: <[email-masked]>
>Date: Fri, 25 Jan 2008 16:06:53 -0800
>From: Andy Bierman <[email-masked]>
>

No, the system records as the configuration only those fields which
are interesting.  For example in JUNOS, we define "interesting" as
anything the user told us to do.  In IOS, they define "interesting"
as any non-default values.  IMHO, you're trying to define interesting
to include some very boring defaults.

>Message-ID: <[email-masked]>
>Date: Sat, 26 Jan 2008 07:01:57 -0800
>From: Andy Bierman <[email-masked]>
>

The application can find all the information about "mtu", including
its default value, in the metadata.  The application can show this
default value to the user as they create a new interface, and the
application can know that if there's an <mtu> in the interface, its
there because someone wanted it, and that's it's not noise.

>devices that send packets to 'eth1' on this agent.

Nope, it's not config data.  It's a default value.  The device
doesn't need it to perform the job of configuration, which is
defined in the NETCONF spec as:

   Configuration data is the set of writable data that is required to
   transform a system from its initial default state into its current
   state.

Default values aren't required in config data.  Or wanted.

If I've got 64,000 interfaces, I don't need to see this default
value for each interface, let alone the hundred other knobs for
each interface that have perfect reasonable and completely
uninteresting default values.

>is a separate issue from whether they exist or not.

The issue isn't filtering them out.  The issue is are defaults part
of the configuration?  I understand the need for a mechanism for
discovering them, both inline and in metadata, but I don't see any
win in considering such noise as part of the configuration of a
device.

We are working hard to make devices _more_ managable.  Adding a
couple of orders of magnitude of noise into the configuration
means:
- performance issues (as my 1m config turns into 100m)
- upgrade/downgrade issues (as defaults for unused features break
  on software that doesn't support them, even if they are completely
  unimportant)
- readability issues (as adding noise makes the config less readable
  and the purpose of using xml was human readability for debugging
  and monitoring)

Inline defaults is broken, to lift your words, since it takes a
complex problem and makes it more complex.  We should be simplifying,
reducing, and giving better visibility into the important parts of
configuration, not polluting them with noise.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Sun, 27 Jan 2008 20:10:33 -0800

> [replying to multiple Andy-grams]

We strongly disagree on the interpretation of RFC 4741
and whether a node with a default value really exists or not.

It is very fragile SW design to assume the agent is using the exact default
that was tracked down in the documentation.

It is up to the operator whether knowing that a node
is actually supported, and knowing the exact value set by the agent,
is a waste of space or important debugging information.

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 27 Jan 2008 20:54:51 -0800

Hi -

> From: "Phil Shafer" <[email-masked]>
> To: "Andy Bierman" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Sunday, January 27, 2008 7:22 PM
> Subject: Re: [YANG] mandatory & default 
...
> want them littered with defaults.
...

If I'm archiving a configuration, I want to know *exactly*
what it is.  One of the reasons for archiving configurations
is so that if a box fails, a replacement can be quickly made
to function in its place.   If there is even a remote chance
that a default value might change between releases or on
different versions of a hardware platform, that value needs
to be included in an archive of the configuration.

Randy

---

From: Phil Shafer <[email-masked]>
Date: Mon, 28 Jan 2008 01:50:09 -0500

"Randy Presuhn" writes:
>One of the reasons for archiving configurations
>to function in its place.

Loading the saved file with defaults won't make this
any saner, safer, or stronger.  It increases the fragility,
but incorporating into the saved file tons of stuff about
which you don't care.  It something fails on these values
that you don't care about, you are broken.

>If there is even a remote chance

The chance of a change in defaults (which annoy customers to
no end) is minor compared to the change of adding features (which
customers insist on) and the need to support downgrading (which
customers insist on).

Consider this example from JUNOS-land.  We have a set of foo-options
containers that are used to hold media-specific options under
the [interfaces] statement.  These options are numerous, verbose,
and rarely used.  If I add a new statement in release 9.0 and
start emitting a boring default value for it, I can no longer
load that config in any release predating 9.0.

In avoiding a rare bug (changing defaults), you'll break real
operational usage.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Mon, 28 Jan 2008 02:07:52 -0500

>and whether a node with a default value really exists or not.

Are you saying that 4741 forces defaults to be emitted in <get-config>?

>that was tracked down in the documentation.

Here we strongly disagree.  Adding noise to configs makes them
more fragile, not less so.

In using the term "tracked down", are you missing that putting these
values in the YANG module (or any metadata/schema) makes them more
than just documentation?  An application should be able to move
from a node in the data tree to the YANG definition of this node
with ease.  Finding the default value (and the data type, range,
and all the other constraints on the data values) should be no
problem for the client application.

>is a waste of space or important debugging information.

You should publish the with-defaults capability as a draft.  I
do see this as having value, but disagree with making it the
default behavior.  If there's a way to turn it on, operators
that want it on can turn it on in their client software.

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 28 Jan 2008 09:18:17 +0100

> values, since they are not stored in the configuration data store.

The important point is whether they are defined in the data model. If
they are mandatory, then the device must tell their value - unless
instructed otherwise (either by a filter or by a default-handling
extension).

And I don't want to have a special data model for each device that
implements a particular subset of permitted mtu values.

> store stuff that's not even needed to store?  That's just a waste of

Well, if the devices can be potentially asked (under any circumstances)
what the value is, it must be able to return it - it doesn't matter
whether it is physically stored, computed on the fly or whatever.

I think the confusion again stems from different interpretations of
validity. IMO the most straightforward one is that I take a concrete
full configuration (e.g., as an XML document) and compare it to the data
model it is supposed to comply to. In particular, if an element is
mandatory in the DM, I must see it in the configuration. Note that no
context or other info is needed for this validation, like whether the
configuration comes from the device or from the manager etc. 

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 28 Jan 2008 09:24:40 +0100

See below!

> CLR "must" considers the leaf existing.)
[BALAZS]: Using the with-defaults statement you will get back the non-existing default even 
though the leaf "set" only by the default value does not exist.
Balazs
> exist in the database.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 28 Jan 2008 09:46:36 +0100

> to be included in an archive of the configuration.

If your replacement is using the exact same hardware configuration and
the exact same firmware version, you do not need to worry about the
defaults.

If your replacement is not using the exact same hardware configuration
and the exact same firmware version, there is a chance that things
won't work as expected, with and without saved defaults.

If things fail, you need to have a human to figure out what is the
configuration and what is saved default noise. So the bottom line of
my thinking is that you like to have both - the explicitly set config
and the full configuration state including the defaults. Only if you
have both, you can reasonably debug configuration playback errors on
replacement hardware.

/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: Ladislav Lhotka <[email-masked]>
Date: Mon, 28 Jan 2008 10:02:13 +0100

> If things fail, you need to have a human to figure out what is the

Here is the problem with changed defaults: things will not fail, they
will just work differently from what you expect.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 28 Jan 2008 10:47:03 +0100

On Mon, Jan 28, 2008 at 10:02:13AM +0100, Ladislav Lhotka wrote:
> Juergen Schoenwaelder p????e v Po 28. 01. 2008 v 09:46 +0100:

Well, applying a default from an old firmware release to a newer
hardware firmware combination can as well lead to something that does
not fail but work differently from what you expect.

My point is you need to be able to (a) get all configuration settings
of a box and (b) the subset that was explicitely configured. It is
then the operator's choice what to use where and when. Trying to rule
out (a) over (b) or (b) over (a) is wasting time and bandwidth.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 28 Jan 2008 11:10:12 +0100

> out (a) over (b) or (b) over (a) is wasting time and bandwidth.

I don't intend to rule anything out, I just don't wan't to have (b) as a
mandatory function in all devices. It should be an optional capability.
On the other hand, (a) is by all means essential.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 28 Jan 2008 11:41:02 +0100

On Mon, Jan 28, 2008 at 11:10:12AM +0100, Ladislav Lhotka wrote:
> 
> Juergen Schoenwaelder p????e v Po 28. 01. 2008 v 10:47 +0100:
> 
> > 

Our problem is that others believe (b) is by all means essential and
(a) should be an optional capability. This is our dilemma.

Why is it not OK to have (a) and (b)? Why do you not want to have (b)
as a mandatory function in all devices? Do you think it is too costly
to maintain this additional bit per explicitely configured knob or are
there other reasons?

/js

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 28 Jan 2008 11:49:51 +0100

Hello,
Some basic statements for me:
1) the get-config results can or can not contain defaults based on the with-defaults parameter, 
so the content of get-config is not a deciding factor between the different "default" alternatives.
2) Storing the default values is an internal issue for the implementation, which is independent 
from the existence (or not) of a leaf in the conceptual database.

Balazs

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 Jan 2008 03:29:13 -0800

> that you don't care about, you are broken.

this is not correct.
If you load a config with the full set of values, then
agent is forced to accept the value or issue an error.
This is not fragile.  This is debugging.

Fragile is when the new software image sees that no value
is given for the foo-knob, so it assigns a *different*
default value than the last SW image, and does not complain
at all.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 28 Jan 2008 13:08:21 +0100

> to maintain this additional bit per explicitely configured knob or are

I guess it is probably because two different implementations are around:

1. The device has an internal "database" of operational parameters
(perhaps as registers, variables and structures in its firmware and
software) but its configuration is something else, for example only the
stuff that the user specified. For this implementation it is an extra
burden to retrieve the parameters from the operational structures and
write them to the configuration.

2. The operational values are explicitly represented in a configuration
database and the internal operational values are either taken directly
from it or synchronised with it (e.g., via ioctl for firmware). This
implementation can simply dump the entire database while it is an extra
burden to keep the information about whether a parameter has been
changed or not.

I understand that JUNOS, IOS and some Unix daemons like GateD use 1
while we use 2 in our devices, but it doesn't matter. The question
really is: Is it OK if we allow a device to keep part of the essential
operational parameters for itself? If the answer is NO, then
implementation 1 must be able to do the homework and collect all the
values for the manager. So, for me (a) is a necessity.

On the other hand, approach 2 doesn't hide anything, it only poses
technical difficulties to the manager by sending the entire operational
configuration. However, I claim it is possible to protect the human user
from being overwhelmed by other means outside the device, i.e., (b) is
not a necessity.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "tom.petch" <[email-masked]>
Date: Mon, 28 Jan 2008 16:16:26 +0100

----- Original Message -----
From: "Andy Bierman" <[email-masked]>
To: "Phil Shafer" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, January 28, 2008 5:10 AM
Subject: Re: [YANG] mandatory & default

> is a waste of space or important debugging information.

I am very much with Andy (and Randy) on this one.  Knowing all the parameters
that affect how a box functions is vital; it may be the only way to work out why
it is not working as the operator thinks it should be.

I would say that having access to both the full and the specified configuration
is a MUST.  If forced to choose which had to be implemented, I would go for the
full configuration every time.  Computers can simply and reliably remove the
extra information, they cannot (as) reliably insert the supposed defaults as
known on the device.

Tom Petch

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 Jan 2008 09:10:43 -0800

> extra information, they cannot (as) reliably insert the supposed defaults as

I think Juergen also agrees that access to all the parameters is sometimes
needed to debug a broken network.

I think there is some consensus that a mechanism is needed to retrieve
just the non-defaults, or retrieve everything.  I have already published
the 'with-defaults' mechanism:

http://www.ietf.org/internet-drafts/draft-bierman-ncx-ext-00.txt

There is no capability URI defined to advertise this extension.

I have also implemented 'per-session' parameters (ala set term)
to set the session default for the per-PDU 'with-defaults', to simplify
manager access.

At a minimum, there should also be a read-only leaf added to
the NETCONF Monitoring DM to indicate the agent-wide default
for the 'with-defaults' flag.  (Per session control is extra credit ;-)

An agent can leave out the defaults as the normal case if this
global flag is set to false.  However, the 'with-defaults=true' flag
must be honored when added to a get* or copy-config PDU.

Andy