Subject: [netmod] assigned-by

From: Martin Bjorklund <[email-masked]>
Date: Tue, 02 Dec 2008 21:56:12 +0100 (CET)

Hi,

We have been talking several times about adding a statement
"assigned-by system" to the "leaf" statement.  I believe that the
chairs will send out a call for consenus to the list.

The idea is that if a leaf is marked as assigned-by system, then the
client MAY choose to not set a value for the leaf when its parent
instance is created.  In this case the system will assign a suitable
value for the leaf.

In Minneapolis the question was raised how this interacts with
'mandatory' and 'default', and also if the server MUST or MAY assign a
value.

Since we already have 'mandatory' which means that a leaf MUST exist
in a valid data store, it makes sense to use it also for this purpose:

  leaf foo {
      type string;
      mandatory true;
      assigned-by system;
  }

  leaf bar {
      type string;
      assigned-by system;
  }

With these definitions, if the client does not assign a value to
"foo", the server MUST assign a value, but if the client does not set
"bar", the server MAY assign a value.

I'm a bit worried that this interpretation is not ... obvious.

An alternative could be to go with one (MUST or MAY), and say that
"assigned-by system" and "mandatory true" must not be used at the same
time, but that might be too restrictive, and it adds a CLR.

As for 'default' and assigned-by system, with the interpretation
above, we could stick with the rules we have.  I.e. a 'default'
statement on "foo" would not be allowed (since "foo" is mandatory),
but it would be allowed in "bar" - if "bar" is not set by either the
client or server, the default value is used internally.

/martin

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 03 Dec 2008 09:38:26 +0100

Hi Martin,

an interesting question is what "system" means and whether the automatic
assignment may depend on other circumstances. Assigning unique list keys
is a relatively easy, but how about e.g., interface addresses: They may
be set manually by the manager, or assigned by "system" via DHCP or
router advertisements. In the latter case, the auto-assignment may or
may not happen depending on conditions that are external to the box.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 03 Dec 2008 09:48:47 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> router advertisements.

I don't think such an object would be defined as "assigned-by
system", since an address received by DHCP is dynamic and does not
modify the configuration.

If the leaf is "assigned-by system", the system fills in a valus in
the configuration, and from then it behaves just as if the user had
entered this value from the start.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 03 Dec 2008 10:18:53 +0100

> modify the configuration.

Do you mean that it becomes "config false" type of data in this case?
But the manager must also be able to set the address manually, so there
has to be a slot for it in the config datastore and it should IMO be
filled with the autoconfigured address when the dynamic assignment takes
place.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 3 Dec 2008 10:29:21 +0100

On Wed, Dec 03, 2008 at 10:18:53AM +0100, Ladislav Lhotka wrote:
 
> Do you mean that it becomes "config false" type of data in this
> case?  But the manager must also be able to set the address
> manually, so there has to be a slot for it in the config datastore
> and it should IMO be filled with the autoconfigured address when the
> dynamic assignment takes place.

An IP address assigned by DHCP is for me operational state, not
configuration state.

/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/>
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 03 Dec 2008 10:38:31 +0100

> An IP address assigned by DHCP is for me operational state, not

The manager must always be able to learn it (via NETCONF, I presume),
but also turn off DHCP and set it manually. So I wonder how the data
model can look like in order to accomodate both requirements.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "tom.petch" <[email-masked]>
Date: Wed, 3 Dec 2008 18:41:06 +0100

----- Original Message -----
From: "Martin Bjorklund" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, December 02, 2008 9:56 PM
Subject: [netmod] assigned-by

> 'mandatory' and 'default', and also if the server MUST or MAY assign a

And in previous discussions on this list, how it would interact with 'config'.
When you have drawn up 8-way charts and tried to assign meanings to the
different combinations, the message I got was that this is a nonsense.  You say
below that mandatory means it MUST exist and must not have a default.  Why?
seems like a nonsense to me.  It must exist and if no value is written, here is
a default instead.

And Juergen's post, that a DHCP assigned value was not config (but if I wrote in
the value I imagine he would agree that it was config) again says to me this is
a nonsense.

