Subject: [Netconf] I-D Action:draft-ietf-netconf-with-defaults-06.txt

From: [email-masked]
Date: Sat, 27 Mar 2010 17:15:07 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Configuration Working Group of the IETF.

	Title           : With-defaults capability for NETCONF
	Author(s)       : A. Bierman, B. Lengyel
	Filename        : draft-ietf-netconf-with-defaults-06.txt
	Pages           : 21
	Date            : 2010-03-27

The NETCONF protocol defines ways to read configuration data from a
NETCONF server.  Part of this data is not set by the NETCONF client,
but rather a default value is used.  In many situations the NETCONF
client has a priori knowledge about default data, so the NETCONF
server does not need to send it to the client.  In other situations
the NETCONF client will need this data as part of the NETCONF <rpc-
reply> messages.  This document defines a capability-based extension
to the NETCONF protocol that allows the NETCONF client to control
whether default values are part of NETCONF <rpc-reply> messages or
<copy-config> output to the target URL.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netconf-with-defaults-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Kent Watsen <[email-masked]>
Date: Mon, 29 Mar 2010 15:11:24 -0700

I just realized that we never resolved the issue raised last September regarding a server whose basic-mode is "explicit', forced to support "report-all", and having an insensitive client feed back the report-all output into an edit-config operation.  A proposal was to allow servers supporting "explicit" to annotate the report-all output with an attribute such that, when fed back to it, it wouldn't suddenly explicitly set all the default values.  Recalling Phil's example of how 2.8M of explicit config would balloon to 46.6M, this issue seems important enough to at least warrant a warning and perhaps a security warning (if concerned about a DoS resulting from exhausted NV space and/or much increased latency).  Of course, if believed to be significant enough, the WG should offer a solution or else risk vendors devising their own non-interoperable solutions.

Just a few editorial comments:

1.1. Terminology: 
	s/e.g. via the NETCONF/e.g. via NETCONF/

A.1. Example YANG module: 
	s/It is intentionally very terse, and include/ \
        It is intentionally very terse, and includes/

A.2. Example Data Set:
	s/The following figure/The following data set/
	*OR*
 	s/The following figure/The following/

A.3. Protocol Operation Examples:
	s/operations which are using/operations using/
	s/<with-defaults >/<with-defaults>/g  (there are 3 of these)

PS: I like the new Appendix section.

Thanks,
Kent

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of [email-masked]
> Sent: Saturday, March 27, 2010 8:15 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Netconf] I-D Action:draft-ietf-netconf-with-defaults-06.txt
>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 29 Mar 2010 15:34:22 -0700

Kent Watsen wrote:
> 
> I just realized that we never resolved the issue raised last September regarding a server whose
> basic-mode is "explicit', forced to support "report-all", and having an insensitive client feed
> back the report-all output into an edit-config operation.  A proposal was to allow servers
> supporting "explicit" to annotate the report-all output with an attribute such that, when fed
> back to it, it wouldn't suddenly explicitly set all the default values.  Recalling Phil's
> example of how 2.8M of explicit config would balloon to 46.6M, this issue seems important enough
> to at least warrant a warning and perhaps a security warning (if concerned about a DoS resulting
> from exhausted NV space and/or much increased latency).  Of course, if believed to be
> significant enough, the WG should offer a solution or else risk vendors devising their own
> non-interoperable solutions.
> 

Why would a client do this?
Since the client has to go out of its way on an 'explicit' basic-mode
server to get a report-all reply, it should know how to deal
with it.

I do not want to add any XML attributes to the config.
A static config should not have any
XML attributes embedded within the content.
The edit-config operation strips out nc:operation
and yang:insert attributes.  The copy-config operation
does not use any XML attributes.

Andy

> 1.1. Terminology: s/e.g. via the NETCONF/e.g. via NETCONF/
> 
> A.1. Example YANG module: s/It is intentionally very terse, and include/ \ It is intentionally
> very terse, and includes/
> 
> A.2. Example Data Set: s/The following figure/The following data set/ *OR* s/The following
> figure/The following/
> 
> A.3. Protocol Operation Examples: s/operations which are using/operations using/ 

will fix soon, thanks

