Subject: [netmod] Issue: add 'assigned-by system'

From: David Partain <[email-masked]>
Date: Tue, 1 Sep 2009 09:59:58 +0200

Hi,

There has been significant debate about whether to reopen the question of 
having 'assigned-by system'.  See this mail thread - 
http://www.ietf.org/mail-archive/web/netmod/current/msg01622.html

The discussion has been in the "agent-default -- new 3rd state" thread (and 
probably elsewhere).

Martin wrote in the message referenced above: "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."

A number of people have said they think this should be reopened and that it 
would be valuable, particularly in dealing with misunderstandings around the 
meaning of default.  Others have questioned doing so at this time.

Clearly, if we think this is a serious enough problem that it MUST be fixed 
for good interoperability, then we should do so.  I'd like to resolve this 
ASAP.  Please voice your opinion by close of business tomorrow (Wednesday) 
about whether you in principle think we should add 'assigned-by system' 
(pending concrete text, of course).

If the rough consensus appears to be to add it, I'll ask Martin to submit a 
proposal with text.  We'll then discuss based on that text.

Thanks.

David

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 01 Sep 2009 10:32:34 +0200 (CEST)

Hi,

> (pending concrete text, of course).

I have changed my mind.  I think we should include this statement.
The reason for this is that I believe that with this statement, the
current confusion about when the server is allowed to create config
instances can be sorted out.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 1 Sep 2009 11:36:47 +0200

> proposal with text.  We'll then discuss based on that text.

I think a statement like assigned-by system help to achieve clarity
and should be added.

/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: Andy Bierman <[email-masked]>
Date: Tue, 01 Sep 2009 04:51:53 -0700

> proposal with text.  We'll then discuss based on that text.

I have not yet seen a complete and convincing problem statement,
let alone a complete and convincing solution proposal.

I expect the NETCONF protocol to be deterministic for all protocol
operations on a particular YANG data model.  Any solution in
which the descriptive annotations in YANG are used as a substitute
for retrieval of definitive values (using protocol operations)
is unacceptable.

Not sure what assigned-by system really does for the data modeler.
Can somebody explain that to me again?  What MUST behavior is
associated with usage of assigned-by system? What about
the other enum (whatever it is called)?

> David

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 01 Sep 2009 14:25:47 +0200 (CEST)

> let alone a complete and convincing solution proposal.

I think there are two benefits:

  1)  it will be clear when the client can expect the server to create
      instances, (see the recent discussion about mandatory)

  2)  it gives the data modeler another formal tool so that his data
      model can be more precise (there are a couple of examples in the
      ipfix module where this could be used; the user's "uid" is the
      other example)

> the other enum (whatever it is called)?

If the WG believes that something like this is useful, then I will
write down one proposal which we then can discuss.  I welcome anyone
who wants to help with this text to let me know!

/martin

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 01 Sep 2009 09:19:56 -0400

I consider this one of several possible paths to an acceptable solution.
I think it is helpful information to the management system to know 
whether the managed device may choose to unilaterally set the value.

For this to solve the related issues about what is a default and when 
are such values returned, we need to be explicit both that
a) such value setting is not a default
b) that system shall not behave as if there is a well-defined value for 
the item without reporting it.

We will also need to make sure that the text is clear as to what would 
happen in the equivalent of the default-by-reference case.

So, I think this is a useful change, and can be part of a larger 
solution to the ongoing debate.

As a minor matter, I would not call it "assign-by system".  That tends 
to make the reader thing that the managing client can not assign to it, 
when they can (it is config data.)
Some other terminology would be a good idea.

Yours,
Joel

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

---

From: Andy Bierman <[email-masked]>
Date: Tue, 01 Sep 2009 06:30:12 -0700

>       instances, (see the recent discussion about mandatory)

so there will be normative text saying
a server MUST NOT create an instance
if it is an 'assigned-by user' type of leaf?

this would be useful to have.

The assigned-by statement has no affect on retrieval
operations whatsoever, correct?  that is also
important.  A server-created leaf instance must be
just a plain old leaf instance, and not special
in any way.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 01 Sep 2009 06:39:12 -0700

> happen in the equivalent of the default-by-reference case.

I think the WG is going in the wrong direction
by trying to create more ways to replace simple
data retrieval with algorithmic synthesis of that data.

I will never trust server vendors to put nearly as much
effort into their documentation as they put into their code.
I know what goes on in the kitchen...

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 01 Sep 2009 15:57:14 +0200 (CEST)

> if it is an 'assigned-by user' type of leaf?

Yes, that is the idea.

Where "create" means "create when the parent node is created" (sort
of).  I.e. it would still be ok for a device to start with a preloaded
data store, or an "initial config".

One way of viewing this is that the server is free to create such
leafs even though the client has the lock on the data store.

> just a plain old leaf instance, and not special

Yes, that is my view as well.

/martin

---

From: "tom.petch" <[email-masked]>
Date: Tue, 1 Sep 2009 17:48:24 +0200

----- Original Message ----- 
From: "David Partain" <[email-masked]>
Sent: Tuesday, September 01, 2009 9:59 AM
> will assign a suitable value for the leaf."

