Subject: [Netconf] we are NOT CONVERGING towards consensus

From: Bert Wijnen <[email-masked]>
Date: Wed, 13 Jun 2012 10:11:54 +0200

Dear WG participants,

We have 7 days (one week) left for responses to our consensus
call for NetConf 2.0. Anyone who still wants to express an
opinion or wants to comment on the discussions so far, please
do so by June 20th. In that case, PLEASE use as subject line:

    Subject: WG Consensus call: Netconf 2.0?

 From the discussion so far, it is pretty clear that we are
NOT CONVERGING towards consensus. As a matter of fact, it
feels to us that the WG is very much diverged as to what
kind of work needs to be done and with what priority/sequence.

The NetConf Lite discussion did not get us to consensus.
Yet, the WG expressed in Paris that we DO WANT/NEED to work
(or at least investigate) in the area of NetConf for
constrained devices.

The idea of the WG chairs was:

If we can do a NetConf 2.0 (or if NetConf 1.2 is more
appropriate, that is fine too) that we define with a
minimum (but agreed by the WG) set of mandatory features,
then all current NetConf 1.0 and 1.1 features can still be
published by existing implementations, and they are in the
same good shape as they are today. But it DOES allow for
constrained devices to choose the minimum (agreed) to
NetConf 2.0 (or 1.2) functionality and to expand on that
depending on the capabilities and needs of the constrained
device.

At the same time, by providing that modularity, all the
other features that have been discussed can be added as
new features (capabilities) to NetConf 2.0 (1.2).

We wanted to restrict the first step to "Making NetConf
more modular" to start with. Then adding other work items
(as discussed on the list) can be done over time. It seems
to us that that first step could be a pretty focused and
soon-to-be-completed work item.

But ... it seems not to be so.
Was this thinking completely wrong?
Or is it that we just rather keep discussing all sorts of
possible (or more important?) work instead of making the
first step?

We're confused. Please enlighten us.
Bert and Mehmet

---

From: Bert Wijnen <[email-masked]>
Date: Wed, 13 Jun 2012 10:41:21 +0200

On 6/13/12 10:24 AM, Romascanu, Dan (Dan) wrote:
> Hi Bert, Mehmet,
>
> I apologize for not using the required subject line but I am doing it on
> purpose. I am confused. The reason is that by discussing and asking for
> consensus for Netconf 2.0 you seem to be asking much more than:
>
>> more modular" to start with.
>
> This is different than:
>
>> allow for
> Can you clarify what the call for consensus is? (or what am I missing?)
>
> Is it only for 'modularized' Netconf?
>

I believe that is what we were asking for:

     Develop standards track NETCONF 2.0 with a new
     modular base version, which has a reduced set of
     mandatory features.
     The present functionality can be used as optional
     capabilities or YANG features.

Bert

> Thanks and Regards,
>
> Dan
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Bert Wijnen
>> Sent: Wednesday, June 13, 2012 11:12 AM
>> To: Netconf
>> Subject: [Netconf] we are NOT CONVERGING towards consensus
>>
>>
>> Dear WG participants,
>>
>> _______________________________________________
>> Netconf mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netconf

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 13 Jun 2012 10:46:26 +0200

> soon-to-be-completed work item.

IMO this is a very sensible scenario that is backward-compatible with NETCONF 1.1, includes NETCONF Light, and opens the space for new development and tests of alternative approaches. I believe it could also eventually help the development of more complex YANG models because, for example, the issue of configuration versus state data is still largely unresolved.

I understand though that the scenario somewhat undermines marketing assets of NETCONF.

Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 13 Jun 2012 10:47:42 +0200

> From: Bert Wijnen [mailto:[email-masked]]
> Sent: Wednesday, June 13, 2012 11:41 AM
> To: Romascanu, Dan (Dan)
> Cc: netconf
> Subject: Re: [Netconf] we are NOT CONVERGING towards consensus
> 
> > I apologize for not using the required subject line but I am doing
it
> on

Hi Bert,

The language is not clear that this is <only> about 'modularizing'
existing functionality. Calling it Netconf 2.0 increases the confusion.
But if it is only about defining the new modular version based on
existing functionality - I support it. 

Regards,

Dan

---

From: Per Hedeland <[email-masked]>
Date: Wed, 13 Jun 2012 11:20:08 +0200

> IMO this is a very sensible scenario that is backward-compatible with NETCONF 1.1, includes NETCONF Light, and opens the space for new development and tests of alternative approaches. I believe it…

