[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Separation of protocol and information model
At 07:27 AM 9/4/2003, Allen, Keith wrote:
>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.
There are many reasons SNMP/SMI has not been widely deployed
for configuration, but that's already been documented elsewhere.
I think you are confusing operations which are independent
of the data model (e.g., lock, checkpoint, rollback, validate,
commit) with data-model-specific operations that should be
defined in an individual schema (add_bgp_neighbor, add_vlan_to_port).
Refer to netconf-00, sec 3.2 to see how the latter type of
operation is supported. BTW, this is the type of high-level
operation for which WSDL can be useful.
>Keith Allen
>SBC Labs
>9505 Arboretum Blvd.
>Austin, TX 78759
>(512) 372-5741
>keith_allen@labs.sbc.com
Andy
>
>
>
>> -----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/>