RE: Separation of protocol and information model

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

Andy Bierman wrote:
> 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.
>

The designers of SNMP were confident they could design a protocol with all
the operations that management applications would ever need, so they didn't
enable MIB designers to add their own.  Now you think this group can do a
better job, and granted this group's list of operations is longer.  We're
still afraid, however, that it won't work out too well.  Thus, we're
proposing a more object-oriented approach that lets MIB designers define
which objects can be applied to object classes, and to extend the set of
operations if necessary.  Had the SNMP designers done this there would be no
RowStatus and we might all be using SNMP for configuration.

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


> -----Original Message-----
> From: Andy Bierman [mailto:abierman@cisco.com]
> Sent: Thursday, September 04, 2003 8:48 AM
> To: Allen, Keith
> Cc: 'Bobby Krupczak'; netconf@ops.ietf.org
> Subject: RE: Separation of protocol and information model
> 
> 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/>