From owner-malloc@catarina.usc.edu Mon Nov 9 18:20:15 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id SAA05810 for ; Mon, 9 Nov 1998 18:20:14 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id OAA20030 for malloc-list; Mon, 9 Nov 1998 14:33:38 -0800 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id OAA20026 for ; Mon, 9 Nov 1998 14:33:33 -0800 Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA12143 for ; Mon, 9 Nov 1998 14:33:01 -0800 Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id RAA23786; Mon, 9 Nov 1998 17:32:57 -0500 Received: from bcn.East.Sun.COM (bcn [129.148.75.4]) by suneast.East.Sun.COM (8.9.1b+Sun/8.8.8) with SMTP id RAA05881 for ; Mon, 9 Nov 1998 17:32:58 -0500 (EST) Received: from pine by bcn.East.Sun.COM (SMI-8.6/SMI-SVR4) id RAA07243; Mon, 9 Nov 1998 17:32:55 -0500 Message-Id: <199811092232.RAA07243@bcn.East.Sun.COM> Date: Mon, 9 Nov 1998 17:32:57 -0500 (EST) From: Steve Hanna Reply-To: Steve Hanna Subject: Revised MDHCP spec To: malloc@catarina.usc.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 1QX02alXaaWpKgjKdOEjrw== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-malloc@catarina.usc.edu Precedence: bulk I have just submitted a revised version of the MDHCP spec to the Internet Drafts editor, so it should show up on the IETF site eventually. For now, I have placed a copy of the spec on the malloc web site. You can download it from http://north.east.isi.edu/malloc/draft-ietf-malloc-mdhcp-01.txt This revision closes almost all of the open issues in the previous draft. A summary of the changes included in this revision appears at the end of this note. Comments are welcome and should be directed to the malloc mailing list. Thanks, Steve Hanna --------------- CHANGES FROM draft-ietf-malloc-mdhcp-00.txt Port number assigned. Removed unused chaddr, sname, and file fields. Split MDHCP option space from DHCP. Changed technique for choosing MDHCP Server Multicast Addresses when initial requests fail. Added Requested Language option. Added language tags and multiple names per zone to the Multicast Scope List option. From owner-malloc@catarina.usc.edu Wed Nov 11 10:25:13 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id KAA02443 for ; Wed, 11 Nov 1998 10:25:12 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id GAA28131 for malloc-list; Wed, 11 Nov 1998 06:46:36 -0800 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id GAA28127 for ; Wed, 11 Nov 1998 06:46:31 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA00760; Wed, 11 Nov 1998 09:45:57 -0500 (EST) Message-Id: <199811111445.JAA00760@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: malloc@catarina.usc.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-malloc-mdhcp-01.txt Date: Wed, 11 Nov 1998 09:45:56 -0500 Sender: owner-malloc@catarina.usc.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multicast-Address Allocation Working Group of the IETF. Title : Multicast address allocation based on the Dynamic Host Configuration Protocol Author(s) : B. Patel, M. Shah, S. Hanna Filename : draft-ietf-malloc-mdhcp-01.txt Pages : 30 Date : 10-Nov-98 This document defines a protocol, MDHCP, that allows hosts to request multicast addresses from multicast address allocation servers. MDHCP is similar to DHCP, but not dependent on it. Internet-Drafts are 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-malloc-mdhcp-01.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-malloc-mdhcp-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nic.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-malloc-mdhcp-01.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: <19981110132113.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-malloc-mdhcp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-malloc-mdhcp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981110132113.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-malloc@catarina.usc.edu Wed Nov 11 14:50:02 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id OAA17488 for ; Wed, 11 Nov 1998 14:50:01 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id KAA29250 for malloc-list; Wed, 11 Nov 1998 10:59:14 -0800 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id KAA29246 for ; Wed, 11 Nov 1998 10:59:10 -0800 Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA10812 for ; Wed, 11 Nov 1998 10:58:38 -0800 Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id NAA26597; Wed, 11 Nov 1998 13:58:35 -0500 Received: from bcn.East.Sun.COM (bcn [129.148.75.4]) by suneast.East.Sun.COM (8.9.1b+Sun/8.8.8) with SMTP id NAA11308 for ; Wed, 11 Nov 1998 13:58:35 -0500 (EST) Received: from pine by bcn.East.Sun.COM (SMI-8.6/SMI-SVR4) id NAA15436; Wed, 11 Nov 1998 13:58:32 -0500 Message-Id: <199811111858.NAA15436@bcn.East.Sun.COM> Date: Wed, 11 Nov 1998 13:58:34 -0500 (EST) From: Steve Hanna Reply-To: Steve Hanna Subject: 43rd IETF-ORLANDO, FL: MALLOC To: malloc@catarina.usc.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 5YS/3WbZDFa7kJx4WyNWow== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-malloc@catarina.usc.edu Precedence: bulk Here's our time slot for IETF 43. Please send topics for the MALLOC agenda to me. I will summarize to the list. Thanks, Steve ------------- Begin Forwarded Message ------------- X-Sender: mbeaulie@odin.cnri.reston.va.us Date: Wed, 11 Nov 1998 13:41:34 -0500 To: Steve Hanna From: Marcia Beaulieu Subject: 43rd IETF-ORLANDO, FL: MALLOC Cc: sob@harvard.edu, vern@ee.lbl.gov, burgan@home.net, narten@raleigh.ibm.com, thalerd@eecs.umich.edu Mime-Version: 1.0 This is to confirm one session for MALLOC as follows: Thursday, December 10 at 0900-1130 (other groups scheduled at that time: rps, manet, icann-BOF, ion) Please submit an agenda for these meeting as soon as possible, the deadline for submitting the agenda is November 30 at 1200 noon ET. Thanks, Marcia ********************************************************************** Marcia Beaulieu Meeting Coordinator Voice: 703-620-8990 ext. 210 Fax: 703-620-9071 ------------- End Forwarded Message ------------- From owner-malloc@catarina.usc.edu Wed Nov 18 05:22:34 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id FAA24358 for ; Wed, 18 Nov 1998 05:22:33 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id BAA27863 for malloc-list; Wed, 18 Nov 1998 01:39:23 -0800 Received: from proxy4.ba.best.com (root@proxy4.ba.best.com [206.184.139.15]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id BAA27859 for ; Wed, 18 Nov 1998 01:39:18 -0800 Received: from kaipara.live.com (kaipara.live.com [206.86.37.12]) by proxy4.ba.best.com (8.9.0/8.9.0/best.out) with SMTP id BAA08573 for ; Wed, 18 Nov 1998 01:38:14 -0800 (PST) Message-Id: <3.0.5.16.19981118023021.0c57d7f6@shell7.ba.best.com> X-Sender: rsf@shell7.ba.best.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (16) Date: Wed, 18 Nov 1998 02:30:21 To: malloc@catarina.usc.edu From: Ross Finlayson Subject: Updated MALLOC "abstract API" draft Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-malloc@catarina.usc.edu Precedence: bulk FYI, I have recently submitted an updated version of the "abstract API" draft: "draft-ietf-malloc-api-04.txt". The major changes are: - Inclusion of "language tags", as discussed on the mailing list last month; - Description of the possible "try again" response to the advance allocation operation; - Addition of a brief "Security Considerations" section (which we'll need for this to eventually become a RFC). This new version is also available online at: Ross. From owner-malloc@catarina.usc.edu Fri Nov 20 18:13:14 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id SAA19478 for ; Fri, 20 Nov 1998 18:13:14 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id OAA09896 for malloc-list; Fri, 20 Nov 1998 14:28:34 -0800 Received: from mercury.Sun.COM ([192.9.25.1]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id OAA09892 for ; Fri, 20 Nov 1998 14:28:28 -0800 Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA23499; Fri, 20 Nov 1998 14:27:52 -0800 Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id RAA10670; Fri, 20 Nov 1998 17:27:33 -0500 Received: from bcn.East.Sun.COM (bcn [129.148.75.4]) by suneast.East.Sun.COM (8.9.1b+Sun/8.8.8) with SMTP id RAA03467; Fri, 20 Nov 1998 17:27:34 -0500 (EST) Received: from pine by bcn.East.Sun.COM (SMI-8.6/SMI-SVR4) id RAA20300; Fri, 20 Nov 1998 17:27:31 -0500 Message-Id: <199811202227.RAA20300@bcn.East.Sun.COM> Date: Fri, 20 Nov 1998 17:27:33 -0500 (EST) From: Steve Hanna Reply-To: Steve Hanna Subject: MDHCP review To: dhcp-v4@bucknell.edu Cc: malloc@catarina.usc.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: PwfXRVsXgUPMfpvxfikIJw== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-malloc@catarina.usc.edu Precedence: bulk In the malloc working group, we have been working on a protocol that hosts may use to allocate multicast addresses (or perform other related operations). This protocol, MDHCP, is described in draft-ietf-malloc-mdhcp-01.txt. Originally, this protocol was a minor variation on DHCP and the idea was that a DHCP client or server implementation could also serve as an MDHCP implementation with minor changes. Over time, the protocol has become more and more different from DHCP (fields removed from header, different option space). However, we have attempted to keep the protocol similar to DHCP in order to allow code sharing. The question has arisen within the malloc working group: "Should we continue to maintain a similarity between MDHCP and DHCP?" Eliminating this design constraint would allow us to make MDHCP simpler and more efficient. However, it would also eliminate any remaining hope for sharing code between MDHCP and DHCP implementations. I would like to ask people who have implemented DHCP clients or servers to examine the current MDHCP draft (available from ftp://ftp.ietf.org/internet-drafts/draft-ietf-malloc-mdhcp-01.txt) and answer the following questions. 1) Do you think that you might implement an MDHCP client or server? 2) If you were to do so, would you attempt to share code with your DHCP client or server? 3) Do you think that we should continue to maintain a similarity between MDHCP and DHCP? Why or why not? Please send answers to the malloc mailing list (malloc@catarina.usc.edu). Thanks, Steve Hanna malloc WG co-chair From owner-malloc@catarina.usc.edu Fri Nov 20 19:32:40 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id TAA22142 for ; Fri, 20 Nov 1998 19:32:39 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id PAA10100 for malloc-list; Fri, 20 Nov 1998 15:49:24 -0800 Received: from mailhub.fokus.gmd.de ([193.174.154.14]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id PAA10096 for ; Fri, 20 Nov 1998 15:49:11 -0800 Received: from dumbo.fokus.gmd.de (dumbo [193.175.132.239]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id AAA00649; Sat, 21 Nov 1998 00:48:58 +0100 (MET) From: Mikhail Smirnov Received: (mis@localhost) by dumbo.fokus.gmd.de (SMI-8.6/8.6.12) id AAA07353; Sat, 21 Nov 1998 00:48:54 +0100 Date: Sat, 21 Nov 1998 00:48:54 +0100 Message-Id: <199811202348.AAA07353@dumbo.fokus.gmd.de > To: shanna@bcn.East.Sun.COM Subject: Re: MDHCP review Cc: smirnow@fokus.gmd.de, malloc@catarina.usc.edu X-Sun-Charset: US-ASCII Sender: owner-malloc@catarina.usc.edu Precedence: bulk Steve, I'm not an implementor, but IMHO your words > maintain a similarity between MDHCP and DHCP?" Eliminating this design > constraint would allow us to make MDHCP simpler and more efficient. provide a good answer to your questions. (and finally, code sharing is not a good design goal). regards Michael From owner-malloc@catarina.usc.edu Fri Nov 20 22:07:43 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id WAA00451 for ; Fri, 20 Nov 1998 22:07:42 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id SAA10625 for malloc-list; Fri, 20 Nov 1998 18:47:46 -0800 Received: from dip.eecs.umich.edu (thalerd@dip.eecs.umich.edu [141.212.99.5]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id SAA10621 for ; Fri, 20 Nov 1998 18:47:40 -0800 Received: (from thalerd@localhost) by dip.eecs.umich.edu (8.9.1/8.9.0) id VAA27119; Fri, 20 Nov 1998 21:47:33 -0500 (EST) From: Dave Thaler Message-Id: <199811210247.VAA27119@dip.eecs.umich.edu> Subject: Re: MDHCP review To: smirnow@fokus.gmd.de (Mikhail Smirnov) Date: Fri, 20 Nov 1998 21:47:33 -0500 (EST) Cc: shanna@bcn.East.Sun.COM, smirnow@fokus.gmd.de, malloc@catarina.usc.edu In-Reply-To: <199811202348.AAA07353@dumbo.fokus.gmd.de > from "Mikhail Smirnov" at Nov 21, 98 00:48:54 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk > (and finally, code sharing is not a good design goal). I disagree. For example, it is the primary reason that PIM-SM and PIM-DM continue to share packet formats and such, even though they are independent protocols. Cisco and gated have both proven the benefits of that decision. -Dave From owner-malloc@catarina.usc.edu Sat Nov 21 04:15:12 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id EAA13610 for ; Sat, 21 Nov 1998 04:15:11 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id AAA11528 for malloc-list; Sat, 21 Nov 1998 00:56:06 -0800 Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id AAA11524 for ; Sat, 21 Nov 1998 00:56:00 -0800 Received: (from vern@localhost) by daffy.ee.lbl.gov (8.9.1/8.9.1) id AAA03283; Sat, 21 Nov 1998 00:55:57 -0800 (PST) Message-Id: <199811210855.AAA03283@daffy.ee.lbl.gov> To: Dave Thaler Cc: malloc@catarina.usc.edu Subject: Re: MDHCP review In-reply-to: Your message of Fri, 20 Nov 1998 21:47:33 PST. Date: Sat, 21 Nov 1998 00:55:57 PST From: Vern Paxson Sender: owner-malloc@catarina.usc.edu Precedence: bulk > > (and finally, code sharing is not a good design goal). > > I disagree. For example, it is the primary reason that PIM-SM and PIM-DM > continue to share packet formats and such, even though they are > independent protocols. Cisco and gated have both proven the benefits of > that decision. I suspect Mikhail meant this more along the lines of "code sharing is not a *compelling* design goal" when designing things with considerably different functionality. Vern From owner-malloc@catarina.usc.edu Sat Nov 21 11:17:34 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id LAA15840 for ; Sat, 21 Nov 1998 11:17:34 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id HAA12363 for malloc-list; Sat, 21 Nov 1998 07:59:32 -0800 Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id HAA12359 for ; Sat, 21 Nov 1998 07:59:25 -0800 Received: from dumbo.fokus.gmd.de (dumbo [193.175.132.239]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id QAA11026; Sat, 21 Nov 1998 16:59:16 +0100 (MET) From: Mikhail Smirnov Received: (mis@localhost) by dumbo.fokus.gmd.de (SMI-8.6/8.6.12) id QAA07642; Sat, 21 Nov 1998 16:59:13 +0100 Date: Sat, 21 Nov 1998 16:59:13 +0100 Message-Id: <199811211559.QAA07642@dumbo.fokus.gmd.de > To: thalerd@eecs.umich.edu Subject: Re: MDHCP review Cc: shanna@bcn.East.Sun.COM, smirnow@fokus.gmd.de, malloc@catarina.usc.edu X-Sun-Charset: US-ASCII Sender: owner-malloc@catarina.usc.edu Precedence: bulk > > (and finally, code sharing is not a good design goal). > > I disagree. For example, it is the primary reason that PIM-SM and PIM-DM > continue to share packet formats and such, even though they are > independent protocols. Cisco and gated have both proven the benefits of > that decision. I agree, but this is not a code sharing but interworking and compatibility feature (1st of all re-use of functionality and, maybe but not necessary a re-use of some code). -Michael From owner-malloc@catarina.usc.edu Sat Nov 21 11:33:16 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id LAA16057 for ; Sat, 21 Nov 1998 11:33:15 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id IAA12392 for malloc-list; Sat, 21 Nov 1998 08:03:45 -0800 Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id IAA12388 for ; Sat, 21 Nov 1998 08:03:40 -0800 Received: from dumbo.fokus.gmd.de (dumbo [193.175.132.239]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id RAA11096; Sat, 21 Nov 1998 17:03:31 +0100 (MET) From: Mikhail Smirnov Received: (mis@localhost) by dumbo.fokus.gmd.de (SMI-8.6/8.6.12) id RAA07648; Sat, 21 Nov 1998 17:03:28 +0100 Date: Sat, 21 Nov 1998 17:03:28 +0100 Message-Id: <199811211603.RAA07648@dumbo.fokus.gmd.de > To: thalerd@eecs.umich.edu, vern@ee.lbl.gov Subject: Re: MDHCP review Cc: malloc@catarina.usc.edu X-Sun-Charset: US-ASCII Sender: owner-malloc@catarina.usc.edu Precedence: bulk on Sat Nov 21 09:58:02 1998 Vern Paxson wrote: > > > > (and finally, code sharing is not a good design goal). > > > > I disagree. For example, it is the primary reason that PIM-SM and PIM-DM > > continue to share packet formats and such, even though they are > > independent protocols. Cisco and gated have both proven the benefits of > > that decision. > > I suspect Mikhail meant this more along the lines of "code sharing is not a > *compelling* design goal" when designing things with considerably different > functionality. > absolutely! (Thanks Vern, I should read my mails bottom up then your reply would save me a message) - Michael From owner-malloc@catarina.usc.edu Sat Nov 21 13:25:12 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id NAA16696 for ; Sat, 21 Nov 1998 13:25:12 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id KAA12542 for malloc-list; Sat, 21 Nov 1998 10:06:34 -0800 Received: from carlsbad.usc.edu (carlsbad.usc.edu [128.125.51.5]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id KAA12538 for ; Sat, 21 Nov 1998 10:06:31 -0800 Received: (pavlin@localhost) by carlsbad.usc.edu (8.6.10/8.6.9) id KAA03585 for malloc@catarina.usc.edu; Sat, 21 Nov 1998 10:06:30 -0800 Received: from basil.cdt.luth.se (root@basil.cdt.luth.se [130.240.64.67]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id EAA12211 for ; Sat, 21 Nov 1998 04:18:27 -0800 Received: from salt (peppar@salt.cdt.luth.se [130.240.64.42]) by basil.cdt.luth.se (8.8.8/8.7.3) with ESMTP id NAA03823; Sat, 21 Nov 1998 13:18:07 +0100 (MET) Message-Id: <199811211218.NAA03823@basil.cdt.luth.se> To: finlayson@live.com cc: malloc@catarina.usc.edu, tech@marratech.com, roxycdt@basil.cdt.luth.se X-uri: http://www.cdt.luth.se/~peppar/ Subject: Comments on draft-ietf-malloc-api-04.txt Content-Transfer-Encoding: 8bit Date: Sat, 21 Nov 1998 13:18:07 +0100 From: Peter Parnes Sender: owner-malloc@catarina.usc.edu Precedence: bulk Hi Here are some comments on the "draft-ietf-malloc-api-04.txt" draft. If this have been discussed earlier on the malloc mailing list then just ignore my rambling :-) Internet-Drafts@ietf.org said: > [*] An open question is: Who is allowed to deallocate (or query or > change the lifetime of) a previously allocated multicast address? > This is an implementation-specific decision, dependent upon the > security policy of the host system, and is not specified in this > abstract API. One possible starting point, however, is the following: > A previously allocated multicast address can be deallocated > (or have > its lifetime queried or changed) by the same "principal", and > on the > same node, as that which originally allocated it. > ("principal" might, > for example, be a "user" in the host operating system.) >From a practical point of view, isn't that quite useless? I'm thinking of how easy it is to impersonate another "principal". A very simple proposal is instead to associate a secret key when the session is allocated and only those that can present that key can later "modify" the address-allocation? (But then we get into snooping problems instead :-/ ) What I'm questioning here is if the security issues really should be left for future implementations or be defined by the WG? > future allocation and not using the addresses Isn't this quite hard to enforce in todays MBone? What if a session announced is to start at some future point in time and this announcement is shown to a user and that user joins the session before it has started? Even if the user don't want to send any traffic to the session s/he most likely will send RTCP packets anyhow (for RTP based media of course). E.g. We usually announce our sessions for live lectures with times that exactly matches the times of the real lecture. This means that video transmission from the lecture room usually begins about 5-10 minutes before the actual start-time. It also means that listeners usually join in a couple of minutes before the lecture starts. Perhaps there is a need to separate the SDP active time from the actual mcast address allocation time? **** Other error messages. It might be useful to add something like a "server busy" error message to notify the client that there are currently to many request being thrown at the server at the same time (on the other hand this might not ever happen :-). /P From owner-malloc@catarina.usc.edu Sat Nov 21 20:37:57 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id UAA19623 for ; Sat, 21 Nov 1998 20:37:55 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id RAA13087 for malloc-list; Sat, 21 Nov 1998 17:14:56 -0800 Received: from dip.eecs.umich.edu (thalerd@[141.212.99.5]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id RAA13083 for ; Sat, 21 Nov 1998 17:14:51 -0800 Received: (from thalerd@localhost) by dip.eecs.umich.edu (8.9.1/8.9.0) id UAA05531; Sat, 21 Nov 1998 20:14:28 -0500 (EST) From: Dave Thaler Message-Id: <199811220114.UAA05531@dip.eecs.umich.edu> Subject: Re: Comments on draft-ietf-malloc-api-04.txt To: peppar@cdt.luth.se (Peter Parnes) Date: Sat, 21 Nov 1998 20:14:27 -0500 (EST) Cc: finlayson@live.com, malloc@catarina.usc.edu, tech@marratech.com, roxycdt@basil.cdt.luth.se In-Reply-To: <199811211218.NAA03823@basil.cdt.luth.se> from "Peter Parnes" at Nov 21, 98 01:18:07 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk > > A previously allocated multicast address can be deallocated > > (or have > > its lifetime queried or changed) by the same "principal", and > > on the > > same node, as that which originally allocated it. > > ("principal" might, > > for example, be a "user" in the host operating system.) > > >From a practical point of view, isn't that quite useless? I'm thinking of how > easy it is to impersonate another "principal". A very simple proposal is > instead to associate a secret key when the session is allocated and only those > that can present that key can later "modify" the address-allocation? (But then > we get into snooping problems instead :-/ ) > > What I'm questioning here is if the security issues really should be left for > future implementations or be defined by the WG? The WG could either decide that deallocation before the lease expires is a good thing, and take on the security problem associated with it. Or the WG could decide that deallocation before the lease expires is not worth it at this point. I'm interested in hearing the WG's opinions on this, and if Ross or someone else wanted to give a presentation at IETF on the tradeoffs, that'd be great. > > future allocation and not using the addresses > > Isn't this quite hard to enforce in todays MBone? What if a session announced > is to start at some future point in time and this announcement is shown to a > user and that user joins the session before it has started? Even if the user > don't want to send any traffic to the session s/he most likely will send RTCP > packets anyhow (for RTP based media of course). E.g. We usually announce our > sessions for live lectures with times that exactly matches the times of the > real lecture. This means that video transmission from the lecture room > usually begins about 5-10 minutes before the actual start-time. It also means > that listeners usually join in a couple of minutes before the lecture starts. This one has been discussed once before (but not at any great length, and I can't remember whether it was on the list or in a meeting), and the consensus at the time was that it is not a problem. This is equivalent to booking a meeting room at IETF. If you show up 30 minutes early, there may be another meeting going on in the room, and if you enter the room, others will see you. Likewise, if you join a multicast group early, some other session may be using it at the time, and others in that session may see you. It would be reasonable in my opinion, to suggest that address allocators may/should actually allocate 5-10 minutes on either end of the requested start and end times. I'm also interested in the WG's opinion on this as well, so thanks for bring this up again. > Other error messages. It might be useful to add something like a "server busy" > error message to notify the client that there are currently to many request > being thrown at the server at the same time (on the other hand this might not > ever happen :-). I'm not sure I understand how that would be used. If it's too busy, it probably wouldn't see the request to respond to. And I'm not sure what you're proposing that a client could do upon receiving such a message. -Dave From owner-malloc@catarina.usc.edu Mon Nov 23 13:52:31 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id NAA28898 for ; Mon, 23 Nov 1998 13:52:30 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id JAA18259 for malloc-list; Mon, 23 Nov 1998 09:35:32 -0800 Received: from mail2.pacbell.com (mail2.PacBell.COM [129.245.2.18]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id JAA18255 for ; Mon, 23 Nov 1998 09:35:27 -0800 Received: from msgnorth99.srv.pacbell.com .(msgnorth99.srv.PacBell.COM [129.245.215.152]) by mail2.PacBell.COM (8.8.5/8.8.5-pb970801) with ESMTP id JAA07604 for ; Mon, 23 Nov 1998 09:35:08 -0800 (PST) Received: by msgnorth99.srv.PacBell.COM with Internet Mail Service (5.5.2232.9) id ; Mon, 23 Nov 1998 09:34:55 -0800 Message-ID: <2F42142EAA6FD211B8FA0008C7A4F99C2B18EA@msgbay15.snfc370.PacBell.COM> From: "Hibbs, R BARR (PB-rbhibbs)" To: "'malloc@catarina.usc.edu'" Subject: MDHCP Questions Date: Mon, 23 Nov 1998 09:34:47 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-malloc@catarina.usc.edu Precedence: bulk Steve Hanna asked the following questions of the DHCP Working Group: 1) Do you think that you might implement an MDHCP client or server? 2) If you were to do so, would you attempt to share code with your DHCP client or server? 3) Do you think that we should continue to maintain a similarity between MDHCP and DHCP? Why or why not? In our enterprise, the services we offer to network clients depend upon the demand for those services and the willingness of the first client to pay a significant portion of the development cost; implementation costs are generally shared among all clients. So, if we implement an MDHCP server (our users would have to obtain a commercial client that implements MDHCP) it would be only if sufficient demand existed for it -- somewhat of a "chicken and egg" problem. I can anticipate that such a service might be requested in the future, but can't imagine when the demand for it will arise. When requested to implement an MDHCP server, we would most definitely attempt to share (or re-use) code with our DHCP server. There is sufficient similarity between the two protocols that such re-use seems prudent as a way of leveraging our investment in the development, implementation, and support infrastructure for DHCP. As for maintaining similarity between the two protocols, I see several relevant points: 1) By choosing to name the two protocols in a similar way, a casual observer would expect the similarities to extend beyond the name to message formats and protocol exchanges. If the two protocols diverge significantly by design, then I suggest that the name MDHCP be changed to avoid confusion with RFC 2131. 2) Again, if the protocols diverge significantly, then perhaps the message formats should avoid similarity and the protocol messages be renamed to avoid confusion with RFC 2131. 3) Instead of using the same format for options data as RFCs 2131 and 2132, consider coordinating the MDHCP options with the expanded options format now being [occasionally] discussed in the DHCP Futures Panel: by agreement between the two Working Groups, it would be possible to declare non-overlapping options space so that the questions raised about similar, but inexact, options and the re-use or overlay of option numbers becomes moot. --Barr Hibbs Pacific*Bell 666 Folsom Street, Room 1225 San Francisco, CA 94107-1384 +1-(415)-545-1576 From owner-malloc@catarina.usc.edu Wed Nov 25 16:59:38 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id QAA29702 for ; Wed, 25 Nov 1998 16:59:37 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id MAA00584 for malloc-list; Wed, 25 Nov 1998 12:30:10 -0800 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id MAA00580 for ; Wed, 25 Nov 1998 12:30:06 -0800 Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA15986 for ; Wed, 25 Nov 1998 12:29:34 -0800 Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id PAA18010; Wed, 25 Nov 1998 15:29:31 -0500 Received: from atlantic.East.Sun.COM (atlantic [129.148.21.1]) by suneast.East.Sun.COM (8.9.1b+Sun/8.8.8) with ESMTP id PAA10332; Wed, 25 Nov 1998 15:29:31 -0500 (EST) Received: from spg-east-004 (spg-east-004 [129.148.21.66]) by atlantic.East.Sun.COM (8.8.8+Sun+sa+re+hr/8.8.8) with SMTP id PAA20767; Wed, 25 Nov 1998 15:29:24 -0500 (EST) Date: Wed, 25 Nov 1998 15:29:21 -0500 (EST) From: Mike Carney - SNT Internet Engineering Reply-To: Mike Carney - SNT Internet Engineering Subject: Re: MDHCP review To: malloc@catarina.usc.edu Cc: shanna@bcn.East.Sun.COM In-Reply-To: "Your message with ID" <199811202227.RAA20300@bcn.East.Sun.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-malloc@catarina.usc.edu Precedence: bulk > In the malloc working group, we have been working on a protocol that hosts > may use to allocate multicast addresses (or perform other related > operations). This protocol, MDHCP, is described in > draft-ietf-malloc-mdhcp-01.txt. Ok, I've taken a look. I wonder why the BOOTP header is still specified (with all of the unused fields) when you've got a different port number and option name space from DHCP... Can't you just dump the BOOTP header? > > Originally, this protocol was a minor variation on DHCP and the idea was > that a DHCP client or server implementation could also serve as an MDHCP > implementation with minor changes. Over time, the protocol has become more > and more different from DHCP (fields removed from header, different option > space). However, we have attempted to keep the protocol similar to DHCP in > order to allow code sharing. > > The question has arisen within the malloc working group: "Should we continue > to maintain a similarity between MDHCP and DHCP?" Eliminating this design > constraint would allow us to make MDHCP simpler and more efficient. However, > it would also eliminate any remaining hope for sharing code between MDHCP > and DHCP implementations. The questions below seem to indicate that one would likely want to co-locate the management of multicast addresses with unicast addresses under a single DHCP service. First, I'd like to say I don't agree with this explicit co-locating of address management. Multicast allocation / management will likely occur at a site / enterprise level, whereas unicast allocation / management is a departmental problem. And these tasks would likely be handled by different organizations. Thus, I don't see any benefit of sharing code - the applications are different. DHCP has a much larger problem to solve that MDHCP; thus I'm surprised that you'd want to carry lots of excess DHCP baggage in order to provide multicast address management. All for services that you'd likely not co-locate. Thus, the code-sharing argument seems specious to me, particularly since the code to parse the options field in a DHCP implementation is on the order of 100 lines. Providing management/administration of both DHCP/MDHCP in a way that would not be confusing to users would be another challenge. IMHO, I think the malloc group would be better off considering a protocol whose primary goal is the delivery and management of multicast addresses in the way that meets the needs of the folks that deal in multicast services. I think you're unnecessarily limiting yourselves by having as a major goal close simularity to DHCP. Such considerations should be secondary. As you've seen, MDHCP started out being very close to DHCP, but over time has diverged. Shouldn't that divergence prompt you to consider whether MDHCP will be adequate in the long run? > > I would like to ask people who have implemented DHCP clients or servers to > examine the current MDHCP draft (available from > ftp://ftp.ietf.org/internet-drafts/draft-ietf-malloc-mdhcp-01.txt) and > answer the following questions. > > 1) Do you think that you might implement an MDHCP client or server? If MDHCP becomes the IETF direction for the management and delivery of multicast addresses, sure. However, it likely wouldn't be co-located with our DHCP service. There might be sharing of database services. But note that this sharing would have nothing to do with the protocol on the wire. > > 2) If you were to do so, would you attempt to share code with your DHCP > client or server? Sure, the 100 or so lines to parse the packet. Obviously, this wouldn't be a major draw. > > 3) Do you think that we should continue to maintain a similarity between > MDHCP and DHCP? Why or why not? See my above statements. I believe you should be looking at what's best for the multicast community as a whole, taking into account the folks (your customers) that'll likely be dealing with your protocol(s) on a day to day basis. > > Please send answers to the malloc mailing list (malloc@catarina.usc.edu). > > Thanks, > > Steve Hanna > malloc WG co-chair > Mike Carney SNT Internet Engineering Sun Microsystems, Inc. From owner-malloc@catarina.usc.edu Thu Nov 26 08:10:40 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id IAA26342 for ; Thu, 26 Nov 1998 08:10:39 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id EAA03805 for malloc-list; Thu, 26 Nov 1998 04:23:52 -0800 Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id EAA03801 for ; Thu, 26 Nov 1998 04:23:34 -0800 Received: from dumbo.fokus.gmd.de (dumbo [193.175.132.239]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id NAA17892; Thu, 26 Nov 1998 13:23:21 +0100 (MET) From: Mikhail Smirnov Received: (mis@localhost) by dumbo.fokus.gmd.de (SMI-8.6/8.6.12) id NAA10886; Thu, 26 Nov 1998 13:23:18 +0100 Date: Thu, 26 Nov 1998 13:23:18 +0100 Message-Id: <199811261223.NAA10886@dumbo.fokus.gmd.de > To: malloc@catarina.usc.edu, Michael.Carney@East.Sun.COM Subject: malloc service model (was: MDHCP review) Cc: shanna@bcn.East.Sun.COM, smirnow@fokus.gmd.de X-Sun-Charset: US-ASCII Sender: owner-malloc@catarina.usc.edu Precedence: bulk On Wed, 25 Nov 1998 15:29:21 -0500 (EST) Mike Carney wrote: <...> > IMHO, I think the malloc group would be better off considering a protocol whose > primary goal is the delivery and management of multicast addresses in the way > that meets the needs of the folks that deal in multicast services. <...> > See my above statements. I believe you should be looking at what's best for > the multicast community as a whole, taking into account the folks (your > customers) that'll likely be dealing with your protocol(s) on a day to day > basis. I think these thoughts are in line with the malloc objectives: "...mechanisms for enforcing policies for multicast address allocation may be considered ..." [http://www.ietf.org/html.charters/malloc-charter.html]. Do we have any document fixing malloc's current understanding of what "the needs of the folks that deal in multicast services" are? I mean how the group understands what are the requirements, usage scenarios, limitations, etc., basically what is the malloc service model? Thanks in advance for any hint Michael From owner-malloc@catarina.usc.edu Sat Nov 28 12:41:15 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id MAA13290 for ; Sat, 28 Nov 1998 12:41:13 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id KAA06796 for malloc-list; Fri, 27 Nov 1998 10:56:41 -0800 Received: from dip.eecs.umich.edu (thalerd@dip.eecs.umich.edu [141.212.99.5]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id KAA06792 for ; Fri, 27 Nov 1998 10:56:35 -0800 Received: (from thalerd@localhost) by dip.eecs.umich.edu (8.9.1/8.9.0) id NAA11448; Fri, 27 Nov 1998 13:56:24 -0500 (EST) From: Dave Thaler Message-Id: <199811271856.NAA11448@dip.eecs.umich.edu> Subject: Re: malloc service model (was: MDHCP review) To: jason.morphett@bt-sys.bt.co.uk (Jason Morphett) Date: Fri, 27 Nov 1998 13:56:24 -0500 (EST) Cc: finlayson@live.com, smirnow@fokus.gmd.de, malloc@catarina.usc.edu In-Reply-To: from "Jason Morphett" at Nov 27, 98 09:55:48 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Just to add to what Mark said... > As an application developer, I need to allocate (potentially) a lot of > multicast addresses with the lowest possible latency in doing so. I > don't want to 'hoard' X addresses and use X/10 of them for 50% of the > time as that's not utilising the available address space. I need to be > able to request and receive addresses in the *least possible time* and > use them for anything varying from a few seconds to (potentially) hours. > But, the key factor is latency in allocation. Right, this is typical. > Reading Mark Handley's AAP proposal. It states that I may have to wait > for anything up to ANNOUNCE-WAIT (at best) before I get the address. > How do the current offerings from MALLOC allow me to request and receive > an address in under ANNOUNCE-WAIT? i.e. request-receive c.f. > claim-collide? My opinion is that servers should always try to keep a small pool of addresses reserved for allocation (the AITU message that Mark mentioned). Anyone requesting a small number of addresses can then get them immediately, with no advance notice. If you ask for a large number of addresses (more than the small pool size), then you have to wait. If you ask for a really large number, you may not get them at all unless you ask for them enough in advance of when you need them. (You may be able to get a hotel room at the last minute, but if you're trying to reserve a block of 1000, you'll definitely be out of luck.) > BTW, the application is a large scale virtual environment using > multicast addresses for 'groups' of inhabitants to use for > audio/text/video etc.? Addresses are handed out as groups form (a > highly dynamic activity). This sounds like a typical DIS-like scenario. You can either a) allocate groups one-at-a-time on demand, or b) pre-allocate a large block, and use some application-layer mapping function to decide which one of the large block to use. The former is more efficient in terms of space utilization. The latter is useful if groups are associated with things in the virtual environment (e.g. rooms). -Dave From owner-malloc@catarina.usc.edu Sat Nov 28 12:41:16 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id MAA13297 for ; Sat, 28 Nov 1998 12:41:15 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id HAA06467 for malloc-list; Fri, 27 Nov 1998 07:58:24 -0800 Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id HAA06463 for ; Fri, 27 Nov 1998 07:58:20 -0800 Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4) id KAA07810; Fri, 27 Nov 1998 10:57:11 -0500 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: Jason Morphett cc: "'Ross Finlayson'" , "'Mikhail Smirnov'" , "'malloc@catarina.usc.edu'" Subject: Re: malloc service model (was: MDHCP review) In-reply-to: Your message of "Fri, 27 Nov 1998 09:55:48 GMT." Date: Fri, 27 Nov 1998 10:57:11 -0500 Message-ID: <7808.912182231@north.lcs.mit.edu> Sender: owner-malloc@catarina.usc.edu Precedence: bulk >Reading Mark Handley's AAP proposal. It states that I may have to wait >for anything up to ANNOUNCE-WAIT (at best) before I get the address. >How do the current offerings from MALLOC allow me to request and receive >an address in under ANNOUNCE-WAIT? i.e. request-receive c.f. >claim-collide? You need a local server that implements AITU. You're also best to predict when you're going to need addresses and request a pool of then in advance. When you can't predict, a server implementing AITU will normally give you some addresses immediately. However, if you surprise the server with a sudden demand for a large number of addresses, then you'll just have to wait. For your application and most other similar applications I've heard described, pre-allocating a relavtively small cache of addresses is going to be your best solution. Cheers, Mark From owner-malloc@catarina.usc.edu Sat Nov 28 12:41:17 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id MAA13307 for ; Sat, 28 Nov 1998 12:41:16 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id BAA05596 for malloc-list; Fri, 27 Nov 1998 01:55:02 -0800 Received: from arthur.axion.bt.co.uk (arthur.axion.bt.co.uk [132.146.5.4]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id BAA05592 for ; Fri, 27 Nov 1998 01:54:57 -0800 Received: from rambo (actually rambo.futures.bt.co.uk) by arthur (local) with SMTP; Fri, 27 Nov 1998 09:53:49 +0000 Received: from mussel.futures.bt.co.uk (actually mussel) by rambo with SMTP (PP); Fri, 27 Nov 1998 09:57:02 +0000 Received: by mussel.futures.bt.co.uk with Microsoft Exchange (IMC 4.0.837.3) id <01BE19EB.18F04100@mussel.futures.bt.co.uk>; Fri, 27 Nov 1998 09:48:33 -0000 Message-ID: From: Jason Morphett To: "'Ross Finlayson'" , "'Mikhail Smirnov'" Cc: "'malloc@catarina.usc.edu'" Subject: RE: malloc service model (was: MDHCP review) Date: Fri, 27 Nov 1998 09:55:48 -0000 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 Sender: owner-malloc@catarina.usc.edu Precedence: bulk Hi Ross, Agreed, the draft does show an 'abstract service interface', but it doesn't illustrate examples of use mapped down to service types. I know that wouldn't be the remit of the draft, but I agree with Mikhail that it would be useful to identify (by service type) where MALLOC can be used. The reason for my '2 penneth worth' here is as follows... As an application developer, I need to allocate (potentially) a lot of multicast addresses with the lowest possible latency in doing so. I don't want to 'hoard' X addresses and use X/10 of them for 50% of the time as that's not utilising the available address space. I need to be able to request and receive addresses in the *least possible time* and use them for anything varying from a few seconds to (potentially) hours. But, the key factor is latency in allocation. Reading Mark Handley's AAP proposal. It states that I may have to wait for anything up to ANNOUNCE-WAIT (at best) before I get the address. How do the current offerings from MALLOC allow me to request and receive an address in under ANNOUNCE-WAIT? i.e. request-receive c.f. claim-collide? BTW, the application is a large scale virtual environment using multicast addresses for 'groups' of inhabitants to use for audio/text/video etc.? Addresses are handed out as groups form (a highly dynamic activity). Thanks in advance, Jason > -----Original Message----- > From: Ross Finlayson [mailto:finlayson@live.com] > Sent: 26 November 1998 21:41 > To: Mikhail Smirnov > Cc: malloc@catarina.usc.edu; Michael.Carney@East.Sun.COM > Subject: Re: malloc service model (was: MDHCP review) > > At 01:23 PM 11/26/98 +0100, Mikhail Smirnov wrote: > > >Do we have any document fixing malloc's current > understanding of what > >"the needs of the folks that deal in multicast services" > are? I mean how > the group > >understands what are the requirements, usage scenarios, > limitations, etc., > >basically what is the malloc service model? > > Yes, the MALLOC "abstract API" document - > "draft-ietf-malloc-api-04.txt" - > describes the "abstract service interface" for MALLOC. > This may be what > you're looking for. > > I and the rest of the MALLOC working group would be > interested in any > specific suggestions you may have as to how this document > might be improved > to better meet the needs of multicast applications. > > Ross. > > From owner-malloc@catarina.usc.edu Sat Nov 28 12:41:19 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id MAA13318 for ; Sat, 28 Nov 1998 12:41:18 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id VAA05175 for malloc-list; Thu, 26 Nov 1998 21:24:12 -0800 Received: from carlsbad.usc.edu (carlsbad.usc.edu [128.125.51.5]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id VAA05171 for ; Thu, 26 Nov 1998 21:24:09 -0800 Received: (pavlin@localhost) by carlsbad.usc.edu (8.6.10/8.6.9) id VAA07646 for malloc@catarina.usc.edu; Thu, 26 Nov 1998 21:24:08 -0800 Received: from proxy3.ba.best.com (root@proxy3.ba.best.com [206.184.139.14]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id VAA05153 for ; Thu, 26 Nov 1998 21:11:00 -0800 Received: from kaipara.live.com (kaipara.live.com [206.86.37.12]) by proxy3.ba.best.com (8.9.0/8.9.0/best.out) with SMTP id VAA28347; Thu, 26 Nov 1998 21:09:33 -0800 (PST) Message-Id: <3.0.5.16.19981126211717.2fe72ad2@shell7.ba.best.com> X-Sender: rsf@shell7.ba.best.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (16) Date: Thu, 26 Nov 1998 21:17:17 To: Peter Parnes From: Ross Finlayson Subject: Re: Comments on draft-ietf-malloc-api-04.txt Cc: malloc@catarina.usc.edu, tech@marratech.com, roxycdt@basil.cdt.luth.se In-Reply-To: <199811211218.NAA03823@basil.cdt.luth.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-malloc@catarina.usc.edu Precedence: bulk At 01:18 PM 11/21/98 +0100, Peter Parnes wrote: >> [*] An open question is: Who is allowed to deallocate (or query or >> change the lifetime of) a previously allocated multicast address? >> This is an implementation-specific decision, dependent upon the >> security policy of the host system, and is not specified in this >> abstract API. One possible starting point, however, is the following: >> A previously allocated multicast address can be deallocated >> (or have >> its lifetime queried or changed) by the same "principal", and >> on the >> same node, as that which originally allocated it. >> ("principal" might, >> for example, be a "user" in the host operating system.) > >>From a practical point of view, isn't that quite useless? I'm thinking of how >easy it is to impersonate another "principal". Well, that, of course, depends on how you define "principal" :-) I agree that this section of the abstract API document could be clearer. The intention is merely to explain that a concrete realization of this API may decide, for security reasons, not to allow 'just anyone' to deallocate (or query or change the lifetime of) a previously allocated address. Beyond this, there's not much more that the abstract API can really say. (The "principal" discussion was intended merely to give designers of concrete APIs a possible starting point to work from. However, this is not the first time that readers have been puzzled by this, so I may end up just removing it.) However, this same security issue also applies to the underlying *inter-node* protocols - MDHCP and/or AAP - that will actually implement multicast address allocation. Here, however, we can actually say something concrete, because these protocols are the actual 'products' that this working group hopes to standardize. In particular, the current MDHCP draft - in the "Security Considerations" section - notes this issue, although it 'hand waves' by merely referring to the possibility of adding (optional) access control (with client authentication). However, I wonder if perhaps we should try to do better than this, by adding explicit support in the MDHCP protocol. E.g., each successful 'allocate' operation could return (in addition to the multicast address) a randomly-generated token that a client would have to present in order to later be able to deallocate the address??? (As far as I can tell, this issue does not arise with AAP, because AAP doesn't have a 'deallocate' operation, and, in any case, uses digital signatures to protect against spoofing.) At 08:14 PM 11/21/98 -0500, Dave Thaler wrote: >The WG could either decide that deallocation before the lease expires >is a good thing, and take on the security problem associated with it. >Or the WG could decide that deallocation before the lease expires >is not worth it at this point. As I noted above (but please correct me if I'm wrong), this seems to be an issue only for MDHCP, not for AAP or MASC. Note, however, that even if we were to remove the 'deallocate' operation from MDHCP, there are still (the same) security issues associated with the 'extend lifetime' operation. >I'm interested in hearing the WG's opinions on this, and if >Ross or someone else wanted to give a presentation at IETF on >the tradeoffs, that'd be great. I probably won't be attending this IETF, unfortunately (I'm too poor right now :-(, so I'd probably have to leave this to someone else. Ross. From owner-malloc@catarina.usc.edu Sat Nov 28 12:41:20 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id MAA13328 for ; Sat, 28 Nov 1998 12:41:19 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id VAA05151 for malloc-list; Thu, 26 Nov 1998 21:10:57 -0800 Received: from proxy3.ba.best.com (root@proxy3.ba.best.com [206.184.139.14]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id VAA05147 for ; Thu, 26 Nov 1998 21:10:52 -0800 Received: from kaipara.live.com (kaipara.live.com [206.86.37.12]) by proxy3.ba.best.com (8.9.0/8.9.0/best.out) with SMTP id VAA28418; Thu, 26 Nov 1998 21:09:42 -0800 (PST) Message-Id: <3.0.5.16.19981126214053.2c2fa164@shell7.ba.best.com> X-Sender: rsf@shell7.ba.best.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (16) Date: Thu, 26 Nov 1998 21:40:53 To: Mikhail Smirnov From: Ross Finlayson Subject: Re: malloc service model (was: MDHCP review) Cc: malloc@catarina.usc.edu, Michael.Carney@East.Sun.COM In-Reply-To: <199811261223.NAA10886@dumbo.fokus.gmd.de > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-malloc@catarina.usc.edu Precedence: bulk At 01:23 PM 11/26/98 +0100, Mikhail Smirnov wrote: >Do we have any document fixing malloc's current understanding of what >"the needs of the folks that deal in multicast services" are? I mean how the group >understands what are the requirements, usage scenarios, limitations, etc., >basically what is the malloc service model? Yes, the MALLOC "abstract API" document - "draft-ietf-malloc-api-04.txt" - describes the "abstract service interface" for MALLOC. This may be what you're looking for. I and the rest of the MALLOC working group would be interested in any specific suggestions you may have as to how this document might be improved to better meet the needs of multicast applications. Ross. From owner-malloc@catarina.usc.edu Mon Nov 30 09:39:08 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id JAA18774 for ; Mon, 30 Nov 1998 09:39:07 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id GAA13040 for malloc-list; Mon, 30 Nov 1998 06:02:03 -0800 Received: from quadntweb.quadritek.com ([198.200.138.211]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id GAA13036 for ; Mon, 30 Nov 1998 06:01:53 -0800 Received: from agrabil-nt ([198.200.138.254]) by quadntweb.quadritek.com (Post.Office MTA v3.0 release 0122 ID# 0-40852U100L100S0) with SMTP id AAA201 for ; Mon, 30 Nov 1998 08:51:48 -0500 Received: by localhost with Microsoft MAPI; Mon, 30 Nov 1998 09:02:01 -0500 Message-ID: <01BE1C40.17FE77B0.agrabil@quadritek.com> From: agrabil@quadritek.com (Greg Rabil) To: "'malloc@catarina.usc.edu'" Subject: RE: Feedback requested (re MDHCP) Date: Mon, 30 Nov 1998 09:02:00 -0500 Organization: Lucent Technologies X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Sender: owner-malloc@catarina.usc.edu Precedence: bulk 1) Do you think that you might implement an MDHCP client or server? Yes, Lucent (Quadritek) is considering building a MDHCP server as a future development effort. We have not discussed building a client. 2) If you were to do so, would you attempt to share code with your DHCP client or server? Most likely. 3) Do you think that we should continue to maintain a similarity between MDHCP and DHCP? Why or why not? As long as the functionality is not hindered, it seems like keeping them similar may speed the acceptance/implementation amongst the vendors. A. Gregory Rabil Sr. Software Engineer/Project Leader Lucent Technologies (Quadritek) IP Services Product Group agrabil@quadritek.com grabil@lucent.com -----Original Message----- From: Ralph Droms [SMTP:droms@bucknell.edu] Sent: Wednesday, November 25, 1998 5:14 PM To: Multiple recipients of list Subject: Feedback requested (re MDHCP) Ralph Droms tells me that this is where the real DHCP implementors hang out. Last week, I sent the following email to the dhcp-v4 list and have received very little response. I would greatly appreciate any input you folks could provide. I am particularly interested in answers to the last question: Do you think that we should continue to maintain a similarity between MDHCP and DHCP? Why or why not? Answers from people that have actually implemented DHCP are especially appreciated. Information like "Maintaining this similarity will save me time and reduce code size because..." or "This similarity stuff doesn't help me at all because..." You can send email to me directly (email:steve.hanna@sun.com) or to the malloc mailing list (email:malloc@catarina.usc.edu). Thanks, Steve Hanna ------------- Begin Forwarded Message ------------- Date: Fri, 20 Nov 1998 17:27:33 -0500 (EST) From: Steve Hanna Subject: MDHCP review To: dhcp-v4@bucknell.edu Cc: malloc@catarina.usc.edu Mime-Version: 1.0 Content-MD5: PwfXRVsXgUPMfpvxfikIJw== In the malloc working group, we have been working on a protocol that hosts may use to allocate multicast addresses (or perform other related operations). This protocol, MDHCP, is described in draft-ietf-malloc-mdhcp-01.txt. Originally, this protocol was a minor variation on DHCP and the idea was that a DHCP client or server implementation could also serve as an MDHCP implementation with minor changes. Over time, the protocol has become more and more different from DHCP (fields removed from header, different option space). However, we have attempted to keep the protocol similar to DHCP in order to allow code sharing. The question has arisen within the malloc working group: "Should we continue to maintain a similarity between MDHCP and DHCP?" Eliminating this design constraint would allow us to make MDHCP simpler and more efficient. However, it would also eliminate any remaining hope for sharing code between MDHCP and DHCP implementations. I would like to ask people who have implemented DHCP clients or servers to examine the current MDHCP draft (available from ftp://ftp.ietf.org/internet-drafts/draft-ietf-malloc-mdhcp-01.txt) and answer the following questions. 1) Do you think that you might implement an MDHCP client or server? 2) If you were to do so, would you attempt to share code with your DHCP client or server? 3) Do you think that we should continue to maintain a similarity between MDHCP and DHCP? Why or why not? Please send answers to the malloc mailing list (malloc@catarina.usc.edu). Thanks, Steve Hanna malloc WG co-chair ------------- End Forwarded Message ------------- From owner-malloc@catarina.usc.edu Mon Nov 30 12:53:30 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id MAA21932 for ; Mon, 30 Nov 1998 12:53:29 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id IAA13308 for malloc-list; Mon, 30 Nov 1998 08:34:49 -0800 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id IAA13304 for ; Mon, 30 Nov 1998 08:34:44 -0800 Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA05087; Mon, 30 Nov 1998 08:34:10 -0800 Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id LAA01082; Mon, 30 Nov 1998 11:33:19 -0500 Received: from bcn.East.Sun.COM (bcn [129.148.75.4]) by suneast.East.Sun.COM (8.9.1b+Sun/8.8.8) with SMTP id LAA12212; Mon, 30 Nov 1998 11:33:06 -0500 (EST) Received: from pine by bcn.East.Sun.COM (SMI-8.6/SMI-SVR4) id LAA17001; Mon, 30 Nov 1998 11:33:04 -0500 Message-Id: <199811301633.LAA17001@bcn.East.Sun.COM> Date: Mon, 30 Nov 1998 11:33:04 -0500 (EST) From: Steve Hanna Reply-To: Steve Hanna Subject: MALLOC agenda for IETF 43 To: agenda@ietf.org Cc: malloc@catarina.usc.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: SIQhub4Hsq+P8HTLLOcADQ== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-malloc@catarina.usc.edu Precedence: bulk Here is the current version of the malloc working group agenda for IETF 43: Multicast Address Allocation WG (malloc) Thursday, December 10 at 0900-1130 ================================== Chair: Steve Hanna Dave Thaler AGENDA: Agenda Bashing [Steve Hanna] Architecture [Steve Hanna] MDHCP Changes [Munil Shah] MDHCP Issues [Dave Thaler] MASC Deployment [Dave Thaler] Language Tags [Steve Hanna]