Subject: [netmod] What is config?

From: Phil Shafer <[email-masked]>
Date: Wed, 14 Oct 2009 12:48:40 -0400

Andy Bierman writes:
>According to YANG, it is config.

Good point.  What NETCONF and YANG lack is a good definition of
what configuration is.  I can point of the issues with making a
leaf "config true" (like the save/restore issue) but lacking a real
definition, we will be asking WG modelers to "know it when they see
it", which will be difficult since many issues (like the save/restore
one) aren't immediately obvious in their impact.

So do we need (and can we) to agree on a definition of configuration
data that is both straight forward enough to read and accurate enough
to be useful?

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 14 Oct 2009 10:30:19 -0700

> data that is both straight forward enough to read and accurate enough

Hmmm...

Our problem is this dual-role leaf, that only
becomes persistent in the NV-storage if the client
requests it.  We agree this is a useful implementation
strategy and N/Y should support it.

An s-c leaf can potentially change value at every reboot,
so it is not persistent config.  We agree on that.

But the data-modeler writing YANG constraints has
no way to guess which of the dual roles of this leaf
to expect on an arbitrary server.

Clearly, we do not want to force the operators
to populate every leaf that is used in a constraint.
I hope.

Yet the must-ripple-effect in YANG is there -- it
can change every leaf to mandatory=true that it references.
Do we agree this doesn't work? Can it be fixed?

The current definition of config=true for the scope
of all XPath statements is useful and predicable.

I don't think a validation model based only
on the explicit commands is useful, and
it certainly is not predictable.

>  Phil

Andy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 14 Oct 2009 15:07:16 -0400

>strategy and N/Y should support it.

I disagree.  We've discussion the "twin leaf" strategy, where one
leaf is config true and one leaf is config false.   One represents
the user-requested behavior and one represents the real observed
behavior.  One leaf cannot be both config and operational
content.

>so it is not persistent config.  We agree on that.

I disagree.  Once an s-c leaf is set, it is normal configuration
data and will not change without express action.

>to populate every leaf that is used in a constraint.

Agreed.  The every leaf should not be forced to exist.

>Do we agree this doesn't work? Can it be fixed?

I suggested not allowing musts to reference s-c leafs.

But you are hijacking the thread to return to the other discussion,
where this thread was meant to investigate whether we could have a
useful definition of configuration data.

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 14 Oct 2009 21:30:10 +0200

> behavior.  One leaf cannot be both config and operational

This is matter of definition, which we don't have yet.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Wed, 14 Oct 2009 12:42:28 -0700

> behavior.  One leaf cannot be both config and operational

I mean 1 leaf with 2 roles, not 2 leafs.

> data and will not change without express action.

So is it treated as explicit config on the next reboot?
Where does it say that in the text?
Once the s-c leaf becomes part of running,
then it is saved to NV-store like a regular leaf?
Is it visible in a plain get-config reply?
It doesn't seem like a normal config leaf to me.

> useful definition of configuration data.

Configuration is defined by the operations that the
server supports for the data node.  We have left config-stmt
as a boolean, so we must think there are only 2 states
for every possible data node.  If config=false, the client
can never alter it.  Period.  Config=true means the client
and the server can alter the data node.  If there is any middle ground,
it is poorly described by system-creatable or any other YANG text.

If it is important to clarify this middle ground, then the
technology needs a lot more work, and then the specification
needs to capture it.

If Joel and Juergen think it is critical that we clarify
this operational state in the standard, then I have to
reluctantly agree with them.

Is it clear to everybody exactly how each YANG constraint combo
will behave for running or candidate, for every existing and
every conceivable database operation?  How do we even figure
it all out? Where is the line between server implementation
choices and standard behavior?  If we don't know, how is
anybody else going to know?

Andy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 14 Oct 2009 15:37:19 -0400

>This is matter of definition, which we don't have yet.

This much we do have.  A leaf is either "config true" or "config
false", there is no "config part-time".  A single leaf cannot
represent both config and operational values.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 14 Oct 2009 22:02:35 +0200 (CEST)

> So is it treated as explicit config on the next reboot?

Yes.

> Where does it say that in the text?

We can add something like:

  Once created by the server, the leaf is just like any other leaf in
  the data tree.

> then it is saved to NV-store like a regular leaf?

Yes.

> Is it visible in a plain get-config reply?

Yes.

> It doesn't seem like a normal config leaf to me.

It is a normal leaf, its just that the server may create it if the
client did not.

> and the server can alter the data node.

Config=true means the client can alter it.

If s-c is false, the server can never alter it.

If s-c is true, the server may *create* it, but not modify it later.

/martin

---

From: Phil Shafer <[email-masked]>
Date: Wed, 14 Oct 2009 15:45:24 -0400

>I mean 1 leaf with 2 roles, not 2 leafs.

I understood and was disagreeing with you.  A leaf is either
"config true" or "config false", not both.

>So is it treated as explicit config on the next reboot?

Yup.

>Where does it say that in the text?

It says:

   The server MUST NOT create the leaf if the leaf already exists or if
   "system-creatable" is "false".

Do we need to explicitly say that other that the given rules, it
behaves just like every other leaf?  It's config data because it's
"config true".

>then it is saved to NV-store like a regular leaf?

Yup.

>Is it visible in a plain get-config reply?

Yup.

>It doesn't seem like a normal config leaf to me.

It's a normal "config true" leaf, just one the
system can create.

