Subject: [netmod] leaf encoding rules

From: Andy Bierman <[email-masked]>
Date: Thu, 07 Aug 2008 10:29:46 -0700

Hi,

 From 7.6.5:

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

The sections on built-in types do not define any XML encoding
rules (yet).  When will those be done?

    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.

I strongly object to this paragraph.
It has no place in the YANG specification.
If you want to modify the NETCONF operations,
then do it in the NETCONF WG.

I also object to the idea a module which happens to be
specified in a YANG module should use a special 'YANG version'
of the NETCONF protocol. The manager should control
the retrieval of defaults, not the agent.  This feature
has nothing to do with YANG.

Andy

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

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 07 Aug 2008 22:09:04 +0200 (CEST)

Hi,

> rules (yet).  When will those be done?

Section 8 says:

   The lexicographic representation of a value of a certain type is used
   in the XML encoding over NETCONF, and when specifying default values
   in a YANG module.

And then each built-in type has a section called "Lexicographic
Representation", e.g. 8.1.1.

> then do it in the NETCONF WG.

I don't agree that the NETCONF operation is changed.  rfc4741 does not
say one way or the other re. defaults.  NETCONF has no concept of
default values.

The intention of this paragraph is to allow a capability such as
'with-defaults' to control if defaults are sent or not.  IMO it is
better to keep this paragraph - if we remove it people will not know
if defaults should always be sent or what the intention of YANG was.
Esp. since there is no standard 'with-defaults' capability, and it
does not seem that it will get standardized any time soon.

> the retrieval of defaults, not the agent.

I agree.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 07 Aug 2008 13:27:43 -0700

> say one way or the other re. defaults.  NETCONF has no concept of

That is not true.
It the leaf exists in the system, because mandatory is false
and there is a default value to apply, then it is part
of the configuration database.

7.1.  <get-config>

    Description:

       Retrieve all or part of a specified configuration.

      ...

      filter:

          The filter element identifies the portions of the device
          configuration to retrieve.  If this element is unspecified, the
          entire configuration is returned.

RFC 4741 clearly states that a get-config (and also get) without
any filter returns the entire configuration database.  Nowhere in
the text on filtering does it mention any consideration
of the default value as part of the filtering process.
That means it is NOT part of the filtering process.

I do not agree at all that agent MAY leave these nodes out,
if they claim conformance to RFC 4741.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 07 Aug 2008 23:13:43 +0200 (CEST)

Hi,

Andy Bierman <[email-masked]> wrote:
> any filter returns the entire configuration database.

Right, but it does not say that if a leaf has a default, then it exist
in the configuration database.  So if you have the view that the
configuration consist of all data that the user explicitly sets, then
you are compliant if defaults are not returned.

I think it is clear that rfc4741 is a bit fussy on this subject.

/martin

---

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

Hello,
I think whether a leaf set by default exists or not should be a topic on the interim. We have 
been debating this for a long time and I would like to have it very clearly described after the 
interim.

We have discussed all 3 possibilities:
A) Configuration is what drives a device, so it is not important how it got there: default or 
an explicit set. This means a leaf set by default DOES exist.
B) Configuration is what you set manually to make the device work, so even if a default does 
modify how the device works, a leaf set by default DOES NOT exist.
C) We try to accommodate both views and try to avoid saying whether such a leaf exists or not.
D) Make this a capability, but that might be an overkill.

My preference is A, but not everyone agrees. We should also consider that the existence of a 
leaf effects at least the following:
- results of get/get-config
- success of edit-config for delete/create
- evaluation of must statements
- evaluation of unique statements
- else?

It is a separate question whether such values should be presented in replies to get/get-config.

Balazs

-- 
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: Balazs Lengyel <[email-masked]>
Date: Fri, 08 Aug 2008 11:18:14 +0200

> does not seem that it will get standardized any time soon.

Maybe we should get with-defaults standardized.

I hereby ask the NETCONF/NETMOD community and specially the chairs of NETCONF if they would 
accept as a new NETCONF work item a small draft adding a with-defaults option to Netconf as a 
capability. As my Partial locking draft seems to wind down (Is this wishful thinking :-) I 
might even volunteer to write a draft on with-defaults.

Opinions? Good idea? Feasible idea?

Balazs

---

From: Andy Bierman <[email-masked]>
Date: Fri, 08 Aug 2008 02:37:57 -0700

Balazs Lengyel wrote:
> Hello,
> I think whether a leaf set by default exists or not should be a topic on 
> the interim. We have been debating this for a long time and I would like 
> to have it very clearly described after the interim.
> 

The first step is agreement that this is a protocol
issue and has nothing to do with YANG.

If the manager sets a leaf to its default value,
is the agent required to save that leaf in NV-storage?

Upon the next reboot, is the agent required to use
the manager-stored value, no matter what?  Even if
the SW image changes and the default value changes?

The argument against returning defaults seems to be
that it will waste bandwidth to retrieve them.
There is probably 1000s of pages of external CLI
documentation that the operator could track down and read,
rather than waste 50 milliseconds retrieving the data directly.

Remember that the defaults on the agent may have nothing
to do with YANG, or may not have any default defined, or may
have different platform-specific defaults.

Andy

> A) Configuration is what drives a device, so it is not important how it 
> got there: default or an explicit set. This means a leaf set by default 
> DOES exist.
> B) Configuration is what you set manually to make the device work, so 
> even if a default does modify how the device works, a leaf set by 
> default DOES NOT exist.
> My preference is A, but not everyone agrees. We should also consider 
> that the existence of a leaf effects at least the following:

---

From: Andy Bierman <[email-masked]>
Date: Fri, 08 Aug 2008 02:48:54 -0700

Balazs Lengyel wrote:
> I hereby ask the NETCONF/NETMOD community and specially the chairs of 
> NETCONF if they would accept as a new NETCONF work item a small draft 
> adding a with-defaults option to Netconf as a capability. As my Partial 
> locking draft seems to wind down (Is this wishful thinking :-) I might 
> even volunteer to write a draft on with-defaults.
> 

You mean something like this:

http://tools.ietf.org/html/draft-bierman-ncx-ext-00

I would be interested in pulling out just the with-defaults
and republishing this draft.  IMO, a capability is overkill,
but if an agent wants to suppress defaults unless explicitly
requested to send them, that should be OK, as long
as there is a status flag the manager can retrieve that
indicates this is how the agent works.

Andy

---

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

Andy Bierman wrote:
>> adding a with-defaults option to Netconf as a capability. As my 
>> Partial locking draft seems to wind down (Is this wishful thinking :-) 
>> I might even volunteer to write a draft on with-defaults.
>>
> 
I think that would be splendid. The flag you mention could go into the Netconf Monitoring model 
Scott is working on (timing, extensibility of that model). On the other hand some might argue, 
that if we already have one method to indicate optional behavior (capabilities) why invent a 
second one (flags).

If you do this yourself good. if you think I should help or do it myself say so.
Balazs
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Phil Shafer <[email-masked]>
Date: Fri, 08 Aug 2008 14:15:28 -0400

>http://tools.ietf.org/html/draft-bierman-ncx-ext-00

Two comments:
(a) with-defaults shouldn't be an attribute on <rpc>.  It should be
an element on the appropriate RPCs (get-config).
(b) Having a mechanism to learn default values is fine, but since
defaults will increase the size of configurations by several orders
of magnitude, making this the base behavior is a Very Bad Idea.  It
should be an option.

Thanks,
 Phil

---

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

>of the configuration database.

This seems to be your opinion, but not one shared by many on
the device side of the world.  The device view is either:

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

or:

   (b) Configuration data is the set of writable data that the users
   have specified to transform a system from its initial default
   state into its current state.

Most devices take one or the other view.  Few take the "all defaults,
all the time" view, since it leads to big configs filled with uninterested
data.  By limiting the config to what's required or what the user said,
the config is kept to a reasonable size and the content is (by definition)
the bits that the user cares about.

Operators care about config content and about config sizes.  They
look at config, they archive config, they diff config, they love
config.  It's the instructions they give the the device to tell it
what to do.

This is a reach, let's try a non-router example.  Consider the
contents of /etc/rc.conf on a unix box.  This file contains a set
of shell variables used by shell scripts like /etc/rc to trigger
boot-time box behavior.  For example:

    defaultrouter="10.0.0.1
    hostname="idle.juniper.net"
    ifconfig_fxp0="inet 10.0.0.2  netmask 255.255.255.0"
    kern_securelevel_enable="NO"
    linux_enable="YES"
    lpd_enable="YES"
    sendmail_enable="YES"
    sshd_enable="YES"
    usbd_enable="YES"
    firewall_type="open"
    nfs_server_enable="YES"

