Subject: [YANG] new pyang errors

From: Andy Bierman <[email-masked]>
Date: Fri, 18 Jan 2008 09:08:46 -0800

Hi,

I notice the new version of pyang says it is
an error to have a mandatory leaf with a default.

I don't agree with this interpretation.
There is no other way to support an agent-supplied default.

  leaf foo {
    mandatory true;
    default 7;
    type int32;
  }

  leaf bar {
    mandatory false;
    default 7;
    type int32;
  }

The leaf 'foo' is created by the agent with the value 7
if the manager tries to set the <running/> config
without it.  Mandatory means it must be present in a
valid config, not that the manager must set some value.

The leaf 'bar' has an irrelevant default clause that
will never be used because the leaf is optional and
the agent will not create it.

I think the CLR is backwards, but none is really needed here at all.

Andy

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

---

From: Phil Shafer <[email-masked]>
Date: Fri, 18 Jan 2008 16:08:22 -0500

Andy Bierman writes:
>Mandatory means it must be present in a

That's certainly not the way I read mandatory.  Mandatory
means that it must be set, meaning that some{one,thing}
must set it.  If there were a reasonable default, you
shouldn't need to make it mandatory.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 18 Jan 2008 22:35:11 +0100 (CET)

> shouldn't need to make it mandatory.

This is one of the areas where we've had some discussions.  If you
classify leafs as 'mandatory' and 'optional', where does a leaf w/ a
default fit in?  IMO it doesn't really matter, it just have to be
clear.  In YANG we chose to define 'mandatory' as mandatory to set,
and a leaf with a default is optional to set.  Thus you cannot have
mandatory and default on one leaf.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 18 Jan 2008 17:04:29 -0800

> shouldn't need to make it mandatory.

I can only find 2 brief paragraphs of text on the mandatory-stmt:

7.6.4.  The leaf's mandatory Statement

    The "mandatory" statement, which is optional, takes as an argument
    the string "true" or "false".  If "mandatory" is "true", the node
    must exist in a valid configuration if its parent node exists.

    If not specified, the default is "false".

7.9.4.  The choice's mandatory Statement

    The "mandatory" statement, which is optional, takes as an argument
    the string "true" or "false".  If "mandatory" is "true", nodes from
    exactly one of the choice's case branches MUST exist in a valid
    configuration.

    If not specified, the default is "false".

The current draft clearly says that 'mandatory true' refers to the
configuration database, not to whether the manager must provide
an explicit value.

I agree with the interpretation in the current draft.

YANG needs to be more consistent wrt/ mixing DM concepts too much.
The data model object definitions (leaf, container, etc.) refer
to the desired/expected state of the configuration database,
not with individual PDUs.

The reason that the data model MUST refer to the configuration
is that schema validation of NETCONF PDUs is mostly meaningless.
Since the PDUs are so flexible, every single element and attribute
would need to be marked optional (minOccurs=0).

Andy

---

From: Phil Shafer <[email-masked]>
Date: Sat, 19 Jan 2008 12:38:30 -0500

>I agree with the interpretation in the current draft.

Well, you agree with your interpretation of the draft ;^)

The issue isn't whether a leaf with a default has to appear
in any particular PDU, but whether a leaf with a default
"exists" until some{one,thing} creates it.  If leafs (and
non-presence containers) are automagically created "in the
configuration database", then configurations become big
and verbose, which is the opposite of what I want.  So
I don't want leafs with defaults to be considered "created".

And when I read the draft with that prespective, it agrees
with me.  So the draft is underspecified.  What outcome do
we want and what do need to add to the draft to ensure there
is only one possible reading of our spec?

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Sat, 19 Jan 2008 10:39:54 -0800

> is only one possible reading of our spec?

It is really up to the DM writer whether they want agent-created
default leafs or not.  I do not care about containers as much,
although the principle is the same.

There is no auto-magic.
The logic is very simple when a leaf value is not provided by the manager:

Q1: Is the leaf mandatory?

   No:  processing is done, node is not instantiated in the agent

  Yes:  Q2: Is there a default-stmt for the leaf, or if not, is there
            a default-stmt for the typedef used by the leaf?

          No: missing mandatory data error

         Yes: use the default value to instantiate the leaf node

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 19 Jan 2008 11:13:50 -0800

>...

Perhaps you want to revive the debate on the NGO list
about the 'with-defaults' extension?

The consensus was that both views of the configuration database
are useful, and the protocol should support both of them.

Without the 'full' view, how is a manager supposed to know
whether a leaf is really there with the default value, or
not supported by the agent or supported but not used in this instance.

How is a manager supposed to get a complete config diff from
the agent, without analyzing all the schema files between N different
software releases?  A diff (with-defaults='true') will expose silent
default value changes for agent-supplied optional knobs, or agents
that are ignoring the schema and using a different default value.

The solution to this supposed YANG problem is to add the with-defaults='false'
extension to the NETCONF operations to filter out these nodes in
get and copy operations.  Currently, 'state' nodes are auto-filtered
by get-config, but not "default true/false".  It should not be
a big deal to add this as a mandatory filter somehow.

Andy

---

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

> are useful, and the protocol should support both of them.

The intention with the YANG solution is to support both these views,
and also support systems that implements the with-default capability.

> not supported by the agent or supported but not used in this instance.

Now you're touching on the conformance / capabilities problem...
Currently in YANG this is pretty coarse-grained, on the module level.

/martin

---

From: Phil Shafer <[email-masked]>
Date: Sun, 20 Jan 2008 12:38:33 -0500

>         Yes: use the default value to instantiate the leaf node

If there's a reasonable default for the node, why would you mark it
as mandatory?  If there's a default, no one needs to create the
statement and is doesn't need to exist in the database.

