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?
Regards, /gww
> -----Original Message-----
> From: Andy Bierman [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/>