Subject: [Netconf] FW: NETCONF WG Session Summary

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 30 Mar 2012 10:32:16 +0200

Dear NETCONF WG,

please find below the summary of the NETCONF session in Paris.

The co-chairs would like to encourage the WG to debate on the issue for
NETCONF-Light discussed during the session as noted below.
Please discuss the pros and cons for a "netconf light with no need to
support any capabilities" vs. a "must document deviations" approach.

Mehmet & Bert

_____________________________________________
From: Ersue, Mehmet (NSN - DE/Munich) 
Sent: Friday, March 30, 2012 10:09 AM
To: ext Benoit Claise
Cc: 'ext Bert Wijnen (IETF)'; 'ext Romascanu, Dan (Dan)'
Subject: NETCONF WG Session Summary

Hi Benoit, 

below is a summary from the NETCONF WG session on March 27, 2012 in
Paris, France: 

- We had approx. 32 participants in the 1 hour NETCONF session. 
- We reviewed the status of the WG. All chartered WG items are finished.
- We went through the non-chartered documents and had a good discussion
and review of the documents.

Status of the documents:

Both chartered items, NETCONF Access Control Model and NETCONF System
Notifications documents have been published as RFC.

Non-chartered items:

Update of NETCONF over TLS (5539bis):

Badra presented remaining issues which he is going to address with a new
I-D. The sense in the room was in favor of the draft and it will become
WG item after the approval on the maillist.

NETCONF over Web Sockets:

Tomoyuki Iijima explained the changes to address the username handling
as required in the updated NETCONF base protocol document. There is a
security issue in the draft because of the independent handling of the
two security layers for TLS and the authentication based on cookies. It
has been recommended to address the issue and submit a new draft.

NETCONF-Light:

Juergen Schoenwaelder described the updated document, which defines only
the hello message as mandatory. Andy Bierman questioned the strategy to
provide a solution which is competing with the current NETCONF protocol
standard, where deviations can be used to reduce the standard features
for an implementation. The WG was in favor of the draft however the
issue needs to be solved and needs a discussion on the maillist as one
of the key contributors of the draft was not present. NETCONF-Light
makes use of the TLS Pre-Shared Key (PSK) authentication introduced in
the update of NETCONF over TLS.

AOB:

Juergen reported from the discussion on the REST API on Monday morning.
The discussion was useful to understand the details. However, it has
been proposed, for the time being, not to plan the REST API as 
a chartered document.

Action item:
The co-chairs will provide a charter update for approval including the
update of NETCONF over TLS and 
NETCONF-Light documents.

Bert & Mehmet

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 30 Mar 2012 10:42:13 +0200

> support any capabilities" vs. a "must document deviations" approach.

There surely are more than those two options.

/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: "Bert Wijnen (IETF)" <[email-masked]>
Date: Fri, 30 Mar 2012 10:47:34 +0200

We would like to encourage the WG participants to
engage in a discussion on how to allow for
the use of NetConf for constrained devices.

See below the summary of our discussion at this weeks
session in IETF83.

Please express your opinions and pls describe
the pros and cons (as you see them) of each
possible approach.

It might also be good if someone (Andy?) could
summarize/describe how exactly one can in fact support
constrained devices with standard Netconf plus
a "deviations" approach. Maybe an example would be
the best way to demonstrate how that would be done.

Bert and Mehmet

---

From: Phil Shafer <[email-masked]>
Date: Fri, 30 Mar 2012 08:45:09 -0400

>There surely are more than those two options.

What is a '"must document deviations" approach'?  IIRC our
discussions of deviation had the underlaying belief that many
vendors would be unwilling to document deviations and tools
would need an out-of-band way to learn deviations for unwilling
vendors.  Is "MUST" supposed to address this issue or some other
issue?

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Fri, 30 Mar 2012 10:07:46 -0700

> the best way to demonstrate how that would be done.

First, I do not agree that NETCONF Light provides any value
to application developers.  If the device can only push
or pull an entire config at once, then FTP already does that.
I strongly oppose this work because it is too server-centric
and appears to exist simply so the IETF can rubber-stamp
anything a server vendor wants to ship and call NETCONF.

But assuming one insisted on using a subset of NETCONF for some reason,
one can write an applicability statement that documented how to
advertise the ietf-netconf module plus some deviations to
identify what is missing from the implementation.  (The AS is only needed
because we are assuming implementers are too dumb to understand RFC 6020
I suppose.)

The AS would remind people that YANG has deviation statements and how they are used.
It would not violate any YANG rules because the deviation is just an example
and published in an AS, not in a YANG module.

