RE: Goals for netconf - moving towards the charter description

["Faye Ly" <faye@pedestalnetworks.com>]

Margaret,

I think Dan is right that current description of the 'network
configuration' is not very well defined.  It does imply unified
semantics across different types of devices.  But again this may be very
clear once the charter and scope are defined. 

The way the current document describes the usage of monitoring and fault
TCP connections are confusing.  I don't fully understand their purpose?
But I need to go back and re-read the document now that you have
clarified a lot of my misunderstandings.

Thanks.

-faye 



-----Original Message-----
From: Margaret Wasserman [mailto:mrw@windriver.com] 
Sent: Thursday, March 27, 2003 11:59 AM
To: Romascanu, Dan (Dan)
Cc: Faye Ly; xmlconf@ops.ietf.org
Subject: RE: Goals for netconf - moving towards the charter description



>There still (at least) two issues open, and which are of some concern
for me:
>
>- Your use of 'network configuration' seems to imply a transaction
model, 
>which is one of the big missing pieces in SNMP. However, many people
have 
>something else in mind when they hear or say 'network configuration'
which 
>is the capability of performing configuration operations on a network 
>(like configuring routing protocols, QoS parameters) while dealing with

>different types of devices

Right.  The ability to configure "networks" (or parts of networks) does
require a set of "primitives" on the device to allow for external
transaction
processing (i.e. lock, set, commit, rollback, etc.).  The XMLCONF
protocol
includes these primitives.

At the application level, the user may be dealing with higher-level
concepts -- changing a network prefix, modifying configuration
templates,
provisioning a full communication channel, etc.  But, it is the current
assumption of the XMLCONF protocol that the application/NMS side will
need to determine what this means for individual devices, and will use
the primitives provided by XMLCONF to achieve the network-wide changes
in an "atomic" (as much as anything between multiple devices can be
atomic) fashion.

The external exposure of these transaction primitives allow this type
of network-wide configuration, and this is an important advantage that
XMLCONF offers over SNMP.

>- Many operational models include performing configuration operations 
>based on faults management (e.g. alarms) or performance monitoring 
>management information. It is not clear if XMLConf will allow for such
a 
>model, especially as the discussion right now avoids ('by design')
dealing 
>with the information and data models behind XMLConf.

I don't understand what you mean well enough to know if XMLCONF will
support
this or not...  Are you talking about boxes doing automatic
configuration
changes based on triggers (changing configuration under network load,
or at certain times of the day, etc?).  If so, XMLCONF might be one
useful part of a system to do this (allowing you to set-up the different
named configurations, set trigger values, etc.), but XMLCONF does not,
inherently provide this type of support.

Margaret




--
to unsubscribe send a message to xmlconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/xmlconf/>