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

[Jon Saperia <saperia@mediaone.net>]

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