What you are doing here is trying to make the meaning of mandatory
conditional based on the presence of a default.  This is confusing.

If something is mandatory, it must exist.  If there's a default,
it need not exist, since the default gives the value.  Making
the agent/manager/user/implementor ask your Q1 and Q2 is unnecessary.
The question is simply "does it exist?".  If it's mandatory and it
doesn't exist, it's an error.

Thanks,
 Phil

---

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

> doesn't exist, it's an error.

We disagree on which POV is confusing.
IMO, it is important to be able to easily distinguish between
some knob that the agent is not using at all (whatever that
means is DM-specific) vs. a knob that is being used, but which
has the DM-defined default value.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 21 Jan 2008 10:38:04 +0100

> has the DM-defined default value.

More to this point: an agent saying "I have parameter X set to the
default value but I won't tell you what it is." doesn't seem acceptable
to me. Even if standard defaults were defined, I am sure there will be
broken (optimised:-) implementations with other default values. It would
be extremely hard to debug network problems if the manager cannot verify
the actual values used by all agents.

I'd thus allow both agents and managers to have their own defaults but
always be explicit when exchanging the data. Relying on common universal
defaults would make the system fragile.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Phil Shafer <[email-masked]>
Date: Wed, 23 Jan 2008 00:32:07 -0500

Ladislav Lhotka writes:
>Relying on common universal

As will shipping voluminous defaults.

Visibility into defaults is a distinct issue from carrying the
defaults in the configuration database.  If I have an object with
50 fields where only 2 or 3 are set on each instance, carting around
fully-fleshed configs will be incredibly annoying.

My view of configuration is that if you set it, it should be there.
If you didn't set it, it shouldn't be there.  If you want extra
information, ask for it.  But the normal view of configuration
should be restricted to only what the user or application expressed
configured.

This leads directly to my interpretation of "mandatory".  A mandatory
config statement is one that some user or application must expressly
configure.  If the configuration is valid without the statement,
then it's not mandatory.

The "mandatory"-ness describes the interaction between the device and
applications configuring it.  If the application must create the statement,
then the statement is mandatory.  The "mandatory plus default" interpretation
Andy's using is more of a description of the interaction between the on-box
management software and the other on-box software components.  IMHO this is
less interesting and more internals that YANG should be describing.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Wed, 23 Jan 2008 00:38:29 -0500

>has the DM-defined default value.

Why is this the important distinction?  "used" by who?

IMHO the important distinction is the one between the application
and the device that tell the application what statements the device
requires and what it takes to create a valid config.  If the config
statement is mandatory, the application must provide it for the
config to be valid.  The application knows that it must get that
value, assumably beating it out of the user, and create the mandatory
config before committing the configuration.

Thanks,
 Phil

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 22 Jan 2008 21:42:32 -0800

Hi -

> From: "Phil Shafer" <[email-masked]>
> To: "Ladislav Lhotka" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, January 22, 2008 9:32 PM
> Subject: Re: [YANG] new pyang errors 
...
> should be restricted to only what the user or application expressed

Strongly disagree.  Operationally, one needs to be able to
determine what the configuration actually *is*, regardless of
whether it was ever expressed by a user or application.

...

This is sufficient to configure a device, but it's not
configuration management.

Randy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 23 Jan 2008 00:59:50 -0500

>whether it was ever expressed by a user or application.

One can use alternative views ("with-defaults") or external information
(YANG modules) to acquire this information.  The main target of
configuration remains (and will remain for some time) the human
users.  Verbose configurations breed confusion and most of my efforts
in my day job are targeted to simplifying configurations and reducing
the volume of data human users need to look at.

>configuration management.

I don't follow you here.  Please explain how the alternative
interpretation of "mandatory" aids in configuration management.
Is the "with-defaults" view key to a good solution?

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Jan 2008 22:22:10 -0800

> As will shipping voluminous defaults.

huh -- it uses up an extra second of bandwidth so the system is fragile?

> should be restricted to only what the user or application expressed

There are lots of scenarios that cause an operator or application
to need to full configuration, not just the values that do not have
the default value.  Many people (including me) do not view this
scenario as the same as the node is not present:

   1) relying on external documentation is too costly on the operator
      and fragile.  Only direct response from the agent is sufficient.
      Looking up answer X to question Y at server Z to find out
      what agent A will answer when asked question Y is full of problems.

   2) augment 'when' clauses could make it confusing as too whether
      a missing node is because it isn't there or because it has a
      default value

   3) more complex agent conformance and variance mechanisms than
      the current ones (i.e., none) could make it unclear whether
      an object is missing due to non-applicability or due to
      non-conformance.

   4) A buggy agent may report all kinds of capabilities and conformance
      and still set a default to a different value than the document.

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 22 Jan 2008 22:32:13 -0800

Hi -

> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, January 22, 2008 9:59 PM
...
> Is the "with-defaults" view key to a good solution?

For real configuration management, I count among the essentials:
   - the ability to bring a device to a known configuration state
   - the ability to determine exactly what a device's configuration
     state is
   - the ability to store and version this configuration information
   - the ability to create (provision) this information in advance
     of deployment
   - the ability to determine whether a device's actual configuration
     is the same as its desired configuration

The "with-defaults" view sounds like it would help, particulary
if a default-ed value isn't known a priori.

Randy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 23 Jan 2008 08:24:57 +0100

> fully-fleshed configs will be incredibly annoying.

It would be sufficient if managers get the full configuration at the
start of each session so that they can be sure what the actual data are.
Then edit-configs etc. can include just the necessary parts. And by full
configuration I mean exactly this, with no hidden assumptions.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 Jan 2008 08:33:37 +0100

> whether it was ever expressed by a user or application.

I actually don't see the conflict in your statements. Phils agrees to
give you the value of all configuration knobs if you ask for it.

And yes, from experience with several boxes, I can confirm that
getting just the configuration values that were really touched is
indeed a nice feature once you are familiar with a device. And many
network devices support this in their native CLI - so we might be well
adviced to support this compact view as well.

/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: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 Jan 2008 08:36:52 +0100

> configuration I mean exactly this, with no hidden assumptions.

I disagree. I like to get the full configuration whenever I want it -
it should not matter whether this is at the start, the middle, or the
end of the session.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 23 Jan 2008 08:40:51 +0100

> the volume of data human users need to look at.
I agree, but im my view of the NETCONF world this (optional) filtering
can and should be done at the user's side, by the management
application. The size/complexity of the data is not an issue for
machine-machine exchange.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 Jan 2008 08:44:27 +0100

> machine-machine exchange.

a) ssh is not going to do that for me anytime soon
b) only the device really knows what has been touched
c) configuration will always be to some extend proprietary; so your
   app needs to understand all the proprietary stuff of all your devices
d) SNMP failed badly in this space, partly because of b) and c)

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 23 Jan 2008 08:48:41 +0100

> it should not matter whether this is at the start, the middle, or the

Of course you could get it whenever you want. My point is that it is
sufficient to get it from the device once so that no "carting around"
takes place.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 23 Jan 2008 09:25:56 +0100

> a) ssh is not going to do that for me anytime soon

It's important that raw ssh works in principle but let's face it -
reading and typing NETCONF XML stuff via stdin/stdout is only for
masochists.
 
> b) only the device really knows what has been touched

I'd like to make sure that my configurations work - as much as possible
- even after the device has been replaced by another brand.

>    app needs to understand all the proprietary stuff of all your devices

I don't agree - the whole NETCONF then wouldn't make much sense. That
"some extent" must be rather minor IMO.

> d) SNMP failed badly in this space, partly because of b) and c)

Avoiding hidden assumptions cannot make the situation worse, only
better.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 23 Jan 2008 09:38:21 +0100

> reading and typing NETCONF XML stuff via stdin/stdout is only for
Our testers very often write the NETCONF requests/replies in a file, and send that over SSH.
So while Netconf is not a CLI, we do use raw SSH. I also think operators stated they like to 
understand raw output.
Balazs

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 Jan 2008 09:41:23 +0100

> reading and typing NETCONF XML stuff via stdin/stdout is only for

Perhaps real operators are masochists. Seriously, the amount of
existing scripting code using CLI interfaces is huge. This is not
going to go away. 

> - even after the device has been replaced by another brand.

There is no contradiction between these two statements so I guess you
agree with my statement. ;-)

> "some extent" must be rather minor IMO.

It is an illusion to believe that all router vendors will ship exactly
the same feature set. Whether the proprietary configuration knobs will
be 1% or 100% we don't know - but it will exist.

> Avoiding hidden assumptions cannot make the situation worse, only

I am not sure which hidden assumptions you have in mind.

/js

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 23 Jan 2008 10:00:50 +0100

> if a default-ed value isn't known a priori.

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:
1) Does it exist?

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

3) 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?

4) 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.

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

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

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

Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 23 Jan 2008 10:09:50 +0100

Actually I am much more afraid that we will get complex, non-intuitive answers to these 
questions then what the answers really are.

I (Ericsson) personally live in a simple world. If you put something there it exists, if no it 
does not. So a default value exists as part of the config, it has effects. For us if a leaf 
does not exist in the config it has no effect whatsoever. We only use the default at creation 
time.

I hope whatever solution we settle on will not be much more complicated then that for any of 
the below 7 questions. As I see it with-defaults solves 1 problem from the below 7 that is 14%.

Balazs

Balazs Lengyel wrote:
> 
> Randy Presuhn wrote:
>> The "with-defaults" view sounds like it would help, particularly
> 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).
> 
> 2) How does edit-config create/delete work on it? E.g. can you create a 
> leaf that already exists(?) due to a default value?
> 
> 3) 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?
> 
> 4) 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.
> 
> 6) Will a non-presence container exist if it has leafs set by default? 
> This will effect how edit-config none is handled.
> 

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 23 Jan 2008 10:19:44 +0100

> existing scripting code using CLI interfaces is huge. This is not

Yes, but scripts connected via stdin to ssh are something different. You
can then set up a pipeline with a filter that suppresses (or fills in in
the opposite direction) the default values - but these could be your
default values that needn't necessarily be the same defaults the device
uses.
 
> agree with my statement. ;-)

Well, if you only have a diff against factory default configuration of
device A and device B has a different one ...

> be 1% or 100% we don't know - but it will exist.

If two devices advertise the same DM then I can assume they both have
the knobs that are present in the DM - perhaps others as well. The
simpler the DM is, the more likely it is that different vendors accept
it. That's why I'd like to remove all constraints that can be handled in
a different way, even if it means more data on the wire.

> I am not sure which hidden assumptions you have in mind.

That configuration parameters in the device have certain values even
though you haven't seen them.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 Jan 2008 10:28:32 +0100

On Wed, Jan 23, 2008 at 10:19:44AM +0100, Ladislav Lhotka wrote:

[...]

Lets just agree to disagree. I count myself in the camp of those
operators who believe that 100% portable device configurations are an
ideal that will never ever happen.

For me, the mission is to find agreement on a standard protocol to
exchange configuration data, a standard data modeling language for
standard and proprietary configuration data models and with some luck
a few widely adopted standard configuration data models.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 23 Jan 2008 10:32:28 +0100

> So while Netconf is not a CLI, we do use raw SSH. I also think operators stated they like to 