[following the trend of ignoring Bert's request for a different subject]

Whatever opinions anyone may have on this, it should be a crystal clear
*fact* that making previously mandatory server functionality optional
(in any protocol) can *never* be considered backward-compatible, since
it breaks client implementations that rely on the presence of this
functionality.

My opinion: Making such non-backward-compatible changes in general, and
making <edit-config> optional in particular, at this point in the life
of NETCONF, will kill any remaining hope of having it become a
ubiquitous and truly interoperable way to manage device configuration.

--Per Hedeland

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 13 Jun 2012 12:03:27 +0200

> it breaks client implementations that rely on the presence of this

The functionality required by the old client can be provided as a module. Of course, the client will have to accept new NETCONF-2.0 capability URIs in the first place but other changes should not be needed. This is what I call backward compatibility.

It is pretty much like moving from a monolithic kernel to a modular one. The latter is not incompatible with the former, provided all necessary modules are properly loaded.

And I don't believe a server upgrade ever happens without considering the impact on clients.

Lada

---

From: Per Hedeland <[email-masked]>
Date: Wed, 13 Jun 2012 12:52:41 +0200

On 2012-06-13 12:03, Ladislav Lhotka wrote:
> The functionality required by the old client can be provided as a module.

I don't see how the form of the potential implementation of some
optional functionality is relevant. The point is that the client, per
the old spec, expects the functionality be present in any server
implementing the protocol - and with the change in the protocol, this
expectation is no longer fulfilled. This is non-backwards-compatibility.
Unless you assume that "someone" will somehow provide and deploy
"modules" implementing the optional functionality for every server
implementation and installation - in which case making it optional would
seem to be unnecessary.

> Of course, the client will have to accept new NETCONF-2.0 capability URIs in the first place but other changes should not be needed. This is what I call backward compatibility.

In that case I find your terminology to be at odds with commonly
accepted usage.

> It is pretty much like moving from a monolithic kernel to a modular one. The latter is not incompatible with the former, provided all necessary modules are properly loaded.

Not at all, this is an implementation detail. The application writer can
still rely on (say) the open(2) system call being present, since it is
mandatory per the POSIX standard - whether it is implemented in a
monolithic kernel or a module doesn't matter.

> And I don't believe a server upgrade ever happens without considering the impact on clients.

I guess this is where your problem is - you're thinking in the narrow
scenario of dedicated clients talking to specific servers. If terms like
"standard protocol" and "backwards compatibility" for such a protocol
should have any meaning, you need to consider all combinations of client
and server implementations, whether they actually happen to be talking
to each other in any real-life deployment or not. The very point of
standardizing a protocol is of course that all such combinations
*should* be able to function correctly.

--Per

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 13 Jun 2012 13:17:04 +0200

> Behalf Of Per Hedeland
> Sent: Wednesday, June 13, 2012 1:53 PM
> To: Ladislav Lhotka

...

> > Of course, the client will have to accept new NETCONF-2.0 capability
> URIs in the first place but other changes should not be needed. This
is
> what I call backward compatibility.
> 
> > It is pretty much like moving from a monolithic kernel to a modular
> one. The latter is not incompatible with the former, provided all
> necessary modules are properly loaded.
> 
> > And I don't believe a server upgrade ever happens without
considering
> the impact on clients.

Hi Per,

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? 

Regards,

Dan

---

From: Per Hedeland <[email-masked]>
Date: Wed, 13 Jun 2012 13:42:26 +0200

> such a way that it can be used as a solution for managing devices with

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.

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

---

From: Bert Wijnen <[email-masked]>
Date: Wed, 13 Jun 2012 14:04:04 +0200

> 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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 13 Jun 2012 15:05:45 +0200

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

> Sent: Wednesday, June 13, 2012 3:04 PM
> To: Per Hedeland
> Cc: Romascanu, Dan (Dan); Ladislav Lhotka; Netconf
> >> So, are you saying that NETCONF will never be able to be
modularized
> in

---

From: Andy Bierman <[email-masked]>
Date: Wed, 13 Jun 2012 07:40:04 -0700

On Wed, Jun 13, 2012 at 3:03 AM, Ladislav Lhotka <[email-masked]> wrote:

> >> IMO this is a very sensible scenario that is backward-compatible with
> NETCONF 1.1, includes NETCONF Light, and opens the space for new
> development and tests of alternative approaches. I believe it could also
> eventually help the development of more complex YANG models because, for
> example, the issue of configuration versus state data is still largely
> unresolved.
> >
> Of course, the client will have to accept new NETCONF-2.0 capability URIs
> in the first place but other changes should not be needed. This is what I
> call backward compatibility.
>
> It is pretty much like moving from a monolithic kernel to a modular one.
> The latter is not incompatible with the former, provided all necessary
> modules are properly loaded.
>

This isn't an upgrade.  A base:1.0 or 1.1 server would never upgrade to this
so-called "NETCONF 1.2".  A base:1.2 server would never advertise 1.0 or 1.1
so an existing client will reject the server <hello> and drop the session.

I think NETCONF-Light is a better name and capability than "NETCONF 1.2".
The false appearance of a protocol update would completely confuse the
market place.
I strongly object to calling the work NETCONF 1.2 since it is not an
upgrade.

I also think many of the WG members do not understand what makes
a NETCONF server heavyweight or not (e.g., getting rid of global <lock>
but keeping full-blown XML encoding).

I agree with Per that if a device does not have a standard way to
do configuration editing, then it isn't a NETCONF device.
It should be called something else.

> Lada

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 13 Jun 2012 17:02:33 +0200

On Jun 13, 2012, at 4:40 PM, Andy Bierman wrote:

> The false appearance of a protocol update would completely confuse the market place.
> I strongly object to calling the work NETCONF 1.2 since it is not an upgrade.
> 

Earlier today I heard a presentation of a guy who actively develops BIND 10. Guess what - the wrote something quite similar to NETCONF based on JSON. They did evaluate NETCONF but rejected it.
 
> It should be called something else.

OK, if it is only a branding issue, I don't mind calling it YUM-YUM 0.1.

Lada

---

From: Carl Moberg <[email-masked]>
Date: Wed, 13 Jun 2012 17:23:23 +0200

> Earlier today I heard a presentation of a guy who actively develops BIND 10. Guess what - the wrote something quite similar to NETCONF based on JSON. They did evaluate NETCONF but rejected it.

 I could tell you many stories where people reviewed and rejected NETCONF since it didn't meet their requirements. So; why (based on which criteria) did they reject NETCONF? Would they have done otherwise if we had a "NETCONF 2.0" now?

--
Carl Moberg, Tail-f Systems
mailto:[email-masked]
twitter: @cmoberg
http://www.tail-f.com/

---

From: Andy Bierman <[email-masked]>
Date: Wed, 13 Jun 2012 09:48:07 -0700

On Wed, Jun 13, 2012 at 8:23 AM, Carl Moberg <[email-masked]> wrote:

> > Earlier today I heard a presentation of a guy who actively develops BIND
> 10. Guess what - the wrote something quite similar to NETCONF based on
> JSON. They did evaluate NETCONF but rejected it.
>
>  I could tell you many stories where people reviewed and rejected NETCONF
> since it didn't meet their requirements. So; why (based on which criteria)
> did they reject NETCONF? Would they have done otherwise if we had a
> "NETCONF 2.0" now?
>
>
And we could tell stories about companies using NETCONF too...

<shameless-plug>
I'm biased, but I think YANG-API addresses many of the issues
that cause NETCONF to be rejected as a solution by application
developers.  I don't think these people share the same requirements
and toolsets as traditional NMS developers.  Each group needs
their own API. The traditional NMS group is covered with NETCONF 1.1.

I don't think configuration of a constrained device should use the same
hammer as a router.  Making the hammer smaller only works to a point.

Stateless RESTful operations encoded in JSON can be much less
heavyweight than NETCONF.  I think YANG-API scales from very
small devices to huge routers with multiple candidates.
</shameless-plug>

--

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 13 Jun 2012 18:49:31 +0200

On Jun 13, 2012, at 5:23 PM, Carl Moberg wrote:

>>> I strongly object to calling the work NETCONF 1.2 since it is not an upgrade

Probably not, their "configuration manager" (we would call it server) uses RESTful API and JSON.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 13 Jun 2012 19:17:17 +0200

> I'm biased, but I think YANG-API addresses many of the issues

Everyone here is biased. :-)

> hammer as a router.  Making the hammer smaller only works to a point.

Well, a multi-core DNS server cannot be classified as a constrained device. I don't think a RESTful API is a priori more primitive or technically inferior compared to NETCONF.
 
> small devices to huge routers with multiple candidates.

Yes, I like it. Perhaps it makes more sense to develop this approach instead of fighting around NETCONF 2.0.

Lada

---

From: Carl Moberg <[email-masked]>
Date: Wed, 13 Jun 2012 19:20:21 +0200

> Probably not, their "configuration manager" (we would call it server) uses RESTful API and JSON.

 So how does this contribute to our understanding of the criticality of the perceived shortcomings in NETCONF (and YANG)?

 I know about people that use XMPP for configuration, does this mean that REST needs to be fixed because they didn't use that?

---

From: Andy Bierman <[email-masked]>
Date: Wed, 13 Jun 2012 10:40:06 -0700

On Wed, Jun 13, 2012 at 10:20 AM, Carl Moberg <[email-masked]> wrote:

> upgrade
> >>> Earlier today I heard a presentation of a guy who actively develops
> BIND 10. Guess what - the wrote something quite similar to NETCONF based on
> >> I could tell you many stories where people reviewed and rejected
> NETCONF since it didn't meet their requirements. So; why (based on which
> criteria) did they reject NETCONF? Would they have done otherwise if we had
> a "NETCONF 2.0" now?
> >
>  So how does this contribute to our understanding of the criticality of
> the perceived shortcomings in NETCONF (and YANG)?
>
>  I know about people that use XMPP for configuration, does this mean that
> REST needs to be fixed because they didn't use that?
>
>
http://dnsccm.org/

