Subject: [YANG] how to signal revision?

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 16 Jan 2008 11:23:01 +0100

Hi,

how can the server and client make sure they are both using the same
revision of a given data model? Capabilities in NETCONF hello messages
use URIs but YANG draft says in sec. 5.4 that different revisions of the
same module should have the same namespace.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

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

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 16 Jan 2008 11:31:57 +0100

Hello Lada,
As I understand it, the basic idea is that you have compatible and incompatible changes. 
Chapter 5.4 speaks about compatible changes. Even for these there could be a subversion 
indicator somewhere in the module.

For incompatible changes, really anything major, the module will have a new name and URI. There 
is currently an empty chapter "9.  Updating a Module" in the current draft that will describe this.

Balazs

-- 
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, 16 Jan 2008 11:42:42 +0100

> is currently an empty chapter "9.  Updating a Module" in the current draft that will describe this.

Hmm, what could be the compatible changes, apart from correcting typos
in descriptions etc.? I guess even changing a single default value
renders the data model incompatible.

Lada 

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 16 Jan 2008 12:02:11 +0100

> renders the data model incompatible.

[BALAZS]: I thought of the following examples
- Extending the value range of a leaf
- adding a new non-mandatory leaf
- changing description in some cases
- adding new cases to a choice

Balazs

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 16 Jan 2008 12:35:49 +0100 (CET)

> same module should have the same namespace.

The idea is that we use the uri query argument to indicate the
revision number (see 7.1.3):

   <capability>http://acme.example.com/system?2007-06-09</capability>

(I realize that the text should be clarified; probably move the
discussion about the capability from 7.1.3 to 5.4).

> renders the data model incompatible.

Yes, changing defaults is incompatible.  If you do that, you have to
change the namespace.

But there are many common compatible changes you can do, the simplest
is to add new optional data.

Note that the text describing this is not yet written in the draft.

/martin

---

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

Hi Martin,

>    <capability>http://acme.example.com/system?2007-06-09</capability>

This makes sense, but is the query argument allowed also in URNs?

> is to add new optional data.

This means that a client that uses a new revision could send data that
the server doesn't know about. I don't think it's acceptable.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 16 Jan 2008 13:33:57 +0100

We should first define, what we mean with compatible. My definition is that a management system 
that knows only the old version can handle the node i.e. anything it writes into the node will 
work as in the previous version. An old management client will not send the new data.
Balazs

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 16 Jan 2008 13:36:15 +0100 (CET)

> This makes sense, but is the query argument allowed also in URNs?

Yes.  We also use them in rfc4741:

      urn:ietf:params:netconf:capability:url:1.0?scheme=http,ftp,file

> the server doesn't know about. I don't think it's acceptable.

No, the client has to understand that it cannot send data that the
server doesn't support.  We want to achive two things essentially -
that the server accepts "an old backup" (copy-config), and that the
server can send all data is has, and let the client worry about
filtering out the stuff it doesn't understand.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 16 Jan 2008 13:39:13 +0100

> Yes, changing defaults is incompatible.  If you do that, you have to

BTW, that's exactly why I am against the default values in typedef: they
make the data model too specialised. The defaults could be easily
handled as follows:

1. The standard that defines the type specifies in plain RFC-English
that the default value MUST, SHOULD or MAY be something.

2. An implementor reflects this in a device, but is also required to
fill the default (or another) value in the initial startup
configuration.

3. The client needn't care about what the default is, it just queries
the device to see the actual value, changes it if necessary etc.

This approach would make the same data model reusable with other default
value and, in addition, allow for honouring the semantics of MUST,
SHOULD and MAY. The default in typedefs is only usable in the MUST case.

So my suggestion is to remove the default statement form YANG.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 16 Jan 2008 14:05:13 +0100

> server doesn't support.  We want to achive two things essentially -

In other words, the client has to understand that the schema it uses is
not compatible with the one used by the server. Would it be a problem to
require that e.g., with every change in the data model proper the major
revision number must be increased and also the namespace URI changed?

