Subject: Re: [netmod] Configuration nodes was Re: meaning of defau

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

----- Original Message -----
From: "Andy Bierman" <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: "Phil Shafer" <[email-masked]>; <[email-masked]>
Sent: Sunday, August 30, 2009 10:49 PM

> tom.petch wrote:
> > ----- Original Message -----
> > From: "Phil Shafer" <[email-masked]>
> > Sent: Friday, August 28, 2009 10:45 PM
> >
> >> Andy Bierman writes:
> >>> if this is true, then why does the 'explicit' mode
> >>> of with-defaults just look at whether the leaf was
> >>> explicitly set and not the YANG default?
> >> The explicit mode should have logic like:
> >>
> >>    if (the user explicitly set it)
> >>        return it
> >
> > Phil
> >
> > I think that you are absolutely right that this mode should exist; I see it
as
> > a major, if not the major, requirement to emerge from RFC3535. But I
> > disagree that it is the only requirement; I think that there is another one,
an
> > operational one, I share certainly with Andy.
> >
> > Enterprise systems could not exist without configuration management; they
simply
> > have too many thousands of devices to configure by any other means.
> >
> > One key part of this is a three part system, a central store of data for
each
> > device, probably several versions for each, a pull protocol to get data from
> > a device and a push protocol, such that given a fresh from shrink-wrap,
> > manufacturer-supplied box, the push will create a replacement operational
box.
> >
> > Box A gets trashed, take a new one off the shelf, push the data to the new
box
> > and the service is restored.
> >
> > So the pull protocol must get everything that needs to be set to create the
> > operational box, regardless of which 'user' set it - CLI, SNMP,
Netconf,..... -
> > or when.
> >
> > I don't think YANG can help much here; it could have a substatement,
> > read-only, modified <true|false>, but really this is a Netconf protocol
> > requirement for the device manufacturer to support.
> >
> > I think it wrong to equate this mode with the one and only meaning of words
> > such as config.
> >
>
> I can agree with Phil that 'config' I did not set
> is not really config -- if the YANG and with-defaults
> draft specify the same thing correctly.
>
> But if it is not config when an instance exists
> because the server created it, then it must be
> operational state.  So it MUST be retrievable,
> in order to support applications (NETCONF was chartered
> to get away from screen-scraping).

Andy,

I agree, it MUST be retrievable.

For Configuration purposes,
I would prefer to stay with 'everything writable is config'
and what has been set (by anyone outside the server, not
as part of operational state or by server) is perforce a
subset of that, and Netconf has the option to
retrieve all or the subset.

For Operational purposes, most of the time, I need a combination
of items.  If I look at an OSPF interface, I want to know
- OSPF configured (explicitly set by some user)
- Active or Passive (probably default but I want to hear
the server's view, not some assumption that everything is
fine)
- timers (almost always default, but I really want to know
what the server is actually using)
- Adjacency (operational state)

and, magically, that is what I currently get.  It would be a
shame if YANG or Netconf required the whole LS database
to be retrieved just to give me the equivalent:-)

And of course, there will be times when this summary
does not resolve my issue, and yes, I will need every one
of the 100 or however many items there are in the server
relating to the interface.

Tom Petch

>
> I am not willing to accept that any leaf instance
> (defined as a leaf with a value != YANG default-stmt)
> can ever be inaccessible for retrieval.
>
> If the server has a value, and the client asks for it
> correctly, it MUST be returned via <get>, <get-config>,
> or <copy-config>.  That's what the standard says now, and
> I agree with it.
>
>
> > Tom Petch
>
> Andy
>
> >
> >> But really it works like:
> >>
> >>    if (there is a value in the config database)
> >>       return it  // since the user must have set it
> >>
> >> In neither approach are default values inspected.
> >>
> >> Thanks,
> >>  Phil
> >
> >
>
>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 01 Sep 2009 10:35:25 -0700

tom.petch wrote:
.....
> to be retrieved just to give me the equivalent:-)

It doesn't.
The <filter> parameter is mandatory to implement
for subtree filters.

> relating to the interface.

Yep -- nobody ever said the server should be forced to send
all the data all the time.  But the client MUST be able
to ask for all the data somehow, even if that is
not the default operation -- it still must be
the same operation on every server.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Tue, 1 Sep 2009 14:06:31 -0400