Here is a project that is using NETCONF/YANG to configure DNS.
I don't think 1-size-fits-all is realistic.  Different tools supporting
different protocols leads to multiple ways to do the same thing.
It solves the "can't get there from here" problem though.

--
Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 13 Jun 2012 19:56:19 +0200

> So how does this contribute to our understanding of the criticality of the perceived shortcomings in NETCONF (and YANG)?

It contributes to my understanding that NETCONF isn't a terribly attractive option for an average developer these days.

> I know about people that use XMPP for configuration, does this mean that REST needs to be fixed because they didn't use that?

XMPP is only a message layer, so we'd need to see their application protocol. Sure, REST is a trendy word, but it is also condensed experience of almost twenty years of web application programming, so I don't think it can be labelled as just another hype.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 13 Jun 2012 20:41:48 +0200

On Jun 13, 2012, at 8:08 PM, Carl Moberg wrote:

> 
> 
> 
> 
> On 13 jun 2012, at 19:56, Ladislav Lhotka <[email-masked]> wrote:
> 
>> 
> In order to try and avoid going around one more time: what was the reasons for NOT using NETCONF in the example that you're presenting? Without knowing that I think it's hard to move the doscussion forward, no?

I don't really know the whole story, for sure XML was one of the reasons against NETCONF.

> Ok, my point was that inferring that "X is broken because a group of people went for Y instead" is less useful unless we know the selection criteria.

I never said that. Thing is, developers prefer to use technologies they already know and NETCONF is an obscure and relatively complex stuff for them. Who wants to investigate the hairy details of <edit-config> if the familiar HTTP methods work just fine? Keep it simple, stupid.

Lada

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 13 Jun 2012 18:54:07 +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 

> 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
> > > unspecified class of "constrained" devices, nor whether it would
be
> a

---

From: Carl Moberg <[email-masked]>
Date: Wed, 13 Jun 2012 20:08:02 +0200

---

From: Carl Moberg <[email-masked]>
Date: Wed, 13 Jun 2012 23:36:43 +0200

> I don't really know the whole story, for sure XML was one of the reasons against NETCONF.

 I'm getting confused; are you proposing NETCONF move away from XML on the wire? If not; what is the reasoning behind bringing up the example in a discussion around NETCONF next steps?

> I never said that. Thing is, developers prefer to use technologies they already know and NETCONF is an obscure and relatively complex stuff for them. Who wants to investigate the hairy details of <…

 This one is easy: the ones that buy into the many features of NETCONF that provides benefits well above and beyond the alternatives (including SNMP, SOAP, and REST)! If you don't think NETCONF provides tangible benefits over the alternatives; then don't use it.

---

From: Per Hedeland <[email-masked]>
Date: Thu, 14 Jun 2012 12:54:46 +0200

> are supported by the managed device, and if so... boom we're running.
[snip]
> Is that not BACKWARD COMPATIBLE ??

I guess the problem is that we are throwing around the term without
saying what is backward compatible with what. What you are saying is
basically that if a server supporting 1.1 is (unlikely or not) upgraded
to also support 2.0, that is a backwards compatible change. And I of
course agree with that - but it doesn't mean that 2.0 is backwards
compatible with 1.1.

Maybe there is some point in making the statement "2.0 is a backwards
compatible change to the protocol" even though 2.0 *isn't* backward
compatible with any earlier version - but then it basically only means
that there is a well-defined way for a 1.1-only client to find out that
it is unable to interoperate with a 2.0-only server. The only way you
could make a *non* backwards compatible change would be to fail to bump
the version number when you should have, which IMO should be called
"broken" or "bug". Thus I find the statement at best meaningless, at
worst misleading.

--Per

---

From: Andy Bierman <[email-masked]>
Date: Thu, 14 Jun 2012 06:33:09 -0700