I am unclear.  I take it this is created in the data tree but is it as 
config or operational state (which affects how it can be retrieved)
and is an instance being created or is this one of those thingies
which seem neither dead nor alive?  This harks back to Phil
differentiating uid from mtu and  Joel not seeing the difference. 
I am afraid I have yet to see the difference:-(  Martin said
'So "if an instance exists because the server created it" then it *is*
config. '  Um, leaves me none the wiser.

And what's the parent instance got to do with it?  It sounds like
an assumption is built in there (and not the usual case or
non-presence container issues) that I am missing.

Tom Petch

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 01 Sep 2009 22:04:11 +0200 (CEST)

"tom.petch" <[email-masked]> wrote:
> which seem neither dead nor alive?

No magic is supposed to happen here.  If the defintion is:

   leaf uid {
      type int32;
      config true;
      assigned-by system;
   }

I hope it is obvious that we're talking about configuration data?

'assigned-by' and 'config false' cannot be used together -- a client
can never create config false data (directly).

> This harks back to Phil

Extending the example a bit:

  list user {
    ...
    leaf uid {
       ...
       assigned-by system;
    }
  }

We need to make it clear that the 'uid' is not spontanesoulsy created
for non-existing users.  The 'uid' leaf will be created by the system
when a new user is created (its "parent" -- note this is not a term we
have used, and we will have to find the right language to describe
this).

Another example:

   container foo {
     presence "...";
     leaf bar {
       ...
       assigned-by system;
     }
   }

/foo/bar is created by the system when the client creates /foo.

/martin

---

From: David Partain <[email-masked]>
Date: Wed, 2 Sep 2009 09:59:18 +0200

Hi,

On Tuesday 01 September 2009 13.51.53 Andy Bierman wrote:
> > David Partain wrote:
> > If the rough consensus appears to be to add it, I'll ask Martin to submit
> > a proposal with text.  We'll then discuss based on that text.
>

The idea was (1) to find out if we should re-open the question and (2) 
_thereafter_ ask Martin to propose a solution to decide on.  I think that's 
what I wrote above.

Cheers,

David

---

From: David Partain <[email-masked]>
Date: Wed, 2 Sep 2009 10:02:12 +0200

Hi,

I think there's been enough mail stating that a proposal would be good.  
Martin, could you please put together some text detailing "assigned-by 
system" (or some other name that is better -- suggestions welcome)?  

Once the text is on the table, y'all can all have at it.

Cheers,

David

---

From: "tom.petch" <[email-masked]>
Date: Wed, 2 Sep 2009 11:30:32 +0200

---- Original Message -----
From: "Martin Bjorklund" <[email-masked]>
Sent: Tuesday, September 01, 2009 10:04 PM

> I hope it is obvious that we're talking about configuration data?

Yes:-)

> have used, and we will have to find the right language to describe