It would include some examples, such as:

   E1) <get> is not supported

   The following example shows a deviation statement that indicates the
   server does not implement the <get> operation:

   Example capabilities:

   The server would advertise both the 'ietf-netconf' module and its own
   set of deviations for that server implementation (called 'acme-mydevs'
   in this example):

   <capability>urn:ietf:params:xml:ns:netconf:base:1.0?module=ietf-netconf&amp;revision=2011-06-01&amp;deviations=mydevs</capability>
   <capability>http://acme.com/xml/acme-ncdevs?module=acme-mydevs&amp;revision=2012-03-30</capability>

   Example deviations module 'acme-ncdevs'

   module acme-ncdevs {

     namespace "http://acme.com/xml/acme-ncdevs";

     prefix ncdevs;

     import ietf-netconf {
       prefix nc;
     }

     organization "Acme";
     description "NETCONF Protocol Deviations.";
     revision 2012-03-30 {
       description
         "Initial revision";
     }

     deviation "/nc:get" {
       deviate not-supported;
     }
  }

YANG already has a standard mechanism for describing a module subset.
I do not care if vendors do not want to use it.  Too bad it
makes it appear to customers that the implementation does not
support the entire mandatory portion of a module -- that is exactly its purpose, so
not surprising that's what it looks like.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 30 Mar 2012 10:11:25 -0700

Oops: changed mydevs to acme-mydevs but missed one of them:

OLD:

NEW:

<capability>urn:ietf:params:xml:ns:netconf:base:1.0?module=ietf-netconf&amp;revision=2011-06-01&amp;deviations=acme-mydevs</capability>

---

From: "Cole, Robert G CIV USARMY CERDEC (US)" <[email-masked]>
Date: Fri, 30 Mar 2012 16:51:42 +0000

Bert,

I am interested in a NETCONF-lite for constrained devises.  However, I worry about approaches that either baseline at either a) NETCONF- zero with vendors adding whatever features they think appropriate  or b) NETCONF with vendors subtracting whatever deviations they think appropriate.   I would, for simplicity sake, prefer the expertise in the WG to define a baseline NETCONF-lite feature set that I could easily explain to my acquisition and procurement folks.

Thanks,  Bob 

----- Original Message -----
From: Bert Wijnen (IETF) [mailto:[email-masked]]
Sent: Friday, March 30, 2012 08:47 AM
To: [email-masked] <[email-masked]>
Subject: [Netconf] Netconf Light or Netconf for constrained devices

Bert and Mehmet

> the update of NETCONF over TLS.
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Andy Bierman <[email-masked]>
Date: Fri, 30 Mar 2012 18:13:51 -0700

> I am interested in a NETCONF-lite for constrained devises.  However, I worry about approaches that either baseline at either a) NETCONF- zero with vendors adding whatever features they think approp…

This seems reasonable -- if we can agree on the definition of a constrained device.
According to the draft, 'constrained' can mean either the device resources
or the server developer resources.

NETCONF is intended to provide configuration management functionality.
I think the people who want NETCONF-Light should write a requirements
document that defines a constrained device, identifies the specific
use cases and specific subset of CM functionality that is mandatory
for constrained devices.

I am concerned about application developers who need to provide
meaningful CM functionality to customers, and this will be nearly
impossible unless the IETF agrees on a mandatory-to-implement subset of NETCONF.

Andy

> To: [email-masked]<[email-masked]>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 31 Mar 2012 07:10:51 +0200

> because we are assuming implementers are too dumb to understand RFC 6020

This is kind of funny. The I-D actually says an incomplete NETCONF
implementation calls itself 'NETCONF Light' (and not 'NETCONF'2) while
you seem to prefer that an incomplete NETCONF implementation calls
itself 'NETCONF' and then posts some deviations.

(While server implementors might be too dumb, it might also be that
client implementors are too dumb to handle deviations well.)

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 31 Mar 2012 07:15:38 +0200

> use cases and specific subset of CM functionality that is mandatory

There is text describing the use cases etc. Perhaps you can help us by
telling us which of the features that the YANG module defines should
be manadatory for you to be happy.

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 30 Mar 2012 23:48:30 -0700

> client implementors are too dumb to handle deviations well.)

There is no NETCONF Light -- and I hope there never will be one.
That is just a meaningless marketing term.  NETCONF for Constrained
Devices might be OK if it provided some meaningful set of CM functionality.

Your draft assumes that customers are too dumb to know the difference.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 30 Mar 2012 23:53:54 -0700

> be manadatory for you to be happy.

You seem to think that constrained devices includes server developers
unwilling to implement NETCONF correctly.  I do not recognize that
class of power constrained devices.

But I'll play along -- I already did this and it got ignored:

   - get-config (with subtree filtering mandatory)
   - edit-config
   - close-session
   - lock
   - unlock

There is my minimum set that provides CM functionality.
One can perform CRUD operations safely on a device with these operations.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 31 Mar 2012 00:08:07 -0700

> itself 'NETCONF' and then posts some deviations.

You probably need to re-read section 5.6.4 of RFC 6020.
Advertising <uri> + deviations is the way YANG is designed.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 31 Mar 2012 00:27:15 -0700

> On Fri, Mar 30, 2012 at 10:07:46AM -0700, Andy Bierman wrote:
...
> itself 'NETCONF' and then posts some deviations.

The solution defined in this draft is completely broken.
It specifies several meaningless YANG features.  They have no affect
on YANG modules whatsoever unless a module contains 'if-feature'
statements identifying which nodes are conditional for the feature.

Your solution does not use YANG correctly.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 31 Mar 2012 11:28:47 +0200

> Your draft assumes that customers are too dumb to know the difference.

The way NETCONF Light is defined in the I-D, it is not a marketing
term. I understand you do not like the -01 I-D, I can follow your
argument that some set of NETCONF operations should be mandatory, the
rest however just seems to be noise.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 31 Mar 2012 11:38:09 +0200

> One can perform CRUD operations safely on a device with these operations.

On constrained devices, you do not need subtree filtering nor do you
have the resources to implement edit-config. But valuable to know that
your requirements differ from the -00 requirements as well.

/js

---

From: Andy Bierman <[email-masked]>
Date: Sat, 31 Mar 2012 06:09:13 -0700

> your requirements differ from the -00 requirements as well.

Do you have any proof to support these claims?
Why is subtree filtering not needed?
What if the bandwidth is very constrained and getting the
entire config is too slow?

IMO it is quite easy to implement these features if they are hard-wired
for the specific data models the server supports.

But let's ignore the solution space for now because we do not agree
on the problem space.

The draft does not describe the problem to be solved in terms of
the minimum set of configuration management functionality that
is needed.  There is no mention at all of the conceptual CRUD
operations or data models.  The WG must agree on this minimum
set of CM functionality before working on a solution.

Section 2.2 does not seem to have anything to do with constrained devices:

2.2.  Gradually Adding NETCONF Support

    While the NETCONF protocol defines a number of capabilities that may
    be optionally implemented, the base protocol remains a significant
    effort to add for existing devices.  For these devices, adding
    support for NETCONF is primarily driven by a specific integration
    target, thus the intrinsic goal is to have an initial release that
    satisfies the integration target and a subsequent release that
    implements the remainder of the NETCONF protocol.

    Some scenarios where phasing in the imeplmentation would be helpful
    include:

    o  The device's primary goal is to implement a vendor-specific
       capability.  In this case, the device is only using NETCONF for
       its "Messages" layer (i.e.  RPC, RPC-reply, and Notification).

This is not standard NETCONF at all so it is not relevant to the IETF.

    o  The device's primary goal is to just support read-only access to
       its configuration.  In this case, it only needs to implement <get-
       config> initially, leaving the remaining operations for a future
       release.

This is not useful configuration management.  read-only is monitoring.

    o  The device's primary goal is to enable full configuration, but it
       doesn't have the time to implement all the <edit-config>
       operations.  In this case, the device could implement just <copy-
       config>.

This is not a standards problem.  There is nothing in any of the RFCs
that says you have to ship incomplete code.

    o  The device's primary goal is to enable full configuration, but it
       is unable to implement <lock> or <unlock> due to its platform not
       having a locking mechanism yet.

This is simply an incomplete implementation and not a standards problem.

I cannot find any terminology in the CoAP documents that would suggest
that constrained devices includes any of the use cases above.  The term
always seems to refer to device resources at run-time, not developer
resources at build-time.  I suggest removing all text from your draft
that is not related to run-time device resources.

I would like to hear from other WG members if they think the definition
of constrained devices includes the use-cases in sec. 2.2.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 31 Mar 2012 16:29:37 +0200

> of constrained devices includes the use-cases in sec. 2.2.

You correctly figured out that section 2 provides two motivations
(sections 2.1 and 2.2) but you incorrectly lump them together thereby
creating noise but not a sound argument.

/js

---

From: Phil Shafer <[email-masked]>
Date: Sat, 31 Mar 2012 11:10:46 -0400

>your requirements differ from the -00 requirements as well.

Since subtree filtering is tied to the data model, can you
constrained device simply say that your data models do not
support subtree filtering?

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 31 Mar 2012 22:24:58 +0200 (CEST)

Phil Shafer <[email-masked]> wrote:
> Since subtree filtering is tied to the data model

Subtree filtering is tied to the NETCONF protocol, independent of the
data model or data modelling language.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sat, 31 Mar 2012 13:27:04 -0700

...
> creating noise but not a sound argument.

So you admit that sec. 2.2 has nothing to do with constrained devices.
Because the WG chairs asked if people wanted to work on
NETCONF for constrained devices.  They did not ask if the
WG wants to work on NETCONF Light.

Does anybody besides the co-authors want to solve the problems
identified in sec 2.2?  Please speak up, yes or no.
I agree with Bob that a standard subset of NETCONF picked by the WG is better
than a random subset picked by each vendor.  Does anybody prefer
a vendor-selected random subset instead of a meaningful subset selected
by the WG?

If the WG comes to some consensus on the problem space, then
we can talk about your 'feature-based' solution that doesn't
actually work because there are no corresponding if-feature
statements in the ietf-netconf module that would make the
new features relevant in YANG.

Andy