> course agree with that - but it doesn't mean that 2.0 is backwards
The end result of NETCONF-Light would be that the "base:1.1" capability
string gets replaced by N different capability strings.
A server which conforms to base:1.1 will be able to send
both base:1.1 and all the new capability strings as well.
For a server that already implements base:1.1, the "new" protocol
will be a step backwards -- it does the same thing as before
but just takes more bytes on the wire to do it.  The the only way
NETCONF Light can be backward compatible with existing clients
is to advertise base:1.0 or base:1.1.  If it could do that, then it
wouldn't need NETCONF Light.

The theory is that the client developers will rewrite their code
so instead of sending a request and getting back an
'operation-not-supported'
error, the app can use the capabilities, and print that error message
without
sending a request.

NETCONF Light is not intended to be backward-compatible.
It is intended to be implemented by new servers that cannot advertise base
1.0
or base:1.1 for whatever reason.

Whether the application business logic still works after taking away
significant
CM functionality seems to be a secondary issue to some, but to me it
is the most important factor.

> "broken" or "bug". Thus I find the statement at best meaningless, at

I strongly oppose the name NETCONF 1.2 because it is not an upgrade.
The capability (and draft) is called NETCONF Light.
I don't understand how that morphed into NETCONF 1.2.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 14 Jun 2012 16:07:23 +0200

On Thu, Jun 14, 2012 at 06:33:09AM -0700, Andy Bierman wrote:
 
> NETCONF Light is not intended to be backward-compatible.  It is
> intended to be implemented by new servers that cannot advertise base
> 1.0 or base:1.1 for whatever reason.

So we call it NETCONF 0.5. ;-)

But, seriously, there was a reason why we originally called it NETCONF
Light and not NETCONF. I agree that if a possible future NETCONF 2.0
version would be more modular, then NETCONF Light would not be
needed. That alone, however, does not seem a reasonable reason to do
NETCONF 2.0 (and probably not even for 1.2 since 1.1 and 1.2 implies
likely more compatibility than a major version number bump).

I have to study the REST API more closely and ideally get
implementation experience with it. If it maps nicely to CoAP, this
might be a much better choice for the constrained devices I have in
mind than NETCONF Light ever was. But I lack implementation experience
with this - so I do not really know.

My personal conclusion from this discussion is to do nothing about
NETCONF Light at the moment. We better spent our time on a REST API,
this seems far more important than NETCONF Light and might make
NETCONF Light a non-issue.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 14 Jun 2012 16:12:58 +0200

> but just takes more bytes on the wire to do it.  The the only way

But a new server can easily replace some of the non-core capabilities with alternative functionality - for example, to provide transactions with optimistic execution instead of locks. In my view, this is an improvement.  

...

> I don't understand how that morphed into NETCONF 1.2.

Because there is no point in keeping two separate versions if one modularized version can eventually be used everywhere.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 14 Jun 2012 16:17:46 +0200

> NETCONF Light a non-issue.

+1

Lada

---

From: t.petch <[email-masked]>
Date: Thu, 14 Jun 2012 16:34:47 +0100

----- Original Message -----
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Bert Wijnen" <[email-masked]>; "Per Hedeland" <[email-masked]>
Cc: "Netconf" <[email-masked]>
Sent: Wednesday, June 13, 2012 2:05 PM

Dan

I think that what you describe is a very sophisticated flavour of
compatibility, that is that if one is prepared to write sophisticated
enough code, almost anything can be made to work with almost anything
else, the exception being when B shuts down the connection and refuses
to respond ever again on receiving something it does not understand from
A.

I think that the more common parlance is making optional additions
without which something meaningful can still be achieved, so B remains
out in the sticks unaltered for years, while A gets new features which
allow it to get more from upgraded boxes but can still do something
meaningful with old-fashioned B.

What is being discussed here seems quite at odds with that.

Tom Petch

be

---

From: Phil Shafer <[email-masked]>
Date: Thu, 14 Jun 2012 11:47:06 -0400

"Romascanu, Dan (Dan)" writes:
>version of a server. This would be forwards compatibility :-)

It's a relative question, since you've got two directions here.

Backwards compatibility means "continues to work with old input".
Forwards compatibility means "continues to work with new input".

So for a client/server system, backwards compatibility means
if a client send old data, the server needs to be able to handle
it and if the server send old data, the client needs to be able
to handle it.

Similarly for forwards compatibility, if the client sends new input,
the server needs to be able to handle it.  If the server send new
input, the client needs to be able to handle it.

In the real world, if you break either of these, you have irate
customers and get called into meetings with senior mgmt to explain
why your change is more important than the customer ;^)

Me, I'm still having trouble understanding why folks are more
interested in perturbing N/Y.  Shouldn't we be putting time into
evangelizing, promoting, using, building, and things that will
help adoption instead of "2.0" efforts that will hamper it?

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Thu, 14 Jun 2012 12:08:25 -0400