>retrieve all or the subset.

Here's a proposal:

Let's make "default" an error for "config false" data.

This means that operational data values cannot default
to a YANG-specified value.  If you want them, you must
emit them.

This should end the comments about having to read documentation to
find default values.

It should also clarify the role of default in a YANG module.

And it should cost almost nothing.

Thanks,
 Phil

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 01 Sep 2009 15:22:17 -0400

I have a strong suspicion that we are talking past each other.

The issue I believe Andy has, and I know I have, is with a "config true"
which is given a value by the system, but where that value is not 
reported to a client application either in a regular get or in get with 
all defaults.

If the system is using a value for a "config true" node,
and that value is not reported, and that value is not the model defined 
default value, then we have an operability problem.
If some systems report it one way, and some systems report it another 
way, then we probably have an interoperability problem.

 From the text below, I would have concluded that you were suggesting 
that the value the system is using should appear in a "config false" 
node, separate from the "config true" node used to set the value.  As I 
said to Juergen, I can live with that.  However, from your previous 
strident responses, I presume that is not what you intended to communicate.

Yours,
Joel

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

---

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

Joel M. Halpern wrote:
> said to Juergen, I can live with that.

I do not understand why, if the
data is tagged config=false, it is somehow less
potentially useful to the operator.
What is the correlation I am missing here?

What about the deviations and no-revision-date corner-cases?
I thought deterministic behavior across versions, platforms,
and vendors was our goal here.  I don't understand why
the functional requirements for network-related data retrieval
established through 2 decades of standards work should be
ignored, and the bar should be lowered for NETCONF.

In SNMP you can get an exact piece of data (get foo.1.2.3).
Not in NETCONF.  In SNMP, if foo.1.2.3 exists then you
can get its value, otherwise it does not exist. Simple yet powerful.
(modulo VACM, of course).

  However, from your previous

Andy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 01 Sep 2009 15:49:06 -0400

Andy, sorry, I have no idea what you are getting at.
I was trying to suggest again that having a "config false" node with the 
data, which is reported, would be a way to have the data reported.
I realize I am repeating myself, and apologize for that.
I was repeating myself because although when I said it last Phill had 
strongly objected to that approach, it is what he seems to be suggesting 
in the note I was responding to.

I think that this is somehow related to Phil's proposed new operation, 
which I also did not understand.  <get-operational-data> sounds to me 
like a <get> which happens to target only "config false" nodes.

Yours,
joel

---

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

> in the note I was responding to.

sorry -- I misread what you meant by your comment.

I cannot live with a solution where a
YANG object that is config=true,
but <*-config> operations do not work.

Ditto for a solution where
a YANG object that is config=false,
but <*-config> operations do work.

Maybe that is not what you are talking about either.

Andy

---

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

We are in agreement.  I was not suggesting either of those alternatives. 
  I would agree with you that those alternatives making the spec 
internally contradictory, and at the very best, confuse the reader. 
More likely they confuse a lot more and cause non-interoperability.

Joel

---

From: Phil Shafer <[email-masked]>
Date: Tue, 1 Sep 2009 16:18:27 -0400

>reported to a client application either in a regular get or in get with 

I believe this is a red herring.  There are no such nodes.  If you
believe such nodes exist, then we are truly talking past each other.
I will try in this email to describe why I believe this, and I hope
at the end you will agree.

>way, then we probably have an interoperability problem.

The delicate terms is "the system is using a value".  This is an
ambiguous term that may be the source of the trouble.  So let's
start with some precise terminology:

"assigned-by system" (ABS): a behavior where the system will,
  at validation time, assign values in the configuration database
  for leafs which are not given values.  If values were given before
  validation time, the system will not assign new values, but will
  honor these existing values.

"configuration default value" (CDV):  the default value used for
  configuration data.  If a list instance is created in the
  configuration database and the value for a leaf is not provided,
  then the CDV is the value which the system will use internally.
  This means that the behaviour of the running system using that
  CDV as the operational value is identical to the behaviour if
  that leaf had been explicitly configured with that value.  The
  CDV value must be a fixed value.

"operational default value" (ODV): the default value used for
  operational data.  This is the value used by the running
  system if a value was not configured.  It may not be fixed or
  easily described.  The value may be dynamic or even unpublished.

