Re: [Netconf] Netconf Light or Netconf for constrained devices

[Andy Bierman <[e-mail]>]

On 03/30/2012 01:47 AM, Bert Wijnen (IETF) wrote:
> 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.
>


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