Of course, developers and testers must sometimes do such awkward things
with other network protocols, too. But for production use, the minimum
requirement for me is that end users (humans) use a decent readable
syntax, which XML generated by a machine isn't. So some processing on
the client side will IMO always be necessary.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 23 Jan 2008 10:39:30 +0100

> ideal that will never ever happen.

Absolutely, but we have to do what we can to allow the portable part to
be big as possible, even if it makes life harder to developers, testers
and masochists. 

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 Jan 2008 11:06:40 +0100

On Wed, Jan 23, 2008 at 10:39:30AM +0100, Ladislav Lhotka wrote:
> 
> Juergen Schoenwaelder p????e v St 23. 01. 2008 v 10:28 +0100:
> 

But we seem to have fundamental differences about the split of work:

- I want the NETCONF server to be authoritative to tell the client what
  the configuration is, with and without defaults expanded.

- You seem to assume some magic processing exists on the manager side
  which takes what the device reports and modifies it e.g. by patching
  in defaults yielding a complete config.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 23 Jan 2008 13:02:43 +0100

>   the configuration is, with and without defaults expanded.

A simpler protocol is better. If you allow this choice, you also have
to:
1. extend the NETCONF protocol so that it is able to distinguish 
   between the two cases,
2. carefully specify the semantics of concepts like default values, 
   mandatory versus optional etc.

>   in defaults yielding a complete config.

Why do you call it magic? It's perfectly deterministic and local
processing from client's point of view - the application has all
information and just does what the user wants. And the user can always
check what's going on without caring about what "magic" happened at the
remote end. It can efficiently work even with different devices - the
factory defaults are not relevant here.

It does imply slightly more complexity than raw ssh on the manager side,
but for the managed device it is actually simpler - it needn't care
about which values in its config datastore differ from factory defaults.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 Jan 2008 13:11:08 +0100

>    mandatory versus optional etc.

I think this is why we are discussing these questions here.

> factory defaults are not relevant here.

The point is that the application does not really kow whether it has
all the information and it is a pain for the user to check this.

> about which values in its config datastore differ from factory defaults.

Lets agree to disagree on this. We won't convince each other.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 23 Jan 2008 13:58:18 +0100

> configure.  If the configuration is valid without the statement,

My definition of mandatory: mandatory configuration parameters are those
that are essential for device or protocol operation. It doesn't matter
whether they are set by the user/application, supplied from non-volatile
memory or perhaps even hardwired. A (full) configuration is valid only
if it contains all values that are declared as mandatory in the DM. 

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Wed, 23 Jan 2008 06:47:54 -0800

>   in defaults yielding a complete config.

I agree with Juergen, but I don't see what standard vs. vendor knobs
has anything to do with the problem.

I thought there was resolution on this way back when the with-defaults
extension was discussed on the NETCONF/NGO lists.

Most of the time it is okay to get the most terse view of the
config possible (with-defaults=false), but once in awhile,
like when a new device or a new SW version is installed,
it is important to get the entire config, with defaults,
for verification purposes.

Both views need to be supported by a NETCONF agent.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 23 Jan 2008 15:35:35 -0500

>huh -- it uses up an extra second of bandwidth so the system is fragile?

No, the human element is fragile.  Having a config file littered
with values that the user didn't ask for and doesn't need it a
great way to help them ignore the parts of the config that they
did ask for and do need.

>the default value.

If you see a value in this, make it an option to <get-config>.
It should not be the default behaviour.

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 Jan 2008 21:43:16 +0100

> It should not be the default behaviour.

Yes, an option for <get-config> would be the clean solution. 

It would be nice if the IETF process would allow us to do good
engineering and not get us in the way. I think this is not the first
time we run into something that really should be "updated" in the
NETCONF protocol itself.

/js

---

From: Phil Shafer <[email-masked]>
Date: Wed, 23 Jan 2008 15:47:54 -0500

>time we run into something that really should be "updated" in the

So let's create an internet draft that defines a NETCONF capability
which adds an element to <get-config> called <with-defaults/> that
tells the NETCONF server to include default values in the <config>
reply, and to tag them with the "wd:default" attribute set to a
value of "true".  This should be a simple draft that we can get
thru the NETCONF WG in less than two years ;^)

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Wed, 23 Jan 2008 15:58:00 -0500

Ladislav Lhotka writes:
>memory or perhaps even hardwired.

Why would you need or want to mark is as mandatory if the value
is hardwired?  What are you trying to say by calling a parameter
"mandatory" and who are you trying to say it to?

If the application need do nothing with such hardwired parameters,
why does it need to distinquish them?

If the device need to nothing <ditto>?

YANG defines constraints on the XML that passes between the client and
server.  Nearly every statement in a YANG module defines a rule which
that XML must follow, both during protocol operations and the valid
configuration being built.

Mandatory is such a constraint, and should be an indication to the
NETCONF client application that it needs to do something explicit
to satisfy this constraint.  If the mandatory parameter isn't set,
the configuration isn't valid.

If we allow this mandatory constraint to be satisfied via mechanisms
that do not involve the client and server, why have it?  How is the
application to discern the difference between a real constraint and
a parameter that the fairy god mother daemon fills in?

>A (full) configuration is valid only

This is a definition that both sides of the debate can love, which
is a problem.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 23 Jan 2008 21:56:43 +0100 (CET)

> thru the NETCONF WG in less than two years ;^)

Andy has already defined such a capability in one of his drafts (I
forgot which one...).  FWIW it's already implemented by >=2
implementations.

/martin

---

From: Phil Shafer <[email-masked]>
Date: Wed, 23 Jan 2008 16:16:26 -0500

Martin Bjorklund writes:
>forgot which one...).

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