The minor revision number then could be used for indicating cosmetic
changes in the YANG document not affecting the data model.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 16 Jan 2008 14:17:57 +0100

> work as in the previous version. An old management client will not send the new data.

OK, so by compatibility you essentialy mean "compatible from server's
viewpoint".

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 16 Jan 2008 14:34:13 +0100

Yes. How would you like to define it?
Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 16 Jan 2008 14:38:20 +0100

So we have two combinations
1) old manager new node (my case)
2) new manager old node

Both are interesting questions.
YANG's primary aim is to define what model the node provides, so I think we should define here 
what is a compatible change in the node's model.
Balazs

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 16 Jan 2008 14:44:10 +0100 (CET)

> revision number must be increased and also the namespace URI changed?

The problem is that it is unnecessarily restrictive - it means that an
old client cannot do its job even though the new revision of a module
just added one optional leaf (for example).  Extrapolating from this,
we can define a set of rules which must be followed in order for a
module to be compatible.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 16 Jan 2008 14:54:11 +0100

> 1) old manager new node (my case)

Right, compatibility means a different thing in each case.
 
> what is a compatible change in the node's model.

Yup, as Martin pointed out, one can assume the manager is more flexible
and should be able to handle gracefully weird data received from the
node, provided it knows the node uses a new data model that the manager
doesn't support.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Wed, 16 Jan 2008 05:58:45 -0800

> same module should have the same namespace.

The agent needs to implement the schema discovery data model
that is being standardized in the NETCONF WG.  Proprietary
extensions to the <capability> element in the <hello> exchange
are being used in the meantime.

> Lada

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 16 Jan 2008 06:08:13 -0800

> the device to see the actual value, changes it if necessary etc.

I disagree 100%.
The management of agent-supplied defaults has always been a problem
in NE devices.  More machine-readable support is needed, not less.

YANG has the "DEFVAL with teeth" that SMIv2 never had.
In YANG the default MUST be supported by the agent.
It is not just a suggestion.  This means the manager can
actually pay attention to the default defined in the data model,
and change it only if needed.

On large NE devices, it is common practice to keep the CLI config file
as small as possible by only including non-default values.  NETCONF
needs to support this feature as well, and YANG leaf/typedef default does that.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 16 Jan 2008 15:14:14 +0100

> we can define a set of rules which must be followed in order for a

Exactly, and this can also be (partly) inferred from the URIs. Depending
on that definition, different URIs (as well as revisions) on the client
and server side may or may not be a problem - some operations can be
safe while other aren't. It's a tricky area though.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 16 Jan 2008 15:31:11 +0100

> and change it only if needed.

I understand this but, as a matter of fact, most defaults in protocol
standards are of the SHOULD class at most. In a vendor-neutral
environment, it would be much safer if each device fills all the blanks.

> needs to support this feature as well, and YANG leaf/typedef default does that.

Yes, but this is only possible because the CLIs are vendor-specific. It
is quite common that different vendors use different defaults. If you
try to enforce a single default in the data model, the vendor that
thinks otherwise will come up with an entirely new data model (namespace
URI) which is IMO much worse for interoperability.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Wed, 16 Jan 2008 07:12:52 -0800

> URI) which is IMO much worse for interoperability.

You are entering a new topic zone -- why the IETF has never been
successful in standardizing the configuration of any of its protocols.
After 20 years and a pathetic handful of standard writable knobs,
one has to ask if maybe there is some part of the problem space
that has been overlooked.

We will never have standard writable knobs until vendors understand
the concept of a standard, and make an effort to define some
standard knobs, which actually provide enough functionality
to configure the device.

It takes a lot of work to define the standard knob settings,
and protocol WGs usually decide not to bother with any configuration
at all.  But we make all our hammers and all our nails by hand,
so it is easy to get away with it.

(Lewis and Clark burned down some forts along the way, to
recover and reuse their precious handmade nails.  We need to
learn how to get machines to make the nails... ;-)

Andy

---