With these terms, we make the following rules:

(a) the YANG default statement can be used to provide a CDV.
(b) the YANG default statement cannot provide defaults for ODVs.
(c) the YANG default statement cannot provide defaults for ABS leafs.
(d) a server MAY choose to not send a leaf element if
    it is a configuration leaf ('config true') and the
    value of the leaf is the default value.
(e) ODVs MUST be sent for operational data, since the default
    statement applies only to configuration data.  In effect,
    operational data has no default values.
(f) ABS data is _real_ configuration data, since it appears
    in the configuration database and can be manipulated with
    the operation NETCONF/YANG operations.

>reported to a client application either in a regular get or in get with

If "given a value by the system" means ABS, then there are no such
nodes.  When the system assigns a value to an ABS leaf, that leaf
and value are now part of the configuration database, and that value
will be returned to any client application (with the proviso that
(d) allows the server to not send the CDV).

If by "given a value by the system" you really mean ODVs, where the
system is used a value for a leaf that was not configured, then the
ODV will be sent, since the server MUST sent ODVs.

>way, then we probably have an interoperability problem.

If we are talking configuration data, then any client can retrieve
any configuration data that has been configured (with the proviso
above).

Consider an example:

    module users {
        container users-top {
            list user {
                key name;
                leaf name { type string; }
                leaf password {
                    type string;
                    default "*";
                }
                leaf uid {
                    type uint32;
                    assigned-by system;
                }
                leaf full-name {
                    type string;
                }
                leaf last-login {
                    type data-time;
                }
            }
        }
    }

If I make a user like:

    <edit-config>
        ...
        <config>
           <users-top>
               <user>
                   <name>phil</name>
               </user>
           </>
        </>
    </>

then at validate time, the system will assign an appropriate "uid"
value.  It will not assign a password leaf in the database, but
when an entry is made for the user in /etc/master.passwd, the line
will start with "phil:*:".

If I get this user, I'll see:

    <top-users>
        <user>
            <name>phil</name>
            <uid>2005</uid>
        </user>
    </top-users>

If I do a <get-operational-data>, I may see the <last-login> element
with an appropriate value.  I will not see a <full-name> element,
since there is no appropriate value.

So I'm hoping you can agree that there is no ghost configuration
data.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Tue, 1 Sep 2009 16:26:16 -0400

>in the note I was responding to.

I strongly oppose mixing default values into the configuration
database.  If I get configuration data, I do not want default values.

>like a <get> which happens to target only "config false" nodes.

No, it's a module-specific get operation, that returns config false
nodes in addition to config true ones.

The interesting bits are how such a scheme would describe the rules
or constraints which are true for config data, but do not hold for
operational data.  For example, the duplex may be "full", "half",
or "auto" for config, but for operational data, would be "full",
"half", and "down".

The strong constraint of config data, which we need to construct
config data that plays by the model's rules, are less important for
operational data.  How do we model the interaction and overlap
between operational and configuration data?  So far, we've really
only worried about config data, since that's the greenfield for
NETCONF/YANG.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Tue, 1 Sep 2009 16:28:55 -0400

>but <*-config> operations do work.

I don't believe anyone is suggesting either of these concepts.

Thanks,
 Phil

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 01 Sep 2009 16:44:23 -0400

Well, I may be missing something, and others may disagree, but this 
looks like progress to me.

They key for me has always been how ODV (Operational Default Values as 
you describe them) show up.  I apparently misunderstood you as not 
wanting them reported in any <get> of any kind.

As long as they show up somewhere that is reasonably describable, I am 
happy.  To drive this down a level of detail, if we have a config 
variable ifMtu, and if in the absence of configuration it uses an ODV, 
how does the client (management system) get that ODV?  (I can think of 
several possible answers, but I think we need to pick one.)

Yours,
Joel

PS: To avoid the temptation to confuse them with defaults, would it make 
sense to render ODV as Operationally Determined Value, i.e. the device 
operation determined a value due to the absence of the configuration?

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 01 Sep 2009 16:51:02 -0400

Based on the other note I responded to, I misunderstood you.  I 
apologize, and lets try to sort out this idea.