> I don't really know the whole story, for sure XML was one of the reasons against NETCONF.

Okay, so they liked:

interfaces: {
    interface: {
        name: "fe-0/0/0";
        description: "Local interface";
    }
}

instead of:

<interfaces>
    <interface>
        <name>fe-0/0/0</name>
        <description>Local interface</description>
    </interface>
</interfaces>

I'm assuming the story can't be this simple.  N/Y offers _much_
more than a local, custom, JSON-based protocol can.  The volume of
functionality they'll have to brew on their own is large.

So that means we can either believe that N/Y adoption is limited because:

(a) we do not have open source tools of sufficient quality and
functionality.
(b) those tools do not have a community of support for them.
(c) we are not evangelizing our story sufficiently for folks to
understand the value of the technologies.
(d) we do not integrate well with other software.
(e) we aren't putting our time into issues that matter.

_or_ we can believe N/Y adoption is limited because:

(1) users have an insane fear of angle brackets.
(2) connection startup is ugly.

FWIW:  I can easily admit that dealing with JSON in javascript is
easier than dealing with XML, but I firmly believe if we had a
XMLParse() that made natively-keyed objects like JSONParse(), this
would not be an issue.  (And I don't know how many network mgmt
apps are being written in javascript anyway.  I'm guessing that
bind10 is not.)

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Thu, 14 Jun 2012 09:28:49 -0700

> why your change is more important than the customer ;^)
I agree.  The argument that the new server will advertise all
versions of the protocol doesn't apply when you are talking
about removing mandatory-to-implement things.
I think NETCONF has enough server options already,
and making almost everything optional is not a step forward.

> help adoption instead of "2.0" efforts that will hamper it?
I agree that nothing is broken and tweaking is optional.
I don't want to make NETCONF 1.1 appear obsolete.
We have customers interested in "NETCONF Light", not NETCONF 1.2 or 2.0.
They expect the server resources to be dramatically reduced
by NETCONF Light, so it can fit on small boxes.

I don't think removing major features is the best approach.
For small devices that already have a tiny WEB server, a REST API
using JSON is going to be way less additional overhead than adding
SSH and XML support.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 14 Jun 2012 22:55:47 +0200

>        description: "Local interface";

Looks familiar. :-)

> functionality they'll have to brew on their own is large.

They already had some infrastructure for messaging among daemons, so they reused it for remote configuration purposes. And I don't think it is so difficult to find generic components providing the necessary functionality. 

> (2) connection startup is ugly.

Most projects, including BIND 10, just write their own client (or simply use a web browser) and maintain it as a part of the system. Without hellos etc., the communication protocol is not a big deal. 

> apps are being written in javascript anyway.  I'm guessing that

No, it's C++ and Python. But JSON parser is trivial, unlike XML parser.

Lada

---

From: Phil Shafer <[email-masked]>
Date: Thu, 14 Jun 2012 18:40:02 -0400

>No, it's C++ and Python. But JSON parser is trivial, unlike XML parser.

libxml2 and libxslt have python bindings.  Part of the value of
standards is that you don't need to roll your own (JSON or XML)
and can use libjson or libxml2.

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 15 Jun 2012 09:43:44 +0200

> and can use libjson or libxml2.

Sure, but adding libxml2 to your dependencies is not without cost. Moreover, JSON is parsed straight to C structures or Python dictionaries, while with XML you get a DOM or something similar.

Of course, nobody can blame NETCONF for choosing XML in 2003.

Lada

---

From: Phil Shafer <[email-masked]>
Date: Fri, 15 Jun 2012 11:58:42 -0400

>Of course, nobody can blame NETCONF for choosing XML in 2003.

And hopefully no one will blame the w3c for choosing it for HTML5
(in 2009 ;^).

FWIW, I favor XML because it gives three axis of richness (hierarchy,
namespaces, attributes).  Hierarchy gives you rich data, namespaces
give you rich extensibility, and attributes give you rich metadata.
NETCONF/YANG uses all three.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Fri, 15 Jun 2012 10:02:55 -0700

> NETCONF/YANG uses all three.
Perhaps the YANG/NETCONF/XML combination is not the right solution
for every use-case.  XML also has processing instructions, and lots of
complex flexibility how namespaces are used.

JSON encoding of YANG with module namespaces provides 2 of the 3:
http://tools.ietf.org/html/draft-lhotka-yang-json-01

HTTP separates meta-data as headers instead of including it in the data.
This can be easier to use if it replaces lots of attributes.  The arbitrary
mix
of nc:operation attributes within the <edit-config> tree allows
fine-grained control
for the client, but it can be expensive to implement in the server.