> Thanks, Kent
>> -----Original Message----- From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of [email-masked] Sent: Saturday, March 27, 2010 8:15 PM To:
>> [email-masked] Cc: [email-masked] Subject: [Netconf] I-D
>> Action:draft-ietf-netconf-with-defaults-06.txt
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is
>> a work item of the Network Configuration Working Group of the IETF.
>> 
>> 
>> Title           : With-defaults capability for NETCONF Author(s)       : A. Bierman, B.
>> Lengyel Filename        : draft-ietf-netconf-with-defaults-06.txt Pages           : 21 Date
>> : 2010-03-27
>> 
>> The NETCONF protocol defines ways to read configuration data from a NETCONF server.  Part of
>> this data is not set by the NETCONF client, but rather a default value is used.  In many
>> situations the NETCONF client has a priori knowledge about default data, so the NETCONF server
>> does not need to send it to the client.  In other situations the NETCONF client will need this
>> data as part of the NETCONF <rpc- reply> messages.  This document defines a capability-based
>> extension to the NETCONF protocol that allows the NETCONF client to control whether default
>> values are part of NETCONF <rpc-reply> messages or <copy-config> output to the target URL.
>> 
>> http://www.ietf.org/internet-drafts/draft-ietf-netconf-with-defaults- 06.txt
>> 
>> Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/
>> 
>> Below is the data which will enable a MIME compliant mail reader implementation to
>> automatically retrieve the ASCII version of the Internet-Draft.
>

---

From: Kent Watsen <[email-masked]>
Date: Mon, 29 Mar 2010 16:03:38 -0700

> server to get a report-all reply, it should know how to deal

Maybe because the client is too simple to be YANG-aware and it's hardcoded to always work with report-all, since that is required by all NETCONF servers?  I'm thinking about perl/python scripts more so than NMSs...

> does not use any XML attributes.

Before discussing the merits of that specific proposal, can we decide if it's an interoperability concern or if just a warning suffices?

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Mon, 29 Mar 2010 17:12:51 -0700

Kent Watsen wrote:
>> Why would a client do this? Since the client has to go out of its way on an 'explicit'
>> basic-mode server to get a report-all reply, it should know how to deal with it.
> 
> Maybe because the client is too simple to be YANG-aware and it's hardcoded to always work with
> report-all, since that is required by all NETCONF servers?  I'm thinking about perl/python
> scripts more so than NMSs...
> 

huh?

A client that knows about with-defaults needs to use it properly.

A client that doesn't know about it is going to get the
server 'basic' behavior every time, so there is no
chance the client can get confused.

The client is not allowed to ignore the 'also-supported' and 'basic'
parameters.  If it does, then garbage-in, garbage-out.

> 
>> I do not want to add any XML attributes to the config. A static config should not have any XML
>> attributes embedded within the content. The edit-config operation strips out nc:operation and
>> yang:insert attributes.  The copy-config operation does not use any XML attributes.
> 
> Before discussing the merits of that specific proposal, can we decide if it's an
> interoperability concern or if just a warning suffices?
> 

not even a warning.
The server does not correlate 1 get-config
with another copy-config.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Tue, 30 Mar 2010 07:59:54 -0700

> parameters.  If it does, then garbage-in, garbage-out.

Didn't say it was ambiguous, just that a script writer might make it easy on themselves and have the script always ask for the mandatory "report-all", do what they want, and send it back.

> with another copy-config.

Well, at least we agree a 'warning' is not preferred  ;)

Let me try another tack...

At Juniper, we call this "data-sourcing" and it crops up in a variety of places including: defaults, config-groups, templates, cluster-global data, data a logical-system inherits from its host-system, etc.  We're just talking about one thing here, but it's good to know that there is a larger pattern.  Now there are times when a client is too lightweight to be YANG-aware - for instance, it could be a thin-client cobbled together with some XSLT, CSS, and HTML, where the goal is to display to the end-user the all the config (after flattening) complete with data-sourcing so they know where/how the data was set.  They can make changes, but any change made becomes local config (i.e. explicit for defaults).  Without annotations, when the config is sent back to the device, everything becomes local config.  So you see, there are both usability and expansion concerns here.

I think vendors will need to solve this problem; the only question is if this WG is going to provide guidance on the solution.

Thanks,
Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 30 Mar 2010 17:17:07 +0200

On Tue, Mar 30, 2010 at 04:59:54PM +0200, Kent Watsen wrote:
 
> I think vendors will need to solve this problem; the only question
> is if this WG is going to provide guidance on the solution.

Not sure what you have in mind but if vendors generate XML attributes
that change the semantics of standard NETCONF operations, I think we
are on a very slippery slope.

/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: Tue, 30 Mar 2010 08:23:28 -0700

