Subject: [netmod] finish up

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

Hi,

IMO, there is no consensus on system-creatable nodes.
Since the WG is already way behind schedule,
I propose that the YANG spec be frozen at -07
and no standardization of s-c leafs be done
at this time.

Let's focus only on errors in the -07 text,
so that a final WGLC can be held
and the document set can be forwarded
to the IESG this year.

Andy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 14 Oct 2009 12:25:50 -0400

Unfortunately, I believe that the problem, and the inconsistency in 
behavior, that are described in the discussion of system-createable are 
just as ambiguous (if not more so) if we do not define the statement. 
So I think we need to figure out how we want the system to work.
Once we agree on that, I think we can then quickly decide what to do 
with the s-c statement.  (For myself, the mere fact that it helps in 
elucidating the issues suggests that it is a very useful statement for 
the data modeler.)

Yours,
Joel

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

---

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

>IMO, there is no consensus on system-creatable nodes.

Perhaps we should call for a concensus before declaring one.

WG chairs, would this be possible?

Thanks,
 Phil

---

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

> elucidating the issues suggests that it is a very useful statement for 

+1. Also, it would be quite useful to gain some practical experience
with different implementation of YANG to see whether it is a real
problem.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Wed, 14 Oct 2009 09:44:23 -0700

Joel M. Halpern wrote:
> just as ambiguous (if not more so) if we do not define the statement. So
> I think we need to figure out how we want the system to work.

I am tired of being told that every legal YANG
example I come up with is not config.
According to YANG, it is config.

What do you propose to do about YANG constraints
that reference s-c nodes?

Do you think the operator MUST provide a value for
every leaf that is referenced in a YANG constraint?

Lada seems to suggest the server should just ignore a constraint
if any s-c leafs are involved.  Do you think this is useful?

Do you think the big-feature example is invalid?
That it is illegal for a YANG constraint to refer
to the operational value (i.e., don't care if
server or client provided)  or do you think the constraints
refer to only client-provided values?
If so, how is the YANG data modeler supposed to know
which leafs the operator is going to want to set,
and which ones it wants the dynamic defaults?

Do you understand that offline validation is
just as possible as before, if the server reports
all leafs?  That if the client validates a config
based on explicit-filtered retrieval, this is altering
the device data-set, so validation is broken before it starts?

I don't see any consensus on the problem,
the architecture, or the solution.
So let's just leave it to the description-stmt
to convey system-creatable details.

Andy

---

From: David Kessens <[email-masked]>
Date: Wed, 14 Oct 2009 16:26:52 -0700

Phil, Andy,

> WG chairs, would this be possible?

With all due respect, I don't see any basis for doing a consensus call
when it is entirely obvious that there is at best an extremely rough
consensus.

We need to see a serious and genuine effort from *all* parties
involved to find a solution. Making statements about a perceived
existing or non-existing consensus is not a very constructive way to
get to the point where we reach progress on this or other open issues.

To say it in another way, do either of you have proposals for a
solution ?

David Kessens
---

---

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

> To say it in another way, do either of you have proposals for a

I think solution proposals have been suggested.
One obvious solution -- stick with the description-stmt
for these tiny 1-in-a-million corner-cases instead
of wasting months or years trying to create machine-readable
clauses for every conceivable detail.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 15 Oct 2009 08:38:57 +0200 (CEST)

> One obvious solution -- stick with the description-stmt

Several people have pointed out (several times) that not doing
anything is what led to the major confusion about mandatory and
if/when/how/why servers were allowed to create config data.

> clauses for every conceivable detail.

And, repeating myself, the biggest value of having s-c is *not* that
we want machine-readable clauses for every conceivable detail, but
that we sort out the confusion I refered to above.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 15 Oct 2009 16:30:11 +0200

> if/when/how/why servers were allowed to create config data.

Personally, I can accept that the server implementations may make
configuration changes on its own provided such changes are
1. not hidden from the client
2. subject to all contraints of the data model

Actually, even if there are some rules like s-c constraining server
behaviour, would they cover actions of an "embedded client" running on
the server host? If not, the server rules would be pretty lame.

As for "mandatory", I am happy with the current meaning: such a leaf
must be present in every valid configuration.

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

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 15 Oct 2009 17:08:58 +0200 (CEST)

> 2. subject to all contraints of the data model

I'm not sure what 1. means.

So a client can never be sure that what he did actually is there in
the data store.  All edit-config will have to be followed by a
complete get-config, even if the client has a lock, if the client
wants to be sure that it is in synch?

> the server host?

An "embedded client" is no different from a "remote client".  It
follows the same rules as other clients.

When we say that the server may create data, it does so as part of the
processing of a NETCONF request (<commit> or <edit-config>).

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 15 Oct 2009 09:32:08 -0700

> 2. subject to all contraints of the data model

I agree with Lada.
I like the -07 spec better than the system-creatable solution proposal.
The description-stmt can specify the 1-in-a-million
uses of system-creatable=true.

The s-c leaf is too fragile and different.
It is invisible in the candidate the first time,
and then it just shows up in running, and becomes
a normal leaf after that (except that it cannot
be part of any YANG constraint, so it is not normal at all).

And Ken pointed out several machine-readable properties
(some done now as extensions), all of which are way more
more interesting than this system-creatable corner-case.

I prefer to finish YANG 1.0 and leave some work for later.
As it is, YANG will be at least a year late, and
that is starting to become a concern.

No programming or data modeling language ever written has
been perfect or complete at version 1.0.  You didn't
think YANG would be the first exception, did you?

A standard contains proven techniques that have WG consensus.
I don't see either in this case.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 15 Oct 2009 19:18:26 +0200

> I'm not sure what 1. means.

That it appears in the affected configuration, i.e. isn't treated as
another class of vendor-specific default by the device.
 
> wants to be sure that it is in synch?

For a human operator, such changes can happen in other ways, for
instance in the manager software before it is sent to the device. It
needn't always be bad thing - automatic uids, password encryption etc.
An implementation tampering with configurations in non-intuitive ways
will be hated by users and rejected. But IMO it's not a data modelling
issue.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Phil Shafer <[email-masked]>
Date: Thu, 15 Oct 2009 13:57:49 -0400

>To say it in another way, do either of you have proposals for a

There are two distinct proposals on the table:

(a) add the text from Martin about s-c leafs
(b) delay the issue until post-YANG 1.0

My request for a call comes from my inability to understand which
side of the issue folks are on.  On the conf call, there seems
overwhelming support for adding s-c leafs.  Does that support still
exist?

