[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: netconf charter proposal - rev B



> > 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?

> > 
> > 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. That would obsolete both after a while.

> > 
> > 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.

> 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.

Branislav

> > 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/>