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

[Juergen Schoenwaelder <[e-mail]>]

On Sat, Mar 31, 2012 at 06:09:13AM -0700, Andy Bierman wrote:
> On 03/31/2012 02:38 AM, Juergen Schoenwaelder wrote:
> >On Fri, Mar 30, 2012 at 11:53:54PM -0700, Andy Bierman wrote:
> >>
> >>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.
> >
> >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.
> >
> 
> 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.

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

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>