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

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

Andrew,

I agree that we should be capable of expressing both types of policies.  I
was suggesting that the example was too complex and could be simplified.  I
would like to get away from any example which says "Somebody gets service X
and now I am going to configure that into all my routers."  We should either
focus on examples of policies that configure routers or broaden examples
that configure routers to explain how someone could use it to get a service.

regards,

-Walter

> -----Original Message-----
> From: Andrew Smith [mailto:andrew@extremenetworks.com]
> Sent: Monday, October 18, 1999 3:01 PM
> To: 'Weiss, Walter'; mumble@ops.ietf.org
> Subject: RE: draft-ops-mumble-conf_management-02.txt
> 
> 
> 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
> > 
>