RE: Goals for netconf - moving towards the charter description

[Margaret Wasserman <mrw@windriver.com>]

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