I do not know what you are trying to achieve with this metadata,
config/mandatory/assigned by/default, but it just seems confused, ill-thought
out, creating confusion where none need exist.  I would scrap the lot until I
saw a good case for anything in this area.

And I do see this, the interactions of this metadata, as a significant issue
whose resolution is long overdue.

Tom Petch

---

From: Phil Shafer <[email-masked]>
Date: Wed, 3 Dec 2008 14:43:09 -0500

"tom.petch" writes:
>You say

View the module as a contract between client and server, and these
properties as terms of that contract.

"mandatory true" means the client must make this leaf.
"default" means if the client does not make the leaf, there is
a value that the server will automatically use.

These are mutually exclusive.  If you have to make it, there's
not point in saying what happens if you don't.

>the value I imagine he would agree that it was config) again says to me this is

This example strengthens my view that config and operational
data are very different things.  The SNMP view of mixing them
into a simple hierarchy misses this (and other) cases.  Joining
config data with non-config data makes modeling harder than it
needs to be.

>saw a good case for anything in this area.

IMHO there are many existing use cases for the config, mandatory,
and default properties.  We use them (the JUNOS equivalents) every
day.

In all of JUNOS there is exactly one case where we would use
assigned-by (if we have it).  This is the case of assigning a uid
to a user, which needs to persist in future instantiations of a
particular user, but which we don't want to burden the CLI user
with the assignment of.  When you create a user, the next free/unused
uid is automatically assigned to the "uid" leaf.  We also match
the uid for the user if that user currently exists.

Given the small need for assigned-by, I'd happily postpone it
as future work (y2:assigned-by ;^).

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 03 Dec 2008 12:16:26 -0800

Phil Shafer wrote:
> ....
> ....

amen!

mixing config leafs and non-config nodes is a bad SNMP habit
that NETMOD should not embrace.

(IMO, a node with min-access=read-only is a different problem).

>  Phil

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 04 Dec 2008 10:41:10 +0100 (CET)

> and default properties.  We use them (the JUNOS equivalents) every

Same here.  We use them and our customers use them all the time.
IMO they are absolutely essential.

Just as one example, how would anyone know what's possible to send in
an edit-config if we simply removed the 'config' statement?

> assigned-by (if we have it).

The ipfix YANG module has 5 objects which would use it if we had it.
Currently they use the description clause:

      leaf observationPointId {
        description "If omitted, the Observation Point ID is assigned
          by the monitoring device.";
        type uint32;
      }

> as future work (y2:assigned-by ;^).

I can live with postponing this as well.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 04 Dec 2008 10:51:33 +0100

> whose resolution is long overdue.

I fully agree with your view. There are many cases when the same
configuration parameter may be, depending on circumstances, explicitly
configured, or supplied from data model default, vendor default or
network protocol.

Given that we don't even agree on what a configuration contains (are the
values that haven't been explicitly set by the manager there or not?), I
think it is hopeless to try to distinguish all these cases in the DML.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 04 Dec 2008 11:03:01 +0100

> that NETMOD should not embrace.

So should an IPv6 address on an interface be modeled as config or
non-config (operational parameter)? Should it depend e.g., on whether an
adjacent router sends router advertisements? Should a link-local address
be handled differently than a global one?

> (IMO, a node with min-access=read-only is a different problem).

Yes, a MTU parameter is essentially config but if it is hardwired in a
device, it should stay config but be declared as read-only.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 04 Dec 2008 11:34:13 +0100

> an edit-config if we simply removed the 'config' statement?

I think nobody suggests to remove this distinction. There are parameters
like byte counters that can never be config. However, those that can be,
at least sometimes, should be declared as config and allowed in
edit-config. However, the manager must be prepared that in some cases an
attempt to change a config parameter will be refused.

Perhaps a configuration parameter could carry an optional attribute
telling how it was set - explicitly (default choice), from a DM default,
vendor default or protocol.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 04 Dec 2008 11:48:10 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> I think nobody suggests to remove this distinction.

Sorry if I misundrestood, but Tom Petch wrote:

  I do not know what you are trying to achieve with this metadata,
  config/mandatory/assigned by/default, but it just seems confused,
  ill-thought out, creating confusion where none need exist.  I would
  scrap the lot