>it is poorly described by system-creatable or any other YANG text.

There is no middle ground.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 14 Oct 2009 14:33:25 -0700

>   Once created by the server, the leaf is just like any other leaf in

 choice fubar {
    case a { // or container a
       leaf X {
          system-creatable true;
          type int32;
       }
       leaf Y {
          type string;
          mandatory true;
       }
    }
    leaf case-b { type string; }
 }

This has an odd effect on NP containers and choices.
Once the s-c leaf exists in running, then
it is possible that may trigger existence requirements
for sibling nodes within a case or within an NP container.

So what does the server do if a mandatory sibling leaf
that is s-c=false needs to be created (Y)?
It cannot create the leaf X in this case, because the
running config would not be valid anymore.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 14 Oct 2009 23:55:18 +0200 (CEST)

> running config would not be valid anymore.

Right.  It must not create something that invalidates running.  So
unless Y exists, the server MUST NOT create X.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 15 Oct 2009 08:42:00 +0200

> data that is both straight forward enough to read and accurate enough

See the start of the thread "Configuration Data versus Operational
State Data versus Statistics":

http://www.ietf.org/mail-archive/web/netmod/current/msg03850.html

/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: Thu, 15 Oct 2009 08:09:22 -0400

>http://www.ietf.org/mail-archive/web/netmod/current/msg03850.html

Apologies, I missed this thread.  Unless there are objections,
I'll add this to the arch draft.

Thanks,
 Phil

---

From: Kent Watsen <[email-masked]>
Date: Thu, 15 Oct 2009 12:29:51 -0700

It looks like a helpful addition to the arch draft, though I would leave out the "Implications" section since it is speculative...

Thanks,
Kent

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Phil Shafer
> Sent: Thursday, October 15, 2009 8:09 AM
> To: Juergen Schoenwaelder
> Cc: NETMOD Working Group
> Subject: Re: [netmod] What is config?
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: "tom.petch" <[email-masked]>
Date: Fri, 16 Oct 2009 18:00:12 +0200

I think that that discussion went down a rat hole - apologies
for my part in that - leaving the main issue of what constitutes
what in this tri-partite split unresolved.

So, no, I see no consensus to add that to any I-D.

What is config is an unresolved issue.

Tom Petch

----- Original Message -----
From: "Kent Watsen" <[email-masked]>
To: "Phil Shafer" <[email-masked]>; "Juergen Schoenwaelder"
<[email-masked]>
Cc: "NETMOD Working Group" <[email-masked]>
Sent: Thursday, October 15, 2009 9:29 PM
Subject: Re: [netmod] What is config?

>
> It looks like a helpful addition to the arch draft, though I would leave out
the "Implications" section since it is speculative...

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 16 Oct 2009 20:54:39 +0200

> What is config is an unresolved issue.

Can you be a bit more constructive and explain what is wrong with the
text so that we can fix it and make forward progress?

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 16 Oct 2009 12:39:21 -0700

> text so that we can fix it and make forward progress?

I am willing to leave this area of work
for the future, but a concern I have is
that description-stmts and constraints
are traditionally written to describe
what happens in the running system.

Nothing 'happens' in the config file.
It is not intuitive at all to think
about a data model object semantics this way.

At first it was not clear that s-c leafs are 'sticky' --
they stay in the config as soon as they are created and
do not change.  IMO, there is no value in a s-c clause,
just document the behavior wrt/candidate and that is enough.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 16 Oct 2009 21:59:50 +0200

> just document the behavior wrt/candidate and that is enough.

Are you in the wrong thread?

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 16 Oct 2009 13:29:45 -0700

> Are you in the wrong thread?

no -- system-creatable is part of the config definition.
So is default, mandatory, unique, etc.  All the scattered
rules combine to create some sort of architecture.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 16 Oct 2009 22:31:25 +0200

> rules combine to create some sort of architecture.

I still think you are in the wrong thread. This thread was supposed to
discuss the text for the architecture document.

/js

---

From: "tom.petch" <[email-masked]>
Date: Mon, 19 Oct 2009 16:17:47 +0200

Juergen

I think that Andy summarises this well,

> rules combine to create some sort of architecture.

and so we need to resolve the issues before we have text
for the architecture I-D.

Look at Joel and Randy on s-c, agreeing that the text has
more than one meaning (I don't know which is right - ironic that
you should say 
>   so that at least all active contributors read the
> sentences leading to the same interpretation of the words they have
> read. )
or the
question of the stickiness of s-c objects (I don't know if there
is consensus on that or not), or Phil,
in the finish-up thread, on defaults and what is in config, which
I understand and disagree with as the solution to a problem,
and that all over this weekend just gone.

My thinking is mostly with Andy and Lada, and not with
Phil and yourself.  I find the definition you give puts too much
into operational state, too little into config.  And the text you
put forward 7 weeks ago calls for upgrades to netconf, new
operations, new mandatory datastores, to create a three way
split instead of our current config and not-config.  You said it
was for discussion but I do not yet see that discussion happening.

So no, I am not ready to propose alternative text.

Tom Petch

----- Original Message -----
From: "Andy Bierman" <[email-masked]>
To: "Andy Bierman" <[email-masked]>; "tom.petch"
<[email-masked]>; "Kent Watsen" <[email-masked]>; "Phil Shafer"
<[email-masked]>; "NETMOD Working Group" <[email-masked]>
Sent: Friday, October 16, 2009 10:29 PM
Subject: Re: [netmod] What is config?