From owner-malloc@catarina.usc.edu Tue Jul 3 14:43:26 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15337 for ; Tue, 3 Jul 2001 14:43:25 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id LAA85017 for malloc-list; Tue, 3 Jul 2001 11:16:22 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id LAA85012 for ; Tue, 3 Jul 2001 11:16:21 -0700 (PDT) Received: (from pavlin@localhost) by rumi.usc.edu (8.9.3/8.9.3) id LAA08700 for malloc@catarina.usc.edu; Tue, 3 Jul 2001 11:16:21 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id LAA85002 for ; Tue, 3 Jul 2001 11:15:03 -0700 (PDT) Received: from sith.maoz.com (sith.maoz.com [205.167.76.10]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA05204 for ; Tue, 3 Jul 2001 11:15:03 -0700 (PDT) Received: (from dmm@localhost) by sith.maoz.com (8.11.3/8.11.2) id f63IEgP10747; Tue, 3 Jul 2001 11:14:42 -0700 Date: Tue, 3 Jul 2001 11:14:42 -0700 From: David Meyer To: malloc@catarina.usc.edu Cc: mjh@aciri.org, thaler@Exchange.Microsoft.com, estrin@usc.edu, van@packetdesign.com, fenner@research.att.com, iana@icann.org, dmm@sprint.net Subject: Reclaiming 225/8 Message-ID: <20010703111442.A10726@sprint.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-malloc@catarina.usc.edu Precedence: bulk 225/8 was allocated for experimentation with the MASC protocol. In particular, it was to be used to statically assign the top level of the MASC infrastructure (statically) so we didn't have to deploy a BRIB capable routing system before experimenting with the MALLOC architecture. The assignment is (from http://www.iana.org/assignments/multicast-addresses): 225.0.0.0-225.255.255.255 MALLOC (temp - renew 1/01) [Handley] Since we are not using 225/8 for this purpose (or at all, for that matter), I want to reclaim it. Mark Handley suggested that I mention this to the list. If you have comments, please respond directly to me (copying the list). Thanks, Dave From owner-malloc@catarina.usc.edu Tue Jul 3 14:43:35 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15358 for ; Tue, 3 Jul 2001 14:43:34 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id LAA85149 for malloc-list; Tue, 3 Jul 2001 11:30:08 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id LAA85144 for ; Tue, 3 Jul 2001 11:30:07 -0700 (PDT) Received: (from pavlin@localhost) by rumi.usc.edu (8.9.3/8.9.3) id LAA14301 for malloc@catarina.usc.edu; Tue, 3 Jul 2001 11:30:07 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id LAA85101 for ; Tue, 3 Jul 2001 11:26:50 -0700 (PDT) Received: from sith.maoz.com (sith.maoz.com [205.167.76.10]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA14529 for ; Tue, 3 Jul 2001 11:26:51 -0700 (PDT) Received: (from dmm@localhost) by sith.maoz.com (8.11.3/8.11.2) id f63IQoK10863; Tue, 3 Jul 2001 11:26:50 -0700 Date: Tue, 3 Jul 2001 11:26:50 -0700 From: David Meyer To: malloc@catarina.usc.edu Cc: dmm@sprint.net Subject: Re: Background regarding [Re: Reclaiming 225/8] Message-ID: <20010703112650.A10858@sprint.net> References: <20010703112429.A10841@sprint.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010703112429.A10841@sprint.net>; from dmm@sprint.net on Tue, Jul 03, 2001 at 11:24:29AM -0700 Sender: owner-malloc@catarina.usc.edu Precedence: bulk One other point to make here: These addresses are in arbitrary use, e.g. orix.maoz.com#sh ip mroute | include 225 (*, 225.1.2.3), 23:57:19/00:02:59, RP 205.167.76.241, flags: SP (128.193.22.165, 225.1.2.3), 00:01:34/00:01:25, flags: PT (128.193.25.37, 225.1.2.3), 00:02:34/00:00:25, flags: PT (128.193.190.19, 225.1.2.3), 00:02:33/00:00:26, flags: PT (128.193.190.93, 225.1.2.3), 00:02:34/00:00:25, flags: PT (128.193.191.234, 225.1.2.3), 00:02:33/00:00:26, flags: PT Dave From owner-malloc@catarina.usc.edu Tue Jul 3 14:58:03 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15887 for ; Tue, 3 Jul 2001 14:58:02 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id LAA85088 for malloc-list; Tue, 3 Jul 2001 11:25:15 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id LAA85083 for ; Tue, 3 Jul 2001 11:25:14 -0700 (PDT) Received: (from pavlin@localhost) by rumi.usc.edu (8.9.3/8.9.3) id LAA10996 for malloc@catarina.usc.edu; Tue, 3 Jul 2001 11:25:14 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id LAA85068 for ; Tue, 3 Jul 2001 11:24:34 -0700 (PDT) Received: from sith.maoz.com (sith.maoz.com [205.167.76.10]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA12733 for ; Tue, 3 Jul 2001 11:24:34 -0700 (PDT) Received: (from dmm@localhost) by sith.maoz.com (8.11.3/8.11.2) id f63IOTa10849; Tue, 3 Jul 2001 11:24:29 -0700 Date: Tue, 3 Jul 2001 11:24:29 -0700 From: David Meyer To: malloc@catarina.usc.edu Cc: dmm@sprint.net Subject: Background regarding [Re: Reclaiming 225/8] Message-ID: <20010703112429.A10841@sprint.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-malloc@catarina.usc.edu Precedence: bulk Please see draft-ietf-mboned-iana-ipv4-mcast-guidelines-03.txt Thanks, Dave On Tue, Jul 03, 2001 at 11:14:42AM -0700, David Meyer wrote: >> >> 225/8 was allocated for experimentation with the MASC protocol. >> In particular, it was to be used to statically assign the top >> level of the MASC infrastructure (statically) so we didn't have >> to deploy a BRIB capable routing system before experimenting >> with the MALLOC architecture. The assignment is (from >> http://www.iana.org/assignments/multicast-addresses): >> >> 225.0.0.0-225.255.255.255 MALLOC (temp - renew 1/01) [Handley] >> >> Since we are not using 225/8 for this purpose (or at all, for >> that matter), I want to reclaim it. Mark Handley suggested that >> I mention this to the list. If you have comments, please >> respond directly to me (copying the list). >> >> Thanks, >> >> Dave From owner-malloc@catarina.usc.edu Tue Jul 3 15:04:52 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16099 for ; Tue, 3 Jul 2001 15:04:51 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id LAA85227 for malloc-list; Tue, 3 Jul 2001 11:44:35 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id LAA85222 for ; Tue, 3 Jul 2001 11:44:34 -0700 (PDT) Received: (from pavlin@localhost) by rumi.usc.edu (8.9.3/8.9.3) id LAA19856 for malloc@catarina.usc.edu; Tue, 3 Jul 2001 11:44:34 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id LAA85169 for ; Tue, 3 Jul 2001 11:34:37 -0700 (PDT) From: shep@shepfarm.com Received: from shepfarm.com (IDENT:root@shepfarm.com [198.58.3.10]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA20202 for ; Tue, 3 Jul 2001 11:34:37 -0700 (PDT) Received: from shepfarm.com (IDENT:shep@shepfarm.com [198.58.3.10]) by shepfarm.com (8.11.3/8.11.3) with ESMTP id f63JPeC27755; Tue, 3 Jul 2001 12:25:40 -0700 Date: Tue, 3 Jul 2001 12:25:40 -0700 (PDT) To: David Meyer cc: malloc@catarina.usc.edu Subject: Re: Background regarding [Re: Reclaiming 225/8] In-Reply-To: <20010703112429.A10841@sprint.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-malloc@catarina.usc.edu Precedence: bulk Good idea Dave. Yes, I'm in favor of reclaiming it. Thanks, Greg On Tue, 3 Jul 2001, David Meyer wrote: > > Please see draft-ietf-mboned-iana-ipv4-mcast-guidelines-03.txt > > Thanks, > > Dave > > > > > On Tue, Jul 03, 2001 at 11:14:42AM -0700, David Meyer wrote: > >> > >> 225/8 was allocated for experimentation with the MASC protocol. > >> In particular, it was to be used to statically assign the top > >> level of the MASC infrastructure (statically) so we didn't have > >> to deploy a BRIB capable routing system before experimenting > >> with the MALLOC architecture. The assignment is (from > >> http://www.iana.org/assignments/multicast-addresses): > >> > >> 225.0.0.0-225.255.255.255 MALLOC (temp - renew 1/01) [Handley] > >> > >> Since we are not using 225/8 for this purpose (or at all, for > >> that matter), I want to reclaim it. Mark Handley suggested that > >> I mention this to the list. If you have comments, please > >> respond directly to me (copying the list). > >> > >> Thanks, > >> > >> Dave > From owner-malloc@catarina.usc.edu Thu Jul 5 12:51:00 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19384 for ; Thu, 5 Jul 2001 12:50:54 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id JAA93031 for malloc-list; Thu, 5 Jul 2001 09:35:36 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id JAA93026 for ; Thu, 5 Jul 2001 09:35:35 -0700 (PDT) Received: (from pavlin@localhost) by rumi.usc.edu (8.9.3/8.9.3) id JAA40997 for malloc@catarina.usc.edu; Thu, 5 Jul 2001 09:35:35 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id JAA93009 for ; Thu, 5 Jul 2001 09:34:09 -0700 (PDT) Received: from sith.maoz.com (sith.maoz.com [205.167.76.10]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id JAA01680 for ; Thu, 5 Jul 2001 09:34:10 -0700 (PDT) Received: (from dmm@localhost) by sith.maoz.com (8.11.3/8.11.2) id f65GY4T16433; Thu, 5 Jul 2001 09:34:04 -0700 Date: Thu, 5 Jul 2001 09:34:04 -0700 From: David Meyer To: malloc@catarina.usc.edu, mboned@network-services.uoregon.edu Cc: mjh@aciri.org, thaler@Exchange.Microsoft.com, estrin@usc.edu, van@packetdesign.com, fenner@research.att.com, iana@icann.org, dmm@sprint.net, randy@psg.com, zaid@juniper.net, almeroth@cs.ucsb.edu, narten@raleigh.ibm.com Subject: more on reclaiming 225/8 Message-ID: <20010705093404.B16396@sprint.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-malloc@catarina.usc.edu Precedence: bulk Regarding what I saw at OSU (225.1.2.3): corvallis-hub>sh ip mroute | inc 225.1.2.3 (*, 225.1.2.3), 4w1d/00:02:59, RP 207.98.64.240, flags: SP [...] (128.193.22.165, 225.1.2.3), 07:41:37/00:03:11, flags: T (128.193.25.37, 225.1.2.3), 05:45:54/00:03:11, flags: T (128.193.190.19, 225.1.2.3), 1w0d/00:03:11, flags: T (128.193.190.93, 225.1.2.3), 5d06h/00:03:11, flags: T [...] There are a ton of these (> 110) in use. Why? It would appear that there is a software/OS replication package named Altiris distributed by/with Compaq. The default OS installation on the Compaqs includes Altiris (whatever it is) and it is configured to use 225.1.2.3 as its default group. However, I can't tell this is a Compaq setting or an Altiris default. This is yet another reason why we need a document like draft-ietf-mboned-iana-ipv4-mcast-guidelines-03.txt. Dave ----- >> 225/8 was allocated for experimentation with the MASC protocol. >> In particular, it was to be used to statically assign the top >> level of the MASC infrastructure (statically) so we didn't have >> to deploy a BRIB capable routing system before experimenting >> with the MALLOC architecture. The assignment is (from >> http://www.iana.org/assignments/multicast-addresses): >> >> 225.0.0.0-225.255.255.255 MALLOC (temp - renew 1/01) [Handley] >> >> Since we are not using 225/8 for this purpose (or at all, for >> that matter), I want to reclaim it. Mark Handley suggested that >> I mention this to the list. If you have comments, please >> respond directly to me (copying the list). >> >> Thanks, >> >> Dave From owner-malloc@catarina.usc.edu Thu Jul 5 16:00:32 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25631 for ; Thu, 5 Jul 2001 16:00:31 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id MAA93748 for malloc-list; Thu, 5 Jul 2001 12:47:30 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id MAA93743 for ; Thu, 5 Jul 2001 12:47:29 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id MAA06933 for ; Thu, 5 Jul 2001 12:47:28 -0700 (PDT) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f65Jb4P00837; Thu, 5 Jul 2001 12:37:04 -0700 (PDT) Received: from cisco.com (dhcp-171-69-127-182.cisco.com [171.69.127.182]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id AKN00503 (AUTH jmeylor); Thu, 5 Jul 2001 12:36:55 -0700 (PDT) Message-ID: <3B44C1F8.C0D95202@cisco.com> Date: Thu, 05 Jul 2001 12:37:28 -0700 From: John Meylor X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: David Meyer CC: zaid , Hugh LaMaster , malloc@catarina.usc.edu, Mboned List , Mark Handley , thaler@Exchange.Microsoft.com, Deborah Estrin , van@packetdesign.com, Bill Fenner , iana@icann.org, Randy Bush , Kevin Almeroth , narten@raleigh.ibm.com Subject: Re: more on reclaiming 225/8 References: <20010705122126.A17282@sprint.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit David Meyer wrote: > > >> May be this needs to specifically include product developers and vendors : > >> > >> 15. Use of IANA Reserved Addresses > >> > >> Applications MUST NOT use addressing in the IANA reserved blocks. > > My sense is that's a different document. I'd like to keep this > one focused on the IANA. right, again, perhaps something like . john From owner-malloc@catarina.usc.edu Thu Jul 5 16:00:36 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25642 for ; Thu, 5 Jul 2001 16:00:34 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id MAA93691 for malloc-list; Thu, 5 Jul 2001 12:42:13 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id MAA93686 for ; Thu, 5 Jul 2001 12:42:12 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id MAA03720 for ; Thu, 5 Jul 2001 12:42:11 -0700 (PDT) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f65JaBP00466; Thu, 5 Jul 2001 12:36:12 -0700 (PDT) Received: from cisco.com (dhcp-171-69-127-182.cisco.com [171.69.127.182]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id AKN00476 (AUTH jmeylor); Thu, 5 Jul 2001 12:36:02 -0700 (PDT) Message-ID: <3B44C1C4.6E202C91@cisco.com> Date: Thu, 05 Jul 2001 12:36:36 -0700 From: John Meylor X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Hugh LaMaster CC: malloc@catarina.usc.edu, David Meyer , Mboned List , Mark Handley , thaler@Exchange.Microsoft.com, Deborah Estrin , van@packetdesign.com, Bill Fenner , iana@icann.org, Randy Bush , Zaid Albanna , Kevin Almeroth , narten@raleigh.ibm.com Subject: Re: more on reclaiming 225/8 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hugh LaMaster wrote: > > We seem to need some kind of educational effort to get > the word out to these companies regarding sensible use. indeed > Certainly, some uses are obviously not sensible, but, > I don't see anything in > > http://www.ietf.org/internet-drafts/draft-ietf-mboned-iana-ipv4-mcast-guidelines-03.txt > > that specifically prescribes the correct thing to do > to a consumer product developer. perhaps this could be incorporated into something like Bob, Kevins: in section on address management. John From owner-malloc@catarina.usc.edu Thu Jul 5 19:28:49 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29942 for ; Thu, 5 Jul 2001 19:28:48 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id QAA94933 for malloc-list; Thu, 5 Jul 2001 16:16:14 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id QAA94928 for ; Thu, 5 Jul 2001 16:16:13 -0700 (PDT) Received: (from pavlin@localhost) by rumi.usc.edu (8.9.3/8.9.3) id QAA54918 for malloc@catarina.usc.edu; Thu, 5 Jul 2001 16:16:13 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id NAA93899 for ; Thu, 5 Jul 2001 13:19:04 -0700 (PDT) Received: from real.com (prognet.com [205.219.198.1]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id NAA26937 for ; Thu, 5 Jul 2001 13:19:04 -0700 (PDT) Received: from real.com ([172.23.106.100]) by real.com (8.9.2/8.9.0) with ESMTP id NAA12092; Thu, 5 Jul 2001 13:15:44 -0700 (PDT) Message-ID: <3B44CAB2.E1F171F8@real.com> Date: Thu, 05 Jul 2001 13:14:42 -0700 From: Brad Hefta-Gaub Organization: RealNetworks X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Hugh LaMaster CC: malloc@catarina.usc.edu, David Meyer , Mboned List , Mark Handley , thaler@Exchange.Microsoft.com, Deborah Estrin , van@packetdesign.com, Bill Fenner , iana@icann.org, Randy Bush , Zaid Albanna , Kevin Almeroth , narten@raleigh.ibm.com Subject: Re: more on reclaiming 225/8 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hugh LaMaster wrote: > Should sdr-like code be required in such products? I don't know what the companies have > in mind if multiple users on a LAN happen to be using the same product. Have any people > on these mailing lists had any discussions with the folks > at these companies regarding what they are going with such products? These are some great questions, and I'm glad to see the discussion group turning its attention to this topic. As a developer of server software that transmits multicast we seriously considered this question and came to the following implementation. 1) We allow users to dynamically configure the address ranges used by each RealSystem Server instance. In our documentation we attempt to educate the users to the standards and issue involved in the selection of an address range. 2) We have also implemented optional support for SAP/SDR. In our implementation, the server can be asked to send out SAP announcements, as well as listen for SAP announcements. When our product is configured to listen for SAP announcements it will remove any addresses that are announced as in use from it's range of selectable addresses. When it is configured to announce, it obviously announces the addresses it is using. For intranet uses, we recommend that network administrators configure their servers to announce and listen for SAP, and provide each of there servers with the same reasonably sized range of addresses. In this configurations, multiple RealSystem Servers will happily coexist without stepping on each others address spaces. Assuming the user is using other multicast applications on their network, they can either configure the RealSystem Server to avoid address ranges they've applied to those other applications, or if that application also uses SAP/SDR, then the RealSystem Server will automatically detect its announcements and avoid those addresses that are in use. Now, to be clear, this is what we've implemented to date. We recognize that SAP never really reached standards track, but we implemented this support before alternate solutions were available. We are aware that today MADCAP is a standards track solution for address allocation, and we are reviewing the feasibility of implementing support for this, as well, in our products. At this point, we don't hear demand for this from our customers. I am curious if the group has insight into the general availability and use of MADCAP servers in the field. (Which vendors have shipping MADCAP server implementations, etc.) I would envision us taking the approach in the future of allowing the use of MADCAP as an option to the user configured address range. I would welcome any feedback that the group might have on the approach we've taken. -Brad Brad Hefta-Gaub General Manager of Product Development Media Systems Division RealNetworks, Inc. From owner-malloc@catarina.usc.edu Thu Jul 5 19:28:49 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29946 for ; Thu, 5 Jul 2001 19:28:49 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id QAA94905 for malloc-list; Thu, 5 Jul 2001 16:15:08 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id QAA94900 for ; Thu, 5 Jul 2001 16:15:07 -0700 (PDT) Received: (from pavlin@localhost) by rumi.usc.edu (8.9.3/8.9.3) id QAA54878 for malloc@catarina.usc.edu; Thu, 5 Jul 2001 16:15:07 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id MAA93715 for ; Thu, 5 Jul 2001 12:44:14 -0700 (PDT) Received: from magenta.juniper.net (natint.juniper.net [207.17.136.129]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id MAA05045 for ; Thu, 5 Jul 2001 12:44:14 -0700 (PDT) Received: from zaid-bsd.jnpr.net (zaid-bsd.jnpr.net [172.25.42.116] (may be forged)) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id f65Jhbf36243; Thu, 5 Jul 2001 12:43:37 -0700 (PDT) (envelope-from zaid@juniper.net) Date: Thu, 5 Jul 2001 15:39:02 -0400 (EDT) From: zaid To: David Meyer cc: Hugh LaMaster , malloc@catarina.usc.edu, Mboned List , Mark Handley , thaler@Exchange.Microsoft.com, Deborah Estrin , van@packetdesign.com, Bill Fenner , iana@icann.org, Randy Bush , Kevin Almeroth , narten@raleigh.ibm.com Subject: Re: more on reclaiming 225/8 In-Reply-To: <20010705122126.A17282@sprint.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-malloc@catarina.usc.edu Precedence: bulk I can see where this can blow up once we start including vendor/apps specific points. Zaid On Thu, 5 Jul 2001, David Meyer wrote: > >> May be this needs to specifically include product developers and vendors : > >> > >> 15. Use of IANA Reserved Addresses > >> > >> Applications MUST NOT use addressing in the IANA reserved blocks. > > My sense is that's a different document. I'd like to keep this > one focused on the IANA. > > Dave > From owner-malloc@catarina.usc.edu Thu Jul 5 19:28:51 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29943 for ; Thu, 5 Jul 2001 19:28:49 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id QAA94912 for malloc-list; Thu, 5 Jul 2001 16:15:22 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id QAA94907 for ; Thu, 5 Jul 2001 16:15:21 -0700 (PDT) Received: (from pavlin@localhost) by rumi.usc.edu (8.9.3/8.9.3) id QAA54888 for malloc@catarina.usc.edu; Thu, 5 Jul 2001 16:15:21 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id MAA93728 for ; Thu, 5 Jul 2001 12:45:34 -0700 (PDT) Received: from sith.maoz.com (sith.maoz.com [205.167.76.10]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id MAA05930 for ; Thu, 5 Jul 2001 12:45:34 -0700 (PDT) Received: (from dmm@localhost) by sith.maoz.com (8.11.3/8.11.2) id f65JjTd17510; Thu, 5 Jul 2001 12:45:29 -0700 Date: Thu, 5 Jul 2001 12:45:29 -0700 From: David Meyer To: John Meylor Cc: Hugh LaMaster , malloc@catarina.usc.edu, Mboned List , Mark Handley , thaler@Exchange.Microsoft.com, Deborah Estrin , van@packetdesign.com, Bill Fenner , iana@icann.org, Randy Bush , Zaid Albanna , Kevin Almeroth , narten@raleigh.ibm.com Subject: Re: more on reclaiming 225/8 Message-ID: <20010705124529.A17502@sprint.net> References: <3B44C1C4.6E202C91@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B44C1C4.6E202C91@cisco.com>; from jmeylor@cisco.com on Thu, Jul 05, 2001 at 12:36:36PM -0700 Sender: owner-malloc@catarina.usc.edu Precedence: bulk >> > that specifically prescribes the correct thing to do >> > to a consumer product developer. >> >> perhaps this could be incorporated into something like Bob, Kevins: >> in section on address management. Good idea (as I said, it belongs somewhere, just not in the IANA guidelines). Dave From owner-malloc@catarina.usc.edu Thu Jul 5 19:29:46 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29987 for ; Thu, 5 Jul 2001 19:29:44 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id QAA94961 for malloc-list; Thu, 5 Jul 2001 16:17:33 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id QAA94956 for ; Thu, 5 Jul 2001 16:17:32 -0700 (PDT) Received: (from pavlin@localhost) by rumi.usc.edu (8.9.3/8.9.3) id QAA54967 for malloc@catarina.usc.edu; Thu, 5 Jul 2001 16:17:32 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id OAA94187 for ; Thu, 5 Jul 2001 14:17:43 -0700 (PDT) Received: from mail1.cisco.com (mail1.cisco.com [171.68.225.60]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id OAA10513 for ; Thu, 5 Jul 2001 14:17:42 -0700 (PDT) Received: from bwilliam-t20.cisco.com (dhcp-161-44-19-39.cisco.com [161.44.19.39]) by mail1.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA26247; Thu, 5 Jul 2001 14:15:56 -0700 (PDT) Message-Id: <4.3.2.7.2.20010705160615.05473008@mail1.cisco.com> X-Sender: bwilliam@mail1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 05 Jul 2001 16:12:52 -0500 To: Hugh LaMaster , malloc@catarina.usc.edu From: Beau Williamson Subject: Re: more on reclaiming 225/8 Cc: John Meylor , David Meyer , Hugh LaMaster , Mboned List , Mark Handley , thaler@Exchange.Microsoft.com, Deborah Estrin , van@packetdesign.com, Bill Fenner , iana@icann.org, Randy Bush , Zaid Albanna , Kevin Almeroth , narten@raleigh.ibm.com In-Reply-To: References: <20010705124529.A17502@sprint.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-malloc@catarina.usc.edu Precedence: bulk Hugh, Wouldn't this be better handled by having all applications use MADCAP to obtain the group address? After all, this is what that protocol was designed to do. (If I remember correctly.) Of course there is a problem if the application is a legacy application that doesn't support MADCAP and doesn't bother to request an group address. How would you enforce certain policies concerning group address usage? I have several customers that are wrestling with these sorts of issues (admission control, rate-limiting, address-allocation, etc.) and it doesn't appear that there are any standard ways to deal with these problems. Beau At 03:22 PM 7/5/2001, Hugh LaMaster wrote: >On Thu, 5 Jul 2001, David Meyer wrote: > >> >> > that specifically prescribes the correct thing to do >> >> > to a consumer product developer. >> >> >> >> perhaps this could be incorporated into something like Bob, Kevins: >> >> in section on address management. >> >> Good idea (as I said, it belongs somewhere, just not in the IANA >> guidelines). > >Sounds good to me also. In fact, I see that the section on >address management actually does have this started: > > > In almost all cases, application designers should assume that > multicast addresses are to be dynamic. Very little of the multicast > address space is available for static assignment by IANA [MADDR]. > Also, given the host-specific addressing available with SSM, Internet- > wide, static address assignment is expected to be very rare. > > >I think with a little more directness, e.g., drop a few qualifiers: > > Application designers should assume that multicast addresses are > to be dynamic. > >But, from this point on, I'm not sure what should be written. >Most of this document is written from the perspective of >streaming media servers/clients or the similar videoconferencing, >but, the applications that are causing the most trouble with MSDP >&etc. are things that don't fit that model - e.g. DriveImage. > >How *should* a non-interactive non-A/V mostly-local application >get its address (presumably in 239.255.x.y) and (port)? >Although sdr does work on the 239.x.y.z spaces by using >the appropriate multicast address, e.g., for 239.255.x.y, >239.255.255.255 for the SAP announcements, it isn't obvious >to me that a batch/CLI type application that might be run >automatically at a particular time fits the sdr/SAP model. > >I'm speculating that a query mechanism could be used, e.g., IGMPv3 >general query, that would instantaneously return groups >to be avoided, and that the application could then randomly >select address and port, and then advertise via SAP >the selected group in 239.255/16. Is that a bad idea (probably)? > > >-- > Hugh LaMaster, M/S 233-21, Email: lamaster@nas.nasa.gov > NASA Ames Research Center Or: lamaster@nren.nasa.gov > Moffett Field, CA 94035-1000 Or: lamaster@kinkajou.arc.nasa.gov > Phone: 650/604-1056 Disc: Unofficial, personal *opinion*. From owner-malloc@catarina.usc.edu Thu Jul 5 19:30:46 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00043 for ; Thu, 5 Jul 2001 19:30:44 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id QAA94947 for malloc-list; Thu, 5 Jul 2001 16:16:38 -0700 (PDT) Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id QAA94942 for ; Thu, 5 Jul 2001 16:16:37 -0700 (PDT) Received: (from pavlin@localhost) by rumi.usc.edu (8.9.3/8.9.3) id QAA54935 for malloc@catarina.usc.edu; Thu, 5 Jul 2001 16:16:37 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id NAA93978 for ; Thu, 5 Jul 2001 13:26:53 -0700 (PDT) Received: from kinkajou.arc.nasa.gov (kinkajou.arc.nasa.gov [128.102.196.170]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id NAA02777 for ; Thu, 5 Jul 2001 13:26:52 -0700 (PDT) Received: from localhost (lamaster@localhost) by kinkajou.arc.nasa.gov (8.9.3+Sun/8.9.1) with ESMTP id NAA01248; Thu, 5 Jul 2001 13:22:55 -0700 (PDT) X-Authentication-Warning: kinkajou.arc.nasa.gov: lamaster owned process doing -bs Date: Thu, 5 Jul 2001 13:22:54 -0700 (PDT) From: Hugh LaMaster X-Sender: lamaster@kinkajou.arc.nasa.gov To: malloc@catarina.usc.edu cc: John Meylor , David Meyer , Hugh LaMaster , Mboned List , Mark Handley , thaler@Exchange.Microsoft.com, Deborah Estrin , van@packetdesign.com, Bill Fenner , iana@icann.org, Randy Bush , Zaid Albanna , Kevin Almeroth , narten@raleigh.ibm.com Subject: Re: more on reclaiming 225/8 In-Reply-To: <20010705124529.A17502@sprint.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-malloc@catarina.usc.edu Precedence: bulk On Thu, 5 Jul 2001, David Meyer wrote: > >> > that specifically prescribes the correct thing to do > >> > to a consumer product developer. > >> > >> perhaps this could be incorporated into something like Bob, Kevins: > >> in section on address management. > > Good idea (as I said, it belongs somewhere, just not in the IANA > guidelines). Sounds good to me also. In fact, I see that the section on address management actually does have this started: In almost all cases, application designers should assume that multicast addresses are to be dynamic. Very little of the multicast address space is available for static assignment by IANA [MADDR]. Also, given the host-specific addressing available with SSM, Internet- wide, static address assignment is expected to be very rare. I think with a little more directness, e.g., drop a few qualifiers: Application designers should assume that multicast addresses are to be dynamic. But, from this point on, I'm not sure what should be written. Most of this document is written from the perspective of streaming media servers/clients or the similar videoconferencing, but, the applications that are causing the most trouble with MSDP &etc. are things that don't fit that model - e.g. DriveImage. How *should* a non-interactive non-A/V mostly-local application get its address (presumably in 239.255.x.y) and (port)? Although sdr does work on the 239.x.y.z spaces by using the appropriate multicast address, e.g., for 239.255.x.y, 239.255.255.255 for the SAP announcements, it isn't obvious to me that a batch/CLI type application that might be run automatically at a particular time fits the sdr/SAP model. I'm speculating that a query mechanism could be used, e.g., IGMPv3 general query, that would instantaneously return groups to be avoided, and that the application could then randomly select address and port, and then advertise via SAP the selected group in 239.255/16. Is that a bad idea (probably)? -- Hugh LaMaster, M/S 233-21, Email: lamaster@nas.nasa.gov NASA Ames Research Center Or: lamaster@nren.nasa.gov Moffett Field, CA 94035-1000 Or: lamaster@kinkajou.arc.nasa.gov Phone: 650/604-1056 Disc: Unofficial, personal *opinion*. From owner-malloc@catarina.usc.edu Thu Jul 5 19:31:37 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00066 for ; Thu, 5 Jul 2001 19:31:37 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id QAA94839 for malloc-list; Thu, 5 Jul 2001 16:13:37 -0700 (PDT) Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id QAA94834 for ; Thu, 5 Jul 2001 16:13:36 -0700 (PDT) Received: (from pavlin@localhost) by rumi.usc.edu (8.9.3/8.9.3) id QAA54808 for malloc@catarina.usc.edu; Thu, 5 Jul 2001 16:13:36 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id LAA93482 for ; Thu, 5 Jul 2001 11:45:43 -0700 (PDT) Received: from kinkajou.arc.nasa.gov (kinkajou.arc.nasa.gov [128.102.196.170]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA28711 for ; Thu, 5 Jul 2001 11:45:43 -0700 (PDT) Received: from localhost (lamaster@localhost) by kinkajou.arc.nasa.gov (8.9.3+Sun/8.9.1) with ESMTP id LAA00596; Thu, 5 Jul 2001 11:41:36 -0700 (PDT) X-Authentication-Warning: kinkajou.arc.nasa.gov: lamaster owned process doing -bs Date: Thu, 5 Jul 2001 11:41:36 -0700 (PDT) From: Hugh LaMaster X-Sender: lamaster@kinkajou.arc.nasa.gov To: malloc@catarina.usc.edu cc: David Meyer , Mboned List , Mark Handley , thaler@Exchange.Microsoft.com, Deborah Estrin , van@packetdesign.com, Bill Fenner , iana@icann.org, Randy Bush , Zaid Albanna , Kevin Almeroth , narten@raleigh.ibm.com Subject: Re: more on reclaiming 225/8 In-Reply-To: <20010705093404.B16396@sprint.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-malloc@catarina.usc.edu Precedence: bulk On Thu, 5 Jul 2001, David Meyer wrote: > Regarding what I saw at OSU (225.1.2.3): > > corvallis-hub>sh ip mroute | inc 225.1.2.3 > (*, 225.1.2.3), 4w1d/00:02:59, RP 207.98.64.240, flags: SP > [...] > (128.193.22.165, 225.1.2.3), 07:41:37/00:03:11, flags: T > (128.193.25.37, 225.1.2.3), 05:45:54/00:03:11, flags: T > (128.193.190.19, 225.1.2.3), 1w0d/00:03:11, flags: T > (128.193.190.93, 225.1.2.3), 5d06h/00:03:11, flags: T > [...] > > There are a ton of these (> 110) in use. Why? It would appear > that there is a software/OS replication package named Altiris > distributed by/with Compaq. The default OS installation on the > Compaqs includes Altiris (whatever it is) and it is configured to > use 225.1.2.3 as its default group. However, I can't tell this is > a Compaq setting or an Altiris default. > > This is yet another reason why we need a document like > draft-ietf-mboned-iana-ipv4-mcast-guidelines-03.txt. We seem to need some kind of educational effort to get the word out to these companies regarding sensible use. Certainly, some uses are obviously not sensible, but, I don't see anything in http://www.ietf.org/internet-drafts/draft-ietf-mboned-iana-ipv4-mcast-guidelines-03.txt that specifically prescribes the correct thing to do to a consumer product developer. I think static assignments in, e.g., 224.[0,1].x.y are almost always a bad idea, but, I'm not sure how a product, intended for use by folks who know little or nothing about multicast, should [automatically] go about assigning such an address dynamically. Something in 239.255/16 is definitely local, but, how should the address/port be assigned? Should sdr-like code be required in such products? I don't know what the companies have in mind if multiple users on a LAN happen to be using the same product. Have any people on these mailing lists had any discussions with the folks at these companies regarding what they are going with such products? -- Hugh LaMaster, M/S 233-21, Email: lamaster@nas.nasa.gov NASA Ames Research Center Or: lamaster@nren.nasa.gov Moffett Field, CA 94035-1000 Or: lamaster@kinkajou.arc.nasa.gov Phone: 650/604-1056 Disc: Unofficial, personal *opinion*. From owner-malloc@catarina.usc.edu Thu Jul 5 19:33:01 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00112 for ; Thu, 5 Jul 2001 19:33:00 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id QAA94846 for malloc-list; Thu, 5 Jul 2001 16:13:49 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id QAA94841 for ; Thu, 5 Jul 2001 16:13:48 -0700 (PDT) Received: (from pavlin@localhost) by rumi.usc.edu (8.9.3/8.9.3) id QAA54821 for malloc@catarina.usc.edu; Thu, 5 Jul 2001 16:13:48 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id LAA93492 for ; Thu, 5 Jul 2001 11:47:30 -0700 (PDT) Received: from sith.maoz.com (sith.maoz.com [205.167.76.10]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA29832 for ; Thu, 5 Jul 2001 11:47:30 -0700 (PDT) Received: (from dmm@localhost) by sith.maoz.com (8.11.3/8.11.2) id f65IlRX17038; Thu, 5 Jul 2001 11:47:27 -0700 Date: Thu, 5 Jul 2001 11:47:27 -0700 From: David Meyer To: Hugh LaMaster Cc: malloc@catarina.usc.edu, Mboned List , Mark Handley , thaler@Exchange.Microsoft.com, Deborah Estrin , van@packetdesign.com, Bill Fenner , iana@icann.org, Randy Bush , Zaid Albanna , Kevin Almeroth , narten@raleigh.ibm.com Subject: Re: more on reclaiming 225/8 Message-ID: <20010705114727.A17035@sprint.net> References: <20010705093404.B16396@sprint.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from lamaster@nas.nasa.gov on Thu, Jul 05, 2001 at 11:41:36AM -0700 Sender: owner-malloc@catarina.usc.edu Precedence: bulk >> I don't see anything in >> >> http://www.ietf.org/internet-drafts/draft-ietf-mboned-iana-ipv4-mcast-guidelines-03.txt >> >> that specifically prescribes the correct thing to do >> to a consumer product developer. That's because it's not targetted at developers. Its built to guide the IANA. >> users on a LAN happen to be using the same product. Have any >> people on these mailing lists had any discussions with the folks >> at these companies regarding what they are going with such products? I have not. Dave From owner-malloc@catarina.usc.edu Thu Jul 5 19:33:03 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00122 for ; Thu, 5 Jul 2001 19:33:02 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id QAA94872 for malloc-list; Thu, 5 Jul 2001 16:14:25 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id QAA94867 for ; Thu, 5 Jul 2001 16:14:24 -0700 (PDT) Received: (from pavlin@localhost) by rumi.usc.edu (8.9.3/8.9.3) id QAA54843 for malloc@catarina.usc.edu; Thu, 5 Jul 2001 16:14:24 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id MAA93586 for ; Thu, 5 Jul 2001 12:21:30 -0700 (PDT) Received: from sith.maoz.com (sith.maoz.com [205.167.76.10]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id MAA21659 for ; Thu, 5 Jul 2001 12:21:29 -0700 (PDT) Received: (from dmm@localhost) by sith.maoz.com (8.11.3/8.11.2) id f65JLQD17303; Thu, 5 Jul 2001 12:21:26 -0700 Date: Thu, 5 Jul 2001 12:21:26 -0700 From: David Meyer To: zaid Cc: Hugh LaMaster , malloc@catarina.usc.edu, Mboned List , Mark Handley , thaler@Exchange.Microsoft.com, Deborah Estrin , van@packetdesign.com, Bill Fenner , iana@icann.org, Randy Bush , Kevin Almeroth , narten@raleigh.ibm.com Subject: Re: more on reclaiming 225/8 Message-ID: <20010705122126.A17282@sprint.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from zaid@juniper.net on Thu, Jul 05, 2001 at 03:05:42PM -0400 Sender: owner-malloc@catarina.usc.edu Precedence: bulk >> May be this needs to specifically include product developers and vendors : >> >> 15. Use of IANA Reserved Addresses >> >> Applications MUST NOT use addressing in the IANA reserved blocks. My sense is that's a different document. I'd like to keep this one focused on the IANA. Dave From owner-malloc@catarina.usc.edu Thu Jul 5 19:35:21 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00165 for ; Thu, 5 Jul 2001 19:35:20 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id QAA94887 for malloc-list; Thu, 5 Jul 2001 16:14:39 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id QAA94882 for ; Thu, 5 Jul 2001 16:14:38 -0700 (PDT) Received: (from pavlin@localhost) by rumi.usc.edu (8.9.3/8.9.3) id QAA54858 for malloc@catarina.usc.edu; Thu, 5 Jul 2001 16:14:38 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id MAA93639 for ; Thu, 5 Jul 2001 12:36:02 -0700 (PDT) Received: from magenta.juniper.net (natint.juniper.net [207.17.136.129]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id MAA29875 for ; Thu, 5 Jul 2001 12:35:59 -0700 (PDT) Received: from zaid-bsd.jnpr.net (zaid-bsd.jnpr.net [172.25.42.116] (may be forged)) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id f65JAHf36169; Thu, 5 Jul 2001 12:10:17 -0700 (PDT) (envelope-from zaid@juniper.net) Date: Thu, 5 Jul 2001 15:05:42 -0400 (EDT) From: zaid To: Hugh LaMaster cc: malloc@catarina.usc.edu, David Meyer , Mboned List , Mark Handley , thaler@Exchange.Microsoft.com, Deborah Estrin , van@packetdesign.com, Bill Fenner , iana@icann.org, Randy Bush , Kevin Almeroth , narten@raleigh.ibm.com Subject: Re: more on reclaiming 225/8 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-malloc@catarina.usc.edu Precedence: bulk Hi Hugh, May be this needs to specifically include product developers and vendors : 15. Use of IANA Reserved Addresses Applications MUST NOT use addressing in the IANA reserved blocks. All addresses that are not currently used or assigned by IANA are considered reserved. I think we also need for networks to update their scope/filter policies to stop forwarding reserved groups. Thanks Zaid On Thu, 5 Jul 2001, Hugh LaMaster wrote: > > On Thu, 5 Jul 2001, David Meyer wrote: > > > Regarding what I saw at OSU (225.1.2.3): > > > > corvallis-hub>sh ip mroute | inc 225.1.2.3 > > (*, 225.1.2.3), 4w1d/00:02:59, RP 207.98.64.240, flags: SP > > [...] > > (128.193.22.165, 225.1.2.3), 07:41:37/00:03:11, flags: T > > (128.193.25.37, 225.1.2.3), 05:45:54/00:03:11, flags: T > > (128.193.190.19, 225.1.2.3), 1w0d/00:03:11, flags: T > > (128.193.190.93, 225.1.2.3), 5d06h/00:03:11, flags: T > > [...] > > > > There are a ton of these (> 110) in use. Why? It would appear > > that there is a software/OS replication package named Altiris > > distributed by/with Compaq. The default OS installation on the > > Compaqs includes Altiris (whatever it is) and it is configured to > > use 225.1.2.3 as its default group. However, I can't tell this is > > a Compaq setting or an Altiris default. > > > > This is yet another reason why we need a document like > > draft-ietf-mboned-iana-ipv4-mcast-guidelines-03.txt. > > We seem to need some kind of educational effort to get > the word out to these companies regarding sensible use. > Certainly, some uses are obviously not sensible, but, > I don't see anything in > > http://www.ietf.org/internet-drafts/draft-ietf-mboned-iana-ipv4-mcast-guidelines-03.txt > > that specifically prescribes the correct thing to do > to a consumer product developer. > > I think static assignments in, e.g., 224.[0,1].x.y are almost always > a bad idea, but, I'm not sure how a product, intended for use by > folks who know little or nothing about multicast, should > [automatically] go about assigning such an address dynamically. > Something in 239.255/16 is definitely local, but, how should the > address/port be assigned? Should sdr-like code be required in such > products? I don't know what the companies have in mind if multiple > users on a LAN happen to be using the same product. Have any > people on these mailing lists had any discussions with the folks > at these companies regarding what they are going with such products? > > > > -- > Hugh LaMaster, M/S 233-21, Email: lamaster@nas.nasa.gov > NASA Ames Research Center Or: lamaster@nren.nasa.gov > Moffett Field, CA 94035-1000 Or: lamaster@kinkajou.arc.nasa.gov > Phone: 650/604-1056 Disc: Unofficial, personal *opinion*. > > > From owner-malloc@catarina.usc.edu Fri Jul 6 14:24:44 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15153 for ; Fri, 6 Jul 2001 14:24:43 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id LAA01328 for malloc-list; Fri, 6 Jul 2001 11:09:02 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id LAA01323 for ; Fri, 6 Jul 2001 11:09:01 -0700 (PDT) Received: (from pavlin@localhost) by rumi.usc.edu (8.9.3/8.9.3) id LAA96092 for malloc@catarina.usc.edu; Fri, 6 Jul 2001 11:09:01 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id LAA01238 for ; Fri, 6 Jul 2001 11:02:27 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by usc.edu (8.9.3.1/8.9.3/usc) with SMTP id LAA11679 for ; Fri, 6 Jul 2001 11:02:27 -0700 (PDT) Received: from 157.54.9.101 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 06 Jul 2001 10:51:33 -0700 (Pacific Daylight Time) Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 6 Jul 2001 10:50:41 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 6 Jul 2001 10:50:40 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 6 Jul 2001 10:49:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5683.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: more on reclaiming 225/8 Date: Fri, 6 Jul 2001 10:48:33 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1B5808B@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: more on reclaiming 225/8 Thread-Index: AcEFnIstzn92IgVtQau2/KDYwh+n3gApaqFA From: "Dave Thaler" To: "Beau Williamson" , "Hugh LaMaster" , Cc: "John Meylor" , "David Meyer" , "Hugh LaMaster" , "Mark Handley" , "Dave Thaler" , "Deborah Estrin" , , "Bill Fenner" , "Randy Bush" , "Zaid Albanna" , "Kevin Almeroth" , X-OriginalArrivalTime: 06 Jul 2001 17:49:50.0056 (UTC) FILETIME=[0DB47E80:01C10644] X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id LAA01239 Sender: owner-malloc@catarina.usc.edu Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by catarina.usc.edu id LAA01328 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA15153 [moving mboned and iana to bcc list, follow up should be on the malloc list] Beau is correct. If the app wants a dynamic address, it should be using an api/library provided by the platform for allocating dynamic addresses. The api (RFC 2771 provides the abstract version) should really be the same regardless of whether the app is asking for an SSM or ASM address, regardless of scope, etc (these can be parameters to the allocation request). This insulates the app from the allocation protocol/mechanism. If the semantics are appropriate (app wants ASM at Local Scope or larger), then the library should use MADCAP to acquire the address. And of course, SSM addresses should be allocated by the library/daemon such that they're guaranteed to be unique across multiple apps on the machine. ASM groups of scope smaller than Local Scope (and a dynamic range for this type of groups is only presently reserved in IPv6) should be allocated by the library/daemon via ZMAAP. We really don't want apps implementing MADCAP (or SAP, or ZMAAP, or SSM address allocation, or whatever else) themselves. It's too easy for naïve app writers to mess up and/or collide with other apps on the same box. If your platform of choice does not currently have such an api/library/daemon/whatever, go write one or beat on your platform vendor. Dave Thaler > -----Original Message----- > From: Beau Williamson [mailto:bwilliam@cisco.com] > Sent: Thursday, July 05, 2001 2:13 PM > To: Hugh LaMaster; malloc@catarina.usc.edu > Cc: John Meylor; David Meyer; Hugh LaMaster; Mboned List; Mark Handley; > thaler@Exchange.Microsoft.com; Deborah Estrin; van@packetdesign.com; Bill > Fenner; iana@icann.org; Randy Bush; Zaid Albanna; Kevin Almeroth; > narten@raleigh.ibm.com > Subject: Re: more on reclaiming 225/8 > > Hugh, > > Wouldn't this be better handled by having all applications use MADCAP to > obtain the group address? After all, this is what that protocol was > designed to do. (If I remember correctly.) > > Of course there is a problem if the application is a legacy application > that doesn't support MADCAP and doesn't bother to request an group > address. How would you enforce certain policies concerning group address > usage? > > I have several customers that are wrestling with these sorts of issues > (admission control, rate-limiting, address-allocation, etc.) and it > doesn't appear that there are any standard ways to deal with these > problems. > > Beau > At 03:22 PM 7/5/2001, Hugh LaMaster wrote: > > >On Thu, 5 Jul 2001, David Meyer wrote: > > > >> >> > that specifically prescribes the correct thing to do > >> >> > to a consumer product developer. > >> >> > >> >> perhaps this could be incorporated into something like Bob, Kevins: > >> >> in section on address > management. > >> > >> Good idea (as I said, it belongs somewhere, just not in the IANA > >> guidelines). > > > >Sounds good to me also. In fact, I see that the section on > >address management actually does have this started: > > > > > > In almost all cases, application designers should assume that > > multicast addresses are to be dynamic. Very little of the multicast > > address space is available for static assignment by IANA [MADDR]. > > Also, given the host-specific addressing available with SSM, Internet- > > wide, static address assignment is expected to be very rare. > > > > > >I think with a little more directness, e.g., drop a few qualifiers: > > > > Application designers should assume that multicast addresses are > > to be dynamic. > > > >But, from this point on, I'm not sure what should be written. > >Most of this document is written from the perspective of > >streaming media servers/clients or the similar videoconferencing, > >but, the applications that are causing the most trouble with MSDP > >&etc. are things that don't fit that model - e.g. DriveImage. > > > >How *should* a non-interactive non-A/V mostly-local application > >get its address (presumably in 239.255.x.y) and (port)? > >Although sdr does work on the 239.x.y.z spaces by using > >the appropriate multicast address, e.g., for 239.255.x.y, > >239.255.255.255 for the SAP announcements, it isn't obvious > >to me that a batch/CLI type application that might be run > >automatically at a particular time fits the sdr/SAP model. > > > >I'm speculating that a query mechanism could be used, e.g., IGMPv3 > >general query, that would instantaneously return groups > >to be avoided, and that the application could then randomly > >select address and port, and then advertise via SAP > >the selected group in 239.255/16. Is that a bad idea (probably)? > > > > > >-- > > Hugh LaMaster, M/S 233-21, Email: lamaster@nas.nasa.gov > > NASA Ames Research Center Or: lamaster@nren.nasa.gov > > Moffett Field, CA 94035-1000 Or: lamaster@kinkajou.arc.nasa.gov > > Phone: 650/604-1056 Disc: Unofficial, personal *opinion*. From owner-malloc@catarina.usc.edu Fri Jul 6 16:52:10 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19545 for ; Fri, 6 Jul 2001 16:52:08 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id NAA03490 for malloc-list; Fri, 6 Jul 2001 13:36:21 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id NAA03485 for ; Fri, 6 Jul 2001 13:36:21 -0700 (PDT) Received: (from pavlin@localhost) by rumi.usc.edu (8.9.3/8.9.3) id NAA21106 for malloc@catarina.usc.edu; Fri, 6 Jul 2001 13:36:21 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id NAA03419 for ; Fri, 6 Jul 2001 13:33:14 -0700 (PDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by usc.edu (8.9.3.1/8.9.3/usc) with SMTP id NAA02357 for ; Fri, 6 Jul 2001 13:33:14 -0700 (PDT) Received: from 157.54.7.67 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 06 Jul 2001 11:40:20 -0700 (Pacific Daylight Time) Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 6 Jul 2001 11:42:54 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 6 Jul 2001 11:42:50 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 6 Jul 2001 11:42:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5683.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: more on reclaiming 225/8 Date: Fri, 6 Jul 2001 11:42:00 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1B5808E@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: more on reclaiming 225/8 Thread-Index: AcEFdyvQ/YMWcixkS0q9LhdJqTxLLgA02XPA From: "Dave Thaler" To: "David Meyer" , , Cc: X-OriginalArrivalTime: 06 Jul 2001 18:42:00.0239 (UTC) FILETIME=[577083F0:01C1064B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id NAA03420 Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit [mboned list bcc'd, follow up should be on malloc list] Dave Meyer write: > >> 225/8 was allocated for experimentation with the MASC protocol. > >> In particular, it was to be used to statically assign the top > >> level of the MASC infrastructure (statically) so we didn't have > >> to deploy a BRIB capable routing system before experimenting > >> with the MALLOC architecture. The assignment is (from > >> http://www.iana.org/assignments/multicast-addresses): > >> > >> 225.0.0.0-225.255.255.255 MALLOC (temp - renew 1/01) [Handley] > >> > >> Since we are not using 225/8 for this purpose (or at all, for > >> that matter), I want to reclaim it. Mark Handley suggested that > >> I mention this to the list. If you have comments, please > >> respond directly to me (copying the list). I propose that we use 225/8 for unicast-prefix-based IPv4 multicast addresses (since it would be basically a drop-in replacement for MASC). I mentioned this idea (but not the specific range) at the last MADDOGS meeting where I gave the differences between IPv4 and IPv6 (I think you have the slides on your site Dave). Since I got favorable feedback about this idea, Andy Adams and Bill Siadak volunteered to go write it up in a draft. I had suggested to Andy and Bill that they use 225/8 in the draft when they write it up. -Dave From owner-malloc@catarina.usc.edu Fri Jul 6 16:55:05 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19673 for ; Fri, 6 Jul 2001 16:55:02 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id NAA03452 for malloc-list; Fri, 6 Jul 2001 13:34:52 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id NAA03447 for ; Fri, 6 Jul 2001 13:34:51 -0700 (PDT) Received: (from pavlin@localhost) by rumi.usc.edu (8.9.3/8.9.3) id NAA21069 for malloc@catarina.usc.edu; Fri, 6 Jul 2001 13:34:51 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id MAA02718 for ; Fri, 6 Jul 2001 12:43:41 -0700 (PDT) Received: from sith.maoz.com (sith.maoz.com [205.167.76.10]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id MAA25708 for ; Fri, 6 Jul 2001 12:43:41 -0700 (PDT) Received: (from dmm@localhost) by sith.maoz.com (8.11.3/8.11.2) id f66JhUT21373; Fri, 6 Jul 2001 12:43:30 -0700 Date: Fri, 6 Jul 2001 12:43:30 -0700 From: David Meyer To: Dave Thaler Cc: ala@nexthop.com, wfs@nexthop.com, malloc@catarina.usc.edu, iana@icann.org, randy@psg.com Subject: Re: more on reclaiming 225/8 Message-ID: <20010706124330.A21340@sprint.net> References: <2E33960095B58E40A4D3345AB9F65EC1B5808E@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC1B5808E@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>; from dthaler@windows.microsoft.com on Fri, Jul 06, 2001 at 11:42:00AM -0700 Sender: owner-malloc@catarina.usc.edu Precedence: bulk On Fri, Jul 06, 2001 at 11:42:00AM -0700, Dave Thaler wrote: >> [mboned list bcc'd, follow up should be on malloc list] >> >> Dave Meyer write: >> > >> 225/8 was allocated for experimentation with the MASC protocol. >> > >> In particular, it was to be used to statically assign the top >> > >> level of the MASC infrastructure (statically) so we didn't have >> > >> to deploy a BRIB capable routing system before experimenting >> > >> with the MALLOC architecture. The assignment is (from >> > >> http://www.iana.org/assignments/multicast-addresses): >> > >> >> > >> 225.0.0.0-225.255.255.255 MALLOC (temp - renew 1/01) [Handley] >> > >> >> > >> Since we are not using 225/8 for this purpose (or at all, for >> > >> that matter), I want to reclaim it. Mark Handley suggested that >> > >> I mention this to the list. If you have comments, please >> > >> respond directly to me (copying the list). >> >> I propose that we use 225/8 for unicast-prefix-based IPv4 multicast addresses (since it would be basically a drop-in replacement for MASC). I mentioned this idea (but not the specific range) at the last MADDOGS meeting where I gave the differences between IPv4 and IPv6 (I think you have the slides on your site Dave). Since I got favorable feedback about this idea, Andy Adams and Bill Siadak volunteered to go write it up in a draft. I had suggested to Andy and Bill that they use 225/8 in the draft when they write it up. >> >> -Dave I don't disagree with the approach (unicast-prefix-based ...). However, the IANA assigned this prefix temporarily for a different purpose, and since we don't in any way own this (or really any) prefix, this is what should be done: (i). Return 225/8 to the IANA immediately (ii). Request a prefix assignment from the IANA when your document is done. I will notify the IANA (copied). Dave From owner-malloc@catarina.usc.edu Fri Jul 6 18:14:10 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21641 for ; Fri, 6 Jul 2001 18:14:04 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id OAA04197 for malloc-list; Fri, 6 Jul 2001 14:59:27 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id OAA04192 for ; Fri, 6 Jul 2001 14:59:26 -0700 (PDT) Received: from aardvark.aciri.org (aardvark.aciri.org [192.150.187.20]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id OAA28936 for ; Fri, 6 Jul 2001 14:59:26 -0700 (PDT) Received: from aardvark.aciri.org (localhost [127.0.0.1]) by aardvark.aciri.org (8.11.3/8.11.1) with ESMTP id f66LvSo80320; Fri, 6 Jul 2001 14:57:28 -0700 (PDT) (envelope-from mjh@aardvark.aciri.org) From: Mark Handley X-Organisation: ACIRI To: David Meyer cc: Dave Thaler , ala@nexthop.com, wfs@nexthop.com, malloc@catarina.usc.edu, iana@icann.org, randy@psg.com Subject: Re: more on reclaiming 225/8 In-reply-to: Your message of "Fri, 06 Jul 2001 12:43:30 PDT." <20010706124330.A21340@sprint.net> Date: Fri, 06 Jul 2001 14:57:28 -0700 Message-ID: <80318.994456648@aardvark.aciri.org> Sender: owner-malloc@catarina.usc.edu Precedence: bulk >I propose that we use 225/8 for unicast-prefix-based IPv4 multicast address >es (since it would be basically a drop-in replacement for MASC). I mentioned >this idea (but not the specific range) at the last MADDOGS meeting where I gav >e the differences between IPv4 and IPv6 (I think you have the slides on your s >ite Dave). Since I got favorable feedback about this idea, Andy Adams and Bil >l Siadak volunteered to go write it up in a draft. I had suggested to Andy an >d Bill that they use 225/8 in the draft when they write it up. >>> >>> -Dave > >I don't disagree with the approach (unicast-prefix-based >...). However, the IANA assigned this prefix temporarily for a >different purpose, and since we don't in any way own this (or >really any) prefix, this is what should be done: > >(i). Return 225/8 to the IANA immediately > >(ii). Request a prefix assignment from the IANA when your > document is done. > >I will notify the IANA (copied). The point of the allocation was to experiment with whatever address allocation mechanism the IETF MALLOC group decides on. We definitely seem to be lacking consensus on deploying MASC, so the question is can the MALLOC working group achieve consensus as to an alternative? If we have consensus on a replacement for MASC, then it makes sense to me to use 225/8 to experiment with that replacement. If we don't agree on a replacement, then we should return 225/8 until such time as there's some general agreement. Can we decide this on the list, or do we need to discuss it in London? Cheers, Mark From owner-malloc@catarina.usc.edu Fri Jul 6 18:33:17 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22293 for ; Fri, 6 Jul 2001 18:33:15 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id PAA04389 for malloc-list; Fri, 6 Jul 2001 15:16:49 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id PAA04384 for ; Fri, 6 Jul 2001 15:16:48 -0700 (PDT) Received: (from pavlin@localhost) by rumi.usc.edu (8.9.3/8.9.3) id PAA23654 for malloc@catarina.usc.edu; Fri, 6 Jul 2001 15:16:48 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id PAA04374 for ; Fri, 6 Jul 2001 15:16:16 -0700 (PDT) Received: from sith.maoz.com (sith.maoz.com [205.167.76.10]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id PAA09588 for ; Fri, 6 Jul 2001 15:16:16 -0700 (PDT) Received: (from dmm@localhost) by sith.maoz.com (8.11.3/8.11.2) id f66MG1D22300; Fri, 6 Jul 2001 15:16:01 -0700 Date: Fri, 6 Jul 2001 15:16:00 -0700 From: David Meyer To: Mark Handley Cc: Dave Thaler , ala@nexthop.com, wfs@nexthop.com, malloc@catarina.usc.edu, iana@icann.org, randy@psg.com, dmm@sprint.net Subject: Re: more on reclaiming 225/8 Message-ID: <20010706151600.A22258@sprint.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-malloc@catarina.usc.edu Precedence: bulk Mark, >> The point of the allocation was to experiment with whatever address >> allocation mechanism the IETF MALLOC group decides on. We definitely >> seem to be lacking consensus on deploying MASC, so the question is can >> the MALLOC working group achieve consensus as to an alternative? As I remember it (and I was asked to intervene with the IANA, which I gladly did), the assignment was to experiment with MASC. More precisely, since we couldn't expect the top level of the MASC hierarchy to be deployed (or the BRIB for that matter), we were going to make static assignments and have something like a host file that we shipped around. >> If we have consensus on a replacement for MASC, then it makes sense to >> me to use 225/8 to experiment with that replacement. If we don't >> agree on a replacement, then we should return 225/8 until such time as >> there's some general agreement. The issue is whether 225/8 is ours to do with what we want. My assertion is that is not. The assignment was temporary, and for the purpose I described above. If we want more addressing, we can ask IANA for that, but just to use it for whatever we want implies some sense of ownership, and that is what I'm objecting to (another case: I didn't agree with the way 232/8 was handled, for similar reasons). Add to that the a /8 is a huge chunk of address space. >> Can we decide this on the list, or do we need to discuss it in London? The list certainly has a larger constituency than what we will find in London. However, what do we need to decide? You need addressing for this new experiment. That's fine, write a document, then ask the IANA. Again, I am not objecting to the experiment, or to the fact that you need addressing to do it. What I am not comfortable with is treating 225/8 like we own it and it is ours to do with what we please. That is not the case. Dave ---- Humorous aside: looks like its expired anyway: http://www.iana.org/assignments/multicast-addresses --> 225.0.0.0-225.255.255.255 MALLOC (temp - renew 1/01) [Handley] From owner-malloc@catarina.usc.edu Fri Jul 6 18:55:19 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22772 for ; Fri, 6 Jul 2001 18:55:16 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id PAA04480 for malloc-list; Fri, 6 Jul 2001 15:40:15 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id PAA04475 for ; Fri, 6 Jul 2001 15:40:14 -0700 (PDT) Received: (from pavlin@localhost) by rumi.usc.edu (8.9.3/8.9.3) id PAA24155 for malloc@catarina.usc.edu; Fri, 6 Jul 2001 15:40:14 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id PAA04418 for ; Fri, 6 Jul 2001 15:26:04 -0700 (PDT) Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id PAA16206 for ; Fri, 6 Jul 2001 15:26:04 -0700 (PDT) Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15Ie2i-0002MQ-00; Fri, 06 Jul 2001 15:25:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Mark Handley Cc: David Meyer , Dave Thaler , ala@nexthop.com, wfs@nexthop.com, malloc@catarina.usc.edu, iana@icann.org Subject: Re: more on reclaiming 225/8 References: <20010706124330.A21340@sprint.net> <80318.994456648@aardvark.aciri.org> Message-Id: Date: Fri, 06 Jul 2001 15:25:44 -0700 Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit > If we have consensus on a replacement for MASC, then it makes sense to > me to use 225/8 to experiment with that replacement. why not go the straight path. the allocation was for masc. if masc is not flying, return it. when someone needs space for another experiment, then do the normal thing, and file a request for it. hoarding it seems quite rude. randy From owner-malloc@catarina.usc.edu Fri Jul 6 18:56:55 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22785 for ; Fri, 6 Jul 2001 18:56:54 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id PAA04493 for malloc-list; Fri, 6 Jul 2001 15:40:29 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id PAA04488 for ; Fri, 6 Jul 2001 15:40:28 -0700 (PDT) Received: from aardvark.aciri.org (aardvark.aciri.org [192.150.187.20]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id PAA25594 for ; Fri, 6 Jul 2001 15:40:29 -0700 (PDT) Received: from aardvark.aciri.org (localhost [127.0.0.1]) by aardvark.aciri.org (8.11.3/8.11.1) with ESMTP id f66Mapo81183; Fri, 6 Jul 2001 15:36:51 -0700 (PDT) (envelope-from mjh@aardvark.aciri.org) From: Mark Handley X-Organisation: ACIRI To: David Meyer cc: Dave Thaler , ala@nexthop.com, wfs@nexthop.com, malloc@catarina.usc.edu, iana@icann.org, randy@psg.com Subject: Re: more on reclaiming 225/8 In-reply-to: Your message of "Fri, 06 Jul 2001 15:16:00 PDT." <20010706151600.A22258@sprint.net> Date: Fri, 06 Jul 2001 15:36:51 -0700 Message-ID: <81181.994459011@aardvark.aciri.org> Sender: owner-malloc@catarina.usc.edu Precedence: bulk >As I remember it (and I was asked to intervene with the IANA, >which I gladly did), the assignment was to experiment with >MASC. More precisely, since we couldn't expect the top level of >the MASC hierarchy to be deployed (or the BRIB for that matter), >we were going to make static assignments and have something like >a host file that we shipped around. > >>> If we have consensus on a replacement for MASC, then it makes sense to >>> me to use 225/8 to experiment with that replacement. If we don't >>> agree on a replacement, then we should return 225/8 until such time as >>> there's some general agreement. > >The issue is whether 225/8 is ours to do with what we want. My >assertion is that is not. The assignment was temporary, and for >the purpose I described above. I've included the text of my original request message from Dec 1998 below - the request was actually not MASC-specific, but to experiment with whatever the MALLOC group decided was the right approach. >Humorous aside: looks like its expired anyway: > >http://www.iana.org/assignments/multicast-addresses --> > >225.0.0.0-225.255.255.255 MALLOC (temp - renew 1/01) [Handley] Agreed - that's why we need to provide guidance to IANA as to what to do with the space. I'm not arguing we should blindly request for renewal - I'm just arguing against a rush to a decision after all this time. Cheers, Mark ----- Forwarded Message ----- From: Mark Handley To: iana@iana.org cc: Subject: Multicast Address Apace for Dynamic Allocation -------- Jon, As I'm sure you're aware, the MALLOC WG has been developing protocols to allow scalable dynamic allocation of the IPv4 multicast address space. We're now starting to approach the point where we will start experiments with this address allocation architecture, and to this end, we're going to need an address space to allocate. The MALLOC architecture is hierarchical, and designed with the eventual goal of allocating the entire multicast address space (with the exception of a relatively small set of well-known and admin-scope-relative groups). Clearly though, the jury is still out on whether this goal will be realised. Thus we should probably start with a moderate sized space to be dynamically allocated, and expand this space later when we can show that the allocation architecture is working effectively. Currently 224.2.0.0 to 224.2.255.255 is allocated to multimedia conferencing, and the upper half of this range is allocated dynamically using SAP. The MALLOC allocation architecture is not restricted to multimedia conferencing - it is intended for general purpose multicast address allocation. SAP will eventually be replaced by the MALLOC architecture for address allocation, but for a while both mechanisms will have to be able to co-exist. Using a different space makes this somewhat simpler. Thus we'd like to request a new and larger space for dynamic allocation using the MALLOC architecture, preferably 225.0.0.0 to 225.255.255.255. This would be large enough to perform realistic experiments and to accomodate current and near-future multicast usage. The idea would be that in the long term the range can be expanded to include the rest of the address space up to the base of the administratively scoped range. To this end, we'd also like to suggest that the ranges 226.0.0.0 to 231.255.255.255 and 233.0.0.0 to 238.255.255.255 be marked as "reserved" to discourage people believing that they can request a large statically allocated range of addresses. We would also envisage that the current VMTP range (232.0.0.0 to 232.255.255.255) will probably be returned to "reserved" status in due course, and would eventually be dynamically allocated too. Please let us know if you need clarification on any of these details. Thank you, Mark Handley (MMUSIC WG chair) Deborah Estrin Dave Thaler (MALLOC WG chair) Steve Hanna (MALLOC WG chair) Bill Fenner (IDMR WG chair) Dave Meyer (MboneD WG chair) Steve Casner (AVT WG chair) ----- End of Forwarded Message ----- From owner-malloc@catarina.usc.edu Fri Jul 6 19:08:42 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA23079 for ; Fri, 6 Jul 2001 19:08:41 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id PAA04562 for malloc-list; Fri, 6 Jul 2001 15:55:14 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id PAA04557 for ; Fri, 6 Jul 2001 15:55:13 -0700 (PDT) Received: (from pavlin@localhost) by rumi.usc.edu (8.9.3/8.9.3) id PAA24506 for malloc@catarina.usc.edu; Fri, 6 Jul 2001 15:55:13 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id PAA04530 for ; Fri, 6 Jul 2001 15:50:34 -0700 (PDT) Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id PAA02524 for ; Fri, 6 Jul 2001 15:50:35 -0700 (PDT) Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15IeQa-0003Z7-00; Fri, 06 Jul 2001 15:50:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Mark Handley Cc: David Meyer , Dave Thaler , ala@nexthop.com, wfs@nexthop.com, malloc@catarina.usc.edu, iana@icann.org Subject: Re: more on reclaiming 225/8 References: <20010706151600.A22258@sprint.net> <81181.994459011@aardvark.aciri.org> Message-Id: Date: Fri, 06 Jul 2001 15:50:24 -0700 Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit seems to me that it would be more productive to work on dynamic address protocols, than how to rationalize keeping space from the last experiment. if y'all had a good experiment, then getting address space for it would be easy. randy From owner-malloc@catarina.usc.edu Fri Jul 6 19:10:49 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA23115 for ; Fri, 6 Jul 2001 19:10:46 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id PAA04576 for malloc-list; Fri, 6 Jul 2001 15:55:29 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id PAA04571 for ; Fri, 6 Jul 2001 15:55:28 -0700 (PDT) Received: (from pavlin@localhost) by rumi.usc.edu (8.9.3/8.9.3) id PAA24521 for malloc@catarina.usc.edu; Fri, 6 Jul 2001 15:55:28 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id PAA04544 for ; Fri, 6 Jul 2001 15:54:56 -0700 (PDT) Received: from sith.maoz.com (sith.maoz.com [205.167.76.10]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id PAA06003 for ; Fri, 6 Jul 2001 15:54:56 -0700 (PDT) Received: (from dmm@localhost) by sith.maoz.com (8.11.3/8.11.2) id f66Mspl22558; Fri, 6 Jul 2001 15:54:51 -0700 Date: Fri, 6 Jul 2001 15:54:51 -0700 From: David Meyer To: Mark Handley Cc: Dave Thaler , ala@nexthop.com, wfs@nexthop.com, malloc@catarina.usc.edu, iana@icann.org, randy@psg.com Subject: Re: more on reclaiming 225/8 Message-ID: <20010706155451.A22542@sprint.net> References: <20010706151600.A22258@sprint.net> <81181.994459011@aardvark.aciri.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <81181.994459011@aardvark.aciri.org>; from mjh@aciri.org on Fri, Jul 06, 2001 at 03:36:51PM -0700 Sender: owner-malloc@catarina.usc.edu Precedence: bulk Ok, here's how you could help me in the short term. The assignment is marked temporary. If you could outline for me the criteria the IANA can use to decide whether to renew it annually that would be very helpful (after all, if its temporary then the IANA will need to know how to evaluate how and when the assignment expires, otherwise it is permanent). Thanks, Dave On Fri, Jul 06, 2001 at 03:36:51PM -0700, Mark Handley wrote: >> >> >As I remember it (and I was asked to intervene with the IANA, >> >which I gladly did), the assignment was to experiment with >> >MASC. More precisely, since we couldn't expect the top level of >> >the MASC hierarchy to be deployed (or the BRIB for that matter), >> >we were going to make static assignments and have something like >> >a host file that we shipped around. >> > >> >>> If we have consensus on a replacement for MASC, then it makes sense to >> >>> me to use 225/8 to experiment with that replacement. If we don't >> >>> agree on a replacement, then we should return 225/8 until such time as >> >>> there's some general agreement. >> > >> >The issue is whether 225/8 is ours to do with what we want. My >> >assertion is that is not. The assignment was temporary, and for >> >the purpose I described above. >> >> I've included the text of my original request message from Dec 1998 >> below - the request was actually not MASC-specific, but to experiment >> with whatever the MALLOC group decided was the right approach. >> >> >Humorous aside: looks like its expired anyway: >> > >> >http://www.iana.org/assignments/multicast-addresses --> >> > >> >225.0.0.0-225.255.255.255 MALLOC (temp - renew 1/01) [Handley] >> >> Agreed - that's why we need to provide guidance to IANA as to what to >> do with the space. I'm not arguing we should blindly request for >> renewal - I'm just arguing against a rush to a decision after all this >> time. >> >> Cheers, >> Mark >> >> >> ----- Forwarded Message ----- >> >> From: Mark Handley >> To: iana@iana.org >> cc: >> Subject: Multicast Address Apace for Dynamic Allocation >> -------- >> >> >> Jon, >> >> As I'm sure you're aware, the MALLOC WG has been developing protocols >> to allow scalable dynamic allocation of the IPv4 multicast address >> space. We're now starting to approach the point where we will start >> experiments with this address allocation architecture, and to this >> end, we're going to need an address space to allocate. >> >> The MALLOC architecture is hierarchical, and designed with the >> eventual goal of allocating the entire multicast address space (with >> the exception of a relatively small set of well-known and >> admin-scope-relative groups). Clearly though, the jury is still out >> on whether this goal will be realised. Thus we should probably start >> with a moderate sized space to be dynamically allocated, and expand >> this space later when we can show that the allocation architecture is >> working effectively. >> >> Currently 224.2.0.0 to 224.2.255.255 is allocated to multimedia >> conferencing, and the upper half of this range is allocated >> dynamically using SAP. The MALLOC allocation architecture is not >> restricted to multimedia conferencing - it is intended for general >> purpose multicast address allocation. SAP will eventually be replaced >> by the MALLOC architecture for address allocation, but for a while >> both mechanisms will have to be able to co-exist. Using a different >> space makes this somewhat simpler. >> >> Thus we'd like to request a new and larger space for dynamic >> allocation using the MALLOC architecture, preferably 225.0.0.0 to >> 225.255.255.255. This would be large enough to perform realistic >> experiments and to accomodate current and near-future multicast usage. >> >> The idea would be that in the long term the range can be expanded to >> include the rest of the address space up to the base of the >> administratively scoped range. To this end, we'd also like to suggest >> that the ranges 226.0.0.0 to 231.255.255.255 and 233.0.0.0 to >> 238.255.255.255 be marked as "reserved" to discourage people believing >> that they can request a large statically allocated range of addresses. >> We would also envisage that the current VMTP range (232.0.0.0 to >> 232.255.255.255) will probably be returned to "reserved" status in due >> course, and would eventually be dynamically allocated too. >> >> Please let us know if you need clarification on any of these details. >> >> Thank you, >> Mark Handley (MMUSIC WG chair) >> Deborah Estrin >> Dave Thaler (MALLOC WG chair) >> Steve Hanna (MALLOC WG chair) >> Bill Fenner (IDMR WG chair) >> Dave Meyer (MboneD WG chair) >> Steve Casner (AVT WG chair) >> >> ----- End of Forwarded Message ----- From owner-malloc@catarina.usc.edu Mon Jul 9 15:01:10 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25945 for ; Mon, 9 Jul 2001 15:01:09 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id LAA19462 for malloc-list; Mon, 9 Jul 2001 11:38:59 -0700 (PDT) Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id LAA19457 for ; Mon, 9 Jul 2001 11:38:59 -0700 (PDT) Received: (from pavlin@localhost) by rumi.usc.edu (8.9.3/8.9.3) id LAA84811 for malloc@catarina.usc.edu; Mon, 9 Jul 2001 11:38:59 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id LAA19436 for ; Mon, 9 Jul 2001 11:38:23 -0700 (PDT) Received: from kinkajou.arc.nasa.gov (kinkajou.arc.nasa.gov [128.102.196.170]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA28704 for ; Mon, 9 Jul 2001 11:38:23 -0700 (PDT) Received: from localhost (lamaster@localhost) by kinkajou.arc.nasa.gov (8.9.3+Sun/8.9.1) with ESMTP id LAA23194; Mon, 9 Jul 2001 11:34:26 -0700 (PDT) X-Authentication-Warning: kinkajou.arc.nasa.gov: lamaster owned process doing -bs Date: Mon, 9 Jul 2001 11:34:26 -0700 (PDT) From: Hugh LaMaster X-Sender: lamaster@kinkajou.arc.nasa.gov To: malloc@catarina.usc.edu cc: Hugh LaMaster Subject: Re: more on reclaiming 225/8 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-malloc@catarina.usc.edu Precedence: bulk On Fri, 6 Jul 2001, Randy Bush wrote: > seems to me that it would be more productive to work on dynamic address > protocols, than how to rationalize keeping space from the last experiment. > if y'all had a good experiment, then getting address space for it would be > easy. I agree. I think that the canonical approach is indicated here -- close out the previous experiment, request a new allocation for the current work. I doubt that the request would be denied, but, IANA might choose to allocate a different block just to keep things neat and tidy - 231/8, say. -- Hugh LaMaster, M/S 233-21, Email: lamaster@nas.nasa.gov NASA Ames Research Center Or: lamaster@nren.nasa.gov Moffett Field, CA 94035-1000 Or: lamaster@kinkajou.arc.nasa.gov Phone: 650/604-1056 Disc: Unofficial, personal *opinion*. From owner-malloc@catarina.usc.edu Mon Jul 9 15:02:30 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25982 for ; Mon, 9 Jul 2001 15:02:30 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id LAA19417 for malloc-list; Mon, 9 Jul 2001 11:37:52 -0700 (PDT) Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id LAA19412 for ; Mon, 9 Jul 2001 11:37:51 -0700 (PDT) Received: (from pavlin@localhost) by rumi.usc.edu (8.9.3/8.9.3) id LAA84770 for malloc@catarina.usc.edu; Mon, 9 Jul 2001 11:37:51 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id LAA19389 for ; Mon, 9 Jul 2001 11:36:26 -0700 (PDT) Received: from kinkajou.arc.nasa.gov (kinkajou.arc.nasa.gov [128.102.196.170]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA26939 for ; Mon, 9 Jul 2001 11:36:26 -0700 (PDT) Received: from localhost (lamaster@localhost) by kinkajou.arc.nasa.gov (8.9.3+Sun/8.9.1) with ESMTP id LAA23162; Mon, 9 Jul 2001 11:32:28 -0700 (PDT) X-Authentication-Warning: kinkajou.arc.nasa.gov: lamaster owned process doing -bs Date: Mon, 9 Jul 2001 11:32:27 -0700 (PDT) From: Hugh LaMaster X-Sender: lamaster@kinkajou.arc.nasa.gov To: malloc@catarina.usc.edu cc: Dave Thaler , Beau Williamson , Hugh LaMaster , John Meylor , David Meyer , Mark Handley , Deborah Estrin , van@packetdesign.com, Bill Fenner , Randy Bush , Zaid Albanna , Kevin Almeroth , narten@raleigh.ibm.com Subject: RE: more on reclaiming 225/8 In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC1B5808B@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by catarina.usc.edu id LAA19390 Sender: owner-malloc@catarina.usc.edu Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by catarina.usc.edu id LAA19417 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA25982 On Fri, 6 Jul 2001, Dave Thaler wrote: > [moving mboned and iana to bcc list, follow up should be on the malloc list] > > Beau is correct. If the app wants a dynamic address, it should be using an > api/library provided by the platform for allocating dynamic > addresses. > > The api (RFC 2771 provides the abstract version) should really be the same regardless of whether the app is asking for an SSM or ASM address, regardless of scope, etc (these can be parameters to the allocation request). This insulates the app from the allocation protocol/mechanism. > > If the semantics are appropriate (app wants ASM at Local Scope or > larger), then the library should use MADCAP to acquire the address. > And of course, SSM addresses should be allocated by the library/daemon such that they're guaranteed to be unique across multiple apps on the machine. ASM groups of scope smaller than Local Scope (and a dynamic range for this type of groups is only presently reserved in IPv6) should be allocated by the library/daemon via ZMAAP. > > We really don't want apps implementing MADCAP (or SAP, or ZMAAP, or SSM address allocation, or whatever else) themselves. It's too easy for naïve app writers to mess up and/or collide with other apps on the same box. > > If your platform of choice does not currently have such an api/library/daemon/whatever, go write one or beat on your platform vendor. I did look around a little bit over the weekend. I found a little bit of alpha-release stuff. Maybe I missed the more fully developed stuff. Is there a website or repository with code or pointers to code for the RFC 2771 API conformant libraries and server daemons? Have any of the common (ie Mbone) tools (e.g. vic, vat, rat) been ported to use these libraries/facilities? How about COTS software? Sorry if these are uninformed questions; I'm very out of date on what has been happening and would like to get up to speed. > > From: Beau Williamson [mailto:bwilliam@cisco.com] > > Sent: Thursday, July 05, 2001 2:13 PM : > > Subject: Re: more on reclaiming 225/8 : > > Wouldn't this be better handled by having all applications use MADCAP to > > obtain the group address? After all, this is what that protocol was > > designed to do. (If I remember correctly.) : > > Of course there is a problem if the application is a legacy application > > that doesn't support MADCAP and doesn't bother to request an group > > address. How would you enforce certain policies concerning group address > > usage? My main concern is, what applications today are *not* legacy applications? -- Hugh LaMaster, M/S 233-21, Email: lamaster@nas.nasa.gov NASA Ames Research Center Or: lamaster@nren.nasa.gov Moffett Field, CA 94035-1000 Or: lamaster@kinkajou.arc.nasa.gov Phone: 650/604-1056 Disc: Unofficial, personal *opinion*. From owner-malloc@catarina.usc.edu Mon Jul 9 15:02:59 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25996 for ; Mon, 9 Jul 2001 15:02:58 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id LAA19469 for malloc-list; Mon, 9 Jul 2001 11:39:07 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id LAA19464 for ; Mon, 9 Jul 2001 11:39:06 -0700 (PDT) Received: (from pavlin@localhost) by rumi.usc.edu (8.9.3/8.9.3) id LAA84817 for malloc@catarina.usc.edu; Mon, 9 Jul 2001 11:39:06 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id LAA19430 for ; Mon, 9 Jul 2001 11:38:20 -0700 (PDT) Received: from sith.maoz.com (sith.maoz.com [205.167.76.10]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA28644 for ; Mon, 9 Jul 2001 11:38:20 -0700 (PDT) Received: (from dmm@localhost) by sith.maoz.com (8.11.3/8.11.2) id f69Ibuf04432; Mon, 9 Jul 2001 11:37:56 -0700 Date: Mon, 9 Jul 2001 11:37:56 -0700 From: David Meyer To: mjh@aciri.org, steve.hanna@sun.com, dthaler@windows.microsoft.co Cc: malloc@catarina.usc.edu, sob@harvard.edu, mankin@isi.edu, ala@nexthop.com, wfs@nexthop.com, iana@icann.org, zaid@juniper.net, almeroth@cs.ucsb.edu, dmm@sprint.net, randy@psg.com Subject: Re: more on reclaiming 225/8 Message-ID: <20010709113756.A4396@sprint.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-malloc@catarina.usc.edu Precedence: bulk Anyone have any other comments on this? I do not believe that there will be a wider constituency (than the list) in London, so I see no benefit in waiting until we congregate there to make a decision. If it is decided that the assignment should be kept, someone please provide me with an overview of how the IANA can decide to reclaim 225/8 (otherwise, as I said, otherwise it's a permanent allocation; BTW, a explanation as to why it should be kept is also needed as the assignment has timed out). Just so that there is no confusion, I against keeping the 225/8 assignment, for all the reasons that have been discussed on this list. In addition, as Randy so eloquently put it, the IANA has not and will not be a problem if we have a cogent proposal. SUMMARY: I am proposing to the MALLOC WG that the 225/8 be returned to the IANA, and that a new assignment be requested though standard IANA channels for whatever experiment is next. Dave From owner-malloc@catarina.usc.edu Mon Jul 9 15:45:30 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26964 for ; Mon, 9 Jul 2001 15:45:30 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id MAA19903 for malloc-list; Mon, 9 Jul 2001 12:14:58 -0700 (PDT) Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id MAA19898 for ; Mon, 9 Jul 2001 12:14:57 -0700 (PDT) Received: (from pavlin@localhost) by rumi.usc.edu (8.9.3/8.9.3) id MAA85680 for malloc@catarina.usc.edu; Mon, 9 Jul 2001 12:14:57 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id MAA19887 for ; Mon, 9 Jul 2001 12:14:38 -0700 (PDT) Received: from kinkajou.arc.nasa.gov (kinkajou.arc.nasa.gov [128.102.196.170]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id MAA22893 for ; Mon, 9 Jul 2001 12:14:38 -0700 (PDT) Received: from localhost (lamaster@localhost) by kinkajou.arc.nasa.gov (8.9.3+Sun/8.9.1) with ESMTP id MAA23380; Mon, 9 Jul 2001 12:10:41 -0700 (PDT) X-Authentication-Warning: kinkajou.arc.nasa.gov: lamaster owned process doing -bs Date: Mon, 9 Jul 2001 12:10:41 -0700 (PDT) From: Hugh LaMaster X-Sender: lamaster@kinkajou.arc.nasa.gov To: malloc@catarina.usc.edu cc: David Meyer , Mark Handley , steve.hanna@sun.com, dthaler@windows.microsoft.co, sob@harvard.edu, mankin@isi.edu, ala@nexthop.com, wfs@nexthop.com, iana@icann.org, Zaid Albanna , Kevin Almeroth , Randy Bush Subject: Re: more on reclaiming 225/8 In-Reply-To: <20010709113756.A4396@sprint.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-malloc@catarina.usc.edu Precedence: bulk On Mon, 9 Jul 2001, David Meyer wrote: > SUMMARY: I am proposing to the MALLOC WG that the 225/8 > be returned to the IANA, and that a new assignment > be requested though standard IANA channels for > whatever experiment is next. I concur with David Meyer's proposal. -- Hugh LaMaster, M/S 233-21, Email: lamaster@nas.nasa.gov NASA Ames Research Center Or: lamaster@nren.nasa.gov Moffett Field, CA 94035-1000 Or: lamaster@kinkajou.arc.nasa.gov Phone: 650/604-1056 Disc: Unofficial, personal *opinion*. From owner-malloc@catarina.usc.edu Mon Jul 9 15:47:17 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27045 for ; Mon, 9 Jul 2001 15:47:16 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id MAA20000 for malloc-list; Mon, 9 Jul 2001 12:22:28 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id MAA19995 for ; Mon, 9 Jul 2001 12:22:28 -0700 (PDT) Received: (from pavlin@localhost) by rumi.usc.edu (8.9.3/8.9.3) id MAA85870 for malloc@catarina.usc.edu; Mon, 9 Jul 2001 12:22:27 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id MAA19985 for ; Mon, 9 Jul 2001 12:22:11 -0700 (PDT) Received: from letters.cs.ucsb.edu (letters.cs.ucsb.edu [128.111.41.13]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id MAA27843 for ; Mon, 9 Jul 2001 12:22:11 -0700 (PDT) Received: from cab.cs.ucsb.edu (cab [128.111.49.120]) by letters.cs.ucsb.edu (8.9.3+Sun/8.9.3) with ESMTP id MAA09758; Mon, 9 Jul 2001 12:18:03 -0700 (PDT) Received: by cab.cs.ucsb.edu (8.10.2+Sun/SMI-SVR4) id f69JI3K22520 for ; Mon, 9 Jul 2001 12:18:03 -0700 (PDT) Date: Mon, 9 Jul 2001 12:18:03 -0700 (PDT) From: almeroth@cs.ucsb.edu (Kevin C. Almeroth) Message-Id: <200107091918.f69JI3K22520@cab.cs.ucsb.edu> To: lamaster@nas.nasa.gov, malloc@catarina.usc.edu Subject: Re: more on reclaiming 225/8 Cc: ala@nexthop.com, dmm@sprint.net, dthaler@windows.microsoft.co, iana@icann.org, mankin@isi.edu, mjh@aciri.org, randy@psg.com, sob@harvard.edu, steve.hanna@sun.com, wfs@nexthop.com, zaid@juniper.net Sender: owner-malloc@catarina.usc.edu Precedence: bulk >>On Mon, 9 Jul 2001, David Meyer wrote: >> >>> SUMMARY: I am proposing to the MALLOC WG that the 225/8 >>> be returned to the IANA, and that a new assignment >>> be requested though standard IANA channels for >>> whatever experiment is next. >> >>I concur with David Meyer's proposal. I do as well. -Kevin From owner-malloc@catarina.usc.edu Mon Jul 9 15:49:05 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27136 for ; Mon, 9 Jul 2001 15:49:04 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id MAA19952 for malloc-list; Mon, 9 Jul 2001 12:18:43 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id MAA19947 for ; Mon, 9 Jul 2001 12:18:42 -0700 (PDT) Received: from aardvark.aciri.org (aardvark.aciri.org [192.150.187.20]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id MAA25706 for ; Mon, 9 Jul 2001 12:18:42 -0700 (PDT) Received: from aardvark.aciri.org (localhost [127.0.0.1]) by aardvark.aciri.org (8.11.3/8.11.1) with ESMTP id f69JIWo05801; Mon, 9 Jul 2001 12:18:32 -0700 (PDT) (envelope-from mjh@aardvark.aciri.org) From: Mark Handley X-Organisation: ACIRI To: David Meyer cc: steve.hanna@sun.com, dthaler@windows.microsoft.co, malloc@catarina.usc.edu, sob@harvard.edu, mankin@isi.edu, ala@nexthop.com, wfs@nexthop.com, iana@icann.org, zaid@juniper.net, almeroth@cs.ucsb.edu, randy@psg.com Subject: Re: more on reclaiming 225/8 In-reply-to: Your message of "Mon, 09 Jul 2001 11:37:56 PDT." <20010709113756.A4396@sprint.net> Date: Mon, 09 Jul 2001 12:18:32 -0700 Message-ID: <5799.994706312@aardvark.aciri.org> Sender: owner-malloc@catarina.usc.edu Precedence: bulk > SUMMARY: I am proposing to the MALLOC WG that the 225/8 > be returned to the IANA, and that a new assignment > be requested though standard IANA channels for > whatever experiment is next. I was arguing against a rush to return this without proper discussion, but I think the issue has now been properly aired and people given enough opportunity to comment. I don't see anyone arguing strenuously for keeping the allocation while experiments are performed, so I agree with the above proposal. Cheers, Mark From owner-malloc@catarina.usc.edu Mon Jul 9 17:14:05 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28771 for ; Mon, 9 Jul 2001 17:14:01 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id NAA20441 for malloc-list; Mon, 9 Jul 2001 13:48:02 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id NAA20436 for ; Mon, 9 Jul 2001 13:48:01 -0700 (PDT) Received: (from pavlin@localhost) by rumi.usc.edu (8.9.3/8.9.3) id NAA87750 for malloc@catarina.usc.edu; Mon, 9 Jul 2001 13:48:01 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id NAA20343 for ; Mon, 9 Jul 2001 13:10:43 -0700 (PDT) Received: from roam.psg.com (mpfg.attlabs.net [12.106.35.2]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id NAA28053 for ; Mon, 9 Jul 2001 13:10:43 -0700 (PDT) Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15JhLX-000GCB-00; Mon, 09 Jul 2001 13:09:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Hugh LaMaster Cc: malloc@catarina.usc.edu, David Meyer , Mark Handley , steve.hanna@sun.com, dthaler@windows.microsoft.co, sob@harvard.edu, mankin@isi.edu, ala@nexthop.com, wfs@nexthop.com, iana@icann.org, Zaid Albanna , Kevin Almeroth Subject: Re: more on reclaiming 225/8 References: <20010709113756.A4396@sprint.net> Message-Id: Date: Mon, 09 Jul 2001 13:09:31 -0700 Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit >> SUMMARY: I am proposing to the MALLOC WG that the 225/8 >> be returned to the IANA, and that a new assignment >> be requested though standard IANA channels for >> whatever experiment is next. > I concur with David Meyer's proposal. meeee tooooo From owner-malloc@catarina.usc.edu Mon Jul 9 17:47:05 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29404 for ; Mon, 9 Jul 2001 17:47:04 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id OAA20599 for malloc-list; Mon, 9 Jul 2001 14:28:31 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id OAA20594 for ; Mon, 9 Jul 2001 14:28:30 -0700 (PDT) Received: (from pavlin@localhost) by rumi.usc.edu (8.9.3/8.9.3) id OAA88693 for malloc@catarina.usc.edu; Mon, 9 Jul 2001 14:28:30 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id NAA20469 for ; Mon, 9 Jul 2001 13:57:12 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by usc.edu (8.9.3.1/8.9.3/usc) with SMTP id NAA00112 for ; Mon, 9 Jul 2001 13:57:10 -0700 (PDT) Received: from 157.54.9.104 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 09 Jul 2001 13:39:06 -0700 (Pacific Daylight Time) Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 9 Jul 2001 13:39:05 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 9 Jul 2001 13:39:05 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 9 Jul 2001 13:38:11 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: more on reclaiming 225/8 X-MimeOLE: Produced By Microsoft Exchange V6.0.5683.0 Date: Mon, 9 Jul 2001 13:38:11 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1B580A0@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: more on reclaiming 225/8 Thread-Index: AcEIsSvanD5yOfMGSYCD6dT7B/MdBgABRzTw From: "Dave Thaler" To: "Hugh LaMaster" , Cc: "Beau Williamson" , "John Meylor" , "David Meyer" , "Mark Handley" , "Deborah Estrin" , , "Bill Fenner" , "Randy Bush" , "Zaid Albanna" , "Kevin Almeroth" , X-OriginalArrivalTime: 09 Jul 2001 20:38:11.0688 (UTC) FILETIME=[11FC7680:01C108B7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id NAA20470 Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hugh asks: > I did look around a little bit over the weekend. I found a little bit > of alpha-release stuff. Maybe I missed the more fully developed stuff. > Is there a website or repository with code or pointers to code for > the RFC 2771 API conformant libraries and server daemons? I'm not aware of a web site that has such information, but I'd be willing to add it on the malloc web site if people want, and people send me information. Speaking on behalf of one specific platform vendor, Windows 2000 and XP have RFC 2771 API conformant libraries and server daemons. I'll let others respond for other platforms. > Have any > of the common (ie Mbone) tools (e.g. vic, vat, rat) been ported > to use these libraries/facilities? How about COTS software? Sorry > if these are uninformed questions; I'm very out of date on what has > been happening and would like to get up to speed. I can't speak on behalf of the tools that you mention (although it would make more sense for sdr to use them, not vic/vat/etc which don't allocate addresses), but Windows 2000 and XP do have tools that use these libraries/facilities. -Dave From owner-malloc@catarina.usc.edu Mon Jul 9 19:58:32 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA01600 for ; Mon, 9 Jul 2001 19:58:31 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id QAA21027 for malloc-list; Mon, 9 Jul 2001 16:40:13 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id QAA21019 for ; Mon, 9 Jul 2001 16:40:11 -0700 (PDT) Received: from multicasttech.com (IDENT:root@garcia.multicasttech.com [63.105.122.8]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id QAB28492 for ; Mon, 9 Jul 2001 16:40:06 -0700 (PDT) Received: from [63.105.122.193] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3.2) with ESMTP id 1016532; Mon, 09 Jul 2001 19:30:51 -0400 Message-ID: <3B4A3F9F.73A96793@21rst-century.com> Date: Mon, 09 Jul 2001 19:34:55 -0400 From: Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: David Meyer CC: mjh@aciri.org, steve.hanna@sun.com, dthaler@windows.microsoft.co, malloc@catarina.usc.edu, sob@harvard.edu, mankin@isi.edu, ala@nexthop.com, wfs@nexthop.com, iana@icann.org, zaid@juniper.net, almeroth@cs.ucsb.edu, randy@psg.com Subject: Re: more on reclaiming 225/8 References: <20010709113756.A4396@sprint.net> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit David Meyer wrote: > > SUMMARY: I am proposing to the MALLOC WG that the 225/8 > be returned to the IANA, and that a new assignment > be requested though standard IANA channels for > whatever experiment is next. > > Dave This seems to me to be the proper thing to do. -- Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@multicasttech.com http://www.on-the-i.com Test your network for multicast : http://www.multicasttech.com/mt/ Check the status of multicast in real time : http://www.multicasttech.com/status/index.html From owner-malloc@catarina.usc.edu Tue Jul 17 13:52:06 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02366 for ; Tue, 17 Jul 2001 13:52:04 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id KAA62159 for malloc-list; Tue, 17 Jul 2001 10:35:47 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id KAA62110 for ; Tue, 17 Jul 2001 10:32:55 -0700 (PDT) Received: (from pavlin@localhost) by rumi.usc.edu (8.9.3/8.9.3) id KAA06102 for malloc@catarina.usc.edu; Tue, 17 Jul 2001 10:32:55 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id KAA61978; Tue, 17 Jul 2001 10:21:58 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id KAA12538; Tue, 17 Jul 2001 10:21:56 -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 NAA23758; Tue, 17 Jul 2001 13:16:53 -0400 (EDT) Message-Id: <200107171716.NAA23758@ietf.org> From: The IESG To: AAA Working Group , ACAP Working Group , ADSLMIB Working Group , AFT Working Group , AGENTX Working Group , APEX Working Group , ATOMMIB Working Group , AVT Working Group , BEEP Working Group , BGMP Working Group , BMWG Working Group , BRIDGE Working Group , CALSCH Working Group , CAT Working Group , CCAMP Working Group , CNRP Working Group , DELTAV Working Group , DHC Working Group , DIFFSERV Working Group , DISMAN Working Group , DNSEXT Working Group , DNSOP Working Group , ECM Working Group , EDIINT Working Group , ENTMIB Working Group , ENUM Working Group , EOS Working Group , FAX Working Group , FRNETMIB Working Group , FTPEXT Working Group , GEOPRIV Working Group , GRIP Working Group , GSMP Working Group , HUBMIB Working Group , IDMR Working Group , IDN Working Group , IDR Working Group , IDWG Working Group , IFMIB Working Group , IMAPEXT Working Group , IMPP Working Group , IPCDN Working Group , IPFC Working Group , IPNGWG Working Group , IPO Working Group , IPORPR Working Group , IPP Working Group , IPPM Working Group , IPS Working Group , IPSEC Working Group , IPSP Working Group , IPSRA Working Group , IPTEL Working Group , ISIS Working Group , ISSLL Working Group , ITRACE Working Group , KINK Working Group , KRB-WG Working Group , L2TPEXT Working Group , LDAPBIS Working Group , LDAPEXT Working Group , LDUP Working Group , MALLOC Working Group , MANET Working Group , MBONED Working Group , MEGACO Working Group , MIDCOM Working Group , MMUSIC Working Group , MOBILEIP Working Group , MPLS Working Group , MSDP Working Group , MSEC Working Group , MSGTRK Working Group , MULTI6 Working Group , NASREQ Working Group , NAT Working Group , NFSV4 Working Group , NGTRANS Working Group , NNTPEXT Working Group , OPENPGP Working Group , OSPF Working Group , OTP Working Group , PILC Working Group , PIM Working Group , PKIX Working Group , POISSON Working Group , POLICY Working Group , PPPEXT Working Group , PPVPN Working Group , PROVREG Working Group , PWE3 Working Group , RAP Working Group , RESCAP Working Group , RIP Working Group , RMONMIB Working Group , RMT Working Group , ROHC Working Group , RSERPOOL Working Group , RUN Working Group , SACRED Working Group , SEAMOBY Working Group , SECSH Working Group , SIGTRAN Working Group , SIMPLE Working Group , SIP Working Group , SMIME Working Group , SMING Working Group , SNMPCONF Working Group , SNMPV3 Working Group , SPIRITS Working Group , SSM Working Group , STIME Working Group , SYSLOG Working Group , TEWG Working Group , TLS Working Group , TN3270E Working Group , TRADE Working Group , TSVWG Working Group , UDLR Working Group , URN Working Group , USEFOR Working Group , USWG Working Group , VPIM Working Group , VRRP Working Group , WEBDAV Working Group , WEBI Working Group , WTS Working Group , XMLDSIG Working Group , ZEROCONF Working Group cc: iesg@ietf.org Subject: Note Well Date: Tue, 17 Jul 2001 13:16:53 -0400 Sender: owner-malloc@catarina.usc.edu Precedence: bulk Greetings, This is the revised text of the NOTE WELL statement. ------------------------------------------------------ NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to: - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. From owner-malloc@catarina.usc.edu Tue Jul 17 13:53:11 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02585 for ; Tue, 17 Jul 2001 13:53:10 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id KAA62166 for malloc-list; Tue, 17 Jul 2001 10:36:29 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id KAA62123 for ; Tue, 17 Jul 2001 10:33:38 -0700 (PDT) Received: (from pavlin@localhost) by rumi.usc.edu (8.9.3/8.9.3) id KAA06129 for malloc@catarina.usc.edu; Tue, 17 Jul 2001 10:33:38 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id KAA62023; Tue, 17 Jul 2001 10:27:29 -0700 (PDT) Received: from roam.psg.com (H-135-207-10-122.research.att.com [135.207.10.122]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id KAA17472; Tue, 17 Jul 2001 10:27:24 -0700 (PDT) Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15MYb7-0000LK-00; Tue, 17 Jul 2001 13:25:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rsent-To: eos@ops.ietf.org From: The IESG To: AAA Working Group , ACAP Working Group , ADSLMIB Working Group , AFT Working Group , AGENTX Working Group , APEX Working Group , ATOMMIB Working Group , AVT Working Group , BEEP Working Group , BGMP Working Group , BMWG Working Group , BRIDGE Working Group , CALSCH Working Group , CAT Working Group , CCAMP Working Group , CNRP Working Group , DELTAV Working Group , DHC Working Group , DIFFSERV Working Group , DISMAN Working Group , DNSEXT Working Group , DNSOP Working Group , ECM Working Group , EDIINT Working Group , ENTMIB Working Group , ENUM Working Group , EOS Working Group , FAX Working Group , FRNETMIB Working Group , FTPEXT Working Group , GEOPRIV Working Group , GRIP Working Group , GSMP Working Group , HUBMIB Working Group , IDMR Working Group , IDN Working Group , IDR Working Group , IDWG Working Group , IFMIB Working Group , IMAPEXT Working Group , IMPP Working Group , IPCDN Working Group , IPFC Working Group , IPNGWG Working Group , IPO Working Group , IPORPR Working Group , IPP Working Group , IPPM Working Group , IPS Working Group , IPSEC Working Group , IPSP Working Group , IPSRA Working Group , IPTEL Working Group , ISIS Working Group , ISSLL Working Group , ITRACE Working Group , KINK Working Group , KRB-WG Working Group , L2TPEXT Working Group , LDAPBIS Working Group , LDAPEXT Working Group , LDUP Working Group , MALLOC Working Group , MANET Working Group , MBONED Working Group , MEGACO Working Group , MIDCOM Working Group , MMUSIC Working Group , MOBILEIP Working Group , MPLS Working Group , MSDP Working Group , MSEC Working Group , MSGTRK Working Group , MULTI6 Working Group , NASREQ Working Group , NAT Working Group , NFSV4 Working Group , NGTRANS Working Group , NNTPEXT Working Group , OPENPGP Working Group , OSPF Working Group , OTP Working Group , PILC Working Group , PIM Working Group , PKIX Working Group , POISSON Working Group , POLICY Working Group , PPPEXT Working Group , PPVPN Working Group , PROVREG Working Group , PWE3 Working Group , RAP Working Group , RESCAP Working Group , RIP Working Group , RMONMIB Working Group , RMT Working Group , ROHC Working Group , RSERPOOL Working Group , RUN Working Group , SACRED Working Group , SEAMOBY Working Group , SECSH Working Group , SIGTRAN Working Group , SIMPLE Working Group , SIP Working Group , SMIME Working Group , SMING Working Group , SNMPCONF Working Group , SNMPV3 Working Group , SPIRITS Working Group , SSM Working Group , STIME Working Group , SYSLOG Working Group , TEWG Working Group , TLS Working Group , TN3270E Working Group , TRADE Working Group , TSVWG Working Group , UDLR Working Group , URN Working Group , USEFOR Working Group , USWG Working Group , VPIM Working Group , VRRP Working Group , WEBDAV Working Group , WEBI Working Group , WTS Working Group , XMLDSIG Working Group , ZEROCONF Working Group cc: iesg@ietf.org Subject: Note Well Message-Id: Date: Tue, 17 Jul 2001 13:25:25 -0400 Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Greetings, This is the revised text of the NOTE WELL statement. ------------------------------------------------------ NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to: - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. From owner-malloc@catarina.usc.edu Mon Jul 23 13:13:51 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07148 for ; Mon, 23 Jul 2001 13:13:48 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id JAA93582 for malloc-list; Mon, 23 Jul 2001 09:56:45 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id JAA93577 for ; Mon, 23 Jul 2001 09:56:44 -0700 (PDT) Received: (from pavlin@localhost) by rumi.usc.edu (8.9.3/8.9.3) id JAA13066 for malloc@catarina.usc.edu; Mon, 23 Jul 2001 09:56:44 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id DAA92314 for ; Mon, 23 Jul 2001 03:59:33 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id DAA14920 for ; Mon, 23 Jul 2001 03:59:30 -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 GAA09841; Mon, 23 Jul 2001 06:55:12 -0400 (EDT) Message-Id: <200107231055.GAA09841@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-malloc-mib-04.txt Date: Mon, 23 Jul 2001 06:55:12 -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 Allocation MIB Author(s) : D. Thaler Filename : draft-ietf-malloc-malloc-mib-04.txt Pages : 39 Date : 20-Jul-01 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multicast address allocation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-malloc-malloc-mib-04.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-malloc-mib-04.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-malloc-mib-04.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: <20010720083122.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-malloc-malloc-mib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-malloc-malloc-mib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010720083122.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-malloc@catarina.usc.edu Tue Jul 24 15:57:35 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16248 for ; Tue, 24 Jul 2001 15:57:31 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id MAA98956 for malloc-list; Tue, 24 Jul 2001 12:42:59 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id MAA98951 for ; Tue, 24 Jul 2001 12:42:58 -0700 (PDT) Received: from rumi (localhost [127.0.0.1]) by rumi.usc.edu (8.9.3/8.9.3) with ESMTP id MAA48304 for ; Tue, 24 Jul 2001 12:42:57 -0700 (PDT) Message-Id: <200107241942.MAA48304@rumi.usc.edu> To: malloc@catarina.usc.edu Subject: MALLOC mailing list temporary unavailable Date: Tue, 24 Jul 2001 12:42:57 -0700 From: Pavlin Ivanov Radoslavov Sender: owner-malloc@catarina.usc.edu Precedence: bulk During the period of time between July 26th and Aug 3th there will be lab renovation in the USC Network lab (where catarina.usc.edu, the mail server for this mailing list is hosted). During the renovation, the mail service for this mailing list (and all other lists hosted on this server) may be disrupted (hopefully for no more than few hours, but if something goes wrong it may be for longer). If there is need for this mailing list to be fully operational during the renovation (e.g, temporary hosting it on a mail server outside that lab), I am looking forward for suggestions/solutions/mail-serverspace hospitality. Thanks, Pavlin Radoslavov (malloc@catarina.usc.edu ML admin) P.S. In case you need to contact me regarding the ML operation during the renovation period, please send me email to pavlin@usc.edu From owner-malloc@catarina.usc.edu Tue Jul 24 17:39:53 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25841 for ; Tue, 24 Jul 2001 17:39:46 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id OAA00226 for malloc-list; Tue, 24 Jul 2001 14:23:50 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: (from pavlin@localhost) by catarina.usc.edu (8.9.3/8.9.3) id OAA00220 for malloc@catarina.usc.edu; Tue, 24 Jul 2001 14:23:49 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id OAA00206 for ; Tue, 24 Jul 2001 14:23:07 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by usc.edu (8.9.3.1/8.9.3/usc) with SMTP id OAA23983 for ; Tue, 24 Jul 2001 14:23:07 -0700 (PDT) Received: from 157.54.1.52 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 24 Jul 2001 14:20:54 -0700 (Pacific Daylight Time) Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 24 Jul 2001 12:35:03 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 24 Jul 2001 12:34:24 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 24 Jul 2001 12:33:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5683.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C11477.7BDDB75A" Subject: FW: I-D ACTION:draft-ietf-malloc-malloc-mib-04.txt Date: Tue, 24 Jul 2001 12:33:15 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC101671FFE@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: yes Thread-Topic: I-D ACTION:draft-ietf-malloc-malloc-mib-04.txt Thread-Index: AcETmxdFCTPme+dPQ0S9QSktJzKt4QA2nNBQ From: "Dave Thaler" To: X-OriginalArrivalTime: 24 Jul 2001 19:33:15.0764 (UTC) FILETIME=[7C07E340:01C11477] Sender: owner-malloc@catarina.usc.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C11477.7BDDB75A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable An updated version of the Multicast Address Allocation MIB is now in the = I-D repository at http://www.ietf.org/internet-drafts/draft-ietf-malloc-malloc-mib-04.txt This email begins a WG last call, to expire in three weeks (due to IETF) = on Tuesday, August 7th. List of changes in -04: 1) Remove AAP objects per previous discussion. 2) Add text mentioning that the MIB applies to SSM addresses too. 3) Added mallocScopeSSM object to the mallocScopeTable to identify SSM = scopes. 4) Added "local" to the list of values of IANAscopeSource and = IANAmallocRangeSource, to cover scopes that are "well-known" and added = automatically, e.g. the SSM range, IPv6 multicast scopes, etc. Dave Thaler MALLOC Co-chair ------_=_NextPart_001_01C11477.7BDDB75A Content-Type: application/octet-stream; name="draft-ietf-malloc-malloc-mib-04.URL" Content-Description: draft-ietf-malloc-malloc-mib-04.URL Content-Disposition: attachment; filename="draft-ietf-malloc-malloc-mib-04.URL" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLW1hbGxvYy1tYWxsb2MtbWliLTA0LnR4dA0K ------_=_NextPart_001_01C11477.7BDDB75A-- From owner-malloc@catarina.usc.edu Wed Jul 25 15:00:09 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23580 for ; Wed, 25 Jul 2001 15:00:08 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id LAA04415 for malloc-list; Wed, 25 Jul 2001 11:19:59 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id LAA04410 for ; Wed, 25 Jul 2001 11:19:58 -0700 (PDT) Received: (from pavlin@localhost) by rumi.usc.edu (8.9.3/8.9.3) id LAA78949 for malloc@catarina.usc.edu; Wed, 25 Jul 2001 11:19:58 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id LAA04400 for ; Wed, 25 Jul 2001 11:17:25 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA06003 for ; Wed, 25 Jul 2001 11:17:21 -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 OAA18604; Wed, 25 Jul 2001 14:12:13 -0400 (EDT) Message-Id: <200107251812.OAA18604@ietf.org> To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu From: The IESG SUBJECT: Last Call: Unicast-Prefix-based IPv6 Multicast Addresses to Proposed Standard Reply-to: iesg@ietf.org Date: Wed, 25 Jul 2001 14:12:13 -0400 Sender: owner-malloc@catarina.usc.edu Precedence: bulk The IESG has received a request from the IPNG and the MALLOC Working Groups to consider publication of the folloing two Interent-Drafts as Proposed Standards. o Unicast-Prefix-based IPv6 Multicast Addresses o Dynamic Allocation Guidelines for IPv6 Multicast Addresses as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by August 25, 2001. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-uni-based-mcast-02.txt http://www.ietf.org/internet-drafts/; Wed, 25 Jul 2001 19:08:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA23057; Wed, 25 Jul 2001 19:05:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA23026 for ; Wed, 25 Jul 2001 19:05:38 -0400 (EDT) Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19591 for ; Wed, 25 Jul 2001 19:04:38 -0400 (EDT) Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id QAA06049 for ; Wed, 25 Jul 2001 16:05:02 -0700 (PDT) Received: from rumi (localhost [127.0.0.1]) by rumi.usc.edu (8.9.3/8.9.3) with ESMTP id QAA85867 for ; Wed, 25 Jul 2001 16:05:02 -0700 (PDT) Message-Id: <200107252305.QAA85867@rumi.usc.edu> To: malloc@ietf.org Date: Wed, 25 Jul 2001 16:05:02 -0700 From: Pavlin Ivanov Radoslavov Subject: [Malloc] MALLOC mailing list (temporary?) moved to malloc@ietf.org Sender: malloc-admin@ietf.org Errors-To: malloc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multicast-Address Allocation X-BeenThere: malloc@ietf.org It was brought to my attention that the MALLOC ML should be up and operational without interruptions because of the Last Call for Proposed Standards of the following two I-Ds (see the last email on this ML that was sent today): o Unicast-Prefix-based IPv6 Multicast Addresses o Dynamic Allocation Guidelines for IPv6 Multicast Addresses Because of the lab renovation in USC, the MALLOC WG mailing list currently is moved FROM malloc@catarina.usc.edu TO malloc@ietf.org The move was originally suppose to be temporary for a week or so, but it could be permanent (this should be finalized after IETF). From now on please send your email to malloc@ietf.org (until further notice). In the mean time the old address should still be operational. Thanks, Pavlin P.S. In case you need to handle your subscription for the next few days, below is the info you may need. If something doesn't work, then drop me an email at pavlin@catarina.usc.ed, cc: pavlin@usc.edu and I will try to fix it. >The web page for users of your mailing list is: > > http://www.ietf.org/mailman/listinfo/malloc > >There is also an email-based interface for users (not administrators) >of your list; you can get info about using it by sending a message >with just the word `help' as subject or in the body, to: > > malloc-request@ietf.org > >Please address all questions to mailman-owner@ietf.org. _______________________________________________ Malloc mailing list Malloc@ietf.org http://www.ietf.org/mailman/listinfo/malloc