I see the case of s-c leafs as a real one, but a very rare one.
I'm not sure it's worth including in the draft.

One major concern is that an s-c leaf will technically break the
semantics of locking, in that a lock held during a commit-config
operation that triggers the creation of s-c leaf means that the
database is changing while the session has it locked.  But one can
view this as an implicit change performed on behalf of the user
holding the lock, so it may be viewed as _not_ a violation of
locking.

In any case, having this scenario documented in a first-class
statement instead of in the description string seems like a Good
Thing.  But there's a long list of other Good Things we can add,
and I'm not sure this one is a clear "must have".

So I'd rate myself "+1/4" on s-c leafs.  Where do others stand?

If we don't add s-c, do we need to stay something in the draft (or
the arch draft) about how/when/why the system can create leafs and
what well-mannered devices need to do about it (refreshing config
after edit-config)?

Thanks,
 Phil

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 15 Oct 2009 14:22:26 -0400

I think the s-c is a good thing, and is helpful.
Among other things, it is actually ahrd to describe the problem without s-c.

And I think that the base protocol document has to talk clearly about 
the problem, and what is permitted or required.  At the moment, 
different devices can behave differently, in ways that will prevent 
interoperability.  And different people still seem to understand the 
words differently.

Yours,
Joel

---

From: Andy Bierman <[email-masked]>
Date: Thu, 15 Oct 2009 11:48:15 -0700

> interoperability.  And different people still seem to understand the

I do not see the value of a machine-readable statement
to tell the client that the server is going to do
a rare thing that doesn't actually affect the client
at all, otherwise the client would have set that
config explicitly.

I think the behavior should be documented somewhere,
so it is clear that a client MUST be able to deal
with the server adding valid config nodes to running
as candidate is being integrated via <commit>,
or running is being altered via copy-config
or edit-config.

The only hole in mandatory=true I really cared about
was already filled (/rpc/input).  I can't think of a reason
why I would care if the server picked a valid value for
some leaf in the configuration database.

The description-stmt can specify if, and how, system-created
values are managed for that specific leaf.

Mandatory=true means it is the client's responsibility
to make sure the node is filled in.  If the client
doesn't provide an explicit value, the commit may fail.
It is possible for the operator/client to read the description
statements and make this decision on a per-data-model basis.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 15 Oct 2009 12:00:01 -0700

> interoperability.  And different people still seem to understand the

The thing that really changed my mind was looking at code,
and thinking from the central stack POV.

The stack would have to do a lot of annoying work
to prevent an individual server instrumentation
callback function from creating a leaf, either
during the edit-config or commit PDU processing.

The stack trusts that the instrumentation knows
how to manage its own portion of the conceptual XML tree.
The instrumentation has been written to a specification,
which includes description-stmts.

Martin also pointed out a long time ago:
Why would you code your client to skip mandatory leafs?
Of course you are going to write the code so
that every mandatory leaf is attempted.

I'm not convinced we have a real problem with mandatory at all.

Andy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 15 Oct 2009 15:05:44 -0400

If I assume your requirements from your other message are documented, 
then I would agree that we don't have a problem.
Unfortunately, that does not match what the current docs say.

And your text about what mandatory means and Lada's word choice do not 
actually match, except in the presence of undocumented assumptions.

Yours,
Joel

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 15 Oct 2009 21:27:49 +0200

> actually match, except in the presence of undocumented assumptions.

To avoid any confusion, I support the formulation in Sec. 7.6.4 of -07
and don't see any problem with it.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 15 Oct 2009 21:44:35 +0200

> So I'd rate myself "+1/4" on s-c leafs.  Where do others stand?

My recollection is that we did not agree what defaults are. And one
_part_ of the discussion was around s-c leafs - so we came up with a
proposal to formalize this. Now such a proposal is on the table and it
seems not all people agree to it and it seems some people prefer to
defer this issues post 1.0 so we don't have to work it out. Going back
to the original discussion, does it mean we now agree what defaults
are? Do we agree what config is?

I am fine with not adding stuff to the language - or even removing
stuff. But I like to see some agreement about basic concepts to be
well documented so that at least all active contributors read the
sentences leading to the same interpretation of the words they have
read.

/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: Thu, 15 Oct 2009 13:24:07 -0700

> sentences leading to the same interpretation of the words they have

Before several comments from lots of people, it wasn't clear
how s-c really affected everything already in place.
Phil and Martin made me realize the client doesn't need
to worry about s-c leafs creating during the commit,
and that is not harmful to the client at all.

Static defaults are handled rather well in YANG.
There is flexibility with refine and deviation
to specify the default, even for a particular session.

Algorithmic defaults should be left to the future,
such as XPath expressions to define the algorithm.

System created defaults which cannot be documented
with default-stmt, refine-stmt, or deviation-stmt,
or a TBD dynamic-default-stmt, should be quite rare.
These s-c leafs that cannot pick a value until
the commit should be allowed, but we don't need
any special rules because after they appear in running,
they are normal leafs.

I am willing to say all YANG config constraints apply
to the visible config=true nodes + YANG defaults,
and leave constraints applied to the operational state
as future work.  That means the operator must make sure
all the nodes referenced in must/when expressions
exist in the configuration, or contain the default value.

Andy

---

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

---- Original Message ----- 
From: "Juergen Schoenwaelder" [email-masked]
Sent: Thursday, October 15, 2009 9:44 PM

> are? Do we agree what config is?

My take is no and no, the latter, what config is, being the major stumbling
block.

Tom Petch

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 17 Oct 2009 14:06:02 +0200

> My take is no and no, the latter, what config is, being the major stumbling

I believe the 'default' issue can be resolved by a minor reformulation -
something is probably already in the queue for -08. My interpretation is
that 'default' is a statement that allows to determine when two
configurations with differing infosets are equivalent - with all
consequences for server behaviour etc.

What a config is seems more complicated. I think though it is necessary
to settle on what a "canonical" configuration is - it is the one to
which all YANG constraints apply. My impression from the conf call was
that the participants agreed that this should be the "report-all" style
with all defaults filled-in.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Sat, 17 Oct 2009 08:40:04 -0700

> with all defaults filled-in.

Yes -- this is what I remember.
I also remember several times we were reassured
that a server-created leaf that did not contain the
YANG default value did exist.

Then it changed to they exist in running, but not candidate.

The servers that implement 'explicit' basic behavior
for filtering defaults will never show the client these s-c leafs,
even in the running config.

The solution of forcing data modelers to ignore s-c leafs in
constraint rules is not going to work, especially if these leafs
are supposed to turn into 'normal' leafs.

