Subject: [Netconf] WG Last Call for daft-ietf-netconf-with-defaults-08. Please review BEFORE June 6th, 2010

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Wed, 26 May 2010 09:20:43 +0200

WG participants,

This is a(nother) formal WG Last Call for this  this document.
Please review and comment BEFORE June 6th 2010.

We did have a pretty extensive discussion on various
topics with the previous WG Last Call. It seems however that we did
come to (at least rough) consensus on the issues that were raised.
As a result, Andy has posted revision 8. The changes since the
last rev are:

   Added report-all-tagged mode.

   Changed conformance so report-all or report-all-tagged mode SHOULD be
   supported.

   Clarified capability requirements for each mode, for edit-config and
   NV storage requirements.

   Changed rpc-error details for unsupported with-defaults value.

   Added XSD for wd:default attribute

   Expanded example to show report-all-tagged for a basic-mode=trim
   server.

For direct pointers to the document and diffs etc, see:
    http://tools.ietf.org/wg/netconf/draft-ietf-netconf-with-defaults/

There was also some discussion on merging all or part of the with-defaults
into the 4741bis document. However, we (WG chairs) do not believe that we
should explore that path this late in the process. Besides, we certainly
did not see a WG consensus to do so.

Bert and Mehmet

-------- Original Message --------
Subject: 	[Netconf] I-D Action:draft-ietf-netconf-with-defaults-08.txt
Date: 	Thu, 20 May 2010 13:15:02 -0700 (PDT)
From: 	[email-masked]
To: 	[email-masked]
CC: 	[email-masked]

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-08.txt
	Pages           : 30
	Date            : 2010-05-20

The NETCONF protocol defines ways to read and edit configuration data
from a NETCONF server.  Part of this data may not be 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 save it in a NETCONF
datastore or send it to the client in a retrieval operation reply.
In other situations the NETCONF client will need this data as part of
the NETCONF <rpc-reply> messages.  Not all server implementations
treat this default data the same way.  This document defines a
capability-based extension to the NETCONF protocol that allows the
NETCONF client to identify how defaults are handled by the server,
and control whether default values are part of NETCONF <rpc-reply>
messages or <copy-config> output to a file.

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

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

---

From: Kent Watsen <[email-masked]>
Date: Thu, 27 May 2010 10:24:37 -0700

1) Sections 2.2.3 and 2.3.3 describe report-all-tagged behavior for 'trim' and 'explicit' servers respectively.  On the mailing list it was suggested that a 'report-all' server could also-support 'report-all-tagged', should we add a similar section to 2.1.3?

2) Typo in section 3.1, "it is present within configuration input"?

3) Clean up text in section 4.1, change from

    "The :with-defaults capability indicates that the NETCONF server
     supports a specific defaults handling basic mode"

  to maybe

    "The :with-defaults capability indicates which defaults handling
     basic mode the NETCONF server supports"

4) in section 4.4, remove the line return between the first and second sentences

5) in section 4.4, in the first sentence, s/will treat/treats/

6) in section 4.4, the paragraph that begins with the word "Note" implies that the <hello> message will need to contain two lines:

  urn:ietf:params:netconf:capability:with-defaults:1.0?basic-mode=explicit
  urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults&revision=2010-05-19

  is this really necessary?

7) in section 4.6.1, it says "Allowed values of the with-defaults element are taken from the list in Section 2", but section 2 doesn't include report-all-tagged, s/section 2/section 3/?

8) in section 4.6.2, it says "If the wd:default attribute is present and set to 'true', then the server MUST treat the new data node as a request to return that node to its default value (i.e., remove it from the database)."  I liked the text from section 2.2.3 better, as it also asserts that the value MUST be the same as the schema default value.

9 In section A.3.2, it says "Any subtrees within the element are also considered to be tagged as dafault data".  While I agree with the statement, it probably should be specified in section 3.1

10) In section A.3.2, it says "The actual data nodes tagged by the server depends on the defaults handling basic mode used by the server" and "If the server's basic mode is 'report-all', then no data nodes are tagged."  I disagree, I think that a "report-all" server that also-supports "report-all-tagged" should tag its defaults, if "report-all-tagged" is requested by the client.

Thanks,
Kent

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Bert (IETF) Wijnen
> Sent: Wednesday, May 26, 2010 3:21 AM
> To: netconf
> Subject: [Netconf] WG Last Call for daft-ietf-netconf-with-defaults-08.
> Please review BEFORE June 6th, 2010
> 
> WG participants,
> 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Andy Bierman <[email-masked]>
Date: Thu, 27 May 2010 11:21:41 -0700

