RE: netconf charter proposal - rev B

[Andy Bierman <abierman@cisco.com>]

At 09:24 AM 4/8/2003 -0700, Branislav Meandzija wrote:

>> > IMO, this will represent the beginning of standards-based 
>> > network configuration, not the end.  There are lots of
>> > operators who are not using SNMP to configure their networks.
>
>Correct, but why would vendors invest into XMLconf to replace their CLI scripting? What is the pressing reason and benefit?

I can only speak for the router vendor I work for:
Customers don't like writing and maintaining lots of scripts
that interact with the CLI.  Many want a programmatic interface.
We have had extremely positive feedback on the XML-based API
work we've done already.  There are plans to continue with
more XML based API work.  We are very interested in netconf,
and hope that it will result in a protocol we can use.


>> > 
>> > As I stated before, I seriously doubt any vendor will yank SNMP
>> > code from their products because they add support for netconf.
>
>Products continuously get updated. It takes effort to keep instrumenting SNMP. My guess would be that only the CLI will reflect the latest and greatest while SNMP and netconf will be an after-thought. 

This is the situation now for SNMP.  There have been I-Ds written
on why SNMP is more difficult to support than the CLI, so I won't
go near that rat-hole now.  XML is a much closer fit with CLI
than SNMP.  It is much more likely that CLI and XML APIs will be 
done at the same time with the same code.

>That would obsolete both after a while.

Customer demand keeps features alive -- nothing else. 
The demand for SNMP may go down over time -- or not.
IMO, netconf is trying to make screen-scraping
obsolete, and nothing more.



>> > 
>> > There is no reason the semantics embodied in standard MIBs
>> > cannot be preserved as they are converted to a syntax that
>> > is compatible with the netconf protocol.  There is no reason
>> > to believe standard data model work will stop.  It will likely
>> > evolve, but not stop.
>> > 
>
>I think this is the corner out of which this possibly could be pulled off. It would need to start with the information model represented by the MIBs. The message would have to be simple and tools would have to be available.

It's easy enough to preserve the DESCRIPTION clauses and
SYNTAX clauses.  The smidump program preserves just about
all the SMIv2 features in the XSD conversion.


>> Right. WE have SNMPv3 and SMIv2 at full IETF STD level. 
>> We also have a number of MIB modules at STD, many more at DS
>> and PS. No need to trow that away. 
>
>It is not really throwing away. More like, using it less and less as it is becoming more and more obsolete.
>
>> 
>> Also... keeping SNMP for monitoring (or even for control and/or
>> configuration for those technologies where people want to use it)
>> is OK.
>> 
>> My intended ID should say something about that.
>> 
>> Hope this helps,
>> Bert
>
>There needs to be a very clear, simple, unambiguous message describing why this will succeed. The message needs to consider the realities of the market place and the history and past experience with network management.

A few sentences in a charter are not going to have any effect
on the success or failure of the WG effort. Those that want
it to succeed will participate, and those that don't will
either ignore it or launch DoS attacks against it. 



>Branislav

Andy


>> > Andy
>> 


--
to unsubscribe send a message to xmlconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/xmlconf/>