RE: Separation of protocol and information model

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

Glenn,

I don't think your question got answered.  The current WG draft defines the
notion of a "target," such as running, backup, candidate, etc.  Weijing and
I feel this is both unnecessary and wrong, and that these notions should be
part of a device's information model.  I gave these two examples in the
email that announced our I-D.  The first is from the WG text, the second is
just an alternative created by me, it follows the theme of our approach but
a few details are different.  I wanted to just change one thing from the WG
draft example:


        <get-config>
           <source>
             <running/>
           </source>
           <config xmlns="http://example.com/schema/1.2/config";>
             <users/>
           </config>
           <format>xml</format>
         </get-config>


        <get-config>
           <config xmlns="http://example.com/schema/1.2/config";>
             <running>
               <users/>
             </running>
           </config>
           <format>xml</format>
         </get-config>

The two messages really convey the same request.  There are, however, some
important differences.  The most obvious is that in the first example the
<running> and <users> elements are separate, but in the second the <users>
element is contained in the <running> element.  Also, in the first example
<running> is part of the message's standard name space, and in the second it
is part of the device's name space.  That is, in the first it is part of the
NETCONF standard message definition and in the second it is part of the XML
"MIB" defined by the device supplier (in this case, example.com).

The first point is an important one and has not been discussed yet.  The
fact that <running> and <users> are separate means that a management system
implementer cannot tell from a device's XML schema what is part of the
running configuration and what is part of the backup or other
configurations.  Does it make sense to retrieve <users> from the target
<backup>?  You'll have to resort to descriptive English text supplied by the
device manufacturer.  In the second example, the device's XML schema must
clearly state that <users> is an element contained by <running> (or
<backup>) or the message won't validate.  So, you can check it with
software.  (Granted, most people would probably realize that <users> should
not be part of a backup configuration but other elements may not be so
clear.  In general a good interface design would make this clear in a
machine-readable form and not rely on human intervention.)

The second point means that if a device implementer does not want to have a
<running> element in their schema, they need not.  A <running> element could
become part of a standard schema, but a device could always support the
standard protocol without supporting the standard schema.  So, a device
could have <running>, <backup>, <every-other-Thursday>, whatever.

Now, the current WG draft does enable a device to only support <running> as
a target, or to have other targets, so the issue is not really whether the
list of configurations is modifiable.

I think the first issue is important, though.

Keith Allen
SBC Labs
9505 Arboretum Blvd.
Austin, TX 78759
(512) 372-5741
keith_allen@labs.sbc.com
 

-----Original Message-----
From: Glenn Waters [mailto:gww@nortelnetworks.com] 
Sent: Wednesday, September 03, 2003 2:27 PM
To: Andy Bierman; Chen, Weijing
Cc: netconf@ops.ietf.org
Subject: RE: Separation of protocol and information model

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

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