I thought "the lot" refered to "this metadata", which included
'config'.

> There are parameters

I agree with what Andy, Phil and others said that we should not mix
config and non-config in the same objects.  And this is of course
what's in the draft today - I don't think there's any confusion in the
draft about this.

For the ip address example you had, I would have a configuration which
is a choice between using dhcp and setting a static address.  Then a
separate non-config object would report the address.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 4 Dec 2008 12:13:50 +0100

On Thu, Dec 04, 2008 at 11:03:01AM +0100, Ladislav Lhotka wrote:
 
> non-config (operational parameter)?

On my Debian system, ifconfig or ip reports the operational state of
an interface including the assigned IP addresses. The configured IP
addresses are stored in a file (/etc/network/interfaces) and assigned
when the configuration file is loaded. In other words, you need to
model the operational state of an interface and the configuration
state of an interface; they are not the same thing. And yes, if all
you have is the output of ifconfig, you can't decide which IP address
is configuration state and which is not. So it requires efforts to
make this distinction on the device. Pushing this effort to the
manager (the way SNMP works) is not a solution since the manager has
no chance to figure this distinction out.

> Should it depend e.g., on whether an adjacent router sends router
> advertisements?

IP addresses obtained via router advertisements are operational state.

> Should a link-local address be handled differently than a global
> one?

The scope does not matter. If the address is assigned via static
configuration, it should be reported as part of configuration state.
If the address is automatically generated, then it should not be
reported as configuration state.

/js

PS: For some background, please consult RFC 3535 and in particular
    section 3 "Operator Requirements". Separation of configuration
    state from operational state was one of the operator's main
    concerns and part of the reason for having NETCONF.

---

From: Phil Shafer <[email-masked]>
Date: Thu, 4 Dec 2008 09:14:31 -0500

>think it is hopeless to try to distinguish all these cases in the DML.

Given that this problem has been solved multiple times in real world
products, I see no point in calling it hopeless.  The question is
can we find a workable compromise that gives us sufficient common
ground to allow clients and servers with differing views to
interoperate.

If the server forces defaults to exist and the client doesn't care,
they should be able to talk to each other.  If the server discards
explicit values and the client panics when it sees its value
"disappear", then they won't be able to work together.

I believe we can write rules that allow this sort of interaction
to occur between clients and servers, even when they differ on some
implementation points.

Sure, I'd rather everyone did it my way, but that's not going
to happen.  But we can leave sufficient flexibility to allow
differing viewpoints to interoperate.

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 04 Dec 2008 18:33:47 +0100

> I thought "the lot" refered to "this metadata", which included

Tom can probably interpret himself better than I, but my understanding was "the
whole lot".

> separate non-config object would report the address.

Assume the device is configured with DHCP and now the manager sends an
edit-config containing a static address. Should the device reject it as
invalid? I think it would be a bad idea. So it means the address is
still a configurable parameter.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 04 Dec 2008 18:34:53 +0100

> no chance to figure this distinction out.

Continuing the Linux example, we also have this nice /proc filesystem.
It contains operational data but in fact also something like the
"running" datastore - some of the parameters are writable. So I tend to
identify the configurable portion of the operational state with the
"running" datastore. They can be in two different places but then
probably some kind of synchronization is needed.

> The scope does not matter. If the address is assigned via static

What matters is how each parameter gets its value. Link-local addresses
are normally set to an EUI-64 based address. Is this assigned-by system,
or operational state? Then how about the global address whose left half
is obtained via RA (=operational state?) and right half initialized
again using EUI-64 (=assigned-by system?)

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 4 Dec 2008 21:18:27 +0100

On Thu, Dec 04, 2008 at 06:34:53PM +0100, Ladislav Lhotka wrote:
 
> What matters is how each parameter gets its value. Link-local
> addresses are normally set to an EUI-64 based address. Is this
> assigned-by system, or operational state?

I consider such an address operational state.

> Then how about the global address whose left half is obtained via RA
> (=operational state?) and right half initialized again using EUI-64
> (=assigned-by system?)

I consider this operational state as well.

/js