RE: Separation of protocol and information model

["Chen, Weijing" <Weijing_Chen@labs.sbc.com>]

> 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.
>
What is exact the problem with SNMP?  If it is the problem of RowStatus and
StorageType, then why throw out the other good part of SNMP like separation
of protocol operation and data model?  Like old proverb said, don't throw
baby out with dirty water.





--

Weijing Chen



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

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