From owner-malloc@catarina.usc.edu Fri Apr 2 14:14:11 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 OAA02000 for ; Fri, 2 Apr 1999 14:14:11 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id KAA01376 for malloc-list; Fri, 2 Apr 1999 10:37:33 -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 KAA01372 for ; Fri, 2 Apr 1999 10:37:27 -0800 Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA19787; Fri, 2 Apr 1999 10:37:32 -0800 (PST) Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id NAA20883; Fri, 2 Apr 1999 13:37:20 -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 NAA21394; Fri, 2 Apr 1999 13:37:21 -0500 (EST) Received: from sun.com by bcn.East.Sun.COM (SMI-8.6/SMI-SVR4) id NAA26892; Fri, 2 Apr 1999 13:37:20 -0500 Message-ID: <37050E60.609EF70D@sun.com> Date: Fri, 02 Apr 1999 13:37:20 -0500 From: Steve Hanna Organization: Sun Microsystems X-Mailer: Mozilla 4.51 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ross Finlayson CC: malloc Subject: Comments on MALLOC API Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Here are some comments on the MALLOC API (draft-ietf-malloc-api-04.txt). Discussion is welcome. Thanks, Steve ------------ There should be a separate Lease abstract data type. This type would include a lease identifier (such as a MADCAP Client Identifier) and other information about the lease, such as the lifetime, set of addresses, start time, etc. A variable of this type should be an out parameter for alloc_multicast_addr and an in parameter for change_multicast_addr_lifetime and deallocate_multicast_addr. The current model of passing a MulticastAddressRange to the latter two functions won't work, since there might be several leases for the same address range (perhaps allocated by different clients). Also, MADCAP requires the client to supply the Client Identifier in order to change or release a lease. We should be using MulticastAddressRangeList or MulticastAddressSet or something like that instead of MulticastAddressRange, since MADCAP servers can return several non-contiguous addresses for a single lease. The query_multicast_addr_lifetime function can be replaced by looking at fields of the Lease. The "open question" regarding who can change or deallocate a lease is no longer open. As you say, this is a policy decision and not part of the API. However, you might want to warn in the description of the Lease type (or in the Security Considerations section) that the Lease type may include a secret, which must be supplied in order to change or deallocate a lease. From owner-malloc@catarina.usc.edu Tue Apr 6 14:46:05 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 OAA15111 for ; Tue, 6 Apr 1999 14:46:04 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id KAA13027 for malloc-list; Tue, 6 Apr 1999 10:50:40 -0700 Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id KAA13023 for ; Tue, 6 Apr 1999 10:50:33 -0700 Received: (dmm@localhost) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id KAA16802; Tue, 6 Apr 1999 10:50:02 -0700 (PDT) Date: Tue, 6 Apr 1999 10:50:02 -0700 (PDT) Message-Id: <199904061750.KAA16802@zipper.cisco.com> From: David Meyer To: malloc@catarina.usc.edu cc: dmm@cisco.com, roll@stupi.se, internet-drafts@ietf.org Subject: draft-ietf-malloc-static-allocation-01.txt Sender: owner-malloc@catarina.usc.edu Precedence: bulk This incorporates Steve Hanna's suggestions. Dave --- MBONED Working Group David Meyer Internet Draft Cisco Systems Peter Lothberg Sprint Category Experimental draft-ietf-malloc-static-allocation-01.txt April, 1999 Static Allocations in 233/8 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 2. Abstract This describes an experimental policy for use of the class D address space using 233/8 as the experimental statically assigned subset of the class D address space. This new experimental allocation is in addition to those described on [IANA] (e.g. [RFC2365]). This memo is a product of the Multicast-Address Allocation working group (MALLOC) in the Internet and Transport Areas of the Internet Engineering Task Force. Submit comments to or the authors. David Meyer [Page 1] Internet Draft draft-ietf-malloc-static-allocation-01.txt April, 1999 3. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. 4. Problem Statement Multicast addresses have traditionally been allocated by a dynamic mechanism such as SDR [SAP]. However, many current multicast deployment models are not amenable to dynamic allocation. For example, many content aggregators require group addresses which are fixed on a time scale which is not amenable to allocation by a mechanism such as described in [SAP]. Perhaps more seriously, since there isn't general consensus by providers, content aggregators, or application writers as to the allocation mechanism, the Internet is left without a coherent multicast address allocation scheme. While the MALLOC working group is looking at a specific strategy [MADCAP, MASC], it is proposed that a different strategy be developed in parallel. 5. Address Space For purposes of the experiment described here, the IANA should allocate 233/8. The remaining 24 bits will be administered in a manner similar to that described in RFC1797: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 233 | 16 bits AS | local bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.1. Example Consider, for example, AS 5662. Written in binary, left padded with 0s, we get 0001011000011110. Mapping the high order octet to the second octet of the address, and the low order octet to the third octet, we get 233.22.30/24. David Meyer [Page 2] Internet Draft draft-ietf-malloc-static-allocation-01.txt April, 1999 6. Allocation As mentioned above, the allocation proposed here follows the RFC1797 (case 1) allocation scheme, modified as follows: the high order octet has the value 233, and the next 16 bits are a previously assigned Autonomous System number (AS), as registered by a network registry and listed in the RWhois database system. This allows a single /24 per AS. As was the case with RFC1797, using the AS number in this way allows the experiment to get underway quickly in that it automatically allocates some addresses to each service provider and does not require a registration step. 6.1. Private AS Space The address space mapped to the private AS space (as defined in [RFC1930], is reserved for future allocation. 7. Security Considerations The approach described here may have the effect of reduced exposure to denial of space attacks based on dynamic allocation. Further, since dynamic assignment does not cross domain boundaries, well known intra-domain security techniques can be applied. 8. IANA Considerations IANA should allocate 233/8 for experimental assignments. This assigment should timeout one year after the assigment is made. The assignment may be renewed at that time. It should be noted that the experiment described here is in the same spirit the experiment described in [RFC1797]. David Meyer [Page 3] Internet Draft draft-ietf-malloc-static-allocation-01.txt April, 1999 9. Acknowledgments This idea originated with Peter Lothberg's idea that we use the same allocation (AS based) as described in RFC 1797 in the class D address space. Randy Bush and Mark Handley contributed many insightful comments. 10. References [MADCAP] B. Patel, et. al., "Multicast Address Dynamic Client Allocation Protocol (MADCAP)", draft-ietf-malloc-madcap-04.txt, Feburay, 1999. [MASC] D. Estrin, et. al., "The Multicast Address-Set Claim (MASC) Protocol", draft-ietf-malloc-masc-01.txt, August, 1998. [IANA] www.isi.edu/in-notes/iana/assignments/multicast-addresses [RFC1797] IANA, "Class A Subnet Experiment", RFC 1797, April, 1995. [RFC1930] J. Hawkinson, et. al., "Guidelines for creation, selection, and registration of an Autonomous System (AS)", RFC1930, March, 1996. [RFC2365] David Meyer, "Administratively Scoped IP Multicast", July, 1998. [RFC2374] R. Hinden, et. al., "An IPv6 Aggregatable Global Unicast Address Format", July, 1998. [SAP] Handley, Mark, "SAP: Session Announcement Protocol", draft-ietf-mmusic-sap-00.txt, November, 1996. David Meyer [Page 4] Internet Draft draft-ietf-malloc-static-allocation-01.txt April, 1999 11. Author's Address David Meyer Cisco Systems, Inc. 170 W. Tasman Drive San Jose, CA 95134-1706 United States EMail: dmm@cisco.com Peter Lothberg Sprint VARESA0104 12502 Sunrise Valley Drive Reston VA, 20196 Email: roll@sprint.net David Meyer [Page 5] From owner-malloc@catarina.usc.edu Tue Apr 6 21:09:22 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 VAA20846 for ; Tue, 6 Apr 1999 21:09:21 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id RAA14654 for malloc-list; Tue, 6 Apr 1999 17:39:09 -0700 Received: from dthaler.microsoft.com ([131.107.1.30]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id RAA14650 for ; Tue, 6 Apr 1999 17:39:02 -0700 Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id TAA01535 for malloc@catarina.usc.edu; Tue, 6 Apr 1999 19:26:17 -0700 (PDT) (envelope-from dthaler) From: Dave Thaler Message-Id: <199904070226.TAA01535@dthaler.microsoft.com> Subject: Comments on static allocation -00 To: malloc@catarina.usc.edu Date: Tue, 6 Apr 1999 19:26:17 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit In comparing the document to RFC 1797, I notice that 1797 contains the word "Experiment" in both the title and in header at the top of each page. I wonder if it might be better for this draft to be titled "Static Allocation Experiment in 233/8" with a page header of "Multicast Static Allocation Experiment"? RFC 1797 is referenced in several places. In my opinion, it would be helpful to say what RFC 1797 is about, perhaps in section 5 where it is first mentioned. For example: "... in RFC 1797 (which describes the use of 39/8 for experimenting with subnetted class A addresses):" Is there a reference for RWhois? (I noticed that 1797 doesn't have a reference for it either.) In section 6, how about adding another sentence right before 6.1 which points out that: for debugging, using the AS number in this way also allows one to easily identify the owner AS of a given multicast address. Under security considerations, I wonder if some mention is in order on the possibility that someone else might start using some or all of the 256 addresses assigned to a given AS? Besides the typos Steve Hanna pointed out, in section 8 "as" should be inserted after "same spirit". RFC2374 is listed in the references, but is never referenced in the draft. It should either be referenced or removed. -Dave From owner-malloc@catarina.usc.edu Thu Apr 8 22:07:20 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 WAA09850 for ; Thu, 8 Apr 1999 22:07:19 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id SAA23577 for malloc-list; Thu, 8 Apr 1999 18:44:31 -0700 Received: from smtp.interlink.com.ar ([200.43.72.8]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id SAA23568; Thu, 8 Apr 1999 18:44:10 -0700 Received: from interlink.com.ar (200.43.72.7) by smtp.interlink.com.ar with ESMTP (Eudora Internet Mail Server 2.2); Thu, 8 Apr 1999 22:40:15 -0300 Received: from MYNAME (200.32.92.242) by interlink.com.ar with SMTP (Eudora Internet Mail Server 2.2); Thu, 8 Apr 1999 22:36:10 -0300 X-Sender: mediadisk@pop.softhome.net X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: desarrollos.digitales@usa.net From: Mediadisk CD-ROMs Subject: Internet Explorer 5 Date: Thu, 8 Apr 1999 22:32:02 -0300 Message-ID: <1288500974-7461304@interlink.com.ar> Sender: owner-malloc@catarina.usc.edu Precedence: bulk Ya esta disponible en CD-ROM la ultima version en castellano del Internet Explorer 5, la cual incluye: * Internet Explorer 5 Castellano Full (navegacion 50% mas rapida) * Maquina Virtual Java de Microsoft * NetMeeting * Outlook Express 5 * Chat 2.5 * Reproductor Multimedia * Direct Animation * Macromedia Shockwave * Macromedia Flash Player * Front Page Express 2.0 Tengalo en CD-ROM por solo $ 20.- Se lo llevamos a domicilio en Cap. Fed. y Gran Bs. As. sin cargo. Como siempre, tambien tenemos todas las novedades del 99 en juegos, MP3 y programas en CD-ROM. Solicite catalogo (sin compromiso) o haga su pedido a: mediadisk@softhome.net From owner-malloc@catarina.usc.edu Sat Apr 10 00:47:33 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 AAA12118 for ; Sat, 10 Apr 1999 00:47:33 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id VAA27419 for malloc-list; Fri, 9 Apr 1999 21:30:16 -0700 Received: from smtp.interlink.com.ar (smtp.interlink.com.ar [200.43.72.8]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id VAA27410; Fri, 9 Apr 1999 21:30:03 -0700 Received: from interlink.com.ar (200.43.72.7) by smtp.interlink.com.ar with ESMTP (Eudora Internet Mail Server 2.2); Sat, 10 Apr 1999 01:05:26 -0300 Received: from MYNAME (200.32.92.210) by interlink.com.ar with SMTP (Eudora Internet Mail Server 2.2); Sat, 10 Apr 1999 00:59:34 -0300 X-Sender: mediadisk@mail.24horas.com (Unverified) X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: desarrollos.digitales@usa.net From: Mediadisk CD-ROMs Subject: Internet Explorer 5 Date: Sat, 10 Apr 1999 00:55:43 -0300 Message-ID: <1288405953-13189133@interlink.com.ar> Sender: owner-malloc@catarina.usc.edu Precedence: bulk ---------------------------------------------------------------------------- ------ Disculpas a los que reciban este E-Mail duplicado, ya que tuvimos problemas con la antigua direccion de E-Mail. ---------------------------------------------------------------------------- ------ Ya esta disponible en CD-ROM la ultima version en castellano del Internet Explorer 5, la cual incluye: * Internet Explorer 5.0 Castellano Full * Maquina Virtual Java de Microsoft * NetMeeting * Outlook Express * Chat 2.5 * Reproductor Multimedia * Direct Animation * Macromedia Shockwave * Macromedia Flash Player * Front Page Express Tengalo en CD-ROM por solo $ 20.- Se lo llevamos a domicilio en Cap. Fed. y Gran Bs. As. sin cargo. Como siempre, tambien tenemos todas las novedades del 99 en juegos, MP3 y programas en CD-ROM. Solicite catalogo (sin compromiso) o haga su pedido a: mediadisk@24horas.com From owner-malloc@catarina.usc.edu Mon Apr 12 09:22:54 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 JAA27286 for ; Mon, 12 Apr 1999 09:22:53 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id FAA03090 for malloc-list; Mon, 12 Apr 1999 05:03:23 -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 FAA03086 for ; Mon, 12 Apr 1999 05:03:17 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23364; Mon, 12 Apr 1999 08:02:44 -0400 (EDT) Message-Id: <199904121202.IAA23364@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-static-ipv6-alloc-00.txt Date: Mon, 12 Apr 1999 08:02:43 -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 : Static Allocation of Multicast Addresses in the Internet Protocol Version 6 (IPv6) Author(s) : B. Haberman Filename : draft-ietf-malloc-static-ipv6-alloc-00.txt Pages : 4 Date : 11-Apr-99 This document defines a mechanism for statically allocating IPv6 multicast addresses by network prefixes. This approach will integrate seamlessly with the Multicast Address Dynamic Client Allocation Protocol (MADCAP). It will also remove the need to support the Multicast Address Set Claim (MASC) Protocol for IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-malloc-static-ipv6-alloc-00.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-static-ipv6-alloc-00.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-static-ipv6-alloc-00.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: <19990411150045.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-malloc-static-ipv6-alloc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-malloc-static-ipv6-alloc-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990411150045.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-malloc@catarina.usc.edu Thu Apr 15 11:58:12 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 LAA04406 for ; Thu, 15 Apr 1999 11:58:11 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id IAA16740 for malloc-list; Thu, 15 Apr 1999 08:23:20 -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 IAA16736 for ; Thu, 15 Apr 1999 08:23:14 -0700 Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id IAA00017 for ; Thu, 15 Apr 1999 08:23:12 -0700 (PDT) Received: from pine.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id LAA21652; Thu, 15 Apr 1999 11:23:05 -0400 Received: from sun.com (pine [129.148.75.93]) by pine.East.Sun.COM (8.9.1b+Sun/8.9.1) with ESMTP id LAA02406 for ; Thu, 15 Apr 1999 11:23:04 -0400 (EDT) Message-ID: <37160458.1AC793F@sun.com> Date: Thu, 15 Apr 1999 11:23:04 -0400 From: Steve Hanna Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.51 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: malloc Subject: MADCAP error codes/messages Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit During the IETF Last Call on MADCAP, a suggestion has been made that we add an error code and/or error message option that would allow servers to respond with an error instead of just ignoring the packet that caused the error. To avoid implosion, servers would not send error responses to multicast messages unless the Server ID matched their own. The arguments in favor of including error codes/messages are: * makes debugging easier * allows for better error messages * avoids pointless retransmissions by client The arguments against are: * no address available is handled by NAK. Other errors are rare. * adds complexity to protocol with little real-world benefit * textual error messages have internationalization problems I would like to solicit feedback from the list. What do you think? Should we add a numeric error code option to MADCAP? What about a textual error message option? Thanks, Steve From owner-malloc@catarina.usc.edu Fri Apr 16 23:16:44 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 XAA21266 for ; Fri, 16 Apr 1999 23:16:43 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id TAA24675 for malloc-list; Fri, 16 Apr 1999 19:54:41 -0700 Received: from kntinter.knt.co.jp (kntinter.knt.co.jp [202.248.38.130]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id TAA24666; Fri, 16 Apr 1999 19:54:18 -0700 Received: from noonmm (localhost [127.0.0.1]) by kntinter.knt.co.jp (8.9.1/3.7W) with ESMTP id LAA23262; Sat, 17 Apr 1999 11:49:39 +0900 (JST) Message-Id: <199904170249.LAA23262@kntinter.knt.co.jp> From: "Joe" Subject: IMPORTANTE ! To: goldlist943e@knt.co.jp X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3 Mime-Version: 1.0 Date: Fri, 16 Apr 1999 22:23:53 -0500 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA21266 -------------------------------- BASES DE DATOS EN CD-ROM PARA MARKETING POR EMAIL -------------------------------- 10.000 EMAILS ARGENTINOS $ 99 20.000 EMAILS ARGENTINOS $ 199 30.000 EMAILS ARGENTINOS $ 299 -------------------------------- DATOS ACTUALIZADOS !!! -------------------------------- LLAME AL 4312-9666 -------------------------------- Los precios NO incluyen el IVA Oferta Valida hasta el 31/06/99 ////////////////////////////////////////////////////////////// REMOVE AT mailto:offlist@isleuthmail.com ////////////////////////////////////////////////////////////// From owner-malloc@catarina.usc.edu Wed Apr 21 17:43:47 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 RAA25885 for ; Wed, 21 Apr 1999 17:43:46 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id OAA11584 for malloc-list; Wed, 21 Apr 1999 14:06:48 -0700 Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id OAA11580 for ; Wed, 21 Apr 1999 14:06:37 -0700 Received: by INET-IMC-05 with Internet Mail Service (5.5.2524.0) id <2699DYBB>; Wed, 21 Apr 1999 14:05:14 -0700 Message-ID: From: Munil Shah To: "'Steve Hanna'" , malloc Subject: RE: MADCAP error codes/messages Date: Wed, 21 Apr 1999 14:05:24 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-malloc@catarina.usc.edu Precedence: bulk I think the major point for adding the error code would be to shorten the retransmission path of the client. If a server does not provide an error code to a client then the client may continue to send bogus requests(e.g invalid scope which may have been in the client cache but no longer available on the network) to one server after another. This could add unnecessary delay on the failure path and does not really help recovery from it. You don't really want to report all the soft errors(e.g server too busy or may be out of resources temporarily). But for hard errors (e.g invalid scope) if server can provide more information then just the NAK then the client can revise its request before retransmitting to the same server or a different server. However, I don't think this is super critical at this time. Maybe we can just have a separate draft to define better reporting mechanism. I think after a little bit of real world experience with this protocol we may have a better idea of what sort of errors we might be interested in reporting back to the client. The interaction with AAP may also help us identify more error conditions we would like to report. I do not feel so strongly about the error message option though. We have had a similar option in DHCP and it has been of little use especially because there is no support for internationalization. -----Original Message----- From: Steve Hanna [mailto:steve.hanna@sun.com] Sent: Thursday, April 15, 1999 8:23 AM To: malloc Subject: MADCAP error codes/messages During the IETF Last Call on MADCAP, a suggestion has been made that we add an error code and/or error message option that would allow servers to respond with an error instead of just ignoring the packet that caused the error. To avoid implosion, servers would not send error responses to multicast messages unless the Server ID matched their own. The arguments in favor of including error codes/messages are: * makes debugging easier * allows for better error messages * avoids pointless retransmissions by client The arguments against are: * no address available is handled by NAK. Other errors are rare. * adds complexity to protocol with little real-world benefit * textual error messages have internationalization problems I would like to solicit feedback from the list. What do you think? Should we add a numeric error code option to MADCAP? What about a textual error message option? Thanks, Steve From owner-malloc@catarina.usc.edu Fri Apr 23 20:14:42 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 UAA28158 for ; Fri, 23 Apr 1999 20:14:41 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id QAA21129 for malloc-list; Fri, 23 Apr 1999 16:54:09 -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 QAA21123 for ; Fri, 23 Apr 1999 16:54:01 -0700 Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id QAA28615; Fri, 23 Apr 1999 16:53:58 -0700 (PDT) Received: from pine.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id JAA27881; Fri, 23 Apr 1999 09:10:46 -0400 Received: from sun.com (pine [129.148.75.93]) by pine.East.Sun.COM (8.9.1b+Sun/8.9.1) with ESMTP id JAA12044; Fri, 23 Apr 1999 09:10:47 -0400 (EDT) Message-ID: <37207156.46AA3E62@sun.com> Date: Fri, 23 Apr 1999 09:10:46 -0400 From: Steve Hanna Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.51 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Munil Shah CC: malloc Subject: Re: MADCAP error codes/messages References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Munil Shah wrote: > However, I don't think this is super critical at this time. Maybe we can > just have a separate draft to define better reporting mechanism. I think > after a little bit of real world experience with this protocol we may have > a better idea of what sort of errors we might be interested in reporting > back to the client. The interaction with AAP may also help us identify > more error conditions we would like to report. There are probably a few error codes that we could agree on now, like clock skew too great or malformed packets. Error code is a pretty basic thing, so maybe we should define the option and a few values now, then add other values later. Also, this raises a related issue. Currently, the MADCAP spec requires the server to ignore many kinds of messages: INFORM messages that can't be handled, RELEASE and RENEW messages with an invalid Client ID, messages that contain a Feature List option unsupported features, malformed packets (too short, unsupported version, unrecognized message type, same option appears more than once, no End option, etc.), messages with bad option values (like min lease time > lease time), and messages with excess clock skew. I would suggest changing the spec to say the server SHOULD NAK these, as long as they were received via unicast or via multicast with the Server ID matching this server. That will help the client stop misbehaving. > I do not feel so strongly about the error message option though. We have > had a similar option in DHCP and it has been of little use especially > because there is no support for internationalization. That's fine with me. We can add this later if we want to. -Steve From owner-malloc@catarina.usc.edu Mon Apr 26 15:09:19 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 PAA21999 for ; Mon, 26 Apr 1999 15:09:17 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id LAA29222 for malloc-list; Mon, 26 Apr 1999 11:34:02 -0700 Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id LAA29206 for ; Mon, 26 Apr 1999 11:33:46 -0700 Received: (dmm@localhost) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id LAA23295; Mon, 26 Apr 1999 11:32:40 -0700 (PDT) Date: Mon, 26 Apr 1999 11:32:40 -0700 (PDT) Message-Id: <199904261832.LAA23295@zipper.cisco.com> From: David Meyer To: malloc@catarina.usc.edu, internet-drafts@ietf.org cc: dmm@cisco.com, roll@stupi.se, steve.hanna@sun.com, dthaler@MICROSOFT.com Subject: please post draft-ietf-malloc-static-allocation-02.txt Sender: owner-malloc@catarina.usc.edu Precedence: bulk MALLOC Working Group David Meyer Internet Draft Cisco Systems Peter Lothberg Sprint Category Experimental draft-ietf-malloc-static-allocation-02.txt April, 1999 Static Allocations in 233/8 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 2. Abstract This describes an experimental policy for use of the class D address space using 233/8 as the experimental statically assigned subset of the class D address space. This new experimental allocation is in addition to those described on [IANA] (e.g. [RFC2365]). This memo is a product of the Multicast-Address Allocation working group (MALLOC) in the Internet and Transport Areas of the Internet Engineering Task Force. Submit comments to or the authors. David Meyer [Page 1] Internet Draft draft-ietf-malloc-static-allocation-02.txt April, 1999 3. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. 4. Problem Statement Multicast addresses have traditionally been allocated by a dynamic mechanism such as SDR [SAP]. However, many current multicast deployment models are not amenable to dynamic allocation. For example, many content aggregators require group addresses which are fixed on a time scale which is not amenable to allocation by a mechanism such as described in [SAP]. Perhaps more seriously, since there isn't general consensus by providers, content aggregators, or application writers as to the allocation mechanism, the Internet is left without a coherent multicast address allocation scheme. The MALLOC working group is looking at a specific strategy for global multicast address allocation [MADCAP, MASC]. This experiment will proceed in parallel. MADCAP may be employed within AS's, if so desired. This document proposes an experimental method of statically allocating multicast addresses with global scope. This experiment will last for a period of one year, but may be extended as described in section 8. 5. Address Space For purposes of the experiment described here, the IANA should allocate 233/8. The remaining 24 bits will be administered in a manner similar to that described in RFC1797: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 233 | 16 bits AS | local bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ David Meyer [Page 2] Internet Draft draft-ietf-malloc-static-allocation-02.txt April, 1999 5.1. Example Consider, for example, AS 5662. Written in binary, left padded with 0s, we get 0001011000011110. Mapping the high order octet to the second octet of the address, and the low order octet to the third octet, we get 233.22.30/24. 6. Allocation As mentioned above, the allocation proposed here follows the RFC1797 (case 1) allocation scheme, modified as follows: the high order octet has the value 233, and the next 16 bits are a previously assigned Autonomous System number (AS), as registered by a network registry and listed in the RWhois database system. This allows a single /24 per AS. As was the case with RFC1797, using the AS number in this way allows the experiment to get underway quickly in that it automatically allocates some addresses to each service provider and does not require a registration step. 6.1. Private AS Space The address space mapped to the private AS space (as defined in [RFC1930], is reserved for future allocation. 7. Security Considerations The approach described here may have the effect of reduced exposure to denial of space attacks based on dynamic allocation. Further, since dynamic assignment does not cross domain boundaries, well known intra-domain security techniques can be applied. David Meyer [Page 3] Internet Draft draft-ietf-malloc-static-allocation-02.txt April, 1999 8. IANA Considerations IANA should allocate 233/8 for experimental assignments. This assigment should timeout one year after the assigment is made. The assignment may be renewed at that time. It should be noted that the experiment described here is in the same spirit the experiment described in [RFC1797]. 9. Acknowledgments This idea originated with Peter Lothberg's idea that we use the same allocation (AS based) as described in RFC 1797 in the class D address space. Randy Bush and Mark Handley contributed many insightful comments. 10. References [MADCAP] B. Patel, et. al., "Multicast Address Dynamic Client Allocation Protocol (MADCAP)", draft-ietf-malloc-madcap-04.txt, Feburay, 1999. [MASC] D. Estrin, et. al., "The Multicast Address-Set Claim (MASC) Protocol", draft-ietf-malloc-masc-01.txt, August, 1998. [IANA] www.isi.edu/in-notes/iana/assignments/multicast-addresses [RFC1797] IANA, "Class A Subnet Experiment", RFC 1797, April, 1995. [RFC1930] J. Hawkinson, et. al., "Guidelines for creation, selection, and registration of an Autonomous System (AS)", RFC1930, March, 1996. [RFC2365] David Meyer, "Administratively Scoped IP Multicast", July, 1998. [RFC2374] R. Hinden, et. al., "An IPv6 Aggregatable Global Unicast Address Format", July, 1998. [SAP] Handley, Mark, "SAP: Session Announcement Protocol", draft-ietf-mmusic-sap-00.txt, November, 1996. David Meyer [Page 4] Internet Draft draft-ietf-malloc-static-allocation-02.txt April, 1999 11. Author's Address David Meyer Cisco Systems, Inc. 170 W. Tasman Drive San Jose, CA 95134-1706 United States EMail: dmm@cisco.com Peter Lothberg Sprint VARESA0104 12502 Sunrise Valley Drive Reston VA, 20196 Email: roll@sprint.net David Meyer [Page 5] From owner-malloc@catarina.usc.edu Thu Apr 29 15:12:58 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 PAA29141 for ; Thu, 29 Apr 1999 15:12:57 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id LAA13468 for malloc-list; Thu, 29 Apr 1999 11:38:26 -0700 Received: from carpincho.overnet.com.ar ([200.10.96.19]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id LAA13459; Thu, 29 Apr 1999 11:37:54 -0700 From: bnt@overnet.com.ar Received: from over (AVE2ppp-138.uc.infovia.com.ar [209.13.188.138]) by carpincho.overnet.com.ar (8.9.3/8.9.3) with SMTP id PAA00268; Thu, 29 Apr 1999 15:49:53 -0300 Date: Thu, 29 Apr 1999 15:49:53 -0300 Subject: Nuevas Tarifas Aereas Message-Id: Content-Type: TEXT/PLAIN charset=US-ASCII Sender: owner-malloc@catarina.usc.edu Precedence: bulk Apparently-To: malloc-list@catarina.usc.edu Por favor disculpar si este mail no es de su interes. Conteste con OUT si quiere ser dado de baja en la lista de distribuicion del mismo. ________________________________________________________________________________________ Madrid , Londres , Amsterdam , Frankfurt : u$s 747 + impuestos Volando con KLM, hasta el 15 de Junio. Roma: u$s 845 + impuestos, volando con Alitalia, hasta el 31 de Mayo. Paris: u$s 849 + impuestos, volando con Air France, hasta el 31 de Mayo. San Pablo: u$s 222 + impuestos, volando con Canadian Santiago de Chile: u$s 130 + impuestos, volando con British Airways Rio de Janeiro: u$s 240 + impuestos, volando con Vasp Lima: u$s 349 + impuestos, volando con Aerolineas Argentinas. ________________________________________________________________________________________ Consultas a: Buenos Aires New Travel 4312-5004 / 4312-6160 / 4315-8148 / 4313-2490 Esmeralda 1269 - 1007 - Capital Federal - bnt@overnet.com.ar ________________________________________________________________________________________ 29/04/99 From owner-malloc@catarina.usc.edu Thu Apr 29 15:42:12 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 PAA00297 for ; Thu, 29 Apr 1999 15:42:11 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id MAA13619 for malloc-list; Thu, 29 Apr 1999 12:02:43 -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 MAA13615 for ; Thu, 29 Apr 1999 12:02:38 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28710; Thu, 29 Apr 1999 15:02:04 -0400 (EDT) Message-Id: <199904291902.PAA28710@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-static-allocation-02.txt Date: Thu, 29 Apr 1999 15:02:03 -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 : Static Allocations in 233/8 Author(s) : P. Lothberg, D. Meyer Filename : draft-ietf-malloc-static-allocation-02.txt Pages : 5 Date : 26-Apr-99 This describes an experimental policy for use of the class D address space using 233/8 as the experimental statically assigned subset of the class D address space. This new experimental allocation is in addition to those described on [IANA] (e.g. [RFC2365]). This memo is a product of the Multicast-Address Allocation working group (MALLOC) in the Internet and Transport Areas of the Internet Engineering Task Force. Submit comments to or the authors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-malloc-static-allocation-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-static-allocation-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-static-allocation-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: <19990428144015.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-malloc-static-allocation-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-malloc-static-allocation-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990428144015.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-malloc@catarina.usc.edu Thu Apr 29 20:43:43 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 UAA08353 for ; Thu, 29 Apr 1999 20:43:37 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id RAA14933 for malloc-list; Thu, 29 Apr 1999 17:21:42 -0700 Received: from dm2.ofiservices.com ([200.41.138.80]) by catarina.usc.edu (8.6.10/8.6.9) with SMTP id PAA14580; Thu, 29 Apr 1999 15:37:54 -0700 Date: Thu, 29 Apr 1999 15:37:54 -0700 From: dm@mya.com.ar Message-Id: <199904292237.PAA14580@catarina.usc.edu> Sender: owner-malloc@catarina.usc.edu Precedence: bulk Apparently-To: malloc-list@catarina.usc.edu From owner-malloc@catarina.usc.edu Thu Apr 29 20:47:59 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 UAA08418 for ; Thu, 29 Apr 1999 20:47:58 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id QAA14645 for malloc-list; Thu, 29 Apr 1999 16:21:21 -0700 Received: from dm2.ofiservices.com ([200.41.138.80]) by catarina.usc.edu (8.6.10/8.6.9) with SMTP id PAA14580; Thu, 29 Apr 1999 15:37:54 -0700 Date: Thu, 29 Apr 1999 15:37:54 -0700 From: dm@mya.com.ar Message-Id: <199904292237.PAA14580@catarina.usc.edu> Sender: owner-malloc@catarina.usc.edu Precedence: bulk Apparently-To: malloc-list@catarina.usc.edu From owner-malloc@catarina.usc.edu Fri Apr 30 16:25:48 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 QAA11922 for ; Fri, 30 Apr 1999 16:25:47 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id MAA19334 for malloc-list; Fri, 30 Apr 1999 12:24:42 -0700 Received: from usc.edu (usc.edu [128.125.253.136]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id MAA19326 for ; Fri, 30 Apr 1999 12:24:37 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by usc.edu (8.8.8/8.8.8/usc) with ESMTP id HAA26470 for ; Fri, 30 Apr 1999 07:34:54 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28008; Fri, 30 Apr 1999 10:27:45 -0400 (EDT) Message-Id: <199904301427.KAA28008@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-nest-opt-01.txt Date: Fri, 30 Apr 1999 10:27:44 -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 : MADCAP Multicast Scope Nesting State Option Author(s) : R. Kermode Filename : draft-ietf-malloc-madcap-nest-opt-01.txt Pages : 13 Date : 29-Apr-99 This document defines a new option to the Multicast Address Dynamic Client Allocation Protocol (MADCAP) to support nested scoping. The new option's purpose is to allow clients to learn which scopes nest inside each other, and hence may be used for expanding scope searches or hierarchical multicast transport. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-malloc-madcap-nest-opt-01.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-nest-opt-01.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-nest-opt-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: <19990429162648.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-malloc-madcap-nest-opt-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-malloc-madcap-nest-opt-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990429162648.I-D@ietf.org> --OtherAccess-- --NextPart--