The s-c leaf is unmanageable without with-defaults=report-all.
It is essentially an undocumented default -- a leaf invisible
from the client, except the client has no clue what value
the server is using.

Setting s-c=true is supposed to be a license to keep these
leafs invisible from the client.  That alone is reason
not to add to the system-creatable statement.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 17 Oct 2009 18:34:50 +0200

> Then it changed to they exist in running, but not candidate.

I think you can only reasonably create s-c leafs at commit time.
Until commit, candidate is just a scratch pad.

> even in the running config.

I think this summary is wrong. Once creation has taken place, the s-c
leafs are part of the config. I think people wrote this here multiple
times.

> from the client, except the client has no clue what value

You are making up a story - and I am slowly getting tired of these
false claims.

> not to add to the system-creatable statement.

You are making up a story and than drawing a pointless conclusion.
Why are you doing this?

/js

---

From: Andy Bierman <[email-masked]>
Date: Sat, 17 Oct 2009 10:01:44 -0700

> leafs are part of the config. I think people wrote this here multiple

So they will always be returned in a plain <get-config>
by every server?  If so, then good.  If not, then
how are they normal?  They are invisible, but unlike
the YANG default, there is no derived value for the
client to extract from the meta-data.

> You are making up a story - and I am slowly getting tired of these

So how does the client retrieve these nodes if
the optional with-defaults capability is not implemented?
Are you saying these s-c leafs turn into explicit
nodes in running, so they are always visible?

> You are making up a story and than drawing a pointless conclusion.

I am trying to understand how compliant servers
that use explicit-mode work.  It seems to me,
these s-c nodes will never be seen by the client, even
though they affect the config like defaults.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 17 Oct 2009 22:32:07 +0200

> client to extract from the meta-data.

My understanding is that once an s-c leaf exists, it is an ordinary
leaf.

> nodes in running, so they are always visible?

That is my understanding.

> though they affect the config like defaults.

I am wondering which email message made you believe this.

/js

---

From: Andy Bierman <[email-masked]>
Date: Sat, 17 Oct 2009 15:06:54 -0700

> My understanding is that once an s-c leaf exists, it is an ordinary

So they are visible on all types of servers all the time,
and not filtered:
   report-all: would be returned
   explicit: would be returned
   trim: N/A, since an s-c leaf cannot have a YANG default,
         or it is ignored, if the typedef has a default

> That is my understanding.

The draft needs to say this somewhere.
Once an s-c leaf is created, such as uid, it
does need to be saved, otherwise the server may not
derive the same value again.

> I am wondering which email message made you believe this.

The definition of explicit in the with-defaults draft
is self-referencing, and useless.  I brought this issue up with the WG
and Balazs a long time ago.  What is an 'explicit' default?
Every month or so, we find out new details on how it is supposed to work.

I would have though a server-created leaf would not
count as an explicitly created leaf, because I keep
hearing from you and Phil that explicit means only
the leafs the client provides.  Now it means all
the client leafs, plus the s-c leafs.

That's fine.  Just trying to keep up with the
concepts and terms that keep changing.
Don't assume everybody has the same understanding of
the poorly documented concepts as you do.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Sat, 17 Oct 2009 22:53:06 -0400

>the client leafs, plus the s-c leafs.

My objection has been constant, that default values are not magically
part of the configuration database, and that only data in the
configuration database should be reported in <get-config> output.

s-c leafs are real leafs, so they are really created in the
configuration database.  Once they are created, they are normal
leafs.  They should be reported in the <get-config>, be changable
by <edit-config>, and in all ways be normal.  "s-c" means on that
the system can create them if they don't exist.

Remember that "client provides" is meaningless, since the client
is not the only source of configuration.  If a CLI user says "set
foo 42", then foo is part of the configuration database.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Sun, 18 Oct 2009 09:49:44 -0700

> foo 42", then foo is part of the configuration database.

This is why I got confused,
and perhaps Lada as well.

The term 'explicitly set' suggests that
it was set through the management protocol,
by some entity other than the managed entity (the server).

But any leaf set by any possible mechanism,
is explicitly set.  A YANG default is presumably
implicitly set because the server already knows the value.

So any internal server application, regardless of whether
it uses NETCONF to transfer the commands, will create
only explicit nodes?  So even if an internal
server app changes a value back to its YANG default,
that node is still explicit, and always returned
by a server that returns with-defaults=explicit?

The YANG spec has to contain all the normative
details for all YANG behavior, not the Informational
Arch spec.  Not sure what to write, but some text
should be added to clarify explicitly set leafs.

Andy

---

From: WashamFan <[email-masked]>
Date: Mon, 19 Oct 2009 09:41:48 +0800

My interpretation, nodes set by the client via Netconf including those
with default values or set by the server via internal mechanisms excluding 
those with default values are considered as "explicitly set" nodes.

washam

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 19 Oct 2009 09:53:34 +0200 (CEST)

> implicitly set because the server already knows the value.

We don't use this term for s-c leafs.  Maybe we should rephrase the
text on defaults so that we don't use this term?  I.e. just say that
the default value is used if the leaf doesn't exist.  This might be
better since the term "explicitly set" sort of indicates that some
leafs might be "implicitily set", and since we never talk about that I
can see that it lead to confusion.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 19 Oct 2009 09:56:25 +0200 (CEST)

> My understanding is that once an s-c leaf exists, it is an ordinary

Yes.

> That is my understanding.

Yes.

> I am wondering which email message made you believe this.

So am I.  Can we clarify the text somehow so that people do not draw
this conclusion?

So Andy, with these clarifications, do you think we should add the s-c
statement or not?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 19 Oct 2009 02:16:32 -0700

> So Andy, with these clarifications, do you think we should add the s-c

It certainly makes more sense, now that the terminology is cleared up.

I am still unclear on 2 points:
  - validation:  nothing special right?
     s-c leafs can have constraints, but they are applied
     to running initially, not to candidate
  - mandatory:  should be allowed;
     Lada's addition of mandatory=true to the
     user ID example makes sense; meaning is unchanged;

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 19 Oct 2009 11:26:01 +0200 (CEST)

> It certainly makes more sense, now that the terminology is cleared up.

Good!

>      user ID example makes sense; meaning is unchanged;

This will depend on what we say in the document about *when* such
leafs are created.  In the first proposal, we said that the server
creates those leafs at commit time (or edit-config towards running).
You suggested that we should be more lax and let this be an
implementation detail.

If we pick one of those proposals, you cannot have 'mandatory' on a
s-c leaf, since the leaf will not exist until after validation (at
least on some implemtations).