From: Jon Saperia <[email-masked]>
Date: Wed, 16 Jan 2008 10:20:47 -0500

> standard knobs, which actually provide enough functionality

And they believe it is in their best interest (beyond lip service and  
Marketing) to have the standard.  There are plenty of smart people at  
vendors, they have the money to do it.  If they really wanted it and  
the customers really wanted to push it we would have them.  It has  
nothing to do with technology.
/jon

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 16 Jan 2008 17:32:11 +0100

> nothing to do with technology.

That's why I believe it won't help to specify the default in the data
model. And it's not necessary - I can actually imagine a manager station
that follows the standards and changes the wrong defaults in misbehaving
devices - and showing the user only non-default values, but according to
its own set of defaults, not necessarily the devices'.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Jon Saperia <[email-masked]>
Date: Wed, 16 Jan 2008 11:54:38 -0500

> its own set of defaults, not necessarily the devices'.

I understand your perspective but even  though I said what I said, if  
we were to go down this path, defaults can be helpful.  Any manager  
that attempts the configuration function will have to be pretty  
sophisticated because of the variability (even with standards) that  
will be sure to exist. That does not mean that they will not do bad  
things from time to time, but the market has a way of fixing things.

/jon

---

From: Andy Bierman <[email-masked]>
Date: Wed, 16 Jan 2008 09:02:46 -0800

> its own set of defaults, not necessarily the devices'.

I disagree.
If there is a agreed-upon default value (along with
the rest of the agreed-upon properties), then it should be
documented, and be both machine and human readable.

Why should the manager assume the devices will be misbehaving or buggy?
I think vendors try to implement the standards as they are written.
There is no big conspiracy theory here -- just a lot of hard work that
has been historically difficult to accomplish.

If the shared mindset persists that all these NE boxes are proprietary
by nature, and they have little or nothing in common that can
be configured with standard data models, then we are wasting
our time with NETCONF and YANG.  I choose to believe that we
are simply in the Stone Ages of network management, and it will
take some time to evolve the protocols and tools beyond the
hand-crafted, ad-hoc, poor excuse for a programmatic interface,
we call The CLI.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 16 Jan 2008 14:08:47 -0500

>standard knobs, which actually provide enough functionality

If you are looking for a constant historical line of thought that
explains the failure of standardized configuration, look no further
than this line above.  The "it's the vendor's fault" line has been
a constant albatross around such efforts.  We are better off admitting
that the problem is not simple, and studying the factors that make
it difficult.  Configuration is not simple and underestimating the
problem won't help standardization issues.

In designing configuration for a complex device, you have a
number of goals:

(a) avoid human error -- design the config to make errors
    detectable in software, and observable in "show" output.
(b) be flexible -- customer deployment scenarios exceed your
    vision when you design something.  Allowing for these
    cases is both important and painful.
(c) complexity reduction -- if it's complex to configure, it
    won't get deployed.  And if it does get deployed, the
    support costs for both the customer and the vendor will
    be high.
(d) details should be hidden where possible -- the user shouldn't
    need to fully grok hardware, software, or protocol issues to
    config them.
(e) enhancement/future proofing -- this config needs to work on
    next year's hardware running next year's software, often
    running next year's protocols.
(f) full feature support -- the config needs to fully represent
    the available features your hardware and software support.
(g) got to be consistent -- make it fit inside the rules and
    conventions of your existing syntax
(h) holistic view -- the config should look like a single description
    of a complete system, not a dog's breakfast of tokens.
(i) I'm sure there's more.....

In the fight for simplification, many of these goals cut against
each other.  For example, in trying to be flexible, I have to decide
when an odd configuration is an error and when the user is just
doing something clever (which may be an error, but is an intentional
one).

For standardization, the goals are often completely different.
Expressiveness and accuracy win over simplicity.  A single complex
method of configuration wins over a dual "common" and "advanced"
approach.  The model for a standard must be something that can
support all platforms, which leads to complexity, and the translation
between the standard's complex model and the unique abilities of
individual platforms is non-trivial.

