RE: Separation of protocol and information model

[Andy Bierman <abierman@cisco.com>]

At 06:35 AM 9/4/2003, Allen, Keith wrote:
>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.

IMO it would be a mistake to push protocol operations into
the data model.  We did this in SNMP (e.g. RowStatus and 
StorageType) and it didn't work out too well.

Andy




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


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