Re: [Netconf] quick comment on NETCONF Light draft

[Andy Bierman <[e-mail]>]

On 01/18/2012 11:43 PM, Juergen Schoenwaelder wrote:
> On Wed, Jan 18, 2012 at 04:39:10PM -0800, Andy Bierman wrote:
>> Hi,
>>
>> I was looking over this draft:
>>
>> http://www.ietf.org/id/draft-schoenw-netconf-light-01.txt
>>
>> I can agree with the problem statement:
>> There is a need for a constrained server which supports a limited subset of NETCONF operations.
>>
>> I don't agree with the solution, since it is not backward-compatible with
>> any version of NETCONF.  A base:1.0 or base:1.1 peer will simply terminate
>> the session when a NETCONF Light peer does not advertise either of these capabilities.
>
> And this is correct. A NETCONF Light server does not implement
> base:1.0 nor base:1.1 - so announcing it would be bad.
>
>> YANG deviations can be used to fully describe the operations subset
>> that a server implements, and this is backward-compatible with the
>> current version of NETCONF.
>
> There are two concerns with this:
>
> 1) YANG says deviations can't be standardized:
>
>     Deviations define the way a device or class of devices deviate from a
>     standard.  This means that deviations MUST never be part of a
>     published standard, since they are the mechanism for learning how
>     implementations vary from the standards.
>

The purpose of deviations is to describe to the client what details in the API
are different than the 'contract'.  YANG deviations are designed and included in the standard
for exactly the purpose that a NETCONF light server needs.

> 2) Can we reasonably expect all client implementations, including
>     scripts, to handle deviations correctly? If not, announcing the
>     base:1.x with deviations will likely lead dumb clients to assume
>     the server speaks NETCONF while it does not. By using a different
>     capability, it is explicit from the start that the device
>     implements NETCONF Lite.
>

Yes, we can expect clients that implement YANG correctly to understand deviations.

IMO this 'light' solution is a hack -- a client would be better off ignoring all of this
and just going by the operation-not-supported errors it gets back.
A new client would have to be coded to look for the special new URI
instead of the old ones, then apply the features from the fake 'light' module
to the ietf-netconf module, and use the ietf-netconf module XML namespace as well.

Or, an existing client could ignore all the deviations and URIs
and just attempt operations to see if they worked.

> I believe it is more robust to use a different capability + features
> than using the NETCONF base:1.1 capability + deviations.
>

IMO, robust would be if the solution did not break with existing versions of the standard.
A non-backward-compatible solution is not robust at all.


> /js
>

Andy