Subject: Re: [netmod] meaning of default

From: David Partain <[email-masked]>
Date: Tue, 1 Sep 2009 13:36:10 +0200

On Monday 31 August 2009 11.26.16 David Partain wrote:
> On Monday 24 August 2009 15.33.06 Phil Shafer wrote:
> > Juergen Schoenwaelder writes:
> > >we need to put this
> > >discussion somehow to an end.
> >
> > +1
>
> I completely agree.  I'm trying to read through huge heaps of email to try
> to figure out what the right question to ask is.  Stay tuned.

Hi folks,  

I'd like this thread closed, too.  The focus of this discussion should now be 
on the mail with the subject "Issue: interpretation of 'default'" 
(http://www.ietf.org/mail-archive/web/netmod/current/msg03821.html).

Cheers,

David

---

From: Andy Bierman <[email-masked]>
Date: Tue, 01 Sep 2009 07:04:33 -0700

> (http://www.ietf.org/mail-archive/web/netmod/current/msg03821.html).

I wish this was a linear process as well but
engineering doesn't work that way.
Sometimes it takes a few tries before you really
understand why a design is broken.

How does this YANG-default as a substitute for data retrieval works
when there are deviation-stmts that change the
default, or a YANG module with no revision-stmts
adds a default over time?  IMO, it doesn't.
The entire premise that YANG default-stmts
are equivalent to runtime data is incorrect.

Note that section 10 clearly states that a default
may be added after initial publication, but that is all.
Once a leaf is published with a YANG default-stmt,
it MUST never be changed or removed.

This makes it even more unlikely that one will
be able to trust the default-stmt value across all
versions of all platforms, because this CLR will be ignored.

So I prefer 'report-all', and don't care about the server
wasting bandwidth while doing its job.

> David

Andy

---

From: Phil Shafer <[email-masked]>
Date: Tue, 1 Sep 2009 13:58:05 -0400

>wasting bandwidth while doing its job.

But others (including me) do not prefer this.  The "with-defaults"
capability gives you the means to make the world work the way you
want it.  Since that's your preference for your applications, you
should simply use 'report-all' for all your config requests.

I guess what I find troubling is your view is that the world MUST
work your way or else it is broken.  The world isn't that fragile.
Giving the device sufficient flexibility to work in their normal,
native way is a good thing.  Let the marketplace decide which default
scheme wins the most converts.  The rest of the world should be
forced to follow your preference.

Thanks,
 Phil

---

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

> forced to follow your preference.

I see the situation just the opposite.

The :with-defaults capability is optional-to-implement.

You want to force your way of thinking on everybody
else by insisting that your server does not need
to ever make the full data-set available to any client,
or to even let the client know what sort of 'server-pruning'
is being done.

You already agreed it is not because there is
some implementation burden, but because
the client 'does not want the data'.  This is
not always true, and several people (including me)
want a standard that forces server-created nodes
to be retrievable on every implementation of
a YANG module.

Andy

---

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

>or to even let the client know what sort of 'server-pruning'

The current scheme in YANG allows the server to behave in any of
the three styles listed in the with-defaults draft.  We have
sufficient flexibility to allow you to work the way you want, and
to allow others to work the way they work.  This is good.

Thanks,
 Phil

---

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

> to allow others to work the way they work.  This is good.

no it does not allow for the 3 current schemes.
That is nonsense.  The draft clearly says that
database = leafs + YANG default-stmt leafs.
There is no text then even suggests anything
other than that.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 01 Sep 2009 21:58:00 +0200 (CEST)

> There is no text then even suggests anything

I don't understand this.  I agree with Phil that the current scheme
allows the server to implement any of the 3 modes in the with-defaults
ID.  The reason it does is that it says:

  A NETCONF server that replies to a <get> or <get-config> request MAY
  choose not to send the leaf element if its value is the default
  value.  Thus, a client that receives an <rpc-reply> for a <get> or
  <get-config> request, MUST be prepared to handle the case that a
  leaf node with a default value is not present in the XML.  In this
  case, the value used by the server is known to be the default value.

/martin

---

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

>   case, the value used by the server is known to be the default value.

We've been going in circles so much, we must be getting dizzy.

1) this is not even true for YANG-default-stmt values,
   because of deviations and no-revision-date modules.

2) a server-created leaf that does not contain the
   YANG-default-stmt value is not a default, so this text
   is irrelevant wrt/ omitting other server-created instances
   from <get*> operations.  That is what is allowed in :explicit
   mode of the :with-defaults capability.  So this assertion
   that :explicit is somehow covered, even if the server
   does not implement :with-defaults is false.  It is only
   covered *if* the server implements and advertises the
   :with-defaults capability.

Andy

---

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

>    because of deviations and no-revision-date modules.

A deviation may change the leaf's default value, so the text still
applies.  (this may or may not be a good idea, but that's a sepatate
issue).