This defines a set of protocol extensions:

     2.1.  test-only Enumeration  . . . . . . . . . . . . . . . . . .  5
     2.2.  with-defaults Attribute  . . . . . . . . . . . . . . . . .  7
     2.3.  with-metadata Attribute  . . . . . . . . . . . . . . . . .  9
     2.4.  last-modified Attribute  . . . . . . . . . . . . . . . . . 11

IMHO these should be distinct capabilities, since this is the way
NETCONF allows for such extensions.

One odd line (on first read) is:

   The 'with-defaults' attribute is defined in the namespace specified
   as the 'targetNamespace' in Section 3.  However, an agent should
   accept it even if no namespace is used.

This seems to play fast and loose with XML namespaces, which isn't
a good idea.

Another issue is that the draft puts these as attributes on the
<rpc>, instead of putting them inside the proper operations:

   If the 'with-defaults' attribute is
   present in the <rpc> element, for any of the protocol operations
   which return the contents of a configuration database, the agent will
   use the 'with-defaults' value to control default suppression.

I'm also missing where the metadata returned with with-metadata is
defined.

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 24 Jan 2008 09:32:28 +0100

> "mandatory" and who are you trying to say it to?

Example: there are many devices out there that have fixed Ethernet MTU
value (1500). Such a device can certainly use a DM that specifies MTU as
mandatory. It will just fill in this slot with the hardwired value and
report a run-time error if a client tries to change it.  

> why does it need to distinquish them?

The application needs to know what the value is (as in the case of MTU).
I don't want to rely on out-of-band resources. We also have get-config,
not only edit-config.

> If the device need to nothing <ditto>?

<ditto>

> configuration being built.

I don't agree. YANG models mostly define constraints on the entire
content of the config datastore, less so on the XML PDUs.

> the configuration isn't valid.

I disagree again: this would mean you cannot change the factory default
configuration part by part. Should the factory default configuration be
marked invalid until the client application touches all mandatory
values?

> a parameter that the fairy god mother daemon fills in?

The mandatory/optional property should be specified by the data modeller
and not depend on the way how it is implemented in different devices.
Example: in an authentication database DM, the login, uid and password
are mandatory while full-name is optional. IMO this DM is perfectly
usable also by devices that either
(i) don't implement the full-name slot, or even
(ii) allow only one user - so, login=admin and uid=0 are effectively
hardwired.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 24 Jan 2008 09:48:50 +0100

For us the default would be: give me the full config with all defaults; and the option, 
without-defaults.
But I agree that both solutions have value.
Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 24 Jan 2008 10:08:09 +0100

Just to give you example of the need for fixed values:
Due to our need to map YANG data to LDAP, we need a key on all encapsulating objects. So we 
have to use lists instead of containers, even where we know there will only be one list entry. 
Often the key for such single entry lists is fixed, but still needed.
So this key is config , mandatory, and fixed.
Balazs

---

From: Phil Shafer <[email-masked]>
Date: Thu, 24 Jan 2008 10:15:01 -0500

>So this key is config , mandatory, and fixed.

Keys are always mandatory in YANG, and have no default.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Thu, 24 Jan 2008 10:49:52 -0500

>report a run-time error if a client tries to change it.  

We're crosstalking on the meaning of mandatory again.  My question
is what's the difference between:

    leaf mtu {
        type uint;
        default 1500;
        mandatory false;
    }

and:

    leaf mtu {
        type uint;
        default 1500;
        mandatory true;
    }

What am I adding by having mandatory set to true?  What
is the mandatory flag adding?  In my view of "mandatory", the
mandatory flag means the client must set this, but the server
has a default which should be used for this, so I'm not seeing
why the client should be forced to send the server information
the server already knows.
 
>I don't want to rely on out-of-band resources. We also have get-config,

The application _has_ to rely on meta data to find the value
for leafs in objects that don't exist.  Even with the :with-defaults
capability, you won't see defaults for stuff that doesn't exist.

A YANG module defines a data model.  The client and server agree to
abide by the constraints and meanings defined in that data model.
Applications can read this model and understand the data that is
being manipulated.  The YANG module is by definition out-of-band,
since it's metadata.

If you don't want out-of-band resources, what's your interest in
YANG?  How do you see this helping you?

>content of the config datastore, less so on the XML PDUs.

In defining what's valid in the datastore, we implicitly define
what's valid in the XML.  If the model says:

     leaf mtu {
         type uint {
             range 576..8192;
         }
     }

then you cannot send xml that looks like:

    <mtu/>
    <mtu>hot-dog</mtu>
    <mtu>10</mtu>
    <mtu>infinitiy minus 3 </mtu>
    <mtu><maybe>not</maybe></mtu>

>marked invalid until the client application touches all mandatory

I don't follow your argument here.  If the factory default config
for a box doesn't follow the rules defined in the data models
supported by that box, then there's a bug somewhere.  The data model
defines what's valid config, so if you don't follow the rules, you
don't have valid config.  If a parameter is tagged as mandatory
in the model, it must appear in the factory-shipped config.

>and not depend on the way how it is implemented in different devices.

Completely agree with you, but I don't see a conflict between your
point and mine.

>(i) don't implement the full-name slot, or even

Here I completely and strongly disagree.  A data model defines how
data works.  If you tell a client that your support this data model
and you don't implement "full-name", your telling a fib.  Customers
will catch you and bludgeon you about the head and shoulders.

A data model is a contract.  A client application should have faith
that you are abiding by that contract.  YANG doesn't have a compliance
mechanism to allow you to avoid parts of the contract, but does
have "augment" to allow you to extend the contract with additional
information if required.  But if your box doesn't have a place to
put "full-name", it shouldn't be advertising the capability for
that data model.

We're looking to build strong and binding underpinning for future
data models and the applications that rely on them.  If a box
doesn't abide by a data model that it advertises, it's a bug.

>(ii) allow only one user - so, login=admin and uid=0 are effectively

Then your factory default config should look like:

system {
    login {
        user admin {
            uid 0;
        }
    }
}

We should note that YANG does not cover factory-default configs.  But
factory-default configs should follow the rules in the YANG data model.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Thu, 24 Jan 2008 08:11:47 -0800

> the server already knows.

IMO this overlap between 'default' and 'mandatory' is not relevant.
If mandatory=false, then the default is ignored in the agent.
In your interpretation, mandatory=true causes the agent to
ignore the default.

Your view of mandatory is inconsistent with the rest of YANG,
which (correctly) focuses on the description of valid NETCONF configuration
databases, not the PDUs.  When focusing on the config, what
difference does it make if the manager explicitly sets the mtu to 1500,
or if the agent sets it to 1500 by default?  The data model should describe
what a valid mtu leaf looks like in the config, and nothing more.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 24 Jan 2008 11:29:22 -0500

>IMO this overlap between 'default' and 'mandatory' is not relevant.

Well, the issue we started with was what happens when there's a
default with mandatory true, but let's move on....

>If mandatory=false, then the default is ignored in the agent.

"ignored"?  No, it's used internally as the default when
the leaf doesn't exist.

>In your interpretation, mandatory=true causes the agent to

Same comment.

>databases, not the PDUs.

I don't agree.  YANG defines a data model, which consists in part
of a set of constraints on the data that appears inside valid
databases for that model.  Out of these constraints flow (fairly
easily) constraints on the NETCONF operations used to manipulate
the data in that database, which leads to constraints on those PDUs.
I don't see this at at odds with the rest of YANG.

>When focusing on the config, what

Why do we model data?  What are we trying to get out of the data
model?  My goal is to provide a formal description between the
device and client applications to allow those client applications
to manipulate data on the devices with a strong understanding of
what the data means and a rich set of operations for manipulating
that data.  We develop a contract between the client and server so
both sides agree that what an "mtu" means and what the valid values
are, when it needs to be set and what it means if it is not set.

So thing of the data model from that device/application point of
view and hopefully you'll understand why the term mandatory should
describe the requirement that something external must set this value.

Think of what "required" means on a web page.  It means that you
the user need to fill in a value.  If the web server knows an
appropriate default, it can fill it in and you don't need to do
anything.

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 24 Jan 2008 19:05:39 +0100

> is what's the difference between:

An implementation may include this leaf or not. In the latter case it
doesn't exist at all, no default is defined. Hence the device must be
able to live without any MTU value available (this is of course
impossible for Ethernet). If the mtu leaf exists in an implementation,
it has to start with the default value of 1500, unless and until a
client changes it (which may or may not be possible).

>         mandatory true;

Here every implementation conformant to this data model must have this
leaf. The interpretation of the default statement is as above.

In my interpretation the mandatory/optional and default concepts are
orthogonal. The former relates to the structure (leaf must or needn't
exist) whereas the latter to the value.
> the server already knows.

I understand what you are saying but I don't like it because it
introduces yet another meaning of validity with respect to a YANG data
model. We already had three:

1. validity of NETCONF PDUs
2. validity of entire configurations
3. managed device behaviour (e.g., must set the defaults)

Your view of mandatory brings another one:

4. client behaviour (must set mandatory parameters)

Each of these views differs in some aspects from the others. I would
myself prefer to concentrate on 2 and try to infer what it means for 1.

> capability, you won't see defaults for stuff that doesn't exist.

If it doesn't exist because the data modeller decided the leaf is
optional, I have to be able to live without it. If it is mandatory, then
I must be able to get it from the device via get-config
(modulo :with-defaults).

> YANG?  How do you see this helping you?

I'd be happy with items 2 and 1 above.
 
> what's valid in the XML.  If the model says:

In some cases this mapping is automatic, some cases are defined in the
YANG draft and some are not clear yet (to me at least).

> in the model, it must appear in the factory-shipped config.

In my view of mandatory the factory default configuration must be (and
is) valid. In your view, if I understand it correctly, it is not valid
till the client sets the mandatory parameters.

> will catch you and bludgeon you about the head and shoulders.

No, since it's optional (but of course lada:optional != phil:optional).
Both the device and manager can live without full names being in the
database.

> put "full-name", it shouldn't be advertising the capability for

Again, my model: if a parameter is optional then the client cannot be
surprised if it is not in the configuration obtained by get-config and
attempts to set it are ignored or return a warning.

> doesn't abide by a data model that it advertises, it's a bug.

I fully agree, we only differ in the interpretation of a YANG statement.
The confusion is due to an interplay between mandatory/optional and
defaults. As I said, I treat them as orthogonal and actually don't need
the defaults at all. I'd also say my interpretation is in accord with
section 7.6.4 of the YANG draft.

> Then your factory default config should look like:

Actually I had this in mind, but it doesn't matter:
users {
  user {
         login admin;
         uid 0;
  }
}

The point is that both admin and uid values are read-only.

> factory-default configs should follow the rules in the YANG data model.

Yes, factory default config should be valid.

Cheers, Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Phil Shafer <[email-masked]>
Date: Thu, 24 Jan 2008 22:11:43 -0500

>exist) whereas the latter to the value.

They aren't orthogonal.  Your intepretation leads to the logic Andy
laid out earlier:

  Q1: Is it mandatory?
     true -->
       Q2: Does it have a default?
          false -->
              A: Then the leaf must be explicitly set
          true -->
              A: Then the agent must implicitly create it w/ the default
     false -->
        A: no one does anything

I want to see the question as:

  Q1: Is it mandatory?
     true --> 
        A: Then the agent must implicitly create it w/ the default
     false -->
        A: no one does anything

Internally, when the subcomponent fetches data from the database,
you may have logic like:

   value = isconfig(x) ? value(x) : default(x);