Software packages may define one or more shell variables to control
their base action.  Most define a "XXX_enable" variable to trigger
their initial start, but the variables and their meaning differ.

So in this world, the contents of /etc/rc.conf are my config database,
and no defaults appear.  If you add "ntp_enable=NO" (the default),
it doesn't change anything.  If sysinstall reads your setting and
rewrites them, it might not re-record this interesting setting.
The operation of your box is unaffected.  But it won't ever write
the hundreds of variables that you don't care about and never set,
even though they will also not affect the operation of your box.

The places you'll see this "flushed-with-defaults" behavior is where
the user is not expected to look at the config or to interact with
it.  I don't see our problem domain as suitable for this style.

>if they claim conformance to RFC 4741.

I disagree with this line of thought.  My implementation returns
the entire configuration database, unfiltered.  Default values are
not part of my configuration database.

Your plank is "default values must appear in the configuration
database".  I strongly disagree.  This isn't the way my part of the
world works and is not present on my reading of NETCONF.  NETCONF
leaves content up to the data model.  YANG-based data model certainly
don't have this "flushed-with-defaults" point of view.  I think you'll
have an uphill battle pushing for this.  An optional <with-default/>
element would be fine, but I don't see changing YANG to add this plank.

Thanks,
 Phil

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 8 Aug 2008 13:07:40 -0700

Hi -

> From: "Phil Shafer" <[email-masked]>
> To: "Andy Bierman" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Friday, August 08, 2008 12:32 PM
> Subject: Re: [netmod] leaf encoding rules
...
>    state into its current state.

I think there are two problems with both of these formulations - the
formulation in terms of "initial default state" and the formulation
in terms of "current state."  A third formulation
might be closer to a more classical view of what constitutes
configuration management:

(c) Configuration data is the set of writable data required to
transform a system from any possible state into a (fully-specified)
desired state.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 08 Aug 2008 13:24:44 -0700

> the device side of the world.  The device view is either:

The *nix .conf file and CLI models you cite are extremely
flawed for standards-based configuration.  Problems with
tracking down documentation, discovering default behavior
changes through new bugs, and little or no consistency
are well understood.  For YANG leafs without any default
defined, there is also no other way to find out what the agent is
expected to do.

In order for standards-based configuration to actually work,
all nodes that are affecting system behavior need to be
accessible to the operator.

These defaults are not always needed, but sometimes they are.
For example, when bench-testing a new SW version or new platform,
it is useful to know ahead of time if the the agent has
changed any of the defaults.  Usually the default change
is OK, but some operators want to know, not just hope.

In many of the unix .conf files I use, they are stuffed
with comments, showing all the knobs set to their default
values.  This is an obvious attempt to deal with the problem
of changing defaults and operators' need to know what
all the knob settings really are.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 08 Aug 2008 15:06:46 -0700

> an element on the appropriate RPCs (get-config).

IMO, it is easier and more consistent to use the XML attribute
mechanism already defined for the <rpc> element. The same mechanism works
for all standard and vendor RPC methods.

> of magnitude, making this the base behavior is a Very Bad Idea.  It

agreed.

A read-only leaf in the netconf-state spec is fine.

But if you support the (separate) 'with-defaults' capability,
then you must return these default leafs when 'with-defaults'
is set to true.

It is OK to make this a marketing decision, similar to
retrieving all the YANG, XSD, or RNG files directly
from the agent.  IMO, NE devices will continue to get smarter,
and 1 way to do that is to help the operator quickly get
out of a jam with instant, context-sensitive documentation.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Sat, 09 Aug 2008 17:11:44 -0400

>for all standard and vendor RPC methods.

"works" != "makes sense".  with-defaults makes no sense for many
RPCs.  It should only be defined for those RPCs where it makes sense.
Imagine if we allow this as a general concept and everyone starts
stuffing all their cruft in <rpc> because is "easier".

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Sat, 09 Aug 2008 17:31:21 -0400

Andy Bierman writes:
>flawed for standards-based configuration.

"flawed"?  Maybe, but definitely real world.  If you are trying to
model lab experiments and trivial "hello world" models, you won't
hit 80% of the interesting issues that happen out in the real world.
We've seen this in the sort of issues we're hitting with the WGs
using YANG already.  We can make claims about "flawed" but the folks
doing the modeling and the device folks doing the coding need real
solutions to their problems.

