RE: draft-ops-mumble-conf_management-02.txt

["Weiss, Walter" <WWeiss@lucentctc.com>]

Luis,

All in all, a very good document.  A few comments follow.

> 
> 1. Introduction
> 
> 1.1 Motivation, Scope and Goals of this document
> 
>     Over the past months, a number of IETF working groups have
>     introduced new technologies which offer integrated and
>     differentiated services.  To support these new technologies,
>     working group members found that they had new requirements for
>     configuration of these technologies. One of these new requirements
>     was for the provisioning (configuration) of behavior at the
>     network level.
> 
>     An example of this type of configuration would be instructing all
>     routers in a network to provide 'gold' service to a particular set
>     of customers. Depending on the specific network equipment and
>     definition of 'gold' service, this configuration request might
>     translate to different configuration parameters on different
>     vendors equipment and many individual configuration commands at
>     the router. This higher level of configuration management has come
>     to commonly be known as policy based management.
> 
I believe Fred made a subtle but inspired point at the face-to-face in
describing an example policy of a service.  He in fact defined two policies.
One policy described the service characteristics the router should apply
when seeing a particular DSCP.  The other policy described the access to the
service by defining the criteria for using the DSCP in a packet.  While it
is possible to construct policies to do both, it may easier for folks to
relate to this example if we remove references to the access to the service
and focus on the definition of the service or desired behavior of the
service.

> 
>     - provide facilities (with host and user-based authentication
>       granularity) to help in tracing back configuration changes,
> 
If indeed you want to propose roll-back mechanisms, I would suggest that you
elaborate a little more, although I agree with Andrew that I am not sure
this is a function of the protocol.

>     - allow for the configuration of redundant components (both as
>       network elements and configuration application platforms).  In
>       addition, the system should support the concept of individuals
>       (humans) in different roles with different access privileges,
> 
First, I think there are two separate requirements here.  I am concerned
about the second requirement because it is not clear what you mean by humans
or roles.  I thought we were using the term roles to mean a grouping of
interfaces or devices that a policy can apply to.  Also are you applying the
concept of access privileges to the policies or the elements being
configured?  If you are going to apply access privileges to configuration
elements, then I think you are also suggesting that this protocol be used
for purposes other than policy (direct configuration of routers in the
absence of policies?).  If this indeed the case, it should be stated as an
additional requirement.

regards,

-Walter