RE: Thoughts on NetConf Requirements

["Hunkins, Andrew" <ahunkins@unimax.com>]

Well as xmlconf says, the content layer is not part of the spec.  So
excluding that, I think the remaining layers represent the device access
layer.

I didn't want to respond directly to xmlconf until I understood the
requirements of the group better (as this thread was pursuing) but since
you raise it up, let me ask a few questions re xmlconf:

1. The document says multiple requester/consumers are communicating with
the device/server.  Terms include: "CLI", "native interface", "SNMP",
"expect scripts", "human users" and xmlconf clients themselves.
Assuming xmlconf is there, then shouldn't all these non-xmlconf clients
be built on top of xmlconf?  (If so, can we eliminate these others and
just declare that all clients must use xmlconf?)  If not, why?  If the
answer is to be backward compatible, then the vendor is forced to
implement the xmlconf flavor of locks across multiple existing UIs and
APIs.  In all practicality, they will not.  And if they do, the best
approach is to build them on top of xmlconf anyway which brings us back
to this first question.

2. The document says xmlconf is "only concerned with information
required to get the system software into its desired running state".  Do
you really mean that?  Just to load entire configuration sets?  It seems
like the netconf discussion includes a lot of desire to manipulate
individual elements, day-to-day transactions and "complete management".
Any particular reason to exclude user database information, etc.?
xmlconf seems awfully rich (a good thing!) just to load up config files.
But if you really just want to focus on this, then my first question
probably goes away.

3. My definition of the management & sync layer is a *programmable*
layer that is tuned to fit the business rules of a particular site.  It
includes complex scheduling procedures and semantic relations across
multiple devices of disparate purposes.  xmlconf has none of this.  It
sounds like these are clearly placed in the hands of an xmlconf client
application.  Am I missing something?

4. My definition of logic and validation layer, as a *layer*, means that
you can tap into it independently.  This is much more than just passing
through failures from the underlying device.  A true logic and
validation layer allows other layers, especially scripts and UIs, to
access the validation and enforce it long before it gets to the device.
It allows UIs to offer "correct choices" based on the exact
configuration for that exact device.  This is much different than an
implied validation by returning blind failures from the device.  Again,
please let me know if I'm interpreting the scope of xmlconf incorrectly.

I feel like up coming down really hard.  I don't mean to be, I just want
to get clear on the boundaries.  I want xmlconf to be the new super
device layer of the future!  But I'm concerned that if we draw the
circles too big, we'll never pull it off.

-Andrew





> -----Original Message-----
> From: Andy Bierman [mailto:abierman@cisco.com]
> Sent: Wednesday, June 11, 2003 7:08 PM
> To: Hunkins, Andrew
> Cc: netconf@ops.ietf.org
> Subject: RE: Thoughts on NetConf Requirements
> 
> 
> At 12:16 PM 6/11/2003, Hunkins, Andrew wrote:
> >All,
> >
> >Some clarification on software architecture would help me 
> understand the
> >current discussion better.  Maybe it would help others too.
> >
> >At what layer is NetConf supposed to support?  I like the following
> >stack:
> >
> >DATA ACCESS LAYER: Common objects to interface with device 
> databases of
> >configuration settings.
> >
> >DEVICE LOGIC & VALIDATION LAYER: Device Logic and validation enforces
> >correct propagation/transformation of data to all devices.  Allows
> >multiple "smart" UIs.
> >
> >MANAGEMENT & SYNCHRONIZATION LAYER: Management functions - create,
> >delete, modify, bulk changes, etc. - along with scheduling & 
> sync rules.
> >Allows intelligent integration with other management framework areas:
> >fault, accounting, performance & security.
> >
> >OPEN API LAYER: API Layer gives common access to management & sync
> >layer.  Integrates with other management applications who 
> are consumers
> >or change requesters.
> >
> >USER INTERFACE LAYER: Multiple UI's support multiple users with
> >different provisioning needs. Look and feel is individually 
> controlled
> >to provide differentiation and branding flexibility.
> >
> >
> >I thought NetConf was providing/describing the Data Access 
> Layer.  The
> >underlying protocols to support it could be a variety of 
> choices for a
> >variety of reasons.
> >
> >But I've also heard some interest in the "higher level" layers.
> >
> >Is this view of system management application layers useful? 
>  If so, I
> >think it is a real problem to try to combine the layers.  It 
> becomes too
> >complex and you can't plug different layers together to achieve
> >interoperability.
> >
> >Thoughts?
> 
> I think netconf focuses mostly on what you call the 
> management and synchronization layer.  The device
> implicitly supplies the device logic and validation 
> layer and the data access layer in order to fulfill
> the protocol operation requests at the management layer.
> 
> I'm not sure I like this stack too much.  The first two
> layers are never really directly exposed in network devices.
> It's not clear to me that the open API layer is independent
> of the management layer.  
> 
> How do all these layers relate to the layering specified
> in the xmlconf draft:
> 
>           Layer                      Example
>          +-------------+      +-----------------------------+
>          |   Content   |      |     Configuration data      |
>          +-------------+      +-----------------------------+
>                 |                           |
>          +-------------+      +-----------------------------+
>          | Operations  |      | <get-config>, <edit-config> |
>          +-------------+      +-----------------------------+
>                 |                           |
>          +-------------+      +-----------------------------+
>          |     RPC     |      |    <rpc>, <rpc-reply>       |
>          +-------------+      +-----------------------------+
>                 |                           |
>          +-------------+      +-----------------------------+
>          |  Transport  |      |   BEEP, SSH, SSL, Console   |
>          +-------------+      +-----------------------------+
> 
> It seems to me that these layers are the focus of netconf,
> except that actual data models for standard configuration
> data are outside the scope of the WG.
> 
> 
> >-Andrew
> >
> >Andrew Hunkins
> >+1 (612) 204-3605
> >ahunkins@unimax.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/>