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

[Jon Saperia <saperia@mediaone.net>]

"Weiss, Walter" wrote:
> 
> 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.

I can see your point.  What we were attempting to do was capture to some
degree how many people think of the problem which is to include both
points - especially in this intro section.  I would have to agree that
the requirment is to be able to specify configurations that have
variable scope.  What I mean by that is that some configuration
operations could set up the DSCP processing/recognition as you suggest
and a separate one the 'action' to take in certain circumstances.  In
either case we have to be able to do both types I think.
> 
> >
> >     - 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.

Yes, roll back in this context should not be part of the protocol.
Sometimes people mix transaction integrity/roll back with protocol
reliability.  The protocol (no matter which one(s) you like) should not
do the roll back.
> 
> >     - 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

Sadly, roles is an over used term.  Roles (before policy was ever
discussed) were the types of fucntions people did in network centers. 
For example, there might be a noc person who watches the display
information and calls for additional help when they can not eaisly solve
the problem.  Another role might be the backbone engineer who would have
broader access to configuration operations.  In fact they might access
systems from home in the case of emergecy.  In this case we me role in
the more conventional use.  Luis, perhaps we can clarify that.

> 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.
> 
Policies are configuration information and not all policies will be
applied by a person to all items filling a certain 'role' using role in
the policy context.  In the end some people have privaleges that others
do not.  The configuration management system we propose must deal with
the fact that network wide configuration information (what people call
policies) can not be applied blindly by a device to all instances of
contained objects which match a particular set of roles.
/jon