Subject: Re: [Netconf] we are NOT CONVERGING towards consensus

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 13 Jun 2012 19:31:47 +0200

Hi All,

speaking as an individual.

I support the idea to provide a modular version of Netconf to enable the
implementers to choose the capabilities they would like to implement.
Let's call it Netconf 1.2 as Netconf 2.0 associates with substantial
changes nobody wants to have right now. I also support the proposal that
the WG should decide on the minimal set of mandatory features where my
impression was actually that we are converging.

I agree with Bert and Dan that providing a Netconf 1.2 does not
necessarily cause any issue with the backward compatibility. If a
Netconf 1.2 implementation aims to be compatible with Netconf 1.1 and
1.0 this can be achieved.

I believe that a modular Netconf can be useful for different deployment
scenarios including the implementation for those devices with  less
memory and resources. 

I also think that we should avoid a competing standard with
Netconf-Light as a standard track document. The modularity Netconf-Light
is proposing can be integrated into the Netconf 1.2 specification.

However, it is clear that this version of Netconf does not aim to and
cannot solve the issue of the management of constrained devices in
general. Instead of opening a new and huge construction site I am in
favor of defining a focused and concrete work which can be completed
soon. Those who discuss on the coma maillist will most likely need more
time to define the work items addressing all management needs for the
constrained devices and the resource constrained networks.

Mehmet 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext
> Romascanu, Dan (Dan)
> Sent: Wednesday, June 13, 2012 3:06 PM
> To: Bert Wijnen; Per Hedeland
> Cc: Netconf
> Subject: Re: [Netconf] we are NOT CONVERGING towards consensus
> 
> 
> Hi,
> 
> I am with Bert on this. Backwards compatibility in this context does
not
> mean to me that any version of an old client must work with any future
> version of a server. This would be forwards compatibility :-)
Backwards
> compatibility means IMO the capability to identify the version of the
> protocol run by the server and its capabilities and to be able to
manage
> what matches the agent version level, and to gracefully ignore and
alert
> the operator when the protocol interaction is not possible.
> 
> Regards,
> 
> Dan
> 
> 
> 
> 
> > -----Original Message-----
> > From: Bert Wijnen [mailto:[email-masked]]
> > Sent: Wednesday, June 13, 2012 3:04 PM
> > To: Per Hedeland
> > Cc: Romascanu, Dan (Dan); Ladislav Lhotka; Netconf
> > Subject: Re: [Netconf] we are NOT CONVERGING towards consensus
> >
> > On 6/13/12 1:42 PM, Per Hedeland wrote:
> > > On 2012-06-13 13:17, Romascanu, Dan (Dan) wrote:
> > >>
> > >> So, are you saying that NETCONF will never be able to be
> modularized
> > in
> > >> such a way that it can be used as a solution for managing devices
> > with
> > >> restrained resources?
> > >
> > > No, I'm mainly objecting to the use of "backwards compatible" to
> > > describe changes that clearly aren't. Obviously non-backwards-
> > compatible
> > > changes are sometimes deemed necessary, or at least better than
> other
> > > alternatives - it's a trade-off decision like so many others.
> > >
> >
> > I would think that an existing NetConf 1.1 client will check if the
> > managed
> > device supports NetConf 1.1 If so, it probably keeps using that set
of
> > capabilities. And so I see no problem.
> >
> > If a more advanced NetConf 2.0 client check if a managed device does
> > NetConf 2.0, and if it does, then it also needs to check if the
> > proper capabilities (those that were mandatory in Netconf 1.0 and
1.1)
> > are supported by the managed device, and if so... boom we're
running.
> > If not, the client can try to fallback to NetConf 1.1.
> > Is supported .. boom we're running.
> > If not supported, then that means a new (constrained) device is
being
> > managed, and probably there are fewer capabilities than those on
> > NetConf 1.1. The client can decide to not support that new
> > (constrained)
> > device, or it can decide to try to manage it with the lesser set of
> > capabilities.
> >
> > All existing/fielded Netconf 1.0 and 1.1 operational configurations
> > should
> > continue to work wothout a problem.
> >
> > Is that not BACKWARD COMPATIBLE ??
> >
> > Maybe I do not understand the term at all??
> >
> > Bert
> >
> >
> >
> >
> > > My *opinion*, as already stated, is that making such changes to
> > NETCONF
> > > would be seriously detrimental to the general "success" of the
> > protocol.
> > > I don't really have an opinion on whether implementation of the
> > > currently mandatory functionality actually is "too hard" for some
> > > unspecified class of "constrained" devices, nor whether it would
be
> a
> > > disaster if such devices do "something else" in that case.
> > >
> > > --Per
> 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf