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

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

Jon,

The more requirements we clearly define in the document the better.  If we
are not in agreement in the document, we can always debate those in the
context of a broader audience.

-Walter

> -----Original Message-----
> From: Jon Saperia [mailto:saperia@mediaone.net]
> Sent: Thursday, October 21, 1999 2:24 AM
> To: Weiss, Walter
> Cc: 'lsanchez@bbn.com'; mumble@ops.ietf.org; Jon Saperia
> Subject: Re: draft-ops-mumble-conf_management-02.txt
> 
> 
> Walter, Thanks for the comments. Sorry for the delay in responding.  I
> have been working on our ID.  In a short time it will be 
> published which
> may help.  It seems like there is never enough time to get such a
> document in the form one would like, but I think it will help forward
> discussions. You did make a couple of good points in your earlier note
> that are important and may not be adequately addressed in the 
> document.
> 
> "Weiss, Walter" wrote:
> >> > 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.
> > 
> > There are two questions here.  First, mention is made of 
> access control
> > lists without reference to what is being controlled.  I 
> suggested that it
> > might be the policy because it is part of the discussion of 
> the document,
> > but I am pretty sure that is not what you had in mind.  I 
> suspect that you
> > meant the interface to the device as abstracted by the configuration
> > protocol.  However that still leaves the question of what is being
> > controlled, the attributes or the records or certain types 
> of requests.
> > 
> > The second question relates more to the phrasing of the 
> requirement.  It is
> > not clear to me how ACLs on attributes make sense if it is 
> policies that are
> > the actors manipulating the attributes.  Hence, there is an 
> implication in
> > the wording that users and policies can use this 
> configuration protocol
> > (although perhaps through a shared PDP) to manipulate the 
> device.  If this
> > is the case, it should be stated more clearly.
> 
> There is some difference of opinion about how much access control is
> needed and where it makes best sense to apply it.  This is a general
> issue and applies in the case of policy work as well.  I can 
> say what I mean.
> 
> 	1.  Policy information is configuration information to 
> be protected.
> 	2.  Some users (humans) will have different job descriptions and
> skills.  As a result, they may have read access to some 
> policies (or sub
> elements) and/or write access to other policies.  To be clear here, I
> mean of the same policy type. Tbe protocol used to convey this
> information should support all these points --- in my view.
> 	3.  Security interests are best served when the managed 
> element is in
> control of the access control at the user and role level - role here
> means job description or user group in a rough analogy to a unix user
> group - though not exactly.
> 	4.  RE: your point about ACLs on policies.  Policies in 
> a sense are
> even more powerful than individual attributes in that they, like
> computers they can mess a whole lot up fast :-).  For this reason, I
> might only want an 'expert' to manipulate policy information which
> controlls my peering relationships. The same policy type for less
> critical access points in the same device may be subject to 
> the control
> of other less capable humans. Policy information is just an 
> abstraction
> above the attributes you describe.  In the end policy information must
> resolve to, in some cases values for hardware registers.
> 	5.  I think that it is also important for users to be 
> recognized at the
> managed device when using a configuration protocol, not only by role,
> but by the operation they wish to perform and where they want 
> to do it from.
> 
> We may not agree on all these points, but they are how I look 
> at the problem.
> 
> Thanks again for the note.
> /jon
>