As for other constraints (must / unique) it depends on how the
constraint is written - if it requires the leaf to exist, it won't
work, but you can e.g. do 'unique uid;' in the example.  The server
MUST make sure it picks a value that doesn't break any constraints.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 19 Oct 2009 11:44:31 +0200

> least on some implemtations).

Does NETCONF somewhere spell out how validation is done if it happens
during commit? If not, we can leave this implementation dependent as
long as the result is validÂ.

The real issue then is the explicit validate operation, which is not
bound to a commit, or am I missing something? Here we would have to
pick a solution; I am not sure yet which one I prefer. Restricting
constraints for s-c leafs achieves the goal but seems a heavy-weight
choice just to make :validate work.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 19 Oct 2009 12:28:10 +0200 (CEST)

> long as the result is validÂ.

No.  But YANG says:

  If the datastore is <running/> or <startup/>, these constraints MUST
  be enforced at the end of the <edit-config> or <copy-config>
  operation.  If the datastore is <candidate/>, the constraint
  enforcement is delayed until a <commit> or <validate> operation.

> bound to a commit, or am I missing something?

It is also for clients that want to do off-line validation.  If they
rely on the server to create s-c leafs, their validation will fail if
a constraint requires the s-c leaf to exist.

> Here we would have to

Do you have an alternative suggestion?

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 19 Oct 2009 12:40:33 +0200

>      user ID example makes sense; meaning is unchanged;

But candidate would then be invalid if mandatory s-c leafs are missing.
So far we assumed that validity of candidate may be relaxed in the area
of referential integrity only.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 19 Oct 2009 13:11:51 +0200

> You suggested that we should be more lax and let this be an

If an s-c leaf is not in candidate but is also a list key - which makes
a very good sense in the uid example - then the client could not use the
keys to address individual list items in candidate. So I think s-c leafs
have to be filled already in candidate, unless we introduce new CLRs.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 19 Oct 2009 13:12:21 +0200

> a constraint requires the s-c leaf to exist.

In the case of such a tool, the knowledge that an s-c leaf is involved
can simply lead to a meaningful warning instead of an error message:

  constraint "XYZ" fails but involves server created leafs and it may
  be satisfied when committed

This is where machine readable information that there are s-c leafs
would be meaningful to have.

> > Here we would have to pick a solution; I am not sure yet which one
> > I prefer. Restricting constraints for s-c leafs achieves the goal
> > but seems a heavy-weight choice just to make :validate work.
> 

If we could do the same as above with NETCONF - but I am not sure we
can do this easily.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 19 Oct 2009 13:25:43 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> If an s-c leaf is not in candidate but is also a list key

We need to say that an s-c leaf cannot be a key.  The client must
always give the key values for list entries in edit-config.

> - which makes
> a very good sense in the uid example

Not really, since you can have multiple users with the same uid.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 19 Oct 2009 13:37:06 +0200 (CEST)

> If we could do the same as above with NETCONF - but I am not sure we

So you want <validate> to return "true", "false", or "maybe" :)

I think restricting constraints for s-c leafs makes more sense.
Actually, we would not have a hard restriction - just as we allow must
expressions to refer to garbage leafs, we would allow them to refer to
s-c leafs; they will just always fail (depending on how the expression
is written - it is of course possible to write expressions that take
non-existing leafs into account, and it might be useful.)

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 19 Oct 2009 13:56:09 +0200

> non-existing leafs into account, and it might be useful.)

I don't think s-c leafs are worth these complications. For server
operation it is only important that all required configuration
parameters be available when they are needed. The "schematic sugar" of
filling in some of these values on behalf of the client can be
considered implementation detail - and my plan actually is to implement
it in the manager software, not in the server.

Lada 

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 19 Oct 2009 14:04:04 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> I don't think s-c leafs are worth these complications.

So what is your proposal?

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 19 Oct 2009 14:26:17 +0200

> So what is your proposal?

Keep this issue outside of YANG as implementation dependent. The three
types of leafs currently are:

1. Mandatory - must be present, otherwise the configuration is not 
   valid.

2. Optional, no default - needn't be present, the system must be 
   able to operate without them.

3. Optional, default specified in DM - needn't be present, in which 
   case the server must behave exactly as if they are present and have 
   the default value.

Do we need anything else?

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 19 Oct 2009 10:02:17 -0400

Maybe I am a broken record.
None of the issues raised about system-created leaves have anything to 
do with the system-createable statement.  All of the issues are present 
in the existing text.

We have to say something to clarify what is permitted.  If the system 
chooses to create a leaf, when is it allowed / required to create it, 
and how does this interact with validation?  Can constraints reference 
optional leaves or leaves that the system may create?  If so, how is the 
client to verify the configuration, or is he not expected to be able to 
verify such configuration?

At this poiint, I can probably live with any consistent story that is 
explained clearly.  As far as I can tell, our current state is that 
reasonable clients drawing on the document may well have expectations 
that do not match what reasonable devices drawing on the same document 
will do.  And these inconsistencies will harm interoperability.  (One 
may need to hypothesise a couple of model writers who draw different 
understandings to cause complete collapse.)

Yours,
Joel

---

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

"Joel M. Halpern" <[email-masked]> wrote:
> None of the issues raised about system-created leaves have anything to do with
> the system-createable statement.  All of the issues are present in the existing
> text.

I agree.  If Andy is ok with s-c with the additional clarifications,
it seems that most people actually are in favor of adding s-c.  Do you
agree?  Is it time to check consensus?  If not, it would be good to
get a sense of where people stand.

/martin

---

From: Kent Watsen <[email-masked]>
Date: Mon, 19 Oct 2009 11:36:16 -0700

I'm with Lada, leave s-c out of YANG for now.   Even though the current definition is OK, I think it's too narrow of a solution to be all that useful - for instance:
  - why are only-leafs and only-creatable?
      - what about containers or list-elements?
      - why not modifiable and deletable?
  - what if the server has a user-defined commit script that modifies
    config even though it's not marked s-c in the YANG model?

I'd wait for next YANG version to define a mechanism to that enables a server to report when/where it created config.  This is what we (Juniper) did and it works great.  I want to submit an I-D to the WG, but I don't want to have it be limited by this s-c definition

> If the system
> and how does this interact with validation?
>
> Can constraints reference

In the YANG model, these leafs would not be mandatory - all normal rules apply, is there really anything more that needs to be said?

