Subject: Re: [netmod] YANG must work with NETCONF

From: Gerhard Muenz <[email-masked]>
Date: Mon, 17 Aug 2009 13:20:12 +0200

Hi,

Martin Bjorklund wrote:
> Andy Bierman <[email-masked]> wrote:
>> There are several details in YANG that are legal,
>> yet they represent data models which cannot possibly
>> be supported on any NETCONF agent.
>>
>> Mandatory top-level nodes are allowed in YANG
>> but not supportable in a NETCONF agent.
> 
> I disagree.  See the email thread "mandatory mess".  If you have a
> top-level mandatory leaf, it MUST have a value in a valid database.
> So, when the system has started and the NETCONF i/f is up and running,
> the leaf MUST exist.  A user can then modify it, but not delete it.

Sorry that I have to ask again. I tried to explain the IPFIX use case in
http://www.ietf.org/mail-archive/web/netmod/current/msg03297.html
I only got one answer by Phil which did not really clarify the issue.

Up to now, I've thought that "mandatory" means "MUST be provided by the 
user". Apparently, this is not true for top-level nodes. I'm confused.

Does "mandatory" mean that the agent will create the node if it is 
missing (i.e., not provided by the user)?
Is this a general rule or does this only apply to top-level nodes?

For me, it is important to know if there is a difference because we have 
nodes in non-mandatory containers which will be created by the device if 
not created by the user. Do I have to declare them mandatory as well?

Thanks,
Gerhard

> 
>> If an agent is free to choose what mandatory means,
>> then since all YANG modules need to
>> work with all conforming NETCONF implementations,
>> the top-level cannot be mandatory.
> 
> The agent is not free to choose what mandatory means.  It means that
> the leaf MUST exist in a valid data store.
> 
>> leafref objects are allowed to point at non-existent
>> nodes in YANG but this is not implementable on
>> the agent.  If the pointed-at object is not present,
>> then any object pointing at that object must also
>> be removed from the agent (ripple out until done).
> 
> I assume you refer to leafrefs which point to leafs with if-feature?
> As I wrote in the other email thread, I think this is a valid concern,
> and we should fix it.  I prefer to keep the discussion in one email
> thread though.
> 
>> YANG is already extremely difficult to learn.
> 
> I don't know what you base this on, and I don't know what do to with
> this comment.  From my experience with pioneer YANG writers, I
> disagree though.
> 
> 
> /martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 17 Aug 2009 14:00:42 +0200 (CEST)

Gerhard Muenz <[email-masked]> wrote:
> user".

Yes this is true, and the way you have solved this in your module is
IMO correct - i.e. use an optional leaf and specify the behavior in
the description clause.

> Apparently, this is not true for top-level nodes. I'm confused.

It is also true for top-level nodes, but since such a node must exist
in the initial data store it must be created as part of the initial
system start.  The data might be set using some initial CLI or using
some other initial data.

The important thing is the observed server behavior.  If you do a
get-config of running, the data you get back must be valid.  If you
create e.g. a list entry which has a mandatory leaf, you must set the
value.  The agent will not set it.

> Does "mandatory" mean that the agent will create the node if it is missing
> (i.e., not provided by the user)?

No.

> Is this a general rule or does this only apply to top-level nodes?

I don't view this as created by the agent.  I view it as being part of
the initial (valid) data store.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 17 Aug 2009 15:24:27 +0200

Hi Gerhard,

in fact, I started the thread "mandatory mess" because of the weaselness
of the crucial (interrelated) terms such as configuration database,
mandatory/optional leaves and default values.

I have the impression that due to political requirements on vendor
neutrality it is taboo to speak about any particular information model,
but IMO this approach will backfire in the future - and the parallel
discussion in NETCONF ML about database architecture seems to indicate
the same thing.

A possible solution - still quite neutral - would be to define a base
infomation model and then the various vendor representations of config
datastores as views of this base model.

Anyway, for me a mandatory value is one that's required for the
operation of a device or protocol and this definition is independent of
whether there is any default value supplied either by the data model or
"initial default configuration".

Lada

Gerhard Muenz píše v Po 17. 08. 2009 v 13:20 +0200:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Mon, 17 Aug 2009 06:56:03 -0700

> "initial default configuration".

I must say that I was surprised to find out that
mandatory doesn't mean the manager must provide a value.
That worries me, because if I do not want any default
in my data model, and I want all implementations of this model
to fail unless the mandatory node is set, there is no way to do that
in YANG.  Any agent is free to make up a value for a mandatory leaf.

This is not the same is pre-loading the /system or /interfaces
subtrees.  Lists and containers cannot have the mandatory-stmt.
They do not matter here.

> Lada

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 17 Aug 2009 16:19:47 +0200 (CEST)

> mandatory doesn't mean the manager must provide a value.

The intention is that the manager must provide a value.

> to fail unless the mandatory node is set

Yes.

> there is no way to do that

No, that is not the intention.

> subtrees.  Lists and containers cannot have the mandatory-stmt.

But the leaf /system/sysName might be mandatory, and can be preloaded.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 17 Aug 2009 16:27:14 +0200

> in YANG.  Any agent is free to make up a value for a mandatory leaf.

That's why I'd prefer to handle the defaults as a separate problem from
mandatory/optional. Parameters like MTU for an interface will most
likely be configured to a value even in a virgin device (or hardwired in
a dumb device), but in my view MTU is mandatory because the interface
cannot work without having the value.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Phil Shafer <[email-masked]>
Date: Mon, 17 Aug 2009 10:37:45 -0400

