RE: Separation of protocol and information model

["Allen, Keith" <Keith_Allen@labs.sbc.com>]

Bobby Krupczak wrote:
> W/o tackling (e.g. standardizing on) some of the
> data-model (not necessarily in the protocol but in accompanying docs),
> is this effort worthwhile?  

We felt the same way.  Early on there was talk of forming a WG to tackle the
development of some standard schema but that seems to have died down.  Our
preference was to design a very simple protocol and develop some of the more
complicated features (killing sessions, locking, copying and validating
configurations, etc.) in a standard MIB along with a standard equipment
model, interface models, and so on.  It seems, though, that we are on a
course to build some of the complicated features into the protocol and stop
there.


Keith Allen
SBC Labs
9505 Arboretum Blvd.
Austin, TX 78759
(512) 372-5741
keith_allen@labs.sbc.com
 


> -----Original Message-----
> From: Bobby Krupczak [mailto:rdk@krupczak.org]
> Sent: Wednesday, September 03, 2003 8:07 PM
> To: phil@juniper.net
> Cc: Keith_Allen@labs.sbc.com; netconf@ops.ietf.org
> Subject: Re: Separation of protocol and information model
> 
> Hi!
> 
> >I think there's a division between what the configuration can contain
> >and how it can be manipulated.  What I'd like to see is a protocol that
> >can take a chunk of opaque configuration and load it only a router, with
> >the maximum degree of reliability, recoverability, and transactionality
> >available in the device's software.
> 
> >The content is the device's data model, which netconf is avoiding.
> >The management is what we're trying to solve.  I can make fairly
> >simple xslt scripts to turn a generic definition of what I want a vpn
> >to look like into a set of configurations for each involved device
> >(and to make it vendor/product/release specific).  I just need
> >a simple and robust mechanism for loading those deltas onto devices.
> >
> >At the same time, I want an extensible mechanism so that applications
> >can take advantage of features like candidate configuration, rollback,
> >locking, named configurations, etc.  And I want something open to
> >future extensions so that the Next Great Idea (tm) can be added
> >incrementally to both devices and applications.  When my
> >time-travel-based pre-corrective measure project comes to fruition, I
> >want to be able to see it get used without having to travel back to
> >now and add it to this spec. ;^)
> 
> I'm having a difficult time seeing how the working group can really
> pull this off and come up with something that really benefits the
> Internet community.  That is, is the resulting standardized protocol
> really worth it.  W/o tackling (e.g. standardizing on) some of the
> data-model (not necessarily in the protocol but in accompanying docs),
> is this effort worthwhile?  It almost seems to be like standardizing
> on SNMP w/o any standard-mibs.  While the ability to have
> private-enterprise mibs was a key to SNMP's success, not having
> standard MIBs would have surely killed it.  In essence, the Internet
> Management Framework community was specifying what it meant to manage
> a device and in term, it was specifying what and how devices should
> handle management information.
> 
> At this point, these comments are probably not terribly helpful to the
> working group as the charter, focus, and specs are already underway.
> 
> I'll probably have to partially re-invent the wheel as I'm really look
> for a bit broader and deeper replacement for SNMP.
> 
> Thanks,
> 
> Bobby

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