Kent Watsen wrote:
> 1) Sections 2.2.3 and 2.3.3 describe report-all-tagged behavior for
> 'trim' and 'explicit' servers respectively.  On the mailing list it
> was suggested that a 'report-all' server could also-support
> 'report-all-tagged', should we add a similar section to 2.1.3?
>

We could add a sentence explaining that nothing would ever be
tagged if basic-mode=report-all.  There is no difference between
a basic=report-all and with-defaults=report-all-tagged reply.

....
> 6) in section 4.4, the paragraph that begins with the word "Note"
> implies that the <hello> message will need to contain two lines:
>

Yes.
The YANG RFC specifies that a server supporting
the ietf0netconf-with-defaults module MUST advertise
a module capability.  That is what this 2nd URI represents.
I think this section makes that point clear.

The YANG module URI is an awesome tool that exists on
its own, separate from the defaults modes supported.  It allows
the client app to re-create the server object tree on-the-fly,
instead of using trial-and-error + a data silo.

>
> 7) in section 4.6.1, it says "Allowed values of the with-defaults
> element are taken from the list in Section 2", but section 2 doesn't
> include report-all-tagged, s/section 2/section 3/?

OK

>
> 8) in section 4.6.2, it says "If the wd:default attribute is present
> and set to 'true', then the server MUST treat the new data node as a
> request to return that node to its default value (i.e., remove it
> from the database)."  I liked the text from section 2.2.3 better, as
> it also asserts that the value MUST be the same as the schema default
> value.

OK

>
> 9 In section A.3.2, it says "Any subtrees within the element are also
> considered to be tagged as dafault data".  While I agree with the
> statement, it probably should be specified in section 3.1
>
> 10) In section A.3.2, it says "The actual data nodes tagged by the
> server depends on the defaults handling basic mode used by the
> server" and "If the server's basic mode is 'report-all', then no data
> nodes are tagged."  I disagree, I think that a "report-all" server
> that also-supports "report-all-tagged" should tag its defaults, if
> "report-all-tagged" is requested by the client.

A report-all basic-mode server has no concept
whatsoever of a default.  Nothing will ever be tagged.
Every node is considered to exist in the database.
Technically, the report-all server is tagging all (zero) of its default
nodes.

> Thanks, Kent

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 27 May 2010 15:13:15 -0400

>instead of using trial-and-error + a data silo.

I guess the sad part is that we didn't add this sort of parameter
mechanism to YANG, so that one announcement can handle both.  This
is a scenario that we are likely to hit repeatedly.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Thu, 27 May 2010 12:43:22 -0700

> is a scenario that we are likely to hit repeatedly.

I disagree, as I pointed out a couple times already.
It is just an implementation detail, which URI string
has which parameter.  It would be horrible if a
client had to first parse foo.yang to find out if
the URI parameters advertised for foo.yang were valid.

If the client understands the static part of the URI,
then it should expect to find a subset of fixed parameters.
Arbitrary parameter/value pairs not defined for the capability
are not useful to the client.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Thu, 27 May 2010 13:58:15 -0700

> Technically, the report-all server is tagging all (zero) of its default

I don't agree.  For instance, even for a report-all server, when the client creates an interface, it could choose to not specify the MTU parameter, at which point the server would use the schema-defined default (1500) by copying the value into the datastore.  I understand that the server then no longer manages the value as a default, but that doesn't mean it couldn't compare the current value to the schema defined value to see if it is, in fact the same and mark it as such.  IMO, if a report-all server can't do this, then it shouldn't advertize supporting "report-all-tagged".

BTW, this is how both our SSL/VPN and Universal Access Control products <get-config> worked for many releases (i.e. report-all).  Only recently did they update to support the "trim" behavior, which they were able to do because, yes, even report-all servers can know what defaults are.

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Thu, 27 May 2010 17:13:20 -0700

