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

[Andy Bierman <[e-mail]>]

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.


> /js
>


Andy