Annotation of /trunk/chap_policy.tex

Revision 1 - (view) (download) (as text)

1 :	mark	1
2 :			\chapter{Policy, Autonomy and Voluntary Cooperation}
3 :
4 :			This chapter is based on \cite{burgessdsom2005}
5 :
6 :
7 :
8 :			\section{The policy timescale}
9 :
10 :			A policy is a declaration, summarizing a number of resolutions made by
11 :			an agent. The function of a policy is to gather the results of a
12 :			complex decision-making process into a single convenient summary of
13 :			intent. A policy can be thought of as defining what is admissable or
14 :			acceptable. It can therefore be regarded as a {\em constraint} on the
15 :			domain of possible intentions for the agent.
16 :
17 :			If we say `policy' rather than `decision', it implies more than a
18 :			passing determination, or spur-of-the-moment choice. A policy is
19 :			expected to have a more lasting value. Perhaps it enshrines a guiding
20 :			principle for the individual, which will preside over many situations
21 :			and encounters. Just as rules and laws are the cached results of
22 :			judicial process, policy is a way of avoiding the need to arrive at a
23 :			similar decision in each new case. Thus, by assumption policy is
24 :			considered to be {\em slowly changing}.
25 :
26 :			Using promise theory, we can develop a notion of distributed
27 :			or entangled policy for multiple agents working together, using only
28 :			the pure policies of individual agents.
29 :			A policy is merely a superposition of possible promises.
30 :
31 :			So policy can be tailored to the different roles and circumstances in
32 :			a division of labour, with agents at possibly different times and
33 :			locations in a collaborative network.
34 :
35 :			This, however, leads to the possibility of contradiction: part of
36 :			policy is about how agents interact, and once agents can interact, two
37 :			agents can interact together in a way that is acceptable to them, but
38 :			not to a third party. This problem of {\em policy conflict} is the
39 :			pernicious problem that has serious problems in an obligation
40 :			picture, but which we shall resolve simply in the promise picture.
41 :
42 :			\section{Policy versus decision theory}
43 :
44 :			Policy should not be confused with optimization or rational decision
45 :			theory. In decision theory, or game theory, decisions are made
46 :			rationally by maximizing a utility function\cite{morgenstern1}. A
47 :			policy decision is distinct from an optimization because it is made by
48 :			agents, who can decide to behave either rationally or irrationally,
49 :			and might not have decided on an appropriate utility function.
50 :
51 :			In optimization one tries to {\em compute} the best course of action,
52 :			using a pre-decided criterion or model. The result of the optimization
53 :			is a rational computation, with (hopefully) only one answer---the
54 :			element of decision has been removed by a standardized
55 :			procedure. There are several meta-level policy decisions surrounding this
56 :			however: the decisions about whether to use optimization or not, which
57 :			model is correct, and which answer (if there are several) to use, are
58 :			matters for policy to decide. policy can therefore be informed and
59 :			guided by optimization, but in the final analysis the choice is {\em
60 :			ad hoc}.
61 :
62 :
63 :			The construction of a distributed policy from individual agent
64 :			promises is precise and can be understood graphically. Such an atomic
65 :			reconstruction provides a framework in which to reason about the
66 :			distributed effect of policy. Immediate applications include resolving
67 :			the problem of policy conflicts in autonomous computer networks.
68 :
69 :			\section{Rule and law, Norms and requirements}
70 :
71 :			One of the problems in discussing policy based management of
72 :			distributed systems\cite{sloman3,lupu1} is the assumption that all
73 :			agents will follow a consistent set of rules. For this to be true, we
74 :			need either an external authority to impose a consistent policy from a
75 :			bird's eye view, or a number of independent agents to collaborate in a
76 :			way that settles on a `consistent' picture autonomously.
77 :
78 :			Political autonomy is the key problem that one has to deal with in ad
79 :			hoc / peer-to-peer networks, and in pervasive computing. When the
80 :			power to decide policy is delegated to individuals, orders cannot be
81 :			issued from a governing entity: consistency and concensus must arise
82 :			purely by {\em voluntary cooperation}. There is no current model for
83 :			discussing systems in this situation.
84 :
85 :			In this chapter outline a theory for the latter, and in doing so provides
86 :			a way to achieve the former. The details of this theory require
87 :			a far more extensive and technical discussion than may be presented in
88 :			this short contribution; details must follow elsewhere.
89 :
90 :			It has been clear to many authors that the way to secure a clear and
91 :			consistent picture of policy, in complex environments, is through the
92 :			use of formal methods. But what formalism do we have to express the
93 :			necessary issues? Previous attempts to discuss the consistency of
94 :			distributed policy have achieved varying degrees of success, but have
95 :			ultimately fallen short of being useful tools except in rather limited
96 :			arenas. For example:
97 :
98 :			\begin{itemize}
99 :			\item Modal logics: these require one to formulate
100 :			hypotheses that can be checked as true/false propositions. This is not
101 :			the way most planners or designers work.
102 :
103 :			It is a stress-testing procedure or a destructive testing method.
104 :
105 :			\item The $\pi$-calculus: has attractive features but focuses on issues
106 :			that are too low-level for management. It describes systems in terms
107 :			of states and transitions rather than policies (constraints about
108 :			states)\cite{parrow1}.
109 :
110 :			\item Implementations like IPSec\cite{fuwu1,lisa0119},
111 :			Ponder\cite{ponder} etc. these do not take
112 :			explicitly into account the autonomy of agents and thus while these implement
113 :			policies well enough, they are difficult to submit to analysis.
114 :			\end{itemize}
115 :
116 :			In each of the latter examples, one tends to fight two separate battles: the
117 :			battle for an optimal mode of expression and the battle for an
118 :			intuitive interface to an existing system.
119 :			For example, consider a set of files and directories, which we want to
120 :			have certain permissions. One has a notion of policy as a
121 :			specification of the permission attributes of these files. Policy suggests
122 :			that we should group items by their attributes. The existing system
123 :			has its own idea of grouping structures: directories.
124 :			A simple example of this is the following:
125 :			\small
126 :			\begin{alltt}
127 :			ACL1: ACL2:
128 :			1. READ-WRITE /directory 1. READ-ONLY /directory/file
129 :			2. READ-ONLY /directory/file 2. READ-WRITE /directory
130 :			\end{alltt}
131 :			\normalsize
132 :			Without clear semantics (e.g. first rule wins) there is now an
133 :			ordering ambiguity. The two rules overlap in the specifically named
134 :			``file'', because we have used a description based on overriding the
135 :			collection of objects implicitly in ``directory''.
136 :
137 :			In a real system, a directory grouping is the simplest way to refer to
138 :			this collection of objects. However, this is not the correct
139 :			classification of the attributes: there is a conflict of interest.
140 :			How can we solve this kind of problem?
141 :
142 :			In the theory of system maintenance\cite{burgesstheory}, one builds up
143 :			consistent and stable structures by imposing independent, atomic
144 :			operations, satisfying certain constraints\cite{lisa0163,burgessC11}.
145 :			By making the building blocks primitive and having special properties,
146 :			we ensure consistency. One would like a similar construction for all
147 :			kinds of policy in human-computer management, so that stable
148 :			relationships between different activities can be constructed without
149 :			excessive ambiguity or analytical effort. This paper justifies such a
150 :			formalism in a form that can be approached through a number of
151 :			simplifications. It can be applied to network or host configuration,
152 :			and it is proposed as a unifying paradigm for autonomous management with
153 :			cfengine\cite{burgessC1}.
154 :
155 :
156 :			\section{Policy with autonomy}
157 :
158 :			By a policy we mean the ability to assert arbitrary constraints of the
159 :			behaviour of objects and agents in a system. The most general kind of
160 :			system one can construct is a collection of objects, each with its own
161 :			attributes, and each with its own policy. A policy can also be quite
162 :			general: e.g.
163 :			policy about behaviour,
164 :			policy about configuration, or
165 :			policy about interactions with others.
166 :
167 :			In a network of {\em autonomous} systems, an agent is only concerned
168 :			with assertions about its own policy; no external agent can tell
169 :			it what to do, without its consent. This is the crucial difference
170 :			between autonomy and centralized management, and it will be the
171 :			starting point here (imagine privately owned devices wandering
172 :			around a shopping mall).
173 :
174 :			\begin{assume}[Autonomy]
175 :			No agent can force any other agent to accept or transmit
176 :			information, alter its state, or otherwise change its behaviour.
177 :			\end{assume}
178 :			(An attempt by one agent to change the state of another might be
179 :			regarded as a definition of an attack.)
180 :			This scenario is both easier and harder to analyze than the
181 :			conventional assumption of a system wide policy. It is easier, because
182 :			it removes many possible causes of conflict and inconsistency. It is
183 :			harder because one must then put back all of that complexity, by hand,
184 :			to show how such individual agents can form collaborative structures,
185 :			free of conflict.
186 :
187 :			The strategy in this paper is to decompose a system into its
188 :			autonomous pieces and to describe the interactions fully, so that
189 :			inconsistencies become explicit. In this way, we discover the emergent
190 :			policy in the swarm of autonomous agents.
191 :

Administrator	ViewVC Help
Powered by ViewVC 1.0.3