RE: Separation of protocol and information model

[Andy Bierman <abierman@cisco.com>]

At 09:17 AM 9/4/2003, Allen, Keith wrote:



>Andy Bierman wrote:
>> 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).
>
>Actually, since a data model represents the capabilities of a device, I am
>arguing that the lock, checkpoint, rollback, etc. operations are not
>necessarily independent of the device's data model.  Some devices might not
>support all of them.  Some devices might support them at a different
>granularity than you envision.  For example, one device might support
>locking only at the highest level, while another might support more granular
>locking.  If you make the operation a part of the data model, you can
>accommodate both devices with the protocol.  One could allow locking on the
><running>, <backup> and <candidate> elements, for example, while another
>allowed it on the <interface> elements.
>
>Your assumption that all devices support all the functions exactly as you
>envision may not hold true, and designing the protocol based on those
>assumptions could lead to a protocol that is not very useful.

On the contrary, having common functions performed in a common way
is exactly what will make a standard protocol useful.  The netconf
protocol can actually be extended by vendors (although IMO this
should be discouraged, but this is a feature of XML).  The protocol 
contains a set of mandatory (base) functions that every device must 
support, and additional (standard and proprietary) functions 
identified by some capability.


>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 10:14 AM
>> To: Allen, Keith
>> Cc: netconf@ops.ietf.org
>> Subject: 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
>> 
>> 
>/>
>
>--
>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/>