I think NETCONF, CLI, WEBui, HTTP/REST, SNMP, and even SYSLOG all need to
operate within a unified management framework. YANG could be the glue that
pulls
them all together.  I like NETCONF 1.1 + XML just fine and would not use
any other
access method for a traditional NMS or EMS.   I wouldn't pick it for some
other use-cases though.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 15 Jun 2012 22:46:57 +0200

> And hopefully no one will blame the w3c for choosing it for HTML5

This is something else - HTML is text with markup, i.e. mixed content. For hierarchical data, the game is over. Last year I attended an XML conference, and a good deal of papers was actually about JSON.

Lada

---

From: t.petch <[email-masked]>
Date: Mon, 18 Jun 2012 10:17:07 +0100

---- Original Message -----
From: "Phil Shafer" <[email-masked]>
To: "Ladislav Lhotka" <[email-masked]>
Cc: "Netconf" <[email-masked]>
Sent: Friday, June 15, 2012 4:58 PM

> NETCONF/YANG uses all three.

Three axes of complexity, three axes within which to foul things up:-(

When I first studied XML, I read a series of papers on its richness, how
it could do things this way or that, you could use one way or another,
etc etc etc.  So someone creating with it has an easy task, they pick
the options they are comfortable with.  Those consuming have a difficult
task, having to cope with every single option since someone somewhere
will have used it.

More generally, the creators of such things as XML underestimate the
complexity of what they are living with day in, day out, and then do not
realise why their ideas are not immediately seen for how good they are.
To the creators, what they have created should seem simple, elementary,
else it will be too complex for those not living with it day in day out.

Not quite the same thing as producing a subset for constrained devices,
more a question of producing a subset for constrained (human) users.

Tom Petch

---

From: <[email-masked]>
Date: Mon, 18 Jun 2012 11:42:44 +0100

Having returned to this thread after a few days off and therefore
reading all the emails in one sitting, one thing seemed to crop up once
in a while without apparently being followed up:

On Wednesday, Carl wrote:

This one is easy: the ones that buy into the many features of NETCONF
that provides benefits well above and beyond the alternatives (including
SNMP, SOAP, and REST)! If you don't think NETCONF provides tangible
benefits over the alternatives; then don't use it.

On Thursday, Phil wrote:

Shouldn't we be putting time into evangelizing, promoting, using,
building, and things that will help adoption instead of "2.0" efforts
that will hamper it?

And again:

Over the last couple of years I have been trying to identify the most
appropriate management approach for future programmes and finally came
to the conclusion that NETCONF/YANG seemed to provide what we needed.
However, apart from NETCONF Central and YANG Central, there was nothing
readily available to help me reach that conclusion. (I at least managed
to find a book on CIM/WBEM which managed to convince me that was not the
direction I wanted to take!)

Subsequently I have been reading the RFCs and following the netconf and
netmod mailing lists. However I have often found it hard to see the wood
for the trees. RFCs by their nature have to be rigorous and, for those
already in the know, are a useful reference and reminder, but they do
not provide an easy way into the subject.

Back in February Juergen, replying to one of my emails, stated:

If you want to start a draft on implementation guidelines, by all means,
please do so. I am not saying everything is totally obvious from the
specs. (And I guess this is even more true for NETCONF than it is for
YANG.) Having a NETCONF / YANG implementation guidelines document at
some point in time might really be useful.

Unfortunately, even now I don't feel anywhere near knowledgeable enough
to embark on such an endeavour, though such a document would certainly
help. 

And the problem I have is that I am trying to convince developers of the
benefits of NETCONF/YANG when they are working flat out and don't have
the time to get up to speed on a new technology, particularly with
sparse documentation by way of an introduction to the benefits of such
an approach.

I have written a couple of documents introducing NETCONF and YANG, but
would really benefit from some introductory documentation from those who
already know both.

I guess what I am trying to say is that, from a newby's perspective,
there is a need for more evangelising and introductory material. If that
could be made available, I would be more than willing to be an ignorant
guinea pig who could review the output (though I like to think I am not
as ignorant as once I was).

For developers, An O'Relly publication (or, if necessary, a NETCONF/YANG
for Dummies) would be really helpful. But together with that, something
more lightweight and digestible might convince more of the benefits.

One other thing, before I get off my soapbox... RFC3535 "Overview of the
2002 IAB Network Management Workshop" obviously had an influence on the
development of NETCONF. Pulling on the information in that RFC (which
many would probably not even stumble across) would make an excellent
introduction to the reasons for NETCONF and the benefits it brings.

I'll climb down now!

Jonathan