An example is packet filtering, where the device config is more
often dictated by the hardware architecture and the layout of that
hardware (in terms of where packets can be filtered, what can be
filtered on, what can be done to them at that layer, and what
resources are consumed) is often directly visible in the configuration
in order for the customer to express their desired setup.

But a standard needs an "uber" model, where any sort of filtering
can be done at any place with any outcome without concern for
resource impact.  No vendor will implement this model, and the
translation between the model and the device config requires a
strong understanding of the performance .vs. resource utilization
tradeoffs that the customer is willing to make.

For example, some functionality may be available in hardware at
wire rate; other in hardware at lower speed; other in dedicated
CPUs; and still other in the main CPU.  Choosing the proper filtering
point is a matter of both the speed and abilities of that point,
plus chip memory and other contention issues.  And getting a correct
assignment will still be wrong if it's not the assignment the
customer wanted.

This translation must be performed in a way that avoids letting
small changes in the config from turning into large config changes
on the device.  It's not an easy problem, and to my mind it's the
key to device- independent configuration.

The fact that my bgp configuration doesn't look like the bgp
mib shouldn't be surprising, since the two configurations
serve two different masters.  The lack of any automated
translation between the two is the real killer.

A key aspect of this translation is the ability to round-trip,
turning MIBs into device config and back in a way that doesn't
lose information.

The problem isn't getting a few knobs to configure basic functionality,
but getting a solution that's complete enough to give folks sufficient
faith to move toward it.  If it solved 20% of the problem, it's
worthless.  When it solves 80-90% of the problem, it's interesting.

NETCONF gives us the ability to manipulate configuration in XML,
which is a good first step.  YANG gives us the ability to define
that XML in a way that allows extensibility and the expression of
device-specific content, which is a good second step.  The next
step will be a translation framework that allows robust translation
between a standard view and a device specific view.

So I think we are on the right road, although the pace of the journey
is disheartening.  But regressing to this "it's the vendor's fault"
line is completely unproductive.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 16 Jan 2008 11:47:14 -0800

> problem won't help standardization issues.

I do not think it is all the vendors fault.
The IETF process, the current state of data modeling tools
used in NE development, and lack of relative priority among all
customer requirements contribute greatly.

(I hope the requirements spec captures all your text below.)

Since we already know that getting 10 vendors together
in a WG meeting room just to agree there is nothing in
common to standardize doesn't work, we need to come
up with a new plan.

IMO, the IETF has been avoiding the real problems facing NETCONF.
YANG does not address the real problems preventing standard
data models for configuration either.

I am hoping that in the end, the solution is something more
elegant than a standard way to figure out which of the 47 ways
a particular device implements a given data model.
But if not, then maybe registry-based-indirection mechanisms
would work instead.

Andy

---

From: Jon Saperia <[email-masked]>
Date: Wed, 16 Jan 2008 14:50:28 -0500

To underestimate other factors that have inhibited progress, whether  
from technical limitations, the vendors, standards organization, or  
user community, has been counter productive as well.  Whatever is  
developed must allow for variability.
/jon

---

From: Jon Saperia <[email-masked]>
Date: Wed, 16 Jan 2008 14:53:50 -0500

> But if not, then maybe registry-based-indirection mechanisms

I think there is a lot of merit in a 'registry-based' mechanism  
approach.   You would still need aspects of what has already been  
accomplished, and YANG, or something else for the broad solution  
desired.
/jon

---

From: Phil Shafer <[email-masked]>
Date: Wed, 16 Jan 2008 15:11:03 -0500

>data models for configuration either.

Yup, it's just another step.  My concern is that we don't
spend seven years on this step.

>But if not, then maybe registry-based-indirection mechanisms

The translation framework needs to give flexibility not only
to the expressiveness of the device configuration, but also
to the ability of the provider to tailor the translation to
their needs/networks/products/customers/etc.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 16 Jan 2008 12:24:57 -0800

> spend seven years on this step.

Some of us will vote with our feet way before then ;-)

> their needs/networks/products/customers/etc.

I can remember (from my former life as an IOS SW developer),
several bold attempts to provide this sort of translation in a closed,
self-contained application -- and they all failed spectacularly.
It is way too hard for 1 apps-dev team (or person!) to keep the
database up to date or even tractable.

But, if WEB apps existed that provided an easy-to-use Wikipedia
kind of community-input approach, combined with structured
use of NETCONF capabilities, YANG data models, and some new (very TBD)
indirection mechanisms in YANG, then it might be possible
to get 80% of a router configured auto-magically, and drastically
simplify the other 20%.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 17 Jan 2008 08:56:59 +0100

> things from time to time, but the market has a way of fixing things.

I am not against specifying defaults (reasonably), I only don't like the
fact that changing a default value implies a different data model. I
understand the data model primarily as a means for checking whether a
given document is valid or not and default values are irrelevant in this
respect. It is already difficult to standardise the knobs and default
values are yet another level.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 17 Jan 2008 09:54:12 +0100

Hello,
I think you are arguing about different things. As I understand your comments:
Statement 1) says: defaults are important, so if we do have an agreed default value, we should 
document it in a proper, formal way. (I fully support this.)
Statement 2) says: it is very difficult to agree on good default values so we should use 
extreme caution specifying "mandatory" defaults in standards. I can agree with that as well.
We can still to define recommended-only defaults in the description statement if the default is 
not obvious enough.

The two statements do not contradict each other in my view.

Also while it is difficult to define default values in standards, YANG and NETCONF will be used 
a lot to define proprietary data models as well. It is much easier to define defaults here, and 
yes we do want a formal definition of these defaults (actually we already have it in the 
Ericsson-DML.)

Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 17 Jan 2008 10:47:59 +0100

Hello,
This is a VERY good mail about configuration management goals, thank you. I would like to add 
one point:

- in my experience if the configuration is complex, the operator will make big mistakes in it, 
leading to system outage. So if it is too complex it is faulty even if it works.

An operator (organization) can easily have 50 different types of nodes to handle, which might 
mean 2 completely different types per operator (person). For this reason he will often  not be 
an expert in my specific node. According to a telecom industry survey about 50% of node 
downtime is attributable to operator errors. The node is too complex, so they make mistakes. 
And when I say too complex I am not just thinking about operators like Sprint or Uunet, but 
operators in Uganda and Laos.

Balazs

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 17 Jan 2008 11:29:03 +0100

Hi Balasz,

in my view, the basic difference is this:

Do we want to use (YANG or other) data models
(i) for validating XML documents in the NETCONF context, or
(ii) for specifying behaviour of network devices and/or management
software?

I am primarily interested in creating standard data models for (i) and
concerned that pursuing (ii) might make the result unusable for (i).
Note that the default statement makes sense only in (ii).

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 17 Jan 2008 11:46:44 +0100

Hello Lada,
I think (for Ericsson I know) we do NEED both i and ii; with all capital letters really. E.g. 
if we were just validating XML you could throw out
- default
- partly description
- reference
- revision
- contact
- organization

maybe more.

I don't see why the two aims are conflicting. Could you give me an example?

Balazs

However all this is needed

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 17 Jan 2008 12:27:02 +0100

> (ii) for specifying behaviour of network devices and/or management

I have no clue what you mean with "validating XML documents in the
NETCONF context".

I believe the real meat is in validating configurations, not so much
the XML serialization of (fragments of) configurations exchanged in
NETCONF messages.

/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: Balazs Lengyel <[email-masked]>
Date: Thu, 17 Jan 2008 12:35:08 +0100