I must have missed some subtlety in the netconf spec.  I am not sure why 
there is a need for a module specific operation, or how this operation 
differs from <get> which is defined to return all running configuration 
and device state information.  (I tend to presume that ODVs, and other 
operational information, appear only in the running config?)

I am confused by your question about different data constraints. 
presumably, the config variable and the operational state variable are 
different.  Operation state variables are "config false", will tend to 
have few or no constraints (MUST statements), and will have value sets 
that cover the operationally availble values.

Yours,
Joel

---

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

> (b) the YANG default statement cannot provide defaults for ODVs.

why is there any correlation between the YANG
config-stmt and the YANG default-stmt?
This is the first I've heard that.

>     value of the leaf is the default value.

what does config=true have to do with it?

does (c) + (d) somehow == "the server can
omit any leaf it set instead of the client"?
If not, no problem.  If yes, big problem.

If the server set it, then it isn't 'explicitly set'.
That seems obvious.

But that is precisely what the 'explicit' mode allows to be filtered out.
So please explain how you reach the conclusion, that
filtering out everything except the explicitly set leafs
somehow is covered by the YANG draft text.

>     operational data has no default values.

this is not what YANG defines for a default+config=false.
I prefer what is already in the spec.

Andy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 01 Sep 2009 17:05:11 -0400

?  You seem to be asking for "default value" statements to be allowed on 
"config false" nodes.  Why?  That is either a meaningless use of 
default, or it describes a constant node.  I suppose that there are some 
corner cases where a constant node might be useful, but it is quite a 
stretch.

I hope I have once again misunderstood.
Yours,
Joel

Andy Bierman wrote:
...

---

From: Andy Bierman <[email-masked]>
Date: Tue, 01 Sep 2009 14:09:26 -0700

> corner cases where a constant node might be useful, but it is quite a

you are right.

I sometimes confuse old SNMP days
where DEFVAL was not binding, and for
some read-only state objects, was relevant.

never mind...

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 01 Sep 2009 14:28:43 -0700

> some read-only state objects, was relevant.

wait a minute...
I was thinking that default was the value
that applied if the server does not return it,
but if the server returned a value, it could
be different than the default.

   leaf operStatus {
      config false;
      type enumeration {
        enum normal;
        // followed by lots of abnormal status enums
      }
      default normal;
   }

In this case, it is really useful to omit all
the status leafs that have a value of 'normal'.
But default is not defined that way now.
However, the same justification for
omitting config leafs applies to state leafs.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Tue, 1 Sep 2009 17:16:10 -0400

>If the server set it, then it isn't 'explicitly set'.

Nope, if the server set the value for an ABS leaf, then that value
is real config data and must be treated as such.  YANG does not
allow the server to not emit configuration data, unless the value
is the default value.  Since ABS leafs should not have default
values, there is no overlap.  ABS leafs are config data, and
config data should be emitted.

If the term "explicit" is confusing to you, please suggest a new
name to use in the with-defaults draft.

>somehow is covered by the YANG draft text.

If a leaf is created in the configuration database, the server can
always emit it.  Either the leaf will have the CDV (which YANG
allows the server to emit), or the leaf will have a non-CDV (which
the server MUST emit).

If the leaf was not created in the database, then it has no value.
YANG allows the server to emit the default value, but does not
require it.

So if the leaf "foo" has a default of "3", and a client sets foo
to 3, then a server can still emit the value "3".  This is the
"explicit" behavior, where the server emits values that the user
has set, without caring whether those values are the CDV.

HTH....

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Tue, 01 Sep 2009 14:55:20 -0700

> config data should be emitted.

So an ABS leaf will always be retrievable on every server
because it does not have the YANG default value.

> name to use in the with-defaults draft.

Then with-defaults needs a lot of fine-tuning,
because it just says:

   o  report-all: All default data is always reported.
   o  trim: Values are not reported if they match the default.
   o  explicit: Report values if they are explicitly set.  For state
      data this has the same effect as report-all

The 3rd bullet is clearly wrong, because 'explicitly set' is never defined,
and you 'set by client or startup' is not what it means anyway.
It really means

   o  explicit: Report all leaf values, including those which are explicitly set,
      even if they are equal to the default value.  For state
      data this has the same effect as report-all.

Seems like for all data it has the same effect as 'report-all'.
What is filtered-out?  Leafs that have no instances?
We know that.

