Subject: [Netconf] [Fwd: New Version Notification for draft-ietf-netconf-with-defaults-03]

From: Balazs Lengyel <[email-masked]>
Date: Wed, 05 Aug 2009 15:11:06 +0200

Hello,
Sorry for doing this in the middle of WG Last call, but I posted a new draft. I realized that 
it would be important to include the non-normative YAM in the WG last call.
Other changes:
- included Phil's comments
- changed the URIs so if we ever get the YAM to be normative, we should only need to advertise 
one URI and not two.
Balazs

PS. I will be mostly unavailable till the 25th so might be slow to answer comments.

-------- Original Message --------
Subject: New Version Notification for draft-ietf-netconf-with-defaults-03
Date: Wed,  5 Aug 2009 06:07:01 -0700 (PDT)
From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]
CC: [email-masked]

A new version of I-D, draft-ietf-netconf-with-defaults-03.txt has been successfuly submitted by 
Balazs Lengyel and posted to the IETF repository.

Filename:	 draft-ietf-netconf-with-defaults
Revision:	 03
Title:		 With-defaults capability for NETCONF
Creation_date:	 2009-08-05
WG ID:		 netconf
Number_of_pages: 14

Abstract:
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 manger 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.

The IETF Secretariat.

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320                  email: [email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 6 Aug 2009 13:13:05 +0200

On Wed, Aug 05, 2009 at 03:11:06PM +0200, Balazs Lengyel wrote:

> Sorry for doing this in the middle of WG Last call, but I posted a
> new draft. I realized that it would be important to include the
> non-normative YAM in the WG last call.

Here is my review of the -03 version of this document. The comments
are in document order.

s /often needs a single/needs a single/

The text talks about "controls whether default data is part of NETCONF
<rpc-reply> messages"; I would prefer if the text would say that it
"extends the NETCONF <get>, <get-config>, and <copy-config> operations
with an additional parameter that allows the NETCONF client to control
whether default data is returned in the result. I think we should take
the layered architecture of NETCONF serious. This change affects
several places of the document since it should nowhere talk about
<rpc-reply> messages.

I am not sure how we deal with capabilities within YANG. What about
having the ietf-netconf.yang introduce a nc:capability extension
statement that can be used to define the capability URI for a YANG
feature, just of usage to describe NETCONF protocol extensions? I
am thinking of

   extension nc:capability {
     description
       "This extension is used to define capability URIs in NETCONF
       protocol modules written in YANG. It is not supposed to be
       used outside of NETCONF protocol specifications.";
     argument "uri";
   }

This way, the features used to define protocol capabilities could
indicate the capability URI associated with a protocol "feature".  I
also note that the with-defaults ID adds special parameters to the
capability URI which is something we do not have special support for
in YANG - think the YANG approach would be to define feature and to
use the feature announcement mechanism. Why do we do something special
here?

I suggest to get rid of the subsubsection headlines 1.1.1 and 1.1.2;
just have a section 1.1.

s/A NETCONF servers/A NETCONF server/

s/parameter Possible/parameter. Possible/

s/return default data in the NETCONF <rpc-reply> message/return default data/

In section 2.5, be explicit which error is returned if a client sends
a with-default value the server does not support.

In the YANG module s/with-defaults-mode-type/with-defaults-mode/ and I
would probably have choosen the prefix nc-wd instead of nwd.

I would prefer if this document would move along with RFC4741bis so
that we can make the YANG normative.

/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 Aug 2009 08:01:10 -0700

>        used outside of NETCONF protocol specifications.";

I am strongly opposed to using extensions to add standard
mechanisms to the YANG language.  The capability-stmt has
been brought up many times before and rejected every time.

YANG does not care about NETCONF capabilities.
It is a short-sighted, and architecturally immature
decision, but it is the NETMOD WG decision.

So all NETCONF capabilities need to be defined as YANG features
instead.

> use the feature announcement mechanism. Why do we do something special

If this is part of YANG, it needs to be done with normal
language constructs.  This proposal does not seem to mesh
at all with the YANG module capability URI encoding.
Why do we need a separate URI for these capabilities?
Just advertise the module-uri with features=a,b,c at the end,
and it serves the same purpose.  Why separate the feature 'a'
out into its own capability URI?

...

> /js

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 6 Aug 2009 17:18:32 +0200

> out into its own capability URI?

All I tried to do was to propose a way to deal with the "legacy"
capability URIs we have in NETCONF. If you think trying to solve this
issue sucks, fine. But then be careful that the YANG modules for
NETCONF and NETCONF extensions do not overload things in wired
ways. The with-default says there is a parameter attached to indicate
the default default handling and this is not expressed using features.
So please fix this.

I do not care whether there is a formal capabilities statement to
handle the legacy NETCONF capabilities or whether we deal with this in
description clauses. But we should stick to the YANG way of doing
things as much as we can from now on. And the YANG way to indicate the
default default handling would be to define features for all options
and to use the YANG mechanism to announce which of them is implemented
by a server.

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 06 Aug 2009 09:05:26 -0700

> issue sucks, fine. But then be careful that the YANG modules for

I object to extensions that every YANG tool must support.
What's the point of that?  Make it a keyword.

So let's add capability-stmt as an optional child of feature-stmt:

   feature candidate {
       description
         "NETCONF :candidate capability;
          If the agent advertises the :candidate
          capability for a session, then this feature must
          also be enabled for that session.  Otherwise,
          this feature must not be enabled.";
       reference "RFC XXXX, section 8.3.";
       capability "urn:ietf:params:netconf:capability:candidate:1.0";
   }

The capability-stmt is used to indicate that a legacy NETCONF
capability URI is mapped to this YANG feature.  Every YANG compiler
MUST support it (opposite of extensions) so a developer can rely on it.

> the default default handling and this is not expressed using features.

I prefer to make with-defaults wait until YANG is done,
and ONLY have a YANG module with read-only 'basic' and 'extended'
leafs to indicate the agent's default handling behavior.

The use of a capability instead of a YANG data model is a total hack.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 7 Aug 2009 11:32:04 +0200

> MUST support it (opposite of extensions) so a developer can rely on it.

I object to this proposal since capabilities are only used for
backwards compatible protocol extensions and not for data models.
 
> The use of a capability instead of a YANG data model is a total hack.

I prefer a solution where NETCONF servers announce their default
handling behaviour in the <hello> message; I do not want to have to
issue a <get> first to figure out how the server behaves. I think this
is also inline with the way all other data model specific features are
announced in NETCONF.

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 07 Aug 2009 06:13:54 -0700

> backwards compatible protocol extensions and not for data models.

OK -- let's leave the whole thing out.
It is not important enough to worry about.

> is also inline with the way all other data model specific features are

This leads to 1-off coding for every single parameter since they
are all encoded differently, and the syntax is only explained
in a description clause.  I prefer consistent, easy-to-use management
operations that can be used at any time.  I prefer to have this
sort of device capability info available in the data model,
so must/when/select expressions can reference it as needed.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 7 Aug 2009 16:10:54 +0200

On Fri, Aug 07, 2009 at 03:13:54PM +0200, Andy Bierman wrote:
 
> operations that can be used at any time.

Features are announced in a consistent way. The -with-defaults ID
currently cooks its own mechanis and I agree this is bad. Thats why I
suggest to use features to announce the default default handling.

> I prefer to have this

I prefer to know after the <hello> exchange to what type of server I
am talking to instead of first having to do an additional <get> and
then to merge the <hello> information and the response of the <get> in
order to know what type of server I am talking with.

/js

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 7 Aug 2009 16:18:05 +0200

> that we can make the YANG normative.

Speaking as a contributor:
I support With-default draft moving along with RFC4741bis 
and YANG documents and having the With-default YAM as normative. 

Mehmet

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of ext Juergen 
> Schoenwaelder
> Sent: Thursday, August 06, 2009 1:13 PM
> To: Balazs Lengyel
> Cc: netconf mailing list
> Subject: Re: [Netconf] [Fwd: New Version Notificationfor 
> draft-ietf-netconf-with-defaults-03]
> 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 7 Aug 2009 16:21:52 +0200

> and YANG documents and having the With-default YAM as normative. 

I also prefer to move to normative YANG in both documents.

/js

---

From: Phil Shafer <[email-masked]>
Date: Fri, 7 Aug 2009 10:14:00 -0400

>I also prefer to move to normative YANG in both documents.

I suggested this also for the monitoring draft, and still do.
If YANG is the future, we shouldn't be afraid of depending on
it, even if it means a small delay.

Thanks,
 Phil

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 7 Aug 2009 16:39:37 +0200

I think we will have still a few things to do for 4741bis through August
and probably September.
We should also think on getting the text more clear by avoiding
conflicts with XSD.

OTOH I'm keen of getting the documents published soon, 
which are ready to publish and for which we decided to start the
publishing process already.

Mehmet

> From: ext Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Friday, August 07, 2009 4:22 PM
> To: Ersue, Mehmet (NSN - DE/Munich)
> Cc: Balazs Lengyel; netconf mailing list
> Subject: Re: [Netconf] [Fwd: New Version 
> Notificationfordraft-ietf-netconf-with-defaults-03]
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 7 Aug 2009 16:50:09 +0200

> it, even if it means a small delay.

I am also in favour of that - and this would solve the IP address
issue. ;-)

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 10 Aug 2009 12:40:02 +0200 (CEST)