Ladislav Lhotka wrote:
> Assume there is a standard data model urn:ietf:X and a vendor that is
> essentially happy with it, but in their device they want to change a
> certain default value specified in the model. So they are forced to use
> another model, say, urn:vendor:Y. A NETCONF manager that uses urn:ietf:X
> should in principle be able to interoperate smoothly with the device but
> refuses to establish a session because of unknown capability.
> 
> If the model did not specify the behaviour of the device, the vendor
> could use it directly.
> 
> Lada
This only means that the standard body for that particular protocol was not careful enough when 
choosing the default value. Maybe it should have chosen a "SHOULD" type of default that is not 
formally specified in the default statement just included in the description statement.

YANG gives you the possibility to enforce a default. It just gives you this as an option, that 
you might or might not use.

Balazs

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 17 Jan 2008 13:07:24 +0100

> I have no clue what you mean with "validating XML documents in the

The NETCONF messages exchanged between the server and client are
serialised XML and validation means that the other side is able to tell
whether the received data are legal. It's not so important whether you
perform this check on the serialised XML, DOM tree or otherwise. YANG
draft always speaks about XML representations and nothing else.

> the XML serialization of (fragments of) configurations exchanged in

I agree, yet even in this case the distinction between (i) and (ii)
holds, after changing "XML documents" to "configuration data".

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 17 Jan 2008 13:16:47 +0100

> you might or might not use.

Do you believe there is no politics involved in the standardisation
process? I don't.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 17 Jan 2008 13:42:13 +0100

> I think (for Ericsson I know) we do NEED both i and ii; with all capital letters really. E.g.

Fine, it could also be done in separate steps. The approach I use takes
RELAX NG together with various extensions (in different namespaces) that
serve the different purposes. Only the RELAX NG part together with a
subset of the extensions are used for validating configuration data
while other extensions specify behaviour of the device (including
defaults), annotations etc.

> if we were just validating XML you could throw out

Yes, I'd like to :-)

> - organization

Well, not necessarily, I consider these items informational (the data
model remains the same if they are changed).

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 17 Jan 2008 14:57:24 +0100

> draft always speaks about XML representations and nothing else.

No, you are missing an important piece. While an XML fragment shipped
in a NETCONF message may be valid, it might not lead to a valid
configuration. I don't think it is true that the YANG draft "always
speaks about XML representations and nothing else".

Regarding defaults, the question boils down to whether a NETCONF
client can assume that specified defaults are used or whether to be on
the safe side the client has to either set defaults itself or check
what was set by the server.

The alternative would be to have a mechanism allowing implementations
to post the defaults they are going to use rather than hard wiring
defaults in the specification. So a vendor can augment a standard with
the defaults that the vendor's implementation is using. This surely
adds some complexity. An even further reaching mechanism would be to
make the defaults being used by an implementation itself writable,
e.g. by introducing a template mechanism which adds defaults for stuff
not defined explicitely by a NETCONF client.

Our goal was to start with something simple, allowing us to add more
powerful mechanism via extensions over time once we see that they are
really needed (that is there is enough uptake of NETCONF / YANG).

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 17 Jan 2008 16:01:50 +0100

> what was set by the server.

At the start of a NETCONF session, the values in the
running/startup/whatever configuration may be different even if the
server's factory defaults follow the standards. The client can't IMO
safely avoid checking or setting all variables in server's
configuration. 

> really needed (that is there is enough uptake of NETCONF / YANG).

I think this applies to the default statement, too. I am arguing it's
not needed for NETCONF operation and may complicate things.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 17 Jan 2008 16:22:00 +0100

> safely avoid checking or setting all variables in server's

Sure. But when I create something new without specifying all defaults,
do I know what I get? In SNMP, you don't. In YANG, you do.
 
> not needed for NETCONF operation and may complicate things.

So if I understand right, your proposal is to remove the default
statement, not to change its semantics, correct?

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 17 Jan 2008 07:42:30 -0800

> statement, not to change its semantics, correct?

I strongly object to removing the default-stmt.
As Balazs pointed out, if a WG does not agree on a suitable
default value, they do not have to define one.  This clause
is needed to support NETCONF, not only to provide as much
machine-readable info about the data model characteristics,
but to simplify NETCONF tasks for operators and applications.