> allows the server to emit), or the leaf will have a non-CDV (which

I prefer to stick with the 'YANG default-stmt == default'
definition we have now.

> has set, without caring whether those values are the CDV.

yes -- the server MAY choose to emit a leaf with its
YANG default value.  Agreed.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 01 Sep 2009 15:00:38 -0700

Hi Phil,

>       data this has the same effect as report-all.

I still got this wrong.
Can you write some normative text so the
capability makes sense?  A capability
where the server MAY do all the things the
protocol says it can do is pointless.

Let's get the normative text to say there are
actual differences between the 3 modes,
or remove redundant modes.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Tue, 1 Sep 2009 21:26:15 -0400

>because it does not have the YANG default value.

Yes.

>I prefer to stick with the 'YANG default-stmt == default'

This lack of common meaning has drawn out a lot of wasted
email.  I don't think we can use the definitions we have
now without some additional clarification.

>YANG default value.  Agreed.

Rah.  We're back to agreeing on what we agreed to when
we wrote the dang thing.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Tue, 01 Sep 2009 19:00:42 -0700

> now without some additional clarification.

I like the current meaning because
it is a single value that MUST be valid for the data type.
It is a trivial implementation detail to exchange 'fred'
for <foo>fred</foo>, (assuming you consider having a perfect
view of the schema definitions used by the current server session
to be trivial).

> Rah.  We're back to agreeing on what we agreed to when

no, because if the definition of explicit in with-defaults
was never right, so we were using different definitions
of 'explicitly set'.  Try these definitions

A default is defined as YANG default-stmt value for
YANG modules, and the 'default' attribute value for XSD:

   o  report-all: All default data MUST be reported.
   o  trim: Default data SHOULD NOT be reported.
   o  explicit: Default data MAY be reported.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 2 Sep 2009 02:48:01 -0400

WashamFan writes:
>Below is my interpretation:

Here's my take:

report-all: The server MUST send the leaf element if the leaf has
a configured value or a default value.  If no value has been
configured, the default value is used as the leaf value.

trim:  The server MUST send the leaf element if the leaf has a
configured value and that value is different than the default value.

explicit:  The server MUST send the leaf element if the leaf has a
configured value.

Would "configured" be more meaningful than "explicit"?

Thanks,
 Phil

---

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

o  report-all: All default data MUST be reported.
     o  trim: Default data MUST NOT be reported.
     o  explicit: Default data MAY be reported. I.e., default data
         explicitly set by the client MUST be reported.

It is what I've been understood :with-defaults. And it is unambiguous.

Any comments?

washam

---

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

Hi all,

>     the operation NETCONF/YANG operations.

Phil, are you proposing that this text be added to the YANG draft to then be 
used to help define 'default' behavior?

David

---

From: Andy Bierman <[email-masked]>
Date: Wed, 02 Sep 2009 03:15:11 -0700

> Would "configured" be more meaningful than "explicit"?

provide a definition for 'configured', and we shall find out.

Andy

---

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

>provide a definition for 'configured', and we shall find out.

So in previous email, we had the definition:

||  "configuration default value" (CDV):  the default value used for
||    configuration data.  If a list instance is created in the
||    configuration database and the value for a leaf is not provided,
||    then the CDV is the value which the system will use internally.
||    This means that the behaviour of the running system using that
||    CDV as the operational value is identical to the behaviour if
||    that leaf had been explicitly configured with that value.  The
||    CDV value must be a fixed value.

So "configured" would mean something like:

configured value (CV): the value for a leaf that has be created or
  set in the configuration database.  A CV is typically created or
  set by an explicit action on the part of a user or client
  application.  The value of an ABS leaf is considered a CV but a
  default value for a leaf that has not been created in the database
  is not a CV.

Hmmm..... problems with the CDV definition above.  If the default
value from the YANG module is not a valid operational value, then
the third sentence is nonsense.  For example "auto" is a great
default value for "duplex" but is not a valid operational value.
How about:

"configuration default value" (CDV):  the default value used for
  a leaf node with "config" set to "true".  If a list instance
  is created in the configuration database and the value for a
  leaf is not provided, then the CDV is the value which the system
  will use internally.  This means that the behaviour of the
  running system using that CDV as the internal value is
  identical to the behaviour if that leaf had been explicitly
  configured with that value.  The CDV value must be a fixed
  value.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Wed, 2 Sep 2009 15:13:07 -0400

David Partain writes:
x>Phil, are you proposing that this text be added to the YANG draft to then be 
>used to help define 'default' behavior?

Yes, with the change from my last email.  I'm normal wary of
overcrafting words, but the confusion and frustration need
to be solved, so if clear and crisp terminology can help,
I'm more than happy to see it.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 02 Sep 2009 13:01:42 -0700

> I'm more than happy to see it.

I don't think everybody wants or needs a complex
definition of all kinds of data, with lots of
new terms to exactly fit your definition of all
this data.

Not everybody wants to do build the exact same
application(s) that you have in mind.
It seems like it it exactly matches your server,
it is a must-have, and otherwise it should be
an optional feature that the protocol can do without.

A brand new complex and confusing modeling language,
plus incomplete data-sets, are not a combination
for robustness, which is what I need in the
applications of interest to me.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 2 Sep 2009 15:24:17 -0400

>operational information, appear only in the running config?)

