From majordomo@raleigh.ibm.com Wed Jan 3 06:59:40 2001 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA18073 for ; Wed, 3 Jan 2001 06:59:39 -0500 (EST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id GAA17430; Wed, 3 Jan 2001 06:49:23 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id GAA27178; Wed, 3 Jan 2001 06:49:22 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA54652; Wed, 3 Jan 2001 06:12:22 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA58736; Wed, 3 Jan 2001 06:12:16 -0500 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id GAA13650 for ; Wed, 3 Jan 2001 06:12:17 -0500 Received: from tungsten.btinternet.com (tungsten.btinternet.com [194.73.73.81]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id GAA32330 for ; Wed, 3 Jan 2001 06:12:13 -0500 Received: from [212.140.202.98] (helo=mss-home-pc.doc.ic.ac.uk) by tungsten.btinternet.com with esmtp (Exim 3.03 #83) id 14Dlq2-0005MG-00 for policy@raleigh.ibm.com; Wed, 03 Jan 2001 11:12:14 +0000 Message-Id: <4.3.2.7.2.20010103110615.00b7ce38@dse-mail.doc.ic.ac.uk> X-Sender: mss@dse-mail.doc.ic.ac.uk X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 03 Jan 2001 11:12:03 +0000 To: policy@raleigh.ibm.com From: Morris Sloman Subject: Policy 2001 Workshop - Register before 9 Jan Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Morris Sloman The deadline for reduce registration fee is Tuesday 9 Jan Policy 2001: Workshop on Policies for Distributed Systems and Networks 29-31 January 2001 Hosted by: HP Laboratories, Bristol, UK Technical Co-sponsored by IEEE ComSoc See: http://www-dse.doc.ic.ac.uk/events/policy-2001/ for programme, hotel and registration details Policy based systems are the subject of a wide range of activities in universities, standardisation bodies and within industry. They have a wide spectrum of applications ranging from quality of service management within networks to security and enterprise modelling. This workshop will provide a forum for discussion and collaboration between researchers, developers and users of policy based systems. It will bring together the various communities working on policy and follows on from the successful informal Policy Workshop held in November 1999 (see http://www-dse.doc.ic.ac.uk/events/policy-99/). Within the Internet community there is considerable interest in Policy Based Networking. A number of companies have announced tools to support the specification and deployment of policies. Much of this work is focused on policies for quality of service management within networks and the Internet Engineering and Distributed Management Task Forces (IETF/DMTF) is actively working on standards related to this area (see http://www-dse.doc.ic.ac.uk/research/policies for links). The Security community has focused on the specification and analysis of access control policy which has evolved into the work on Role-Based Access Control (RBAC). There has been work over a number of years in the academic community on specification and analysis of policies for Distributed Systems mostly concentrating on authorisation policies. Although there are strong similarities in the concepts and techniques used by the different communities there is no commonly accepted terminology or notation for specifying policy. Several research groups are looking at high-level aspects of policy related to Enterprise Modelling. An ISO Open Distributed Processing working group is defining Policy and Role concepts within the Enterprise Viewpoint. Enterprise goals or Service Level Agreements can be considered as high-level abstract policies which must be progressively refined into implementable policies. The workshop programme includes invited speakers and refereed papers covering the above areas. There will be ample time for discussion. __________________________________________________ Professor Morris Sloman Imperial College of Science Technology and Medicine Department of Computing 180 Queen's Gate London SW7 2BZ, U.K. Phone: +44 20 7594 8279 Fax: +44 20 7594 8282 Email: m.sloman@doc.ic.ac.uk WWW: http://www.doc.ic.ac.uk/~mss Policy 2001: Workshop on Policies for Distributed Systems and Networks, HP Laboratories, Bristol, 29-31 Jan. 2001 http://www-dse.doc.ic.ac.uk/Events/policy-2001/ From majordomo@raleigh.ibm.com Mon Jan 8 00:20:56 2001 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA14327 for ; Mon, 8 Jan 2001 00:20:55 -0500 (EST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id AAA23324; Mon, 8 Jan 2001 00:11:10 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id AAA28984; Mon, 8 Jan 2001 00:11:10 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA37878; Sun, 7 Jan 2001 23:33:50 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA60910; Sun, 7 Jan 2001 23:33:46 -0500 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id XAA42462 for ; Sun, 7 Jan 2001 23:33:50 -0500 Received: from mail5.nc.rr.com (fe5.southeast.rr.com [24.93.67.52]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id XAA21368 for ; Sun, 7 Jan 2001 23:33:48 -0500 Received: from ellesson ([24.25.5.43]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.537.53); Sun, 7 Jan 2001 23:33:42 -0500 Message-Id: <002601c0792c$35ecb0c0$2b051918@nc.rr.com> From: "Ed Ellesson" To: Cc: Subject: Final Minutes of Policy Framework WG, San Diego Date: Sun, 7 Jan 2001 23:33:55 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Ed Ellesson" Content-Transfer-Encoding: 7bit Summary and Minutes Policy Framework Working Group Meeting 49th IETF, San Diego Submitted by Ed Ellesson, January 7, 2001 Charts submitted separately to minutes@ietf.org 1. Summary and Action Items, combined from both wg sessions: 1.1 QDDIM: (QOS DiffServ Device Info Model, or QOS Datapath Device Info Model) -Differences with DiffServ are now resolved -Expect name change to the QDDIM draft to reflect generic qos datapath focus for traffic handling and conditioning (ie. not just diffserv), but qos signaling (control plane) will continue to be out of scope for this document. * Action: Bob Moore -Schedulers/Queues relationship: Expect co-author consensus to be posted on the policy mailing list, in approximately two weeks. * Action: Walter Weiss 1.2 QPIM: (QOS Policy Information Model) * Action: QPIM Authors: -Overlap and linkage with QDDIM: Need added text/terminology to describe how/why policy objects are approached differently in QPIM, than from device level view in QDDIM. -Further clarification may be added to describe distinctions among the following functions: Configuration, policy (operational behavior), and state. -QPIM continues to be device independent, and mechanism independent. Examples are needed that show the abstraction level for QPIM, including policy vs. mechanism. -A new PCIM extensions draft will be written, which describes generic PCIM functions that can be broken out separately from the current QPIM draft (ie. those that are not QOS-specific. The first phase of this was agreed to be done by the current QPIM authors, themselves. -RSVP with diffserv in the same network. Positioning statement needed for this situation. 1.3 ICIM (IPSP Configuration Information Model): -The content of this document is owned by the IPSP working group. -Our liaison with IPSP (Lee Rafalow) will take a look at similarities with QPIM, to determine if there is any reason to recommend further harmonizing any of the functionality there with QDDIM or QPIM approaches, such as in the area of sequenced actions. 1.4 Packet classification work effort proposed: -Small design team will be formed to clearly document the motivations for the differing approaches to packet classification across QDDIM, QPIM and ICIM. This team will clearly express the design goals of each approach. *Action: Volunteers to contact WG chairs -Consideration will be given, to converge or not, the four approaches to packet classification presented by Bob Moore: a) single field generic (filter entry) b) variables/operators/values (qpim) c) single field specific (ipsp's icim) d) multi-field specific (6-tuple) -Consideration will be given to documenting this in the separate, common document, (see above) which defines general purpose mechanisms, or to document why general purpose approaches are not appropriate. These guidelines will be intended to guide further application of our models to other domains. -If multiple approaches continue to exist after this design team effort, mapping the methods, one to the other, will need to be documented. 1.5 Terminology Draft: -Expect document rev in a few weeks, then working group Last Call. * Action: Andrea 1.6 PCLS (Policy Core LDAP Schema): -Expect another rev with recent input from mailing list, and a new security considerations section. *Action: Ryan Moats, Bob Moore and Ed Ellesson. -Expect this document to be ready for last call next month. 1.7 MPLS Policy: -Authors will discuss potential homes for this work with wg chairs, and the appropriate AD's . The Policy Framework wg charter does not cover this. As a general rule, it is expected that further application of the policy model, beyond qos, will be accomplished within technologly-specific working groups, which is where the subject matter experts are for those technical domains. This is similar to the way mibs/pibs are developed. * Action: Joel will help by discussing this with the chairs and/or AD's for MPLS. 1.8 Charter Milestones: The co-chairs will work with Bert on a new set of wg charter-milestones, now that our first document (PCIM) has been approved for advancement to Proposed Standard. * Action: Joel and Ed 2. Detailed Minutes from the Monday, December 11 Session: -The order of the minutes is in the order of the agenda topics. 2.1 Intro/Objectives/Milestones: Joel Halpern: -Welcome. Thanks to the many authors who have worked to get drafts for this meeting. -However, we are WAY behind schedule. -Particular items of note that need to be worked on include: a) Framework b) Requirements c) Use Cases d) Terminology -The QPIM and QDIM work has made some significant progress. Remember: "A key part of demonstrating that this model can provide end-to-end translation of high-level policy specifications to device configurations is to ensure that the information model and schemata are compatible with and can use the information contained in the PIB(s) and MIB(s) being developed in the Differentiated Services WG. To this end, the Policy Framework WG will supply input to the development of the PIBs, and include all applicable PIBs and MIBs in its development considerations for the framework, information model, and schemata." So we need to get QPIM and QDIM aligned with each other and with the diffserv work. QDIM is now much more closely aligned with diffserv than in the past. Cooperation with DiffServ here is a key goal. -Similarly, we need to work with the IPSP folks to align the usage of the model there. We will work to put together a new schedule. We will be reluctant to take on any new work items until the backlog has cleared. And even then we would like to get this working group wrapped up rather than perpetually adding work items. 2.2 Agenda Bash. No changes for now. (see later changes to second day's agenda) 2.3 QDDIM Issues Presentation: Bob Moore -Bob's charts were also presented in the DiffServ working group, just prior to this Policy Framework meeting. Some of the decisions on these issues are DiffServ's to make, since they are the owners of the diffserv conceptual model, mib, and pib, with which we want to be consistent. -The word "device" was added to the title, to reflect the fact that rsvp is no longer included in the initial focus of this document. (It proved to be too hard to reach closure on both diffserv and rsvp at the same time.) -See the charts that Bob presented, for the details of each specific issue. * Issue 1: On whether the QDDIM Scheduler class is to be a subclass of Condition: -It was decided that Scheduler is, indeed, to be a subclass of Condition. * Issue 2: should scheduling disciplines be modeled as associations or as classes? -Walter: It turns out that the DiffServ MIB will not allow one approach, but the conceptual model will support it. The question is: should we align with the mib or the informal conceptual model? -Andrea, Walter, John Strassner and Dave Durham all had opinions on which was a better representation, and the vote among them was split. The decision was to revisit this...see the summary for the resolution. * Issue 3: How should the tail drop and head drop dropping algorithms be represented? -The resolution is that the the DiffServ working group will loosen the language in the conceptual model to allow for the dropper to be represented either before or after the queue, and the MIB will be tightly defined, as it is now, to include a property to describe a dropper as tail drop or head drop. This leaves the policy working group clear to document the model as we are doing it now. * Issue 4: Bob described a taxonomy for the four ways to represent filters, used across multiple documents in our working group. -We will take up this topic for discussion in the Wednesday session, after the ICIM presentation. 2.4 QPIM Issues Presentation: Ron Cohen -QPIM includes PCIM extensions, including those that are QOS-specific (both diffserv and intserv), as well as those that are useful beyond just the QOS discipline. -See Ron's charts for a complete list of the changes from the last draft of the QPIM document and for the generic and qos-specific extensions included there. -Generic Extensions to PCIM include the modeling of variables and values, which allows for the reuse of values, and for specifying value constraints, and for adding new variables and values without changing the syntax. See the charts for other extensions. -Mapping to the DiffServ MIB is supported. -Reuse and "domain-wide" application of QPIM, are the primary drivers for organizing the model the way it is currently. -Missing Pieces: * a model of the "capabilities" functionality in the PIB * an approach for binding roles to entities -Status of QPIM: The last call on this document forced discussion, and the feedback was valuable and incorporated into the current draft. 2.5 QPIM and QDDIM Compatibility with DiffServ Discussion Moderators: Joel and Ed -On QPIM relationship to QDDIM: This relationship is not formally documented in the QPIM document. John Strassner commented that this is a "works with" relationship, rather than a "mapping" relationship, between QPIM and QDDIM. -Bob Moore questioned the issue about DSCP markers not having two values. This may need to be clarified. Also, Bob suggested not reusing the class names from the QDDIM model, in the QPIM model, since that could cause confusion. Ron accepted this last comment as a valid point. -Andrea expressed the opinion that a mapping from QPIM to QDDIM is, indeed, required. We also need to work on clarifying the "configuration" vs. "state" issue. -It was agreed that a new PCIM extensions document would be created, and the relevant parts of QPIM that are generically applicable, would be pulled out and documented separately. The QPIM authors will articipate, as well as volunteers, as they come forward. -Lee Rafalow: Not convinced that the following aspects of QPIM are justified: complexity of "atoms" approach, compound conditions, and Rules within Rules. -Yoram Bernet requested that more attention be given to admission control, and to those conditioning services that are in common to both intserv and rsvp. -Shai Herzog questioned the level of the policy documented here...is it "mechanism" or is it "policy"? 2.6 Monday's Session Wrap-up: -See Section 1, above, for the combined summary of both Monday and Wednesday sessions 3. Detailed Minutes from the Wednesday, December 13 Session: 3.1 Intro and News: Changed the agenda to continue the discussion of Queues and Schedulers. See the sixth item on the agenda (item 3.6, below). 3.2 ICIM: IPSP Policy Model Presentation, Lee Rafalow: -Lee suggests that we harmonize among the various document authors on appropriate re-usable components for packet classification, across the several documents which address this. -See Lee's charts for his review of the IPSP (ICIM) Model. * Basic model structure * Filter-based conditions * Actions, Proposals, and Transforms -Discussion Points: -Differences between the multiple models that do packet classification were reviewed. Lee noted the different objectives for each model, which motivated the different approaches. See the charts. -Semantics of subclassed condition class, as used in the ipsp's icim model, are specific to the ipsec negotiation, which can change from true to false, as more info is received about the security association. This is a different semantic than in the case of QOS. -Grouping differences were also discussed. -Evaluation order is always determined ahead of time, in IPsec policy. This is always mandatory, but the semantic is different from the mandatory semantic in the rest of the policy model. The semantic is: "Try this first, and if it does not work try the next one." -Roles: As used in the policy model, roles represent a binding of policy to interfaces. This is not the appropriate semantic for IPsec, so the PolicyRole object was not used. Instead, the ipsp icim model uses IdentityContexts. -The IPSP model is more oriented toward individual device policy, like QDDIM, rather than the domain level, like QPIM, but the IPSP model derives from the policy classes, like QPIM does. -Discussion: * Strassner: QPIM differences have to do with the reusability of the classes, without binding to specific devices. * Ron Cohen: Sequenced actions: There is a similar function in QPIM, with a selector, for path messages. Suggests we take a look at whether we should have the same basic approach in both QPIM and IPSP's ICIM * ICIM is a model for the PDP to PEP configuration function; it is not a domain level model * Rules are "leaf" objects in the IPSP's ICIM model 3.3 Applying and Linking Policy Discussion (including the discussion about packet classification) -Proposed objective: Harmonize the reusable components across the documents which describe how to represent policy for packet classification, or clearly document why there are differences, due to different design points, different disciplines, etc. Are the semantics really different? -Walter Weiss: Questions whether the IPSP's ICIM model should be handling both levels in one model. Conditions and Actions, can one thing be both? -A work effort is proposed: mapping the different approaches, one to the other. -Reuse of instances vs. reuse of classes: this motivates some of the differences in QPIM. -The usefulness of the QPIM "atoms" approach might drive the QPIM method of representing filters, as being different from other models. On the other hand, maybe convergence of documentation is called for: perhaps a single document which describes the generic approaches, and when each is called for: single field generic (filter entry), variables/operators/values (QPIM), single field specific (ICIM), multi-field specific (6-tuple). -A separate document is proposed to split out the portion of QPIM that documents functions, such as packet classification, that can be re-used across multiple disciplines, with an explanation of the different approaches that remain, if they do indeed remain after the attempt to harmonize them. The current authors of the QPIM document will take the lead with this effort, but volunteers are encouraged, as well. We may do this in a two- step process, with the current authors taking the first shot at the generic document. -The MPLS needs for packet classification should also be taken into account, since this is also valuable experience that we can learn from for the purpose of coming up with a generic approach. -Example: "Source Port = 80" appears to be in all the models. -There is controversy about this point: The distinctions between QPIM and QDDIM may be defensible, given the difference in their scope (network domain-wide scope, vs. device level scope), but what about ICIM (the IPSP's model), which appears to be device-level? But we should be able to articulate the reason that any differences remain, if we can. -The topic of policy languages came up. This is not in our charter, but Andrea suggested we might want to look at the language constructs developed by Morris Sloman at Imperial College in London. -There was also a question about how SNMP handles differences in mibs. Does the SNMP area directorate push back on working groups that taken different approaches to the same problem? Bert: Yes, the Ops and Management area pushes back on working groups that want to go a different way, but the AD's are not always successful in pushing for common approaches. Despite the best of intentions, there are mibs that provide duplicate function in different ways. (BTW: Wasn't Policy supposed to solve this?) 3.4 PCLS Update: (Ryan Moats and Ed Ellesson) -Changes for the -08 version: Please see Ryan's charts for details. -Ryan reviewed the syntax changes from the previous version, as well as other changes, including an issue associated with matching rules, and the fact that there will be a -09 version shortly, with new aux classes, and a new security considerations section. -Security Considerations section: Please see Ed's charts for details. -Ed reviewed the security considerations which will be re-written for the next version. The challenge is to make sure that all the necessary security considerations are covered, across the multiple documents which complete the standardized "policy package" of documents for any specific discipline. -For example, the QOS group of policy documents will include the core policy documents, PCIM and PCLS, as well as the QOS-specific policy info model (QPIM), and the device level info model for QOS (QDDIM), plus whatever the appropriate mapping of these QOS- specific models turn out to be, to an LDAP-accessible directory. -The security considerations sections of all these documents taken together, have to cover all the appropriate issues for applying QOS policy in a real world environment. The security considerations section of PCLS is part of this total coverage. -Please contact Ed if you want to contribute to this section. 3.5 Polterm Harmonization: Andrea Westerinen -See Andrea's charts. -The team which created this draft was successful in achieving its goal: to finalize common policy terminology across multiple working groups, without creating new terms. -The team resolved the conflicting use of the term Policy Rule in different wg's -Polterm draft will be revised with changes discussed in presentation and sent to last call. -References to I-D's will be removed and maintained separately in a cross-reference table linked from the policy framework working group's home page. 3.6 Queues and Schedulers: Walter Weiss -See Walter's charts. This is meant to provide a context for continuing the discussion from Monday on this topic. -In the current QDDIM model, we have greater flexibility in representing queues and schedulers than is currently available in the DiffServ mib with SMIv2. This was accepted as not being a problem, since individual vendors may extend the DiffServ mib in proprietary ways, and we want the QDDIM model to be able to map to these extensions, if possible, to the extent that we can anticipate them. -Brian Carpenter stated that the DiffServ working group's criteria for including something in the DiffServ mib is that it be expressible, and that vendors want it there. Further, it should be clear that QDDIM does not drive the content of the DiffServ mib. -There was considerable discussion of the six charts which Walter presented, which described the pro's and con's of different ways of representing queues, schedulers, and their relationships to each other. This presentation and discussion further clarified the issues, and will be used to help the QDDIM authors come to an agreement for finalizing how that model will represent queues and schedulers and their relationships. 3.7 Use of Policy in AAA Architecture: Cees de Laat -See charts from Cees de Laat, at: http://www.phys.uu.nl/~wwwfi/aaaarch/sandiego/delaat.htm -Cees presented the policy work that is going on in the IRTF, under the AAA Architecture working group. -This working group has an inter-domain focus and an architectural focus, which differentiates it from the work in the policy framework working group, in addition to the fact that they are working on AAA. 3.8 Use of Policy in MPLS: Ritu Chadha and Marcus Brunner -Ritu presented the changes and convergence from the first drafts which dealt with MPLS policy. The authors re-used a number of the ideas for packet filtering, roles and other functions, from the QDDIM and QPIM drafts. -Marcus presented the open issues, including the fact that MPLS policy has not been accepted as a charter item by any IETF working group, including policy framework, mpls, and traffic engineering. -Joel committed to talking to the chairs of the mpls and tewg to help determine the appropriate home for this work. It seems appropriate to host this work where the subject matter experts are (mpls or tewg), with help provided from policy liaison people who have experience in applying the policy information model. 3.9 Wrap-up: See Section 1 of these minutes for the combined summary for both sessions. Ed From majordomo@raleigh.ibm.com Mon Jan 8 08:20:40 2001 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA02250 for ; Mon, 8 Jan 2001 08:20:40 -0500 (EST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id IAA19398; Mon, 8 Jan 2001 08:10:17 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id IAA30844; Mon, 8 Jan 2001 08:10:13 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA38128; Mon, 8 Jan 2001 07:35:20 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA43494; Mon, 8 Jan 2001 07:35:16 -0500 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id HAA28328 for ; Mon, 8 Jan 2001 07:35:16 -0500 Received: from mx-relay1.treas.gov (mx-relay1.treas.gov [199.196.144.5]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id HAA27348 for ; Mon, 8 Jan 2001 07:35:15 -0500 Received: from tias4.treas.gov (tias-gw4.treas.gov [199.196.144.14]) by mx-relay1.treas.gov (8.9.1b+Sun/8.9.3) with SMTP id HAA27939 for ; Mon, 8 Jan 2001 07:35:14 -0500 (EST) Received: from mailhub.net.treas.gov by tias4.treas.gov via smtpd (for mx-relay.treas.gov [199.196.144.5]) with SMTP; 8 Jan 2001 12:35:14 UT Received: from mears.indy.cr.irs.gov (mailhub-2.net.treas.gov [10.7.8.10]) by mailhub-2.net.treas.gov (8.9.1b+Sun/8.9.3) with ESMTP id HAA23092 for ; Mon, 8 Jan 2001 07:35:13 -0500 (EST) Received: from parnelli.indy.cr.irs.gov (IDENT:lsbart35@localhost [127.0.0.1]) by mears.indy.cr.irs.gov (8.9.3/8.9.3) with ESMTP id HAA11331; Mon, 8 Jan 2001 07:35:13 -0500 Message-Id: <3A59B401.80AE6B6F@parnelli.indy.cr.irs.gov> Date: Mon, 08 Jan 2001 07:35:13 -0500 From: "Larry S. Bartz" X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0smp i686) X-Accept-Language: en Mime-Version: 1.0 To: IETF Policy WG LIST Subject: suggested appendix for schema-09 and RFC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Larry S. Bartz" Content-Transfer-Encoding: 7bit I like the narrative style of the schema drafts. In particular, describing objectclasses before describing their attributetypes gives the reader a context for understanding the attributes. But this style makes work for implementers, as they must discover and resolve forward references when implementing under Directory products which balk at forward references. I suggest the next draft and final memo contain an appendix which is only ABNF and which is devoid of forward references. -- #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| # Larry Bartz | | # lbartz@parnelli.indy.cr.irs.gov | Ooo, ooo, | # | Ooo, ooo, oooooo! | # | I've got a gnu attitude! | # voice (317) 226-7060 | | # FAX (317) 226-6378 | | #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| From majordomo@raleigh.ibm.com Mon Jan 8 10:12:26 2001 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06790 for ; Mon, 8 Jan 2001 10:12:26 -0500 (EST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id JAA30426; Mon, 8 Jan 2001 09:52:14 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA30790; Mon, 8 Jan 2001 09:52:11 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA38458; Mon, 8 Jan 2001 08:47:12 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA43058; Mon, 8 Jan 2001 08:47:09 -0500 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id IAA05784 for ; Mon, 8 Jan 2001 08:47:09 -0500 Received: from mx-relay2.treas.gov (mx-relay2.treas.gov [199.196.144.6]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id IAA26758 for ; Mon, 8 Jan 2001 08:47:08 -0500 Received: from tias4.treas.gov (tias-gw4.treas.gov [199.196.144.14]) by mx-relay2.treas.gov (8.9.1b+Sun/8.9.3) with SMTP id IAA22090 for ; Mon, 8 Jan 2001 08:47:08 -0500 (EST) Received: from mailhub.net.treas.gov by tias4.treas.gov via smtpd (for mx-relay.treas.gov [199.196.144.6]) with SMTP; 8 Jan 2001 13:47:08 UT Received: from mears.indy.cr.irs.gov (mailhub-3.net.treas.gov [10.7.8.11]) by mailhub-3.net.treas.gov (8.9.3+Sun/8.9.3) with ESMTP id IAA29354 for ; Mon, 8 Jan 2001 08:44:55 -0500 (EST) Received: from parnelli.indy.cr.irs.gov (IDENT:lsbart35@localhost [127.0.0.1]) by mears.indy.cr.irs.gov (8.9.3/8.9.3) with ESMTP id IAA11398; Mon, 8 Jan 2001 08:47:06 -0500 Message-Id: <3A59C4DA.FE0F215C@parnelli.indy.cr.irs.gov> Date: Mon, 08 Jan 2001 08:47:06 -0500 From: "Larry S. Bartz" X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0smp i686) X-Accept-Language: en Mime-Version: 1.0 To: IETF Policy WG LIST Subject: schema-09 and RFC: avoiding collisions in RoleName namespace Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Larry S. Bartz" Content-Transfer-Encoding: 7bit I suggest this (or similar) verbiage be added to schema-09 and subsequent documents, possibly in "5.3. The Class policyRule", following the ABNF for the policyRoles attributetype. Alternatively, this verbiage could be included as an appendix entitled "Avoiding Collisions in the RoleName Namespace". Such an appendix could be referenced from "5.3. The Class policyRule". The RoleName substring component of the policyRoles attribute must be drawn by implementers from an unregulated namespace. Since the namespace is unregulated, there is a potential for namespace collisions. The same RoleName could be associated with entirely different semantics in two or more implementations. The negative consequences of these namespace collisions could be manifested in several situations, including: when policy information from two or more unrelated Directory implementations is accessed and evaluated simultaneously; when policy infomation from two or more federated Directory instances is evaluated in the federated context; when policy information is replicated from its initial Directory implementation to another. Implementers whose policy information may be subject to the potential for namespace collision SHOULD devise and follow a strategy of collision avoidance in the RoleName namespace. Implementers MAY create values for the RoleName substring which consist of the descriptive and functional name of the role (the "natural" role name), then prepend the natural role name with a string which guarantees uniqueness to their implementation. Choosing an interCap style for the resulting string can promote readability. For example, policy administrators at bigcorp.com and tinycorp.com each create a RoleName "firewall". While the term "firewall" may appear to offer unambiguous semantics, it is entirely possible that the two policy admins ascribe some conflicting properties to the "firewall" role. When bigcorp and tinycorp interoperate in Policy, the namespace collision produces negative consequences. In order to collision-proof the RoleName, the policy admins should create and implement RoleNames "comBigcorpFirewall" and "comTinycorpFirewall", respectively. -- #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| # Larry Bartz | | # lbartz@parnelli.indy.cr.irs.gov | Ooo, ooo, | # | Ooo, ooo, oooooo! | # | I've got a gnu attitude! | # voice (317) 226-7060 | | # FAX (317) 226-6378 | | #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| From majordomo@raleigh.ibm.com Mon Jan 8 19:15:56 2001 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18972 for ; Mon, 8 Jan 2001 19:15:55 -0500 (EST) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id TAA35052; Mon, 8 Jan 2001 19:08:02 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id TAA29284; Mon, 8 Jan 2001 19:07:10 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA39472; Mon, 8 Jan 2001 10:20:52 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA26664; Mon, 8 Jan 2001 10:20:48 -0500 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA07096 for ; Mon, 8 Jan 2001 10:20:49 -0500 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.228.37]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id KAA17058; Mon, 8 Jan 2001 10:20:47 -0500 Importance: Normal Subject: Re: schema-09 and RFC: avoiding collisions in RoleName namespace To: "Larry S. Bartz" Cc: IETF Policy WG LIST X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-Id: From: "Robert Moore" Date: Mon, 8 Jan 2001 10:25:57 -0500 X-Mimetrack: Serialize by Router on D04NM200/04/M/IBM(Release 5.0.3 (Intl)|21 March 2000) at 01/08/2001 10:20:47 AM Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Robert Moore" Larry, I have no problem adding some text along these lines, if the rest of the WG thinks it would be valuable. Since the possibility of collisions in policyRoles values has nothing to do with storing policy in an LDAP-accessible directory, the text you're interested in should really have gone into the PCIM, not PCLS. But since it's not in the PCIM, PCLS is as good a place as any for it. Would other WG members like to see Larry's text included in PCLS-09? Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com "Larry S. Bartz" @raleigh.ibm.com on 01/08/2001 08:47:06 AM Please respond to "Larry S. Bartz" Sent by: policy-owner@raleigh.ibm.com To: IETF Policy WG LIST cc: Subject: schema-09 and RFC: avoiding collisions in RoleName namespace I suggest this (or similar) verbiage be added to schema-09 and subsequent documents, possibly in "5.3. The Class policyRule", following the ABNF for the policyRoles attributetype. Alternatively, this verbiage could be included as an appendix entitled "Avoiding Collisions in the RoleName Namespace". Such an appendix could be referenced from "5.3. The Class policyRule". The RoleName substring component of the policyRoles attribute must be drawn by implementers from an unregulated namespace. Since the namespace is unregulated, there is a potential for namespace collisions. The same RoleName could be associated with entirely different semantics in two or more implementations. The negative consequences of these namespace collisions could be manifested in several situations, including: when policy information from two or more unrelated Directory implementations is accessed and evaluated simultaneously; when policy infomation from two or more federated Directory instances is evaluated in the federated context; when policy information is replicated from its initial Directory implementation to another. Implementers whose policy information may be subject to the potential for namespace collision SHOULD devise and follow a strategy of collision avoidance in the RoleName namespace. Implementers MAY create values for the RoleName substring which consist of the descriptive and functional name of the role (the "natural" role name), then prepend the natural role name with a string which guarantees uniqueness to their implementation. Choosing an interCap style for the resulting string can promote readability. For example, policy administrators at bigcorp.com and tinycorp.com each create a RoleName "firewall". While the term "firewall" may appear to offer unambiguous semantics, it is entirely possible that the two policy admins ascribe some conflicting properties to the "firewall" role. When bigcorp and tinycorp interoperate in Policy, the namespace collision produces negative consequences. In order to collision-proof the RoleName, the policy admins should create and implement RoleNames "comBigcorpFirewall" and "comTinycorpFirewall", respectively. -- #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| # Larry Bartz | | # lbartz@parnelli.indy.cr.irs.gov | Ooo, ooo, | # | Ooo, ooo, oooooo! | # | I've got a gnu attitude! | # voice (317) 226-7060 | | # FAX (317) 226-6378 | | #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| From majordomo@raleigh.ibm.com Tue Jan 9 06:34:48 2001 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08682 for ; Tue, 9 Jan 2001 06:34:48 -0500 (EST) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id GAA34638; Tue, 9 Jan 2001 06:24:08 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id GAA11136; Tue, 9 Jan 2001 06:24:06 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA48456; Tue, 9 Jan 2001 05:54:42 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA50752; Tue, 9 Jan 2001 05:54:37 -0500 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id FAA25954 for ; Tue, 9 Jan 2001 05:54:40 -0500 Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id FAA34676 for ; Tue, 9 Jan 2001 05:54:37 -0500 Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id FAA12818 for ; Tue, 9 Jan 2001 05:54:37 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id FAA12801 for ; Tue, 9 Jan 2001 05:54:36 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Tue, 9 Jan 2001 11:54:31 +0100 Message-Id: <2413FED0DFE6D111B3F90008C7FA61FB0AAEEE80@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Larry S. Bartz" , Robert Moore Cc: Policy Mailing List Subject: RE: schema-09 and RFC: avoiding collisions in RoleName namespace Date: Tue, 9 Jan 2001 11:54:29 +0100 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Wijnen, Bert (Bert)" Comments inline > ---------- > From: Robert Moore[SMTP:remoore@us.ibm.com] > Reply To: Robert Moore > Sent: Monday, January 08, 2001 4:25 PM > To: Larry S. Bartz > Cc: IETF Policy WG LIST > Subject: Re: schema-09 and RFC: avoiding collisions in RoleName > namespace > > Larry, > > I have no problem adding some text along these lines, if > the rest of the WG thinks it would be valuable. Since the > possibility of collisions in policyRoles values has nothing > to do with storing policy in an LDAP-accessible directory, > the text you're interested in should really have gone into > the PCIM, not PCLS. But since it's not in the PCIM, PCLS > is as good a place as any for it. > If we believe it belongs on PCIMMM, then another way to achieve this is that we put it on our list of edits for the next rev of PCIM (i.e. whenever we go to DS or recycle at PS). Bert > Would other WG members like to see Larry's text included > in PCLS-09? > > Regards, > Bob > > Bob Moore > IBM Networking Software > +1-919-254-4436 > remoore@us.ibm.com > > > > "Larry S. Bartz" @raleigh.ibm.com on > 01/08/2001 08:47:06 AM > > Please respond to "Larry S. Bartz" > > Sent by: policy-owner@raleigh.ibm.com > > > To: IETF Policy WG LIST > cc: > Subject: schema-09 and RFC: avoiding collisions in RoleName namespace > > > > I suggest this (or similar) verbiage be added to schema-09 and > subsequent documents, possibly in "5.3. The Class policyRule", > following the ABNF for the policyRoles attributetype. Alternatively, > this verbiage could be included as an appendix entitled "Avoiding > Collisions in the RoleName Namespace". Such an appendix could be > referenced from "5.3. The Class policyRule". > > The RoleName substring component of the policyRoles attribute must be > drawn by implementers from an unregulated namespace. Since the > namespace is unregulated, there is a potential for namespace collisions. > The same RoleName could be associated with entirely different semantics > in two or more implementations. The negative consequences of these > namespace collisions could be manifested in several situations, > including: > when policy information from two or more unrelated Directory > implementations > is accessed and evaluated simultaneously; when policy infomation from > two > or more federated Directory instances is evaluated in the federated > context; when policy information is replicated from its initial > Directory > implementation to another. > > Implementers whose policy information may be subject to the potential > for namespace collision SHOULD devise and follow a strategy of collision > avoidance in the RoleName namespace. Implementers MAY create values for > the RoleName substring which consist of the descriptive and functional > name of the role (the "natural" role name), then prepend the natural > role name with a string which guarantees uniqueness to their > implementation. > Choosing an interCap style for the resulting string can promote > readability. > > For example, policy administrators at bigcorp.com and tinycorp.com each > create a RoleName "firewall". While the term "firewall" may appear to > offer > unambiguous semantics, it is entirely possible that the two policy > admins > ascribe some conflicting properties to the "firewall" role. When bigcorp > and tinycorp interoperate in Policy, the namespace collision produces > negative consequences. In order to collision-proof the RoleName, the > policy > admins should create and implement RoleNames "comBigcorpFirewall" and > "comTinycorpFirewall", respectively. > > -- > #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| > # Larry Bartz | | > # lbartz@parnelli.indy.cr.irs.gov | Ooo, ooo, | > # | Ooo, ooo, oooooo! | > # | I've got a gnu attitude! | > # voice (317) 226-7060 | | > # FAX (317) 226-6378 | | > #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| > > From majordomo@raleigh.ibm.com Tue Jan 9 10:44:54 2001 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14241 for ; Tue, 9 Jan 2001 10:44:53 -0500 (EST) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA34372; Tue, 9 Jan 2001 10:38:38 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id KAA32970; Tue, 9 Jan 2001 10:38:30 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA40672; Tue, 9 Jan 2001 10:03:02 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA34008; Tue, 9 Jan 2001 10:02:59 -0500 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA23874 for ; Tue, 9 Jan 2001 10:03:00 -0500 Received: from longsys.com (dmz.longsys.com [63.111.150.5]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA21516 for ; Tue, 9 Jan 2001 10:02:58 -0500 Received: from joel (discordian.longsys.com [63.111.150.74]) by longsys.com (8.10.0/8.10.0) with ESMTP id f09F2WR21718; Tue, 9 Jan 2001 15:02:33 GMT Message-Id: <4.2.2.20010109100159.00b5d3b0@localhost> X-Sender: joel@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 09 Jan 2001 10:02:29 -0500 To: "Wijnen, Bert (Bert)" , "Larry S. Bartz" , Robert Moore From: "Joel M. Halpern" Subject: RE: schema-09 and RFC: avoiding collisions in RoleName namespace Cc: Policy Mailing List In-Reply-To: <2413FED0DFE6D111B3F90008C7FA61FB0AAEEE80@nl0006exch002u.nl .lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Joel M. Halpern" Another place to capture this (at least for the time being) would be in the PCIM extensions draft. Yours, Joel M. Halpern At 11:54 AM 1/9/01 +0100, Wijnen, Bert (Bert) wrote: >Comments inline > > > ---------- > > From: Robert Moore[SMTP:remoore@us.ibm.com] > > Reply To: Robert Moore > > Sent: Monday, January 08, 2001 4:25 PM > > To: Larry S. Bartz > > Cc: IETF Policy WG LIST > > Subject: Re: schema-09 and RFC: avoiding collisions in RoleName > > namespace > > > > Larry, > > > > I have no problem adding some text along these lines, if > > the rest of the WG thinks it would be valuable. Since the > > possibility of collisions in policyRoles values has nothing > > to do with storing policy in an LDAP-accessible directory, > > the text you're interested in should really have gone into > > the PCIM, not PCLS. But since it's not in the PCIM, PCLS > > is as good a place as any for it. > > >If we believe it belongs on PCIMMM, then another way to achieve >this is that we put it on our list of edits for the next rev of PCIM >(i.e. whenever we go to DS or recycle at PS). > >Bert > > > Would other WG members like to see Larry's text included > > in PCLS-09? > > > > Regards, > > Bob > > > > Bob Moore > > IBM Networking Software > > +1-919-254-4436 > > remoore@us.ibm.com > > > > > > > > "Larry S. Bartz" @raleigh.ibm.com on > > 01/08/2001 08:47:06 AM > > > > Please respond to "Larry S. Bartz" > > > > Sent by: policy-owner@raleigh.ibm.com > > > > > > To: IETF Policy WG LIST > > cc: > > Subject: schema-09 and RFC: avoiding collisions in RoleName namespace > > > > > > > > I suggest this (or similar) verbiage be added to schema-09 and > > subsequent documents, possibly in "5.3. The Class policyRule", > > following the ABNF for the policyRoles attributetype. Alternatively, > > this verbiage could be included as an appendix entitled "Avoiding > > Collisions in the RoleName Namespace". Such an appendix could be > > referenced from "5.3. The Class policyRule". > > > > The RoleName substring component of the policyRoles attribute must be > > drawn by implementers from an unregulated namespace. Since the > > namespace is unregulated, there is a potential for namespace collisions. > > The same RoleName could be associated with entirely different semantics > > in two or more implementations. The negative consequences of these > > namespace collisions could be manifested in several situations, > > including: > > when policy information from two or more unrelated Directory > > implementations > > is accessed and evaluated simultaneously; when policy infomation from > > two > > or more federated Directory instances is evaluated in the federated > > context; when policy information is replicated from its initial > > Directory > > implementation to another. > > > > Implementers whose policy information may be subject to the potential > > for namespace collision SHOULD devise and follow a strategy of collision > > avoidance in the RoleName namespace. Implementers MAY create values for > > the RoleName substring which consist of the descriptive and functional > > name of the role (the "natural" role name), then prepend the natural > > role name with a string which guarantees uniqueness to their > > implementation. > > Choosing an interCap style for the resulting string can promote > > readability. > > > > For example, policy administrators at bigcorp.com and tinycorp.com each > > create a RoleName "firewall". While the term "firewall" may appear to > > offer > > unambiguous semantics, it is entirely possible that the two policy > > admins > > ascribe some conflicting properties to the "firewall" role. When bigcorp > > and tinycorp interoperate in Policy, the namespace collision produces > > negative consequences. In order to collision-proof the RoleName, the > > policy > > admins should create and implement RoleNames "comBigcorpFirewall" and > > "comTinycorpFirewall", respectively. > > > > -- > > #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| > > # Larry Bartz | | > > # lbartz@parnelli.indy.cr.irs.gov | Ooo, ooo, | > > # | Ooo, ooo, oooooo! | > > # | I've got a gnu attitude! | > > # voice (317) 226-7060 | | > > # FAX (317) 226-6378 | | > > #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| > > > > From majordomo@raleigh.ibm.com Mon Jan 15 00:11:01 2001 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA15339 for ; Mon, 15 Jan 2001 00:11:01 -0500 (EST) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id AAA07110; Mon, 15 Jan 2001 00:05:24 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id AAA13244; Mon, 15 Jan 2001 00:05:24 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA64348; Sun, 14 Jan 2001 23:37:54 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA62546; Sun, 14 Jan 2001 23:37:50 -0500 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id XAA37622 for ; Sun, 14 Jan 2001 23:37:50 -0500 Received: from web10511.mail.yahoo.com (web10511.mail.yahoo.com [216.136.172.143]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id XAA20150 for ; Sun, 14 Jan 2001 23:37:45 -0500 Message-Id: <20010115043749.91189.qmail@web10511.mail.yahoo.com> Received: from [198.206.187.100] by web10511.mail.yahoo.com; Sun, 14 Jan 2001 20:37:49 PST Date: Sun, 14 Jan 2001 20:37:49 -0800 (PST) From: Mahadevan Iyer Subject: PCIM Extensions To: policy@raleigh.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Mahadevan Iyer Hello All, Context ======= I am working on an information model for a policy application related to provisioning of VPN's over an IP network(IPVPN Policy Information Model). Each IPVPN has connectivity, security and QoS components. I am attempting to use the constructs defined in the QPIM as far as possible. Details ======= There were 3 requirements (among others) which I could not resolve using the QPIM constructs. I would like to address them to the group investigating extensions to PCIM. The hope is that the application can use standardized extensions to satisfy these reqirements. This would help limit the new constructs being defined in the IPVPN model to the application specific details. 1. There needs to be a means to associate aggregate conditions at the policy group level to narrow the search for a matching policy. (There have been many emails explaining this requirement on the mailing list) 2. There are 3 types of policy domains which need to be supported in the application viz. Administrative, Functional and Enforcement. Organizing the containment according to one of these domains does not solve the problem of the remaining two domains. The three domains could be completely overlapping or mutually exclusive. There needs to be an uniform means to map all three domains. 3. There needs to be a means to formally specify the policy target(some overlap with the enforcement domain) in the policyrule. I am looking for something that is stronger than a policy condition variable type. The logic that led to the creation of "PolicyTimePeriodCondition", instead of adding a policy condition variable type, could be applied out here. Looking for ... =============== 1. Feedback on relevence of these requirements in other policy applications 2. Feedback on whether these should be addressed in the extensions 3. Feedback on how they(if the answer to 2 is yes) could be addressed in extensions. Thanks __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ From majordomo@raleigh.ibm.com Mon Jan 15 05:47:25 2001 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA00516 for ; Mon, 15 Jan 2001 05:47:25 -0500 (EST) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id FAA19764; Mon, 15 Jan 2001 05:41:26 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id FAA19626; Mon, 15 Jan 2001 05:41:15 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA48220; Mon, 15 Jan 2001 05:00:49 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA42066; Mon, 15 Jan 2001 05:00:44 -0500 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id FAA17088 for ; Mon, 15 Jan 2001 05:00:43 -0500 Received: from ntx.netguard.co.il ([212.68.136.130]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id FAA09104 for ; Mon, 15 Jan 2001 05:00:35 -0500 Received: by ntx.netguard.co.il with Internet Mail Service (5.5.2650.21) id ; Mon, 15 Jan 2001 11:58:39 +0200 Message-Id: <6923C8A11386D311BAF300508B0A9727644149@ntx.netguard.co.il> From: Sagit Buchnik To: policy@raleigh.ibm.com Subject: Policy holders - where are they placed in CIM? Date: Mon, 15 Jan 2001 11:58:39 +0200 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Sagit Buchnik Hi, Where among the CIM schemas are the entities (like firewalls and VPNs) that hold the policies placed? Regards, Sagit Buchnik Software Engineer NetGuard Ltd. Tel: 972 66 44 98 04 E-Mail: sagit_b@netguard.co.il Web Site: www.netguard.com __________________________________________________________ NetGuard. The Key to Productive Security. _________________________________________________________ From majordomo@raleigh.ibm.com Mon Jan 15 11:04:29 2001 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08151 for ; Mon, 15 Jan 2001 11:04:29 -0500 (EST) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA21552; Mon, 15 Jan 2001 10:56:12 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id KAA26838; Mon, 15 Jan 2001 10:56:04 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA38316; Mon, 15 Jan 2001 10:17:24 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA47776; Mon, 15 Jan 2001 10:17:21 -0500 Received: from lmr (dyn9-37-49-17.raleigh.ibm.com [9.37.49.17]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id KAA25762 for ; Mon, 15 Jan 2001 10:17:22 -0500 Message-Id: <003d01c07f05$fe3c42a0$11312509@raleigh.ibm.com> From: "Lee Rafalow" To: References: <20010115043749.91189.qmail@web10511.mail.yahoo.com> Subject: Re: PCIM Extensions Date: Mon, 15 Jan 2001 10:15:27 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Lee Rafalow" Content-Transfer-Encoding: 7bit Mahadevan, > 1. There needs to be a means to associate aggregate > conditions at the policy group level to narrow the > search for a matching policy. (There have been many > emails explaining this requirement on the mailing > list) I think the requirement is now understood, it's just the solution that needs further discussion. > 2. There are 3 types of policy domains which need to > be supported in the application viz. Administrative, > Functional and Enforcement. Organizing the containment > according to one of these domains does not solve the > problem of the remaining two domains. The three > domains could be completely overlapping or mutually > exclusive. > There needs to be an uniform means to map all > three domains. Say more. > 3. There needs to be a means to formally specify the > policy target(some overlap with the enforcement > domain) in the policyrule. I am looking for something > that is stronger than a policy condition variable > type. The logic that led to the creation of > "PolicyTimePeriodCondition", instead of adding a > policy condition variable type, could be applied out > here. What are the functions you're looking for that are not provided by PolicyRole? Lee Lee M. Rafalow Voice: 1-919-254-4455; Fax: 1-919-254-6243 IBM Internet Technology Management IBM Corporation P.O. Box 12195, BRQA/502 RTP, NC 27709 USA Alternate email: rafalow@us.ibm.com Home email: rafalow@mindspring.com From majordomo@raleigh.ibm.com Mon Jan 15 11:04:50 2001 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08165 for ; Mon, 15 Jan 2001 11:04:49 -0500 (EST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA24394; Mon, 15 Jan 2001 10:56:15 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id KAA17132; Mon, 15 Jan 2001 10:56:04 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA51088; Mon, 15 Jan 2001 10:17:03 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA41832; Mon, 15 Jan 2001 10:16:59 -0500 Received: from lmr (dyn9-37-49-17.raleigh.ibm.com [9.37.49.17]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id KAA20870 for ; Mon, 15 Jan 2001 10:17:00 -0500 Message-Id: <003c01c07f05$f1131ea0$11312509@raleigh.ibm.com> From: "Lee Rafalow" To: References: <6923C8A11386D311BAF300508B0A9727644149@ntx.netguard.co.il> Subject: Re: Policy holders - where are they placed in CIM? Date: Mon, 15 Jan 2001 10:15:05 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Lee Rafalow" Content-Transfer-Encoding: 7bit Sagit, The CIM v2.5 schema is now available so take a look at the CIM_System objects and the Policy model. A System aggregates system components (e.g., PolicyRepository), hosts services (e.g., IKEService) and has associations with policies (PolicyInSystem). For our purposes a system is likely to be a ComputerSystem or an AdminDomain. http://www.dmtf.org/spec/cim_schema_v25.html which has links to: http://www.dmtf.org/spec/cim_schema25/cim_core25.mof http://www.dmtf.org/spec/cim_schema25/cim_system25.mof http://www.dmtf.org/spec/cim_schema25/cim_policy25.mof The IPsec model is included in the zip files but there's no link on the cim_schema_v25.html page (hopefully it'll get fixed later today). Lee ----- Original Message ----- From: "Sagit Buchnik" To: Sent: Monday, January 15, 2001 4:58 AM Subject: Policy holders - where are they placed in CIM? > > Hi, > Where among the CIM schemas are the entities (like firewalls and VPNs) that > hold the policies placed? > Regards, > Sagit Buchnik > Software Engineer > NetGuard Ltd. > Tel: 972 66 44 98 04 > E-Mail: sagit_b@netguard.co.il > Web Site: www.netguard.com > __________________________________________________________ > NetGuard. The Key to Productive Security. > _________________________________________________________ > From majordomo@raleigh.ibm.com Tue Jan 16 05:39:22 2001 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA07773 for ; Tue, 16 Jan 2001 05:39:19 -0500 (EST) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id FAA34252; Tue, 16 Jan 2001 05:20:58 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id FAA03822; Tue, 16 Jan 2001 05:20:51 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA41842; Tue, 16 Jan 2001 04:43:46 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA41820; Tue, 16 Jan 2001 04:43:41 -0500 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id EAA25756 for ; Tue, 16 Jan 2001 04:43:41 -0500 Received: from web10501.mail.yahoo.com (web10501.mail.yahoo.com [216.136.130.151]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id EAA22580 for ; Tue, 16 Jan 2001 04:43:38 -0500 Message-Id: <20010116094338.11256.qmail@web10501.mail.yahoo.com> Received: from [198.206.187.100] by web10501.mail.yahoo.com; Tue, 16 Jan 2001 01:43:38 PST Date: Tue, 16 Jan 2001 01:43:38 -0800 (PST) From: Mahadevan Iyer Subject: Re: PCIM Extensions To: Lee Rafalow , policy@raleigh.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Mahadevan Iyer Lee, > > I think the requirement is now understood, it's just > the solution that needs > further discussion. OK > > > 2. There are 3 types of policy domains which > need to > > be supported in the application viz. > Administrative, > > Functional and Enforcement. Organizing the > containment > > according to one of these domains does not solve > the > > problem of the remaining two domains. The three > > domains could be completely overlapping or > mutually > > exclusive. > > There needs to be an uniform means to map all > > three domains. > > Say more. Administrative domain - decides who gets to modify which parts of the policy database Functional domain - indicates the functionality being addressed by the policies e.g. Firewall, QoS etc. Enforcement domain - decides the physical or logical region over which the policy is to be enforced. The "Functional Domain" is less important than the others, but neverthless required. I see the PolicyRole providing this capability but more on that later ... In a lot of instances the Administrative domain and Enforcement domain go hand in hand. e.g."EastCoast" admins will manage policies for "EastCoast" domains. But when the administrative domain does not map to the enforcement domain there is a need to separate them. e.g. A single "EastCoast" user administrator manages user groups for the "EastCoast" as well as "WestCoast" > > > 3. There needs to be a means to formally specify > the > > policy target(some overlap with the enforcement > > domain) in the policyrule. I am looking for > something > > that is stronger than a policy condition variable > > type. The logic that led to the creation of > > "PolicyTimePeriodCondition", instead of adding a > > policy condition variable type, could be applied > out > > here. > > What are the functions you're looking for that are > not provided by > PolicyRole? The PolicyRole from [PCIM] ======================= Using the roles and role-combinations it received from its PEPs as indicated in the examples above, the PDP is able to locate and retrieve the policy rules that are relevant to it. ======================== This is used to indicate a class of consumers e.g "all policy enforcers that implement a firewall" should pick up policies that have "firewall" mentioned in their "PolicyRole" attribute. This does not address the problem of which of the 10 firewalls in the network need to download the policy. This is how I read it, maybe you could tell me how the PolicyRole is supposed to be used. Thanks __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ From majordomo@raleigh.ibm.com Tue Jan 16 11:30:40 2001 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15576 for ; Tue, 16 Jan 2001 11:30:40 -0500 (EST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA32144; Tue, 16 Jan 2001 10:12:48 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id KAA29712; Tue, 16 Jan 2001 10:10:19 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA50160; Tue, 16 Jan 2001 09:44:05 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA38372; Tue, 16 Jan 2001 09:44:02 -0500 Received: from lmr (dyn9-37-49-17.raleigh.ibm.com [9.37.49.17]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA28180 for ; Tue, 16 Jan 2001 09:44:00 -0500 Message-Id: <001f01c07fca$7ef23de0$11312509@raleigh.ibm.com> From: "Lee Rafalow" To: References: <20010116094338.11256.qmail@web10501.mail.yahoo.com> Subject: Re: PCIM Extensions Date: Tue, 16 Jan 2001 09:41:52 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Lee Rafalow" Content-Transfer-Encoding: 7bit Mahadevan, Thanks for the additional explanations. A few thoughts in reply.... > Administrative domain - decides who gets to modify > which parts of the policy database > > Functional domain - indicates the functionality being > addressed by the policies e.g. Firewall, QoS etc. > > Enforcement domain - decides the physical or logical > region over which the policy is to be enforced. > > The "Functional Domain" is less important than the > others, but neverthless required. I see the PolicyRole > providing this capability but more on that later ... > > In a lot of instances the Administrative domain and > Enforcement domain go hand in hand. e.g."EastCoast" > admins will manage policies for "EastCoast" domains. > But when the administrative domain does not map to the > enforcement domain there is a need to separate them. > e.g. A single "EastCoast" user administrator manages > user groups for the "EastCoast" as well as "WestCoast" In your example, isn't it simply that there are a set of administrators that have rights for administering both the east and west domains? I think one has to ask why resources are divided into domains. I suppose there can be scaling issues but the way I've thought of administrative domains is that policies within a domain are consistent and coherent. That is, the enforcement points within a domain are all cooperating to achieve some consistent set of organizational objectives. If it's scaling issues that cause one to break a logical domain into subdomains then I'd try to represent them that way, if for no other reason than to capture the common organizational objectives. AdminDomain USA / \ / \ / \ AdminDomain AdminDomain West East The users that are authorized to administer the resources within a domain can be associated with the superior and/or subordinate domains as needed or with multiple disjoint domains for that matter. Am I missing something? > The PolicyRole from [PCIM] > ======================= > Using the roles and role-combinations it received from > its PEPs as > indicated in the examples above, the PDP is able > to locate and > retrieve the policy rules that are relevant to > it. > ======================== > > This is used to indicate a class of consumers e.g "all > policy enforcers that implement a firewall" should > pick up policies that have "firewall" mentioned in > their "PolicyRole" attribute. > > This does not address the problem of which of the 10 > firewalls in the network need to download the policy. > > This is how I read it, maybe you could tell me how the > PolicyRole is supposed to be used. > We've found PolicyRole to be a bit problematic as well. It's overloaded and I don't think it has a clear delineation from conditions. The terminology doc says it's "an administratively specified characteristic of a managed element...to determine the applicability of the rule/PRC to a particular managed element." We're not confined to a single functional PolicyRole (e.g., "firewall"), one can have role combinations for "firewall&&interior" or "exterior&&firewall" thus defining the sets of policy consumers by both function and an interface classifying qualifier. Similarly, one can have a function and qualifiers like "firewall&&interior&&raleigh.ibm.com" adding another characteristic for network domain thus fully specifying an example of what you've called the functional and the enforcement domains. Does that help or is there more needed? Lee M. Rafalow Voice: 1-919-254-4455; Fax: 1-919-254-6243 IBM Internet Technology Management IBM Corporation P.O. Box 12195, BRQA/502 RTP, NC 27709 USA Alternate email: rafalow@us.ibm.com Home email: rafalow@mindspring.com From majordomo@raleigh.ibm.com Thu Jan 18 07:45:25 2001 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22530 for ; Thu, 18 Jan 2001 07:45:24 -0500 (EST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id HAA25276; Thu, 18 Jan 2001 07:40:04 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id HAA24548; Thu, 18 Jan 2001 07:39:59 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA28742; Thu, 18 Jan 2001 07:01:42 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA33086; Thu, 18 Jan 2001 07:01:39 -0500 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id HAA21884; Thu, 18 Jan 2001 07:01:42 -0500 Received: from cisco.com (csi-admin1.cisco.com [144.254.91.12]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id HAA27352; Thu, 18 Jan 2001 07:01:37 -0500 Received: from yramberg-8000.cisco.com (telaviv3-dhcp159.cisco.com [144.254.93.97]) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id OAA11226; Thu, 18 Jan 2001 14:01:03 +0200 (IST) Message-Id: <4.3.2.7.2.20010118133353.029cea10@csi-admin1.cisco.com> X-Sender: yramberg@csi-admin1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 18 Jan 2001 14:01:19 +0200 To: Mahadevan Iyer , Lee Rafalow , policy@raleigh.ibm.com From: Yoram Ramberg Subject: Re: PCIM Extensions In-Reply-To: <20010116094338.11256.qmail@web10501.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Yoram Ramberg [...snip...] > > > > 3. There needs to be a means to formally specify > > the > > > policy target(some overlap with the enforcement > > > domain) in the policyrule. I am looking for > > something > > > that is stronger than a policy condition variable > > > type. The logic that led to the creation of > > > "PolicyTimePeriodCondition", instead of adding a > > > policy condition variable type, could be applied > > out > > > here. > > > > What are the functions you're looking for that are > > not provided by > > PolicyRole? > >The PolicyRole from [PCIM] >======================= >Using the roles and role-combinations it received from >its PEPs as > indicated in the examples above, the PDP is able >to locate and > retrieve the policy rules that are relevant to >it. >======================== > >This is used to indicate a class of consumers e.g "all >policy enforcers that implement a firewall" should >pick up policies that have "firewall" mentioned in >their "PolicyRole" attribute. > >This does not address the problem of which of the 10 >firewalls in the network need to download the policy. > >This is how I read it, maybe you could tell me how the >PolicyRole is supposed to be used. [...snip...] Ah... Actually, my reading of this is slightly different. However, I have my problems with that text, which may be also the cause for the apparent misunderstanding. The following text from PCIM seems to imply what you said: "A role represents a functional characteristic or capability of a resource to which policies are applied. Examples of roles include Backbone interface, Frame Relay interface, BGP-capable router, web server, firewall, etc. " However, this is quite restrictive and unnecessary. Furthermore, it is not (IMO) the intention of the authors at all!. I think of a role as a mapping mechanism between policies and their targets. The above text represent an example where roles are used to map policy to objects that have some "functional characteristics" such as "Backbone interface", etc. However, these are just names, nothing more. "Frame Relay" may be a role name and the mapping of a given policy using this role *may be* interpreted by a (a very smart) PDP to frame relay interfaces. Another usage for role will be "VPN1-Ingress". This is, yet again, a name. How to assign this name to actual network elements is way outside the scope of PCIM. Within a given network, the 'VPN1-Ingress' role may be assigned to a bunch of interfaces determined to be serving in this role. Some of those may be actually frame relay while others may be ATM and maybe even virtual tunnel interfaces or what have you. No requirement is placed on a semantic mapping from the value of the role name to a member in a set of network elements carrying this role. This means that the mapping you desire is exactly what roles do. This also means that the text you're referring to in PCIM is somewhat misleading. Bottom line: The role *may* represent a functional characteristic. It may also represent more or less than a functional characteristic, say a functional characteristic and an administrative purpose. One more thing about this example: The text also says that the roles are received from the PEPs. This is true only when the PEPs and PDPs use COPS to inter-communicate. Notwithstanding the PEP/PDP terminology, this is not only the case. Indeed, this is still the minority case in the real world to date. I'm just saying this lest further confusion is created by that text. *Yoram From majordomo@raleigh.ibm.com Thu Jan 18 09:53:21 2001 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25482 for ; Thu, 18 Jan 2001 09:53:21 -0500 (EST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id JAA27286; Thu, 18 Jan 2001 09:44:50 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA32854; Thu, 18 Jan 2001 09:44:50 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA59832; Thu, 18 Jan 2001 09:20:58 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA50606; Thu, 18 Jan 2001 09:20:54 -0500 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id JAA34048; Thu, 18 Jan 2001 09:20:57 -0500 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.228.37]) by southrelay02.raleigh.ibm.com (8.11.1/NCO v4.95) with ESMTP id f0IEKsk80258; Thu, 18 Jan 2001 09:20:54 -0500 Importance: Normal Subject: Re: PCIM Extensions To: Mahadevan Iyer , Yoram Ramberg Cc: Lee Rafalow , policy@raleigh.ibm.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-Id: From: "Robert Moore" Date: Thu, 18 Jan 2001 09:26:16 -0500 X-Mimetrack: Serialize by Router on D04NM200/04/M/IBM(Release 5.0.3 (Intl)|21 March 2000) at 01/18/2001 09:20:56 AM Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Robert Moore" Mahadevan, Yoram is correct. The intent of roles / role combinations all along was to allow the values to provide functional categorization, or administrative categorization, or both. In fact, the first example cited (Backbone interface) was supposed to represent an administrative category, to be contrasted with the functional one represented by the second example (Frame Relay interface). Since this distinction apparently didn't come across clearly, we can look at choosing some better words. First, though, as part of the PCIM Extensions work, we're planning to re-examine the question of whether PolicyRoles is defined correctly in the first place. Within the basic concept of roles / role combinations as a vehicle to allow policy rules to be associated with the resources to which they apply, there's room to ask whether a single property that combines functional and administrative categorization into one set of selectors is the best way to do it. A second question we need to examine is the relationship between policy roles and policy conditions, since both of them are true of a resource when a policy action is performed. For example, if it's true (long term) that an interface is Frame Relay, and it's true (right now) that the interface is congested, then some action to address the congestion will be performed. We had thought that there was a clear distinction between these long- term truths (represented by policy roles) and the more passing one (represented by policy conditions). But the initial work in the SNMPconf WG has started from the opposite viewpoint, that there is no relevant distinction between these two types of truths. Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com Yoram Ramberg @raleigh.ibm.com on 01/18/2001 07:01:19 AM Please respond to Yoram Ramberg Sent by: policy-owner@raleigh.ibm.com To: Mahadevan Iyer , Lee Rafalow , policy@raleigh.ibm.com cc: Subject: Re: PCIM Extensions [...snip...] > > > > 3. There needs to be a means to formally specify > > the > > > policy target(some overlap with the enforcement > > > domain) in the policyrule. I am looking for > > something > > > that is stronger than a policy condition variable > > > type. The logic that led to the creation of > > > "PolicyTimePeriodCondition", instead of adding a > > > policy condition variable type, could be applied > > out > > > here. > > > > What are the functions you're looking for that are > > not provided by > > PolicyRole? > >The PolicyRole from [PCIM] >======================= >Using the roles and role-combinations it received from >its PEPs as > indicated in the examples above, the PDP is able >to locate and > retrieve the policy rules that are relevant to >it. >======================== > >This is used to indicate a class of consumers e.g "all >policy enforcers that implement a firewall" should >pick up policies that have "firewall" mentioned in >their "PolicyRole" attribute. > >This does not address the problem of which of the 10 >firewalls in the network need to download the policy. > >This is how I read it, maybe you could tell me how the >PolicyRole is supposed to be used. [...snip...] Ah... Actually, my reading of this is slightly different. However, I have my problems with that text, which may be also the cause for the apparent misunderstanding. The following text from PCIM seems to imply what you said: "A role represents a functional characteristic or capability of a resource to which policies are applied. Examples of roles include Backbone interface, Frame Relay interface, BGP-capable router, web server, firewall, etc. " However, this is quite restrictive and unnecessary. Furthermore, it is not (IMO) the intention of the authors at all!. I think of a role as a mapping mechanism between policies and their targets. The above text represent an example where roles are used to map policy to objects that have some "functional characteristics" such as "Backbone interface", etc. However, these are just names, nothing more. "Frame Relay" may be a role name and the mapping of a given policy using this role *may be* interpreted by a (a very smart) PDP to frame relay interfaces. Another usage for role will be "VPN1-Ingress". This is, yet again, a name. How to assign this name to actual network elements is way outside the scope of PCIM. Within a given network, the 'VPN1-Ingress' role may be assigned to a bunch of interfaces determined to be serving in this role. Some of those may be actually frame relay while others may be ATM and maybe even virtual tunnel interfaces or what have you. No requirement is placed on a semantic mapping from the value of the role name to a member in a set of network elements carrying this role. This means that the mapping you desire is exactly what roles do. This also means that the text you're referring to in PCIM is somewhat misleading. Bottom line: The role *may* represent a functional characteristic. It may also represent more or less than a functional characteristic, say a functional characteristic and an administrative purpose. One more thing about this example: The text also says that the roles are received from the PEPs. This is true only when the PEPs and PDPs use COPS to inter-communicate. Notwithstanding the PEP/PDP terminology, this is not only the case. Indeed, this is still the minority case in the real world to date. I'm just saying this lest further confusion is created by that text. *Yoram From majordomo@raleigh.ibm.com Mon Jan 22 05:16:10 2001 Received: from fwns1.raleigh.ibm.com ([204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA01196 for ; Mon, 22 Jan 2001 05:16:10 -0500 (EST) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id FAA17124; Mon, 22 Jan 2001 05:10:57 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id FAA26802; Mon, 22 Jan 2001 05:10:45 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA35748; Mon, 22 Jan 2001 04:42:20 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA24476; Mon, 22 Jan 2001 04:42:17 -0500 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id EAA26436 for ; Mon, 22 Jan 2001 04:42:16 -0500 Received: from web10501.mail.yahoo.com (web10501.mail.yahoo.com [216.136.130.151]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id EAA06840 for ; Mon, 22 Jan 2001 04:42:14 -0500 Message-Id: <20010122094214.86228.qmail@web10501.mail.yahoo.com> Received: from [198.206.187.100] by web10501.mail.yahoo.com; Mon, 22 Jan 2001 01:42:14 PST Date: Mon, 22 Jan 2001 01:42:14 -0800 (PST) From: Mahadevan Iyer Subject: Re: PCIM Extensions To: Robert Moore , Yoram Ramberg Cc: Lee Rafalow , policy@raleigh.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Mahadevan Iyer --- Robert Moore wrote: > Yoram is correct. The intent of roles / role > combinations > all along was to allow the values to provide > functional > categorization, or administrative categorization, or > both. I feel it would be important to standardize the policyTarget, since most external interactions (with PEP's, PDP's etc) will benefit from it. The policyTarget would map to a special kind of role as described later. > First, though, as part of the PCIM Extensions work, > we're > planning to re-examine the question of whether > PolicyRoles > is defined correctly in the first place. Within the > basic > concept of roles / role combinations as a vehicle to > allow > policy rules to be associated with the resources to > which > they apply, there's room to ask whether a single > property > that combines functional and administrative > categorization > into one set of selectors is the best way to do it. I would suggest that we further refine PolicyRoles into AdministrativeRole, FunctionalRole and EnforcementRole. If Roles are going away then the replacement could provide the equivalent refinement. The PolicyTarget could map to the EnforcementRole. > A second question we need to examine is the > relationship > between policy roles and policy conditions, since > both of > them are true of a resource when a policy action is > performed. For example, if it's true (long term) > that an > interface is Frame Relay, and it's true (right now) > that the interface is congested, then some action to > address the congestion will be performed. We had > thought > that there was a clear distinction between these > long- > term truths (represented by policy roles) and the > more > passing one (represented by policy conditions). But > the > initial work in the SNMPconf WG has started from the > opposite viewpoint, that there is no relevant > distinction > between these two types of truths. I don't see the issue here, looks like the (condition + role) should handle the combinations supported by the work in the SNMPconf WG. Thanks __________________________________________________ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/ From majordomo@raleigh.ibm.com Mon Jan 22 07:41:52 2001 Received: from fwns1.raleigh.ibm.com ([204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA02661 for ; Mon, 22 Jan 2001 07:41:52 -0500 (EST) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id HAA21360; Mon, 22 Jan 2001 07:36:10 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id HAA26722; Mon, 22 Jan 2001 07:36:08 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA16190; Mon, 22 Jan 2001 07:14:06 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA39734; Mon, 22 Jan 2001 07:14:03 -0500 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id HAA05708; Mon, 22 Jan 2001 07:14:03 -0500 Received: from cisco.com (csi-admin1.cisco.com [144.254.91.12]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id HAA21500; Mon, 22 Jan 2001 07:13:59 -0500 Received: from yramberg-8000.cisco.com (telaviv3-dhcp164.cisco.com [144.254.93.102]) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id OAA01944; Mon, 22 Jan 2001 14:13:24 +0200 (IST) Message-Id: <4.3.2.7.2.20010122135204.02f95400@csi-admin1.cisco.com> X-Sender: yramberg@csi-admin1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 22 Jan 2001 14:13:42 +0200 To: Mahadevan Iyer , Robert Moore From: Yoram Ramberg Subject: Re: PCIM Extensions Cc: Lee Rafalow , policy@raleigh.ibm.com In-Reply-To: <20010122094214.86228.qmail@web10501.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Yoram Ramberg Inline. *Yoram At 01:42 AM 1/22/01 -0800, Mahadevan Iyer wrote: >--- Robert Moore wrote: > > Yoram is correct. The intent of roles / role > > combinations > > all along was to allow the values to provide > > functional > > categorization, or administrative categorization, or > > both. > >I feel it would be important to standardize the >policyTarget, since most external interactions (with >PEP's, PDP's etc) will benefit from it. The >policyTarget would map to a special kind of role as >described later. Maybe. I think there might be an issue with this. Policy target is probably somewhat standardized in the network model. In DiffServ there is a notion of policy target although it might not be so termed. In COPS there's a notion of PEP. I'm sure IPSec and MPLS have their own concepts of policy target. If I were to approach this from an information modelling angle within the Policy WG, I'd take this approach: First, of course, I'd construct an argument to justify an inclusion of such work in the WG's assignment list... the charter may need to be revised to explicitly specify a deliverable for this. Now, a policy target may end up being an object with some policy capabilities. Policy capabilities are tricky to model and must be done so that specific domain policy targets can be modeled as a derivative of the "core" policy target model. Interesting. Maybe this will lead to the long awaited QoS capabilities info model... > > First, though, as part of the PCIM Extensions work, > > we're > > planning to re-examine the question of whether > > PolicyRoles > > is defined correctly in the first place. Within the > > basic > > concept of roles / role combinations as a vehicle to > > allow > > policy rules to be associated with the resources to > > which > > they apply, there's room to ask whether a single > > property > > that combines functional and administrative > > categorization > > into one set of selectors is the best way to do it. > >I would suggest that we further refine PolicyRoles >into AdministrativeRole, FunctionalRole and >EnforcementRole. If Roles are going away then the >replacement could provide the equivalent refinement. > >The PolicyTarget could map to the EnforcementRole. See, this can lead to an over-design. While you're certainly aiming right, you're simply charting out a great example forr deriving useful mapping mechanisms using PCIM. I haven't looked, but maybe all you're asking for is allowing the PolicyRole to be a class that one could further refine by derivation. Now, about PolicyTarget being EnforcementRole -- as I said above, I have a hunch that this might develop into a richer concept deserving its own modeling efffort. > > > A second question we need to examine is the > > relationship > > between policy roles and policy conditions, since > > both of > > them are true of a resource when a policy action is > > performed. For example, if it's true (long term) > > that an > > interface is Frame Relay, and it's true (right now) > > that the interface is congested, then some action to > > address the congestion will be performed. We had > > thought > > that there was a clear distinction between these > > long- > > term truths (represented by policy roles) and the > > more > > passing one (represented by policy conditions). But > > the > > initial work in the SNMPconf WG has started from the > > opposite viewpoint, that there is no relevant > > distinction > > between these two types of truths. > >I don't see the issue here, looks like the (condition >+ role) should handle the combinations supported by >the work in the SNMPconf WG. > Frankly I don't think the difference between eternal truth and other truths is to be modeled at the level of core. You might then bring this ad absurdum by requiring a condition on this very property of the truth as in: "If is true AND the truth of Cond is eternal, then ..." clearly this is verging on the ridiculous. I suppose in some special cases the notion of an interface being Frame Relay is meaningful, but in general, a good abstraction of the policy target should remove the dependency on a target being Frame Relay. Rather, a class with set of capabilities/attributes (possibly called "FrameRelay") is a better approach as it is very refineable and extensible (is this a redundant sentence?). >Thanks Yea, me too. *Yoram >__________________________________________________ >Do You Yahoo!? >Yahoo! Auctions - Buy the things you want at great prices. >http://auctions.yahoo.com/ From majordomo@raleigh.ibm.com Mon Jan 22 08:10:13 2001 Received: from fwns2.raleigh.ibm.com ([204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03146 for ; Mon, 22 Jan 2001 08:10:13 -0500 (EST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id IAA22264; Mon, 22 Jan 2001 08:04:51 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id IAA25238; Mon, 22 Jan 2001 08:04:44 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA39956; Mon, 22 Jan 2001 07:46:40 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA33544; Mon, 22 Jan 2001 07:46:36 -0500 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id HAA27722 for ; Mon, 22 Jan 2001 07:46:37 -0500 Received: from ntx.netguard.co.il ([212.68.136.130]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id HAA23504 for ; Mon, 22 Jan 2001 07:46:34 -0500 Received: by ntx.netguard.co.il with Internet Mail Service (5.5.2650.21) id ; Mon, 22 Jan 2001 14:44:38 +0200 Message-Id: <6923C8A11386D311BAF300508B0A972764417D@ntx.netguard.co.il> From: Sagit Buchnik To: "'policy@raleigh.ibm.com'" Subject: FW: The benefit of using CIM Application Model 2.5 Date: Mon, 22 Jan 2001 14:44:37 +0200 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08471.149DCA30" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Sagit Buchnik This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C08471.149DCA30 Content-Type: text/plain; charset="ISO-8859-1" What can I benefit from using the CIM Application Model, for representing Elements like Firewalls and VPNs, which all I am interested in is their Name, Version Number, Manufactorer and there is no relevance about their inside structure of Features. Furthermore, I don't care about their Life cycle states and checks. But I Plan on using the CIM policy Model. Thanks in advance, Regards, Sagit Buchnik Software Engineer NetGuard Ltd. Tel: 972 66 44 98 04 E-Mail: sagit_b@netguard.co.il Web Site: www.netguard.com __________________________________________________________ NetGuard. The Key to Productive Security. _________________________________________________________ ------_=_NextPart_001_01C08471.149DCA30 Content-Type: text/html; charset="ISO-8859-1" FW: The benefit of using CIM Application Model 2.5

What can I benefit from using the CIM Application Model,
for representing Elements like Firewalls and VPNs, which all I am interested in is
their Name, Version Number, Manufactorer and there is no relevance about their inside structure of Features.
Furthermore, I don't care about their Life cycle states and checks.
But I Plan on using the CIM policy Model.
Thanks in advance,

Regards,
Sagit Buchnik
Software Engineer
NetGuard Ltd.
Tel: 972 66 44 98 04
E-Mail: sagit_b@netguard.co.il
Web Site: www.netguard.com
__________________________________________________________
NetGuard. The Key to Productive Security.
_________________________________________________________

------_=_NextPart_001_01C08471.149DCA30-- From majordomo@raleigh.ibm.com Mon Jan 22 08:28:11 2001 Received: from fwns1.raleigh.ibm.com ([204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03489 for ; Mon, 22 Jan 2001 08:28:11 -0500 (EST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id IAA20506; Mon, 22 Jan 2001 08:22:36 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id IAA25092; Mon, 22 Jan 2001 08:22:34 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA26056; Mon, 22 Jan 2001 08:03:38 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA43408; Mon, 22 Jan 2001 08:03:31 -0500 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id IAA23332 for ; Mon, 22 Jan 2001 08:03:32 -0500 Received: from ntx.netguard.co.il ([212.68.136.130]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id IAA23446 for ; Mon, 22 Jan 2001 08:03:28 -0500 Received: by ntx.netguard.co.il with Internet Mail Service (5.5.2650.21) id ; Mon, 22 Jan 2001 15:01:32 +0200 Message-Id: <6923C8A11386D311BAF300508B0A972764417E@ntx.netguard.co.il> From: Sagit Buchnik To: "'policy@raleigh.ibm.com'" Subject: FW: The benefit of using CIM Application Model 2.5 Date: Mon, 22 Jan 2001 15:01:32 +0200 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08473.71745A10" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Sagit Buchnik This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C08473.71745A10 Content-Type: text/plain; charset="ISO-8859-1" Could you please direct me to where I can find examples of usage of the CIM Policy Model and the CIM Application Model? Thanks in advance, Regards, Sagit Buchnik Software Engineer NetGuard Ltd. Tel: 972 66 44 98 04 E-Mail: sagit_b@netguard.co.il Web Site: www.netguard.com __________________________________________________________ NetGuard. The Key to Productive Security. _________________________________________________________ ------_=_NextPart_001_01C08473.71745A10 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable FW: The benefit of using CIM Application Model 2.5

Could you please direct me to where I can find = examples of usage of the CIM Policy Model and the CIM Application = Model?
Thanks in advance,

Regards,
Sagit Buchnik
Software Engineer
NetGuard Ltd.
Tel: 972 66 44 98 04
E-Mail: sagit_b@netguard.co.il
Web Site: www.netguard.com
__________________________________________________________ =
NetGuard. The Key to Productive Security.
_________________________________________________________ =

------_=_NextPart_001_01C08473.71745A10-- From majordomo@raleigh.ibm.com Mon Jan 22 09:34:30 2001 Received: from fwns1.raleigh.ibm.com ([204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05302 for ; Mon, 22 Jan 2001 09:34:29 -0500 (EST) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id JAA32450; Mon, 22 Jan 2001 09:28:08 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA20704; Mon, 22 Jan 2001 09:28:07 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA33758; Mon, 22 Jan 2001 09:10:45 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA34262; Mon, 22 Jan 2001 09:10:42 -0500 Received: from lmr (dyn9-37-49-17.raleigh.ibm.com [9.37.49.17]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA20488; Mon, 22 Jan 2001 09:10:43 -0500 Message-Id: <004d01c0847c$d483ea40$11312509@raleigh.ibm.com> From: "Lee Rafalow" To: Cc: "Hilarie Orman" , "Luis Sanchez" References: <6923C8A11386D311BAF300508B0A972764417D@ntx.netguard.co.il> Subject: VPN Model (was: The benefit of using CIM Application Model 2.5) Date: Mon, 22 Jan 2001 09:08:42 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Lee Rafalow" Content-Transfer-Encoding: 7bit Sagit, I'm not sure why you're looking to the application model to represent elements of firewalls; the application model is currently a software installation model. Take a look at the CIM_Product class to see if it has what you're looking for to represent the product information. For VPN policy, take a look at the IPsec model (CIM_Network25_Add) which is the DMTF version of the work being done in the IPSP WG (the updated IETF doc is work in progress). It doesn't have everything needed to model a VPN, but it's a start. There had been talk about doing some work in the IETF to generalize the model to be a domain-level model but it's out of scope for IPSP and no one has taken the step to get a BOF started. IHTH. Lee ----- Original Message ----- From: "Sagit Buchnik" To: Sent: Monday, January 22, 2001 7:44 AM Subject: FW: The benefit of using CIM Application Model 2.5 > > What can I benefit from using the CIM Application Model, > for representing Elements like Firewalls and VPNs, which all I am > interested in is > their Name, Version Number, Manufactorer and there is no relevance about > their inside structure of Features. > Furthermore, I don't care about their Life cycle states and checks. > But I Plan on using the CIM policy Model. > Thanks in advance, > > Regards, > Sagit Buchnik > Software Engineer > NetGuard Ltd. > Tel: 972 66 44 98 04 > E-Mail: sagit_b@netguard.co.il > Web Site: www.netguard.com > __________________________________________________________ > NetGuard. The Key to Productive Security. > _________________________________________________________ > > From majordomo@raleigh.ibm.com Tue Jan 23 05:44:38 2001 Received: from fwns1.raleigh.ibm.com ([204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08212 for ; Tue, 23 Jan 2001 05:44:37 -0500 (EST) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id EAA24734; Tue, 23 Jan 2001 04:56:50 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id EAA25932; Tue, 23 Jan 2001 04:56:42 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA46436; Tue, 23 Jan 2001 04:33:52 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA48156; Tue, 23 Jan 2001 04:33:45 -0500 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id EAA25280 for ; Tue, 23 Jan 2001 04:33:51 -0500 Received: from web10513.mail.yahoo.com (web10513.mail.yahoo.com [216.136.172.145]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id EAA19700 for ; Tue, 23 Jan 2001 04:33:50 -0500 Message-Id: <20010123093349.35111.qmail@web10513.mail.yahoo.com> Received: from [198.206.187.100] by web10513.mail.yahoo.com; Tue, 23 Jan 2001 01:33:49 PST Date: Tue, 23 Jan 2001 01:33:49 -0800 (PST) From: Mahadevan Iyer Subject: Re: PCIM Extensions To: policy@raleigh.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Mahadevan Iyer --- Yoram Ramberg wrote: > that specific domain policy targets can be modeled > as a derivative of the > "core" policy target model. Nevermind "domain specific", what I am looking for is a commonly understood placeholder for policy target. If tying this to some thing bigger is going to slow things down(charter etc), then I would rather see a simple extension. > >I would suggest that we further refine PolicyRoles > >into AdministrativeRole, FunctionalRole and > >EnforcementRole. If Roles are going away then the > >replacement could provide the equivalent > refinement. > > > >The PolicyTarget could map to the EnforcementRole. > you're simply charting out a great example forr > deriving useful mapping > mechanisms using PCIM. I haven't looked, but maybe > all you're asking for is > allowing the PolicyRole to be a class that one could > further refine by > derivation. Precisely, this request has been addressed to the group working on PCIM extensions. Once again my request is that we standardize these extensions of the PolicyRole. Thanks __________________________________________________ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/ From majordomo@raleigh.ibm.com Thu Jan 25 16:16:08 2001 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09000 for ; Thu, 25 Jan 2001 16:16:07 -0500 (EST) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA17726; Thu, 25 Jan 2001 16:08:21 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id QAA25984; Thu, 25 Jan 2001 16:07:58 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA55978; Thu, 25 Jan 2001 15:29:53 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA35998; Thu, 25 Jan 2001 15:29:47 -0500 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id PAA27348 for ; Thu, 25 Jan 2001 15:29:51 -0500 Received: from dcn.infos.ru (dcn.infos.ru [195.209.228.109]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA22752 for ; Thu, 25 Jan 2001 15:29:40 -0500 Received: from advanced2 (unknown [213.172.17.250]) by dcn.infos.ru (Postfix) with SMTP id B307037EF8 for ; Thu, 25 Jan 2001 23:24:12 +0300 (MSK) From: "Andrew Mishchenko" To: Subject: Information models relations Date: Thu, 25 Jan 2001 23:29:50 +0300 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Andrew Mishchenko" Content-Transfer-Encoding: 7bit Hi, I have some questions left after weeks of reading I-Ds. 1. As I understood, PEP and PDP should work with the same PIB to be interoperable - or, at least, they should work with PIBs derived from the same base PIB. It seems to me that PIB defined by DiffServ WG is aimed to play this role. Thus, any implementation of the PEP that uses its own PIB will be not interoperable with PDP that uses PIB defined by DiffServ WG. Am I right? 2. It's reasonably clear to me how to specify QoS requirements by means of QOSPIM and how to specify QoS mechanisms by means of QOSDEVIM. But: a) I'm not sure how to map QoS requirements (supplied by an administrator and modeled by QOSPIM) to the QoS mechanisms definition modeled by QOSDEVIM. Are there any recommendations or thoughts on this subject? I believe it's possible to develop some algorithm for mapping, but is this left to the implementers? b) It looks difficult to map QOSDEVIM classes structure to the PIB classes structure (IMO, the information model defined in the QOSPIM is mapped to the PIB classes more easy). Are there any ideas on this? Or QOSDEVIM is not yet well-aligned with PIBs structure and implementers should avoid using it for now? c) Then, what information model should be used to represent QoS policy information in the repository? I think that QOSPIM MUST be used because it is used to specify QoS requirements. But should policies modeled by QOSPIM be translated to the policies modeled by QOSDEVIM at the time of policy creation or the translation should occur in the runtime? If I'm asking the questions the wrong way, may be you can give me a direction? Thanks, Andrey Mishchenko andrew@dcn.nord.nw.ru From majordomo@raleigh.ibm.com Fri Jan 26 18:30:14 2001 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24598 for ; Fri, 26 Jan 2001 18:30:13 -0500 (EST) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA21506; Fri, 26 Jan 2001 18:23:04 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id SAA20062; Fri, 26 Jan 2001 18:22:53 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA35476; Fri, 26 Jan 2001 17:55:54 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA57482; Fri, 26 Jan 2001 17:55:50 -0500 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id RAA37806 for ; Fri, 26 Jan 2001 17:55:56 -0500 Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA26268 for ; Fri, 26 Jan 2001 17:55:51 -0500 Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Fri, 26 Jan 2001 17:51:22 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id ; Fri, 26 Jan 2001 17:51:24 -0500 Message-Id: <28560036253BD41191A10000F8BCBD11841D9F@zcard00g.ca.nortel.com> From: "Mircea Pana" To: "'policy@raleigh.ibm.com'" Subject: semantics of Priority of PolicyRule Date: Fri, 26 Jan 2001 17:51:22 -0500 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C087EA.8123FBD0" X-Orig: Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Mircea Pana" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C087EA.8123FBD0 Content-Type: text/plain; charset="ISO-8859-1" Is PCIM intentionally ambiguous w.r.t. the usage of the Priority property of the PolicyRule class? In situations where multiple PolicyRules are applicable which one of the following scenarios does PCIM recommended one: 1. For each applicable(*) PolicyRule, in descending order of Priorities, the conditions are evaluated and, only for the first one that evaluates true, the actions are executed. 2. For each applicable(*) PolicyRule, in descending order of Priorities, the conditions are evaluated and, for all those that evaluate true, the actions are executed. (*) a PolicyRule is applicable if its PolicyRole matches the functional, admin etc. role of the PEP. Thanks, Mircea Pana ------_=_NextPart_001_01C087EA.8123FBD0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable semantics of Priority of PolicyRule

Is PCIM intentionally ambiguous w.r.t. the usage of = the Priority property of the PolicyRule class? In situations where = multiple PolicyRules are applicable which one of the following = scenarios does PCIM recommended one:

1. For each applicable(*) PolicyRule, in descending = order of Priorities, the conditions are evaluated and, only for the = first one that evaluates true, the actions are executed.

2. For each applicable(*) PolicyRule, in descending = order of Priorities, the conditions are evaluated and, for all those = that evaluate true, the actions are executed.

(*) a PolicyRule is applicable if its PolicyRole = matches the functional, admin etc. role of the PEP.

Thanks,
Mircea Pana      =       

------_=_NextPart_001_01C087EA.8123FBD0-- From majordomo@raleigh.ibm.com Mon Jan 29 10:15:45 2001 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03702 for ; Mon, 29 Jan 2001 10:15:45 -0500 (EST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA27228; Mon, 29 Jan 2001 10:08:24 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id KAA03560; Mon, 29 Jan 2001 10:08:08 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA45662; Mon, 29 Jan 2001 09:33:50 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA45650; Mon, 29 Jan 2001 09:33:46 -0500 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id JAA24988 for ; Mon, 29 Jan 2001 09:33:47 -0500 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.228.37]) by southrelay02.raleigh.ibm.com (8.11.1/NCO v4.95) with ESMTP id f0TEXjZ28692; Mon, 29 Jan 2001 09:33:46 -0500 Importance: Normal Subject: Re: semantics of Priority of PolicyRule To: "Mircea Pana" Cc: "'policy@raleigh.ibm.com'" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-Id: From: "Robert Moore" Date: Mon, 29 Jan 2001 09:39:32 -0500 X-Mimetrack: Serialize by Router on D04NM200/04/M/IBM(Release 5.0.6 |December 14, 2000) at 01/29/2001 09:33:45 AM Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Robert Moore" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA03702 Mircea, How about "unintentionally ambiguous"? What we were *trying* to say in PCIM is neither of your alternatives. The additional, ill-defined concept of conflicting policy rules also figures into the algorithm. The basic idea is that in the absence of conflicts, actions for all of the rules whose conditions evaluate to true are performed. When there are conflicts, however, the actions for the higher-priority conflicting rule are performed, and those for any lower-priority conflicting rules are not. You should be aware, though, that in the PCIM Extensions work currently going on, we're looking to clarify/modify these semantics. Based on some existing work in QPIM, we're thinking about eliminating policy conflicts from the algorithm altogether, and introducing a new property at the PolicyGroup level, to let the policy administrator specify which of your two ways of doing it he/she wants: perform the actions for the first matching PolicyRule, or perform them for all matching PolicyRules. For this and several other PCIM changes, stay tuned for a first PCIM Extensions I-D, which will be available by the -00 draft cutoff date of February 23. Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com "Mircea Pana" @raleigh.ibm.com on 01/26/2001 05:51:22 PM Please respond to "Mircea Pana" Sent by: policy-owner@raleigh.ibm.com To: "'policy@raleigh.ibm.com'" cc: Subject: semantics of Priority of PolicyRule Is PCIM intentionally ambiguous w.r.t. the usage of the Priority property of the PolicyRule class? In situations where multiple PolicyRules are applicable which one of the following scenarios does PCIM recommended one: 1. For each applicable(*) PolicyRule, in descending order of Priorities, the conditions are evaluated and, only for the first one that evaluates true, the actions are executed. 2. For each applicable(*) PolicyRule, in descending order of Priorities, the conditions are evaluated and, for all those that evaluate true, the actions are executed. (*) a PolicyRule is applicable if its PolicyRole matches the functional, admin etc. role of the PEP. Thanks, Mircea Pana From majordomo@raleigh.ibm.com Tue Jan 30 15:12:13 2001 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16912 for ; Tue, 30 Jan 2001 15:12:13 -0500 (EST) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA23424; Tue, 30 Jan 2001 15:04:09 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id PAA23086; Tue, 30 Jan 2001 15:04:08 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA50966; Tue, 30 Jan 2001 10:55:50 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AB45070; Tue, 30 Jan 2001 10:55:47 -0500 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA36190 for ; Tue, 30 Jan 2001 10:55:50 -0500 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.228.37]) by southrelay02.raleigh.ibm.com (8.11.1/NCO v4.95) with ESMTP id f0UFtma32314 for ; Tue, 30 Jan 2001 10:55:48 -0500 Importance: Normal Subject: Preliminary results from PCIMe technical meeting, 1/24/01 - 1/26/01 To: policy@raleigh.ibm.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-Id: From: "Robert Moore" Date: Tue, 30 Jan 2001 11:01:37 -0500 X-Mimetrack: Serialize by Router on D04NM200/04/M/IBM(Release 5.0.6 |December 14, 2000) at 01/30/2001 10:55:49 AM Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Robert Moore" A subset of the PCIM, QPIM, ICIM, and MQPIM (Policy Framework MPLS Information Model for QoS and TE) authors met last week, to begin work on the PCIM Extensions (PCIMe) draft. The goal was to take the "implementation" experience from the three submodels of PCIM, and determine what changes and extensions they suggested for the proposed-standard PCIM document (currently sitting in the RFC Editor's queue as draft-ietf-policy-core-info-model-08.txt). The following is the list of changes that we agreed to pursue documenting in the -00 version of the PCIMe draft. Rather than springing these changes cold on the WG at the I-D cutoff date, we'll provide a brief summary of them here. This is still work in progress for the people who attended last week's meeting, so these formulations of the issues may change. But here's a snapshot of where we stand right now. The following subsections provide a very brief overview of the changes to PCIM being proposed in PCIMe. 2.2.1. Changes to PolicyRepository Because of the potential for confusion with the Policy Framework component Policy Repository (from the four-box picture: Policy Management Tool, Policy Repository, PDP, PEP), it was determined that "PolicyRepository" is a bad name for the PCIM class representing a container of reusable policy elements. Thus the class PolicyRepository has been replaced with the class ReusablePolicyContainer. To accomplish this change, it was necessary to deprecate the PCIM class PolicyRepository and its three associations, and replace them with a new class ReusablePolicyContainer and new associations. As a separate change, the definition of a ReusablePolicyContainer was broadened, to allow it to contain any reusable policy elements. In PCIM, a PolicyRepository was allowed to contain only policy conditions and policy actions. 2.2.2. Additional Associations and Additional Reusable Elements The PolicyRuleInPolicyRule and PolicyGroupInPolicyRule associations were imported from QPIM. These associations make it possible to define larger "chunks" of reusable policy to place in a ReusablePolicyContainer. The PolicyRuleInPolicyRule association also introduces new semantics representing the contextual implications of having one PolicyRule executing within the scope of another PolicyRule. 2.2.3. CompoundPolicyConditions and CompoundPolicyActions The concept of a CompoundPolicyCondition was imported into PCIMe from QPIM, and broadened to include a parallel CompoundPolicyAction. In both cases the idea is to create reusable "chunks" of policy that can exist as named elements in a ReusablePolicyContainer. The "Compound" classes and their associations incorporate the condition and action semantics that PCIM defines at the PolicyRule level: DNF/CNF for conditions, and ordering for actions. Compound conditions and actions were defined to work with any component conditions and actions. In other words, while the components may be instances, respectively, of SimplePolicyCondition and SimplePolicyAction (discussed immediately below), they need not be. 2.2.4. Variables and Values The SimplePolicyCondition / PolicyVariable / PolicyValue structure was imported into PCIMe from QPIM. A list of PCIMe-level variables was defined, as was a list of PCIMe-level values. Other variables and values may, if necessary, be defined in submodels of PCIMe. A corresponding SimplePolicyAction / PolicyVariable / PolicyValue structure was also defined. While the semantics of a SimplePolicyCondition are "variable matches value", a SimplePolicyAction has the semantics "set variable to value". 2.2.5. Packet Filtering For packet filtering done in the context of a PolicyCondition, a set of PolicyVariables and PolicyValues were defined, corresponding to the fields in an IP packet header plus the most common Layer 2 frame header fields. It is expected that policy conditions that filter on these header fields will be expressed in terms of CompoundPolicyConditions built up from SimplePolicyConditions that use these variables and values. An additional PolicyVariable, PacketDirection, was also defined, to indicate whether a packet being filtered is traveling inbound or outbound on an interface. For packet filtering in other contexts (specifically, for the packet classifier filters modeled in QDDIM), these variables and values need not be used. Filter classes derived from the CIM FilterEntryBase class hierarchy may still be used in these contexts. 2.2.6. Priorities and Decision Strategies Drawing from both QPIM and ICIM, the priority property has been deprecated in PolicyRule, and placed instead on the associations PolicyRuleInPolicyGroup, PolicyGroupInPolicyGroup, PolicyGroupInPolicyRule, and PolicyRuleInPolicyRule. (Obvious question: would it be better to introduce a superclass PrioritizedPolicyComponent for these four associations, just to contain the priority property? The answer is probably "yes".) The QPIM rules for resolving relative priorities across nested PolicyGroups and PolicyRules have been incorporated into PCIMe as well. With the removal of the priority property from PolicyRule, a new modeling dependency has been introduced: in order to prioritize a PolicyRule relative to other PolicyRules, the rules must be placed in a PolicyGroup. In the absence of any clear, general criterion for detecting policy conflicts, the PCIM restriction stating that priorities are relevant only in the case of conflicts has been removed. In its place, a DecisionStrategy property has been added to PolicyGroup class, to allow the policy administrator to select one of two behaviors with respect to rule evaluation: either perform the actions for all PolicyRules whose conditions evaluate to TRUE, or perform the actions only for the highest- priority PolicyRule whose conditions evaluate to TRUE. The QPIM rules for applying decision strategies to a nested set of PolicyGroups and PolicyRules were also imported. The question of whether to require unique priority values for the PolicyRules in a PolicyGroup was raised and discussed, but the decision was to allow these values to collide within a PolicyGroup, to indicate "don't care". Submodels of PCIMe are free to add the restriction that priority values not collide within a PolicyGroup. 2.2.7. Policy Roles Policy roles were removed from PolicyRules (that is, the PolicyRoles property was deprecated there), and placed instead on PolicyGroups. For nested PolicyGroups, any roles associated with the outer PolicyGroup are automatically "inherited" by the nested PolicyGroup. Additional roles may be added at the level of the nested group, but inherited roles cannot be canceled or overridden there. It was also observed that there was no mechanism at all in PCIM for assigning roles to resources. For example, while it was possible to associate a PolicyRule with the role combination "FrameRelay&&WAN", there was no way to indicate which interfaces had this role combination. A new PolicyRole class was defined, representing the collection of resources associated with a particular role combination. The linkage between a PolicyGroup and a set of resources is then represented by having an instance of PolicyRole that shares its name with a role combination value for the PolicyGroup, and is associated with the set of resources having that role combination. If you have any comments on these proposed updates to PCIM, please post them to the mailing list. Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com