RE: Separation of protocol and information model

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

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.

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