Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST ***CALL for draft-ietf-netconf-with-defaults-07.txt

From: Phil Shafer <[email-masked]>
Date: Thu, 6 May 2010 09:58:53 -0400

Ladislav Lhotka writes:
>So how about moving the "basic-mode" announcement to RFC 4741bis and
>dealing with "also-supported" and the modifications to the existing
>operations in a separate document?

I don't see this as fitting in the "bugs and clarifications" charter.

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 06 May 2010 16:30:13 +0200

> I don't see this as fitting in the "bugs and clarifications" charter.

But what's the alternative? Will an implementation be considered
4741bis-compliant if it entirely ignores with-defaults without stating a
compelling reason?

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 6 May 2010 17:38:43 +0200

> I don't see this as fitting in the "bugs and clarifications" charter.

With 4741, your client does not know what the defaults handling mode
of a server is. I consider this a bug. Lada's suggestion removes the
fuzziness we have, which I think is a good thing. And you usually like
to have precise semantics.

/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, 06 May 2010 09:11:17 -0700

> to have precise semantics.

The RFC that contains with-defaults is not important.
The conformance already says SHOULD implement.
Even if we were on schedule, rearranging the deliverables
would be a super-low priority.  But since we are collectively
years behind schedule, it seems like a really bad idea.
Whether a server advertises :with-defaults or not has
nothing to do with which RFC contains the text.

IMO, report-all needs to be mandatory because every server
can support it.  No matter what defaults mode is used,
every implementation of every NETCONF server
knows the difference between its own default and a non-default,
and knows its own total set of leafs.

> /js
Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 06 May 2010 09:55:50 -0700

> 4741bis-compliant if it entirely ignores with-defaults without stating a

It means that the server vendor does not think its
customers need that functionality.

The current solution is already decoupled to allow what you want.
Only normative text stands in the way.

If the server does not advertise the <with-defaults> YANG module,
then a client won't use that module.  Since the :with-defaults capability
is separate, a server could advertise just that URI to announce
its basic-mode. 

Summary of changes:
   - change RFC conformance from SHOULD to MUST implement
   - make advertisement of :with-defaults basic-mode MUST implement
   - make implementation of report-all SHOULD implement
   - make implementation of the YANG module SHOULD implement

IMO, this addresses your concerns without rearranging any drafts,
and without changing the SHOULD conformance we already had
in place for everything but basic-mode.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Thu, 6 May 2010 10:19:58 -0700

> and knows its own total set of leafs.

I'm OK with a mandatory report-all if, and only if, tagging defaults is allowed

K.

---

From: Andy Bierman <[email-masked]>
Date: Thu, 06 May 2010 10:40:17 -0700

> I'm OK with a mandatory report-all if, and only if, tagging defaults is allowed

You haven't explained why operators need this meta-data
added to the payload and lowering the bandwidth utilization.
It seems to me an operator would rather have other meta-data
from the YANG module, such as the description-stmt.

I understand the dumb MIB walker / thin client argument.
These have utility and have existed in SNMP for decades.
These tools display the identity and value of each object.
I don't understand the problem that the wd:default="true"
data solves.

My proposal was addressing Lada's legitimate concern,
which has nothing to do with tagging the defaults.
It is not hard for the server to advertise its default basic-mode,
and this could help clients optimize code and better utilize
the results of get/copy operations.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 6 May 2010 19:58:22 +0200

On Thu, May 06, 2010 at 06:55:50PM +0200, Andy Bierman wrote:
> Ladislav Lhotka wrote:
> > Phil Shafer p????e v ??t 06. 05. 2010 v 09:58 -0400:
> >   
> >> Ladislav Lhotka writes:
> >>     

For what it is worth, I believe the announcement how defaults are
handled should be part of 4741bis. Knowing how defaults are handled by
a server is crucial for using NETCONF and the announcement itself
really is not a big deal.

/js

---

From: Phil Shafer <[email-masked]>
Date: Thu, 6 May 2010 13:44:55 -0400

>added to the payload and lowering the bandwidth utilization.

Bandwidth utilization is hardly a key issue for report-all.

>from the YANG module, such as the description-stmt.

The description statement is for implementors.  I don't see
this as vital meta-data.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Thu, 6 May 2010 14:00:49 -0400

>really is not a big deal.

I disagree, since I don't want my app to even care about how the
server is handling defaults.  If I have to special case this in my
app-side code, something is very wrong.

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 6 May 2010 20:30:43 +0200

> app-side code, something is very wrong.

I just do not know how to write an app that deals in a sensible way
with servers that deal with defaults differently. Perhaps I am just
dumb. Then I vote for an appendix that explains how that can be done
to be added to 4741bis.

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 06 May 2010 11:35:50 -0700

>> app-side code, something is very wrong.

First you argue that every client MUST be able to accept
wd:default="true" attributes in RPC replies, and now you are saying
you don't want a client to ever care about defaults.
Which is it?

> dumb. Then I vote for an appendix that explains how that can be done

Why does it matter which document contains with-defaults?
I don't want to waste any time going over text that has already
been approved by the WG, and gone through 2 WGLCs.
The 4741bis work is already behind schedule, and nobody seems
interested in resolving the open issues already holding up that draft.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 6 May 2010 14:31:16 -0400

>you don't want a client to ever care about defaults.

I'm arguing Kent's point, that if you add this default stuff into
normal config you need a way to flag it both so the client knows
that it is, and so the server can safely discard it.

My personal take is that w-d is misguided, but if you are going to
do it, make it work in a safe way that won't turn normal
config on the box into a bloated, default-laden mess.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Thu, 6 May 2010 14:43:33 -0400

Juergen Schoenwaelder writes:
>with servers that deal with defaults differently.

I think the sensible way is also the easy way.  The YANG module
lists the default value; if your app is happy with those values,
then it need not send that leaf; if your app wants another value,
then it sends that leaf with the value.  If you send the leaf
containing the default value, that's perfectly fine.  When you fetch
the leaf, be aware that if the leaf's value is the default, it may
not be present in the returned data.  Server's know enough to
be well behaved if a client attempts to delete or create a leaf
that has a default value, and clients know enough to be well behaved
when default values are not returned.  

I'd be happy to see a section that defines these as rules of the road.

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 6 May 2010 21:23:17 +0200

> I'd be happy to see a section that defines these as rules of the road.

So this means you can't simply diff/compare configs without an
application that first grabs all relevant YANG modules and normalizes
the defaults by triming them? And you are fine that well behaved
clients remove explicitely set defaults from config? I also note that
default statements may be added to YANG definitions - so that client
needs to be aware of all relevant revisions of the YANG definitions
involved.

If clients at the end have to trim in any case to be well-behaved, why
do we then allow servers to behave in different ways in the first
place? If there is a reason for servers to have differnet behaviour
when it comes to defaults, what is wrong with telling the client what
a server actually does?

/js