Right (why do I often need a second lesson from you to understand:-(

So is this 'system will assign' a MAY, MUST, SHOULD?

And is it immediate ancestor only?  I am thinking of the complex
nested stack one gets with physical and logical interfaces, with the
server allocating VCs at the bottom of the stack.

Last time around, we spent time discussing the interaction with
default and mandatory, but I see these two as incompatible
with assigned-by-system
if default means a value that the server MUST use and mandatory
means the client MUST supply (disagree with these two, but suspect
that these are the current view).

Tom Petch

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 02 Sep 2009 13:16:12 +0200 (CEST)

> So is this 'system will assign' a MAY, MUST, SHOULD?

Open question.  See below.

> server allocating VCs at the bottom of the stack.

Yes, ancestor only (modulo NP-containers).

> that these are the current view).

(See also
http://www.ietf.org/mail-archive/web/netmod/current/msg01622.html) 

Here are some alternatives:

  A.  Keep the current text about mandatory, and allow the combination
      assigned-by system and mandatory true.  The combination then
      means that the server MUST assign a value if the client doesn't.
      If assigned-by system mandatory is false, the server MAY assign a value.

      In this case, default would be ok if mandatory is false.  If the
      server did not assign a value the default applies.

  B.  Change mandatory to mean that the client MUST set it.  This
      rules out the combination assigned-by system and mandatory true.

    B.1  B +  assigned-by system means MUST assign
         This rules out the combination assigned-by system and default
          
    B.2  B +  assigned-by system means MAY assign
         The combination assigned-by system and default would be ok.

A gives most flexibility, but is also more error-prone.  B.1 seems to
be the most straight forward solution if we don't want to do A.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 02 Sep 2009 14:16:36 +0200

Martin Bjorklund píše v St 02. 09. 2009 v 13:44 +0200:
> Ladislav Lhotka <[email-masked]> wrote:
> > Martin Bjorklund píše v St 02. 09. 2009 v 13:16 +0200:
> > I want to do A. Why is it error-prone?
> 
> It adds complexity, and the interactions may be subtle.

IMO, it is exactly the case A where interactions are minimal or none -
'mandatory' and 'default' address static configurations whereas
'assigned-by' addresses workflow. In particular, 'assigned-by' is
irrelevant for the validation of a configuration.

Lada

> 
> This said, I prefer A as well.
> 
> 
> 
> /martin
-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: WashamFan <[email-masked]>
Date: Wed, 02 Sep 2009 22:11:35 +0800

>       server did not assign a value the default applies.

I prefer A, except the last sentence. I'd like, rule out the combination
assigned-by system and default. I.e., unless the client explicit set
it, the default value MUST be used.

washam

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 02 Sep 2009 13:40:06 +0200

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 02 Sep 2009 10:37:41 -0400

I was going to object to the combination of mandatory and assigned-by 
system.  However, the more I think about it, I can live with it.
BUT...
If we allow that combination, then we need to be very clear that a 
mandatory node that is not marked "assigned-by system" really needs to 
be provided by the client.

I think I agree with the second part of A, but the wording keeps getting 
me crossed up.  I believe what you are saying there is that if a not is 
"assigned-by system" and is NOT mandatory (mandatory false or 
unspecified, which equals false), then the system may create a value.

The only point to clarify then is that if a node is not, has a default, 
and has assigned-by system, then if the system is going to use any value 
other than the default, it needs to consider that node to exist, and to 
return it when the configuration is requested.

I believe that specifying things this way will get out of my persistent 
confusion about what Lada is asking for, as I think this would allow 
representing the cases he has tried to describe.

However, can I repeat my request to change the term.
I realize that "assigned-by system" is what was proposed a long time 
ago.  However, I think it creates some confusion.
Could we use "system-assignable {true | false}"?

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 02 Sep 2009 11:01:08 -0400

(Resending, to fix at least some of the typos.)

I think I agree with the second part of A, but the wording keeps getting
me crossed up.  I believe what you are saying there is that if a node is
"assigned-by system" and is NOT mandatory (mandatory false or
unspecified, which equals false), then the system may create a value.

The only point to clarify then is that if a node is not mandatory, has a 
default, and has assigned-by system, then if the system is going to use 
any value other than the default, it needs to consider that node to 
exist, and to return it when the configuration is requested.

Yours,
Joel

---

From: Jon Saperia <[email-masked]>
Date: Wed, 2 Sep 2009 11:22:28 -0400

Joel, I would want to know for sure that it was or was not assigned by  
the system which in my mind is separate from its status as mandatory.

/jon
On Sep 2, 2009, at 10:37 AM, Joel M. Halpern wrote:

> I was going to object to the combination of mandatory and assigned- 
> by system.  However, the more I think about it, I can live with it.
> BUT...
> mandatory node that is not marked "assigned-by system" really needs  
> to be provided by the client.
>
> I think I agree with the second part of A, but the wording keeps  
> getting me crossed up.  I believe what you are saying there is that  
> if a not is "assigned-by system" and is NOT mandatory (mandatory  
> false or unspecified, which equals false), then the system may  
> create a value.
>
> The only point to clarify then is that if a node is not, has a  
> default, and has assigned-by system, then if the system is going to  
> use any value other than the default, it needs to consider that node  
> to exist, and to return it when the configuration is requested.
>
> I believe that specifying things this way will get out of my  
> persistent confusion about what Lada is asking for, as I think this  
> would allow representing the cases he has tried to describe.
>

---

From: Phil Shafer <[email-masked]>
Date: Wed, 2 Sep 2009 11:29:37 -0400

>I want to do A. Why is it error-prone?

It adds complexity to "mandatory" (a common statement)
for "assigned-by system" (a very rare statement).  The rarity of
ABS means that code will be written that only tests mandatory without
caring about ABS.  So this will be a source of coding errors.

More importantly, it means you need to understand a rare
concept in order to fully grok a common one.

I vote for "MAY assign", since that's the simplest, most
flexible option.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 02 Sep 2009 13:44:48 +0200 (CEST)

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 02 Sep 2009 20:53:26 +0200

> for "assigned-by system" (a very rare statement).  The rarity of

Why does it add complexity? IMO "mandatory" means as before  that a
configuration is valid only if this value is present (modulo conditions
on ancestor nodes), no matter who set it.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 02 Sep 2009 21:56:17 +0200 (CEST)

> be provided by the client.

I think we need to make this very clear regardless of which option we
choose.  I.e. if a node is not marked as 'assignable-by system', it
MUST NOT be created by the server.

> unspecified, which equals false), then the system may create a value.

Yes.

> Could we use "system-assignable {true | false}"?

Fine with me.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 02 Sep 2009 22:03:11 +0200

> MUST NOT be created by the server.

So it means it mustn't be e.g. a mandatory top-level leaf, if we assume
that the server starts with a valid configuration, right?

Lada
 
-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Thu, 03 Sep 2009 13:25:32 -0700

> This said, I prefer A as well.

I prefer (A).
The wording should be clarified to say that the
server MUST set the value in a valid configuration
if mandatory=true, or generate the appropriate <rpc-error>.
You can't force the server to provide a value every time.
Top-level mandatory nodes are still unsafe.

Andy