One thing I have not heard discussed is that the s-c leafs need to be created as part of the transaction - prior to the RPC-Reply being sent.  This is important as we (Juniper) have also created a capability for devices to return the timestamp/fingerprint of their running config, which allows a client to discover when it's out of sync without having to get the entire config from the device.  Here is the sequence we use:

  <lock>
  <edit-config>
  <commit>
  if RPC-Reply indicates implicit-changes
    <get-config> on nodes identified in RPC-Reply
  <get-config-info>  // get new timestamp/fingerprint
  <unlock>

Its important that the changes occur as part of the transaction so that they can be reported in the RPC-Reply

Thanks,
Kent

---

From: "tom.petch" <[email-masked]>
Date: Wed, 21 Oct 2009 11:53:57 +0200

---- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
Sent: Monday, October 19, 2009 2:26 PM

> 1. Mandatory - must be present, otherwise the configuration is not

and I assume must be created by client, system has no choice

>    able to operate without them.

so I assume may be created by client else not present (in any sense, not
visible in any retrieval operation)

>    case the server must behave exactly as if they are present and have

so may be created by client if not must be 'created' with default value
by system (and so visible in some form of retrieval)

which leaves out two possible use cases (looking back to see what
came up in earlier discussions)

4 may be created by client else may be created by system else not present
(so may be visible in some form of retrieval if system did create it)

5 may be created by client else must be created by system but data model
cannot suggest a suitable value (visible in some form of retrieval)

Tom Petch

---

From: "t.petch" <[email-masked]>
Date: Wed, 21 Oct 2009 11:52:51 +0200

---- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
Sent: Monday, October 19, 2009 2:26 PM

Tom Petch

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 21 Oct 2009 13:54:17 +0200

> and I assume must be created by client, system has no choice

It depends on the point(s) in the workflow where validity is checked and
enforced. If it is at commit time, both client and server have a chance
to supply the mandatory leaf. However, YANG only says the leaf must be
there when the configuration is required to be valid, nothing more. So I
think this also covers your case 5.

Yes.

> by system (and so visible in some form of retrieval)

Yes, with-defaults=report-all.

> (so may be visible in some form of retrieval if system did create it)

This case doesn't make much sense to me, unless the value of the leaf is
completely irrelevant.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "tom.petch" <[email-masked]>
Date: Thu, 22 Oct 2009 19:07:44 +0200

----- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
Sent: Wednesday, October 21, 2009 1:54 PM

Lada

Two reasons for suggesting this somewhat vague case.  More importantly,
the other cases are hedged around with restrictions, some overt, others
that Andy comes up with, so this is a get out, saying that we may not
have thought of everything that a data modeller wants to do, and this
allows them to specify what they want in the description clause.

Less importantly, I am wondering how to model an interface slot, which
may have a ethernet card or may have an HDLC card, each with a different
set of parameters; simple approach is to allow the lot, and let the user/system
sort out which they need in any particular instant.

TomPetch

---

From: Andy Bierman <[email-masked]>
Date: Thu, 22 Oct 2009 12:15:34 -0700

>From the POV of a data model designer, the s-c leaf proposal
is just too fragile.  Just because the server MAY provide
a value is no reason to write the YANG module with kid gloves,
making sure no conceptual referential integrity requirements
include an s-c leaf.  This is only relevant in a small
number of corner-cases, not nearly 'all' s-c leafs, as the proposal claims.

If the s-c leaf is created during boot-up or if was already added to
running before the session started, then the client is expected
to treat the s-c leaf as just a normal leaf.

Since we keep discussing the s-c-stmt, instead of agreeing
to leave it out of YANG 1.0:

Summary of proposed changes to s-c stmt:

  1) All s-c leafs are part of the validation model.
  2) The server MAY create an s-c leaf at any time
     in either candidate or running, providing the
     config remains valid.
  3) Validation of s-c leafs in candidate is only assured during a
     real <commit> operation, not a <validate> operation or off-line
     validation procedure.
  4) mandatory-stmt is allowed with s-c-stmt.
     true=node MUST exist, as before; if s-c=false, then
     client MUST provide, otherwise server MAY provide and client
     must make sure server will do this (read the description-stmt).
  5) All s-c nodes are explicit nodes, except if a deviation adds a YANG default,
     and the leaf contains that value.
  6) It is better practice to use a deviation-stmt to add a
     vendor-specific default, than to use an s-c-stmt.
     They are not the same thing.  Usage guidelines for s-c leafs
     are still very unclear.
  7) The description-stmt SHOULD be used to specify if/when/how
     the server creation requirement is SHOULD or MUST, instead
     of a MAY requirement (if s-c=true).

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 22 Oct 2009 15:19:30 -0400

Andy Bierman writes:
>include an s-c leaf.

Following the rules is no more "kid gloves" than not having config
nodes to refer to non-config data.

>This is only relevant in a small

What "'all'" in the proposal are your referring to?

>  1) All s-c leafs are part of the validation model.

-1, since I want the client to be able to validate the config.

If the s-c leafs are required for validation, then the client
can't validate.

>     in either candidate or running, providing the

-1, since this impacts interoperability.

If I make a list of users, some with and some without uids,
the "any time" means user A may make user B invalid for
some implementations.

>     real <commit> operation, not a <validate> operation or off-line

-1, since I want the client to be able to validate the config.

Not allowing validation during a <validate> operation is silly.
Not allowing offline validation goes in the face of all our
work to allow clients to know they are sending valid config,
instead of the old "fire and pray" approach.

>     must make sure server will do this (read the description-stmt).

-1, since I want the client to be able to validate the config.

If an s-c leaf can be mandatory, then the client cannot validate.

>     and the leaf contains that value.

Don't follow you here.

>     They are not the same thing.  Usage guidelines for s-c leafs

+1

>     of a MAY requirement (if s-c=true).

+1

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Thu, 22 Oct 2009 13:05:59 -0700

Phil Shafer wrote:

There are several people who think the s-c leaf MUST
be part of the validation model.  It seems to be a majority
to me.  The consensus seems about split on server MAY vs. MUST create
as well.  I expect the co-Chairs to determine consensus
based on mailing list input at some point, instead of relying
on in-person input at the IETF meeting.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 22 Oct 2009 22:42:58 +0200 (CEST)

Andy Bierman <[email-masked]> wrote:
> to me. 

Note that the revised proposal says that s-c leafs are not created
until after validation, so their initial value is not available for
validation, but the server MUST NOT assign value which breaks any
constraint.  I don't think the majority is against this?

> The consensus seems about split on server MAY vs. MUST create
> as well.

I have just seen Randy proposing this. 

> I expect the co-Chairs to determine consensus

I agree that we do not have consensus to add s-c.

