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

[Andrew Smith <andrew@extremenetworks.com>]

Walter,

I'm slightly confused by your first point: are you suggesting that this
"mumble" effort not include definition of protocols for carrying policies
for determining "access to the service" and focus only on policies for
"definition of the service or desired behavior of the service"? I think that
would be a mistake - I think we need to do both. Or maybe you are just
talking about simplifying the example in the "Motivation" section of the
document. Please clarify.

Andrew

****************************************************************
Andrew Smith                              tel: +1 (408) 579-2821
Extreme Networks                          fax: +1 (408) 579-3000
3585 Monroe St.                   http://www.extremenetworks.com
Santa Clara CA 95051-1450        em:  andrew@extremenetworks.com
****************************************************************



> -----Original Message-----
> From: Weiss, Walter [mailto:WWeiss@lucentctc.com]
> Sent: Monday, October 18, 1999 11:40 AM
> To: 'lsanchez@bbn.com'; mumble@ops.ietf.org
> Subject: RE: draft-ops-mumble-conf_management-02.txt
> 
> 
> 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
>