There are likely to be many knobs in a real config file that are optional
and have suitable agent-supplied default values.  It is very useful
for operators and applications to know this information.

There are some cases where the agent implementation varies from
the data model specification.  This does not mean we should throw
out 'default'.  It means we need to address agent conformance
and agent capabilities (Something YANG ignores completely right now.)

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 17 Jan 2008 17:19:50 +0100

> do I know what I get? In SNMP, you don't. In YANG, you do.

It depends on what that something is: Manager front ends can certainly
save the user from seeing/specifying configuration variables with
default values (and these needn't be only "MUST" ones, see most CLIs)
but in get-config and edit-config messages I'd prefer not to rely on the
other end to interpret the missing values as defaults. If this is
ensured, the server and client may use different sets of defaults
without any risk of confusion. 
 
> statement, not to change its semantics, correct?

Yes.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 17 Jan 2008 17:57:09 +0100

> but to simplify NETCONF tasks for operators and applications.

Operators should only be concerned with the defaults used by their front
ends - and these would typically include much more than just the MUST
defaults that YANG can handle.

> and have suitable agent-supplied default values.  It is very useful

How many of them could possibly be of the MUST sort? I don't know many.
The default is a weak concept, it's not like a fixed constant.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Thu, 17 Jan 2008 10:12:13 -0800

> defaults that YANG can handle.

Many operators want to know how to control the NE devices
in their network without relying on any magic 'front-end' that
always knows what values work on any given device.

NETCONF is designed to work, even if all the operator
has is 'ssh -s netconf -p 830' for access to the NETCONF agent.

> The default is a weak concept, it's not like a fixed constant.

I disagree.
First, it is up to the protocol WG defining the knob, not the YANG WG.
Given that the protocol could define a range of compliant values for a
standard knob, it is one extra step to pick 1 of the compliant values as
the default.

A trivial example is a boolean knob (or presence container in YANG)
that represents some service or feature, and the WG agrees it is 'off' 
by default.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 17 Jan 2008 21:44:11 +0100 (CET)

Hi,

> that represents some service or feature, and the WG agrees it is 'off' 

This is an interesting example, but currently YANG does not support
this use case, i.e. marking a presence container as present by
default.  Is that something we should add?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 17 Jan 2008 13:01:54 -0800

> default.  Is that something we should add?

What does it mean wrt/ the child nodes of the container
if the default present flag is set to true?

Isn't the container created by default if it has any child nodes with
defaults?  If this flag=FALSE, does that change?

This new feature would allow the container to be created even if
it has no child nodes with defaults?

Can this be turned on/off with a container refinement statement (in a 
uses-stmt)?

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 17 Jan 2008 22:09:53 +0100 (CET)

> if the default present flag is set to true?
         ^^^^^^^^^^^^^^^^^^^^
What is that?

> defaults?  If this flag=FALSE, does that change?

A normal structural container (with no presence statement) behaves
like that, except that it seems to be a meta-physical question whether
the container really is created or not ;-)

> it has no child nodes with defaults?

Currently, it cannot be defined in the data model if a presence
container gets created by default or not.  So if you do:

  container foo {
    presence "turns on the foo protocol";
   
    leaf bar {
       type int32;
       default 42;
    }
  }

Then it is not defined if foo exists or not (when it's parent gets
created).  If it exists, foo/bar has the value of 42 by default.

At least we should clarify this in the draft, e.g. by saying that a
presence container is not created by default.  That means that the
manager knows which behavior to expect.

Or we could add a new statement to control this.