This is actually the part I want to avoid.  If I've got an "mtu"
leaf, can't the operational value of that leaf just be available
from a different source, but in the same hierarchy/name?  I dislike
the idea of "mtu-configured" and "mtu-right-now".  I'd rather get
the config with <get-config> and the operational data with
<get-operational-data> and keep the same leafs, reusing them to
hold operational values.

This idea clearly needs some work.  But having to double every leaf
in every YANG module to get operational values makes my skin crawl.

Thanks,
 Phil

---

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

> an optional feature that the protocol can do without.

Well, I suspect we all approach it this way, since our applications
shape our minds. :-)

> applications of interest to me.

I am in favor of simplicity, too.

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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 02 Sep 2009 14:31:23 -0700

> I am in favor of simplicity, too.

The IETF has a different definition of simplicity
than the one most people know.

I hardly think the authors and the people
working on the spec for 2 years straight
are the ones to judge whether YANG is simple or not.

I also have a different definition of 'interoperability'
and 'robustness' than the WG.  I think layering matters.
We designed NETCONF with an independent content layer on purpose.
The protocol was supposed to have content-neutral operations
on the suitcase full of data.

My concern about forming a NETMOD WG in the first place was
that we would take forever to design (on paper) what
should be the perfect DML for standards-base management,
all before we barely standardize 'hello world'.

There is nothing interoperable about N proprietary CLIs,
so following 'the CLI' instead of SNMP for guidance
on interoperability is never going to work.

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 2 Sep 2009 14:04:26 -0700

Hi -

> To: "Andy Bierman" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, September 02, 2009 12:11 PM
> Subject: Re: [netmod] proposal: no defaults for non-config data
...
> default value for "duplex" but is not a valid operational value.

This is a good example of where trying to munge the configuration
and operational values together would be a bad idea.  A configuration
backup should retrieve "auto" (if that is what has been configured)
rather than whatever the operational value is at the moment.  Otherwise,
a subsequent "restore" of the configuration could end up doing the
wrong thing.

Duplex, interface speeds, and protocol options are just a few examples
where things analogous to "auto" are legitimate configurations, and need
to be kept distinct from (useful) operational data about what the device /
interface is actually doing at the moment.  This will happen whenever
there is a legitimate need to configure something to make its own operational
decision from some set of possibilities.

Randy

---

From: David Partain <[email-masked]>
Date: Thu, 3 Sep 2009 13:33:59 +0200

Greetings,

On Wednesday 02 September 2009 22.01.42 Andy Bierman wrote:
> Phil Shafer wrote:
> > David Partain writes:
> > Phil, are you proposing that this text be added to the YANG draft to
> > then be used to help define 'default' behavior?
> >

We've been arguing about things surrounding this terminology for weeks now.  
If definitions will help clarify what we all mean so that we stop talking 
past each other, then they may well be worth adding.  I'm waiting to see what 
others say about the text that Phil is suggesting.

> an optional feature that the protocol can do without.

Let's discuss text, please, and keep this discussion constructive.  
Finger-pointing doesn't seem helpful to me.

> applications of interest to me.

Repeatedly claiming that YANG is too complex doesn't solve anything.  If you 
(or anyone else) has suggestions for simplification, bring 'em on.

