RE: Separation of protocol and information model

[Andy Bierman <abierman@cisco.com>]

At 12:26 PM 9/3/2003, Glenn Waters wrote:

>It has taken a me while to understand but I think the point that Keith and Weijing are making is that the list of configs (running, candidate, etc.) is configurable and in fact configuration commands are used to define the set of configs. Since the list is configurable that makes it a part of the data model and hence it is not appropriate as a protocol capability.
>
>Is that what is trying to be said? 

I don't know if that's what they are saying, but the list of
configuration database types is not configurable by the user.  
It is defined by the vendor when the product is designed.

All devices must have a set of current operational configuration
values (running config).  Some devices require that configuration
changes are placed in a scratchpad (candidate config) configuration
and then applied all at once to the running config.  Some devices
do not overwrite the configuration for the next reboot (startup config)
automatically, but instead require an explicit action from the user
to copy the contents of the running config to the startup config.

It is possible that other operational models exist, and we should
discuss whether or not netconf should support them.  For example,
some devices retrieve their startup config from the network
instead of storing it locally.  Some devices can associate
different startup configs with different SW images.  There
are probably more variants not yet supported by the protocol.
Note that the list of configuration types can be extended
without rewriting the protocol.


>Regards, /gww 

Andy



>> -----Original Message----- 
>> From: Andy Bierman [<mailto:abierman@cisco.com>mailto:abierman@cisco.com] 
>> Sent: Wednesday, September 03, 2003 15:01 
>> To: Chen, Weijing 
>> Cc: netconf@ops.ietf.org 
>> Subject: RE: Separation of protocol and information model 
>> 
>> At 11:50 AM 9/3/2003, Chen, Weijing wrote: 
>> >> These are basic facts about the operational model, not assumptions 
>> >> about the information model.  Only the running config is part of 
>> >> the base protocol.  All devices have a running config.  The other 
>> >> config types are added based on capabilities. 
>> >> 
>> >Whether it is running config, candidate config, startup config, they all 
>> are 
>> >part of device configuration setup.  It is device configuration-related. 
>> >Other than router, there are a lot of IP-capable devices: DSLAM, ATM 
>> switch, 
>> >DWDM, NG SONET, FTTP, Voice over X gateway, B-RAS, etc. does not have 
>> >concept of separate configuration.  They have one configuration.   The 
>> world 
>> >of router is larger, but not THE WORLD yet. 
>> 
>> As I have already explained, these devices would have just 
>> a running config and no candidate or startup config.  Only 
>> the running config is mandatory.  The other config types 
>> are only present if the device supports them. 
>> 
>> > 
>> > 
>> >We surely see the function of capabilities in WG text to be able to 
>> describe 
>> >the permutation of device configuration option. But then where is the 
>> line 
>> >in the sand?  Why can't I use capabilities to describe my interface 
>> >configuration option?  Isn't that a part of the information model?  If 
>> the 
>> >configuration information is not information model, then what is the 
>> >information model? 
>> 
>> The capabilities describe features that are independent 
>> of the device config details.  Whether a device supports 
>> checkpoint and rollback of config data is totally independent 
>> of what its interface configuration looks like. 
>> 
>> The high level issue is how much functionality should the 
>> standard protocol provide.  You want to move lots of 
>> generic functionality (i.e., the protocol operations) 
>> to the vendor-specific data models.  I totally agree 
>> that this provides maximum flexibility, but the purpose 
>> of a standard is interoperability.  What use is the 
>> standard to an application developer if the protocol 
>> operations are different on every device? 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> >-- 
>> > 
>> >Weijing Chen 
>> 
>> 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/>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/>