Kent Watsen wrote:
>> A client that doesn't know about it is going to get the server 'basic' behavior every time, so
>> there is no chance the client can get confused.
>> 
>> The client is not allowed to ignore the 'also-supported' and 'basic' parameters.  If it does,
>> then garbage-in, garbage-out.
> 
> Didn't say it was ambiguous, just that a script writer might make it easy on themselves and have
> the script always ask for the mandatory "report-all", do what they want, and send it back.
> 
> 

This will change all the server defaults to explicitly set leafs.

>> not even a warning. The server does not correlate 1 get-config with another copy-config.
> 
> At Juniper, we call this "data-sourcing" and it crops up in a variety of places including:
> defaults, config-groups, templates, cluster-global data, data a logical-system inherits from its
> host-system, etc.  We're just talking about one thing here, but it's good to know that there is
> a larger pattern.  Now there are times when a client is too lightweight to be YANG-aware - for
> instance, it could be a thin-client cobbled together with some XSLT, CSS, and HTML, where the
> goal is to display to the end-user the all the config (after flattening) complete with
> data-sourcing so they know where/how the data was set.  They can make changes, but any change
> made becomes local config (i.e. explicit for defaults).  Without annotations, when the config is
> sent back to the device, everything becomes local config.  So you see, there are both usability
> and expansion concerns here.

I do not buy the premise that NETCONF applications are unaware of
the data models they are using.  This can be done with hardwired hacks,
a proprietary mapping to YANG, native YANG, etc.

A dumb MIB walker type of application will display everything.
So what?

I strongly oppose any standard to add meta-data to the configuration
or to the RPC replies.

If the NETCONF application is smart enough to parse most of
the capability URI, then it can parse the whole thing.
I do not accept the premise that the application only
knows how to parse part of the URI, and does not know
the value of the 'also-supported' field.

> provide guidance on the solution.

I disagree.  The correct design approach is
to use the YANG modules (or other schema) to understand
the properties of the NETCONF content.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 30 Mar 2010 10:23:54 -0700

> are on a very slippery slope.

The extreme conclusion would be to encode most of
the YANG module inline in the replies as meta-data.

A client should ignore unknown XML attributes it gets from servers.
(e.g., parse unknown nodes as 'anyxml').

I don't think it is interoperable if server vendors mark up
their configuration data with proprietary XML attributes
(or worse -- XML elements).

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 30 Mar 2010 19:35:09 +0200

> (or worse -- XML elements).

Andy, this is not a YANG issue as far as I can tell.

/js

---

From: Kent Watsen <[email-masked]>
Date: Tue, 30 Mar 2010 14:27:04 -0700

> are on a very slippery slope.

I would never intentionally propose doing something that changes the semantics of standard NETCONF operations and I don't believe this proposal does.  Do you?

Thanks,
Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 31 Mar 2010 00:40:12 +0200

> I would never intentionally propose doing something that changes the semantics of standard NETCONF operations and I don't believe this proposal does.  Do you?

If someone inserts proprietary XML attributes that cause data nodes to
be ignored in a standard NETCONF operations, I think the semantics of
the operation have changed.

If our goal is interoperable standards for configuration, then we
can't expect different implementations to do the same thing if the
interpretation of an operation depends on proprietary XML attributes.

/js

---

From: Kent Watsen <[email-masked]>
Date: Tue, 30 Mar 2010 16:36:19 -0700

> Andy, this is not a YANG issue as far as I can tell.

