From subs-reminder@vpnc.org Mon Apr 1 21:53:39 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23581 for ; Mon, 1 Apr 2002 21:53:38 -0500 (EST) From: subs-reminder@vpnc.org Received: by above.proper.com (8.11.6/8.11.3) id g322rcY17107; Mon, 1 Apr 2002 18:53:38 -0800 (PST) Date: Mon, 1 Apr 2002 18:53:38 -0800 (PST) Message-Id: <200204020253.g322rcY17107@above.proper.com> To: ipsp-archive@ietf.org Subject: [[519592928]] Subscription to ipsec-policy for ipsp-archive@lists.ietf.org Greetings. This message is a periodic reminder that ipsp-archive@lists.ietf.org is subscribed to the ipsec-policy mailing list. There are two purposes for this message: - If this message is bounced by your mail server, I can remove you from the mailing list and reduce waste of bandwidth and resources. (If you are reading this message, it clearly didn't get bounced!) - Some people stay subscribed to mailing lists even though they do not want to because they do not know how to unsubscribe. If you want to stay subscribed to the ipsec-policy mailing list, you do not need to do anything. Feel free to delete this message. On the other hand, if you want to unsubscribe from this list, simply go to the following link: If for some reason you cannot go to that web site, you can also unsubscribe by email; however, doing so is not as likely to get you unsubscribed as the web site is. To unsubscribe using email, you can respond to this message and I will unsubscribe you by hand in the next few days. Again, this is not assured to work because your mail system may make it impossible for me to determine who you are or what you want to unsubscribe to. Alternatively, you can send a plain-text message to: ipsec-policy-request@vpnc.org with the single word unsubscribe in the body of the message. This last method assumes that the "From:" address in your mail is "ipsp-archive@lists.ietf.org". Again, using the web site above is more likely to work than this method (due to limitations in Majordomo, the mailing list software we currently use). If you have any questions, feel free to contact me. --Paul Hoffman, list administrator From owner-ipsec-policy@mail.vpnc.org Wed Apr 3 22:12:20 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23155 for ; Wed, 3 Apr 2002 22:12:19 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g342UgJ24246 for ipsec-policy-bks; Wed, 3 Apr 2002 18:30:42 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g342Uem24242 for ; Wed, 3 Apr 2002 18:30:40 -0800 (PST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g342UQV29730; Wed, 3 Apr 2002 18:30:26 -0800 (PST) Received: from janpc-home.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g342UcPb005512; Wed, 3 Apr 2002 18:30:38 -0800 (PST) Date: Wed, 3 Apr 2002 18:30:13 -0800 (PST) From: Jan Vilhuber To: Casey Carr cc: , IPSec Policy WG Subject: Re: FW: Dead peer detection In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 3 Apr 2002, Casey Carr wrote: > Sorry. I sent this to the IPSec Policy WG the first time by mistake. > > I think it more appropriate in the general IPSec WG. > > -----Original Message----- > From: Casey Carr [mailto:caseyc@cipheroptics.com] > Sent: Wednesday, April 03, 2002 2:24 PM > To: IPSec Policy WG > Subject: Dead peer detection > > > Is there an RFC or draft on standards track to deal with dead peer > detection? After spending some time reviewing the IPSec, IKE, ISAKMP RFCs I > have drawn the conclusion that there is not a "standard" way to implement > dead peer detection. Have I reached a valid conclusion? Are other IPSec > vendors implementing proprietary solutions? If so, have there been > interoperability issues? > > I reviewed draft-ietf-ipsec-dpd-00.txt. It appears to be a year old without > revisions which leads me to believe that it may not be widely accepted. > > It also appears from a statement in JFK that the authors regard this as an > implementation issue: > > "A second major reason for Phase II is dead peer detection. IPsec > gateways often need to know if the other end of a security association > is dead, both to free up resources and to avoid "black holes". > In JFK, this is done by noting the time of the last packet received. When we were designing the DPD mechanism published in the draft, we actually considered this. Given that media traffic can easily be unidirectional (UDP/RTP traffic needs no ack's), we didn't think this was appropriate, since you could go your whole life without a packet in the other direction (internet radio comes to mind, except of course that most of those run over tcp..). > A peer that wishes to elicit a packet may send a "ping". Such > hosts MAY decline any proposed security associations that do not > permit such "ping" packets." > The sense I get in the working group is that the key protocol should indeed have formalized key management functionality (deletes, informationals, DPD, etc). Using pings has its own set of problems, so we should formalize this all under the key management protocol (i.e. son of IKE). jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec-policy@mail.vpnc.org Fri Apr 5 22:09:36 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20061 for ; Fri, 5 Apr 2002 22:09:36 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g362Qf619321 for ipsec-policy-bks; Fri, 5 Apr 2002 18:26:41 -0800 (PST) Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g362Qdm19317 for ; Fri, 5 Apr 2002 18:26:39 -0800 (PST) Received: from study ([24.61.240.100]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020406022637.EQCF21252.rwcrmhc53.attbi.com@study>; Sat, 6 Apr 2002 02:26:37 +0000 Message-ID: <009801c1dd11$a70fd620$650a0a0a@ne.client2.attbi.com> From: "Walter Weiss" To: "John Schnizlein" Cc: , "DiffServ2" , References: <4.3.2.7.2.20020327164457.019cd2a8@diablo.cisco.com> Subject: Re: [Diffserv] Re: why i should like pibs Date: Fri, 5 Apr 2002 21:20: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.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John, Sorry for the late reply. I missed your posting. Comments follow inline. regards, -Walter ---------- [snip] > The fundamental problem with distributing policy to traffic-forwarding > devices rather than translating policy into configurations under the > constraints of the composition (topology) and capabilities of the > devices in the path of the traffic remains. It is essentially wishful > thinking that individual devices can determine the correct configuration > of their local parameters without the domain-wide information. I have > not been persuaded that the capability-exchange between the PEP and PDP > solves this problem. There are hints of importance of the domain-wide > context in DiffServ's per-domain behavior (PDB) specifications. > I can't speak for others but the capabilities aspects of COPS-PR have always troubled me although for slightly different reasons. It is my view that capabilities are abstractions of implementations. However, it is difficult to decide where to stop. It is fine to say that a router supports classification. But it is not that simple. A policy server (and I use the term very loosely :) would also like to know how many classifiers, whether ranges or lists are supported, and where classifiers can be placed in a datapath. There is far more complexity in representing capabilities than it appears. Therefore, my view of capabilities is that it is a convenient mechanism not for identifying the implementation, but for defining the hardware and software versioning that allows a policy server to implicitly know what configuration will and won't work. > It is even a mistake IMHO to invite network administrators to establish > policies their networks cannot deliver. Although consensus was never > reached on the architecture for policy networking, the insistence that > policy be independent of the devices and topology that started there > seems to persist under the surface of the COPS-PR development. > Since policies within the context of COPS-PR are specific to a given device, clearly the implication that COPS-PR provides network level policy functionality is erroneous. > My concerns about distributing un-interpreted policy appears to be > shared by the network operators who shared their view with people > soliciting "requirements for network configuration" when they say > they do not want policy, or even configuration, distributed to devices > until they know what it will do to the network. > Given the scope of application I am offering (binding of edge resource consumers to specific services), I would suggest that core operators would be unaffected and unaware of these configurations. > Response to particular points: > > At 04:50 PM 3/26/2002, Walter Weiss wrote: [snip] > >I would also like to consider this issue from a requirements perspective. In > >my view, we can divide operational needs into four areas: Stats Collection, > >Events, Static config and Dynamic config. > > This taxonomy of operational needs for network management is novel. > Instead of the 5 FCAPS categories, it creates 4, with a new distinction > in configuration that may or may not have value. It also seems that > this Dynamic Config has a lot in common with what has been supported in > RADIUS as user profiles. Why is this not better treated as a QoS case > of authorization? > We had private discussions along similar lines at the last IETF meeting. The challenge has always been that the RADIUS protocol has serious limitations in it's ability to support edge provisioning issues (security, QoS, Tunnels, etc.) Conversely, COPS PIBs, while offering more sophisticated provisioning capabilities have not adequately addressed the authentication and access management issues. The AccessBind PIB makes some strides towards addressing this, but it is by no means comprehensive. > >I would also like to reconsider Bert's points. First, I would agree that the > >level of interest in COPS-PR is relatively small. However, I would argue > >that this is because Dynamic Config is only starting to become important as > >mappings for QoS, Security, and Tunneling are coming to the forefront. > > Maybe we should see if this new category of Dynamic Config really develops > before standardizing it into existence. > It already has. There is just no standard for it. There are lots of devices (CMTSes, GGSNs, and BRAS products) that are using COPS, SNMP, and RADIUS in proprietary ways to support the functionality I have described. The 3GPP have agreed on COPS-PR because they have this very need. This is not about whether the category exists but what the IETF will do (if anything) to provide a standard for supporting it. > >Second, I disagree that there is overlap with PIBs. While the DiffServ PIB > >and MIB are nearly identical, this was done because it was assumed that they > >were both addressing the config space that CLI is so clearly dominating. In > >the absense of a common model for all config, I believe this was a mistake. > > Don't follow this. You think any correspondence in the data models for the > DiffServ application is a mistake without a "common model for all config"? > Wouldn't incremental steps be more practical? > I actually favor incremental models over comprehensive models. Comprehensive models are really complicated and have to consider many factors. Data models (MIBs, PIBs, MOFs, Schemas, etc.) represent behavioral interfaces. If the behavioral requirements are different for different parts of the network, different technologies, and different implementations, the model quickly turns into an excercise in boiling the ocean. My point was that the MIB and PIB were conceived to address provisioning of the core of the DiffServ network. Given the clear domination of CLI in this space, the model is not ideally suited for edge config either. > >Given the unique applicability of COPS-PR, PIBs should be defined > >specifically for this purpose and only this purpose. > > Which unique applicability of COPS-PR is this? The newly proposed > Dynamic Config? > Correct. > >On Bert's third point, > >I would argue that the investment in PIBs is far smaller than he suggests. > >Given the specific scope of applicability, PIBs would not be appropriate for > >most IETF activities involving failure events or static config (routing, > >transport and applications). Hence, the number of PIBs is relatively small. > >Further, I do not believe that any of the alternatives on the table can meet > >these requirements to the extent that COPS-PR can. > > > >I would agree with Juergen that what we have today is a hodge-podge of > >protocols and mechanisms for configuration management and little incentive > >for changing the situation. As such, I see two alternatives: > >1. We can use COPS-PR and restrict it specifically to the area that it > >addresses most effectively: dynamic config management (at the network edge). > >2. We can block progress on all config drafts/standards to motivate a > >solution to Juergen's larger issue of concerted participation in a single > >and uniform set of standards. > > No one has proposed to "block progress on all config drafts/standards" > up until this point. Way back in the Configuration Management BOF in > Washington, I thought Bert supported Experimental status as the best > way to explore the new ideas proposed with COPS-PR and PIBs. > Yes and in that same discussion, it was also agreed that if PIBs were put on an experimental track, SNMPCONF MIBs would also be put on a experimental track. As long as we consider the larger question (config) rather than looking at a specific instance of the question (PIBs) I am fine with any answer. For me at least, the question is not what should be done with PIBs, but what should be done with config in general. When we have answered the second question the first one becomes easy. In the mean time all config related standards (Policy Framework, writable MIBs, and PIBs) should be treated consistently until we sort out the first question. > >We could also block the advancement of COPS-PR. However, that prevents us > >from addressing the dynamic config space and does not advance an > >alternative. > > Bert's original suggestion of Experimental seems again the best way to > encourage use of the new ideas in COPS-PR. I have never seen him (or > Randy, for that matter) try to "block advancement". I believe Randy at least is still considering his position on this. However, Bert should be able to offer a pretty clear position on whether he is in favor of Experimental or Informational (which to me amounts to blocked advancement). From owner-ipsec-policy@mail.vpnc.org Thu Apr 11 13:20:00 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06776 for ; Thu, 11 Apr 2002 13:20:00 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g3BGrfw10217 for ipsec-policy-bks; Thu, 11 Apr 2002 09:53:41 -0700 (PDT) Received: from rebma.mikesoffice.com (adsl-63-195-146-66.dsl.scrm01.pacbell.net [63.195.146.66]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3BGrem10213 for ; Thu, 11 Apr 2002 09:53:40 -0700 (PDT) Received: (from baerm@localhost) by rebma.mikesoffice.com (8.11.6/8.11.6) id g3BGrfR14240; Thu, 11 Apr 2002 09:53:41 -0700 X-Authentication-Warning: rebma.mikesoffice.com: baerm set sender to baerm@mikesoffice.com using -f To: ipsec-policy@vpnc.org Subject: policy model Q, SARuleInPolicyGroup::GroupComponent From: Michael Baer Organization: NAI Labs Date: Thu, 11 Apr 2002 09:53:41 -0700 Message-ID: Lines: 51 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) XEmacs/21.4 (Common Lisp, ppc-yellowdog-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, In the policy model, 4.7.2 : >4.7. The Aggregation Class SARuleInPolicyGroup > > The class SARuleInPolicyGroup associates a SARule with the > IPsecPolicyGroup that contains it. The class definition for > SARuleInPolicyGroup is as follows: > > NAME SARuleInPolicyGroup > DESCRIPTION Associates a SARule with the IPsecPolicyGroup that > contains it. > DERIVED FROM PolicySetComponent (see [PCIME]) > ABSTRACT FALSE > PROPERTIES Priority (from PolicySetComponent) > GroupComponent [ref IPsecPolicyGroup [1..1]] > PartComponent [ref SARule [0..n]] > > Note: an implementation can easily partition the set of SARules > aggregated by a SARuleInPolicyGroup instance into one IKERule > instances subset and into one IPsecRule instances subset based on the > class type of the component instances (being either IKERule or > IPsecRule instances). > >4.7.1. The Property Priority > > For a description of this property, see [PCIME]. > >4.7.2. The Reference GroupComponent > > The property GroupComponent is inherited from PolicyRuleInPolicyGroup > and is overridden to refer to an IPsecPolicyGroup instance. The > [1..1] cardinality indicates that a SARule instance may be contained > in one and only one IPsecPolicyGroup instance (i.e., SARules are not > shared across IPsecPolicyGroups). The GroupComponent explicitly states that SARules are not sharable between IPsecPolicyGroups. I couldn't think of any reason for this restriction and it seems arbitrarily limiting. So, basically, I wanted to know what are the reasons for choosing a 1..1 cardinality here (as opposed to say, 0..n or 1..n)? thanks, Mike -- Michael Baer baerm@mikesoffice.com NAI Labs From owner-ipsec-policy@mail.vpnc.org Mon Apr 15 13:02:42 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27842 for ; Mon, 15 Apr 2002 13:02:41 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g3FGCLq26588 for ipsec-policy-bks; Mon, 15 Apr 2002 09:12:21 -0700 (PDT) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3FGCJm26581 for ; Mon, 15 Apr 2002 09:12:19 -0700 (PDT) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.38 2002/04/09 21:20:23 root Exp $) with ESMTP id g3FGDTD15803 for ; Mon, 15 Apr 2002 16:13:29 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.15 2002/04/01 17:51:48 root Exp $) with SMTP id g3FGAqQ29072 for ; Mon, 15 Apr 2002 16:10:52 GMT Received: from fmsmsx019.fm.intel.com ([132.233.42.130]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002041509112207328 ; Mon, 15 Apr 2002 09:11:22 -0700 Received: by fmsmsx019.fm.intel.com with Internet Mail Service (5.5.2653.19) id <2XMFXLSD>; Mon, 15 Apr 2002 09:12:18 -0700 Message-ID: <65D5A07B5098D511BDDA0002A508E64F048E7792@orsmsx110.jf.intel.com> From: "Sahita, Ravi" To: "'Randy Bush'" , rap@ops.ietf.org, diffserv@ietf.org Cc: ipsec-policy@vpnc.org Subject: RE: why i should like pibs Date: Mon, 15 Apr 2002 09:12:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Randy, Here's a link to our open-source implementation of a client side SDK for COPS. This link should provide you with more information related to the usefulness of PIBs. The SDK also provides source code for a SPPI (RFC3159) compliant PIB Compiler/Client Control Interface Generator that integrates into the SDK. The SDK is at: http://www.intel.com/labs/manage/cops/ Hopefully, this demonstrates industry commitment to deliver quality and readily available tools for easy PIB development. Regards, Ravi -----Original Message----- From: Randy Bush [mailto:randy@psg.com] Sent: Monday, March 18, 2002 6:13 AM To: rap@ops.ietf.org; diffserv@ietf.org Cc: ipsec-policy@vpnc.org Subject: why i should like pibs wearing my iesg hat but being just a stupid operator, i am trying to understand the pib/mib controversy. fyi, i currently use snmp heavily for monitoring devices on my network. i configure using large db-driven code and spew text-based cli to the devices. let's assume i want to take the leap to a binary, as opposed to textual, configuration language. i.e. for some reason(s) [which we will PLEASE NOT discuss here] i decide to move from pushing text-based cli configs out to pushing a binary format. hence, i would have to push my vendors to implement snmp/cops writes for all configuration aspects of all devices. this would be big cost for both me and for my vendors. why would cops/pibs be significantly better (remember it has to replace my current investment, so it can not be 'just as good') than snmp/mibs? randy From owner-ipsec-policy@mail.vpnc.org Fri Apr 19 12:17:14 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27262 for ; Fri, 19 Apr 2002 12:17:14 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3JFU1M27841 for ipsec-policy-bks; Fri, 19 Apr 2002 08:30:01 -0700 (PDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3JFTxb27825 for ; Fri, 19 Apr 2002 08:29:59 -0700 (PDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g3JFTruE131124; Fri, 19 Apr 2002 11:29:54 -0400 Received: from sifaka (sig-9-15-10-240.mts.ibm.com [9.15.10.240]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g3JFToV80632; Fri, 19 Apr 2002 11:29:51 -0400 Message-ID: <000301c1e7b7$0dec35a0$429af7a5@sifaka> Reply-To: "Lee Rafalow" From: "Lee Rafalow" To: , "Michael Baer" References: Subject: Re: policy model Q, SARuleInPolicyGroup::GroupComponent Date: Thu, 18 Apr 2002 18:38:22 -0400 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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Mike, If memory serves me well, it was just a simplification of the core model. The core model permits arbitrary reuse of conditions and actions in rules, rules|groups in rules|groups, etc. and we add to that structure a couple of associations that eventually get you to the interface(s) to which the rules apply. It's all quite workable if we have a need for the generality, but the authors agreed early on to the simplifications and no one challenged it. If there's a compelling reason to change it and Luis & Hilarie are ok including such a change in our editorial update, I don't have a problem with it. Jamie, I think Intel asked for this simplification; comments? ----- Original Message ----- From: "Michael Baer" To: Sent: Thursday, April 11, 2002 12:53 PM Subject: policy model Q, SARuleInPolicyGroup::GroupComponent > > Hi, > > In the policy model, 4.7.2 : > > >4.7. The Aggregation Class SARuleInPolicyGroup > > > > The class SARuleInPolicyGroup associates a SARule with the > > IPsecPolicyGroup that contains it. The class definition for > > SARuleInPolicyGroup is as follows: > > > > NAME SARuleInPolicyGroup > > DESCRIPTION Associates a SARule with the IPsecPolicyGroup that > > contains it. > > DERIVED FROM PolicySetComponent (see [PCIME]) > > ABSTRACT FALSE > > PROPERTIES Priority (from PolicySetComponent) > > GroupComponent [ref IPsecPolicyGroup [1..1]] > > PartComponent [ref SARule [0..n]] > > > > Note: an implementation can easily partition the set of SARules > > aggregated by a SARuleInPolicyGroup instance into one IKERule > > instances subset and into one IPsecRule instances subset based on the > > class type of the component instances (being either IKERule or > > IPsecRule instances). > > > >4.7.1. The Property Priority > > > > For a description of this property, see [PCIME]. > > > >4.7.2. The Reference GroupComponent > > > > The property GroupComponent is inherited from PolicyRuleInPolicyGroup > > and is overridden to refer to an IPsecPolicyGroup instance. The > > [1..1] cardinality indicates that a SARule instance may be contained > > in one and only one IPsecPolicyGroup instance (i.e., SARules are not > > shared across IPsecPolicyGroups). > > > The GroupComponent explicitly states that SARules are not sharable > between IPsecPolicyGroups. I couldn't think of any reason for this > restriction and it seems arbitrarily limiting. So, basically, I wanted > to know what are the reasons for choosing a 1..1 cardinality here (as > opposed to say, 0..n or 1..n)? > > thanks, > Mike > > -- > Michael Baer > baerm@mikesoffice.com > NAI Labs > From owner-ipsec-policy@mail.vpnc.org Fri Apr 19 13:06:40 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04564 for ; Fri, 19 Apr 2002 13:06:40 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3JGT5201758 for ipsec-policy-bks; Fri, 19 Apr 2002 09:29:05 -0700 (PDT) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3JGT4b01754 for ; Fri, 19 Apr 2002 09:29:04 -0700 (PDT) Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.39 2002/04/15 17:47:23 root Exp $) with ESMTP id g3JGSMt12983 for ; Fri, 19 Apr 2002 16:28:22 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by talaria.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.16 2002/04/15 17:47:00 root Exp $) with SMTP id g3JGUxa26703 for ; Fri, 19 Apr 2002 16:30:59 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002041909330907482 ; Fri, 19 Apr 2002 09:33:09 -0700 Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id <2LKB963T>; Fri, 19 Apr 2002 09:29:04 -0700 Message-ID: <86DB568235A8D511ABAC0002A5072CA501E925C0@orsmsx120.jf.intel.com> From: "Jason, Jamie" To: "Lortz, Victor" , "'Lee Rafalow'", "IPsec Policy (E-mail)" Subject: RE: policy model Q, SARuleInPolicyGroup::GroupComponent Date: Fri, 19 Apr 2002 09:29:02 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: If I recall correctly, Vic is correct. I think that since a rule's priority is now an attribute of the association between group and rule, there is not a harm in removing this restriction. However, I will leave it up to Luis and Hilarie to decide if it is okay to include this change in the minor edits necessary to move this document to last call. Jamie > -----Original Message----- > From: Lortz, Victor > Sent: Friday, April 19, 2002 9:05 AM > To: 'Lee Rafalow' > Cc: Jason, Jamie > Subject: RE: policy model Q, SARuleInPolicyGroup::GroupComponent > > > Lee, I think the cardinality was limited to 1 originally > because the priority of a given rule was scoped to the policy > to which it belonged. I'm not sure if the model has evolved > since then such that this is no longer important (I haven't > been following this closely). > > Regards, > Vic > > -----Original Message----- > From: Lee Rafalow [mailto:rafalow@watson.ibm.com] > Sent: Thursday, April 18, 2002 3:38 PM > To: ipsec-policy@vpnc.org; Michael Baer > Subject: Re: policy model Q, SARuleInPolicyGroup::GroupComponent > > > > Mike, If memory serves me well, it was just a simplification > of the core > model. The core model permits arbitrary reuse of conditions > and actions in > rules, rules|groups in rules|groups, etc. and we add to that > structure a > couple of associations that eventually get you to the > interface(s) to which > the rules apply. It's all quite workable if we have a need for the > generality, but the authors agreed early on to the > simplifications and no > one challenged it. > > If there's a compelling reason to change it and Luis & Hilarie are ok > including such a change in our editorial update, I don't have > a problem with > it. Jamie, I think Intel asked for this simplification; comments? > > > ----- Original Message ----- > From: "Michael Baer" > To: > Sent: Thursday, April 11, 2002 12:53 PM > Subject: policy model Q, SARuleInPolicyGroup::GroupComponent > > > > > > Hi, > > > > In the policy model, 4.7.2 : > > > > >4.7. The Aggregation Class SARuleInPolicyGroup > > > > > > The class SARuleInPolicyGroup associates a SARule with the > > > IPsecPolicyGroup that contains it. The class definition for > > > SARuleInPolicyGroup is as follows: > > > > > > NAME SARuleInPolicyGroup > > > DESCRIPTION Associates a SARule with the IPsecPolicyGroup that > > > contains it. > > > DERIVED FROM PolicySetComponent (see [PCIME]) > > > ABSTRACT FALSE > > > PROPERTIES Priority (from PolicySetComponent) > > > GroupComponent [ref IPsecPolicyGroup [1..1]] > > > PartComponent [ref SARule [0..n]] > > > > > > Note: an implementation can easily partition the set of SARules > > > aggregated by a SARuleInPolicyGroup instance into one IKERule > > > instances subset and into one IPsecRule instances > subset based on the > > > class type of the component instances (being either IKERule or > > > IPsecRule instances). > > > > > >4.7.1. The Property Priority > > > > > > For a description of this property, see [PCIME]. > > > > > >4.7.2. The Reference GroupComponent > > > > > > The property GroupComponent is inherited from > PolicyRuleInPolicyGroup > > > and is overridden to refer to an IPsecPolicyGroup instance. The > > > [1..1] cardinality indicates that a SARule instance may > be contained > > > in one and only one IPsecPolicyGroup instance (i.e., > SARules are not > > > shared across IPsecPolicyGroups). > > > > > > The GroupComponent explicitly states that SARules are not sharable > > between IPsecPolicyGroups. I couldn't think of any reason for this > > restriction and it seems arbitrarily limiting. So, > basically, I wanted > > to know what are the reasons for choosing a 1..1 > cardinality here (as > > opposed to say, 0..n or 1..n)? > > > > thanks, > > Mike > > > > -- > > Michael Baer > > baerm@mikesoffice.com > > NAI Labs > > > > From owner-ipsec-policy@mail.vpnc.org Fri Apr 19 13:13:36 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05275 for ; Fri, 19 Apr 2002 13:13:36 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g3JGccK02198 for ipsec-policy-bks; Fri, 19 Apr 2002 09:38:38 -0700 (PDT) Received: from wanderer.hardakers.net (adsl-64-165-72-146.dsl.scrm01.pacbell.net [64.165.72.146]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3JGcab02191 for ; Fri, 19 Apr 2002 09:38:36 -0700 (PDT) Received: (from hardaker@localhost) by wanderer.hardakers.net (8.11.6/8.11.6) id g3JGcYl01866; Fri, 19 Apr 2002 09:38:34 -0700 To: "Lee Rafalow" Cc: , "Michael Baer" Subject: Re: policy model Q, SARuleInPolicyGroup::GroupComponent References: <000301c1e7b7$0dec35a0$429af7a5@sifaka> From: Wes Hardaker Organization: Network Associates - NAI Labs X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Date: Fri, 19 Apr 2002 09:38:34 -0700 In-Reply-To: <000301c1e7b7$0dec35a0$429af7a5@sifaka> ("Lee Rafalow"'s message of "Thu, 18 Apr 2002 18:38:22 -0400") Message-ID: Lines: 19 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) XEmacs/21.5 (bamboo, i686-pc-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> On Thu, 18 Apr 2002 18:38:22 -0400, "Lee Rafalow" said: Lee> If there's a compelling reason to change it and Luis & Hilarie Lee> are ok including such a change in our editorial update, I don't Lee> have a problem with it. Jamie, I think Intel asked for this Lee> simplification; comments? I think it would be a good thing to do. Right now, nearly all the classes are fairly reusable (ie, actions, filters, conditions, etc) *except* rules which seems a bit odd. An example usage would be two different groups assigned to two different endpoints, but each should contain a specific rule after the endpoint-specific-rules had been ruled out. (I thought about trying to use the word "ruler" as well in that sentence, but it just didn't work). -- Wes Hardaker NAI Labs Network Associates From owner-ipsec-policy@mail.vpnc.org Thu Apr 25 08:22:20 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02800 for ; Thu, 25 Apr 2002 08:22:19 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3PBlYv20209 for ipsec-policy-bks; Thu, 25 Apr 2002 04:47:34 -0700 (PDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3PBlWa20205 for ; Thu, 25 Apr 2002 04:47:32 -0700 (PDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g3PBlQuE044480; Thu, 25 Apr 2002 07:47:26 -0400 Received: from sifaka (dyn9-27-16-228.raleigh.ibm.com [9.27.16.228]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g3PBlQ4124442; Thu, 25 Apr 2002 07:47:26 -0400 Message-ID: <002301c1ec4e$fc2bd5e0$e4101b09@sifaka> Reply-To: "Lee Rafalow" From: "Lee Rafalow" To: Cc: "Jason, Jamie" , "Lortz, Victor" References: <86DB568235A8D511ABAC0002A5072CA5034BD2AF@orsmsx120.jf.intel.com> Subject: Re: policy model Q, SARuleInPolicyGroup::GroupComponent Date: Thu, 25 Apr 2002 07:47:31 -0400 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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Victor remembers it differently. The model has moved on since then so if we think the restriction should be removed it wouldn't be hard to do so. ----- Original Message ----- From: "Lortz, Victor" To: "'Lee Rafalow'" Cc: "Jason, Jamie" Sent: Friday, April 19, 2002 12:04 PM Subject: RE: policy model Q, SARuleInPolicyGroup::GroupComponent > Lee, I think the cardinality was limited to 1 originally because the > priority of a given rule was scoped to the policy to which it belonged. I'm > not sure if the model has evolved since then such that this is no longer > important (I haven't been following this closely). > > Regards, > Vic > > -----Original Message----- > From: Lee Rafalow [mailto:rafalow@watson.ibm.com] > Sent: Thursday, April 18, 2002 3:38 PM > To: ipsec-policy@vpnc.org; Michael Baer > Subject: Re: policy model Q, SARuleInPolicyGroup::GroupComponent > > > > Mike, If memory serves me well, it was just a simplification of the core > model. The core model permits arbitrary reuse of conditions and actions in > rules, rules|groups in rules|groups, etc. and we add to that structure a > couple of associations that eventually get you to the interface(s) to which > the rules apply. It's all quite workable if we have a need for the > generality, but the authors agreed early on to the simplifications and no > one challenged it. > > If there's a compelling reason to change it and Luis & Hilarie are ok > including such a change in our editorial update, I don't have a problem with > it. Jamie, I think Intel asked for this simplification; comments? > > > ----- Original Message ----- > From: "Michael Baer" > To: > Sent: Thursday, April 11, 2002 12:53 PM > Subject: policy model Q, SARuleInPolicyGroup::GroupComponent > > > > > > Hi, > > > > In the policy model, 4.7.2 : > > > > >4.7. The Aggregation Class SARuleInPolicyGroup > > > > > > The class SARuleInPolicyGroup associates a SARule with the > > > IPsecPolicyGroup that contains it. The class definition for > > > SARuleInPolicyGroup is as follows: > > > > > > NAME SARuleInPolicyGroup > > > DESCRIPTION Associates a SARule with the IPsecPolicyGroup that > > > contains it. > > > DERIVED FROM PolicySetComponent (see [PCIME]) > > > ABSTRACT FALSE > > > PROPERTIES Priority (from PolicySetComponent) > > > GroupComponent [ref IPsecPolicyGroup [1..1]] > > > PartComponent [ref SARule [0..n]] > > > > > > Note: an implementation can easily partition the set of SARules > > > aggregated by a SARuleInPolicyGroup instance into one IKERule > > > instances subset and into one IPsecRule instances subset based on the > > > class type of the component instances (being either IKERule or > > > IPsecRule instances). > > > > > >4.7.1. The Property Priority > > > > > > For a description of this property, see [PCIME]. > > > > > >4.7.2. The Reference GroupComponent > > > > > > The property GroupComponent is inherited from PolicyRuleInPolicyGroup > > > and is overridden to refer to an IPsecPolicyGroup instance. The > > > [1..1] cardinality indicates that a SARule instance may be contained > > > in one and only one IPsecPolicyGroup instance (i.e., SARules are not > > > shared across IPsecPolicyGroups). > > > > > > The GroupComponent explicitly states that SARules are not sharable > > between IPsecPolicyGroups. I couldn't think of any reason for this > > restriction and it seems arbitrarily limiting. So, basically, I wanted > > to know what are the reasons for choosing a 1..1 cardinality here (as > > opposed to say, 0..n or 1..n)? > > > > thanks, > > Mike > > > > -- > > Michael Baer > > baerm@mikesoffice.com > > NAI Labs > > > >