no-revision-date modules might be an issue, but I believe it can be
solved (see Phil's email).

>    YANG-default-stmt value is not a default

Agreed.

>    so this text
>    mode of the :with-defaults capability.

Is it?  If so, the :with-defaults capability needs to be fixed.  Wait
- you and I at least already agreed that it should be fixed.

>    So this assertion

Here I disagree.  If the server does not implement :with-defaults, the
client knows what it means if a leaf with a default statement is not
present in the reply.

/martin

---

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

>We've been going in circles so much, we must be getting dizzy.

We're going in circles, because you keep repeating the same false
statements.  Please read the text Martin and I keep posting.

>   because of deviations and no-revision-date modules.

A deviation is a claim from the device that it is behaving
in a non-standard way.  It is making an attempt to tell
you how broken it is, but you cannot claim that because
we have a mechanism for a device to announce this broken-ness,
we lack a standard way to behave.

>   from <get*> operations.

An ABS leaf is not a default, and such a leaf cannot have
a default statement.  Once the leaf is created, it is normal
config data, but since there's no default value, the server
MUST emit the value for that leaf.

>That is what is allowed in :explicit

This is simply not true.  YANG allows the explicit behavour
in a way that it unlinked to with-defaults.  In addition,
this issue is unrelated to "assigned-by system".

The YANG spec says that if the value is the default value, the
server may choose to not emit it.  The "trim" behavior avoids
emitting leafs when the value is the default value.  The explcit
behavior emits values if the value was set by the user.  Both are
allowed under the text that Martin and I continue to point you to.
Please read it and let's stop circling this particular rat hole.

Thanks,
 Phil

---

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

> client knows what it means if a leaf with a default statement is not

There is no disagreement about leafs that contain
the YANG default statement value.  Move on.

As long as the server does not omit any leaf instance
that is not the YANG default statement value, there is
no problem.  Right?

Andy

---

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

Hi all,

We're treading in and out of NETCONF territory...

So, :with-defaults supports three ways of handling defaults (quoting...)

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

Andy argues that YANG cannot support these three different modes.  Martin has 
agreed that there are issues that need to be addressed, but not that it's 
broken in the way Andy claims.  I see two things that need to happen:

1. If there are problems in the :with-defaults document, they should be fixed 
in NETCONF.  Proposals are, I'm sure, welcome.

2. If there are problems in the YANG spec that make it impossible (I'm 
unconvinced) to support all three, please provide textual proposals of what 
needs to change.

Thanks.

David

---

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

----- Original Message -----
From: "David Partain" <[email-masked]>
Sent: Wednesday, September 02, 2009 9:00 AM

> the same effect as report-all

Depends what you mean by 'explicitly set'.  If it is only by Netconf, (which
is what the with-defaults I-D suggests to me)
then I think this too narrow to be useful.  I want it to include CLI, SNMP
etc since this is the data that needs to be available for configuration
backup/restore, as Randy referred to.

But if it includes data set by operations - IP FIB, Bridge forwarding table,
BGP RIB, OSPF adjacencies and LS database - then I find that too
wide to be useful.

I see this last case as yang independent; there is nothing in yang that records
whether or not something has been explicitly set.  It is currently just a matter
for Netconf.

Tom Petch

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 2 Sep 2009 14:00:36 +0200

> unconvinced) to support all three, please provide textual proposals of what 

I like to find agreement that NETCONF/YANG lacks proper mechanisms to
deal with the distinction of configuration data and operational state
data called out for by the operators in RFC 3535.

If we can agree on this, we can discuss what needs to be done to solve
this problem. For YANG, this might imply that "config true/false" is
too simplistic. For NETCONF, it might mean that three different ways
to deal with-defaults are not needed - instead we create a proper and
clean way to retrieve operational state separately from config state.

But the first step is to agree that the problem is of a much more
fundamental nature and requires fixes affecting both NETCONF and
NETMOD.

/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: David Partain <[email-masked]>
Date: Wed, 2 Sep 2009 16:23:27 +0200

Howdy,

On Wednesday 02 September 2009 14.00.36 Juergen Schoenwaelder wrote:
> > - explicit: Report values if they are explicitly set.  For state data
> > this has the same effect as report-all
> >
> > Andy argues that YANG cannot support these three different modes.  Martin
> > has agreed that there are issues that need to be addressed, but not that
> > it's broken in the way Andy claims.  I see two things that need to
> > happen:
> >
> > 1. If there are problems in the :with-defaults document, they should be
> > fixed in NETCONF.  Proposals are, I'm sure, welcome.
> >
> > unconvinced) to support all three, please provide textual proposals of
> > what needs to change.
>

And I think that discussion is appropriately happening in "Configuration Data 
versus Operational State Data versus Statistics".  Thank you for writing 
that.

> fundamental nature and requires fixes affecting both NETCONF and

Fair enough.  See you in the other thread.  We'll have to revisit this one 
later, though...

Cheers,

David

---

From: "tom.petch" <[email-masked]>
Date: Wed, 2 Sep 2009 15:53:34 +0200

---- Original Message ----- 
From: "Juergen Schoenwaelder" <[email-masked]>
To: "David Partain" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, September 02, 2009 2:00 PM

<snip>
> data called out for by the operators in RFC 3535.

Yes, I agree

I would look to a three way split, adding statistics, as RFC3535 suggests, 
but  a two-way split would be good progress.

Tom Petch