Polterm Minutes. Friday, Nov. 12, Washington DC IETF Submitted by Ed Ellesson Meeting chaired by Bert Wijnen Policy Terminology BOF Agenda and Intro: Goal: described by Bert on the chart he presented: We want a common set of terms that we can all agree on, used across four working groups involved in policy-based network management: policy, rap, diffserv, ipsp (to be wg soon). This is also for the benefit of the IESG, to create a common terminology for evaluating policy-related documents that come forward for review. A partial list of documents was presented, that represents the work coming out of these working groups. The list of documents needs to be/will be completed and posted. The intended output from this BOF should be a document of common terms that can be used by the various WGs. Need to develop a proper set of abstractions. Mark and Fran have that continuing assignment, since the draft is not perfect yet. Brian pointed out that, in DiffServ, their terminology document is a living document, and not intended to be an RFC. It may go through many revisions. The important thing is that we not have different groups using one term differently, or using multiple terms to refer to the same thing. Configuration Management: Bert quickly reviewed the results of the cnfmgt bof the day before: need to align high level policy, and abstractions by level down to device. Fran's Presentation: The objective is for the following draft, authored by Fran and Mark, to eventually become an fyi rfc: http://www.ietf.org/internet-drafts/draft-ops-mumble-terminology-00.txt Caveats: Note that the functional levels of abstraction for policy are described in another draft: http://www.ietf.org/internet-drafts/draft-ietf-policy-framework-00.txt Since the work on that document is not yet complete, the terminology draft must move forward in parallel with that doc. In fact, there is some functionality placement work in the terminology draft that needs to be reconciled with, and fed into, the policy framework draft. Therefore, think of this work as a strawman. Also, it should be noted that Mark and Fran did not necessarily see eye-to-eye on the definitions of all the terms in the document, which reflects the confusion in the larger set of working groups. New approach suggested: Fran suggests that instead of box level descriptions of functionality, we document the individual functions that need to be provided, and the relationship among these functions, regardless of how they are packaged, or what box they go in. That is, the approach would be something like this: out of requirements/framework discussions: start by - define some # of functional blocks - descriptions of what they do - relationships among them reasonably descriptive names for these blocks... just pick some needs to be done in conjunction with policy framework/architecture/requirements So, Fran offers the following strawman: This is not meant to represent the physical components of a policy-based network management system, but rather is meant to represent the functions performed at some set of points in the system The idea is that, regardless of where implemented in the system, the relationship among functional blocks remains unchanged (true?) Relationships dictate protocols and data models used in different parts of the system (or is it the other way around?) In consideration of policy abstraction levels, Fran presented the following: policy repository policy/report repository | ^ V | policy distribution policy/report retrieval | ^ V | policy translation policy/report translation | ^ v | policy decision policy decision | ^ V | policy formatting policy/report formatting | ^ V | policy enforcement policy enforcement Each of the above levels corresponds to the following functions: Policy repository - policy storage - policy retrieval Report repository - policy report storage - report/feedback retrieval = e.g., accounting applications Policy distribution - policy is about consistent configuration across the network - need to move policy between centrral repository and other parts of the system Policy report retrieval - policy mgmt requires feedback and reporting - retrieval of policy feedback Policy translation - translation of policy rules from one data model to another (i.e. from the business level, or high level view, down to the low level device view) Report translation - translation of report/feedback info from one data model to another Policy decision Downward direction: - policy trigger - respond to policy request from network - state and resource validation Upward direction: - incorporate report/feeback info into policy decisions Discussion about where decisions are made, and what kind of decisions: Hugh suggests that the a decision is relative to an event, and that places it in the framework. For example, an outsourcing decision is not done in the enforcement device. Shai suggests using different terminology. The definition should be based on where the trigger is. If the trigger is generated internal to the PEP, it is an outsourcing event, since the event triggers the device to go outside itself to get an answer. If the trigger is generated external to the PEP, that is, the PEP gets its configuration in advance from the PDP or above, it is a provisioned operation. Jon Saperia points out that there are multiple levels of translation. Joel Halpern: There will be multiple kinds of decisions and translations, and we don't yet know what all the levels and protocols will be. Rob Shirley, from GTE/BBN: When doing management of a large system, the administrator doesn't necessarily know what is out in the network, so that the global language made to express policy, needs to be translated to other languages or information for the individual components in the network. This is evident from how policy is used to manage security at various levels in a network. Translation does not equal decision. You have meta-rules that govern how you translate. Reference security research in this area. Bob Moore: A continuum of decisions are being made. At one end of the continuum, a decision is being made about whether or not a condition is being satisfied. At the other end, a decision is being made every time code is executed anywhere. Shai says that he agrees that both the terms decision and translation are overloaded, in opposite directions (decision implies more than policy decisions, translation implies no decisions at all are being made). Shai says the same terms should be used for both outsourcing and provisioning, and we should come up with some new ones. Jeff Wheeler says that there were three layers created for the original framework document draft: Policy Services (at the business level), Policy Rule (composed of condition and action), and Policy Mechanisms (marking, queuing, etc.) Juergen: Policy "expansion" occurs, as you add more detail. There are different kinds of decisions being made depending on whether it is an outsourcing or provisioning scenario. Shai: there are three levels: enforcement (packet-level), repository, and the "advisor" to the PEP (similar to a professor assigned as an advisor to a grad student). We need to define interfaces. Rob disagrees: Wants agreement on what processes, mechanisms, and translations need to be performed. The "advisor" function could be involved in all three: decisions, translations and formatting. Tony Hain: Believes we should concentrate on what the terms mean, and some ordering of the boxes, so you can define the interfaces. Bert: We need to get back to the discussion of terminology. Interfaces belong in the framework discussion. Then we can iterate on the terminology. Lee says that we use the term policy incorrectly. We should use policy at the translation layer and above, and configuration below the translation layer. It is the "Resource Manager" that gets configured. (Anruda Kulatunge disagrees...its "policy" below, as above.) Shai believes that there is no pure translation layer, and that translation is mixed throughout the framework. Also believes that there is no pure order. Bob says we need to have a term to describe a policy server which is 1) a client to the policy repository, and which 2) acts as a COPS Server, or SNMP manager, or a command generator to a CLI device interface. Shai points out that there seems to be convergence on the advisor role, and an enforcement point that sees packets. Rob disagrees...thinks it is too "stovepipe". Whole layers of security policy can be turned off in some real world scenarios, depending on network load or intrusion status. Rob advises that we use the formalized policy calculus presented in the IPSP BOF. Points made by folks from audience that policy is not static (It appears that these points are being made about human initiated changes) so things need to be able to change. There also needs to be a policy resolution function to resolve policies from different sources. Lee reiterates that the way the group has been using the term "policy" to date, policy is not dynamic. Policy is relatively static. That does not mean it cannot change. It means that it changes on a human time scale. That is, when a "policy" changes (the way we are using this term), a human causes it to change. More rapid dynamicity is below the level of policy, where conditions are being evaluated. For example, a policy may be dependent on the state of the network. When the network state changes, the policy does not change, but which conditions evaluate to "true" within a policy may indeed change. (There was some disagreement registered with this use of the term "policy" to restrict the meaning to that which humans change on a human time scale. Apparently, some government/military applications of policy, which are stored in a directory, changes as situational circumstances and awareness change.) Hugh notes that there are different scopes of 'dynamicity', where terms are defined in terms of system time, not human time, and that any system needs to allow changes by humans at any time, and allow timely implementation of those changes. Ed suggests that we need to formally recognize that part of the framework includes a GUI, as a component, and that this component needs to be in the terms that we define here. Shai agrees, and clarifies that the repository may be populated from other sources besides the GUI, but that the GUI definitely exists as part of the overall framework. Dan Romascanu believes that the policy effort here is in trouble because it is trying to solve a problem that is too large in scope. Focus on QOS and get that part done. Only way to make progress. Bert responds that we need to try to make progress at the higher layer, and only constrain the scope if we cannot make that progress. Back to the presentation by Fran: Policy Formatting: - Rules for going from one data format to another - Mechanism-specific - Device-specific? - Vendor-specific? Report Formatting: - Adaptation of report/feedback from one data format to another Management Models: (determined by where the trigger occurs) - Outsourcing - Provisioning Policy Rules: "Policy" needs a qualifier adjective to specify at what layer of abstraction we are dealing with, such as "schema" level, or "pib" level. Policy Requests: Originally this was from the enforcement point to the decision point in the outsourcing model. Could this be morphed to also apply to a request for provisioning? (Rob: wants devices to configure themselves, via a request to the policy advisor.) Roles: This term appears in multiple drafts. Its clear that it is not being used the same way in all cases. (Rob believes that "role-based access control" does not work. A subject plays a role. Permissions are in a many-to-many relationship with "roles". We need to separate permissions from roles.) (Lee: Role is a more overloaded term than policy! Role has been used to describe the concepts known as "subject", "target", "resource manager", "search key", and others.) Perhaps we should leverage work performed in the Object Management Group (OMG) in this area. Related to CORBA. There are URL's we can look at. Shai does not want to give up on how it has been defined before for IETF policy. There are two models: 1) The server knows the "role" of the devices that it serves, and pushes the policy down. 2) The device identifies itself to its server (advisor) about what its "role" is, so that the server can go get the appropriate policy from the repository. SLA: A contract between customer and service provider. Wrap-up: There are some application-specific uses of terms that need to be understood and/or reconciled. Coordination is required with ipsp/ipsec, and diffserv, which has its own terminology document. Six i-d's were listed as being relevant. Randy created the following lists for discussion (archives will also be created): polterm@ops.ietf.org and confmgt@ops.ietf.org We need the design team to get on track, and we need new volunteers. Bert will discuss with the relevant working group chairs to make this happen.