From owner-rap@ops.ietf.org Thu Aug 26 15:36:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00989 for ; Thu, 26 Aug 2004 15:36:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C0Q1R-0006Gq-9L for rap-data@psg.com; Thu, 26 Aug 2004 19:34:57 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C0Q1G-0006EN-Fa for rap@ops.ietf.org; Thu, 26 Aug 2004 19:34:46 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00886; Thu, 26 Aug 2004 15:34:44 -0400 (EDT) Message-Id: <200408261934.PAA00886@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-08.txt Date: Thu, 26 Aug 2004 15:34:44 -0400 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.64 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-08.txt Pages : 11 Date : 2004-8-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-08.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-08.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-08.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: <2004-8-26150724.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-cops-tls-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-cops-tls-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-26150724.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Tue Aug 31 12:45:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03708 for ; Tue, 31 Aug 2004 12:45:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C2BjZ-000ORk-Jb for rap-data@psg.com; Tue, 31 Aug 2004 16:43:49 +0000 Received: from [192.11.226.161] (helo=hoemail1.lucent.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C2BjO-000OR7-Ta for rap@ops.ietf.org; Tue, 31 Aug 2004 16:43:39 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i7VGhaxn001168 for ; Tue, 31 Aug 2004 11:43:36 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 31 Aug 2004 18:43:35 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550516F391@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Kulkarni, Amol" , "Hahn, Scott" Cc: "Rap-wg (E-mail)" Subject: AD review: draft-ietf-rap-cops-tls-08.txt submission Date: Tue, 31 Aug 2004 18:43:34 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-rap@ops.ietf.org Precedence: bulk Here is what I found 1. Sect 4.1, it is unclear what kind of field the FLAGS field is is it a bitmask? an Unsigned16, or what? If a bit field, which bit indicates the TLS flag? I also wonder if the flag would not be better called StartTLS, but that is a nit. 2. Same sect 4,1 Also, I guess the ///// field is a reserved field? If so, I would make that clear, and I would state that it must be set to zero in transmit and be ignored on receipt. 3. I had this comment/question back inmarch of this year as well and have not yet seen a response: Section 7 states that the non-well-know port needs to be communicated by the server to the client. But it does not explain how. Am I missing something here? 4. You may want to add to the IANA considerations section that the registry is located at: http://www.iana.org/assignments/cops-parameters That is where they are supposed to add the error code. 5. Assigning value 16 as an error code is something that the WG should not do. The proper procedure is to mark it as a error-code-TBD-by-IANA and then ask IANA to assign and then RFC-Editor will fill in the numbers. I am not aware that other on-going work is taking place in this area, so the risk for conflicts is probably low. 6. I also still wonder: that StartTLS ClientSI object... who controls assignment of additional flags in the future? x. You are now (changing) defining protocol messages for COPS. In sect 5 you change the ClientAccept. So I wonder: - does this doc UPDATE RFC2748 as a result? it seems to me it does and so it should state so and mention so in the abstract if we indeed agree - if we define protocol extensions to RFC2748, should this not be a stds track document instead of informational Certainly if it updates 2748, it should be stds track I think. - The fact that this document fills in the "how to" for the last para in the security considerations section of RFC2748 may be another reason to make this stds track. admin nits. - There should be no reference to RFC2026, nor should their be a citation in the front matter. See www.ietf.org/ID-Checklist.html sect 2.1 item 7. - If you do do a respin, better use the text from RFC3667/3668 anyway. Thanks, Bert