My belief is that the closer we follow the CLI model the more likely
is that YANG and NETCONF will find a place as an integral part of
device implementations, rather than becoming "yet another management
API" that gets glommed on after the real world is done (in the CLI).

>These defaults are not always needed, but sometimes they are.

I'm fine with an optional knob to get this information.  But I
completely disagree with your assertion that default values are
part of the config database and any data model that doesn't work
that way isn't compliant with NETCONF.   NETCONF leaves the entire
content of the <config> to the data model, with few rules about
what that content looks like, means, or how it behaves.  YANG defines
the rules (keys, ops, encoding, etc) that apply to YANG-based data
models.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Sat, 09 Aug 2008 15:03:24 -0700

> solutions to their problems.

I am using examples like the ipfix-psamp DM.

It is a tough sell to convince an SDO that access
to device data in a standard way is a bad idea.
Your device knows there is a leaf there,
and knows what the effective value is,
but chooses not to let the manager know that info as well.

Memory and bandwidth are dirt cheap.
Skilled labor and network downtime are not.

> the rules (keys, ops, encoding, etc) that apply to YANG-based data

I suspect your implementation keeps track internally of every
leaf, and if it has a default value.  Otherwise, how would
you be prepared to allow edit-config on that leaf?

It is a implementation detail to use this internal data
to generate the default in effect for RPC requests.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Sat, 09 Aug 2008 17:59:53 -0400

>transform a system from any possible state into a (fully-specified)

This (c) is the world of "CLI screen scraping".  NETCONF brings us
above this level by defining configuration as a cohesive whole.

The configuration tells you what you want, not what you might need
to throw away.  The current config can be discarded as a new
configuration is loaded.  The role of "from any possible state" is
unrelated to the validity of the target configuration.  The
configuration database tells you want; the server figures out how
to get there.

While <edit-config> allows you to change an existing configuration,
the end result is a new configuration dataset.  That config can
be fetched, archived, and restored later without regard to the
future state of the device.

When you load a new config, it need not have instructions to handle
any possible current state.  The old config can be completely
overwritten with the new config ("replace" for edit-config, or just
do a copy-config).

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Sat, 09 Aug 2008 18:22:02 -0400

>Skilled labor and network downtime are not.

My static routes have 70-80 configurable knobs, many with sane
defaults.  Skilled labor looks at those routes when they run "show
configuration".  Showing them the uninteresting values costs time
and money.  The signal (important values they set) would be lost
in the noise.  Increasing the volume of configuration an operator
has to look at will have a negative impact on uptime.