> Can this be turned on/off with a container refinement statement (in a 

If we add such a statement, yes I think it could be refined, just like
defaults for leafs.

/martin

---

From: Phil Shafer <[email-masked]>
Date: Thu, 17 Jan 2008 22:00:36 -0500

>default.  Is that something we should add?

This would be confusing and probably broken.  If it's "present"
by default, why have it and how do you turn it off?  You can't
delete it, since it comes right back, so you can't turn it off.
So what's the point of giving it a "presence"?

Thanks,
 Phil

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 18 Jan 2008 10:21:47 +0100

Hello,
Why would the presence container come back automatically? There's today no text in the draft, 
that says presence containers are automatically removed or created.

The draft says
"If the leaf has a default value, the server MUST use this value internally if no value is 
provided by the NETCONF client when the instance is created."

Actually we failed to state what happens, if we later explicitly delete a leaf with a default 
value. In my view if the user wants to delete it then it should go away; no value present any 
more.
One more thing I think is still missing from the draft, is whether must expressions consider 
default values or not?

Balazs

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 18 Jan 2008 14:29:44 +0100

On Thu, Jan 17, 2008 at 05:57:09PM +0100, Ladislav Lhotka wrote:
> Andy Bierman p????e v ??t 17. 01. 2008 v 07:42 -0800:

I believe the assumption of the availability of a smart frontend 
won't work for all. For me, usefulness without a smart frontend is a
requirement. If there are requirements folks here, please write this
down.

/js

---

From: Phil Shafer <[email-masked]>
Date: Fri, 18 Jan 2008 09:09:55 -0500

>that says presence containers are automatically removed or created.

"come back" in the virtual sense, so if the element isn't it the
document, it implicitly is there.  Isn't that what Martin meant by
"present by default"?

>value. In my view if the user wants to delete it then it should go away; no value presen
>t any more.

If an element is deleted, the configuration should behave as if it never
were present, meaning it should revert to the default.  Otherwise there's
a difference in behavior between not having an statement in the config
and having it but deleting it.  This difference won't be reflected in
the "show" output, and reloading the config or rebooting the device will
give different behavior.

>One more thing I think is still missing from the draft, is whether must expressions cons

We discussed this at some point and decided that "must"s must
see defaults, but there needs to be a helper function to allow
one to detect unconfigured values.

    must "../mtu < 1500 or not(yang:is-set(../mtu))";

I don't think this is in the current spec.

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 18 Jan 2008 15:20:54 +0100

> requirement. If there are requirements folks here, please write this

I didn't say "smart frontend". Even the standard input used for
connecting server's ssh subsystem is a frontend (dumb, right). However,
in this case no substitution of defaults happens at the client side and
I would require the poor user to type in all elements&values he wants to
change. In the default merge mode of edit-config it's not an issue
anyway.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

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

> document, it implicitly is there.  Isn't that what Martin meant by

You're right, this won't work, or maybe we should say that it is
different.  It is more of an "initial-value" than default.

>> that represents some service or feature, and the WG agrees it is 'off' 

This cannot be done in current YANG.

/martin

---

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

>This cannot be done in current YANG.

If it's off, then it doesn't appear in configs.  When it appears,
it's turned on.  When it's removed, it's turned off.

But I'm sure I'm missing something here....

Thanks,
 Phil

---

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

> >One more thing I think is still missing from the draft, is whether
> >must expressions consider default values or not?
> 

It's on my TODO list.

I was thinking the text should say that default values exist in the
data tree, and then clarify the text about XML encoding of leafs to
say that leafs which are set to their default values in the data tree
do not have to be sent.  The must description talks about the data
tree, so by adding the defaults to the data tree, the must expressions
are covered.

One question is how the xpath function should behave:

                            node set     node set to   node does
                            to default   other value   not exist
   --------------------------------------------------------------
   yang:has-default(node)    true          false         false
   yang:is-set(node)         false         true          false

Maybe it's no big deal - if you want to check for existance, that's
trivial in XPath.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 18 Jan 2008 15:51:28 +0100 (CET)

> But I'm sure I'm missing something here....

I guess I mentally extrapolated from Andy's example... if the WG can
agree that it's 'off' by default, I was thinking they could agree that
it is 'on' by default as well.  This cannot be done.

/martin

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 18 Jan 2008 19:41:30 +0100

If we could agree that a leaf thats set automatically to it's default at least conceptually 
exists, that would make understanding how this works MUCH easier.
However we have to describe how this effects non-presence containers
Balazs