The first question is if we can agree that this is a data modeling
issue, and not an implementation issue?

I see a couple of alternatives in order to move forward:

  1a. Do nothing.  Let implementations and data models figure out
      how/if/when/why the server can modify the configuration data.

  1b. As 1a. but add text that documents this.

  2a. Add text that says that the server MUST NOT modify config data
      unless dictated by the data model (through description clauses
      or future extensions).

  2b. Add text that says that the server is free to modify config data
      in any way it wants, unless constrained by the data model
      (through description clauses or future extensions).

  3.  Add formal statements (e.g. the current s-c) to control how the
      server can modfiy config.

My preference would be 3 or 2a.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 23 Oct 2009 10:55:55 +0200

Hi,

I'd really appreciate if we put this discussion off for now and resume
it after YANG 1.0. As we saw in IPFIX examples, the system-created leafs
may sometimes be device-specific defaults and sometimes sort of
operational values. Also, Kent previously suggested other server actions
similar to s-c. So I think we need a broader view of the problem.
Anyway, few comments are below.

> constraint.  I don't think the majority is against this?

I'd prefer to have all data available for validation at some point.
I also don't like the fact that the current semantics of mandatory is
lost for these leafs.

> I have just seen Randy proposing this. 

No, I also support MUST.

> issue, and not an implementation issue?

I am now inclined towards considering it an implementation issue.

>       how/if/when/why the server can modify the configuration data.

This is my preferred choice for YANG 1.0.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Phil Shafer <[email-masked]>
Date: Fri, 23 Oct 2009 08:26:44 -0400

>> I have just seen Randy proposing this. 

Can you explain what extra information "MUST" would denote
to either the client or the server?  The server will know
what it needs to do based on the description (since the
contents will need special code implementing what the
description says will be allowed).  The client knows
that anytime it ships a config that is missing an s-c leaf,
it must refetch the config if it wants to see what the
leaf will contain.  "MUST" does not change the behavior
of either side, but forces the hand of the modeler, who
may only want a "MAY".

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 23 Oct 2009 15:21:54 +0200

> to either the client or the server?  The server will know

The client has a guarantee that the server will supply a value.
As I wrote before, the server needn't be a monolithic application and
for processes that cooperate through the configuration datastore it is
important know that the configuration is valid and all values are in
their places.

> leaf will contain.  "MUST" does not change the behavior

If the server only MAY set the value, it's also possible the leaf in the
re-fetched config will contain nothing, right?

> of either side, but forces the hand of the modeler, who

Maybe I don't understand it properly. If the parameter in question is
required for server operation - and those in the examples we had are -
and client doesn't provide a value, the server can:

1. set the value in the configuration and use it internally
2. use some value behind the scenes without showing it in the 
   configuration
3. report an error

I think only 1 makes sense and I understand it as the "MUST" variant.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 23 Oct 2009 09:49:39 -0400

Let me rephrase your statement:
"If the parameter in question is require for operation of all servers,"
then the modeler would want to represent it as a must.
But it is pretty easy to envision cases where depending upon the 
implementation, the field may be necesary, useufl, or almost irrelevant. 
  There are also modeling constructs where the field is clearly 
necessary in all implementations.

Unfortunatley, we only have so many dimensions we can represent in the 
modelling language.  We all know that some information ends up in the 
description clause.  What Martin, Phil, and I have been saying is that 
the piece of information that seems useful to us is whether the system 
may choose to fill in this field during the process of committing the 
configuration.  I.e. it will be filled in as part of the users actions.
One can argue that a conservative implementation has to assume that 
anyway.  In that case, we don't need this marking.
One can also look for different value, such as the client knowing that 
the FIELD will be filled by the server.  I consider that to be less useful.

What I consider necessary at this point is that we put in text that 
clearly indicates what can be modified by the server, and what 
constraints such modifications must meet.

Yours,
Joel

Ladislav Lhotka wrote:
...

---

From: "tom.petch" <[email-masked]>
Date: Fri, 23 Oct 2009 14:50:33 +0200

----- Original Message ----- 
From: "Martin Bjorklund" <[email-masked]>
Sent: Thursday, October 22, 2009 10:42 PM

> constraint.  I don't think the majority is against this?

I am against it.  It just slices off part of the 'config' and stops
us using the good things of YANG, the extra logic it brings,
against a part of the config.  I do not see many things as CLRs,
but I do see this as one.

Rather, redefine validate to let it create S-C nodes and then validate
afterwards.

I am also in Randy's MUST camp, not MAY.

And if I have to choose one of the options below - I do not want to -
then 2b would be my preferred choice.

Tom Petch

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 23 Oct 2009 16:07:58 +0200

> implementation, the field may be necesary, useufl, or almost irrelevant. 

Can you give me an example? I don't get how this varying relevance could
occur for the same data model.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Fri, 23 Oct 2009 07:41:32 -0700

Joel M. Halpern wrote:
>  There are also modeling constructs where the field is clearly necessary
> in all implementations.
> 

I guess I am in the MUST camp,
although I prefer to leave s-c-stmt out of YANG.

>From the client developer perspective, 'server MAY create'
is very close to useless.   It certainly is not worth
all the CLRs that come with this bit of meta-data.
All config=true objects MUST be part of the configuration
validation model.

A 3rd party app cannot rely on MAY create, and so
the server-creatable aspect of the leaf is of no use.
The client will set everything explicitly instead.

A 1st or 2nd party developer may be used to hacking code
to get it to work with ad-hoc server CLI.  They may bother
(through trial and error) to hard-code various
objects to use the s-c value instead.

Unlike other standard node types, there doesn't seem to be much
standard behavior in an s-c leaf at all.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Fri, 23 Oct 2009 12:34:39 -0400

>The client has a guarantee that the server will supply a value.

But I'm trying to understand why the guarantee matters to the client
and how it changes any behavior on the part of the client.  If
the client wants post-s-c config, it knows that it needs to refetch
it, and that post-s-c config may still not contain the s-c leaf.

>important know that the configuration is valid and all values are in

If the server didn't see the need to set the s-c leaf, we
know that the description must allow this.  Our client
can rest assured that all config is valid and in the right
place, even if that means an s-c leaf does not exist.

Yes.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Fri, 23 Oct 2009 10:19:33 -0700

> it, and that post-s-c config may still not contain the s-c leaf.

If the client can rely on the server to create a reasonable
value, then the client developer does not need to write code
to set that leaf. (MUST)

Since the client developer cannot rely on the server
to create a reasonable default (MAY), the developer can either
ignore that leaf or write code to support it.