This is a usability issue.  Asking an "explicit" server to report-all, I expect the defaults to be annotated as such.  Obviously, if my logic was in full knowledge of the defaults defined in the YANG model, it'd just ask for explicit and fill in the blanks.  So it implies that the client isn't YANG-aware (i.e. it's a "thin-client") and we're not allowing the response to be as meaningful as it could be.

But let's take this a step further.  Going back to the other examples I gave for data-sourcing, there is a general pattern whereby some configuration can be factored out and then applied where needed - templates, config-groups, clusters, and logical-systems all have this property.  I know the WG hasn't discussed any of these yet, but it turns out that it is *not possible* to derive values from the schema as they are not statically defined there (it's in the instance data).  Yet still thin-clients want a flattened/expanded view of the configuration - with annotations indicating where the non-local values came from and, for local values, what globally-defined value they may be overriding, if any.

Perhaps the question for the group is if we're only supporting clients that grok all the details (i.e. thick-clients)?  If not supporting thin-clients, then why does this I-D allow servers to return something besides their basic-mode?

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Tue, 30 Mar 2010 17:03:02 -0700

Kent Watsen wrote:
> 
>>> The extreme conclusion would be to encode most of the YANG module inline in the replies as
>>> meta-data.
>>> 
>>> A client should ignore unknown XML attributes it gets from servers. (e.g., parse unknown
>>> nodes as 'anyxml').
>>> 
>>> I don't think it is interoperable if server vendors mark up their configuration data with
>>> proprietary XML attributes (or worse -- XML elements).
> This is a usability issue.  Asking an "explicit" server to report-all, I expect the defaults to
> be annotated as such.  Obviously, if my logic was in full knowledge of the defaults defined in
> the YANG model, it'd just ask for explicit and fill in the blanks.  So it implies that the
> client isn't YANG-aware (i.e. it's a "thin-client") and we're not allowing the response to be as
> meaningful as it could be.

The WG has consistently not approved adding any meta-data.
IMO you should use YANG, XSD, RelaxNG, or something else to learn
the schema defaults.

> 
> But let's take this a step further.  Going back to the other examples I gave for data-sourcing,
> there is a general pattern whereby some configuration can be factored out and then applied where
> needed - templates, config-groups, clusters, and logical-systems all have this property.  I know
> the WG hasn't discussed any of these yet, but it turns out that it is *not possible* to derive
> values from the schema as they are not statically defined there (it's in the instance data).
> Yet still thin-clients want a flattened/expanded view of the configuration - with annotations
> indicating where the non-local values came from and, for local values, what globally-defined
> value they may be overriding, if any.
> 
> Perhaps the question for the group is if we're only supporting clients that grok all the details
> (i.e. thick-clients)?  If not supporting thin-clients, then why does this I-D allow servers to
> return something besides their basic-mode?

IMO, we are only supporting data-model specific functionality
with YANG.  I think the NETCONF WG has agreed to this over and over.

I don't think parsing a URI completely is a burden on the client.

We should not keep expanding the charter of the with-defaults document.
Defining a lot of meta-data for NETCONF databases sounds like another
project that has not been proposed or approved by any WG.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 31 Mar 2010 08:57:15 +0200

On Wed, Mar 31, 2010 at 01:36:19AM +0200, Kent Watsen wrote:
> This is a usability issue.  Asking an "explicit" server to
> report-all, I expect the defaults to be annotated as such.
> Obviously, if my logic was in full knowledge of the defaults defined
> in the YANG model, it'd just ask for explicit and fill in the
> blanks.  So it implies that the client isn't YANG-aware (i.e. it's a
> "thin-client") and we're not allowing the response to be as

I do not really care what the motivation is for the client, whether it
is not YANG aware or just lazy or ignorant. By way of a Unix analogy,
if I want to edit /etc/sysctl.conf, then starting by calling sysctl -a
is simply a bad idea. You get what you ask for. If this is a problem,
then we probably need some usage guidelines stating on a server with
explicit config, you likely only want to edit explicit config.

/js

---

From: Kent Watsen <[email-masked]>
Date: Wed, 31 Mar 2010 14:09:10 -0700

> The WG has consistently not approved adding any meta-data.

I'm sorry to be late to a party, but could you explain why this is so?  I've heard this said a few times before, but I never get why it is so.  I've also read others suggest using metadata for things, so I know I'm not the only one who may be struggling with why we can't...

> IMO you should use YANG, XSD, RelaxNG, or something else to learn

Agreed, but it seems that the primary purpose of this I-D is to support thin-clients, which I'm also OK with.   But IMO, this I-D doesn't go far enough to make that support very compelling.  You wrote last September that you felt report-all was only for a diagnostic purpose - really?  If that is it, then should we remove the last two use-cases from the I-D's Introduction?

PS: as an aside, while I agree with the first use-case in the Introduction, one could claim that a schema-aware app doesn't need report-all to get the complete set of data.  Should this use-case also be removed?

> with YANG.  I think the NETCONF WG has agreed to this over and over.

Right, which is why we're talking about this now

> I don't think parsing a URI completely is a burden on the client.

I agree - and this has never been a URI parsing issue for me...

> project that has not been proposed or approved by any WG.

What is the charter for this document?  AFAICT, it does exactly two things:
  1) enables servers to advertise their basic-mode  (this is a good thing)
  2. forces trim/explicit servers to support report-all (for diags only?)

My concern is that we'll release an incomplete solution now with no ideas for how we might extend it in the future, if needed.

Thanks,
Kent