Ladislav Lhotka writes:
>Parameters like MTU for an interface will most

This makes a great example for explaining the YANG take on defaults
and mandatory.

An operating interface must have an MTU, but the configuration for
that MTU is not considered mandatory in YANG, since the device will
provide a default value if there is not one in the configuration.

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 17 Aug 2009 17:13:46 +0200

> provide a default value if there is not one in the configuration.

What is the relationship of this "default value" to YANG 'default'
statement?

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 17 Aug 2009 17:38:57 +0200

On Mon, Aug 17, 2009 at 05:13:46PM +0200, Ladislav Lhotka wrote:
> Phil Shafer p????e v Po 17. 08. 2009 v 10:37 -0400:
> > Ladislav Lhotka writes:

None. If you plug a PCMCIA network card in your notebook, you will see
a suitable MTU - you did not configure it nor is it going to be the
same for all possible network cards.

/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: Phil Shafer <[email-masked]>
Date: Mon, 17 Aug 2009 11:22:20 -0400

>What is the relationship of this "default value" to YANG 'default'

They are identical.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Mon, 17 Aug 2009 11:30:30 -0400

>same for all possible network cards.

Depending on if the 'default' statement appears inside the model.
If the model has a default statement and the configuration was
made using this model, then the device should honor that model's
default value.

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 17 Aug 2009 18:14:36 +0200

> made using this model, then the device should honor that model's

But in the example we discussed, such a default statement does not
make sense.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 17 Aug 2009 19:59:21 +0200

> same for all possible network cards.

I think making the notion of mandatory dependent on manager actions is
broken, especially because there can be multiple managers. Say the "mtu"
leaf is declared mandatory in the data model and the device "calls home"
after being switched on and the vendor's manager application sets the
"mtu" parameter. Is it OK with respect to YANG rules? What's the
difference between mandatory and optional in this case?

I very much prefer the static notion of optional/mandatory that's common
in XML schema languages, which says whether the element must be present
in a valid document.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 17 Aug 2009 20:33:22 +0200

> >What is the relationship of this "default value" to YANG 'default'

If there is no 'default' statement in the data model, perhaps because
there is no single "right" default value, the "vendor default" may
(must) still be set, if I understand you correctly. So they are not
identical.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 17 Aug 2009 20:34:52 +0200

> made using this model, then the device should honor that model's

Where is this specified?

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 17 Aug 2009 21:04:53 +0200

> difference between mandatory and optional in this case?

Section 7.6.4 spells out what mandatory means. Can you phrase your
question relative to the text in 7.6.4?
 
> in XML schema languages, which says whether the element must be present

I think this is what section 7.6.4 says. It establishes an existance
constraint on leafs. What is wrong with that?

/js

---

From: Phil Shafer <[email-masked]>
Date: Mon, 17 Aug 2009 14:51:26 -0400

>(must) still be set, if I understand you correctly. So they are not

Yup, if there's no default statement in the data model, they are not
identical, and there's no relationship (since having a relationship
with something that does not exist is difficult).

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 17 Aug 2009 21:24:38 +0200

> constraint on leafs. What is wrong with that?

Nothing, and I am perfectly fine with it, but it also doesn't say that
mandatory leafs must be set by the manager, unless "MUST exist" means
that.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 17 Aug 2009 21:55:25 +0200

On Mon, Aug 17, 2009 at 09:24:38PM +0200, Ladislav Lhotka wrote:
> Juergen Schoenwaelder p????e v Po 17. 08. 2009 v 21:04 +0200:

Mandatory leafs must exist in a valid configuration. We agree on that
I think and it seems we even agree that the text in the ID is fine.

The remaining discussion how those leafs are created is more a
philosophical discussion about what configuration is in the first
place. Some people argue configuration is all information needed to
make a (sub)system work while others argue that a (sub)system has a
default behaviour that is not part of the (sub)system's configuration
as long as it is not changed or set explicitely. As far as I know,
this is currently best explained in the :with-defaults document.

Unfortunately, the world has not yet reached agreement on a common
definition what configuration really is and as long as this does not
happen, we will not have a final answer about questions such as "who
creates mandatory leafs". So what are our options?

a) Agree on a common definition what configuration is. This would
   solve many problems - but it might be hard to find agreement.

b) Accept 2-3 different definitions and be explicit what things mean
   according to systems following the different approaches. Not nice,
   lots of work, looks complicated (like the real world).

c) Ignore the differences and leave some details open to variations in
   implementation.

This last approach allows us to get started in a timely manner.  It
might cause additional work later down the road if this technology
gets widely used - but this is perhaps goodness because some of this
is going to be easier to understand with more implementation and usage
experience and perhaps we can have BCPs that describe how to best
practice documents what configuration really is or should be.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 18 Aug 2009 10:53:58 +0200

> practice documents what configuration really is or should be.

Well, it means that I would always write the model for network interface
with "mtu" declared as mandatory (because this configuration parameter
must be present in every valid configuration) but Phil would leave it as
optional, as he suggested. I think this is a problem.

My preference is clearly (a). The fact that one approach just presents a
diff against a system-assigned configuration can be accomodated in this
scenario.

Lada

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Tue, 18 Aug 2009 03:58:25 -0700

> diff against a system-assigned configuration can be accomodated in this

I agree with Lada's interpretation of mandatory.

Andy