From owner-rap@ops.ietf.org Thu Feb 3 18:06:19 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03659 for ; Thu, 3 Feb 2005 18:06:19 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Cwq1w-0002nt-Vp for rap-data@psg.com; Thu, 03 Feb 2005 23:04:56 +0000 Received: from [192.11.222.163] (helo=ihemail2.lucent.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Cwq1u-0002mc-Pi for rap@ops.ietf.org; Thu, 03 Feb 2005 23:04:54 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j13N4q5L022064 for ; Thu, 3 Feb 2005 17:04:53 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 4 Feb 2005 00:04:51 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503C7A08E@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'amol.kulkarni@intel.com'" , "'jesse.walker@intel.com'" Cc: "Scott Hahn (E-mail)" , "Rap-wg (E-mail)" Subject: Status of: Date: Fri, 4 Feb 2005 00:04:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-rap@ops.ietf.org Precedence: bulk The doc is still in IETF Last Call (up till Feb 08). However, the IESG did discuss it on the IESG telechat today. Here are the comments: Harald Alvestrand: Comment: [2005-02-03] Reviewed by Lucy Lynch, Gen-ART No show-stopper comments. Review in document comments. See http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-rap-cops-tls-10-lynch.txt Basically that says everything is fine, module the RFC-Editor notes that I already have recorded (quite a list). Sam Hartman: Comment: [2005-02-03] Section 9 of rfc 2246 says: In the absence of an application profile standard specifying otherwise, a TLS compliant application MUST implement the cipher suite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA. Are you sure that's the cipher you want to require people to implement? RSA seems more common today. If that's what you want the current text is fine. So pls let me know if you were indeed aware of that and if that is what you want. I propose that the authors prepare a new revision with any changes they may want to make because of the above, plus the changes below (as discussed earlier). Then be ready to submit to internet-drafts@ietf.org BEFORE noon US Eastern on Monday, so it will get posted on Monday and so that we can get it approved on Tuesday. Note that I will be offline for an extended period of time after Tuesday (my tuesday in Europe). Bert on first Page (Status of this Memo): OLD TEXT: --------- ...section 3 of RFC 3667 [RFC3667]. By submitting this... NEW TEXT: --------- ...section 3 of RFC 3667. By submitting this... ==================================== Section 5.1 OLD TEXT: ---------- ::= [] [] NEW TEXT: --------- ::= [] [] Note also that this new format of the Client-Accept message does not replace or obsolete the existing Client-Accept message format, which can continue to be used for non-secure COPS session negotiations. ====================================== Section 9 OLD TEXT: ---------- For the Integrity-TLS object for Client-Type 0, the IANA shall add the following Flags value: 0x01 = StartTLS NEW TEXT: ---------- The IANA shall add the following C-Num, C-Type combination for the Integrity-TLS object to the registry at http://www.iana.org/assignments/cops-parameters: 0x10 0x02 Message Integrity, Integrity-TLS [RFCxxxx] For Client-Type 0, the IANA shall add the following Flags value for the Integrity-TLS object: 0x01 = StartTLS Further, for Client-Type 0, the IANA shall add the following text for Error Sub-Codes: Error Code: 15 Error Sub-Code: Octet 2: C-Num of the Integrity object Octet 3: C-Type of the supported/preferred Integrity object or Zero. Error-Code Error-SubCode Description Octet 2 Octet 3 --------------------------------------------------- 15 16 0 No security 15 16 2 Integrity-TLS supported/preferred ===================================== Section 11.1 OLD TEXT: --------- [RFC2026] Bradner, S., "The Internet Standards Process - Revision 3", RFC 2026, October 1996 NEW TEXT: --------- (delete OLD TEXT) OLD TEXT: ---------- [RFC3280]... NEW TEXT (add citation before RFC3280 citation): ------------------------------------------------- [RFC2753] Yavatkar, R., Pendarakis, D., Guerin, R., "A Framework for Policy-based Admission Control", RFC 2753, January 2000. [RFC3280]... ============================== Section 11.2 OLD TEXT: --------- [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002. NEW TEXT: --------- (delete OLD TEXT) From owner-rap@ops.ietf.org Thu Feb 3 18:09:00 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04117 for ; Thu, 3 Feb 2005 18:08:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Cwq5G-0003bm-RD for rap-data@psg.com; Thu, 03 Feb 2005 23:08:22 +0000 Received: from [192.11.222.163] (helo=ihemail2.lucent.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Cwq5E-0003bU-Kq for rap@ops.ietf.org; Thu, 03 Feb 2005 23:08:20 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j13N8IjF023648 for ; Thu, 3 Feb 2005 17:08:19 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 4 Feb 2005 00:08:17 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503C7A090@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Rap-wg (E-mail)" Subject: Status of: draft-ietf-rap-cops-tls-10.txt Date: Fri, 4 Feb 2005 00:08:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-rap@ops.ietf.org Precedence: bulk Now with proper subject line. -----Original Message----- From: Wijnen, Bert (Bert) Sent: Friday, February 04, 2005 00:05 To: 'amol.kulkarni@intel.com'; 'jesse.walker@intel.com' Cc: Scott Hahn (E-mail); Rap-wg (E-mail) Subject: Status of: The doc is still in IETF Last Call (up till Feb 08). However, the IESG did discuss it on the IESG telechat today. Here are the comments: Harald Alvestrand: Comment: [2005-02-03] Reviewed by Lucy Lynch, Gen-ART No show-stopper comments. Review in document comments. See http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-rap-cops-tls-10-lynch.txt Basically that says everything is fine, module the RFC-Editor notes that I already have recorded (quite a list). Sam Hartman: Comment: [2005-02-03] Section 9 of rfc 2246 says: In the absence of an application profile standard specifying otherwise, a TLS compliant application MUST implement the cipher suite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA. Are you sure that's the cipher you want to require people to implement? RSA seems more common today. If that's what you want the current text is fine. So pls let me know if you were indeed aware of that and if that is what you want. I propose that the authors prepare a new revision with any changes they may want to make because of the above, plus the changes below (as discussed earlier). Then be ready to submit to internet-drafts@ietf.org BEFORE noon US Eastern on Monday, so it will get posted on Monday and so that we can get it approved on Tuesday. Note that I will be offline for an extended period of time after Tuesday (my tuesday in Europe). Bert on first Page (Status of this Memo): OLD TEXT: --------- ...section 3 of RFC 3667 [RFC3667]. By submitting this... NEW TEXT: --------- ...section 3 of RFC 3667. By submitting this... ==================================== Section 5.1 OLD TEXT: ---------- ::= [] [] NEW TEXT: --------- ::= [] [] Note also that this new format of the Client-Accept message does not replace or obsolete the existing Client-Accept message format, which can continue to be used for non-secure COPS session negotiations. ====================================== Section 9 OLD TEXT: ---------- For the Integrity-TLS object for Client-Type 0, the IANA shall add the following Flags value: 0x01 = StartTLS NEW TEXT: ---------- The IANA shall add the following C-Num, C-Type combination for the Integrity-TLS object to the registry at http://www.iana.org/assignments/cops-parameters: 0x10 0x02 Message Integrity, Integrity-TLS [RFCxxxx] For Client-Type 0, the IANA shall add the following Flags value for the Integrity-TLS object: 0x01 = StartTLS Further, for Client-Type 0, the IANA shall add the following text for Error Sub-Codes: Error Code: 15 Error Sub-Code: Octet 2: C-Num of the Integrity object Octet 3: C-Type of the supported/preferred Integrity object or Zero. Error-Code Error-SubCode Description Octet 2 Octet 3 --------------------------------------------------- 15 16 0 No security 15 16 2 Integrity-TLS supported/preferred ===================================== Section 11.1 OLD TEXT: --------- [RFC2026] Bradner, S., "The Internet Standards Process - Revision 3", RFC 2026, October 1996 NEW TEXT: --------- (delete OLD TEXT) OLD TEXT: ---------- [RFC3280]... NEW TEXT (add citation before RFC3280 citation): ------------------------------------------------- [RFC2753] Yavatkar, R., Pendarakis, D., Guerin, R., "A Framework for Policy-based Admission Control", RFC 2753, January 2000. [RFC3280]... ============================== Section 11.2 OLD TEXT: --------- [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002. NEW TEXT: --------- (delete OLD TEXT) From owner-rap@ops.ietf.org Tue Feb 8 15:43:23 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15737 for ; Tue, 8 Feb 2005 15:43:23 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1Cyc9l-000IzI-SB for rap-data@psg.com; Tue, 08 Feb 2005 20:40:21 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1Cyc9i-000Iya-St for rap@ops.ietf.org; Tue, 08 Feb 2005 20:40:19 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15360; Tue, 8 Feb 2005 15:40:16 -0500 (EST) Message-Id: <200502082040.PAA15360@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: rap@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rap-cops-tls-11.txt Date: Tue, 08 Feb 2005 15:40:16 -0500 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.0.1 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-11.txt Pages : 12 Date : 2005-2-8 This document describes how to use Transport Layer Security (TLS) to secure Common Open Policy Service (COPS) connections over the Internet. This document also updates RFC 2748 by modifying the contents of the Client-Accept message. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-cops-tls-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-11.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-11.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: <2005-2-8160521.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-cops-tls-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-cops-tls-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-8160521.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Sun Feb 13 05:30:49 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11290 for ; Sun, 13 Feb 2005 05:30:49 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D0Gzm-000F7a-U6 for rap-data@psg.com; Sun, 13 Feb 2005 10:28:54 +0000 Received: from [64.168.64.114] (helo=slepton.muonics.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D0Gzk-000F72-TX for rap@ops.ietf.org; Sun, 13 Feb 2005 10:28:53 +0000 Received-SPF: Received-SPF: pass (slepton.muonics.com: domain of mikek@muonics.com designates 64.168.64.114 as permitted sender) receiver=slepton.muonics.com; client_ip=64.168.64.114; envelope-from=mikek@muonics.com; Received: from slepton.muonics.com (slepton.muonics.com [64.168.64.114]) by slepton.muonics.com (8.13.2/8.13.2) with ESMTP id j1DAHLtJ083019 for ; Sun, 13 Feb 2005 02:17:22 -0800 (PST) Date: Sun, 13 Feb 2005 02:17:07 -0800 (PST) From: Michael Kirkham To: rap@ops.ietf.org Subject: FRAMEWORK-FEEDBACK-PIB (RFC 3571) errata Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,UPPERCASE_25_50 autolearn=no version=3.0.1 Sender: owner-rap@ops.ietf.org Precedence: bulk Updating my MIB/PIB repository, I came across this item again. Looking back in the archive it seems I didn't bring it up the last time I saw it. MIB Smithy generates the following warning and error for FRAMEWORK-FEEDBACK-PIB: FRAMEWORK-FEEDBACK-PIB.mib [FRAMEWORK-FEEDBACK-PIB] : warning : SMIv2 macros/base types cannot be imported in COPS-PR-SPPI modules, nor vise-versa. FRAMEWORK-FEEDBACK-PIB.mib [FRAMEWORK-FEEDBACK-PIB:Usage64] : error : 'Unsigned64' data type is only supported by COPS-PR-SPPI. What happens here is it sees you've imported TEXTUAL-CONVENTION from SNMPv2-TC and uses SMIv2 rules to validate the Usage64 TEXTUAL-CONVENTION, in which the Unsigned64 data type is not allowed. FRAMEWORK-FEEDBACK-PIB should import TEXTUAL-CONVENTION from COPS-PR-SPPI-TC rather than SNMPv2-TC. The warning probably ought to be an error too, but it's somewhat iffy as it's not specifically stated in the specs and there is overlap between the base types and their encodings (except Unsigned64). -- Michael Kirkham www.muonics.com From owner-rap@ops.ietf.org Sun Feb 13 05:31:22 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11345 for ; Sun, 13 Feb 2005 05:31:22 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D0H1Z-000FIw-Ah for rap-data@psg.com; Sun, 13 Feb 2005 10:30:45 +0000 Received: from [64.168.64.114] (helo=slepton.muonics.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D0H1Y-000FIk-Dn for rap@ops.ietf.org; Sun, 13 Feb 2005 10:30:44 +0000 Received-SPF: Received-SPF: pass (slepton.muonics.com: domain of mikek@muonics.com designates 64.168.64.114 as permitted sender) receiver=slepton.muonics.com; client_ip=64.168.64.114; envelope-from=mikek@muonics.com; Received: from slepton.muonics.com (slepton.muonics.com [64.168.64.114]) by slepton.muonics.com (8.13.2/8.13.2) with ESMTP id j1DAJFjW083028 for ; Sun, 13 Feb 2005 02:19:16 -0800 (PST) Date: Sun, 13 Feb 2005 02:19:10 -0800 (PST) From: Michael Kirkham To: rap@ops.ietf.org Subject: Re: FRAMEWORK-FEEDBACK-PIB (RFC 3571) errata In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_05,UPPERCASE_25_50 autolearn=no version=3.0.1 Sender: owner-rap@ops.ietf.org Precedence: bulk Oops. I mean should import from COPS-PR-SPPI. Also the warning is iffy because importing non-base types from MIBs is allowed - I think that's probably why I made it a warning. On Sun, 13 Feb 2005, Michael Kirkham wrote: > Date: Sun, 13 Feb 2005 02:17:07 -0800 (PST) > From: Michael Kirkham > To: rap@ops.ietf.org > Subject: FRAMEWORK-FEEDBACK-PIB (RFC 3571) errata > > > Updating my MIB/PIB repository, I came across this item again. Looking back > in the archive it seems I didn't bring it up the last time I saw it. MIB > Smithy generates the following warning and error for FRAMEWORK-FEEDBACK-PIB: > > FRAMEWORK-FEEDBACK-PIB.mib [FRAMEWORK-FEEDBACK-PIB] : warning : SMIv2 > macros/base types cannot be imported in COPS-PR-SPPI modules, nor vise-versa. > FRAMEWORK-FEEDBACK-PIB.mib [FRAMEWORK-FEEDBACK-PIB:Usage64] : error : > 'Unsigned64' data type is only supported by COPS-PR-SPPI. > > What happens here is it sees you've imported TEXTUAL-CONVENTION from > SNMPv2-TC and uses SMIv2 rules to validate the Usage64 TEXTUAL-CONVENTION, in > which the Unsigned64 data type is not allowed. FRAMEWORK-FEEDBACK-PIB should > import TEXTUAL-CONVENTION from COPS-PR-SPPI-TC rather than SNMPv2-TC. The > warning probably ought to be an error too, but it's somewhat iffy as it's not > specifically stated in the specs and there is overlap between the base types > and their encodings (except Unsigned64). > > -- > Michael Kirkham > www.muonics.com > -- Michael Kirkham www.muonics.com