Cheers,

David

---

From: David Partain <[email-masked]>
Date: Thu, 3 Sep 2009 13:43:51 +0200

Hi,

Phil suggested some definitions to use in other discussions.  Just to make it 
easier to follow, here's the updated text (based on the subsequent mail 
thread) and a new thread.  Phil, please sanity check that I got it all..

Comments on this text?  Do people want to put it into the YANG spec (arch 
doc?) or not?

Thanks, 

David

"assigned-by system" (ABS): a behavior where the system will, at
validation time, assign values in the configuration database for
leafs which are not given values.  If values were given before
validation time, the system will not assign new values, but will
honor these existing values.

"configuration default value" (CDV):  the default value used for
a leaf node with "config" set to "true".  If a list instance is
created in the configuration database and the value for a leaf is
not provided, then the CDV is the value which the system will use
internally.  This means that the behaviour of the running system
using that CDV as the internal value is identical to the
behaviour if that leaf had been explicitly configured with that
value.  The CDV value must be a fixed value.

"operational default value" (ODV): the default value used for
operational data.  This is the value used by the running system
if a value was not configured.  It may not be fixed or easily
described.  The value may be dynamic or even unpublished.

"configured value" (CV): the value for a leaf that has be created
or set in the configuration database.  A CV is typically created
or set by an explicit action on the part of a user or client
application.  The value of an ABS leaf is considered a CV but a
default value for a leaf that has not been created in the
database is not a CV.

(c) the YANG default statement cannot provide defaults for ABS
leafs.

(d) a server MAY choose to not send a leaf element if it is a
configuration leaf ('config true') and the value of the leaf is
the default value.

(f) ABS data is _real_ configuration data, since it appears in
the configuration database and can be manipulated with the
operation NETCONF/YANG operations.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 03 Sep 2009 09:21:41 -0400

I find these terms and definitions very helpful, and would like to see 
them in the YANG document itself.

As a minor tweak, I suggest reading ODV as "Operationally Determined 
Value" meaning that when a value is not configured, the system will 
operationally determine a value to use.

Yours,
Joel

---

From: Andy Bierman <[email-masked]>
Date: Thu, 03 Sep 2009 08:26:46 -0700

> (or anyone else) has suggestions for simplification, bring 'em on.

Repeatedly insisting that YANG is simple, and
ignoring the technical issues I keep raising
doesn't solve anything either.

Make all leaf instances available for retrieval on
all servers at all times, instead of trying to come
up with complex mechanisms and excuses for why the client
doesn't need to retrieve all data from the server.

Andy

---

From: Mark Ellison <[email-masked]>
Date: Thu, 3 Sep 2009 12:53:48 -0400

Hi David,