[ FWIW, my first implementation actually worked this way, keeping
nodes in the config database for defaults, but the first test our
systest ran was 50,000 static routes.  The memory footprint sent
me back to the drawing board to make a sparse database.  Memory
isn't always cheap. ]

Try this as an experiment in your software.  Make a list with a
hundred leafs, build 50,000 of them, and see if you like it.

>you be prepared to allow edit-config on that leaf?

Can't parse the question, but it works like this: we have rich
meta-data which defines the hiearchy of objects and the type and
defaults for leafs.  As the user creates config, we build data
structures in the configuration database that mirror this hierarchy
for each node they create.  If a system subcomponent requires a
leaf and it does not appear in the tree, the API looks at the meta
data and returns the default there as the value.  The user need not
enter or see this default.  If they want to know it, there's a
option that displays all meta-data (defaults, patterns, types, etc).

>to generate the default in effect for RPC requests.

It's a design principal to not mix meta-data (like types and defaults)
into the configuration.  Yes, we can, but it's Bad News.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Sat, 09 Aug 2008 17:12:20 -0700

> into the configuration.  Yes, we can, but it's Bad News.

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

Does the interface have a maximum transmission unit at all
times, or will the NE device allow infinite sized packets?
If it does have an MTU, whether the value is 1500 or not,
the manager should get to read it.

We disagree on the value of accessing the actual default values
in effect, right now, on a particular device.  Nobody ever said
the manager wants to see these defaults all the time.  Several
people have agreed with me that sometimes these values are needed.

This is is the same category as the <get-schema> RPC or module version
advertisement.  The manager can just use off-line vendor provided
documentation somehow, so why bother with these on-line mechanisms?
Vendors that think instant online documentation (including defaults)
is useful will provide that feature, and others will not.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Sat, 09 Aug 2008 23:17:46 -0400

>the manager should get to read it.

These are all valid questions but are really about the meta-data,
which we should find a way to address.  See Martin's email earlier
(on this thread?) about "device deviations".

The idea is creating it and _then_ discovering what value was used
is strange.  If my app really cares about the mtu, it cares before
it creates an interface, not after the fact.

>the manager wants to see these defaults all the time.

Apologies, I misunderstood you when you said:

I read this as saying that default values appear as part of the
config, but I'm glad to have misread it.

>is useful will provide that feature, and others will not.

I think that online meta-data (machine readable info, not human-
oriented documentation) provides a better solution.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Sat, 09 Aug 2008 20:33:46 -0700

> (on this thread?) about "device deviations".

I don't see this as meta-data.

If the user sends a <get> request for the exact
node (subtree or Xpath), then you pretend the node is
not there if it has the default value?  And generate
and error instead?

Do you require that the user only include nodes in
must/when expressions that they have explicitly set?
So if the user sets the MTU value to 1500, the Xpath works,
but if the agent sets it to 1500, then the Xpath is an
error because 'if-mtu' does not exist?

IMO, your model is fragile, and not suitable for standards.
It doesn't matter if CLI and foo.conf do it some other way.
They aren't standards and never will be.

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 9 Aug 2008 21:41:47 -0700

Hi -

> From: "Andy Bierman" <[email-masked]>
> To: "Phil Shafer" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Saturday, August 09, 2008 8:33 PM
...
> not there if it has the default value?  And generate

I think where this thread is leading it depends on the kind of <get>
request.

> error because 'if-mtu' does not exist?

It *does* exist in some sense, but because it has not
explictly been configured, I think Phil would like to be
able to retrieve a representation of the configuration
that omits this information.  I don't think we're terribly
far apart on this.

> They aren't standards and never will be.

In fairness, it depends on the strength of the contract implied by a
claim of conformance to a particular model.  One of the things
that eventually became quite clear to the requirements design
team was that "defaults" were only useful if they really were an
"iron-clad" part of the contract specified by a model.  If a device
claims to support a model and does not do defaults exactly as
specified, then yes, it will be "fragile", but just how robust against
non-conformant implementations do things need to be?  (This
isn't merely a rhetorical question!)

Randy

---

From: Phil Shafer <[email-masked]>
Date: Sun, 10 Aug 2008 01:44:38 -0400

>I don't see this as meta-data.

This is meta-data, since it's information about the data (what value
will be used as a default?) rather than data itself.

Pick another statement where a device might differ from a standard.
"max-elements"?  If the model defines a list of "users", does an
application need to know that a particular device supports only 16
users?  Should the app have to create 17 users to watch the failure
to "know" that 16 is the real max-elements?

The idea is that there are three types of information:
(a) the basic model elements
(b) deviations (from the basic model) that the modeler wants to
    model.   These are constructs that are important to the model
    but are optional.
(c) deviations from the model that the modeler didn't model which
    the device wants to make apps aware of.

(a) is normal YANG. (b) is the new "feature" feature.  And (c) is
the "overlay" or "device deviation" mechanism we've been talking
about.

The device deviation is not likely to be part of YANG 1.0, so we
can table it for now, but I'm imagining something like:

    module my-bgp-deviations {
        import bgp;

        deviation /bgp/peers {
            max-elements 16;  // Fixed number of peers
        }

        deviation /bgp/as-number {
            range min..1024;   // trim range
        }

        deviation /bgp/priority {
            default 20;        // provide my default
        }
    }

This puts these deviations in a machine readable form that apps can
use to learn device specific _before_ they create/change configuration.

>not there if it has the default value?  And generate

Did you intentionally move from config data to <get> here?

For configuration, if the node isn't there, it's _not_ there.  I
don't pretend that it is.

Default values for non-config data returned by <get> are an interesting
question.  If I follow your view, the device has to provide the
leaf with the default value, but if I have to provide the value,
what's the use of the default?

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Sun, 10 Aug 2008 01:17:19 -0700

> what's the use of the default?

IMO, your view of 'config data' means an optional leaf can
never be used in a must or when XPath expression.

If you allow something like 'if-mtu != 1500' in your XPath,
only when the manager has set it 1500 (but not the agent),
then that seems fairly broken and unreliable to me.

If you always allow the XPath access for must/when, but
ignore the node's existence for protocol operations,
that also seems broken to me.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sun, 10 Aug 2008 01:17:58 -0700

> I think where this thread is leading it depends on the kind of <get>

how about the ones in RFC 4741.
What are your specific comments on yang-00 and RFC 4741?

Andy

---

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

>..

What about agent-selected, platform-specific defaults?
Sure, you could retrieve the YANG files for all the optional
leafs that have defaults defined.  What about all
the leafs that have no default defined? You could hope for
the first time in history a vendor actually ships
bug-free, 100% fully documented code.  This seems
less robust than just asking the agent directly
for these leaf values.

Perhaps YANG's mandatory true/false is too simplistic?
Sometimes an optional leaf will not be used by an agent
at all.  Sometimes it will be used with the defined default.
Sometimes it will be used with an undocumented default.
Sounds like 4 classifications, not 2.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 10 Aug 2008 21:27:01 +0200 (CEST)

> must/when expressions that they have explicitly set?

Different 'user' here.  The first is the NETCONF user, and IMO the
answer again depends on the with-defaults parameter.

In the second case the 'user' is the DM writer, and section 7.5.2
specifies that default values are visible in must expressions.  The
same text should be in 7.15.2 (for when) as well.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 10 Aug 2008 21:44:36 +0200 (CEST)

> What about agent-selected, platform-specific defaults?

Currently in YANG, there is no formal way to learn these or even know
that a leaf is intended to get an agent-selected default.  We have
discussed several ways to address this, but I think the main question
the WG has to answer is what level of support YANG should provide for
this problem, if any.

One way for a client to *know* that a leaf has an egent-selected value
is to add the "created-by" statement.

In order to learn such a value, I think the best solution is to keep
these values in category 2 "vendor-specific deviations not specified
in the model", and as Phil said thus probably out of scope for YANG
1.0.

/martin

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 21 Aug 2008 14:42:31 +0200

I don't agree. We have the case where the there is a default, but it is not just a simple value 
e.g. the number of users I can serve depends on the amount of memory, the number of interfaces etc.

So we should have a marking stating: leaf foo does have a default, but it is not specified in 
the YAM.
Balazs

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 21 Aug 2008 14:56:09 +0200 (CEST)

Hi,

Balazs Lengyel <[email-masked]> wrote:
> I don't agree. We have the case where the there is a default, but it
> is not just a simple value e.g. the number of users I can serve
> depends on the amount of memory, the number of interfaces etc. 
> 
> So we should have a marking stating: leaf foo does have a default,
> but it is not specified in the YAM. 

I'm confused.   What part did you disagree with?  The suggestion below
is to add a statement "created-by system".  Isn't that what you ask
for above?

/martin

> -- Balazs Lengyel                       Ericsson Hungary Ltd.
> TSP System Manager

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 21 Aug 2008 14:58:49 +0200

Hello Martin,
I got the mistaken feeling from your mail, that created-by system was covered by

"thus probably out of scope for YANG 1.0."

So as you propose to handle the case with "created-by system" in YANG 1.0, I am perfectly happy.
Balazs

---

From: Phil Shafer <[email-masked]>
Date: Thu, 21 Aug 2008 10:19:40 -0400

>So as you propose to handle the case with "created-by system" in YANG 1.0, I a

"created-by system" and "I have a complex default that isn't static"
are two distinct issues.

"created-by system" means that if you don't specify a value, the
system will happily assign you one that is better than one you
could pick out of thin air.  For example, if you are making users,
the "uid" will be assigned based on the next available (unused) uid.

This is different than complex defaults, where the value isn't created
by the system explicitly, but an implicit value is used based on some
conditions that aren't easily specified on a "default" statement.

For example, the user's disk quota could be the amount of available
space divided by the number of configured users.  A 4G flash with
40 users will give each user 100M.  Delete 20 users and you double
the quota for the remaining users.  If you assign "quota 100m" in
the config, the quota is fixed and no longer floats in accordance
with the formula.

My question is:  what does the application or the device do with
the knowledge that the default value is complex?  Do they not let
the user set it?  Do they warn the user "complex stuff here"?  What's
the value is saying "there's a default but I can't tell you it"?

Thanks,
 Phil