So if I don't make an mtu leaf, the software that asks for the mtu
can get the default value without forcing this into the config.
 
>myself prefer to concentrate on 2 and try to infer what it means for 1.

I'm not adding this aspect.  The client must know what parameters
it needs to set.  I'm just wanting the answer to this aspect to
be simple.  If it's mandatory, the client will need to set it.  If
it's mandatory and not present, the server will fail the config.

>YANG draft and some are not clear yet (to me at least).

Please let me know where it isn't clear and we can fix the draft.

>Both the device and manager can live without full names being in the

How?  If I give the user a form to fill in with the full name (which
I assume I should since the data model says it's there), and the user
gives me one, I'll send it to the device.  Will the device throw it
away?  This will lead to much weeping and gnashing of teeth.

>attempts to set it are ignored or return a warning.

This would be disasterous and would render the entire effort of
data modeling moot.  The data model is supposed to move us out
of the Wild West and into a more civilized world.  If the locals
can ignore parts of the law, then there is no law.  If you can't
even find out what parts of the law are being ignored, you're lost.

>I fully agree, we only differ in the interpretation of a YANG statement.

It seems we disagree on much more than that.  Should we step back
and think about what problem we're trying to solve?

Thanks,
 Phil

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 24 Jan 2008 20:17:21 -0800

Hi -

> Sent: Thursday, January 24, 2008 7:11 PM
...
...

In the SNMP/SMI worlds, the "optionality" Ladislav refers to is
handled by conformance statements, rather than the model per se.
In the CMIP/GDMO world, attributes are only optional to the
extent that they are associated with conditional packages, which
normally reflect varying conformance requirements, and whose
presence will be listed in the packages attribute.

Randy

---

From: Phil Shafer <[email-masked]>
Date: Fri, 25 Jan 2008 01:14:19 -0500

>handled by conformance statements, rather than the model per se.

Ah so maybe the confusion is "mandatory to implement" versus
"mandatory to configure".  YANG's mandatory statement is the latter.

YANG has no conformance mechanism.  Whether it appears in YANG-2.0,
I can't predict, but I'm hoping we can make base models that devices
can implement, with augmentations for additional config.

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 25 Jan 2008 11:02:05 +0100

>               A: Then the leaf must be explicitly set

I guess I differ from Andy here: in my view the agent will fill here a
value that satisfies the DM, even though it is not a default specified
in the DM (i.e, it is vendor's internal default). For example, if IP
address is mandatory on an interface but no default is defined in the
DM, the device could set it to 0.0.0.0. From the viewpoint of validating
the configuration (my item 2), it is valid - the mandatory element
exists and its value (presumably) conforms to inet:ip-address. True, the
interface is not fully operational, but this has nothing to do with
validity of the configuration wrt the DM.

> away?  This will lead to much weeping and gnashing of teeth.

In most cases a warning would be appropriate. I think though such
situations are hardly avoidable. I take your example:

     leaf mtu {
         type uint {
             range 576..8192;
         }
     }

What if a device supports only a subset of this range and the user tries
to set it to a value outside of this subset? Or should the range
statement in fact mean that this data model requires each implementation
to support the entire range?

> even find out what parts of the law are being ignored, you're lost.

If the law says something is optional, I can assume it's possible not to
have it.

> and think about what problem we're trying to solve?
Okay, what I am trying to solve:

I'd like to have first rather generic data models that can be used by a
broad range of devices. This is IMO possible only if the data models are
relatively liberal. The first important step for me is to be able to
decide whether an entire configuration is valid (in a static XML-like
sense) and what it means for the NETCONF PDUs. This would already be a
big boon - the knobs would be standardised. I am not saying the other
aspects of validity (behaviour of the devices and managers) are
unimportant but these are separate problems that should be addressed
separately.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 25 Jan 2008 11:07:44 +0100

> validity of the configuration wrt the DM.

I guess part of the problem we have in this discussion is that we do
not properly distinguish between configuration data and operational
state data. While a device may choose to assign automatically an
operational state of 0.0.0.0 for an unconfigured IPv4 address, this
particular address may still not be configuration state.

/js

---

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

> "mandatory to configure".  YANG's mandatory statement is the latter.

Oh yes, this is the Pudels Kern :-) I am sorry I wasn't able to express
myself so concisely. However, I still think Sec. 7.6.4 in the YANG draft
can be understood as "mandatory to implement": >>If "mandatory" is
"true", the node must exist in a valid configuration if its parent node
exists.<< I guess it's again due to the different meanings of validity.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 25 Jan 2008 11:23:50 +0100

> particular address may still not be configuration state.

Would it be a problem if it were a factory default configuration state
as well?

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 25 Jan 2008 11:30:10 +0100

On Fri, Jan 25, 2008 at 11:23:50AM +0100, Ladislav Lhotka wrote:
 
> Would it be a problem if it were a factory default configuration
> state as well?

If I as a user configure a box, I usually do not want to see the
millions of knobs that exists in the box which I have never touched
and are mostly irrelevant, especially for things like e.g. interfaces
that not configured by me. As someone who has to configure boxes once
in a while, I do agree with Phil's plea to keep the configuration
really down to the minimum that I have really configured and to
exclude noise about all the things I could potentially configure as
much as possible.

/js

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 25 Jan 2008 12:19:22 +0100

Mandatory in YANG means mandatory to configure.
Today YANG considers all mandatory and optional elements mandatory to implement.

Later we will probably define a conformance mechanism, then YANG will be able to say:

module foo defines 100 leafs and these 85 are mandatory to implement and the rest is optional.

We consider this conformance mechanism to belong to step to in the DML. AFAIK it is not really 
used in SNMP either. (We could start using mustImplement or something similar as a term for 
mandatory to implement.)

Balazs

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 25 Jan 2008 12:47:36 +0100

> exclude noise about all the things I could potentially configure as

I see, so we essentially come back to the fact that I would leave the
task of reducing complexity on the client side whereas you want to have
it on the server side.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 25 Jan 2008 12:55:08 +0100

Hi Balasz,

> used in SNMP either. (We could start using mustImplement or something similar as a term for 

I guess it's actually one of the differences between the SNMP and XML
worlds. Validity of an XML document means conformance to a schema.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 25 Jan 2008 12:56:59 +0100

> Please let me know where it isn't clear and we can fix the draft.
Here is one: what's the interpretation (if any) of the unique statement
for PDUs?

Example:

list aaa {
  key "k";
  unique "b c";
  leaf k { ... }
  leaf b { ... }
  leaf c { ... }

and assume the existing configuration contains two list items:

<aaa>
  <k>k1</k> <b>b1</b> <c>c1</c>
</aaa>
<aaa>
  <k>k2</k> <b>b2</b> <c>c2</c>
</aaa>  

1. Is it possible to send the following fragment in an edit-config
(merge mode)?

<aaa>
  <k>k1</k> <b>b3</b>
<aaa>
<aaa>
  <k>k2</k> <b>b3</b>
<aaa>

That is, after merging the resulting configuration will still satisfy
the statement 'unique "b c"' (values of c are different) but the PDU
doeasn't.

2. Does "unique" and also "key" statements assume any space
normalisation? For example, are the following keys different?

<k>k1</k>

<k>
  k1
</k>

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "Bert Wijnen" <[email-masked]>
Date: Fri, 25 Jan 2008 13:05:00 +0100

Inline

Bert Wijnen 

> -----Oorspronkelijk bericht-----
> Van: Balazs Lengyel [mailto:[email-masked]]
> Verzonden: vrijdag 25 januari 2008 12:19
> Aan: Ladislav Lhotka
> CC: [email-masked]
> Onderwerp: Re: [YANG] new pyang errors
> 
> 

OK, I like that. Can you make that statement explicit in the
draft, so everyone understands the intention.

> We consider this conformance mechanism to belong to step to in 
> the DML. AFAIK it is not really used in SNMP either.

In some MIB modules we actually have pretty good MODULE-COMPLIANCE
statements that try to make it clear which objects must be implemented
and what their minimum implementation needs to support. Such MIB modules
often have multiple such module-compliance statements if that makes
sense for different environments. 

Other MIB modules just have one big MODULE-COMPLIANCE statement that
- requires to implement all objects
- but leaves it open to the implementation to implement them
  read-only or read-write. 
Supposedly that can be reported by the agent via a AGENT-CAPABILITIES,
(in which one can also report deviations) which results in an OID 
that one can store in the sysOrTable and so a manager can pick up the 
compliance that an agent claims and then supposedly can read the
AGENT-CAPABILITIES statement and so it can determine (in machine
readable form) what exactly is supported by the agent.

Well, at least that was/is the theory.

But other than during early SNMP interoperability tests in the mid-1990s
I have never seen it used much (if at all). 
So we should learn from this and think hard before we fall into the
same trap of designing mechanisms that no-one uses.

Bert
> (We could start using mustImplement or 
> something similar as a term for 
> mandatory to implement.)
> 
> Balazs
> 
> Ladislav Lhotka wrote:

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 25 Jan 2008 13:44:17 +0100 (CET)

> Here is one: what's the interpretation (if any) of the unique statement

The draft says:

  The "unique" statement is used to put constraints on valid
  configurations. [...]

  In a valid configuration, the combined values of all the leaf
  instances specified in the string MUST be unique within all list
  entry instances.

Maybe we should be more clear what we mean with "valid configuration"?

> the statement 'unique "b c"' (values of c are different) but the PDU

Absolutely.  Also note that if you're modifying the candidate, it
is also ok to send:

 <aaa>
   <k>k1</k> <b>b3</b> <c>c3</c>
 <aaa>
 <aaa>
   <k>k2</k> <b>b3</b> <c>c3</c>
 <aaa>

When you <validate/> the candidate, it will fail.  It will also fail
to <commit/>.

> normalisation? For example, are the following keys different?

This isn't really a "unique" or "key" question; it is a datatype
equestion.  In this case, the YANG built-in type "string" behaves as
"xs:string", so no whitespace normalization is done.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 25 Jan 2008 14:28:20 +0100

> task of reducing complexity on the client side whereas you want to have

Yes.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 25 Jan 2008 14:33:34 +0100

[...]
 
> same trap of designing mechanisms that no-one uses.

Perhaps a clarification: We are not saying conformance mechanisms are
not useful. We just like to postpone them to the second phase of YANG
since conformance mechanisms are not needed to get started and we like
to keep the YANG effort reasonably scoped so that we have a chance to
complete what we started in reasonable amounts of time.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 25 Jan 2008 15:03:32 +0100

>   The "unique" statement is used to put constraints on valid

Yup, but Phil claimed:
server.

> Maybe we should be more clear what we mean with "valid configuration"?

Yes, there seem to be at least four different meanings.

> equestion.  In this case, the YANG built-in type "string" behaves as

Sure, but here it is quite crucial. Shouldn't YANG perhaps include a
built-in type equivalent to xs:token for these purposes?

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "Bert Wijnen" <[email-masked]>
Date: Fri, 25 Jan 2008 15:18:35 +0100

> complete what we started in reasonable amounts of time.

I understood that. And I am OK with postponing such work to a possible
2nd phase.  Appology if I gave the impression that I wanted it
to be addressed now. On the contrary, I was asking for reflection first
and to not quickly design such a feature without first understanding
why the mechanism we developed for MIB modules did not work (or did
not get deployed).

Bert