From owner-malloc@catarina.usc.edu Mon Aug 2 14:48:41 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02502 for ; Mon, 2 Aug 1999 14:48:39 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id LAA02084 for malloc-list; Mon, 2 Aug 1999 11:14:45 -0700 Received: from excalibur.usc.edu (excalibur.usc.edu [128.125.51.11]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id LAA02080 for ; Mon, 2 Aug 1999 11:14:39 -0700 Received: (pavlin@localhost) by excalibur.usc.edu (8.6.10/8.6.9) id LAA03121 for malloc@catarina.usc.edu; Mon, 2 Aug 1999 11:14:36 -0700 Received: from hubbub.cisco.com (hubbub.cisco.com [171.69.11.2]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id IAA01477; Mon, 2 Aug 1999 08:19:59 -0700 Received: from OranLT ([171.69.210.9]) by hubbub.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.GATE.1.1) with SMTP id IAA04139; Mon, 2 Aug 1999 08:18:09 -0700 (PDT) From: "David Oran" To: , , , , , , , Subject: Maestro BoF Results Date: Mon, 2 Aug 1999 11:17:41 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit The Routing Area held a BoF at the Oslo IETF whose purpose was to discuss potential refinements to the IP multicast model in two areas: 1) Enhanced two-part multicast addressing to ease scalability and deployment headaches, 2) Optimizations to exploit the single-sender case The BoF announcement, along with its scope and agenda, may be found at: http://www.ietf.org/ietf/99jul/maestro-agenda-99jul.txt. I am sending this message to who I think are all the relevant WG mailing lists, and it will also be sent out via IETF-announce, so please let me know directly if I've missed a relevant group rather than risk clogging peoples' mailboxes with multiple forwards. The minutes of BoF are attached below. One of the conclusions from the BoF was to continue discussions on these subjects to ascertain if there is a critical mass of support to charter one or more Working Groups to pursue IETF standards (or other outputs) in these areas. We are therefore resurrecting a moribund Routing Area mailing list for this purpose: routing-discussion@ietf.org Subscription is via majordomo@ietf.org Thanks to all who participated in the BoF and in advance for useful low-flamability discussion on the mailing list. Regards, Dave Oran (routing co-area director) MAESTRO BOF, Dave Oran ---------------------- AGENDA History - modify multicast model, do we need a working group on this? A number of people think if we simplify the multicast model there are significant benefits in reducing complexity. changes: addressing model, assume single sender. We want to look at the problems today and see how proposed simplications might help. Ground rules: talk about problems and how they map to the proposed simplifications. from two perspectives, isp's and architectural view. Bryan Lyles, Sprint Deployment Strategy --------------------------------------- Today, multicast enabled, working with vendors and customers to make it work. built on PIM-SM, MSDP, MBGP, IGMPV2, GLOP. Short Term - push current protocols, work in ietf to enhance base. Certain kinds of applications want single server (radio station, politician giving speech, dont want opposition heckling him) Hugh Holbrook, Stanford/Cisco ----------------------------- Some multicast applications work well with unicast others its impossible, high data rates, many receivers questions to isp's - how do you bill for it. make billing reflect cost. so charge by size of group. dmm - if i am a source, receivers on same isp are onnet, other receivers are offnet. want to billed for offnet folks. brad cain - bill by bandwidth, can isp's break even on multicast. Queries flow down tree, counts flow back up, somehow gather data to bill src. access control for large groups, restrict senders in advance (pirates on tv station), important for commercial applications too. kevin almeroth - why does it work with radia, lawyers are the answers, no one owns a multicast address, if they did you could sue someone for using yours without permission. security - source provides passwd to receivers www.dsg.stanford.edu/hollbrook/express Jeremy Hall, uunet ------------------ Problems - scalability, single source model ok, hard to implement. you are trying to restrict something that is not restrictable. lots of protocols running as ships in the night, ok when it works, never know which one is not working correctly. way too much ad hoc stuff going on. which protocol is broken. nice to be able to trace a problem from the sender, to the receiver. receiver says i'm not receiving this content. have to figure out from that info, where the source is and what the problem is. Some applications hide the group, so you cant figure out where to troubleshoot. people dont understand how it works, so they cant help you debug. need education. Billing problems, counting receivers might be nice but is hard as groups get big. onnet vs offnet. tried to employ things that are parallel to unicast. unicast routing tries to dump traffic asap, mulitcast wants to keep as long as possible. current model doesnt scale. anyone can source to any group and thats a security problem. there are a lot of security issues with multicast. Mark Handley, ACIRI ------------------- Internet Standard Multicast, where it came from and why it had nice properties. direct extension of the unicast model, host sends packets to destination address, it gets there. nice architecure, senders dont need to know about receivers. recievers dont need to know who senders are. distributed binding is useful resource. senders and receivers dont need to know about topology, robust, route around failures etc. hosts dont need to knows about routing protocool. need distinction between service model and its implementation in the network. separates what the application wants and how the network achieves it. clean separation of routing and transport/application layer. What can we do with it: Regular one to many applications - video distribution, data distribution many to many applications - conferening, games, dont know members in advance, distributed binding is very robust, changes the way you design applications (eg wb) Many to few applications - server discovery Scoping, used to have ttl scoping, poor for traffic engineering, great for self organizing applications, expanding ring search, we lost the ttl in pim, admin scoping getting it back, mzap Security - can only restrict traffic safely with encryption. content providers want authentication, have the mechanisms already. problems: forwarding table size, aggregation helps some; how can isp's make money; lack of scalable routing protocol, bgmp, hierarchical pim, bi-direction pim with grib, bgmp will probably work, hierarchical pim too; lack or good network management and diagnostic tools. serious growing pains, transition from dvmrp painful distributed binding a key - wb, sdr, mimaze applications important to avoid constraining network mechanisms to support only one to many applications Bryan - lots of differences of opionion in the community. Hugh - avoid overly commplicating things for futures applications when we have existing applications that need support now. jon crowcroft, ucl, www.cs.ucl.ac.uk/research/rama -------------------------------------------------- Enhancing deering multicast, enhancing the addressing scheme. class D address is a channel, not really an ip address. Anonymously names a group of receivers, allows anyone to send to it. alternatives, allow end systems to be explicit DCM/connectionless multicast - add list of addresses, transparency and fault tolerance David Oran - Final Questions ---------------------------- we have 5 minutes, where should we go with this? Brian Whetten - wishes had heard more from isps about problems. TODO - decide which problems are of deployment and which are based on what we are deploying. Scott Petrak - 3 things: think about low bandwidth hosts at the end, like wireless; thing 2 i missed; small number of senders a worthy optimization. Dorian Kim - deployment problems have been maturity of implementation issues and how to make all the hacks play together. havent tried running native multicast at scales we want. will find more answers as we deploy and ramp up, at this point probably not worth limiting model. Hum votes create a mailing list 2/3 hum no mailing list 1/3 hum From owner-malloc@catarina.usc.edu Mon Aug 2 15:03:17 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03023 for ; Mon, 2 Aug 1999 15:03:15 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id LAA02098 for malloc-list; Mon, 2 Aug 1999 11:19:16 -0700 Received: from excalibur.usc.edu (excalibur.usc.edu [128.125.51.11]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id LAA02094 for ; Mon, 2 Aug 1999 11:18:56 -0700 Received: (pavlin@localhost) by excalibur.usc.edu (8.6.10/8.6.9) id LAA03139 for malloc@catarina.usc.edu; Mon, 2 Aug 1999 11:18:47 -0700 Received: from mailman.sprintlabs.com (mx.sprintlabs.com [208.30.174.2]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id IAA01645; Mon, 2 Aug 1999 08:59:44 -0700 Received: from sprintlabs.com (ip199-2-54-117.sprintlabs.com [199.2.54.117]) by mailman.sprintlabs.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id P60ZAK1M; Mon, 2 Aug 1999 08:59:40 -0700 Message-ID: <37A5C07E.9482F819@sprintlabs.com> Date: Mon, 02 Aug 1999 08:59:58 -0700 From: christophe diot Organization: SPRINT ATL X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: David Oran CC: maddogs@ietf.org, idmr@cs.ucl.ac.uk, idr@merit.edu, msdp@network-services.uoregon.edu, pim@catarina.usc.edu, mboned@network-services.uoregon.edu, malloc@catarina.usc.edu, rmt@lbl.gov Subject: Re: Maestro BoF Results References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit David Oran wrote: > > The Routing Area held a BoF at the Oslo IETF whose purpose was to discuss > potential refinements to the IP multicast model in two areas: > 1) Enhanced two-part multicast addressing to ease scalability and > deployment > headaches, > 2) Optimizations to exploit the single-sender case > > The BoF announcement, along with its scope and agenda, may be found at: > http://www.ietf.org/ietf/99jul/maestro-agenda-99jul.txt. > > I am sending this message to who I think are all the relevant WG mailing > lists, and it will also be sent out via IETF-announce, so please let me know > directly if I've missed a relevant group rather than risk clogging peoples' > mailboxes with multiple forwards. > > The minutes of BoF are attached below. One of the conclusions from the BoF > was to continue discussions on these subjects to ascertain if there is a > critical mass of support to charter one or more Working Groups to pursue > IETF standards (or other outputs) in these areas. We are therefore > resurrecting a moribund Routing Area mailing list for this purpose: > routing-discussion@ietf.org > Subscription is via majordomo@ietf.org > > Thanks to all who participated in the BoF and in advance for useful > low-flamability discussion on the mailing list. > > Regards, Dave Oran (routing co-area director) > > MAESTRO BOF, Dave Oran > ---------------------- > > AGENDA > > History - modify multicast model, do we need a working group > on this? > > A number of people think if we simplify the multicast model > there are significant benefits in reducing complexity. > changes: addressing model, assume single sender. > > We want to look at the problems today and see how proposed > simplications might help. > > Ground rules: talk about problems and how they map to the > proposed simplifications. from two perspectives, isp's > and architectural view. > > Bryan Lyles, Sprint Deployment Strategy > --------------------------------------- > Today, multicast enabled, working with vendors and customers to make > it work. built on PIM-SM, MSDP, MBGP, IGMPV2, GLOP. > > Short Term - push current protocols, work in ietf to enhance base. > > Certain kinds of applications want single server (radio station, > politician giving speech, dont want opposition heckling him) If I remember well, this is not exactly what we said ... What we "also" sayed is that we encouter problems with providing stable and robust multicast service, and that we are not really satisfied with the current protocol architecture and with its implementation (difficult to know if the architecture or the implementation is broken). The conslusion of the talk was that Sprint would like IETF to consider a protocol architecture that would be stable, more simple, and more scalable. > Hugh Holbrook, Stanford/Cisco > ----------------------------- > Some multicast applications work well with unicast > others its impossible, high data rates, many receivers > questions to isp's - how do you bill for it. make billing reflect > cost. so charge by size of group. > > dmm - if i am a source, receivers on same isp are onnet, > other receivers are offnet. want to billed for offnet folks. > > brad cain - bill by bandwidth, can isp's break even on multicast. > > Queries flow down tree, counts flow back up, somehow gather data > to bill src. access control for large groups, restrict senders > in advance (pirates on tv station), important for commercial > applications too. > > kevin almeroth - why does it work with radia, lawyers are > the answers, no one owns a multicast address, if they did > you could sue someone for using yours without permission. > > security - source provides passwd to receivers > > www.dsg.stanford.edu/hollbrook/express > > Jeremy Hall, uunet > ------------------ > Problems - scalability, single source model ok, hard to implement. > you are trying to restrict something that is not restrictable. > lots of protocols running as ships in the night, ok when it works, > never know which one is not working correctly. way too much ad hoc > stuff going on. which protocol is broken. nice to be able to trace > a problem from the sender, to the receiver. receiver says i'm not > receiving this content. have to figure out from that info, where > the source is and what the problem is. > > Some applications hide the group, so you cant figure out where > to troubleshoot. people dont understand how it works, so they > cant help you debug. need education. > > Billing problems, counting receivers might be nice but is hard > as groups get big. onnet vs offnet. tried to employ things > that are parallel to unicast. unicast routing tries to dump traffic > asap, mulitcast wants to keep as long as possible. current model > doesnt scale. anyone can source to any group and thats a security > problem. there are a lot of security issues with multicast. > > Mark Handley, ACIRI > ------------------- > Internet Standard Multicast, where it came from and why it had > nice properties. direct extension of the unicast model, host > sends packets to destination address, it gets there. nice > architecure, senders dont need to know about receivers. > recievers dont need to know who senders are. distributed binding > is useful resource. senders and receivers dont need to know about > topology, robust, route around failures etc. hosts dont need to > knows about routing protocool. need distinction between service > model and its implementation in the network. separates what > the application wants and how the network achieves it. clean > separation of routing and transport/application layer. > > What can we do with it: > > Regular one to many applications - video distribution, data distribution > many to many applications - conferening, games, dont know members in > advance, distributed binding is very robust, changes the way you design > applications (eg wb) > > Many to few applications - server discovery > > Scoping, used to have ttl scoping, poor for traffic engineering, > great for self organizing applications, expanding ring search, > we lost the ttl in pim, admin scoping getting it back, mzap > > Security - can only restrict traffic safely with encryption. > content providers want authentication, have the mechanisms already. > > problems: > > forwarding table size, aggregation helps some; > how can isp's make money; > lack of scalable routing protocol, bgmp, hierarchical pim, > bi-direction pim with grib, bgmp will probably work, > hierarchical pim too; > lack or good network management and diagnostic tools. > > serious growing pains, transition from dvmrp painful > > distributed binding a key - wb, sdr, mimaze applications > > important to avoid constraining network mechanisms to support only one > to many applications > > Bryan - lots of differences of opionion in the community. > Hugh - avoid overly commplicating things for futures applications > when we have existing applications that need support now. > > jon crowcroft, ucl, www.cs.ucl.ac.uk/research/rama > -------------------------------------------------- > Enhancing deering multicast, enhancing the addressing scheme. > class D address is a channel, not really an ip address. > Anonymously names a group of receivers, allows anyone to send to it. > alternatives, allow end systems to be explicit > DCM/connectionless multicast - add list of addresses, > transparency and fault tolerance > > David Oran - Final Questions > ---------------------------- > we have 5 minutes, where should we go with this? > > Brian Whetten - wishes had heard more from isps about problems. > > TODO - decide which problems are of deployment and which are based > on what we are deploying. > > Scott Petrak - 3 things: think about low bandwidth hosts at the end, > like wireless; thing 2 i missed; small number of senders a worthy > optimization. > > Dorian Kim - deployment problems have been maturity of implementation issues > and how to make all the hacks play together. havent tried running native > multicast at scales we want. will find more answers as we deploy and ramp > up, at this point probably not worth limiting model. > > Hum votes > create a mailing list 2/3 hum > no mailing list 1/3 hum -- ======================================================= christophe Diot | tel: 1(650)375.4539 Sprint ATL | fax: 1(650)375.4490 1 Adrian Court | cdiot@sprintlabs.com Burlingame CA 94010 | www.sprintlabs.com USA | From owner-malloc@catarina.usc.edu Sun Aug 8 17:28:38 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10691 for ; Sun, 8 Aug 1999 17:28:38 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA07526 for malloc-list; Sun, 8 Aug 1999 13:58:30 -0700 Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id NAA07522 for ; Sun, 8 Aug 1999 13:58:25 -0700 Received: from rumi (localhost [127.0.0.1]) by rumi.usc.edu (8.8.5/8.6.9) with ESMTP id NAA08051 for ; Sun, 8 Aug 1999 13:58:25 -0700 (PDT) Message-Id: <199908082058.NAA08051@rumi.usc.edu> To: malloc@catarina.usc.edu Subject: MASC draft updated Date: Sun, 08 Aug 1999 13:58:24 -0700 From: Pavlin Ivanov Radoslavov Sender: owner-malloc@catarina.usc.edu Precedence: bulk I just submitted an update of the MASC draft (draft-ietf-malloc-masc-03.txt). In the mean time (until it appears in the I-D directory), you can get a copy of it from http://netweb.usc.edu/masc/ One of the changes that was described/suggested during IETF in OSLO is to use separate TCP connections between siblings, one for each parent in common. During the IETF meeting someone has asked whether this require multiple port numbers, and how can we determine which tcp connection goes with which common parent? The answer is that each OPEN message has a field "Parent's Domain ID", so each initiated/created connection between siblings can be associated with a particular parent. Also, this mechanism requires one single well-known MASC port used to listen for new OPEN messages. Obviously, creating a number of TCP connections between same nodes will require different ports at one side, but those ports will be dynamically chosen and don't have to be well known. Below is the list of all major changes. Thanks, Pavlin Major changes since draft-02: o "APPENDIX C: QUERY/RESPONSE Debug Messages" added. o CLAIM_DENIED propagation rules refined. o Holdtime timer restarted if NOTIFICATION with C-bit reset received o The exponentially increased re-opening connection time interval after an error cannot be longer than 24 hours. o Claim Type Error condition bug fix. o "CC" definition in Error subcode description is changed from "C-bit is not set" to "C-bit might be set". o CLAIM_DENIED definition refined as "peer refuses your claim..." instead of "origin refuses your claim...", because CLAIM_DENIED remains the Origin Node and Domain IDs same as those of the denied claim. o "Multi-Parent Sibling-to-Sibling and Internal Peering" sub-section added. o Parents Information (Parameter Type 2) OPEN optional parameter removed (XXX: just realized that this change is not mentioned in the submitted draft) From owner-malloc@catarina.usc.edu Tue Aug 10 07:51:36 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05803 for ; Tue, 10 Aug 1999 07:51:35 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id EAA13498 for malloc-list; Tue, 10 Aug 1999 04:21:59 -0700 Received: (from pavlin@localhost) by catarina.usc.edu (8.6.10/8.6.9) id EAA13487 for malloc@catarina.usc.edu; Tue, 10 Aug 1999 04:21:55 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id EAA13465 for ; Tue, 10 Aug 1999 04:16:48 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05051; Tue, 10 Aug 1999 07:16:14 -0400 (EDT) Message-Id: <199908101116.HAA05051@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-masc-03.txt Date: Tue, 10 Aug 1999 07:16:14 -0400 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 : The Multicast Address Set Claim (MASC) Protocol Author(s) : D. Estrin, R. Govindan, M. Handley, S. Kumar, P. Radoslavov, D. Thaler Filename : draft-ietf-malloc-masc-03.txt Pages : 64 Date : 09-Aug-99 This document describes the Multicast Address-Set Claim (MASC) protocol which can be used for inter-domain multicast address set allocation. MASC is used by a node (typically a router) to claim and allocate one or more address prefixes to that node's domain. While a domain does not necessarily need to allocate an address set for hosts in that domain to be able to allocate group addresses, allocating an address set to the domain does ensure that inter-domain distribution trees will be locally-rooted, and that traffic will be sent outside the domain only when and where external receivers exist. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-malloc-masc-03.txt 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-malloc-masc-03.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-malloc-masc-03.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: <19990809094119.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-malloc-masc-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-malloc-masc-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990809094119.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-malloc@catarina.usc.edu Fri Aug 13 16:18:57 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09881 for ; Fri, 13 Aug 1999 16:18:56 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id MAA27671 for malloc-list; Fri, 13 Aug 1999 12:43:03 -0700 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 MAA27667 for ; Fri, 13 Aug 1999 12:42:59 -0700 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA14144 for ; Fri, 13 Aug 1999 12:42:58 -0700 (PDT) Received: from bcn.East.Sun.COM (bcn.East.Sun.COM [129.148.75.4]) by eastmail2.East.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA14195 for ; Fri, 13 Aug 1999 15:42:56 -0400 (EDT) Received: from sun.com (dhcp75-155 [129.148.75.155]) by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with ESMTP id PAA11048 for ; Fri, 13 Aug 1999 15:42:57 -0400 (EDT) Message-ID: <37B47456.E47CF435@sun.com> Date: Fri, 13 Aug 1999 15:39:02 -0400 From: Steve Hanna Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: malloc Subject: WG Last Call on draft-ietf-malloc-masc-03.txt Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit This message starts a working group last call on the latest MASC spec: http://www.ietf.org/internet-drafts/draft-ietf-malloc-masc-03.txt This last call will expire in 2 weeks. Please review this document and send comments to the author or the malloc list by August 27. Thanks, Steve Hanna From owner-malloc@catarina.usc.edu Thu Aug 19 16:25:36 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16470 for ; Thu, 19 Aug 1999 16:25:35 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id JAA20223 for malloc-list; Thu, 19 Aug 1999 09:55:29 -0700 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 JAA20219 for ; Thu, 19 Aug 1999 09:55:23 -0700 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA28449 for ; Thu, 19 Aug 1999 09:55:20 -0700 (PDT) Received: from bcn.East.Sun.COM (bcn.East.Sun.COM [129.148.75.4]) by eastmail1.East.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA20995 for ; Thu, 19 Aug 1999 12:55:18 -0400 (EDT) Received: from sun.com (dhcp75-155 [129.148.75.155]) by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with ESMTP id MAA12237 for ; Thu, 19 Aug 1999 12:55:16 -0400 (EDT) Message-ID: <37BC3605.8688D534@sun.com> Date: Thu, 19 Aug 1999 12:51:17 -0400 From: Steve Hanna Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: malloc Subject: Revised MADCAP spec -06 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit I have submitted a revised version of the MADCAP spec to the Internet Drafts archive. For now, it is available from http://www.aciri.org/malloc/draft-ietf-malloc-madcap-06.txt As you may recall, we submitted madcap-05 to the IESG in May, requesting publication as a Proposed Standard. They had a few more comments and this draft addresses those comments. A list of changes is included below. Please review this list of changes and send email to the malloc list if you have any concerns. I expect that these changes will be non-controversial, so I will send the draft back to the area directors on Monday unless I hear otherwise. Thanks, Steve --------------- Changes between madcap-05 and madcap-06 * Many minor fixes and clarifications. * Changed the name of the INFORM message to GETINFO. * Changed the default behavior so that, by default, only the client that allocated a lease can change it. If a client wants the ability to have somebody else modify a lease that it allocated, it must request or require the new "Shared Lease Identifier" feature when allocating the lease. This change makes the default be the more common and safer behavior. Simple clients don't need to worry about making their Lease Identifier cryptographically random or about encrypting the Lease Identifier. From owner-malloc@catarina.usc.edu Fri Aug 20 13:08:17 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03809 for ; Fri, 20 Aug 1999 13:08:15 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id JAA26541 for malloc-list; Fri, 20 Aug 1999 09:44:41 -0700 Received: (from pavlin@localhost) by catarina.usc.edu (8.6.10/8.6.9) id JAA26536 for malloc@catarina.usc.edu; Fri, 20 Aug 1999 09:44:38 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id DAA25602 for ; Fri, 20 Aug 1999 03:58:57 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09715; Fri, 20 Aug 1999 06:58:24 -0400 (EDT) Message-Id: <199908201058.GAA09715@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-madcap-06.txt Date: Fri, 20 Aug 1999 06:58:24 -0400 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 Dynamic Client Allocation Protocol (MADCAP) Author(s) : S. Hanna, B. Patel, M. Shah Filename : draft-ietf-malloc-madcap-06.txt Pages : 50 Date : 19-Aug-99 This document defines a protocol, Multicast Address Dynamic Client Allocation Protocol (MADCAP), that allows hosts to request multicast addresses from multicast address allocation servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-malloc-madcap-06.txt 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-malloc-madcap-06.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-malloc-madcap-06.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: <19990819082353.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-malloc-madcap-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-malloc-madcap-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990819082353.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-malloc@catarina.usc.edu Thu Aug 26 12:29:55 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24113 for ; Thu, 26 Aug 1999 12:29:54 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id IAA23758 for malloc-list; Thu, 26 Aug 1999 08:36:25 -0700 Received: (from pavlin@localhost) by catarina.usc.edu (8.6.10/8.6.9) id IAA23753 for malloc@catarina.usc.edu; Thu, 26 Aug 1999 08:36:20 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id EAA23084 for ; Thu, 26 Aug 1999 04:03:34 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09322; Thu, 26 Aug 1999 07:02:55 -0400 (EDT) Message-Id: <199908261102.HAA09322@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-api-07.txt Date: Thu, 26 Aug 1999 07:02:54 -0400 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 : An Abstract API for Multicast Address Allocation Author(s) : R. Finlayson Filename : draft-ietf-malloc-api-07.txt Pages : 5 Date : 25-Aug-99 This document describes the 'abstract service interface' for the dynamic multicast address allocation service, as seen by applications. While it does not describe a concrete API (i.e., for a specific programming language), it describes - in abstract terms - the semantics of this service, including the guarantees that it makes to applications. Additional documents (not necessarily products of the IETF) would describe concrete APIs for this service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-malloc-api-07.txt 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-malloc-api-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-malloc-api-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: <19990825120556.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-malloc-api-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-malloc-api-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990825120556.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-malloc@catarina.usc.edu Fri Aug 27 13:04:30 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08519 for ; Fri, 27 Aug 1999 13:04:27 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id JAA01161 for malloc-list; Fri, 27 Aug 1999 09:33:05 -0700 Received: (from pavlin@localhost) by catarina.usc.edu (8.6.10/8.6.9) id JAA01156 for malloc@catarina.usc.edu; Fri, 27 Aug 1999 09:33:01 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id DAA29779 for ; Fri, 27 Aug 1999 03:57:03 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22022; Fri, 27 Aug 1999 06:56:19 -0400 (EDT) Message-Id: <199908271056.GAA22022@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-arch-02.txt Date: Fri, 27 Aug 1999 06:56:19 -0400 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 : The Internet Multicast Address Allocation Architecture Author(s) : M. Handley, D. Thaler, D. Estrin Filename : draft-ietf-malloc-arch-02.txt Pages : 11 Date : 26-Aug-99 This document proposes a multicast address allocation architecture for the Internet. The architecture is modular with three layers, comprising a host-server mechanism, an intra-domain server-server coordination mechanism, and an inter-domain mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-malloc-arch-02.txt 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-malloc-arch-02.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-malloc-arch-02.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: <19990826091454.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-malloc-arch-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-malloc-arch-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990826091454.I-D@ietf.org> --OtherAccess-- --NextPart--