> I am also in favour of that - and this would solve the IP address

+1

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 18 Aug 2009 09:21:30 +0200 (CEST)

Hi,

Here are my comments on with-defaults-03.

General:
---------
I have implemented a proprietary version of this capability, and plan
to move to this version when it is finished.

I agree with previous comments that this draft should move along with
4741bis, so that the XSD can be removed and YANG be normative.  One
reason is that the XSD together with the XSD in 4741 cannot be used to
validate the PDUs (b/c of the extensibility problem of the XSD in
4741).

Abstract:
---------
s/NETCONF manger/NETCONF client/

Section 1
---------
Talks about default valus being part of <rpc-reply>.  But this isn't
the whole story, since it also can be controlled for copy-config
result (url).

2.1
---

2.3
---
s/This indicates what other default handling modes does the server
support./This parameter indicates which additional default handling
modes the server supports./

2.5
---
  "A new <with-defaults> XML child element is added to the method-name
  element.  This is the element that indicates the type of the
  operation e.g. <get>, <get-config> or <copy-config>."

I think this can be made more specific, e.g.

  A new parameter "with-defaults" is added to the <get>, <get-config>,
  and <copy-config> operations.

  "If the target is a NETCONF datastore (running, candidate or
  startup) the capability has no effect."

So if the capability has no effect, what happens if the with-defaults
parameter is present?  Will you get an error (which one?) or is the
parameter silently ignored?

Section 4
---------
As I said I prefer the XSD to be removed, but it also contains an
error; it defines an xs:attribute, it should be an xs:element.

Section 5
---------
  "Network Configuration Protocol (NETCONF) Capability URNs"

Is this the registry "netconf", defined in 4741?  I suggest you also
add a reference to 4741 here.

Section 6
---------
s/operations. it does/operations. It does/

s/provides client controls/gives the client control/ ??

Section 7
---------
Remove this section.

Section 8
---------
s;// for the uri data type;;

why is with-default defined as a feature?

/martin