RE: Thoughts on NetConf Requirements

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

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?

-Andrew

Andrew Hunkins
+1 (612) 204-3605
ahunkins@unimax.com



> -----Original Message-----
> From: David T. Perkins [mailto:dperkins@dsperkins.com]
> Sent: Tuesday, June 03, 2003 4:29 PM
> To: Kevin C Miller; netconf@ops.ietf.org
> Subject: Re: Thoughts on NetConf Requirements
> 
> 
> HI,
> 
> This NETCONF effort is multi-dimensional, and both simple and complex
> at the same time. Yes, one of the primary issues is being able to
> send and retrieve configuration; but it also must retrieve status,
> statistics, and asynchronous notifications of events and trace output.
>    
> And yes, to do simple things it should be simple, but to do "complete"
> management, it should also be complete, secure, and do this using
> the appropriate amount of managed system and network resources.
> Plus, it's got to be interoperable. And there is this silly problem
> of an installed base.
> 
> In an idealized world, the XML interface is just a portal to 
> a transport
> mapping, which as a user to the XML interface, the details of the
> transport are not really relevant to accomplishing a task. Of course,
> you are still concerned about security and cost to use the transport.
> Given this, you could send the XML as text, encode it in binary,
> put it directly on top of TCP, or on SSH, or on TLS. You could use
> one transport connection per channel, or use BEEP to provide
> support of multiple channels over one transport connection.
> You might be able to get by with a single channel (if everything
> works OK). But you might need a channel to abort a request or
> its response. And another channel to receive the events and/or
> tracing that starts to happen because of the command that you
> sent on the operations channel.
> 
> I hope the above has provided a few insights into why the
> NETCONF is not limited to just sending XML text over an
> unspecified transport layer with support for just a single
> channel.
> 
> Regards,
> /david t. perkins
> 
> 
> --
> 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/>