> From: Phil Shafer [mailto:[email-masked]]
> Sent: 14 June 2012 17:08
> To: Netconf
> > I don't really know the whole story, for sure XML was one of the
reasons
> against NETCONF.

This email and any files attached are intended for the addressee and may contain information of a confidential nature. If you are not the intended recipient, be aware that this email was sent to you in error and you should not disclose, distribute, print, copy or make other use of this email or its attachments. Such actions, in fact, may be unlawful. In compliance with the various Regulations and Acts, General Dynamics United Kingdom Limited reserves the right to monitor (and examine for viruses) all emails and email attachments, both inbound and outbound. Email communications and their attachments may not be secure or error- or virus-free and the company does not accept liability or responsibility for such matters or the consequences thereof. General Dynamics United Kingdom Limited, Registered Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and Wales No: 1911653.

---

From: Andy Bierman <[email-masked]>
Date: Mon, 18 Jun 2012 08:00:26 -0700

Hi,

I think it was probably a mistake to couple the NETCONF protocol to XML
encoding.
It relies on XML attributes for <edit-config> to work.  The other uses of
XML attributes
were just ad-hoc decisions that could have been done with elements instead.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 18 Jun 2012 08:54:00 -0700

Hi,

For better or worse, RFCs tend to leave out most of the rationale for a
particular decision.
This means RFCs tend to be horrible for tutorial reading.

IMO, until "Cloud" came along, NETCONF was seen by vendors as an internal
protocol so
the internal NMS dept. could control the hardware they sell.  Now some of
their customers
have business cases for device programmability, so maybe the visibility of
NETCONF will change.

It's a lot of work to write books, free software tools, free WEB sites,
etc.,
so I'm not surprised that these resources are scarce for NETCONF.
I agree we could write more RFCs to help but nobody is volunteering.
The focus is on standard data models for NETCONF at this point.

But even with lots of free help, that doesn't change this thread.

I would sum up this thread as:

  - The vendors/users of products where NETCONF is a good use-case fit
don't see any
     need to make changes.

 - The vendors/users of products where device configuration is needed, but
NETCONF does not
    look like a good fit, want to make changes to better address their use
cases.

I do not see any compelling reasons to introduce a new version of the
NETCONF protocol
at this time.  NETCONF-Light is not the right CM solution for tiny boxes,
so better to
just leave what works alone.

I don't think NETCONF-Light will have a significant impact on server
implementation footprint, and
it is too state-full and too flexible for the client to be efficiently
implemented in the server.
I am also concerned that removing <edit-config> and just using <copy-config>
for replacing the entire running config at once is the wrong way to do CM.

Andy

On Mon, Jun 18, 2012 at 3:42 AM,
<[email-masked]>wrote:

> This email and any files attached are intended for the addressee and may
> contain information of a confidential nature. If you are not the intended
> recipient, be aware that this email was sent to you in error and you should
> not disclose, distribute, print, copy or make other use of this email or
> its attachments. Such actions, in fact, may be unlawful. In compliance with
> the various Regulations and Acts, General Dynamics United Kingdom Limited
> reserves the right to monitor (and examine for viruses) all emails and
> email attachments, both inbound and outbound. Email communications and
> their attachments may not be secure or error- or virus-free and the company
> does not accept liability or responsibility for such matters or the
> consequences thereof. General Dynamics United Kingdom Limited, Registered
> Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and
> Wales No: 1911653.

---

From: t.petch <[email-masked]>
Date: Mon, 18 Jun 2012 18:12:56 +0100

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Sent: Monday, June 18, 2012 11:42 AM

Jonathan

That probably makes you best qualified to produce such a document.

As I say every now and then, experts sometimes produce documents that
are comprehensible only to other experts, whereas someone less
knowledgeable better recognises what is hard to understand, what the key
points are and what is needed to make it clear.

Yes, you may get a lot wrong before you get it right, but what you
eventually produce may well be better than that which anyone else could
produce.

Honest.

Tom Petch

---

From: <[email-masked]>
Date: Tue, 19 Jun 2012 10:00:21 +0100

> eventually produce may well be better than that which anyone else
could

So, if one were to contemplate such an endeavour, should the outcome be
an RFC or some other form of publication? What is a more appropriate
medium in which to evangelise? For example, print or web, formal or
informal, etc?

And what level of peer review could one expect? As you say, there are
plenty of opportunities to "get a lot wrong" and, without peer review,
this task would ultimately have involved a lot of nugatory effort.
Misinformation is far more damaging than no information.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 19 Jun 2012 13:00:12 +0200

> Misinformation is far more damaging than no information.

I am confident that there are enough people here who will help with
reviews because it is their interest that what is written down is
technically correct.

/js