If the client ignores the leaf (at its own peril),
then it doesn't really matter who creates that leaf,
i.e., server or some other application.

If there is code to set the leaf explicitly,
then the client will use it every time,
and not guess/wait-and-see what the server will do.

Either way, the s-c boolean has no real value to the client
developer.

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 23 Oct 2009 10:26:10 -0700

Hi -

> From: "Phil Shafer" <[email-masked]>
> To: "Ladislav Lhotka" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, October 23, 2009 9:34 AM
> Subject: Re: [netmod] use cases was: finish up
>
> Ladislav Lhotka writes:

You're only looking at part of the problem.  The difference is in how
the value is allocated.  With the "MAY" behaviour, the client needs
to replicate whatever allocation logic the server should have had, in
case the server didn't feel like allocating one that day.  With the "MUST"
behaviour, client implementors don't need to replicate that logic unless
they have some other compelling reason to.

For the cases of "s-c" that I'd care about, the only times a client would
supply an s-c value would be in a configuration restore from archive,
or to ensure parameter consistency across systems after initially
allocated on a "master".

> place, even if that means an s-c leaf does not exist.

But that means the data wouldn't be merely s-c.  From an information
modeling perspective, it is truly optional.  What's happening here looks
like an attempt to to ram two closely-related models together and pretend
that they are a single model.  The implementation which requires the
s-c bit of information and the implementation which does not require that
bit of information are clearly working with different information models,
even if the only difference between the two models is the optionality
of that bit of information.

Randy

---

From: Phil Shafer <[email-masked]>
Date: Fri, 23 Oct 2009 14:23:35 -0400

>they have some other compelling reason to.

Consider the following slightly faked-up scenario:  an IDP detection
policy is shared between a set of chassis.  To be shared, the policy
needs a unique number, but some policies (based on the needs of the
policy) are not shared and do not need this number.  The system MAY
create the "number" leaf if the policy needs it, but won't bother
creating it if it does not need it.

I guess this leaf could be made irrelevant by using a "must" statement
that discards it unless the policy needs it.

Thanks,
 Phil

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 23 Oct 2009 13:05:10 -0700

Hi -

> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, October 23, 2009 11:23 AM

This dives into the question of "optional" configuration data that isn't
really optional - there is a (potentially complex) presence condition,
in this case the semantics of the policy's "payload" that determins
whether the policy is or is not shareable. Slightly different ways
to look at the handling of "conditionally mandatory" stuff include
(1) subclassing, though this gets messy when there are multiple
"conditionally mandatory" bits; (2) packaging this stuff into aspects,
though I don't see a terribly tidy way for yang to handle these;
(3) wrapping the conditionally mandatory bits into types that permit
"N/A" as a potential value.

(To the specifics of the example, however, I think the computational
burden of figuring out whether a policy would need a number would
probably be greater than unconditionally assigning one.  :-)

However, recognizing that there are cases where s-c behaviour is
useful, the conditionally mandatory case seems to me to be a corner
case.  I think some more experience with actual models and implementation
might be needed to figure out how to do it right.  For example,
to what extent should the representation of the conditions be machine-
readable in the model?  On the other hand, this question doesn't even
arise for the "MUST" interpretation.

I'm not arguing that we need to do the s-c at this time.
Rather, I'm arguing that if we do do s-c at this time,
the MUST approach is much more tractable than the MAY
approach.  The MAY approach may have its legitimate uses,
but doing it right means (at least to me) going through
the exercise of figuring out the limits of conditionally
mandatory elements in models, which in your example goes
far beyond what can reasonably be expressed today.

Randy

---

From: Phil Shafer <[email-masked]>
Date: Fri, 23 Oct 2009 16:07:35 -0400

>far beyond what can reasonably be expressed today.

My concerns are more practical.  MUST forces a modeler to do something
that might not be required, and the real difference (in terms of
behaviors) in MUST and MAY is near zero.  The client will refetch
either way (if it cares).  The server will be driven by the behavior
required in the "description", not the "s-c" statement.

Thanks,
 Phil

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 23 Oct 2009 13:56:38 -0700

Hi -

> Sent: Friday, October 23, 2009 1:07 PM
...
> behaviors) in MUST and MAY is near zero.

As both Andy and I have pointed out, it makes a huge difference
for the client implementation.

>  The client will refetch
> either way (if it cares).

That's not the point, as both Andy and I have pointed out.

>  The server will be driven by the behavior

The problem is what the client is required to do.  If the server
cannot be relied on to supply required s-c values, equivalent,
or potentially more complex logic, which would otherwise not be
needed, must be implemented in clients.

Randy

---

From: Phil Shafer <[email-masked]>
Date: Sun, 25 Oct 2009 14:01:00 -0400

>needed, must be implemented in clients.

I don't see that.  If the client doesn't care enough to give it a
value when it creates the instance, and the server doesn't see a
need to set it when it is validating the config, then neither side
needs to set it.  There's no requirement that this logic must be
implemented in the clients.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Sun, 25 Oct 2009 11:35:17 -0700

> implemented in the clients.

How does the client know what the server will 'see'
and 'decide', wrt/ creating the leaf or not?

We do not agree that the s-c leaf is part of the
YANG constraints, so we cannot agree on why
the client would care if the server creates a
valid leaf (or not), to keep some must/when/unique constraint
from causing an error.

IMO, it is more important to leave the current
validation model alone, and that means all config=true
objects are allowed to be used in
configuration database constraints.

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 25 Oct 2009 15:17:20 -0700

Hi -

> Sent: Sunday, October 25, 2009 11:01 AM

If "neither side needs to set it" then it's truly optional, and
the model should identify it as such.

If it's truly necessary, but the server can be relied to create it
if not supplied by the client - well, that seems a reasonable use of s-c.

If it's what other standards would call "conditionally mandatory",
then a compromise would be to say that the server MUST create it
when not supplied by the client *if* the conditions that make it
mandatory (presumably rigorously spelled out in description text)
are satisfied.  What I can't abide is just leaving it to
an implementation's whims, which is what the proposed "MAY"
language would do.

But I think this group needs to step back a bit and think about what
conditionally mandatory parameters really mean architecturally.  Usually
their presence corresponds to the selection of a particular capability
or package of capabilities.  In such case, at least at a conceptual level,
they're mandatory bits within an optional presence container.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 25 Oct 2009 23:45:47 +0100

> they're mandatory bits within an optional presence container.

I think the YANG mechanism here are features.

/js

---

From: Phil Shafer <[email-masked]>
Date: Sun, 25 Oct 2009 21:59:18 -0400

