From owner-ipsec-policy@mail.vpnc.org Tue May 1 13:02:48 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04019 for ; Tue, 1 May 2001 13:02:47 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id IAA13693 for ipsec-policy-bks; Tue, 1 May 2001 08:47:06 -0700 (PDT) Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA13684 for ; Tue, 1 May 2001 08:47:05 -0700 (PDT) Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.36 2001/04/18 16:16:02 root Exp $) with SMTP id PAA24039; Tue, 1 May 2001 15:46:48 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 01 May 2001 15:46:48 0000 (GMT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 May 2001 08:46:45 -0700 Message-ID: <794826DE8867D411BAB8009027AE9EB90AD0E652@FMSMSX38> From: "Jason, Jamie" To: "'Eric Vyncke'" Cc: "IPsec Policy (E-mail)" , "'rcharlet@redcreek.com'" , "'HORMAN@volera.com'" , "'wes@hardakers.net'" , "'Man.M.Li@nokia.com'" , "'lsanchez@megisto.com'" , "Lee Rafalow (E-mail)" Subject: RE: Conference Call Date: Tue, 1 May 2001 08:46:43 -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: My apologies. It is __Thursday, May 3__ at 8:00a PDT. I was in a rush when I fat fingered the date. Also thanks for posting an initial agenda. I was going to do that today. Jamie > -----Original Message----- > From: Eric Vyncke [mailto:evyncke@cisco.com] > Sent: Sunday, April 29, 2001 3:04 PM > To: Jason, Jamie > Cc: IPsec Policy (E-mail); 'rcharlet@redcreek.com'; > 'HORMAN@volera.com'; > 'wes@hardakers.net'; 'Man.M.Li@nokia.com'; 'lsanchez@megisto.com'; Lee > Rafalow (E-mail) > Subject: Re: Conference Call > > > Jamie, > > Is it Wednesday May 2nd (then I cannot attend) or Thursday > May 3rd (then I > can attend) ? > > I do appreciate the timing which is convenient for Europe ;-) > > Regarding the agenda, I guess it will be for the open points: > - use of granularity (the authors want to keep it like it is > in -02 for > simplicity sake) > - multiple actions: is it needed ? is it useful ? how to > implement it ? > (the authors have a current proposal that should be checked > by the WG) > - use of filters for dynamic ports negotiation (the authorq > want to keep > it like it is in -02 for simplicity sake and for RFC 2401 & > Co compliance) > - ... > > Regards > > -eric > > At 15:21 26/04/2001 -0700, Jason, Jamie wrote: > >The authors of the IPsec Policy Configuration Model would > like to have a > >conference call to work out issues that were brought up > during the IPSP WG > >meeting in Minneapolis. The conference call will be on > Thursday, May 2 at > >8:00 PDT. It is expected that the people in the cc: list > will be the ones > >most interested in participating, but it is open to the > entire WG. If you > >would like to participate, please email me directly so I can > get a count for > >when I shedule the conference call through our local IT > group. I'll post > >details about the call when I get them...unfortunately, I > don't think that > >our conference calls are toll-free. > > > >Jamie > > > >---------------------------------------------------------------- > >Jamie Jason email: jamie.jason@intel.com > >Intel Architecture Labs phone: 503-264-9531 > >2111 NE 25th Avenue fax: 503-264-9428 > >Hillsboro, OR 97124 > > > >"To give anything less than your best is to sacrifice the gift." > > - Steve Prefontaine > > > >All opinions expressed are: > >1. Entirely my own. > >2. Not necessarily shared by my employer. > >3. Unencumbered by the thought process. > >---------------------------------------------------------------- > > From owner-ipsec-policy@mail.vpnc.org Tue May 1 13:19:42 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04591 for ; Tue, 1 May 2001 13:19:41 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id JAA15741 for ipsec-policy-bks; Tue, 1 May 2001 09:00:34 -0700 (PDT) Received: from hypnos.cps.intel.com (hypnos.cps.intel.com [192.198.165.17]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA15736 for ; Tue, 1 May 2001 09:00:33 -0700 (PDT) Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203]) by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.36 2001/04/18 16:16:02 root Exp $) with SMTP id PAA22894; Tue, 1 May 2001 15:59:06 GMT Received: from fmsmsx19.fm.intel.com ([132.233.48.19]) by 132.233.48.203 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 01 May 2001 15:59:06 0000 (GMT) Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 May 2001 08:59:03 -0700 Message-ID: <794826DE8867D411BAB8009027AE9EB90AD0E654@FMSMSX38> From: "Jason, Jamie" To: "'Jon Saperia'" , Wes Hardaker Cc: "IPsec Policy (E-mail)" , "'rcharlet@redcreek.com'" , "'HORMAN@volera.com'" , "'Man.M.Li@nokia.com'" , "'lsanchez@megisto.com'" , "Lee Rafalow (E-mail)" , "Eric Vyncke (E-mail)" Subject: RE: Conference Call Date: Tue, 1 May 2001 08:58:59 -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: Apologies. I was trying to get out of the office in a hurry to catch a plane. Here is the proposed agenda I have - note that we are only discussing the open issues with the IPsec policy model draft. The hope of the authors is that we can drive these issues to closure as we would like to last call the draft at or before London IETF. Agenda: - multiple actions (not just as fallback) and see if the authors' proposed solution is adequate to meet the needs and conforms with RFC 2401 - granularity proposal put forward by Luis Sanchez - dynamic ports - filtering on other packet values besides 5-tuple (e.g., ICMP type) - how to progress in the face of PCIMe Jamie > -----Original Message----- > From: Jon Saperia [mailto:saperia@jdscons.com] > Sent: Sunday, April 29, 2001 5:14 AM > To: Wes Hardaker > Cc: Jason, Jamie; IPsec Policy (E-mail); 'rcharlet@redcreek.com'; > 'HORMAN@volera.com'; 'Man.M.Li@nokia.com'; 'lsanchez@megisto.com'; Lee > Rafalow (E-mail); Eric Vyncke (E-mail) > Subject: Re: Conference Call > > > > > I think that it would be good to have an agenda to help > decide whether > > this was a good thing to call in for or not. > > -- > > Wes Hardaker > > NAI Labs > > Network Associates > > Always a good idea. Given that I have not done (yet) at least > on of the > things I was assigned, one suggestion for an agenda topic would be a > discussion of the open issues and how we are proposing to resolve > them. My example is NOTIFICATIONS. They are obviously tied > to the rest > of the Module structure. > > Thanks, > /jon > -- > > Jon Saperia saperia@jdscons.com > Phone: 617-744-1079 > Fax: 617-249-0874 > http://www.jdscons.com/ > From owner-ipsec-policy@mail.vpnc.org Tue May 1 14:55:18 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07541 for ; Tue, 1 May 2001 14:55:17 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id KAA23970 for ipsec-policy-bks; Tue, 1 May 2001 10:36:51 -0700 (PDT) Received: from h0001027441c5.ne.mediaone.net (h0001027441c5.ne.mediaone.net [24.128.61.165]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA23964 for ; Tue, 1 May 2001 10:36:49 -0700 (PDT) Received: from europa-h0001027441c5.ne.mediaone.net ([192.168.20.40]) by h0001027441c5.ne.mediaone.net (8.9.3/8.8.7) with ESMTP id NAA01420; Tue, 1 May 2001 13:40:15 -0400 Received: from jdscons.com (localhost [127.0.0.1]) by europa-h0001027441c5.ne.mediaone.net (8.9.3+Sun/8.9.3) with ESMTP id NAA09958; Tue, 1 May 2001 13:34:27 -0400 (EDT) Message-Id: <200105011734.NAA09958@europa-h0001027441c5.ne.mediaone.net> To: "Jason, Jamie" cc: "'Eric Vyncke'" , "IPsec Policy (E-mail)" , "'rcharlet@redcreek.com'" , "'HORMAN@volera.com'" , "'wes@hardakers.net'" , "'Man.M.Li@nokia.com'" , "'lsanchez@megisto.com'" , "Lee Rafalow (E-mail)" Subject: Re: Conference Call From: Jon Saperia In-reply-to: Your message of Tue, 01 May 2001 08:46:43 -0700. <794826DE8867D411BAB8009027AE9EB90AD0E652@FMSMSX38> Date: Tue, 01 May 2001 13:34:27 -0400 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > My apologies. It is __Thursday, May 3__ at 8:00a PDT. I was in a rush when > I fat fingered the date. Also thanks for posting an initial agenda. I was > going to do that today. > > Jamie > I would like to put one other item on the agenda. I was going over the current draft again thinking about the NOTIFICATIONs to write. I am concerned that we do not have any fault or counter information in this MIB Module. To do policy correctly (I think) you need to know if it [the policy] is broken and how much of it is used. There is nothing in my reading of the charter that prohibits this. Thanks, /jon -- Jon Saperia saperia@jdscons.com Phone: 617-744-1079 Fax: 617-249-0874 http://www.jdscons.com/ From owner-ipsec-policy@mail.vpnc.org Tue May 1 16:18:35 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09403 for ; Tue, 1 May 2001 16:18:35 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA27896 for ipsec-policy-bks; Tue, 1 May 2001 12:00:48 -0700 (PDT) Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA27890 for ; Tue, 1 May 2001 12:00:46 -0700 (PDT) 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 PAA28838 for ; Tue, 1 May 2001 15:00:10 -0400 Received: from lmr (dyn9-37-49-197.raleigh.ibm.com [9.37.49.197]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id OAA27068 for ; Tue, 1 May 2001 14:59:59 -0400 Message-ID: <006901c0d270$617065a0$c5312509@raleigh.ibm.com> From: "Lee Rafalow" To: References: Subject: Re: group in group in MIB Date: Tue, 1 May 2001 14:55:56 -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 Wes, A few comments interspersed below...cheers. 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 ----- Original Message ----- From: "Wes Hardaker" To: Sent: Wednesday, April 25, 2001 7:16 PM Subject: group in group in MIB > Currently the IPSEC-POLICY-MIB doesn't support group-in-group. The > original definitions of the tables that Mike Baer and I came up with > (sitting in a coffee shop) had more tables than the current MIB has > and implemented group-in-group semantics. We then dropped the support > for it when writing the draft as it was decided it was too complex. > Then, in the Minneapolis meeting it was discussed again (in a wider > audience) and decided that it should be supported. So, now I'm > bringing it to the widest of the audiences (the mailing list) and we > need to decide what to do and whether or not to support group-in-group > semantics. > > Choices: > > 1) Leave it as is, where only rules can be inside groups. This would > deviate from the data model. The ICPM info model makes this optional. That is, a rule MUST be aggregated into one and only one group but a group MAY be aggregated into a 'parent' group. > > 2) Add a new table defining what a group is supposed to contain > (1=groups, 2=rules). And another table containing the groups in a > group if the type = 1. > > 3) merge the rules-in-groups/groups-in-groups table to be all one > table containing merely a list of "names" in side a group, and then > add one table like the first in #2 above that defined what a group > was supposed to contain. > > I'm not really happy with how the data model currently works, and it > makes this whole decision hard. As defined a group can contain *only* > a set of groups *or* a set of rules. This makes it impossible to > define a groupA that contains groupB, ruleC, groupD. ruleC, in this > case, would have to be put into a group of its own (which is just > silly). True (...not the silly part, but the restriction in the ICPM info model). I don't remember exactly where this restriction came from, but it was intended to simplify. It was done at the time when priority for a rule was expressed in the rule rather than in the aggregation and we defined our own way to do priority for groups since there wasn't one in PCIM. Our methodology has been adopted in PCIM extensions for both groups and rules. I suspect that was part of the complexity, but I also think it had something to do with the natural groupings, e.g., a group is made up of the phase 1 and phase 2 rules that are used together. But if, in fact, it doesn't simplify things, then I'm sure people will be open to changing it. > > Also, what is the difference between GroupComponent and PartComponent > in the current IPsecPolicyGroupInPolicyGroup object? The GroupComponent and PartComponent are simply the references to the aggregation pair: GroupComponent is the parent or containing instance and PartComponent is the child or contained instance. > It also makes no sense to me that the data model is defined such that > groups and rules can even exist with the same priority level. I don't > think "two ContainedGroups with the same precedence is undefined" is > correct. I think it should be simply illegal. They haven't been permitted to do so in the IPSP model for some time now and the PCIM extensions draft currently states that unique priority values are required in all models. The case for the non-unique priority values is that there are things that are simply independent of one another and therefore need no prioritization, but the requirement for deterministic behavior won in the end. > > To do this properly though, the priority shouldn't be associated with > the group itself, but with whatever contains it. IE, I'd like groupA > (above) to contain 1=groupB, 5=ruleC, 1000=groupD and still have a > second group optionally reorder them such that groupX contained > 1=groupB, 20=groupD, 800=ruleC (last two swapped in precedence). The way PCIM extensions discusses this topic is that the contents of a group assumes the relative priority of the group in its context. See section 4.5 of the PCIMe draft, http://www.ietf.org/internet-drafts/draft-ietf-policy-pcim-ext-01.txt, which largely reflects the way we've been handling priority in the ICPM draft for some time now. We only use the FirstMatching decision strategy. In the example below, A contains A1 and A2 with the context-specific priority 1 and 2, respectively, and so on. Priority is high-to-low. groupA | +--1--groupA1 | | | +----10-----ruleA1a | | | +----15-----ruleA1b | | | +----20-----ruleA1c | +--2--groupA2 | +-----6-----ruleA2a | +-----5-----ruleA2b | +-----4-----ruleA1c Note that ruleA1c appears in both groups with a different priority assigned in each context. The order of evaluation of the above set is: A2a, A2b, A1c (in its A2 context), A1c (in its A1 context), A1b and then A1a. IHTH. Lee From owner-ipsec-policy@mail.vpnc.org Tue May 1 17:12:29 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10384 for ; Tue, 1 May 2001 17:12:28 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id NAA29309 for ipsec-policy-bks; Tue, 1 May 2001 13:02:50 -0700 (PDT) Received: from cisco.com (brussels.cisco.com [144.254.15.68]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA29305 for ; Tue, 1 May 2001 13:02:49 -0700 (PDT) Received: from EVYNCKE-W2K.cisco.com (evyncke-isdn-home.cisco.com [10.49.1.170]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id WAA02292; Tue, 1 May 2001 22:01:45 +0200 (MET DST) Message-Id: <4.3.2.7.2.20010501215509.03faaae8@brussels.cisco.com> X-Sender: evyncke@brussels.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 01 May 2001 22:00:59 +0200 To: Jon Saperia From: Eric Vyncke Subject: Notifications (was Re: Conference Call ) Cc: "Jason, Jamie" , "IPsec Policy (E-mail)" , "'rcharlet@redcreek.com'" , "'HORMAN@volera.com'" , "'wes@hardakers.net'" , "'Man.M.Li@nokia.com'" , "'lsanchez@megisto.com'" , "Lee Rafalow (E-mail)" In-Reply-To: <200105011734.NAA09958@europa-h0001027441c5.ne.mediaone.net > References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 13:34 1/05/2001 -0400, Jon Saperia wrote: >I would like to put one other item on the agenda. I was going over the >current draft again thinking about the NOTIFICATIONs to write. I am >concerned that we do not have any fault or counter information in this >MIB Module. To do policy correctly (I think) you need to know if it [the >policy] is broken and how much of it is used. There is nothing in my >reading of the charter that prohibits this. Jon, Is your request about adding a setting in the configuration information model to specify: - which IKE notifications is the device assumed to send - what must be the behavior of the device when IKE notifications are received Regards -eric From owner-ipsec-policy@mail.vpnc.org Tue May 1 18:12:21 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11392 for ; Tue, 1 May 2001 18:12:21 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id NAA03011 for ipsec-policy-bks; Tue, 1 May 2001 13:55:51 -0700 (PDT) Received: from wanderer.hardakers.net (dns1.hardaker.davis.ca.us [168.150.190.1]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA03006 for ; Tue, 1 May 2001 13:55:49 -0700 (PDT) Received: (from hardaker@localhost) by wanderer.hardakers.net (8.11.2/8.11.2) id f41KtNu16167; Tue, 1 May 2001 13:55:23 -0700 X-Authentication-Warning: wanderer.hardakers.net: hardaker set sender to wes@hardakers.net using -f To: "Lee Rafalow" Cc: Subject: Re: group in group in MIB References: <006901c0d270$617065a0$c5312509@raleigh.ibm.com> From: Wes Hardaker X-URL: http://dcas.ucdavis.edu/~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: 01 May 2001 13:55:23 -0700 In-Reply-To: <006901c0d270$617065a0$c5312509@raleigh.ibm.com> ("Lee Rafalow"'s message of "Tue, 1 May 2001 14:55:56 -0400") Message-ID: Lines: 98 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.2 (Terspichore) 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 Tue, 1 May 2001 14:55:56 -0400, "Lee Rafalow" said: Lee> Wes, A few comments interspersed below...cheers. Thanks for responding. >> 1) Leave it as is, where only rules can be inside groups. This would >> deviate from the data model. Lee> The ICPM info model makes this optional. That is, a rule MUST be Lee> aggregated into one and only one group but a group MAY be Lee> aggregated into a 'parent' group. Right, but we decided at the Minneapolis meeting that it should be done anyway as it really isn't that hard to do, its just hard to do "nicely" and have it align with the data-model. >> I'm not really happy with how the data model currently works, and >> it makes this whole decision hard. As defined a group can contain >> *only* a set of groups *or* a set of rules. This makes it >> impossible to define a groupA that contains groupB, ruleC, groupD. >> ruleC, in this case, would have to be put into a group of its own >> (which is just silly). Lee> True (...not the silly part, but the restriction in the ICPM info Lee> model). It seems that every time I find something I don't like, its always our parent's fault... Lee> I don't remember exactly where this restriction came from, but it Lee> was intended to simplify. IMHO, it failed to do so and made it more complex (implementation and usage, not necessarily the definition itself). Lee> It was done at the time when priority for a rule was expressed in Lee> the rule rather than in the aggregation and we defined our own Lee> way to do priority for groups since there wasn't one in PCIM. Lee> Our methodology has been adopted in PCIM extensions for both Lee> groups and rules. I suspect that was part of the complexity, but Lee> I also think it had something to do with the natural groupings, Lee> e.g., a group is made up of the phase 1 and phase 2 rules that Lee> are used together. But if, in fact, it doesn't simplify things, Lee> then I'm sure people will be open to changing it. IMHO, I think it would be more simplistic to have a group contain both, with a (unique) priority assigned to each "member", be it a rule or a group. >> Also, what is the difference between GroupComponent and PartComponent >> in the current IPsecPolicyGroupInPolicyGroup object? Lee> The GroupComponent and PartComponent are simply the references to Lee> the aggregation pair: GroupComponent is the parent or containing Lee> instance and PartComponent is the child or contained instance. Ahh. The description clauses are a bit vague in this regard. >> It also makes no sense to me that the data model is defined such >> that groups and rules can even exist with the same priority level. >> I don't think "two ContainedGroups with the same precedence is >> undefined" is correct. I think it should be simply illegal. Lee> They haven't been permitted to do so in the IPSP model for some Lee> time now and the PCIM extensions draft currently states that Lee> unique priority values are required in all models. To quote section 4.5.3 of the -02 data model draft: NAME GroupPriority DESCRIPTION Specifies the rule priority to be set to all nested rules. SYNTAX unsigned 16-bit integer VALUE Any value between 1 and 2^16-1 inclusive. Lower values have higher precedence (i.e., 1 is the highest -------- see here -------------- precedence). The merging order of two ContainedGroups with the same precedence is undefined. -------- see here -------------- That text is the reason for my comment. I guess that text was missed in the last update? >> To do this properly though, the priority shouldn't be associated >> with the group itself, but with whatever contains it. Lee> The way PCIM extensions discusses this topic is that the contents Lee> of a group assumes the relative priority of the group in its Lee> context. Ahh... A hierarchical priority scheme, which works as well. Thanks for the description. -- Wes Hardaker NAI Labs Network Associates From owner-ipsec-policy@mail.vpnc.org Tue May 1 19:20:02 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12261 for ; Tue, 1 May 2001 19:20:01 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id PAA10167 for ipsec-policy-bks; Tue, 1 May 2001 15:16:07 -0700 (PDT) Received: from hypnos.cps.intel.com (hypnos.cps.intel.com [192.198.165.17]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA10160 for ; Tue, 1 May 2001 15:16:05 -0700 (PDT) Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203]) by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.36 2001/04/18 16:16:02 root Exp $) with SMTP id WAA28770; Tue, 1 May 2001 22:15:08 GMT Received: from fmsmsx19.fm.intel.com ([132.233.48.19]) by 132.233.48.203 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 01 May 2001 22:15:07 0000 (GMT) Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 May 2001 15:15:06 -0700 Message-ID: <794826DE8867D411BAB8009027AE9EB90AD0E661@FMSMSX38> From: "Jason, Jamie" To: "'Wes Hardaker'" , Lee Rafalow Cc: ipsec-policy@vpnc.org Subject: RE: group in group in MIB Date: Tue, 1 May 2001 15:14:57 -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: > Lee> True (...not the silly part, but the restriction in the ICPM info > Lee> model). > > It seems that every time I find something I don't like, its always our > parent's fault... That's an unfortunate side effect of the mandate that we derive the IPsec policy model from PCIM. We are happy with the things we like, but we are unhappy about the warts. We have tried to, within our power, mitigate the effect of the things we don't like. > -------- see here -------------- > precedence). The merging order of two ContainedGroups > with the same precedence is undefined. > -------- see here -------------- > > That text is the reason for my comment. I guess that text was missed > in the last update? True. I'll make a note that this text needs to be fixed for the next revision. Jamie From owner-ipsec-policy@mail.vpnc.org Wed May 2 06:10:43 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04667 for ; Wed, 2 May 2001 06:10:41 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id CAA29195 for ipsec-policy-bks; Wed, 2 May 2001 02:00:34 -0700 (PDT) Received: from smtp4.cluster.oleane.net (smtp4.cluster.oleane.net [195.25.12.62]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA29191 for ; Wed, 2 May 2001 02:00:33 -0700 (PDT) Received: from oleane (dyn-1-1-106.Vin.dialup.oleane.fr [195.25.4.106]) by smtp4.cluster.oleane.net with SMTP id f4290Ww22785 for ; Wed, 2 May 2001 11:00:32 +0200 (CEST) Message-ID: <01a201c0d2e6$6bb35600$8001a8c0@oleane.com> From: "Peter Lewis" To: Subject: IPsec Global Summit Date: Wed, 2 May 2001 11:01:05 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_019F_01C0D2F7.2EE839A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_019F_01C0D2F7.2EE839A0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello, The third edition of the IPsec Global Summit will be organised next = 23-26 October in Paris. A call for proposals is online at: http://www.upperside.fr/ipsec2001/ipsec01cfp.htm ------=_NextPart_000_019F_01C0D2F7.2EE839A0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hello,
The third edition of the IPsec Global Summit will be = organised=20 next 23-26 October in Paris.
A call for proposals is online at:
http://www.uppe= rside.fr/ipsec2001/ipsec01cfp.htm
 
 
------=_NextPart_000_019F_01C0D2F7.2EE839A0-- From owner-ipsec-policy@mail.vpnc.org Wed May 2 12:57:31 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17195 for ; Wed, 2 May 2001 12:57:30 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id IAA01211 for ipsec-policy-bks; Wed, 2 May 2001 08:37:53 -0700 (PDT) Received: from duval.se.mediaone.net (duval.se.mediaone.net [24.129.0.67]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA01206 for ; Wed, 2 May 2001 08:37:51 -0700 (PDT) Received: from [10.69.10.51] (rr-165-122-197.atl.mediaone.net [24.165.122.197]) by duval.se.mediaone.net (8.11.1/8.11.1) with ESMTP id f42Fbk514160 for ; Wed, 2 May 2001 11:37:47 -0400 (EDT) Mime-Version: 1.0 X-Sender: rks@freesnmp.com Message-Id: Date: Wed, 2 May 2001 11:40:15 -0400 To: ipsec-policy@vpnc.org From: Robert Story Subject: MIB TimeStamps Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Shouldn't all the xxx[Last]Changed TimeStamps in rows have a MAX-ACCESS of read-only? From owner-ipsec-policy@mail.vpnc.org Fri May 4 21:28:19 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA23373 for ; Fri, 4 May 2001 21:28:18 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id RAA06498 for ipsec-policy-bks; Fri, 4 May 2001 17:36:27 -0700 (PDT) Received: from longmail2.lboard.com ([63.109.116.89]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA06493 for ; Fri, 4 May 2001 17:36:25 -0700 (PDT) Received: by longmail2.lboard.com with Internet Mail Service (5.5.2650.21) id ; Fri, 4 May 2001 20:36:00 -0400 Message-ID: From: Ed Ellesson To: "'ipsec-policy@vpnc.org'" Cc: "'Hilarie Orman'" , "'Luis Sanchez'" , "Joel M. Halpern" , "'Wijnen, Bert (Bert)'" Subject: IPSP WG Notice: Policy Terminology Draft, Extended WG Last Call Date: Fri, 4 May 2001 20:35:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: IPSP WG: Our AD has asked us to inform your WG that this WG Last Call is going on in the Policy Framework WG. This is to give you a chance for review and comments, because the terminology is also meant to be used by your WG. Extended WG Last Call: This last call is hereby extended to end at CoB on Fri, May 18, 2001. The latest revision of the Terminology Draft is in the I-D repository. for your reference: http://www.ietf.org/internet-drafts/draft-ietf-policy-terminology-03.txt Please also note that the title is changing to be more descriptive: Terminology for Policy-Based Management This revision reflects all known issues and comments. This note extends the current working group last call, to two weeks from today, and is intended to bring forth any last issues. After such issues are resolved according to the working group consensus, we will be submitting this document to the IESG for publication as an informational RFC. We are also strongly suggesting that the comments/discussion be done to/on the policy fw wg mailing list... so that we have one archive to check later if needed. If you are not already subscribed to the policy framework mailing list: General Discussion: policy@raleigh.ibm.com To Subscribe: policy-request@raleigh.ibm.com In Body: subscribe Archive: ftp://ftp.ietf.org/ietf-mail-archive/policy Thank you, and we apologize if you receive more than one notice like this. Ed Ellesson, with Joel Halpern Co-chairs, Policy Framework Working Group From owner-ipsec-policy@mail.vpnc.org Wed May 9 12:13:51 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14441 for ; Wed, 9 May 2001 12:13:50 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id IAA20300 for ipsec-policy-bks; Wed, 9 May 2001 08:04:30 -0700 (PDT) Received: from Mail6.nc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA20296 for ; Wed, 9 May 2001 08:04:29 -0700 (PDT) Received: from casey ([66.26.63.121]) by Mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Wed, 9 May 2001 11:04:30 -0400 Reply-To: From: "Casey Carr" To: "IPSec Policy WG" Subject: IPSEC-POLICY-MIB - Negotiation actions Date: Wed, 9 May 2001 11:05:53 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I'm concerned about the apparent deviation from the IPSec Policy model that the IPSEC-POLICY-MIB has taken with regards to SANegotiatedActions. The NegotiationAction table contains the sanIKEActionName and sanIPsecActionName. It appears to me that the MIB intends for these names to be used to look-up an associated IKEAction and an associated IPSecAction for the NegotiatedAction. This implies a Has-A relationship where the model calls for an Is-A relationship. It appears to me that it not only breaks the model but requires that the both the IPSecAction and the IKEAction use the same values for the following attributes: sanMinimumLifetimeSeconds, sanMinimumLifetimeKB, sanRefreshThresholdSeconds, sanRefreshThresholdKB, sanIdleDurrationSeconds. Isn't this a bad idea? Wouldn't the end user want to be able to define these values much differently for the Phase 1 and Phase 2 SAs? I believe that it is necessary to change these table definitions based on the requirement of matching the IPSec Policy Model. I propose that the saNegotiationActionTable be removed and the appropriate parameters be copied into each of the IPSecAction and IKEAction tables. Another possible solution would be to have both the IPSecAction and the IKEAction tables AUGMENT the NegotationAction ( of course removing the IPSec and IKE action name objects). I'm not a big fan of augmented tables so I would vote for the first proposal. Casey From owner-ipsec-policy@mail.vpnc.org Wed May 9 14:29:44 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20578 for ; Wed, 9 May 2001 14:29:43 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id KAA03550 for ipsec-policy-bks; Wed, 9 May 2001 10:18:58 -0700 (PDT) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA03545 for ; Wed, 9 May 2001 10:18:57 -0700 (PDT) Received: by mail.redcreek.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 May 2001 10:18:50 -0700 Received: from redcreek.com (host186.redcreek.com [209.218.26.186]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHZ8BG39; Wed, 9 May 2001 10:18:47 -0700 From: Ricky Charlet To: caseycarr@usa.com Cc: IPSec Policy WG Message-ID: <3AF96FB1.97966E4F@redcreek.com> Date: Wed, 09 May 2001 10:26:25 -0600 Organization: Redcreek Communications X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: IPSEC-POLICY-MIB - Negotiation actions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thanks pondering.... Ricky Charlet Casey Carr wrote: > > I'm concerned about the apparent deviation from the IPSec Policy model that > the IPSEC-POLICY-MIB has taken with regards to SANegotiatedActions. > > The NegotiationAction table contains the sanIKEActionName and > sanIPsecActionName. It appears to me that the MIB intends for these names > to be used to look-up an associated IKEAction and an associated IPSecAction > for the NegotiatedAction. This implies a Has-A relationship where the model > calls for an Is-A relationship. It appears to me that it not only breaks > the model but requires that the both the IPSecAction and the IKEAction use > the same values for the following attributes: > sanMinimumLifetimeSeconds, sanMinimumLifetimeKB, > sanRefreshThresholdSeconds, sanRefreshThresholdKB, sanIdleDurrationSeconds. > Isn't this a bad idea? Wouldn't the end user want to be able to define > these values much differently for the Phase 1 and Phase 2 SAs? > > I believe that it is necessary to change these table definitions based on > the requirement of matching the IPSec Policy Model. I propose that the > saNegotiationActionTable be removed and the appropriate parameters be copied > into each of the IPSecAction and IKEAction tables. Another possible > solution would be to have both the IPSecAction and the IKEAction tables > AUGMENT the NegotationAction ( of course removing the IPSec and IKE action > name objects). I'm not a big fan of augmented tables so I would vote for > the first proposal. > > Casey -- Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec-policy@mail.vpnc.org Wed May 9 14:38:33 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20823 for ; Wed, 9 May 2001 14:38:32 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id KAA05251 for ipsec-policy-bks; Wed, 9 May 2001 10:51:33 -0700 (PDT) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA05247 for ; Wed, 9 May 2001 10:51:32 -0700 (PDT) Received: by mail.redcreek.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 May 2001 10:51:26 -0700 Received: from redcreek.com (host186.redcreek.com [209.218.26.186]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHZ8BGS3; Wed, 9 May 2001 10:51:23 -0700 From: Ricky Charlet To: caseycarr@usa.com Cc: IPSec Policy WG , Ricky Charlet Message-ID: <3AF97756.A8246854@redcreek.com> Date: Wed, 09 May 2001 10:59:02 -0600 Organization: Redcreek Communications X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: IPSEC-POLICY-MIB - Negotiation actions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Casey Carr wrote: > > I'm concerned about the apparent deviation from the IPSec Policy model that > the IPSEC-POLICY-MIB has taken with regards to SANegotiatedActions. > > The NegotiationAction table contains the sanIKEActionName and > sanIPsecActionName. It appears to me that the MIB intends for these names > to be used to look-up an associated IKEAction and an associated IPSecAction > for the NegotiatedAction. This implies a Has-A relationship where the model > calls for an Is-A relationship. That was not what we intended, but your interpretation of what we did (inspite of what we inteded) is entirely reasonable. We do need to change to remove the ambiguity. We intended that sanIKEActionName and sanIPsecActionName should be mutually exclusive in the SaNegotiationActionEntry and each should be matched with either a pgIKERuleName or pgIPsecRuleName respectively. We certianly needed to include text stating that requirement in the descriptions, our bad. But I am thinking that I like your proposal anyway ( that is... get rid of saNegotiaitonAction and just have IPsecActions and IKEActions (and move the common parameters into both of those tables. After another review of draft-ietf-ipsp-config-policy-model-02.txt, I note that is says: the class SANegotiationAction serves as the base class for IKE and IPsec actions that result in a IKE negotiation. Although the class is concrete, is MUST not be instantiated. (section 6.9) Hmmm... MUST not be instantiated, that is exactly what we did in the MIB and it led very directly to confusion. I'm almost willing to start modifying the text of the MIB, but I'd just like to survey for other opinions first. What to others feel like here? > It appears to me that it not only breaks > the model but requires that the both the IPSecAction and the IKEAction use > the same values for the following attributes: > sanMinimumLifetimeSeconds, sanMinimumLifetimeKB, > sanRefreshThresholdSeconds, sanRefreshThresholdKB, sanIdleDurrationSeconds. > Isn't this a bad idea? Wouldn't the end user want to be able to define > these values much differently for the Phase 1 and Phase 2 SAs? Yes, users will certianly want that adminstrative capability. Both the model and our mib allow for it. Its just that our MIB was highly ambigious in this area.... A problem that needs fixing. > > I believe that it is necessary to change these table definitions based on > the requirement of matching the IPSec Policy Model. I propose that the > saNegotiationActionTable be removed and the appropriate parameters be copied > into each of the IPSecAction and IKEAction tables. Another possible > solution would be to have both the IPSecAction and the IKEAction tables > AUGMENT the NegotationAction ( of course removing the IPSec and IKE action > name objects). I'm not a big fan of augmented tables so I would vote for > the first proposal. > Although, wouldn't augmenting be a truer representation of an uninstantiated base class with two differing intantiated and inheriting classes? Maybe not... just wondering. -- Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec-policy@mail.vpnc.org Wed May 9 15:07:10 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21852 for ; Wed, 9 May 2001 15:07:09 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id LAA05968 for ipsec-policy-bks; Wed, 9 May 2001 11:05:38 -0700 (PDT) Received: from Mail6.nc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA05959 for ; Wed, 9 May 2001 11:05:36 -0700 (PDT) Received: from casey ([66.26.63.121]) by Mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Wed, 9 May 2001 14:05:38 -0400 Reply-To: From: "Casey Carr" To: "IPSec Policy WG" Subject: RE: IPSEC-POLICY-MIB - Negotiation actions Date: Wed, 9 May 2001 14:07:00 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3AF97756.A8246854@redcreek.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit See my comments at the end. Casey -----Original Message----- From: Ricky Charlet [mailto:rcharlet@redcreek.com] Sent: Wednesday, May 09, 2001 12:59 PM To: caseycarr@usa.com Cc: IPSec Policy WG; Ricky Charlet Subject: Re: IPSEC-POLICY-MIB - Negotiation actions Casey Carr wrote: > > I'm concerned about the apparent deviation from the IPSec Policy model that > the IPSEC-POLICY-MIB has taken with regards to SANegotiatedActions. > > The NegotiationAction table contains the sanIKEActionName and > sanIPsecActionName. It appears to me that the MIB intends for these names > to be used to look-up an associated IKEAction and an associated IPSecAction > for the NegotiatedAction. This implies a Has-A relationship where the model > calls for an Is-A relationship. That was not what we intended, but your interpretation of what we did (inspite of what we inteded) is entirely reasonable. We do need to change to remove the ambiguity. We intended that sanIKEActionName and sanIPsecActionName should be mutually exclusive in the SaNegotiationActionEntry and each should be matched with either a pgIKERuleName or pgIPsecRuleName respectively. We certianly needed to include text stating that requirement in the descriptions, our bad. But I am thinking that I like your proposal anyway ( that is... get rid of saNegotiaitonAction and just have IPsecActions and IKEActions (and move the common parameters into both of those tables. After another review of draft-ietf-ipsp-config-policy-model-02.txt, I note that is says: the class SANegotiationAction serves as the base class for IKE and IPsec actions that result in a IKE negotiation. Although the class is concrete, is MUST not be instantiated. (section 6.9) Hmmm... MUST not be instantiated, that is exactly what we did in the MIB and it led very directly to confusion. I'm almost willing to start modifying the text of the MIB, but I'd just like to survey for other opinions first. What to others feel like here? > It appears to me that it not only breaks > the model but requires that the both the IPSecAction and the IKEAction use > the same values for the following attributes: > sanMinimumLifetimeSeconds, sanMinimumLifetimeKB, > sanRefreshThresholdSeconds, sanRefreshThresholdKB, sanIdleDurrationSeconds. > Isn't this a bad idea? Wouldn't the end user want to be able to define > these values much differently for the Phase 1 and Phase 2 SAs? Yes, users will certianly want that adminstrative capability. Both the model and our mib allow for it. Its just that our MIB was highly ambigious in this area.... A problem that needs fixing. > > I believe that it is necessary to change these table definitions based on > the requirement of matching the IPSec Policy Model. I propose that the > saNegotiationActionTable be removed and the appropriate parameters be copied > into each of the IPSecAction and IKEAction tables. Another possible > solution would be to have both the IPSecAction and the IKEAction tables > AUGMENT the NegotationAction ( of course removing the IPSec and IKE action > name objects). I'm not a big fan of augmented tables so I would vote for > the first proposal. > Although, wouldn't augmenting be a truer representation of an uninstantiated base class with two differing intantiated and inheriting classes? Maybe not... just wondering. Yes it would be more accurate. I'm not an SMI expert, but does it support designing a table definition that has to be AUGMENTed in order to have an instantiated row? I.E. Does can SMI support the concept of an abstract base class? If SMI supports it, maybe you could omit a RowStatus in the base table and but have one in each of the tables that AUGMENT it. -- Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec-policy@mail.vpnc.org Wed May 9 15:19:25 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22159 for ; Wed, 9 May 2001 15:19:24 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id LAA06540 for ipsec-policy-bks; Wed, 9 May 2001 11:24:51 -0700 (PDT) Received: from Mail6.nc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA06536 for ; Wed, 9 May 2001 11:24:50 -0700 (PDT) Received: from casey ([66.26.63.121]) by Mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Wed, 9 May 2001 14:24:52 -0400 Reply-To: From: "Casey Carr" To: "IPSec Policy WG" Subject: IPSEC-POLICY-MIB - ContainedProposals Date: Wed, 9 May 2001 14:26:14 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit It does not appear that the MIB fully supports "ContainedProposal" aggregation defined in the IPSec policy model. This aggregation is defines as a "many-to-many" relationship. The attribute ikeProposalName in the ikeActionTable and the ipsecProposalName in the ipsecActionTable are defined as a string and the description indicates that it refers to a single entry in the corresponding proposal table. Did I miss something? Casey From owner-ipsec-policy@mail.vpnc.org Wed May 9 17:27:50 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25615 for ; Wed, 9 May 2001 17:27:49 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id NAA15194 for ipsec-policy-bks; Wed, 9 May 2001 13:30:22 -0700 (PDT) Received: from wanderer.hardakers.net (IDENT:root@dns2.hardaker.davis.ca.us [168.150.190.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA15184 for ; Wed, 9 May 2001 13:30:20 -0700 (PDT) Received: (from hardaker@localhost) by wanderer.hardakers.net (8.11.2/8.11.2) id f49KU2v20436; Wed, 9 May 2001 13:30:02 -0700 X-Authentication-Warning: wanderer.hardakers.net: hardaker set sender to wes@hardakers.net using -f To: Cc: "IPSec Policy WG" Subject: Re: IPSEC-POLICY-MIB - Negotiation actions References: From: Wes Hardaker X-URL: http://dcas.ucdavis.edu/~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: 09 May 2001 13:30:00 -0700 In-Reply-To: ("Casey Carr"'s message of "Wed, 9 May 2001 14:07:00 -0400") Message-ID: Lines: 38 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.2 (Terspichore) 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, 9 May 2001 14:07:00 -0400, "Casey Carr" said: Casey> Although, wouldn't augmenting be a truer representation of an Casey> uninstantiated base class with two differing intantiated and Casey> inheriting classes? Maybe not... just wondering. Yes it would Casey> be more accurate. I'm not an SMI expert, but does it support Casey> designing a table definition that has to be AUGMENTed in order Casey> to have an instantiated row? I.E. Does can SMI support the Casey> concept of an abstract base class? If SMI supports it, maybe Casey> you could omit a RowStatus in the base table and but have one Casey> in each of the tables that AUGMENT it. Part of the problem here is that Mike and I came up with the initial table breakdown, but Ricky and Cliff wrote the tables in question so what Mike and I were thinking didn't get exactly mapped into reality. I have many minor "corrections" I'll propose (when I get the time, hopefully later this month, sigh) in this regard. The problem is basically one of reuse. The idea was the notification parameters that were common to both action sets should be defined in a single table such that reuse of the definition would be possible. IE, the table in question should have been "pointed to" by the other two action tables such that it would be a reference saying "see here for common parameters". Now, it doesn't make sense for all instances and this is what we need to determine. However, I'm admittedly opposed (from an admittedly idealistic standpoint) to taking the exact same set of paramaters and making them identical column sets in two other tables. Instead, we should use a pointer of some kind (whether that's via a string index (I think what was originally intended), or via a RowPointer, or via an AUGMENTS (IE, MIB-specific) style of inheritance. Make sense? -- Wes Hardaker NAI Labs Network Associates From owner-ipsec-policy@mail.vpnc.org Wed May 9 18:38:19 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27981 for ; Wed, 9 May 2001 18:38:19 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id OAA20396 for ipsec-policy-bks; Wed, 9 May 2001 14:47:31 -0700 (PDT) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA20388 for ; Wed, 9 May 2001 14:47:29 -0700 (PDT) Received: by mail.redcreek.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 May 2001 14:47:23 -0700 Received: from redcreek.com (host186.redcreek.com [209.218.26.186]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHZ8BHHG; Wed, 9 May 2001 14:47:20 -0700 From: Ricky Charlet To: Wes Hardaker Cc: caseycarr@usa.com, IPSec Policy WG Message-ID: <3AF9AEA0.A5EBE1B2@redcreek.com> Date: Wed, 09 May 2001 14:54:56 -0600 Organization: Redcreek Communications X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: IPSEC-POLICY-MIB - Negotiation actions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Wes Hardaker wrote: > > >>>>> On Wed, 9 May 2001 14:07:00 -0400, "Casey Carr" said: > > Casey> Although, wouldn't augmenting be a truer representation of an > Casey> uninstantiated base class with two differing intantiated and > Casey> inheriting classes? Maybe not... just wondering. Yes it would > Casey> be more accurate. I'm not an SMI expert, but does it support > Casey> designing a table definition that has to be AUGMENTed in order > Casey> to have an instantiated row? I.E. Does can SMI support the > Casey> concept of an abstract base class? If SMI supports it, maybe > Casey> you could omit a RowStatus in the base table and but have one > Casey> in each of the tables that AUGMENT it. > > Part of the problem here is that Mike and I came up with the initial > table breakdown, but Ricky and Cliff wrote the tables in question so > what Mike and I were thinking didn't get exactly mapped into reality. > I have many minor "corrections" I'll propose (when I get the time, > hopefully later this month, sigh) in this regard. > > The problem is basically one of reuse. The idea was the notification > parameters that were common to both action sets should be defined in a > single table such that reuse of the definition would be possible. > IE, the table in question should have been "pointed to" by the other > two action tables such that it would be a reference saying "see here > for common parameters". > > Now, it doesn't make sense for all instances and this is what we need > to determine. However, I'm admittedly opposed (from an admittedly > idealistic standpoint) to taking the exact same set of paramaters and > making them identical column sets in two other tables. Instead, we > should use a pointer of some kind (whether that's via a string index > (I think what was originally intended), or via a RowPointer, or via an > AUGMENTS (IE, MIB-specific) style of inheritance. > > Make sense? > -- > Wes Hardaker But as the tables stand today, the SANegotiationAction entries are not re-usable by several ike or ipsec actions. Each saNegotiationAction must point to only one IKEAction or one IPsecAction. So here comes just a brain-storm type idea (ie.. not well thought out) If We arranged our tables such that the actionName rowpointer in the actionsInRuleEntry pointed at either an Ike or an IPsec action and then the IKE/IPsec actions had a columb to point at saNegotiationAction.... then we could re-use common timout type parameters. -- Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec-policy@mail.vpnc.org Wed May 9 18:50:04 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28271 for ; Wed, 9 May 2001 18:50:03 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id OAA20791 for ipsec-policy-bks; Wed, 9 May 2001 14:49:36 -0700 (PDT) Received: from pavilion (a24b31n80client230.hawaii.rr.com [24.31.80.230]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA20774 for ; Wed, 9 May 2001 14:49:33 -0700 (PDT) Message-ID: <214092001539214129240@pavilion> X-EM-Version: 5, 0, 0, 19 X-EM-Registration: #01B0530810E603002D00 X-Priority: 3 X-MSMail-Priority: Normal From: "Mitchell" To: ipsec-policy@vpnc.org Subject: Business/Employment Opportunity Date: Wed, 9 May 2001 11:41:29 -1000 MIME-Version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id OAA20781 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Dear Friend: "Making over half million dollars every 4 to 5 months from your home for an investment of only $25 U.S. Dollars expense one time" THANKS TO THE COMPUTER AGE AND THE INTERNET! =============================================== BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR !! Before you say "Bull" , please read the following. This is the letter you have been hearing about on the news lately. Due to the popularity of this letter on the internet, a national weekly news program recently devoted an entire show to the investigation of this program described below , to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are "absolutely no laws prohibiting the participation in the program and if people can follow the simple instructions, they are bound to make some mega bucks with only $25 out of pocket cost". DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING BETTER THAN EVER. This is what one had to say: "Thanks to this profitable opportunity. I was approached many times before but each time I passed on it. I am so glad I finally joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received total $ 610,470.00 in 21 weeks, with money still coming in". Pam Hedland, Fort Lee, New Jersey. ------------------------------------------------------------------------- Here is another testimonial: "This program has been around for a long time but I never believed in it. But one day when I received this again in the mail I decided to gamble my $25 on it. I followed thesimple instructions and walaa ..... 3 weeks later the money started to come in. First month I only made $240.00 but the next 2 months after that I made a total of $290,000.00. So far, in the past 8 months by re-entering the program,I have made over $710,000.00 and I am playing it again. The key to success in this program is to follow the simple steps and NOT change anything ." More testimonials later but first, ****** PRINT THIS NOW FOR YOUR FUTURE REFERENCE ******* $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make at least $500,000 every 4 to 5 months easily and comfortably, please read the following...THEN READ IT AGAIN and AGAIN !!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL DREAMS WILL COME TRUE, GUARANTEED! INSTRUCTIONS: **** Order all 5 reports shown on the list below. **** For each report, send $5 CASH, THE NAME & NUMBER OF THE REPORT YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the person whose name appears ON THAT LIST next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mail problems. **** When you place your order, make sure you order each of the 5 reports. You will need all 5 reports so that you can save them on your computer and resell them. YOUR TOTAL COST $5 X 5 = $25.00. **** Within a few days you will receive, via e-mail, each of the 5 reports from these 5 different individuals. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. Also make a floppy of these reports and keep it on your desk in case something happen to your computer. ****.IMPORTANT - DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than what is instructed below in steps 1 through6 or you will loose out on majority of your profits. Once you understand the way this works, you will also see how it does not work if you change it. Remember, this method has been tested, and if you alter, it will NOT work!!! People have tried to put their friends/relatives names on all five thinking they could get all the money. But it does not work this way. Believe us, we all have tried to be greedy and then nothing happened. So Do Not try to change anything other than what is instructed. Because if you do, it will not work for you. Remember, honesty reaps the reward!!! 1.. After you have ordered all 5 reports, take this advertisement and REMOVE the name & address of the person in REPORT # 5. This person has made it through the cycle and is no doubt counting their fortune. 2.... Move the name & address in REPORT # 4 down TO REPORT # 5. 3.... Move the name & address in REPORT # 3 down TO REPORT # 4. 4.... Move the name & address in REPORT # 2 down TO REPORT # 3. 5.... Move the name & address in REPORT # 1 down TO REPORT # 2 6.... Insert YOUR name & address in the REPORT # 1 Position. PLEASE MAKE SURE you copy every name & address ACCURATELY ! ========================================================= Take this entire letter, with the modified list of names, and save it on your computer. DO NOT MAKE ANY OTHER CHANGES. Save this on a disk as well just in case if you loose any data. To assist you with marketing your business on the internet, the 5 reports you purchase will provide you with invaluable marketing information which includes how to send bulk e-mails legally, where to find thousands of free classified ads and much more. There are 2 Primary methods to get this venture going: METHOD # 1 : BY SENDING BULK E-MAIL LEGALLY ============================================ let's say that you decide to start small, just to see how it goes, and we will assume You and those involved send out only 5,000 e-mails each. Let's also assume that the mailing receive only a0.2% response (the response could be much better but lets just say it is only 0.2% . Also many people will send out hundreds of thousands e-mails instead of only 5,000 each). Continuing with this example, you send out only 5,000 e-mails. With a 0.2% response, that is only 10 orders for report # 1. Those 10 people responded by sending out 5,000 e-mail each for a total of 50,000. Out of those 50,000 e-mails only 0.2% responded with orders. That's = 100 people responded and ordered Report # 2. Those 100 people mail out 5,000 e-mails each for a total of 500,000 e-mails. The 0.2% response to that is 1000 orders for Report # 3. Those 1000 people send out 5,000 e-mails each for a total of 5 million e-mails sent out. The 0.2% response to that is 10,000 orders for Report # 4. Those 10,000 people send out 5,000 e-mails each for a total of 50,000,000 (50 million) e-mails. The 0.2% response to that is 100,000 orders for Report # 5. THAT'S 100,000 ORDERS TIMES $5 EACH = $500,000.00 (half million). Your total income in this example is: 1..... $50 + 2..... $500 + 3..... $5,000 + 4..... $50,000 + 5..... $500,000 ......... Grand Total = $555,550.00 NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE OUT THE WORST POSSIBLE RESPONSES AND NO MATTER HOW YOU CALCULATE IT, YOU WILL STILL MAKE A LOT OF MONEY ! ------------------------------------------------------------------------------ REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE ORDERING OUT OF 5,000 YOU MAILED TO. Dare to think for a moment what would happen if everyone, or half or even one 4th of those people mailed 100,000 e-mails each or more? There are over 250 million people on the internet worldwide and counting. Believe me, many people will do just that, and more! METHOD # 2 : BY PLACING FREE ADS ON THE INTERNET =================================================== Advertising on the net is very very inexpensive and there are hundreds of FREE places to advertise. Placing a lot of free adson the internet will easily get a larger response. We strongly suggest you start with Method # 1 and add METHOD # 2 as you go along. For every $5 you receive, all you must do is e-mail them the Report they ordered. That's it . Always provide same day service on all orders. This will guarantee that the e-mail they send out, with your name and address on it, will be prompt because they can not advertise until they receive the report. _____________________ AVAILABLE REPORTS_____________________ ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes: Always send $5 cash (U.S. CURRENCY) for each Report. Checks NOT accepted. Make sure the cash is concealed by wrapping it in at least 2 sheets of paper. On one of those sheets of paper, Write the NUMBER & the NAME of the Report you are ordering, YOUR E-MAIL ADDRESS and your name and postal address. PLACE YOUR ORDER FOR THESE REPORTS NOW : ============================================== REPORT #1, "The Insider's Guide to Sending Bulk E-mail on the Internet" ORDER REPORT #1 FROM: G. Donaldson P.O. Box 25884 Honolulu, Hawaii 96825-0884 don't forget to provide a permanent e-mail address in clear writing (better typed) to receive the reports. We had problems in delivery e-mails before!!! ============================================== REPORT #2 "The Insider's Guide to Advertising for Free on the Internet" ORDER REPORT #2 FROM: Vijay Paul C-291, Second Floor Defence Colony New Delhi - 110024 INDIA ============================================== REPORT #3 "The Secrets to Multilevel Marketing on the Internet" ORDER REPORT #3 FROM: JD P.O.Box 1114 Des Plaines, IL 60017 USA ============================================== REPORT #4 "How to become a Millionaire utilizing the Power of Multilevel Marketing and the Internet" ORDER REPORT #4 FROM: J Santi 833 Walter Ave Des Plaines, IL 60016 USA ============================================== REPORT #5 "How to SEND 1,000,000 e-mails for FREE" ORDER REPORT #5 FROM: Elaine Rix 138 Dundas Street, West, #243 Toronto, Ontario Canada M5G 1C3 ============================================== There are currently more than 250,000,000 people online worldwide! $$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$ Follow these guidelines to guarantee your success: If you do not receive at least 10 orders for Report #1 within 2 weeks, continue sending e-mails until you do. After you have received 10 orders, 2 to 3 weeks after that you should receive 100 orders or more for REPORT # 2. If you did not, continue advertising or sending e-mails until you do. Once you have received 100 or more orders for Report # 2, YOU CAN RELAX, because the system is already working for you , and the cash will continue to roll in ! THIS IS IMPORTANT TO REMEMBER : Every time your name is moved down on the list, you are placed in front of a different report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. IF YOU WANT TO GENERATE MORE INCOME SEND ANOTHER BATCH OF E-MAILS AND START THE WHOLE PROCESS AGAIN. There is NO LIMIT to the income you can generate from this business !!! ____________________________________________________ FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS PROGRAM: You have just received information that can give you financial freedom for the rest of your life, with NO RISK and JUST A LITTLE BIT OF EFFORT. You can make more money in the next few weeks and months than you have ever imagined. Follow the program EXACTLY AS INSTRUCTED. Do Not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report after you have put your name and address in Report #1 and moved others to #2...........# 5 as instructed above. One of the people you send this to may send out 100,000 or more e-mails and your name will be on everyone of them. Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU NOW ! ************** MORE TESTIMONIALS **************** "My name is Mitchell. My wife , Jody and I live in Chicago. I am an accountant with a major U.S. Corporation and I make pretty good money. When I received this program I grumbled to Jody about receiving ''junk mail''. I made fun of the whole thing, spouting my knowledge of the population and percentages involved. I ''knew'' it wouldn't work. Jody totally ignored my supposed intelligence and few days later she jumped in with both feet. I made merciless fun of her, and was ready to lay the old ''I told you so'' on her when the thing didn'twork. Well, the laugh was on me! Within 3 weeks she had received 50 responses. Within the next 45 days she had received a total of $ 147,200.00 all cash! I was shocked. I have joined Jody in her ''hobby''." Mitchell Wolf, Chicago, Illinois ------------------------------------------------------------ "Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back. I was surprised when I found my medium size post office box crammed with orders. I made $319,210.00 in the first 12 weeks. The nice thing about this deal is that it does not matter where people live. There simply isn't a better investment with a faster return and so big." Dan Sondstrom, Alberta, Canada ----------------------------------------------------------- "I had received this program before. I deleted it, but later I wondered if I should have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed again by someone else.........11 months passed then it luckily came again...... I did not delete this one! I made more than $490,000 on my first try and all the money came within 22 weeks". Susan De Suza, New York, N.Y. ---------------------------------------------------- "It really is a great opportunity to make relatively easy money with little cost to you. I followed the simple instructions carefully and within 10 days the money started to come in. My first month I made $ 20,560.00 and by the end of third month my total cash count was $ 362,840.00. Life is beautiful, Thanx to internet". Fred Dellaca, Westport, New Zealand ------------------------------------------------------------ ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO FINANCIAL FREEDOM ! ======================================================= If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection, Washington, D.C. Under Bill s.1618 TITLE III passed by the 105th US Congress this letter cannot be considered spam as long as the sender includes contact information and a method of removal. This is one time e-mail transmission. No request for removal is necessary. ------------------------------------------------------------ This message is sent in compliance of the new email Bill HR 1910. Under Bill HR 1910 passed by the 106th US Congress on May 24, 1999, this message cannot be considered Spam as long as we include the way to be removed. Per Section HR 1910, Please type "REMOVE" in the subject line and reply to this email. All removal requests are handled personally an immediately once received. From owner-ipsec-policy@mail.vpnc.org Wed May 9 18:51:03 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28298 for ; Wed, 9 May 2001 18:51:02 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id OAA20420 for ipsec-policy-bks; Wed, 9 May 2001 14:47:38 -0700 (PDT) Received: from Mail6.nc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA20414 for ; Wed, 9 May 2001 14:47:37 -0700 (PDT) Received: from casey ([66.26.63.121]) by Mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Wed, 9 May 2001 17:47:39 -0400 Reply-To: From: "Casey Carr" To: "IPSec Policy WG" Subject: IPSec Policy Model Date: Wed, 9 May 2001 17:49:01 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Looking for a pointer to the correct paragraph in the correct document for the following: I have been unable to locate the definition for the use of FilterInCondition and ConditionInRule. I believe that the original draft-ietf-ipsp-config-policy-model-00.txt (I no longer have a copy) described exactly how the filters were suppose to be used and how the conditions were supposed to be used. The FilterList definition in the draft-ietf-ipsp-config-policy-model-01.txt document defines "FilterList aggregates an ANDed set of filters" but I could not find a statement like this in the 02 draft. Presumably because the FilterList object was removed. How are multiple conditions supposed to be evaluated so that a single true/false results when a SARule has multiple conditions and each condition has multiple filters? I believe the original 00 draft covered this but I am unable to find this in the new draft or any of the DMTF documents. My assumption is that all filters are ANDed together (of course taking into account the "negated" attribute). If all filters evaluate to true then the condition is true. If this is the case, then "EntrySequence" attribute of the aggregation is meaningless. This same process would then be repeated for each condition in the rule and the results of each condition are ANDed together. Would someone please point me to the correct document to validate/correct my assumption? Casey From owner-ipsec-policy@mail.vpnc.org Wed May 9 20:26:32 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29825 for ; Wed, 9 May 2001 20:26:32 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id QAA28342 for ipsec-policy-bks; Wed, 9 May 2001 16:40:35 -0700 (PDT) Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA28338 for ; Wed, 9 May 2001 16:40:35 -0700 (PDT) Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.38 2001/05/09 12:49:45 root Exp $) with SMTP id XAA03973; Wed, 9 May 2001 23:40:27 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 09 May 2001 23:40:27 0000 (GMT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 May 2001 16:40:26 -0700 Message-ID: <794826DE8867D411BAB8009027AE9EB90AD0E6AC@FMSMSX38> From: "Jason, Jamie" To: "'caseycarr@usa.com'" , IPSec Policy WG Subject: RE: IPSec Policy Model Date: Wed, 9 May 2001 16:40:16 -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: I think that for the next version of the draft, we probably should put some verbage in it to explain how conditions and filters are combined. But, for the time being... Multiple conditions are grouped by the GroupNumber attribute in the association SAConditionInRule - this attribute is inherited from PolicyConditionInPolicyRule, which is defined in the Policy Core Information Model (PCIM). PolicyRule, which is also defined in PCIM, has an attribute ConditionListType. See pages 28 & 29 of RFC 3060 for an explanation of this. A short description is: - if the list type is Conjunctive Normal Form (CNF), then the individual conditions in a group are ORed and condition groups are ANDed - if the list type is Disjunctive Normal Form (DNF), then the individual conditions in a group are ANDed and the condition groups are ORed Note...that the individual conditions may be negated. As for FilterList, it can be found on page 110 in Appendix C of the draft and the appropriate assocation EntriesInFilterList can be found on page 112 in the same appendix. The association EntriesInFilterList has an attribute, EntrySequence, which is defined as follows: "The order of the Entry relative to all others in the FilterList. A value of zero indicates that all the Entries should be ANDed together. Use of the Sequence property should be consistent across the List. It is not valid to define some Entries as ANDed in the FilterList (Sequence=0) while other Entries have a non-zero Sequence number." So, specific filter entries can either be ANDed or ORed. Hope that this helps. Jamie > -----Original Message----- > From: Casey Carr [mailto:caseycarr@usa.com] > Sent: Wednesday, May 09, 2001 2:49 PM > To: IPSec Policy WG > Subject: IPSec Policy Model > > > Looking for a pointer to the correct paragraph in the correct > document for > the following: > > I have been unable to locate the definition for the use of > FilterInCondition > and ConditionInRule. I believe that the original > draft-ietf-ipsp-config-policy-model-00.txt (I no longer have a copy) > described exactly how the filters were suppose to be used and how the > conditions were supposed to be used. The FilterList definition in the > draft-ietf-ipsp-config-policy-model-01.txt document defines > "FilterList > aggregates an ANDed set of filters" but I could not find a > statement like > this in the 02 draft. Presumably because the FilterList > object was removed. > > How are multiple conditions supposed to be evaluated so that a single > true/false results when a SARule has multiple conditions and > each condition > has multiple filters? I believe the original 00 draft > covered this but I am > unable to find this in the new draft or any of the DMTF documents. > > My assumption is that all filters are ANDed together (of > course taking into > account the "negated" attribute). If all filters evaluate to > true then the > condition is true. If this is the case, then "EntrySequence" > attribute of > the aggregation is meaningless. This same process would then > be repeated > for each condition in the rule and the results of each > condition are ANDed > together. > > Would someone please point me to the correct document to > validate/correct my > assumption? > > Casey > > From owner-ipsec-policy@mail.vpnc.org Wed May 9 20:29:06 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29869 for ; Wed, 9 May 2001 20:29:05 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id QAA26738 for ipsec-policy-bks; Wed, 9 May 2001 16:11:28 -0700 (PDT) Received: from mail.bicea.net.cn ([210.72.225.107]) by above.proper.com (8.9.3/8.9.3) with SMTP id QAA26704; Wed, 9 May 2001 16:11:11 -0700 (PDT) From: x-word@yahoo.com Received: from yahoo.com by mail.bicea.net.cn (SMI-8.6/SMI-SVR4) id HAA18673; Thu, 10 May 2001 07:01:55 +0800 Subject: Samples!!! Date: Wed, 9 May 2001 19:09:06 Message-Id: <837.341771.896898@yahoo.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id QAA26738 Content-Transfer-Encoding: quoted-printable WORD PUZZLE LOVERS=97 =20 =20 =20 =20 =20 =20 =20 =20 =20
=20

= ~ WORD=20 PUZZLE LOVERS ~

 
=20

Do you like double acrostics?

We=20 Want To Send You, a FREE Sample?
=20

 

  • Do you like them big with lots of meat= in them?=20

Our puzzles average well over 250 letters. Most= published=20 puzzles have around 200.

 

  • Do you like them really tough and chal= lenging?=20

We dig deep for our clues and once in a while = we stick=20 in a real off-the-wall doozer

 
=20
If you answer YES,= we have=20 the acrostics for you!
=20

 

 

* We offer a subscription service.<= /u> *
=20
=20

Our= Subscribers=20 receive five new mind-ben= ders every=20 month

and they are delivered right into their m= ailbox.

 
=20
Would You Like us to Send= You, a FREE=20 Sample?
=20
=20

Yes, I want=20 to learn more about your Puzzles= .

Please click below

=20
=20

I am not interested; take me off your lis= t.

Please click=20 below
=20 =20
  =20     =20  

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 
=20
=20

 

 

 

 =20

Our=20 puzzles, [word puzzles for the connoisseur] start out with a lite= rary=20 quote. We use all the letters in the quote and create clues. The = first=20 letters of the clues spell out the author=92s name and the title = of the=20 source of the quote. The letters of the clue words are numbered a= nd correspond=20 to squares in the accompanying grid. Filling in the grid reveals = the quotation.=20

Sound=20 complicated?

Well=20 maybe a little, but that's where the solving fun comes in.

 

 

  
=20
=20
=20

Yes,=20 I want to learn more about your Puzzles and=20 I want to receive a FREE = sample.

Please=20 click below

 =20
=20

 
=20
=20  
=20 =20
=20

Please=20 include your Name and US Mailing Address including Zip Code.

 
=20
=20

 

I=20 am not interested; take me off your list.

Please=20 click below

  
=20
=20  

 

 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0   =20

From owner-ipsec-policy@mail.vpnc.org Thu May 10 01:26:35 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA07771 for ; Thu, 10 May 2001 01:26:35 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id VAA07189 for ipsec-policy-bks; Wed, 9 May 2001 21:39:09 -0700 (PDT) Received: from hebe.or.intel.com (jffdns02.or.intel.com [134.134.248.4]) by above.proper.com (8.9.3/8.9.3) with ESMTP id VAA07185 for ; Wed, 9 May 2001 21:39:08 -0700 (PDT) Received: from SMTP (orsmsxvs01-1.jf.intel.com [192.168.65.200]) by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.38 2001/05/09 12:49:45 root Exp $) with SMTP id EAA18835 for ; Thu, 10 May 2001 04:39:02 GMT Received: from orsmsx28.jf.intel.com ([192.168.70.28]) by 192.168.70.200 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 10 May 2001 04:39:02 0000 (GMT) Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 May 2001 21:38:56 -0700 Message-ID: <794826DE8867D411BAB8009027AE9EB90AD0E6A6@FMSMSX38> From: "Jason, Jamie" To: "'ipsec-policy@vpnc.org'" Subject: IPSP Authors' Design Meeting Minutes Date: Wed, 9 May 2001 11:10:58 -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: IPSP Authors' Design Meeting Thursday, May 3, 2001 Particpants: Wes Hardaker, Network Associates Jamie Jason, Intel Man Li, Nokia Lee Rafalow, IBM Eric Vyncke, Cisco Cliff Wang, SmartPipes The authors of the different IPSP policy drafts (model, MIB, and PIB) participated in a teleconference to discuss several issues that were raised at the Minneapolis IETF. These issues were: - filtering on dynamic ports (for example, as are used in the context of a protocol like H.323). The decision was made that for the sake of progressing the model to last call, this issue will not be addressed and the recommendation is to use the existing filtering mechanisms. The filtering that would be necessary to accomplish dynamic ports in the manner brought up in the Minneapolis WG meeting would require additional context, for example, an application type (like H.323). - filtering on other packet values in addition to 5-tuple (for example, ICMP type). The decision was made that for the sake of progressing the model to last call, this issue will not be addressed. However, the model is extensible so that in the future new filter types may be added to allow this capability. - executing multiple actions with one rule. The method originally proposed on the mailing list (adding an additional attribute to the assocation between SARule and SAAction) is deemed as sufficient. However, the Policy Core Information Model extensions (PCIMe) introduced the idea of a compound action and the group took as an action item to determine if the compound action can be used instead. This has the added benefit that we also partially address how the IPsec policy model will interact with the PCIMe work. - one of the universally hated restrictions has been removed from the IPsec policy model. Originally, it was stated that a policy group may only contain rules or other groups. That restriction has been lifted so that now IPsec policy groups may contain both. - an investigation is to be made into the amount of work necessary to define a common rule structure that can be shared among all WGs (DiffServ, MPLS, IPSP, etc.) so that mixture of different kinds of rules is easier. A pitfall to avoid is delaying the IPsec policy model last call an indeterminate amount of time in order to align all of the different factions. Any umbrella work that would affect multiple WGs working on policy would likely need to be done in the Policy Framework WG and it is unlikely that they would be willing to take on new charter items given their desire to finish up all current work in time for the London IETF in August. - an investigation will be made into whether or not the 5-tuple and 6-tuple filter classes defined in the QoS device-level model (QDDIM) can be used to replace the FilterEntry class currently being used. These filter classes are going to be moved into PCIMe. ---------------------------------------------------------------- Jamie Jason email: jamie.jason@intel.com Intel Architecture Labs phone: 503-264-9531 2111 NE 25th Avenue fax: 503-264-9428 Hillsboro, OR 97124 "To give anything less than your best is to sacrifice the gift." - Steve Prefontaine All opinions expressed are: 1. Entirely my own. 2. Not necessarily shared by my employer. 3. Unencumbered by the thought process. ---------------------------------------------------------------- From owner-ipsec-policy@mail.vpnc.org Thu May 10 02:22:26 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA19966 for ; Thu, 10 May 2001 02:22:25 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id WAA08029 for ipsec-policy-bks; Wed, 9 May 2001 22:29:21 -0700 (PDT) Received: from falcon.cdac.ernet.in (falcon.cdac.ernet.in [196.1.109.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id WAA08025 for ; Wed, 9 May 2001 22:29:18 -0700 (PDT) Received: from mailhub.cdac.ernet.in (mailhub.cdac.ernet.in [196.1.109.254]) by falcon.cdac.ernet.in (8.9.2/8.9.2) with ESMTP id LAA25301 for ; Thu, 10 May 2001 11:02:04 +0530 (IST) Received: from ashish ([192.9.205.45]) by mailhub.cdac.ernet.in (8.9.2/8.9.2) with SMTP id KAA09457 for ; Thu, 10 May 2001 10:59:31 +0530 (IST) Message-ID: <001601c0d97a$f3ea25e0$2dcd09c0@ashish> From: "Ashish Chaurasia" To: References: <20010426124102.20023.qmail@squatch.ir.bbn.com> <000b01c0cee4$5bb35a80$3f02a8c0@garibaldi> Subject: a question on vpn design Date: Thu, 10 May 2001 10:59:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I am a newcomer in the field of VPN. I am working on a VPN project. Content-Transfer-Encoding: 7bit We are implementing a LAN-LAN VPN and using BITS implementation of IPSec. We have freezed the specifications of the product. Now we are in the design phase, but stuck there as we are not finding any right direction for design. So please give me some suggetions that how to proceed now. Ashish From owner-ipsec-policy@mail.vpnc.org Thu May 10 10:11:19 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27572 for ; Thu, 10 May 2001 10:11:15 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id GAA24920 for ipsec-policy-bks; Thu, 10 May 2001 06:01:59 -0700 (PDT) Received: from Mail6.nc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA24916 for ; Thu, 10 May 2001 06:01:58 -0700 (PDT) Received: from casey ([66.26.63.121]) by Mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Thu, 10 May 2001 09:01:59 -0400 Reply-To: From: "Casey Carr" To: "IPSec Policy WG" Subject: RE: IPSec Policy Model Date: Thu, 10 May 2001 09:03:19 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <794826DE8867D411BAB8009027AE9EB90AD0E6AC@FMSMSX38> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thank you Jamie. That is exactly what I was looking for. Just didn't dig deep enough to get to RFC 3060. Casey > -----Original Message----- > From: Jason, Jamie [mailto:jamie.jason@intel.com] > Sent: Wednesday, May 09, 2001 7:40 PM > To: 'caseycarr@usa.com'; IPSec Policy WG > Subject: RE: IPSec Policy Model > > > I think that for the next version of the draft, we probably > should put some > verbage in it to explain how conditions and filters are combined. > But, for > the time being... > > Multiple conditions are grouped by the GroupNumber attribute in the > association SAConditionInRule - this attribute is inherited from > PolicyConditionInPolicyRule, which is defined in the Policy Core > Information > Model (PCIM). PolicyRule, which is also defined in PCIM, has an attribute > ConditionListType. See pages 28 & 29 of RFC 3060 for an explanation of > this. A short description is: > - if the list type is Conjunctive Normal Form (CNF), then the individual > conditions in a group are ORed and condition groups are ANDed > - if the list type is Disjunctive Normal Form (DNF), then the individual > conditions in a group are ANDed and the condition groups are ORed > Note...that the individual conditions may be negated. > > As for FilterList, it can be found on page 110 in Appendix C of the draft > and the appropriate assocation EntriesInFilterList can be found > on page 112 > in the same appendix. The association EntriesInFilterList has an > attribute, > EntrySequence, which is defined as follows: > > "The order of the Entry relative to all others in the FilterList. > A value of > zero indicates that all the Entries should be ANDed together. Use of the > Sequence property should be consistent across the List. It is not valid to > define some Entries as ANDed in the FilterList (Sequence=0) while other > Entries have a non-zero Sequence number." > > So, specific filter entries can either be ANDed or ORed. > > Hope that this helps. > > Jamie > > > -----Original Message----- > > From: Casey Carr [mailto:caseycarr@usa.com] > > Sent: Wednesday, May 09, 2001 2:49 PM > > To: IPSec Policy WG > > Subject: IPSec Policy Model > > > > > > Looking for a pointer to the correct paragraph in the correct > > document for > > the following: > > > > I have been unable to locate the definition for the use of > > FilterInCondition > > and ConditionInRule. I believe that the original > > draft-ietf-ipsp-config-policy-model-00.txt (I no longer have a copy) > > described exactly how the filters were suppose to be used and how the > > conditions were supposed to be used. The FilterList definition in the > > draft-ietf-ipsp-config-policy-model-01.txt document defines > > "FilterList > > aggregates an ANDed set of filters" but I could not find a > > statement like > > this in the 02 draft. Presumably because the FilterList > > object was removed. > > > > How are multiple conditions supposed to be evaluated so that a single > > true/false results when a SARule has multiple conditions and > > each condition > > has multiple filters? I believe the original 00 draft > > covered this but I am > > unable to find this in the new draft or any of the DMTF documents. > > > > My assumption is that all filters are ANDed together (of > > course taking into > > account the "negated" attribute). If all filters evaluate to > > true then the > > condition is true. If this is the case, then "EntrySequence" > > attribute of > > the aggregation is meaningless. This same process would then > > be repeated > > for each condition in the rule and the results of each > > condition are ANDed > > together. > > > > Would someone please point me to the correct document to > > validate/correct my > > assumption? > > > > Casey > > > > > > From owner-ipsec-policy@mail.vpnc.org Thu May 10 11:07:34 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00017 for ; Thu, 10 May 2001 11:07:33 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id FAA24504 for ipsec-policy-bks; Thu, 10 May 2001 05:56:23 -0700 (PDT) Received: from Mail6.nc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA24499 for ; Thu, 10 May 2001 05:56:21 -0700 (PDT) Received: from casey ([66.26.63.121]) by Mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Thu, 10 May 2001 08:56:22 -0400 Reply-To: From: "Casey Carr" To: "IPSec Policy WG" Subject: RE: IPSEC-POLICY-MIB - Negotiation actions Date: Thu, 10 May 2001 08:57:42 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3AF9AEA0.A5EBE1B2@redcreek.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Ricky Charlet [mailto:rcharlet@redcreek.com] > Sent: Wednesday, May 09, 2001 4:55 PM > To: Wes Hardaker > Cc: caseycarr@usa.com; IPSec Policy WG > Subject: Re: IPSEC-POLICY-MIB - Negotiation actions > > > Wes Hardaker wrote: > > > > >>>>> On Wed, 9 May 2001 14:07:00 -0400, "Casey Carr" > said: > > > > Casey> Although, wouldn't augmenting be a truer representation of an > > Casey> uninstantiated base class with two differing intantiated and > > Casey> inheriting classes? Maybe not... just wondering. Yes it would > > Casey> be more accurate. I'm not an SMI expert, but does it support > > Casey> designing a table definition that has to be AUGMENTed in order > > Casey> to have an instantiated row? I.E. Does can SMI support the > > Casey> concept of an abstract base class? If SMI supports it, maybe > > Casey> you could omit a RowStatus in the base table and but have one > > Casey> in each of the tables that AUGMENT it. > > > > Part of the problem here is that Mike and I came up with the initial > > table breakdown, but Ricky and Cliff wrote the tables in question so > > what Mike and I were thinking didn't get exactly mapped into reality. > > I have many minor "corrections" I'll propose (when I get the time, > > hopefully later this month, sigh) in this regard. > > > > The problem is basically one of reuse. The idea was the notification > > parameters that were common to both action sets should be defined in a > > single table such that reuse of the definition would be possible. > > IE, the table in question should have been "pointed to" by the other > > two action tables such that it would be a reference saying "see here > > for common parameters". > > > > Now, it doesn't make sense for all instances and this is what we need > > to determine. However, I'm admittedly opposed (from an admittedly > > idealistic standpoint) to taking the exact same set of paramaters and > > making them identical column sets in two other tables. Instead, we > > should use a pointer of some kind (whether that's via a string index > > (I think what was originally intended), or via a RowPointer, or via an > > AUGMENTS (IE, MIB-specific) style of inheritance. > > > > Make sense? > > -- > > Wes Hardaker > > But as the tables stand today, the SANegotiationAction > entries are not > re-usable by several ike or ipsec actions. Each saNegotiationAction must > point to only one IKEAction or one IPsecAction. > > So here comes just a brain-storm type idea (ie.. not well > thought out) > If We arranged our tables such that the actionName rowpointer in the > actionsInRuleEntry pointed at either an Ike or an IPsec action and then > the IKE/IPsec actions had a columb to point at saNegotiationAction.... > then we could re-use common timout type parameters. That seems reasonable but it adds complexity to maintaining the saNegotiationAction for cleanup. If a saNegotiationActon row is to be deleted then there has to be a check to make sure it is not referenced from by an IKE/IPSec entry. Plus, how do you prevent a user from changing a column in the saNegotiationAcion to accommodate one IKE/IPSec action without inadvertently changing another one pointing to the same column? Is this price paid for this much additional logic worth the storage for four or five extra integers per IKE/IPSec action? > > -- > Ricky Charlet : Redcreek Communications : usa (510) 795-6903 > From owner-ipsec-policy@mail.vpnc.org Thu May 10 11:22:04 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00378 for ; Thu, 10 May 2001 11:22:02 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id HAA29355 for ipsec-policy-bks; Thu, 10 May 2001 07:13:08 -0700 (PDT) Received: from Mail6.nc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA29347 for ; Thu, 10 May 2001 07:13:06 -0700 (PDT) Received: from casey ([66.26.63.121]) by Mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Thu, 10 May 2001 10:13:07 -0400 Reply-To: From: "Casey Carr" To: "IPSec Policy WG" Subject: IPSEC-POLICY-MIB - Processing of filters and conditions Date: Thu, 10 May 2001 10:14:27 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I was confused between the MIB contents pertaining to filter/condition processing and the contents of the Policy Model draft. Jamie Jason was able to point me to the correct location in RFC 3060 and the Policy Model draft to get clarification. After reviewing these documents it appears to me that the MIB has changed the semantics for this processing. The MIB draft seems to be a somewhat simpler implementation. Was that the desire? In particular the concept of a "condition group" has been dropped in favor of a sequence of conditions. Also, the "sequence" attribute of filtersInCondition has been dropped. This attribute was intended to allow either ANDing or ORing filters. Casey From owner-ipsec-policy@mail.vpnc.org Fri May 11 11:43:03 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13383 for ; Fri, 11 May 2001 11:43:02 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id HAA22440 for ipsec-policy-bks; Fri, 11 May 2001 07:41:00 -0700 (PDT) Received: from wanderer.hardakers.net (dns1.hardaker.davis.ca.us [168.150.190.1]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA22432 for ; Fri, 11 May 2001 07:40:54 -0700 (PDT) Received: (from hardaker@localhost) by wanderer.hardakers.net (8.11.2/8.11.2) id f4BEeNL01490; Fri, 11 May 2001 07:40:23 -0700 X-Authentication-Warning: wanderer.hardakers.net: hardaker set sender to wes@hardakers.net using -f To: Cc: "IPSec Policy WG" Subject: Re: IPSEC-POLICY-MIB - Processing of filters and conditions References: From: Wes Hardaker X-URL: http://dcas.ucdavis.edu/~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 In-Reply-To: ("Casey Carr"'s message of "Thu, 10 May 2001 10:14:27 -0400") Message-ID: User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.2 (Terspichore) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: 11 May 2001 07:40:23 -0700 Lines: 19 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> On Thu, 10 May 2001 10:14:27 -0400, "Casey Carr" said: Casey> I was confused between the MIB contents pertaining to Casey> filter/condition processing and the contents of the Policy Casey> Model draft. The filter table is probably going to be rewritten. One thing you should note is that the MIB was written from the -01 version of the data-model, and both the -02 version of the data-model and the MIB were published at the same time so that the MIB is functionally behind the data model and needs to catch up again. I'll try to a new draft out by the end of this month, but I doubt I'll make that deadline. June should be possible, however. -- Wes Hardaker NAI Labs Network Associates From phoffman@above.proper.com Sun May 13 11:52:13 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12098 for ; Sun, 13 May 2001 11:52:12 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id IAA24111; Sun, 13 May 2001 08:52:17 -0700 (PDT) Date: Sun, 13 May 2001 08:52:17 -0700 (PDT) Message-Id: <200105131552.IAA24111@above.proper.com> To: ipsp-archive@ietf.org From: subs-reminder@vpnc.org Subject: Subscription for ipsp-archive@lists.ietf.org to the ipsec-policy mailing list Greetings. This message is a periodic reminder that you are subscribed to the ipsec-policy mailing list, and you are subscribed as: ipsp-archive@lists.ietf.org 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 anyting. If you want to unsubscribe from this list, you can respond to this message and I will unsubscribe you. This may take a few days because it will be done by hand by a human. If you want to unsubscribe automatically, send a plain-text message to: ipsec-policy-request@vpnc.org with the single word unsubscribe in the body of the message. If you have any questions, feel free to contact me. --Paul Hoffman, list administrator From owner-ipsec-policy@mail.vpnc.org Mon May 14 01:27:05 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA22202 for ; Mon, 14 May 2001 01:27:04 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id VAA12327 for ipsec-policy-bks; Sun, 13 May 2001 21:31:27 -0700 (PDT) Received: from falcon.cdac.ernet.in (falcon.cdac.ernet.in [196.1.109.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id VAA12322 for ; Sun, 13 May 2001 21:31:19 -0700 (PDT) Received: from mailhub.cdac.ernet.in (mailhub.cdac.ernet.in [196.1.109.254]) by falcon.cdac.ernet.in (8.9.2/8.9.2) with ESMTP id KAA09102 for ; Mon, 14 May 2001 10:04:20 +0530 (IST) Received: from ashish ([192.9.205.45]) by mailhub.cdac.ernet.in (8.9.2/8.9.2) with SMTP id KAA19838 for ; Mon, 14 May 2001 10:01:47 +0530 (IST) Message-ID: <000e01c0dc97$f5faf150$2dcd09c0@ashish> From: "Ashish Chaurasia" To: Subject: Query:Best IPSec implementation Date: Mon, 14 May 2001 10:04:38 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C0DC5D.490641F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C0DC5D.490641F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am working on a VPN project. We are implementing a LAN-LAN VPN = and using BITS implementation of IPSec. For implementing IPSec we are = planning to use a public domain implementation. I know that there are = some public domain implementations are available of IPSec such as = FreeSwan, OpenBSD etc. But is there any comparision of all these = implementation available ? I want to use the best implementation of = IPSec. So please tell me the best IPSec public domain implementaiton. With regards Ashish =20 =20 ------=_NextPart_000_000B_01C0DC5D.490641F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
        I = am working=20 on a VPN project. We are implementing a LAN-LAN VPN and using BITS=20 implementation of IPSec. For implementing IPSec we are planning to use a = public=20 domain implementation. I know that there are some public domain = implementations=20 are available of IPSec such as FreeSwan, OpenBSD etc. But is there any=20 comparision of all these implementation available ? I want to use = the best=20 implementation of IPSec.
        So=20 please tell me the best IPSec public domain implementaiton.
 
With regards
Ashish
 
  
      =20
------=_NextPart_000_000B_01C0DC5D.490641F0-- From owner-ipsec-policy@mail.vpnc.org Mon May 14 13:16:30 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18518 for ; Mon, 14 May 2001 13:16:30 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id JAA21439 for ipsec-policy-bks; Mon, 14 May 2001 09:10:04 -0700 (PDT) Received: from mailsys01.intnet.net (mailhost.wwc.com [198.252.32.15]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA21422 for ; Mon, 14 May 2001 09:09:57 -0700 (PDT) Received: from [206.112.123.141] (HELO p01z0nb0x) by mailsys01.intnet.net (CommuniGate Pro SMTP 3.3.2) with SMTP id 8113736 for ipsec-policy@vpnc.org; Mon, 14 May 2001 12:09:07 -0400 Reply-To: "Anshuman Sharma" From: "Anshuman Sharma" To: Subject: RE: Query:Best IPSec implementation Date: Mon, 14 May 2001 09:10:03 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 In-Reply-To: <000e01c0dc97$f5faf150$2dcd09c0@ashish> Importance: Normal Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Check out www.vpnc.org. OpenBSD and FreeSwan is one of the more reliable implementations. You can also check this out http://www.freeswan.org/freeswan_trees/freeswan-1.3/doc/links.ipsec.ht ml. /Anshuman - -----Original Message----- From: owner-ipsec-policy@mail.vpnc.org [mailto:owner-ipsec-policy@mail.vpnc.org]On Behalf Of Ashish Chaurasia Sent: Monday, May 14, 2001 10:05 AM To: ipsec-policy@vpnc.org Subject: Query:Best IPSec implementation I am working on a VPN project. We are implementing a LAN-LAN VPN and using BITS implementation of IPSec. For implementing IPSec we are planning to use a public domain implementation. I know that there are some public domain implementations are available of IPSec such as FreeSwan, OpenBSD etc. But is there any comparision of all these implementation available ? I want to use the best implementation of IPSec. So please tell me the best IPSec public domain implementaiton. With regards Ashish -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.4 Comment: Be careful what you wish for as it may come true. iQA/AwUBOwADWkQZ5G4oNJmnEQKxxQCdEgjMMa4MDqTHoASlJ1gm3SNYDYEAoOOv dzNQVEVl9oSCc86K05j8t8wu =Y8rm -----END PGP SIGNATURE----- From owner-ipsec-policy@mail.vpnc.org Thu May 31 08:36:47 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA22264 for ; Thu, 31 May 2001 08:36:46 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id EAA19014 for ipsec-policy-bks; Thu, 31 May 2001 04:59:31 -0700 (PDT) Received: from smtp2.cluster.oleane.net (smtp2.cluster.oleane.net [195.25.12.17]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA19006 for ; Thu, 31 May 2001 04:59:25 -0700 (PDT) Received: from oleane (dyn-1-1-243.Vin.dialup.oleane.fr [195.25.4.243]) by smtp2.cluster.oleane.net with SMTP id f4VBxLL38798 for ; Thu, 31 May 2001 13:59:22 +0200 (CEST) Message-ID: <005701c0e9c9$1dc4a9e0$8001a8c0@oleane.com> From: "Peter Lewis" To: Subject: IP Policy Conference Date: Thu, 31 May 2001 13:59:03 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004E_01C0E9D9.D9DEB480" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_004E_01C0E9D9.D9DEB480 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable IP Policy Conference, Paris 11-14 September: IPsec policy issues: http://www.upperside.fr/ippol2001/ippol2001intro.htm ------=_NextPart_000_004E_01C0E9D9.D9DEB480 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
IP Policy Conference, Paris 11-14 = September:=20 IPsec policy issues:
http://www.= upperside.fr/ippol2001/ippol2001intro.htm
 
------=_NextPart_000_004E_01C0E9D9.D9DEB480-- From owner-ipsec-policy@mail.vpnc.org Thu May 31 08:42:47 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA22497 for ; Thu, 31 May 2001 08:42:46 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id FAA19642 for ipsec-policy-bks; Thu, 31 May 2001 05:09:39 -0700 (PDT) Received: from p-mail1.cnet.fr (p-mail1.rd.francetelecom.fr [193.49.124.31]) by above.proper.com (8.9.3/8.9.3) with SMTP id FAA19631 for ; Thu, 31 May 2001 05:09:33 -0700 (PDT) Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Thu, 31 May 2001 14:08:45 +0200 Message-ID: <91A311FF6A85D3118DDF0060080C3D829DE23D@lat3721.rd.francetelecom.fr> From: MORAND Pierrick FTRD/DMI/CAE To: "IPSEC-POLICY (E-mail)" , "RAP (E-mail)" Cc: NOISETTE Yoann FTRD/DMI/CAE , RABOT Wilfrid FTRD/DMI/CAE Subject: COPS-PR security general issues Date: Thu, 31 May 2001 14:08:24 +0200 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: We are currently working on the general theme of provisioning. We are considering COPS-PR with attention and would bring to the attention of RAP and IPSP experts the following remarks and questions with our apologizes if these issues have already been debated. In a general way, COPS-PR has been designed to provision configuration policies for various functional domains such as IPSec, L2TP, MPLS, AAA, Routing, TE .... Considering for instance, IPSec, AAA and L2TP, provisioning of those functions leads to exchange with the equipment sensitive information such as shared secrets (L2TP-Tunnel-password, users password, radius secret and so on). Within COPS there is an optional security mechanisms, which only guarantees the integrity of the COPS messages. There is no general mechanisms allowing to cipher some particular sensitive fields. Do these security issues shall conduct an implementer or an operator to systematically make use of IPSec to secure exchanges between a PEP and a PDP so that it becomes possible to provision sensitive security information without having to defined ciphered fields in the PIBs for which no generic mechanisms have currently been defined ? If IPSec is used to secure COPS-PR exchanges what would become the utility of the integrity mechanisms defined within COPS and more especially when used within COPS-PR ? Additionally, the IPSec PIB which is currently in its definition phase, allows to define IKE rules specifying pre-shared key as Ike proposal authentication [ipSecIkeProposalAutenticationMethod OBJET-TYPE with presharedKey(1) as possible value]method but does not allow to provision those secrets. This means that the provisioning of those secrets shall be done by an other way and in that case advantages of COPS-PR in case of pre-shared authentication becomes greatly reduced since this shall be achieved by hand or using an other mechanism. In a same way if L2TP or AAA PIBs were to be defined how secrets (and more generally sensitive information) should be provisioned ? -In clear : not reasonable -Ciphered : there is no generic mechanisms -Protected by IPSec, SSL... : should work fine, but the RFC should precise that usage of a particular client type, defining sensitive information MUST make use of an external mechanisms in order to secure those sensitive information.. To conclude it seams that we can have the two possible approaches in order to allow the exchange of sensible security information between a PEP an a PDP : 1-systematicaly make use of an underlying security layer (IPSec for instance) to secure exchanges between PEP and PDP. In that case the COPS integrity mechanism is no more necessary. This approach implies that the PEP has to support a security communication layer which might not be the case in all situation. 2-defines a generic COPS ciphering mechanism which allows to protect some sensitive fields. Security is embedded in the COPS protocol and must be supported. If this issue was solved, could IPSP experts extend the PIB so that shared secret can be exchanged or is the reason for which it is not currently supported more fundamental ? Thanks in advance for your answers and comments. Pierrick Morand france telecom R&D/DMI/SIR/IPI Tel : +33 2 31 75 91 79 - Fax : +33 2 31 73 56 26 Email :pierrick.morand@francetelecom.com From owner-ipsec-policy@mail.vpnc.org Thu May 31 16:36:31 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07737 for ; Thu, 31 May 2001 16:36:30 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id MAA17553 for ipsec-policy-bks; Thu, 31 May 2001 12:39:33 -0700 (PDT) Received: from wanderer.hardakers.net (dns1.hardaker.davis.ca.us [168.150.190.1]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA17537 for ; Thu, 31 May 2001 12:39:26 -0700 (PDT) Received: (from hardaker@localhost) by wanderer.hardakers.net (8.11.2/8.11.2) id f4VJd2N06305; Thu, 31 May 2001 12:39:02 -0700 X-Authentication-Warning: wanderer.hardakers.net: hardaker set sender to wes@hardakers.net using -f To: Ricky Charlet Cc: caseycarr@usa.com, IPSec Policy WG Subject: Re: FW: TDomain in IPSEC-POLICY-MIB References: <3AE071BE.70D3C0A5@redcreek.com> From: Wes Hardaker X-URL: http://dcas.ucdavis.edu/~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 In-Reply-To: (Wes Hardaker's message of "25 Apr 2001 15:40:08 -0700") Message-ID: User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.2 (Terspichore) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: 31 May 2001 12:39:02 -0700 Lines: 43 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Since no one responded to my queries about the following, I'll probably pick #2 (shortly, as I'll be working on the MIB this week and next) unless someone argues otherwise. >>>>> On 25 Apr 2001 15:40:08 -0700, Wes Hardaker said: Wes> 1) use current existing TDomain style definitions, which (as pointed Wes> out) don't really fit our needs. Wes> 2) Use the above IpsecDoiIdentType definition, and then define how the Wes> value half of that is specified, um, somewhere? Should we then Wes> make a IpsecDoiIdentValue TC that has an extremely long description Wes> clause spelling out the value formating of the OCTETSTRING that its Wes> made of? Wes> 3) Define our own set of 11 or so TDomains to match the above and Wes> continue to use TAddress as the value specifier. Wes> There are also issues revolving around how they should be used. In Wes> the case of specifying an endpoint that is supposed to be singular Wes> (open a connection to "here"), should the description clause of every Wes> object dictate which is legal for that column and which isn't? Or Wes> should that definition be defined in the TC (I'd vote for the TC, but Wes> common MIB practice is to cut-n-paste it everywhere to make sure its Wes> visible and not missed because they didn't follow the TC reference). Wes> I've started converting the other pieces of the MIB to use the other Wes> TCs defined in the previously mentioned draft, but this is the case Wes> that truly needs more thoughts. Wes> Opinions? I'm leaning towards #2 above I guess. Wes> -- Wes> Wes Hardaker Wes> NAI Labs Wes> Network Associates -- Wes Hardaker NAI Labs Network Associates From owner-ipsec-policy@mail.vpnc.org Thu May 31 19:39:09 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10233 for ; Thu, 31 May 2001 19:39:09 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id PAA29355 for ipsec-policy-bks; Thu, 31 May 2001 15:32:51 -0700 (PDT) Received: from wanderer.hardakers.net (dns1.hardaker.davis.ca.us [168.150.190.1]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA29349 for ; Thu, 31 May 2001 15:32:45 -0700 (PDT) Received: (from hardaker@localhost) by wanderer.hardakers.net (8.11.2/8.11.2) id f4VMRRk06877; Thu, 31 May 2001 15:27:27 -0700 X-Authentication-Warning: wanderer.hardakers.net: hardaker set sender to wes@hardakers.net using -f To: Cc: "IPSec Policy WG" Subject: Re: IPSEC-POLICY-MIB - Processing of filters and conditions References: From: Wes Hardaker X-URL: http://dcas.ucdavis.edu/~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: 31 May 2001 15:27:26 -0700 In-Reply-To: ("Casey Carr"'s message of "Thu, 10 May 2001 10:14:27 -0400") Message-ID: Lines: 63 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.2 (Terspichore) 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, 10 May 2001 10:14:27 -0400, "Casey Carr" said: Casey> I was confused between the MIB contents pertaining to Casey> filter/condition processing and the contents of the Policy Casey> Model draft. Jamie Jason was able to point me to the correct Casey> location in RFC 3060 and the Policy Model draft to get Casey> clarification. After reviewing these documents it appears to Casey> me that the MIB has changed the semantics for this processing. Casey> The MIB draft seems to be a somewhat simpler implementation. Casey> Was that the desire? Casey> In particular the concept of a "condition group" has been Casey> dropped in favor of a sequence of conditions. Also, the Casey> "sequence" attribute of filtersInCondition has been dropped. Casey> This attribute was intended to allow either ANDing or ORing Casey> filters. You're right that doing DNF and CNF processing wasn't possible in the MIB. I've inserted the following object into the conditionTable which should allow you to either AND or OR the filters. Note that we have separate objects that would functionally let you do things that the policy model wouldn't let you do, like "AND and AND" and "OR and OR" the conditions and filters respectively. This is done for processing simplicity and makes reuse of filter and condition definitions a bit better. conditionFilterListType OBJECT-TYPE SYNTAX IpsecBooleanOperator MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates whether the filters contained within this filter are functionally ANDed or ORed together" DEFVAL { and } ::= { conditionEntry 3 } Does this meet your requirements stated above? You're right that the MIB draft attempted to simplify the model usage a bit, as I found it somewhat complex and that you could accomplish the same functionality without the higher overhead of the more OO like model. The sequencing introduced into the model was intentional, primarily as an methodology for introducing optimization. If, for instance, you put your more generic simpler filters higher in the sequence list you could determine early on that the more complex filters/conditions later in the sequence didn't need to be evaluated if the current filter/condition indicated a stop condition. Make sense? So, condition grouping is functionally established in a different way: the rule dictates the ANDing/ORing of the conditions within, and the sequence number allows you to optimize which are evaluated first. Do you find this a reasonable design, or do you still have problems with it? Note that I'm trying to support everything the data model contains, but in a possibly more simple and flexible architecture. -- Wes Hardaker NAI Labs Network Associates