> Comments on this text?  Do people want to put it into the YANG spec (arch

After catching up on the long and winding NETMOD email threads, the
following text looks like real progress.  I have added notes inline
where some minor edits may improve readability and consistency.
Hopefully these edits stay consistent with intended meanings.

> leafs which are not given values.  If values were given before

s/which are not given values/which are not given a configured value
and for which no CDV applies/

> created in the configuration database and the value for a leaf is

s/the value for/a configured value (CV) for/

> behaviour if that leaf had been explicitly configured with that

s/behaviour if that leaf/behaviour of the running system if that leaf/

> value.  The CDV value must be a fixed value.

s/configured with that value/configured with the CDV/

> if a value was not configured.  It may not be fixed or easily

s/if a value was not configured/if a configured value (CV) was given
and no CDV applies/

> configuration leaf ('config true') and the value of the leaf is

s/the default value/the configured default value (CDV)/

Regards,

Mark
-------

---

From: "tom.petch" <[email-masked]>
Date: Fri, 4 Sep 2009 14:01:09 +0200

---- Original Message -----
From: "David Partain" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, September 03, 2009 1:43 PM
Subject: [netmod] Terminology discussion (was Re: proposal: no defaults
fornon-config data)

> Comments on this text?

Terminology!

'Configuration database' is not defined in YANG or NETCONF (NETCONF
even hints that this is something on the client).  Is this a reference to
the running configuration datastore?

There is a mixture of 'leaf', 'leaf instance', 'list instance'; I think leaf
node
should only be part of the schema tree, using instance for data tree.  Leaf
nodes
have config and default substatements, instances have values.

Tom Petch

>                     Do people want to put it into the YANG spec (arch
> doc?) or not?
>
> Thanks,
>
> David
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 07 Sep 2009 10:24:12 +0200

> the running configuration datastore?

Yes, this is an important point. Moreover, "validation time" is in fact
"commit time" - the device can (partly) validate candidate or startup
configuration without caring about assigned-by.

> have config and default substatements, instances have values.

I understand that "object instance" is part of the SNMP heritage but
since in NETCONF/NETMOD these instances are always XML elements,
"element" would IMO be clearer. In XML texts, the term "instance" is
often used to mean the entire XML document. Perhaps we could use

"Element <foo> is an instance of (schema) node 'foo'."

Lada

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "tom.petch" <[email-masked]>
Date: Tue, 8 Sep 2009 10:01:18 +0200

----- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
Sent: Monday, September 07, 2009 10:24 AM

> "Element <foo> is an instance of (schema) node 'foo'."

Yes, that looks good; I wonder if we can get the document editors to
agree.

In passing, I think of instance as coming from object class and object
instance, rather than from SMI in particular, but providing a useful
generic term even when the language is not truly O-O.  But element
is certainly a good fit here.

Tom Petch

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 08 Sep 2009 12:36:49 +0200 (CEST)

> > > have config and default substatements, instances have values.

A tree is built up of nodes.

In the schema tree, there will be schema nodes.

In the data tree, there will be data nodes.

Sometimes the term instance is used, as in "A leaf node exists in zero
or one instances in the data tree".

> Yes, that looks good; I wonder if we can get the document editors to

We never talk about named leafs or instances or elements, except maybe
in some example.  So we would never use the "<foo>" syntax.  That
leaves us with the generic term "element", and we use that term only
when we talk about the XML encoding.  I think it would be confusing to
use the same term for both things.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 08 Sep 2009 13:49:55 +0200

> In the data tree, there will be data nodes.

This is not waht Terminology section says:

o  data node: A node in the schema tree that can be instantiated in a
   data tree.  One of container, leaf, leaf-list, list, and anyxml.

IMO it is indeed useful to have data nodes as a subset of schema nodes
in the schema tree. The problem is how to call the "instance of a data
node in the data tree" - reusing "data node" here may lead to confusion.

Lada 

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Phil Shafer <[email-masked]>
Date: Mon, 14 Sep 2009 15:16:53 -0400

>node in the data tree" - reusing "data node" here may lead to confusion.

Can we agree that this is a bug in the spec?  A data node is a node in
the data tree that blah blah blah...

Thanks,
 Phil

---

From: "tom.petch" <[email-masked]>
Date: Tue, 15 Sep 2009 12:43:01 +0200

----- Original Message ----- 
From: "Phil Shafer" <[email-masked]>
Sent: Monday, September 14, 2009 9:16 PM

> the data tree that blah blah blah...

No:-)

There is a subset of schema nodes which may be instantiated in the data tree
and that subset is defined as data nodes.  I think that that concept needs a
term and it has it, i.e. data nodes.

If you now use data nodes for some other purpose, then you will need  a
term for what is now referred to as data nodes and data nodes has a 
certain logic about it.

Tom Petch

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 15 Sep 2009 13:56:51 +0200

> term for what is now referred to as data nodes and data nodes has a 

+1

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Phil Shafer <[email-masked]>
Date: Tue, 15 Sep 2009 09:29:47 -0400

>term for what is now referred to as data nodes and data nodes has a 

"data nodes" should be in the "data tree" and "schema nodes" should
be in the "schema tree".  I'm not sure that we have an appropriate
term for saying "this data node is an instance based on that schema
node", but we should never say that a data node is a "node in the
schema tree".

Thanks,
 Phil

---

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

> be in the "schema tree".  I'm not sure that we have an appropriate

But "data nodes in schema tree" are used in the YANG draft and not only
in the terminology section. For instance, in SEc. 4.1

"The hierarchy can be augmented, allowing one module to add data nodes
to the hierarchy defined in another module."

The "hierarchy defined in another module" is clearly the schema tree.

> node", but we should never say that a data node is a "node in the

Yes, a good term for this (important) relationship would be very useful.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C