>an implementation's whims, which is what the proposed "MAY"

I read "MUST if xxxx" as "MAY", in which case "conditionally
mandatory" means "the implementor must read the description to know
what they are doing", which is unavoidable on the server side.
I do not read "MAY" as the "implementation's whims", since
the implementor must live by the rules in the description.

Thanks,
 Phil

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 26 Oct 2009 11:02:21 -0700

Hi -

> Sent: Sunday, October 25, 2009 6:59 PM
...
> the implementor must live by the rules in the description.

RFC 2119 doesn't support that reading.  It says "[t]his word, or
the adjective 'OPTIONAL', mean[s] that an item is truly optional."

Randy

---

From: David Partain <[email-masked]>
Date: Tue, 27 Oct 2009 14:56:35 +0100

Hi,

The various documents have been updated in advance of the upcoming IETF, and, 
unless I'm mistaken, we seem to have one sticky issue left to clear up, and 
that is what to do about system-creatable.

Last week, Martin published a set of possible choices of what we could do.

It would be helpful if everyone who cares would reply to this message telling 
me / the group what you think the right answer is.

The choices are below.  If you think there are other possible choices, please 
say so.  I've renumbered just to try to make it clearer what you're "voting" 
for.

1. Do nothing in the draft and let implementations and data models figure out
how/if/when/why the server can modify the configuration data.

2. Do nothing but write in the document that we _know_ it's an issue but we're 
still not doing anything.

3. Add text that says that the server MUST NOT modify config data unless 
dictated by the data model (through description clauses or future 
extensions).

4. Add text that says that the server is free to modify config data in any way 
it wants, unless constrained by the data model (through description clauses 
or future extensions).

5.  Add formal statements (e.g. the current s-c) to control how the server can 
modfiy config.

Please let your voice be heard as soon as possible.  Please try to choose 
one...

Thanks.

David

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 27 Oct 2009 10:04:24 -0400

You said "Please try to choose one..."
With that dictum in mind:  5 would be my preference.

I will say that I think 1 would be a serious mistake, as it is likely to 
induce interoperability failures.

Yours,
Joel

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 27 Oct 2009 15:15:05 +0100

Hi David,

if this choice refers to YANG 1.0, my preference is 1 but I am also fine
with 2 - it could be actually helpful if the _issue_ gets formulated
rather than the solution.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Phil Shafer <[email-masked]>
Date: Tue, 27 Oct 2009 09:58:08 -0400

>how/if/when/why the server can modify the configuration data.

-1

>still not doing anything.

This is the minimum we need to do.

>dictated by the data model (through description clauses or future 

-1.  "MUST unless you make an extension" has no force.

>it wants, unless constrained by the data model (through description clauses 

ditto.

>5.  Add formal statements (e.g. the current s-c) to control how the server can 

I'd learn toward this, but I really think there's too much
conflict to move down this path.  s-c should be broken out
into a distinct I-D.

So I guess that makes me a "2".

Thanks,
 Phil

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 27 Oct 2009 15:25:29 +0100

(speaking as a contributor who cares) I think that the WG MUST achieve
#5 sooner or later. As I know that the nasty AD is pushing on us to
deliver, it looks like we are forced to fall back on #2 right now and
start working on #5 as soon as we have delivered our main chartered
items. 

Dan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of David Partain
> Sent: Tuesday, October 27, 2009 3:57 PM
> To: [email-masked]
> Subject: [netmod] Wrapping up system-creatable
> 
> Hi,
> 
> The various documents have been updated in advance of the 
> upcoming IETF, and, unless I'm mistaken, we seem to have one 
> sticky issue left to clear up, and that is what to do about 
> system-creatable.
> 
> It would be helpful if everyone who cares would reply to this 
> message telling me / the group what you think the right answer is.
> 
> The choices are below.  If you think there are other possible 
> choices, please say so.  I've renumbered just to try to make 
> it clearer what you're "voting" 
> for.
> 
> 1. Do nothing in the draft and let implementations and data 
> models figure out how/if/when/why the server can modify the 
> configuration data.
> 
> 2. Do nothing but write in the document that we _know_ it's 
> an issue but we're still not doing anything.
> 
> 3. Add text that says that the server MUST NOT modify config 
> data unless dictated by the data model (through description 
> clauses or future extensions).
> 
> 4. Add text that says that the server is free to modify 
> config data in any way it wants, unless constrained by the 
> data model (through description clauses or future extensions).
> 
> 5.  Add formal statements (e.g. the current s-c) to control 
> how the server can modfiy config.
> 
> Please let your voice be heard as soon as possible.  Please 
> try to choose one...
> 
> Thanks.
> 
> David

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 27 Oct 2009 15:26:48 +0100 (CET)

My votes are for 5,3,2, in that order, where 2 probably is the most
realistic.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Oct 2009 15:30:42 +0100

On Tue, Oct 27, 2009 at 02:56:35PM +0100, David Partain wrote:
 
> 2. Do nothing but write in the document that we _know_ it's an issue
> but we're still not doing anything.

I believe this is the best we can do in order to make forward progress
on YANG 1.0 and taking the time to work out a good solution. It
appears to me that s-c is only the tip of an iceberg.

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 27 Oct 2009 07:51:30 -0700

> still not doing anything.

(2) is the best outcome we can achieve, since there is
no consensus on most of the important s-c details.
Nor is there consensus that s-c is sufficient in
scope or utility.

I don't think we understand the problem well enough
to write anything really useful in the draft.

> dictated by the data model (through description clauses or future 

This is could be added to the Usage Guidelines I-D,
so it would apply to modules in drafts.

In general the data model is the only source for
making decisions what the server is allowed to
do for that section of the conceptual database.
The implementor MUST NOT do stuff that is not
specified in the data model.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Tue, 27 Oct 2009 09:23:08 -0700

In preference order: 1, 4, 2

As mentioned before, I will submit an ID shortly for a more holistic approach for this...

Thanks,
Kent

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of David Partain
> Sent: Tuesday, October 27, 2009 9:57 AM
> To: [email-masked]

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 27 Oct 2009 10:00:04 -0700

Hi -

I could live with 2.

I think 3 and 4 are potentially problematic.  Lots of daemons in the details.  :-)

I strongly oppose both 1 and 5 (if the latter is understood as being
the current s-c proposal)

I could support 5 if it were understood as a re-formulated s-c proposal,
though I do agree with Juergen about the probable presence of icebergs.

Randy

---

From: "tom.petch" <[email-masked]>
Date: Tue, 27 Oct 2009 18:19:09 +0100

4 I think the best.

Tom Petch