Subject: Re: [netmod] various defaults discussions

From: Gerhard Muenz <[email-masked]>
Date: Thu, 28 Aug 2008 10:02:55 +0200

Dear all,

I've seen the following table and the corresponding discussion about
created-by.

>    default | mandatory | cr-by |  rule
>    --------+-----------+-------+-------------------------
>     no     |   false   |  user |  node MAY be created by user (a)
>    --------+-----------+-------+-------------------------
>     no     |   false   |  sys  |  node MUST be created by system (b)
>    --------+-----------+-------+-------------------------
>     no     |   true    |  user |  node MUST be created by user
>    --------+-----------+-------+-------------------------
>     no     |   true    |  sys  |  invalid YANG
>    --------+-----------+-------+-------------------------
>     yes    |   false   |  user |  node MAY be created by user (c)
>    --------+-----------+-------+-------------------------
>     yes    |   false   |  sys  |  node MUST be created by system (d)
>    --------+-----------+-------+-------------------------
>     yes    |   true    |  user |  invalid YANG
>    --------+-----------+-------+-------------------------
>     yes    |   true    |  sys  |  invalid YANG
>    --------+-----------+-------+-------------------------

I do not really understand the meaning of created-by. Maybe you are
discussing the problem in a way that goes beyond what we would like to
do in IPFIX.

Here is my point of view:

We have the mandatory statement. In a leaf, the node must exist in a
valid configuration if mandatory is true. In this case, we have two
options: either the manager provides a value, or the agent chooses an
appropriate one.

Note that 7.6.4 of the YANG draft does not specify who is to supply a
mandatory value. Probably everybody thinks of the manager. However, the
draft only says that the node must exist "in a valid configuration".

In IPFIX, we want to force the manager to provide a mandatory value in
some cases. In other cases, we want to give the manager to opportunity
to provide a mandatory value, yet if he does not want to, the device
chooses an appropriate value. So, it would be nice to have two types of
mandatory:

- mandatory nodes which must be set by the manager
- mandatory nodes which may be set by the manager. If not, they are set
by the agent.

If mandatory is false, the data is optionally provided by the manager.
The device will not provide any values. However, it will use a default
value if specified in the YANG module.

A final comment: agent-supplied values for mandatory nodes should not be
seen as agent-supplied default values. In our case, these values are
sometimes dynamically assigned, for example in the case of identifiers.
"Default" sounds like a static value.

Regards,
Gerhard

-- 
Dipl.-Ing. Gerhard Münz
Computer Networks and Internet
Wilhelm Schickard Institute for Computer Science
University of Tuebingen
Sand 13 (Room B309), D-72076 Tuebingen, Germany
Phone:  +49 7071 29-70534       Fax: +49 7071 29-5220
E-mail: [email-masked]
WWW:    http://net.informatik.uni-tuebingen.de/~muenz

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

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 28 Aug 2008 13:33:56 +0200 (CEST)

Hi,

> - mandatory nodes which may be set by the manager. If not, they are set

That is what created-by gives you.

> If mandatory is false, the data is optionally provided by the

There are some interaction between created-by and mandatory, and it is
not clear to me which combination(s) make sense.

Maybe we should allow both mandatory true and false with created-by
system:

    default | mandatory | cr-by |  rule
    --------+-----------+-------+-------------------------
     no     |   false   |  sys  |  node MUST be created by system
            |           |       |  if not created by user
    --------+-----------+-------+-------------------------
     no     |   true    |  sys  |  node MUST be created by system
            |           |       |  if not created by user
    --------+-----------+-------+-------------------------

Consider this example:

  list x {
    key id;
    leaf id { type int32; }
    leaf y {
      type int32;
      created-by system;
    }
  }

If a client sends an edit-config with:

  <x>
    <id>1</id>
  </x>

The server will create y and give it a value, say 42.

Now, what happens if the client deletes /x/y?  Will it get
auto-recreated?   (intuitively it seems weird if it is)

What happens if the client deletes /x and then recreates /x?
(intuitively it seems y should be auto-created as well.  but then the
question is why it gets auto-recreated in this case but not in the
case above).

> seen as agent-supplied default values.

I fully agree.  They should be reported even if with-defaults is
false.

/martin

---

From: Gerhard Muenz <[email-masked]>
Date: Thu, 28 Aug 2008 13:48:17 +0200

Hi,

> That is what created-by gives you.

Hm. Then "created-by system" is a misleading term because it is only
created by the system if not provided by the manager.

>     default | mandatory | cr-by |  rule

Do you mean "MUST NOT" in the first case?

>       created-by system;

Does created-by system imply mandatory=true?

I'm not sure if created-by system should be mixed with optional nodes.
It is confusing because the node will always exist, i.e. it is not
optional in the sense that it may not exist in a valid configuration.

> question is why it gets auto-recreated in this case but not in the

You do not have this problem if created-by system is restricted to
mandatory nodes. But again, "created-by system" sounds strange.

Gerhard

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 28 Aug 2008 14:05:02 +0200 (CEST)

> created by the system if not provided by the manager.

created-by-if-not-created-by-the-other-part system;

seems a bit awkward :)

> Do you mean "MUST NOT" in the first case?

No I mean that the value of mandatory doesn't really matter when
created-by is system.  The effect is the same when the instance is
initially created.

> optional in the sense that it may not exist in a valid configuration.

That's what my example below tried to illustrate.  If you have the
view that created-by system implies mandatory true, then if a client
deletes 'y' w/o recreating it won't be valid (or it should get
auto-created).  If created-by system works with mandatory false, then
it would be just an initial value provided by the system, which a
client later can delete.

> mandatory nodes.

So assuming we restrict created-by system to mandatory true, will /x/y
get auto-recreated in the first case above?

/martin

---

From: Gerhard Muenz <[email-masked]>
Date: Thu, 28 Aug 2008 14:23:15 +0200

> created-by-if-not-created-by-the-other-part system;

BTW: what does "created-by user" mean? Or is system the only valid
parameter for created by?

We could call it:
auto-configurable true/false;

> auto-created).  

Yes.

> If created-by system works with mandatory false, then

Maybe it makes sense. Yet, we do not have such a use-case in IPFIX.

> get auto-recreated in the first case above?

Yes. Remove means that the manager is not interested any more in setting
a specific value. So, it is up to the agent to assign a new one - or
keep using the old one.

Gerhard

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 28 Aug 2008 15:11:55 +0200

See below:

> question is why it gets auto-recreated in this case but not in the
BALAZS: I would argue that created-by system takes effect only when the containing 
container/list is created.
> I fully agree.  They should be reported even if with-defaults is
BALAZS: So once the system created "y" it behaves just as if it was set by the manager?

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: "David Harrington" <[email-masked]>
Date: Thu, 28 Aug 2008 09:29:01 -0400

Hi,

As co-chair I have a request.

Can we split this "various" thread into separate topics? That will
make it much easier for the chairs to determine when consensus has
been achieved on specific points. 

Thanks,
David Harrington
[email-masked]
[email-masked]
[email-masked]