From owner-rap@ops.ietf.org Thu Nov 6 16:45:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02718 for ; Thu, 6 Nov 2003 16:45:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHrva-000BSa-31 for rap-data@psg.com; Thu, 06 Nov 2003 21:44:30 +0000 Received: from [192.11.226.161] (helo=hoemail1.firewall.lucent.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHrvT-000BRv-IM for rap@ops.ietf.org; Thu, 06 Nov 2003 21:44:23 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hA6Lgop02191 for ; Thu, 6 Nov 2003 15:43:22 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id ; Thu, 6 Nov 2003 21:56:37 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502D954E1@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Scott Hahn (E-mail)" , "Mark Stevens (E-mail)" Cc: "Rap-wg (E-mail)" , "Uri Blumenthal (E-mail)" Subject: RE: Feedback on draft-ietf-rap-cops-tls-06.txt Date: Thu, 6 Nov 2003 21:56:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-rap@ops.ietf.org Precedence: bulk I guess that it just alternates between the security advisor and the WG (and/or eduitors/authors)... but now we've been waiting for close to two weeks without any response from WG. This is not gonna work I hope you understand the implied message here! Thanks, Bert > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: maandag 27 oktober 2003 12:06 > To: Rap-wg (E-mail) > Cc: Uri Blumenthal (E-mail) > Subject: Feedback on draft-ietf-rap-cops-tls-06.txt > > > Sorry for the long delay, but finally our Security Advisor has > found time to review revision 6. > > I hope that the authors/editors and the WG can quickly > respond and act, so that we can now get some pressure to > complete this last RAP-WG document soon. > > Thanks, > Bert > > -----Original Message----- > From: Uri Blumenthal [mailto:uri@lucent.com] > Sent: donderdag 23 oktober 2003 23:58 > To: Wijnen, Bert > Cc: Blumenthal, Uri > Subject: COPS etc.3.2.1. So is at least one protocol > mandatory? And why > is it valid to make them all optional? > > > Bert, > > Sorry for prolonged silence - was sick and then took me > time to get through the e-mail piles. > > Here's my review of COPS-06, please forward it to the > appropriate AD and WG chair(s). > > ================================================== > cops-06.txt > > GENERIC COMMENTS. > > I'd prefer the following important issues described > somewhere: > - key provisioning (how the initial/first keys > get in); > - key management/update; > - key requirments. What kind of keys are accepted? > Public Key in X.509 format only? Anything else? > Any reason why neither symmetric keys nor > password-based methods (such as SRP, or what's in > SSL) are there? > - policy - how it gets there, how it's processed, > what it looks like, etc. Something comparable to > VACM of SNMPv3... > > I found the text on Access Control exceedingly muddy/unclear. I'm > coming from reasonably good understanding of Access Control, but > shallow knowledge of COPS. Request rephrasing (and maiing it > CLEARER). > > Excessive use of abbreviations (PEP, PDP) without defining them > in this document doesn't help. > > Otherwise the document is OK, notwithstanding the following. > > SPECIFIC COMMENTS. > > 3.2.1. So is at least one protocol mandatory? And why is it valid > to make them all optional? > > 4.4. I'm not sure server (in the last case) should be allowed to > just proceed establishing insecure connection. Perhaps better if > the client decides how to proceed? > > PDP implementations MUST NOT require use of access control?! I'm > violently against this prohibition. > > 8. Forcing to choose between insecure and X.509 PKI infrastructure > is unfair and improper. Recommendation: support Web of trust, > possibly other... > > PDP hostname availavle via Access Control mechanism? I don't > understand - please clarify. > > 9.1. And the point of backward compatibility with old insecure > implementations is...? > > References. RFC2748 is not of January 200 (unless it's a part > of Gospel?). > From owner-rap@ops.ietf.org Thu Nov 6 16:50:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02974 for ; Thu, 6 Nov 2003 16:50:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHs0y-000CIb-Ft for rap-data@psg.com; Thu, 06 Nov 2003 21:50:04 +0000 Received: from [192.52.57.35] (helo=hermes.hd.intel.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHs0p-000CE2-Bj for rap@ops.ietf.org; Thu, 06 Nov 2003 21:49:55 +0000 Received: from petasus.hd.intel.com (petasus.hd.intel.com [10.127.45.3]) by hermes.hd.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hA6Lkhmd000382 for ; Thu, 6 Nov 2003 21:46:43 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.hd.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hA6Li3J23931 for ; Thu, 6 Nov 2003 21:44:03 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003110613495230577 ; Thu, 06 Nov 2003 13:49:52 -0800 Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 6 Nov 2003 13:49:52 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: Feedback on draft-ietf-rap-cops-tls-06.txt Date: Thu, 6 Nov 2003 13:49:51 -0800 Message-ID: Thread-Topic: Feedback on draft-ietf-rap-cops-tls-06.txt Thread-Index: AcOkr4DO0Sw2UK5VTbKbk9F8stad+wAAEK/A From: "Kulkarni, Amol" To: "Wijnen, Bert (Bert)" , "Hahn, Scott" , "Mark Stevens (E-mail)" Cc: "Rap-wg (E-mail)" , "Uri Blumenthal (E-mail)" X-OriginalArrivalTime: 06 Nov 2003 21:49:52.0370 (UTC) FILETIME=[E883F520:01C3A4AF] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Bert, I AM working on modifying the draft to Uri's satisfaction. Amol -----Original Message----- From: owner-rap@ops.ietf.org [mailto:owner-rap@ops.ietf.org] On Behalf Of Wijnen, Bert (Bert) Sent: Thursday, November 06, 2003 12:56 PM To: Hahn, Scott; Mark Stevens (E-mail) Cc: Rap-wg (E-mail); Uri Blumenthal (E-mail) Subject: RE: Feedback on draft-ietf-rap-cops-tls-06.txt I guess that it just alternates between the security advisor=20 and the WG (and/or eduitors/authors)... but now we've been waiting for close to two weeks without any response from WG. This is not gonna work=20 I hope you understand the implied message here! Thanks, Bert=20 > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: maandag 27 oktober 2003 12:06 > To: Rap-wg (E-mail) > Cc: Uri Blumenthal (E-mail) > Subject: Feedback on draft-ietf-rap-cops-tls-06.txt >=20 >=20 > Sorry for the long delay, but finally our Security Advisor has=20 > found time to review revision 6. >=20 > I hope that the authors/editors and the WG can quickly=20 > respond and act, so that we can now get some pressure to > complete this last RAP-WG document soon. >=20 > Thanks, > Bert=20 >=20 > -----Original Message----- > From: Uri Blumenthal [mailto:uri@lucent.com] > Sent: donderdag 23 oktober 2003 23:58 > To: Wijnen, Bert > Cc: Blumenthal, Uri > Subject: COPS etc.3.2.1. So is at least one protocol=20 > mandatory? And why > is it valid to make them all optional? >=20 >=20 > Bert, >=20 > Sorry for prolonged silence - was sick and then took me > time to get through the e-mail piles. >=20 > Here's my review of COPS-06, please forward it to the > appropriate AD and WG chair(s). >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > cops-06.txt >=20 > GENERIC COMMENTS. >=20 > I'd prefer the following important issues described > somewhere: > - key provisioning (how the initial/first keys > get in); > - key management/update; > - key requirments. What kind of keys are accepted? > Public Key in X.509 format only? Anything else? > Any reason why neither symmetric keys nor > password-based methods (such as SRP, or what's in > SSL) are there? > - policy - how it gets there, how it's processed, > what it looks like, etc. Something comparable to > VACM of SNMPv3... >=20 > I found the text on Access Control exceedingly muddy/unclear. I'm > coming from reasonably good understanding of Access Control, but > shallow knowledge of COPS. Request rephrasing (and maiing it > CLEARER). >=20 > Excessive use of abbreviations (PEP, PDP) without defining them > in this document doesn't help. >=20 > Otherwise the document is OK, notwithstanding the following. >=20 > SPECIFIC COMMENTS. >=20 > 3.2.1. So is at least one protocol mandatory? And why is it valid > to make them all optional? >=20 > 4.4. I'm not sure server (in the last case) should be allowed to > just proceed establishing insecure connection. Perhaps better if > the client decides how to proceed? >=20 > PDP implementations MUST NOT require use of access control?! I'm > violently against this prohibition. >=20 > 8. Forcing to choose between insecure and X.509 PKI infrastructure > is unfair and improper. Recommendation: support Web of trust, > possibly other... >=20 > PDP hostname availavle via Access Control mechanism? I don't > understand - please clarify. >=20 > 9.1. And the point of backward compatibility with old insecure > implementations is...? >=20 > References. RFC2748 is not of January 200 (unless it's a part > of Gospel?). >=20 From owner-rap@ops.ietf.org Thu Nov 6 17:02:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03846 for ; Thu, 6 Nov 2003 17:02:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHsCo-000E66-W8 for rap-data@psg.com; Thu, 06 Nov 2003 22:02:18 +0000 Received: from [192.11.226.161] (helo=hoemail1.firewall.lucent.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHsCi-000E52-3x for rap@ops.ietf.org; Thu, 06 Nov 2003 22:02:12 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hA6M0up15159 for ; Thu, 6 Nov 2003 16:01:17 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id ; Thu, 6 Nov 2003 23:00:54 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502D954ED@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Kulkarni, Amol" , "Hahn, Scott" , "Mark Stevens (E-mail)" Cc: "Rap-wg (E-mail)" , "Uri Blumenthal (E-mail)" Subject: RE: Feedback on draft-ietf-rap-cops-tls-06.txt Date: Thu, 6 Nov 2003 23:00:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-rap@ops.ietf.org Precedence: bulk OK, that is good to hear. But was I supposed to just assume that based on the silence? Thanks, Bert > -----Original Message----- > From: Kulkarni, Amol [mailto:amol.kulkarni@intel.com] > Sent: donderdag 6 november 2003 22:50 > To: Wijnen, Bert (Bert); Hahn, Scott; Mark Stevens (E-mail) > Cc: Rap-wg (E-mail); Uri Blumenthal (E-mail) > Subject: RE: Feedback on draft-ietf-rap-cops-tls-06.txt > > > Bert, > > I AM working on modifying the draft to Uri's satisfaction. > > Amol > > -----Original Message----- > From: owner-rap@ops.ietf.org [mailto:owner-rap@ops.ietf.org] On Behalf > Of Wijnen, Bert (Bert) > Sent: Thursday, November 06, 2003 12:56 PM > To: Hahn, Scott; Mark Stevens (E-mail) > Cc: Rap-wg (E-mail); Uri Blumenthal (E-mail) > Subject: RE: Feedback on draft-ietf-rap-cops-tls-06.txt > > I guess that it just alternates between the security advisor > and the WG (and/or eduitors/authors)... but now we've been waiting > for close to two weeks without any response from WG. > > > This is not gonna work > I hope you understand the implied message here! > > > Thanks, > Bert > > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > Sent: maandag 27 oktober 2003 12:06 > > To: Rap-wg (E-mail) > > Cc: Uri Blumenthal (E-mail) > > Subject: Feedback on draft-ietf-rap-cops-tls-06.txt > > > > > > Sorry for the long delay, but finally our Security Advisor has > > found time to review revision 6. > > > > I hope that the authors/editors and the WG can quickly > > respond and act, so that we can now get some pressure to > > complete this last RAP-WG document soon. > > > > Thanks, > > Bert > > > > -----Original Message----- > > From: Uri Blumenthal [mailto:uri@lucent.com] > > Sent: donderdag 23 oktober 2003 23:58 > > To: Wijnen, Bert > > Cc: Blumenthal, Uri > > Subject: COPS etc.3.2.1. So is at least one protocol > > mandatory? And why > > is it valid to make them all optional? > > > > > > Bert, > > > > Sorry for prolonged silence - was sick and then took me > > time to get through the e-mail piles. > > > > Here's my review of COPS-06, please forward it to the > > appropriate AD and WG chair(s). > > > > ================================================== > > cops-06.txt > > > > GENERIC COMMENTS. > > > > I'd prefer the following important issues described > > somewhere: > > - key provisioning (how the initial/first keys > > get in); > > - key management/update; > > - key requirments. What kind of keys are accepted? > > Public Key in X.509 format only? Anything else? > > Any reason why neither symmetric keys nor > > password-based methods (such as SRP, or what's in > > SSL) are there? > > - policy - how it gets there, how it's processed, > > what it looks like, etc. Something comparable to > > VACM of SNMPv3... > > > > I found the text on Access Control exceedingly muddy/unclear. I'm > > coming from reasonably good understanding of Access Control, but > > shallow knowledge of COPS. Request rephrasing (and maiing it > > CLEARER). > > > > Excessive use of abbreviations (PEP, PDP) without defining them > > in this document doesn't help. > > > > Otherwise the document is OK, notwithstanding the following. > > > > SPECIFIC COMMENTS. > > > > 3.2.1. So is at least one protocol mandatory? And why is it valid > > to make them all optional? > > > > 4.4. I'm not sure server (in the last case) should be allowed to > > just proceed establishing insecure connection. Perhaps better if > > the client decides how to proceed? > > > > PDP implementations MUST NOT require use of access control?! I'm > > violently against this prohibition. > > > > 8. Forcing to choose between insecure and X.509 PKI infrastructure > > is unfair and improper. Recommendation: support Web of trust, > > possibly other... > > > > PDP hostname availavle via Access Control mechanism? I don't > > understand - please clarify. > > > > 9.1. And the point of backward compatibility with old insecure > > implementations is...? > > > > References. RFC2748 is not of January 200 (unless it's a part > > of Gospel?). > > > > From owner-rap@ops.ietf.org Thu Nov 13 16:42:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22157 for ; Thu, 13 Nov 2003 16:42:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKPCk-000JNd-W1 for rap-data@psg.com; Thu, 13 Nov 2003 21:40:42 +0000 Received: from [134.134.136.7] (helo=caduceus.jf.intel.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKPCg-000JMs-5W for rap@ops.ietf.org; Thu, 13 Nov 2003 21:40:38 +0000 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hADLehvn030342; Thu, 13 Nov 2003 21:40:44 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hADLVYC23353; Thu, 13 Nov 2003 21:31:34 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.1.32) with SMTP id M2003111313403020698 ; Thu, 13 Nov 2003 13:40:30 -0800 Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 13 Nov 2003 13:40:30 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: Feedback on draft-ietf-rap-cops-tls-06.txt Date: Thu, 13 Nov 2003 13:40:30 -0800 Message-ID: Thread-Topic: Feedback on draft-ietf-rap-cops-tls-06.txt Thread-Index: AcOceohIrfho4Tb5SY6klbin/p6JHwNMn6RQ From: "Kulkarni, Amol" To: "Rap-wg (E-mail)" , "Uri Blumenthal (E-mail)" X-OriginalArrivalTime: 13 Nov 2003 21:40:30.0717 (UTC) FILETIME=[C2A2C2D0:01C3AA2E] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Uri, Thanks for reviewing the draft. I've made most of the changes you've asked for. However, I have some comments below... Thanks, Amol -----Original Message----- From: Uri Blumenthal [mailto:uri@lucent.com] Sent: donderdag 23 oktober 2003 23:58 To: Wijnen, Bert Cc: Blumenthal, Uri Subject: COPS etc.3.2.1. So is at least one protocol mandatory? And why is it valid to make them all optional? Bert, Sorry for prolonged silence - was sick and then took me time to get through the e-mail piles. Here's my review of COPS-06, please forward it to the appropriate AD and WG chair(s). =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= cops-06.txt GENERIC COMMENTS. I'd prefer the following important issues described somewhere: - key provisioning (how the initial/first keys get in); - key management/update; - key requirments. What kind of keys are accepted? Public Key in X.509 format only? Anything else? Any reason why neither symmetric keys nor password-based methods (such as SRP, or what's in SSL) are there? ------------- Amol> I assume the above points refer to the authentication keys used by the client and the 'insecure' COPS server. There is some description of the keys and how to use them in the original COPS RFC. However, the key provisioning and management has been left out as an implementation issue.=20 I'm not sure if I should use this draft to modify or clarify something that's essentially a COPS/TCP RFC issue. - policy - how it gets there, how it's processed, what it looks like, etc. Something comparable to VACM of SNMPv3... ---------- Amol> Again, I believe that policy specification is not within the scope of this draft. Maybe I should explicitly mention that? I found the text on Access Control exceedingly muddy/unclear. I'm coming from reasonably good understanding of Access Control, but shallow knowledge of COPS. Request rephrasing (and maiing it CLEARER). ------------ Amol> Are you referring to Section 5 or section 8? I've updated text in both sections, but I'd still like to know. 4.4. I'm not sure server (in the last case) should be allowed to just proceed establishing insecure connection. Perhaps better if the client decides how to proceed? ---------- Amol> I don't think so. The client, by indicating that a secure connection is optional, should be OK with the insecure connection being established.=20 From owner-rap@ops.ietf.org Sun Nov 23 23:13:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10501 for ; Sun, 23 Nov 2003 23:13:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AO84q-00072C-5d for rap-data@psg.com; Mon, 24 Nov 2003 04:11:56 +0000 Received: from [204.178.16.49] (helo=crufty.research.bell-labs.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AO84d-00071I-Di for rap@ops.ietf.org; Mon, 24 Nov 2003 04:11:43 +0000 Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id hAO4Bgxl054089 for ; Sun, 23 Nov 2003 23:11:42 -0500 (EST) Received: from zydeco.research.bell-labs.com (zydeco.research.bell-labs.com [135.104.120.150]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id hAO4Ba0C077987 for ; Sun, 23 Nov 2003 23:11:36 -0500 (EST) Received: from lucent.com (dhcp50109.cs.bell-labs.com [135.104.50.109]) by zydeco.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id hAO4BZX0025026 for ; Sun, 23 Nov 2003 23:11:35 -0500 (EST) Message-ID: <3FC184F7.4040506@lucent.com> Date: Sun, 23 Nov 2003 23:11:35 -0500 From: Madhur Kohli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: rap@ops.ietf.org Subject: Policy 2004: Call for Papers Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This CFP posted here, with permission of the WG chairs, to solicit participation from members of this community. -- Policy 2004: 5th IEEE International Workshop on Policies for Distributed Systems and Networks 7-9 June 2004 IBM T.J. Watson Research Centre, Yorktown Heights, New York. http://www.policy-workshop.org/2004/ The policy workshop aims to bring together researchers and practitioners working on policy-based systems across a wide range of application areas including policy-based networking, security management, storage area networking, and enterprise systems. Policy 2004 is the 5th in a series of successful workshops which since 1999 have provided a forum for discussion and collaboration between researchers, developers and users of policy-based systems. This year, in addition to the latest research results from the communities working in the areas mentioned above, we encourage contributions on policy-based techniques in support of: autonomic computing, ubiquitous systems and business rules. Policy 2004 invites contributions in the form of either: - Technical papers (max. length 10 pages). - Short position papers describing preliminary experimental results, experiences with deployed policy systems, and new applications and directions for policies (max. length 4 pages) Paper submission deadline: 19 December 2003 -- Madhur Kohli, Emil Lupu Program Co-chairs, Policy 2004 From owner-rap@ops.ietf.org Wed Nov 26 10:32:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12358 for ; Wed, 26 Nov 2003 10:32:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AP1e3-000ISR-DD for rap-data@psg.com; Wed, 26 Nov 2003 15:31:59 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AP1dr-000IRK-Gs for rap@ops.ietf.org; Wed, 26 Nov 2003 15:31:47 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12207; Wed, 26 Nov 2003 10:31:33 -0500 (EST) Message-Id: <200311261531.KAA12207@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rap@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rap-cops-tls-07.txt Date: Wed, 26 Nov 2003 10:31:33 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Sender: owner-rap@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Allocation Protocol Working Group of the IETF. Title : COPS Over TLS Author(s) : J. Walker, A. Kulkarni Filename : draft-ietf-rap-cops-tls-07.txt Pages : 11 Date : 2003-11-26 This memo describes how to use TLS to secure COPS connections over the Internet. Please send comments on this document to the rap@ops.ietf.org mailing list. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-cops-tls-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rap-cops-tls-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rap-cops-tls-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-11-26103701.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-cops-tls-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-cops-tls-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-11-26103701.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Fri Nov 28 04:49:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20090 for ; Fri, 28 Nov 2003 04:49:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1APfEM-0009hs-Er for rap-data@psg.com; Fri, 28 Nov 2003 09:48:06 +0000 Received: from [217.32.166.20] (helo=relhubc02-ukbr.tcrelay.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1APfE9-0009gj-96 for rap@ops.ietf.org; Fri, 28 Nov 2003 09:47:53 +0000 Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:42:02 +0000 Received: from asgard.ietf.org ([132.151.6.40]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 16:14:29 +0000 Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1AP1iV-0004On-Do for ietf-announce-list@asgard.ietf.org; Wed, 26 Nov 2003 10:36:35 -0500 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1AP1ds-0004LS-2y for all-ietf@asgard.ietf.org; Wed, 26 Nov 2003 10:31:48 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12207; Wed, 26 Nov 2003 10:31:33 -0500 (EST) Message-Id: <200311261531.KAA12207@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rap@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rap-cops-tls-07.txt Date: Wed, 26 Nov 2003 10:31:33 -0500 X-OriginalArrivalTime: 26 Nov 2003 16:14:33.0566 (UTC) FILETIME=[610917E0:01C3B438] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Sender: owner-rap@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Allocation Protocol Working Group of the IETF. Title : COPS Over TLS Author(s) : J. Walker, A. Kulkarni Filename : draft-ietf-rap-cops-tls-07.txt Pages : 11 Date : 2003-11-26 This memo describes how to use TLS to secure COPS connections over the Internet. Please send comments on this document to the rap@ops.ietf.org mailing list. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-cops-tls-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rap-cops-tls-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rap-cops-tls-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-11-26103701.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-cops-tls-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-cops-tls-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-11-26103701.I-D@ietf.org> --OtherAccess-- --NextPart--