Kent Watsen wrote:
>>> 10) In section A.3.2, it says "The actual data nodes tagged by
>>> the server depends on the defaults handling basic mode used by
>>> the server" and "If the server's basic mode is 'report-all', then
>>> no data nodes are tagged."  I disagree, I think that a
>>> "report-all" server that also-supports "report-all-tagged" should
>>> tag its defaults, if "report-all-tagged" is requested by the
>>> client.
>> A report-all basic-mode server has no concept whatsoever of a
>> default.  Nothing will ever be tagged. Every node is considered to
>> exist in the database. Technically, the report-all server is
>> tagging all (zero) of its default nodes.
>
>
> I don't agree.  For instance, even for a report-all server, when the
> client creates an interface, it could choose to not specify the MTU
> parameter, at which point the server would use the schema-defined
> default (1500) by copying the value into the datastore.  I understand
> that the server then no longer manages the value as a default, but
> that doesn't mean it couldn't compare the current value to the schema
> defined value to see if it is, in fact the same and mark it as such.
> IMO, if a report-all server can't do this, then it shouldn't
> advertize supporting "report-all-tagged".
>
> BTW, this is how both our SSL/VPN and Universal Access Control
> products <get-config> worked for many releases (i.e. report-all).
> Only recently did they update to support the "trim" behavior, which
> they were able to do because, yes, even report-all servers can know
> what defaults are.
>

But you implement 'explicit' basic-mode, not 'report-all'.

Think of it this way -- The tagged nodes are the
ones that the server leaves out of a basic-mode reply.
That is true in every case. Right?

And the basic-mode=report-all server never leaves
any nodes out of basic-mode reply.  Right?

So the set of nodes the report-all server needs to
tag in a report-all-tagged reply is 'NIL'.  Right?

So the report-all and the report-all-tagged reply
would be exactly the same in this case.  Right?

What matters is whether or not the server keeps a node
in its database for a schema default.  That is what
the basic-mode represents.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Fri, 28 May 2010 10:08:55 -0700

> But you implement 'explicit' basic-mode, not 'report-all'.

Our JUNOS-based products implement explicit, but the SSL/VPN and UAC products I mentioned before are non-JUNOS based products.

> That is true in every case. Right?

You could use that definition, but I prefer defining tagged nodes as those the server suspects as being such.  Report-all and trim servers are similar in that neither is sure if the user set the default value or not.  The difference, of course, is that a trim server MUST be default-aware, whereas a report-all server *MAY* be default-aware.  You seem to think that report-all servers can not be default aware, but don't assume that.  My point is that, *if* a report-all server is default-aware, then it can advertise report-all-tagged and tag values having the same value as the schema-default; otherwise it should not advertize report-all-tagged.

> any nodes out of basic-mode reply.  Right?

Agreed

> would be exactly the same in this case.  Right?

With your definition, these are both true.  I prefer the definition of tagging defaults when they're presumed to be.  For a report-all server, "report-all-tagged" would return the exact same number of nodes as "report-all", just that now some of them might be tagged, since the server can see they have the same value as the schema-defined default.

Kent

---

From: Andy Bierman <[email-masked]>
Date: Fri, 28 May 2010 14:17:43 -0700

Kent Watsen wrote:
> Our JUNOS-based products implement explicit, but the SSL/VPN and UAC
> products I mentioned before are non-JUNOS based products.
>
>
>> Think of it this way -- The tagged nodes are the ones that the
>> server leaves out of a basic-mode reply. That is true in every
>> case. Right?
>
> You could use that definition, but I prefer defining tagged nodes as
> those the server suspects as being such.  Report-all and trim servers
> are similar in that neither is sure if the user set the default value
> or not.  The difference, of course, is that a trim server MUST be
> default-aware, whereas a report-all server *MAY* be default-aware.
> You seem to think that report-all servers can not be default aware,
> but don't assume that.  My point is that, *if* a report-all server is
> default-aware, then it can advertise report-all-tagged and tag values
> having the same value as the schema-default; otherwise it should not
> advertize report-all-tagged.
>

I don't understand.
Both the trim and explicit servers have their own definition
of a default.  They know what nodes to omit in a basic-mode reply.
These are the nodes that get tagged in a report-all-tagged reply.

How would you define it?
I do not like "The server presumes this node to
be a default".  The server knows because it
can support its own basic mode.  t does not
need to presume anything.

>
>> And the basic-mode=report-all server never leaves any nodes out of
>> basic-mode reply.  Right?
>
> Agreed
>
>
>> So the set of nodes the report-all server needs to tag in a
>> report-all-tagged reply is 'NIL'.  Right?
>>
>> So the report-all and the report-all-tagged reply would be exactly
>> the same in this case.  Right?
>
> With your definition, these are both true.  I prefer the definition
> of tagging defaults when they're presumed to be.  For a report-all
> server, "report-all-tagged" would return the exact same number of
> nodes as "report-all", just that now some of them might be tagged,
> since the server can see they have the same value as the
> schema-defined default.

No -- a report-all server does not have to 'know' the node
has its schema-defined default value.  It is not required
to have any concept of a default.

That is not what wd:default means.
It means the server treats that node as
a default node, not the node is set to
the schema default value.

Andy