From owner-malloc@catarina.usc.edu Mon Jul 5 15:11:57 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04663 for ; Mon, 5 Jul 1999 15:11:56 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id LAA10006 for malloc-list; Mon, 5 Jul 1999 11:47:15 -0700 Received: from dthaler.microsoft.com ([131.107.1.30]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id LAA10002 for ; Mon, 5 Jul 1999 11:47:10 -0700 Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id NAA10496 for malloc@catarina.usc.edu; Mon, 5 Jul 1999 13:28:57 -0700 (PDT) (envelope-from dthaler) From: Dave Thaler Message-Id: <199907052028.NAA10496@dthaler.microsoft.com> Subject: WG Last Call on Abstract API In-Reply-To: <3.0.5.16.19990613111630.346fbaea@shell7.ba.best.com> from Ross Finlayson at "Jun 13, 1999 11:16:30 am" To: malloc@catarina.usc.edu Date: Mon, 5 Jul 1999 13:28:57 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit As a reminder, one of our WG goals is: Jul 99 Submit the abstract API document(s0 to the IESG for consideration as Informational. This message starts a WG last call on the Abstract API draft: draft-ietf-malloc-api-06.txt The last call will expire in 3 weeks. Please send comments by July 26th. Thanks, -Dave Thaler From owner-malloc@catarina.usc.edu Fri Jul 9 04:34:36 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA08971 for ; Fri, 9 Jul 1999 04:34:35 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id UAA21919 for malloc-list; Thu, 8 Jul 1999 20:09:50 -0700 Received: from dthaler.microsoft.com ([131.107.1.30]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id OAA21315 for ; Thu, 8 Jul 1999 14:49:10 -0700 Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id QAA15013 for malloc@catarina.usc.edu; Thu, 8 Jul 1999 16:30:43 -0700 (PDT) (envelope-from dthaler) From: Dave Thaler Message-Id: <199907082330.QAA15013@dthaler.microsoft.com> Subject: Updated MALLOC architecture draft To: malloc@catarina.usc.edu Date: Thu, 8 Jul 1999 16:30:39 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit An new MALLOC architecture draft revision is now available on the MALLOC web site at: http://www.aciri.org/malloc/malloc-arch-02.txt This revision acts on the items that were marked as TODO in the previous draft, and mostly center around describing the architecture in a more general/modular manner, and allowing other methods at each layer, such as 233/8 allocation at the top layer. -Dave From owner-malloc@catarina.usc.edu Fri Jul 9 04:37:05 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA08983 for ; Fri, 9 Jul 1999 04:37:04 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id AAA22244 for malloc-list; Fri, 9 Jul 1999 00:10:22 -0700 Received: from dthaler.microsoft.com ([131.107.1.30]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id OAA21315 for ; Thu, 8 Jul 1999 14:49:10 -0700 Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id QAA15013 for malloc@catarina.usc.edu; Thu, 8 Jul 1999 16:30:43 -0700 (PDT) (envelope-from dthaler) From: Dave Thaler Message-Id: <199907082330.QAA15013@dthaler.microsoft.com> Subject: Updated MALLOC architecture draft To: malloc@catarina.usc.edu Date: Thu, 8 Jul 1999 16:30:39 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit An new MALLOC architecture draft revision is now available on the MALLOC web site at: http://www.aciri.org/malloc/malloc-arch-02.txt This revision acts on the items that were marked as TODO in the previous draft, and mostly center around describing the architecture in a more general/modular manner, and allowing other methods at each layer, such as 233/8 allocation at the top layer. -Dave From owner-malloc@catarina.usc.edu Fri Jul 9 04:38:19 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA08994 for ; Fri, 9 Jul 1999 04:38:17 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id TAA21866 for malloc-list; Thu, 8 Jul 1999 19:09:48 -0700 Received: from dthaler.microsoft.com ([131.107.1.30]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id OAA21315 for ; Thu, 8 Jul 1999 14:49:10 -0700 Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id QAA15013 for malloc@catarina.usc.edu; Thu, 8 Jul 1999 16:30:43 -0700 (PDT) (envelope-from dthaler) From: Dave Thaler Message-Id: <199907082330.QAA15013@dthaler.microsoft.com> Subject: Updated MALLOC architecture draft To: malloc@catarina.usc.edu Date: Thu, 8 Jul 1999 16:30:39 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit An new MALLOC architecture draft revision is now available on the MALLOC web site at: http://www.aciri.org/malloc/malloc-arch-02.txt This revision acts on the items that were marked as TODO in the previous draft, and mostly center around describing the architecture in a more general/modular manner, and allowing other methods at each layer, such as 233/8 allocation at the top layer. -Dave From owner-malloc@catarina.usc.edu Fri Jul 9 04:38:41 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09005 for ; Fri, 9 Jul 1999 04:38:40 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id PAA21374 for malloc-list; Thu, 8 Jul 1999 15:09:26 -0700 Received: from dthaler.microsoft.com ([131.107.1.30]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id OAA21315 for ; Thu, 8 Jul 1999 14:49:10 -0700 Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id QAA15013 for malloc@catarina.usc.edu; Thu, 8 Jul 1999 16:30:43 -0700 (PDT) (envelope-from dthaler) From: Dave Thaler Message-Id: <199907082330.QAA15013@dthaler.microsoft.com> Subject: Updated MALLOC architecture draft To: malloc@catarina.usc.edu Date: Thu, 8 Jul 1999 16:30:39 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit An new MALLOC architecture draft revision is now available on the MALLOC web site at: http://www.aciri.org/malloc/malloc-arch-02.txt This revision acts on the items that were marked as TODO in the previous draft, and mostly center around describing the architecture in a more general/modular manner, and allowing other methods at each layer, such as 233/8 allocation at the top layer. -Dave From owner-malloc@catarina.usc.edu Fri Jul 9 04:39:56 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09016 for ; Fri, 9 Jul 1999 04:39:54 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id BAA22645 for malloc-list; Fri, 9 Jul 1999 01:10:49 -0700 Received: from dthaler.microsoft.com ([131.107.1.30]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id OAA21315 for ; Thu, 8 Jul 1999 14:49:10 -0700 Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id QAA15013 for malloc@catarina.usc.edu; Thu, 8 Jul 1999 16:30:43 -0700 (PDT) (envelope-from dthaler) From: Dave Thaler Message-Id: <199907082330.QAA15013@dthaler.microsoft.com> Subject: Updated MALLOC architecture draft To: malloc@catarina.usc.edu Date: Thu, 8 Jul 1999 16:30:39 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit An new MALLOC architecture draft revision is now available on the MALLOC web site at: http://www.aciri.org/malloc/malloc-arch-02.txt This revision acts on the items that were marked as TODO in the previous draft, and mostly center around describing the architecture in a more general/modular manner, and allowing other methods at each layer, such as 233/8 allocation at the top layer. -Dave From owner-malloc@catarina.usc.edu Fri Jul 9 04:40:11 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09031 for ; Fri, 9 Jul 1999 04:40:10 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id VAA22013 for malloc-list; Thu, 8 Jul 1999 21:09:55 -0700 Received: from dthaler.microsoft.com ([131.107.1.30]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id OAA21315 for ; Thu, 8 Jul 1999 14:49:10 -0700 Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id QAA15013 for malloc@catarina.usc.edu; Thu, 8 Jul 1999 16:30:43 -0700 (PDT) (envelope-from dthaler) From: Dave Thaler Message-Id: <199907082330.QAA15013@dthaler.microsoft.com> Subject: Updated MALLOC architecture draft To: malloc@catarina.usc.edu Date: Thu, 8 Jul 1999 16:30:39 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit An new MALLOC architecture draft revision is now available on the MALLOC web site at: http://www.aciri.org/malloc/malloc-arch-02.txt This revision acts on the items that were marked as TODO in the previous draft, and mostly center around describing the architecture in a more general/modular manner, and allowing other methods at each layer, such as 233/8 allocation at the top layer. -Dave From owner-malloc@catarina.usc.edu Fri Jul 9 04:41:43 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09054 for ; Fri, 9 Jul 1999 04:41:42 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id SAA21775 for malloc-list; Thu, 8 Jul 1999 18:09:45 -0700 Received: from dthaler.microsoft.com ([131.107.1.30]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id OAA21315 for ; Thu, 8 Jul 1999 14:49:10 -0700 Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id QAA15013 for malloc@catarina.usc.edu; Thu, 8 Jul 1999 16:30:43 -0700 (PDT) (envelope-from dthaler) From: Dave Thaler Message-Id: <199907082330.QAA15013@dthaler.microsoft.com> Subject: Updated MALLOC architecture draft To: malloc@catarina.usc.edu Date: Thu, 8 Jul 1999 16:30:39 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit An new MALLOC architecture draft revision is now available on the MALLOC web site at: http://www.aciri.org/malloc/malloc-arch-02.txt This revision acts on the items that were marked as TODO in the previous draft, and mostly center around describing the architecture in a more general/modular manner, and allowing other methods at each layer, such as 233/8 allocation at the top layer. -Dave From owner-malloc@catarina.usc.edu Fri Jul 9 04:43:03 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09065 for ; Fri, 9 Jul 1999 04:43:02 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id WAA22101 for malloc-list; Thu, 8 Jul 1999 22:09:57 -0700 Received: from dthaler.microsoft.com ([131.107.1.30]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id OAA21315 for ; Thu, 8 Jul 1999 14:49:10 -0700 Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id QAA15013 for malloc@catarina.usc.edu; Thu, 8 Jul 1999 16:30:43 -0700 (PDT) (envelope-from dthaler) From: Dave Thaler Message-Id: <199907082330.QAA15013@dthaler.microsoft.com> Subject: Updated MALLOC architecture draft To: malloc@catarina.usc.edu Date: Thu, 8 Jul 1999 16:30:39 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit An new MALLOC architecture draft revision is now available on the MALLOC web site at: http://www.aciri.org/malloc/malloc-arch-02.txt This revision acts on the items that were marked as TODO in the previous draft, and mostly center around describing the architecture in a more general/modular manner, and allowing other methods at each layer, such as 233/8 allocation at the top layer. -Dave From owner-malloc@catarina.usc.edu Fri Jul 9 04:45:42 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09076 for ; Fri, 9 Jul 1999 04:45:41 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id RAA21666 for malloc-list; Thu, 8 Jul 1999 17:09:39 -0700 Received: from dthaler.microsoft.com ([131.107.1.30]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id OAA21315 for ; Thu, 8 Jul 1999 14:49:10 -0700 Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id QAA15013 for malloc@catarina.usc.edu; Thu, 8 Jul 1999 16:30:43 -0700 (PDT) (envelope-from dthaler) From: Dave Thaler Message-Id: <199907082330.QAA15013@dthaler.microsoft.com> Subject: Updated MALLOC architecture draft To: malloc@catarina.usc.edu Date: Thu, 8 Jul 1999 16:30:39 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit An new MALLOC architecture draft revision is now available on the MALLOC web site at: http://www.aciri.org/malloc/malloc-arch-02.txt This revision acts on the items that were marked as TODO in the previous draft, and mostly center around describing the architecture in a more general/modular manner, and allowing other methods at each layer, such as 233/8 allocation at the top layer. -Dave From owner-malloc@catarina.usc.edu Fri Jul 9 04:46:23 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09087 for ; Fri, 9 Jul 1999 04:46:22 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id AAA22269 for malloc-list; Fri, 9 Jul 1999 00:20:30 -0700 Received: from infoviaplus.net.ar ([200.9.212.61]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id AAA22265; Fri, 9 Jul 1999 00:20:18 -0700 Message-Id: <199907090720.AAA22265@catarina.usc.edu> Received: from ariel-borger ([209.13.191.209]) by infoviaplus.net.ar (Tid InfoMail Exchanger v2.20) with SMTP id #931504624.072150001; Fri, 9 Jul 1999 04:17:04 -0300 X-Mailer: Aureate Group Mail Free Edition From: DJ REMIX To: DJ Date: Fri, 09 Jul 1999 04:17:15 -0300 Subject: DeeJay Remix "EL SOFT MAS VENDIDO EN EE.UU" Reply-To: info@beatmail.com Organization: DJ REMIX MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=XXA7E4A7C4-0164A7E4XX Content-Transfer-Encoding: 7bit X-Priority: 3 X-Infomail-Id: 931504624.1C2F01AC1E039E.4624 Sender: owner-malloc@catarina.usc.edu Precedence: bulk This is a Multipart MIME message. Since your mail reader does not understand this format, some or all of this message may not be legible. --XXA7E4A7C4-0164A7E4XX Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit este mensaje se envia por unica vez DJ REMIX ES EL SOFT MUSICAL POR EXCELENCIA. Con DJ Remix podes: Crear tu musica. Hacer tus remix. Realizar scraching y mas... Incluye: Mas de 1300 Sampleos. Sequencer 8 canales Video tutorial Facil uso. OFERTA CONTADO A SOLO $49.- PEDILO AHORA ENVIANDO UN E-MAIL A: djremix@beatmail.com (con tu telefono) Envios en Capital sin cargo. ---------------------------------------------------------------------- This Message sent with Aureate Group Mail Free Edition http://groupmail.aureate.com --XXA7E4A7C4-0164A7E4XX Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit EL SOFT MUSICAL POR EXCELENCIA

EL SOFT MUSICAL POR EXCELENCIA

DEE JAY REMIX CONTIENE:

CON DEE JAY REMIX PODRAS:

Secuencer 8 canales.

Crear tu propia musica.

Video tutorial.

Hacer Scraching.

Mas de 1300 sampleos.

Crear los mejores remixes.

Pitch variable.

Incorporar tus propias creaciones.

Sistema interactivo de mezcla.

Importa y exporta tu musica al formato que te guste !

Ritmos y voces.

Facil Uso !

NO SE REQUIEREN CONOCIMIENTOS PREVIOS.

 OFERTA CONTADO A SOLO $49.- COMPRALO YA ENVIANDO UN E-MAIL: djremix@beatmail.com (con tu telefono)

ENVIO EN CAP. FED. SIN CARGO.

DEEJAY REMIX EL SOFT #1 DE EE.UU AHORA EN ARGENTINA

--XXA7E4A7C4-0164A7E4XX-- From owner-malloc@catarina.usc.edu Fri Jul 9 04:51:03 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09140 for ; Fri, 9 Jul 1999 04:51:02 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id XAA22153 for malloc-list; Thu, 8 Jul 1999 23:09:58 -0700 Received: from dthaler.microsoft.com ([131.107.1.30]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id OAA21315 for ; Thu, 8 Jul 1999 14:49:10 -0700 Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id QAA15013 for malloc@catarina.usc.edu; Thu, 8 Jul 1999 16:30:43 -0700 (PDT) (envelope-from dthaler) From: Dave Thaler Message-Id: <199907082330.QAA15013@dthaler.microsoft.com> Subject: Updated MALLOC architecture draft To: malloc@catarina.usc.edu Date: Thu, 8 Jul 1999 16:30:39 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit An new MALLOC architecture draft revision is now available on the MALLOC web site at: http://www.aciri.org/malloc/malloc-arch-02.txt This revision acts on the items that were marked as TODO in the previous draft, and mostly center around describing the architecture in a more general/modular manner, and allowing other methods at each layer, such as 233/8 allocation at the top layer. -Dave From owner-malloc@catarina.usc.edu Fri Jul 9 04:52:14 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09151 for ; Fri, 9 Jul 1999 04:52:13 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id OAA21319 for malloc-list; Thu, 8 Jul 1999 14:49:16 -0700 Received: from dthaler.microsoft.com ([131.107.1.30]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id OAA21315 for ; Thu, 8 Jul 1999 14:49:10 -0700 Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id QAA15013 for malloc@catarina.usc.edu; Thu, 8 Jul 1999 16:30:43 -0700 (PDT) (envelope-from dthaler) From: Dave Thaler Message-Id: <199907082330.QAA15013@dthaler.microsoft.com> Subject: Updated MALLOC architecture draft To: malloc@catarina.usc.edu Date: Thu, 8 Jul 1999 16:30:39 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit An new MALLOC architecture draft revision is now available on the MALLOC web site at: http://www.aciri.org/malloc/malloc-arch-02.txt This revision acts on the items that were marked as TODO in the previous draft, and mostly center around describing the architecture in a more general/modular manner, and allowing other methods at each layer, such as 233/8 allocation at the top layer. -Dave From owner-malloc@catarina.usc.edu Fri Jul 9 05:01:12 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09239 for ; Fri, 9 Jul 1999 05:01:11 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id QAA21570 for malloc-list; Thu, 8 Jul 1999 16:09:36 -0700 Received: from dthaler.microsoft.com ([131.107.1.30]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id OAA21315 for ; Thu, 8 Jul 1999 14:49:10 -0700 Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id QAA15013 for malloc@catarina.usc.edu; Thu, 8 Jul 1999 16:30:43 -0700 (PDT) (envelope-from dthaler) From: Dave Thaler Message-Id: <199907082330.QAA15013@dthaler.microsoft.com> Subject: Updated MALLOC architecture draft To: malloc@catarina.usc.edu Date: Thu, 8 Jul 1999 16:30:39 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit An new MALLOC architecture draft revision is now available on the MALLOC web site at: http://www.aciri.org/malloc/malloc-arch-02.txt This revision acts on the items that were marked as TODO in the previous draft, and mostly center around describing the architecture in a more general/modular manner, and allowing other methods at each layer, such as 233/8 allocation at the top layer. -Dave From owner-malloc@catarina.usc.edu Sat Jul 10 02:44:34 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA07991 for ; Sat, 10 Jul 1999 02:44:33 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id XAA27190 for malloc-list; Fri, 9 Jul 1999 23:21:33 -0700 Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id XAA27186 for ; Fri, 9 Jul 1999 23:21:28 -0700 Received: from rumi (localhost [127.0.0.1]) by rumi.usc.edu (8.8.5/8.6.9) with ESMTP id XAA03779 for ; Fri, 9 Jul 1999 23:21:27 -0700 (PDT) Message-Id: <199907100621.XAA03779@rumi.usc.edu> To: malloc@catarina.usc.edu Subject: AAP draft quick comments Date: Fri, 09 Jul 1999 23:21:27 -0700 From: Pavlin Ivanov Radoslavov Sender: owner-malloc@catarina.usc.edu Precedence: bulk 1) Packet Formats (Section 4): * Signature type has to be 3 bytes instead of 4 (this applies to the text that explains that entry) * Probably there should be a separate explanation entry for the P-bit, instead of only mentioning it in the SLEN text 2) The ASA (Address-Set-Announce) message should have entry with total number of sets in the message 3) The bit-mask in ASA message should be just the opposite (for consistency with "traditional" (?) use of bit-mask, if such thing exists of course ;) E.g. the mask in the example should be 0xfffeff00 instead of 0x000100ff. At least, the MASC draft/code uses the former definition/form of bit-mask, so it will be less confising if the whole malloc architecture uses the same definition. BTW, what bitmask definition other drafts/code use? 4) All other messages (ACLM, AITU, AIU, ASRP) do not have mask field. A 'Mask' field and 'Number of Entries' field should be added to each of those messages. 5) Address-Space-Report (ASRP) message does not include the MASC prefix description a pair of should be associated with. 6) If the MAAS needs more addresses than the MASC servers currently have/advertise, MAAS should somehow inform the amount of addresses MASC should allocate. Section 4.2.6 (ASRP description) has a paragraph re. "if the address space is insufficient", but it is not clear. If the ASRP messages include the description of the MASC prefixes each pair <# of addresses, end time> should be associated with, then sending a report re. MASC prefix can be used to inform the MASC servers that they need to allocate more addresses. Thanks, Pavlin From owner-malloc@catarina.usc.edu Sat Jul 10 13:20:48 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10606 for ; Sat, 10 Jul 1999 13:20:47 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id JAA00338 for malloc-list; Sat, 10 Jul 1999 09:35:05 -0700 Received: from svi.ssdnet.com.ar (root@[200.10.112.2]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id JAA00334; Sat, 10 Jul 1999 09:34:55 -0700 Received: from emc.ssdnet.com.ar (smtp.ssdnet.com.ar [200.10.112.14] (may be forged)) by svi.ssdnet.com.ar (8.8.8/8.8.7) with ESMTP id NAA29836; Sat, 10 Jul 1999 13:34:51 -0300 Received: from lulu (modemd202.ssdnet.com.ar [200.16.229.180]) by emc.ssdnet.com.ar (8.8.5/8.8.5) with SMTP id NAA14020; Sat, 10 Jul 1999 13:49:42 -0300 Message-Id: <199907101649.NAA14020@emc.ssdnet.com.ar> From: Cyberferia To: BaseMasiva Date: Sat, 10 Jul 1999 13:38:48 -0300 Subject: Comercio Electrónico Reply-To: publicitarya@mercosur.net MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Priority: 3 X-MIME-Autoconverted: from 8bit to quoted-printable by svi.ssdnet.com.ar id NAA29836 Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA10606 En http://cyberferia.com podes crear tu propio local virtual, gratis. Podes hacerlo desde tu propia computadora. Es facil, rapido, y seguro. No es necesario saber programacion. No importa que ya tengas un web site propio o no. Podes vender lo que sea: ropa, consejos, mascotas, relojes, objetos de arte, pasajes, software, suscripciones... Podes incluir fotos de los productos, el logo, y una presentacion de tu local. Si no queres vender, podes crear una pagina solamente para mostrar tu catalogo de productos. Por consultas sobre este producto, escribir a webmaster@cyberferia.com http://www.lsf.com.ar es la sucursal virtual de la Libreria Santa Fe. Fue inaugurada el 1 de julio de 1998. Podes revisar nuestro catalogo on-line de 70000 titulos. Aceptamos distintas formas de pago y enviamos a todo el mundo. http://www.libreriapaidos.com es la sucursal virtual de la Libreria Paidos. Fue inaugurada el 1 de diciembre de 1997. Esta librería virtual es la única en español especializada en Psicología. También encontrarás títulos de Psicoanálisis, Filosofía, Sociología y Educación. Podes revisar nuestro catalogo on-line de 20000 titulos, leer descripciones de los libros, y enterarte de los eventos psi de Buenos Aires. Aceptamos distintas formas de pago y enviamos a todo el mundo. (Este aviso se envía por única vez. No es necesario desuscribirse). From owner-malloc@catarina.usc.edu Sat Jul 10 16:53:18 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11441 for ; Sat, 10 Jul 1999 16:53:17 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA01629 for malloc-list; Sat, 10 Jul 1999 13:31:34 -0700 Received: from relay2.impsat1.com (relay2.impsat1.com [200.31.1.8]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id NAA01619 for ; Sat, 10 Jul 1999 13:31:25 -0700 Received: from impsat1.com.ar.impsat.net.ar (200.41.35.2.impsat.net [200.41.35.2]) by relay2.impsat1.com (8.8.5/8.8.4) with SMTP id RAA16513 for ; Sat, 10 Jul 1999 17:30:48 +0300 (GMT) Message-Id: <199907101430.RAA16513@relay2.impsat1.com> X-Mailer: Aureate Group Mail Free Edition From: TopCam To: Date: Sat, 10 Jul 1999 17:31:38 -0300 Subject: Cámara Digital para Video Conferencia Reply-To: ventas@siroflex.com.ar Organization: VIEWCOME ARGENTINA S.A. MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Priority: 3 X-MIME-Autoconverted: from 8bit to quoted-printable by relay2.impsat1.com id RAA16513 Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA11441 Ahora usted podrá adquirir la cámara para Video Conferencia más vendida por sólo US$ 99,00 + más gastos de envío (gratis en Capital Federal). No desaproveche esta Oferta!!! Puerto Paralelo http://www.siroflex.com.ar/es/TopCames1.htm Puerto USB http://www.siroflex.com.ar/es/TopCames1.htm#TC-203Mb No dude en contactarnos por cualquier consulta escribiendo a: ventas@siroflex.com.ar O llamándonos al 15-4998-2439 ó 15-4470-6257. Gracias por su atención!!! <<<<<<>>>>>>>>> ---------------------------------------------------------------------- This Message sent with Aureate Group Mail Free Edition http://groupmail.aureate.com From owner-malloc@catarina.usc.edu Sat Jul 10 18:34:50 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11851 for ; Sat, 10 Jul 1999 18:34:49 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id PAA01836 for malloc-list; Sat, 10 Jul 1999 15:11:58 -0700 Received: from skierka.adm.uni.wroc.pl ([156.17.87.193]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id PAA01827; Sat, 10 Jul 1999 15:11:49 -0700 Received: from moog (ip80.providence11.ri.pub-ip.psi.net [38.26.242.80]) by skierka.adm.uni.wroc.pl (8.9.0.Beta5/8.6.11) with ESMTP id XAA25188; Sat, 10 Jul 1999 23:59:42 +0300 Organization: University of Wroclaw Reply-To: Message-Id: <199907102059.XAA25188@skierka.adm.uni.wroc.pl> From: "Rick" Subject: URGENTE! To: araddress202kl@skierka.adm.uni.wroc.pl X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3 Mime-Version: 1.0 Date: Sat, 10 Jul 1999 17:07:59 -0500 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA11851 *********************************************************** AHORA SU EMPRESA PUEDE TENER SUS PROPIAS PAGINAS WEB http://www.su_empresa.com.ar info@su_empresa.com.ar POR SOLO $ 750 POR AÑO *********************************************************** EL PLAN ESPECIAL PARA "PYMES" INCLUYE: * DISEÑO DE 5 PAGINAS WEB (HASTA 15 PAGINAS EN WORD) Con los textos, fotos y logos de su empresa * REGISTRO DE SU MARCA/DOMINIO EN NIC-ARGENTINA (MINISTERIO DE RELACIONES EXTERIORES) Ej: http://www.suempresa.com.ar * ALQUILER POR 1 AÑO DEL ESPACIO EN NUESTRO SERVIDOR Inlcluye es espacio necesario para alojar sus Paginas Web Las 24 horas, los 365 dias * PUBLICACION EN MAS DE 200 GUIAS Y BUSCADORES DE EMPRESAS EN ARGENTINA, LATINOAMERICA Y EN EL RESTO DEL MUNDO Ej: Yahoo, Webcrawler, Altavista, Lycos, Guia, etc. * ESTADISTICAS DE ACCESO A SUS PAGINAS WEB Para medir la cantidad de visitantes que tiene su Web * REDIRECCIONAMIENTO ILIMITADO DE SUS E-MAILS Ej: info@suempresa.com.ar *********************************************************** INTER-MARKETING GROUP ARGENTINA Gallo 1527 Piso 2 (1425) Capital, Buenos Aires Tel: 4825-1115 Fax: 4825-1117 *********************************************************** >> Mas de 300 Clientes Satisfechos desde 1996 << *********************************************************** La oferta no incluye el IVA y es válida hasta el 31/10/99 REMOVE AT mailto:offlist92@yahoo.com?subject=remove From owner-malloc@catarina.usc.edu Tue Jul 13 01:28:16 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA01280 for ; Tue, 13 Jul 1999 01:28:15 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id VAA10017 for malloc-list; Mon, 12 Jul 1999 21:55:28 -0700 Received: from julieta.sldigital.com.ar ([209.13.135.194]) by catarina.usc.edu (8.6.10/8.6.9) with SMTP id VAA10009 for ; Mon, 12 Jul 1999 21:55:17 -0700 Date: Mon, 12 Jul 1999 21:55:17 -0700 Message-Id: <199907130455.VAA10009@catarina.usc.edu> Received: (qmail 30173 invoked from network); 13 Jul 1999 04:23:01 -0000 Received: from softdnserror (HELO MYNAME) (200.41.130.160) by julieta.sldigital.com.ar with SMTP; 13 Jul 1999 04:23:01 -0000 X-Sender: tecnico@mail.24horas.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" To: (Recipient list suppressed) From: Tecnico Subject: Tecnico a Domicilio Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA01280 Hola, Este mensaje es para poner en vuestro conocimiento la gama de servicios que ofrezco a mis clientes desde hace 10 años, entre los que se destacan: Instalación de: -------------- Discos Rigidos Modem/Fax Placas de Sonido y Video Kits Multimedias CD-Roms (Lectoras y Grabadoras) Placas SCSI Scanners Impresoras Redes Windows 95-98 Office 97-2000 Instalación y actualización de Antivirus Solucion de conflictos de Hardware y detección de fallas Instalación y Mantenimiento de Redes Backup de datos en CD-ROM o discos ZIP Instalación de Software Actualización de Motherboards y Microprocesadores Ampliaciones de Memoria Diseño Integral de WEB SITES (Páginas para Internet) Programación de Aplicaciones Standards y a Medida en Visual Basic 5.0 Programación de Servers en Internet con lenguaje PERL 5.0 Programas Administrativos en Visual Basic de Facturación, control de stock, cuentas corrientes. Programas para Facturación de cuotas sociales, tanto para clubes como para Asociaciones o Cámaras Empresarias. Registracion de dominios www.suempresa.com.ar en Cancillería Copiado de CD-ROMs en pequeñas o grandes cantidades Escaneo de Imagenes Trabajos de Diseño Grafico desde Logotipos, Facturas y Comprobantes, hasta Folletos y Catalogos. Sin otro motivo, y esperando contar con Ud. como uno de mis clientes, lo saludo atentamente. Fabio tecnico@24horas.com From owner-malloc@catarina.usc.edu Tue Jul 13 02:27:41 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA08698 for ; Tue, 13 Jul 1999 02:27:41 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id WAA10219 for malloc-list; Mon, 12 Jul 1999 22:59:31 -0700 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id WAA10215 for ; Mon, 12 Jul 1999 22:59:26 -0700 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA28288 for ; Mon, 12 Jul 1999 22:59:25 -0700 (PDT) Received: from bcn.East.Sun.COM (bcn.East.Sun.COM [129.148.75.4]) by eastmail2.East.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA16495 for ; Tue, 13 Jul 1999 01:59:22 -0400 (EDT) Received: from bcn.East.Sun.COM (euroapp.Holland.Sun.COM [129.159.197.58]) by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with ESMTP id BAA11247 for ; Tue, 13 Jul 1999 01:59:22 -0400 (EDT) From: Steve Hanna Message-Id: <199907130559.BAA11247@bcn.East.Sun.COM> Date: Tue, 13 Jul 1999 14:01:29 +0-200 To: Reply-To: Subject: AAP discussion topics X-Mailer: Sun NetMail 2.2.5 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit For Thursday's MALLOC meeting, we have scheduled time for "AAP Discussion" Here is a list of topics I would like to cover. I would like to settle these 'big-picture' topics first. We can work out minor changes to packet formats and such later. If there are other 'big-picture' topics that we should discuss, please let me know. Also, feel free to discuss these topics and others on the list as well. Especially those who weren't able to make it to Oslo. Thanks, Steve P.S. This discussion pertains to draft-ietf-malloc-aap-01.txt. ------------------ * Should we include failover support in AAP? If so, what form should it take. By failover, I mean the ability to have one MAAS fail and have another take over seamlessly (able to extend leases allocated by the first, etc.). I suggest that we not include failover support in the current version of AAP. Doing failover will require sending per-lease information from each server to one or more backup servers, ensuring that the backup servers know when the primary server goes offline (and that the primary server knows if communications to the backup servers is lost), ensuring that the primary and backup servers operate in a safe mode while communications are down (since they might both still be operating, but with a network partition), and resynchronizing when communications are reestablished. Adding all of these features to AAP will take a good deal of time and delay the standardization of an important protocol. For now, MAAS's that need to implement failover can do so using other techniques (such as proprietary failover protocols). Eventually, we can come back and standardize a MAAS failover protocol, basing it on AAP if we like. This approach is analogous to the DHCP approach: standardize the base protocol, then develop failover support later. Even without failover support, we can still prevent allocation clashes in the face of network partition by having AAP servers defend each others' allocations. This is described in the current spec. * Do we need to provide support for MADCAP's Server Mobility in the current AAP spec? Providing support for Server Mobility will require support quite similar to that required for failover. MAAS's will need to communicate per-lease information to each other, ensure consistency among each other, detect loss of communication, and have a fail-safe mode that they enter when communication is lost, to ensure that they do not cause clashes. Again, I suggest that we omit this support at this time. Adding it will add a lot of complexity to AAP and slow down its development. For now, Server Mobility should be supported via other techniques (such as proprietary protocols). Later, a standard protocol for this purpose can be developed. * How can we best use preallocation to support our architecture? Preallocation can be used to improve timeliness and efficiency of MAAS operation, as well as providing safe operation during network partition. I'll give a more detailed explanation during the AAP discussion on Thursday. From owner-malloc@catarina.usc.edu Wed Jul 14 15:57:50 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14412 for ; Wed, 14 Jul 1999 15:57:49 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id MAA17688 for malloc-list; Wed, 14 Jul 1999 12:10:24 -0700 Received: from hotmail.com (law-f67.hotmail.com [209.185.131.130]) by catarina.usc.edu (8.6.10/8.6.9) with SMTP id MAA17684 for ; Wed, 14 Jul 1999 12:10:19 -0700 Received: (qmail 62266 invoked by uid 0); 14 Jul 1999 19:09:48 -0000 Message-ID: <19990714190948.62265.qmail@hotmail.com> Received: from 128.39.28.73 by www.hotmail.com with HTTP; Wed, 14 Jul 1999 12:09:47 PDT X-Originating-IP: [128.39.28.73] From: "Christian JACQUENET" To: malloc@catarina.usc.edu Subject: GLOP meaning ? Date: Wed, 14 Jul 1999 12:09:47 PDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-malloc@catarina.usc.edu Precedence: bulk Hello there, Can anybody tell me what is the meaning of the "GLOP" acronym ? Many thanx in advance, Christian. ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-malloc@catarina.usc.edu Wed Jul 14 17:01:04 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14888 for ; Wed, 14 Jul 1999 17:01:03 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA18031 for malloc-list; Wed, 14 Jul 1999 13:22:24 -0700 Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id NAA18027 for ; Wed, 14 Jul 1999 13:22:19 -0700 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 84EB04CE2F; Wed, 14 Jul 1999 16:22:18 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id QAA21349; Wed, 14 Jul 1999 16:22:18 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id NAA19359; Wed, 14 Jul 1999 13:22:17 -0700 (PDT) Message-Id: <199907142022.NAA19359@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: deguello@hotmail.com Subject: Re: GLOP meaning ? Cc: malloc@catarina.usc.edu Date: Wed, 14 Jul 1999 13:22:16 -0700 Versions: dmail (solaris) 2.2c/makemail 2.8t Sender: owner-malloc@catarina.usc.edu Precedence: bulk It stands for draft-ietf-mboned-static-allocation-00.txt . Bill From owner-malloc@catarina.usc.edu Wed Jul 14 21:28:19 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA16509 for ; Wed, 14 Jul 1999 21:28:18 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id SAA18946 for malloc-list; Wed, 14 Jul 1999 18:09:54 -0700 Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id SAA18942 for ; Wed, 14 Jul 1999 18:09:48 -0700 Received: from rumi (localhost [127.0.0.1]) by rumi.usc.edu (8.8.5/8.6.9) with ESMTP id SAA15864 for ; Wed, 14 Jul 1999 18:09:47 -0700 (PDT) Message-Id: <199907150109.SAA15864@rumi.usc.edu> To: malloc@catarina.usc.edu Subject: MASC draft update Date: Wed, 14 Jul 1999 18:09:47 -0700 From: Pavlin Ivanov Radoslavov Sender: owner-malloc@catarina.usc.edu Precedence: bulk I just submitted an update of the MASC I-D. In the mean time (until it appears on the ftp servers), you can get a copy of it from MASC homepage: http://netweb.usc.edu/masc/ The major changes/updates are: o MASC Domain ID changed from 16 to 32 bits o No Appropriate Parent Prefix, No Appropriate Child Prefix, No Appropriate Internal Prefix, and No Appropriate Sibling Prefix Error Subcodes added to UPDATE Message Errors o UPDATE Message Processing refined o UPDATE Messages Ordering subsection added o Bootup Operations, Leaf MASC Domain Operation, Clock Skew Workaround subsections added (all in Operational Consideration section) o Security Considerations section updated o APPENDIX A (Sample Algorithms) written Please send your comments to the ML. Thanks, Pavlin From owner-malloc@catarina.usc.edu Sun Jul 18 10:21:24 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22790 for ; Sun, 18 Jul 1999 10:21:24 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id HAA04489 for malloc-list; Sun, 18 Jul 1999 07:04:48 -0700 Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id HAA04485 for ; Sun, 18 Jul 1999 07:04:41 -0700 Received: from dumbo.fokus.gmd.de (dumbo [193.175.132.239]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id QAA12675; Sun, 18 Jul 1999 16:04:34 +0200 (MET DST) From: Mikhail Smirnov Received: (mis@localhost) by dumbo.fokus.gmd.de (SMI-8.6/8.6.12) id QAA03126; Sun, 18 Jul 1999 16:04:32 +0200 Date: Sun, 18 Jul 1999 16:04:32 +0200 Message-Id: <199907181404.QAA03126@dumbo.fokus.gmd.de > To: malloc@catarina.usc.edu Subject: Roles config. in MASC Cc: smirnow@fokus.gmd.de X-Sun-Charset: US-ASCII Sender: owner-malloc@catarina.usc.edu Precedence: bulk Hi, it is not clear for me how roles should be configured in MASC nodes: per interface or just a single role per MASC node? From 7.2 (OPEN msg format) saying: My Role (Rol): The proposed relationship of the sending system to the receiving system and from 7.3 (UPDATE) saying Rol: The relationship/role of the Origin of the message to the node sending that message I can conclude that roles might be configured per interface. However from Table 1 (11.1) it seems that there is a single role per MASC node. Thanks in advance for your comments Michael From owner-malloc@catarina.usc.edu Sun Jul 18 10:32:54 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22876 for ; Sun, 18 Jul 1999 10:32:54 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id HAA04527 for malloc-list; Sun, 18 Jul 1999 07:13:40 -0700 Received: from lizzard.roonet.com.au ([203.58.57.31]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id HAA04522; Sun, 18 Jul 1999 07:13:34 -0700 Message-Id: <199907181413.HAA04522@catarina.usc.edu> Received: from oppi ([38.26.242.22]) by lizzard.roonet.com.au (Post.Office MTA v3.0 release 0122 ID# 0-41017U100L2S100) with ESMTP id AAA315; Sun, 18 Jul 1999 23:22:27 +0930 From: "Paul" Subject: IMPORTANTE To: arlist9349k@catarina.usc.edu X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3 Mime-Version: 1.0 Date: Sun, 18 Jul 1999 08:57:08 -0500 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA22876 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* BASES DE DATOS EN CD-ROM PARA MARKETING POR EMAIL *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 20.000 Emails Argentinos $ 99 50.000 Emails Argentinos $ 200 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > Informacion Incluida: Email, Nombre, Empresa y Rubro > Formatos Disponibles: Excel, Access, Dbase, Texto *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* ENVIO DE EMAILS DESDE NUESTRO SERVIDOR EN FORMA AUTOMATICA: Por 10.000 Envios = $ 99 Por 20.000 Envios = $ 199 Por 30.000 Envios = $ 299 Por 40.000 Envios = $ 399 Por 50.000 Envios = $ 499 Consulte por mas de 50.000 envios *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* INTER-MARKETING GROUP ARGENTINA Gallo 1527 Piso 2 Tel: 4825-1115 Fax: 4825-1117 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Los Precios no Incluyen el IVA Oferta Valida hasta el 30/10/99 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* REMOVE AT mailto:deleteme72@yahoo.com?subject=remove From owner-malloc@catarina.usc.edu Sun Jul 18 14:25:00 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23733 for ; Sun, 18 Jul 1999 14:25:00 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id LAA05089 for malloc-list; Sun, 18 Jul 1999 11:09:44 -0700 Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id LAA05085; Sun, 18 Jul 1999 11:09:32 -0700 Received: from rumi (localhost [127.0.0.1]) by rumi.usc.edu (8.8.5/8.6.9) with ESMTP id LAA25942; Sun, 18 Jul 1999 11:09:18 -0700 (PDT) Message-Id: <199907181809.LAA25942@rumi.usc.edu> To: Mikhail Smirnov cc: malloc@catarina.usc.edu Subject: Re: Roles config. in MASC In-reply-to: Your message of "Sun, 18 Jul 1999 16:04:32 +0200." <199907181404.QAA03126@dumbo.fokus.gmd.de > Date: Sun, 18 Jul 1999 11:09:18 -0700 From: Pavlin Ivanov Radoslavov Sender: owner-malloc@catarina.usc.edu Precedence: bulk > it is not clear for me how roles should be configured in MASC nodes: > per interface or just a single role per MASC node? > > >From 7.2 (OPEN msg format) saying: > > My Role (Rol): > The proposed relationship of the sending system to the receiving > system > > and from 7.3 (UPDATE) saying > > Rol: > The relationship/role of the Origin of the message to the node > sending that message > > I can conclude that roles might be configured per interface. > However from Table 1 (11.1) it seems that there is a single role > per MASC node. The Role is "per Open (TCP) connection". Will make this clearer in the next revision. Thanks, Pavlin From owner-malloc@catarina.usc.edu Sun Jul 18 14:28:48 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23761 for ; Sun, 18 Jul 1999 14:28:47 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id LAA05118 for malloc-list; Sun, 18 Jul 1999 11:14:23 -0700 Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id LAA05114; Sun, 18 Jul 1999 11:14:14 -0700 Received: from dumbo.fokus.gmd.de (dumbo [193.175.132.239]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id UAA17220; Sun, 18 Jul 1999 20:14:12 +0200 (MET DST) From: Mikhail Smirnov Received: (mis@localhost) by dumbo.fokus.gmd.de (SMI-8.6/8.6.12) id UAA03220; Sun, 18 Jul 1999 20:14:09 +0200 Date: Sun, 18 Jul 1999 20:14:09 +0200 Message-Id: <199907181814.UAA03220@dumbo.fokus.gmd.de > To: pavlin@catarina.usc.edu Subject: Re: Roles config. in MASC Cc: malloc@catarina.usc.edu, smirnow@fokus.gmd.de X-Sun-Charset: US-ASCII Sender: owner-malloc@catarina.usc.edu Precedence: bulk Pavlin, thanks for your fast reply - > The Role is "per Open (TCP) connection". > Will make this clearer in the next revision. regards Michael From owner-malloc@catarina.usc.edu Mon Jul 19 08:06:45 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA16142 for ; Mon, 19 Jul 1999 08:06:44 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id EAA08014 for malloc-list; Mon, 19 Jul 1999 04:30:40 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id EAA08010 for ; Mon, 19 Jul 1999 04:30:35 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14014; Mon, 19 Jul 1999 07:30:00 -0400 (EDT) Message-Id: <199907191130.HAA14014@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: malloc@catarina.usc.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-malloc-masc-02.txt Date: Mon, 19 Jul 1999 07:29:59 -0400 Sender: owner-malloc@catarina.usc.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multicast-Address Allocation Working Group of the IETF. Title : The Multicast Address-Set Claim (MASC) Protocol Author(s) : D. Estrin, R. Govindan, M. Handley, S. Kumar, P. Radoslavov, D. Thaler Filename : draft-ietf-malloc-masc-02.txt Pages : 59 Date : 15-Jul-99 This document describes MASC, a protocol for inter-domain multicast address set allocation. The MASC protocol is used by a node (typically a router) to claim and allocate one or more address prefixes to that node's domain. Each prefix has an associated lifetime, and is chosen out of a larger prefix with a lifetime at least as long, in a manner such that prefixes are aggregatable. At any time, each MASC node will typically advertise several prefixes with different lifetimes and scopes, allowing Multicast Address Allocation Servers (MAAS's) in that domain or child MASC domains to choose appropriate addresses for their clients. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-malloc-masc-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-malloc-masc-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-malloc-masc-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990715080439.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-malloc-masc-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-malloc-masc-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990715080439.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-malloc@catarina.usc.edu Mon Jul 19 17:06:14 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02782 for ; Mon, 19 Jul 1999 17:06:13 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA10237 for malloc-list; Mon, 19 Jul 1999 13:19:47 -0700 Received: from dthaler.microsoft.com ([131.107.1.30]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id NAA10223 for ; Mon, 19 Jul 1999 13:19:42 -0700 Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id PAA03528; Mon, 19 Jul 1999 15:00:05 -0700 (PDT) (envelope-from dthaler) From: Dave Thaler Message-Id: <199907192200.PAA03528@dthaler.microsoft.com> Subject: Re: Roles config. in MASC In-Reply-To: <199907181404.QAA03126@dumbo.fokus.gmd.de > from Mikhail Smirnov at "Jul 18, 1999 4: 4:32 pm" To: smirnow@fokus.gmd.de (Mikhail Smirnov) Date: Mon, 19 Jul 1999 15:00:05 -0700 (PDT) Cc: malloc@catarina.usc.edu, smirnow@fokus.gmd.de X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit > it is not clear for me how roles should be configured in MASC nodes: > per interface or just a single role per MASC node? Neither, it's peer peering. Interfaces are not relevant to a MASC node. -Dave From owner-malloc@catarina.usc.edu Mon Jul 19 17:12:02 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02869 for ; Mon, 19 Jul 1999 17:12:01 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA10384 for malloc-list; Mon, 19 Jul 1999 13:37:43 -0700 Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id NAA10380 for ; Mon, 19 Jul 1999 13:37:37 -0700 Received: from dumbo.fokus.gmd.de (dumbo [193.175.132.239]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id WAA23245; Mon, 19 Jul 1999 22:37:33 +0200 (MET DST) From: Mikhail Smirnov Received: (mis@localhost) by dumbo.fokus.gmd.de (SMI-8.6/8.6.12) id WAA03893; Mon, 19 Jul 1999 22:37:29 +0200 Date: Mon, 19 Jul 1999 22:37:29 +0200 Message-Id: <199907192037.WAA03893@dumbo.fokus.gmd.de > To: dthaler@dthaler.microsoft.com Subject: Re: Roles config. in MASC Cc: malloc@catarina.usc.edu, smirnow@fokus.gmd.de X-Sun-Charset: US-ASCII Sender: owner-malloc@catarina.usc.edu Precedence: bulk Hi, > > it is not clear for me how roles should be configured in MASC nodes: > > per interface or just a single role per MASC node? > > Neither, it's peer peering. Interfaces are not relevant to > a MASC node. OK, Pavlin said that roles are per open TCP connections (I called them "interfaces"). From the MASC Topology example [ietf-42-masc-update.ps] and other drawings it's clear that a MASC node could participate in more than one TCP connection at a time, right? From section 11.1 [masc-02] it looks like a node can receive on a connection for which it's locally configured as "internal peer" an UPDATE message with *any* Orgin Role (1st column of Table 1). Is this what you call peer peering? Thanks in advance Michael From owner-malloc@catarina.usc.edu Mon Jul 19 18:35:03 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03965 for ; Mon, 19 Jul 1999 18:35:02 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id OAA10726 for malloc-list; Mon, 19 Jul 1999 14:26:28 -0700 Received: from dthaler.microsoft.com ([131.107.1.30]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id OAA10722 for ; Mon, 19 Jul 1999 14:26:22 -0700 Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id QAA03647; Mon, 19 Jul 1999 16:06:37 -0700 (PDT) (envelope-from dthaler) From: Dave Thaler Message-Id: <199907192306.QAA03647@dthaler.microsoft.com> Subject: Re: Roles config. in MASC In-Reply-To: <199907192037.WAA03893@dumbo.fokus.gmd.de > from Mikhail Smirnov at "Jul 19, 1999 10:37:29 pm" To: smirnow@fokus.gmd.de (Mikhail Smirnov) Date: Mon, 19 Jul 1999 16:06:37 -0700 (PDT) Cc: dthaler@dthaler.microsoft.com, malloc@catarina.usc.edu, smirnow@fokus.gmd.de X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > > it is not clear for me how roles should be configured in MASC nodes: > > > per interface or just a single role per MASC node? > > > > Neither, it's peer peering. Interfaces are not relevant to typo: ^ delete extra e > > a MASC node. "per peering" > OK, Pavlin said that roles are per open TCP connections (I called them > "interfaces"). From the MASC Topology example [ietf-42-masc-update.ps] Roles are configured per peering ( = a TCP connection regardless of whether it's currently open or not ). > and other drawings it's clear that a MASC node could participate in more > than one TCP connection at a time, right? Right. > From section 11.1 [masc-02] it looks like a node can receive on a > connection for which it's locally configured as "internal peer" an UPDATE > message with *any* Orgin Role (1st column of Table 1). Yes. > Is this what you call peer peering? No. Everyone you have a potential connection to is called a "peer" (whether internal or external, and whether parent, child, or sibling). A peer just means someone you talk to. Maybe it's a bad term, but it's the same term used in BGP and other related protocols. -Dave From owner-malloc@catarina.usc.edu Mon Jul 19 18:48:28 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04060 for ; Mon, 19 Jul 1999 18:48:27 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id OAA10794 for malloc-list; Mon, 19 Jul 1999 14:42:32 -0700 Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id OAA10790 for ; Mon, 19 Jul 1999 14:42:26 -0700 Received: from dumbo.fokus.gmd.de (dumbo [193.175.132.239]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id XAA25385; Mon, 19 Jul 1999 23:42:04 +0200 (MET DST) From: Mikhail Smirnov Received: (mis@localhost) by dumbo.fokus.gmd.de (SMI-8.6/8.6.12) id XAA03916; Mon, 19 Jul 1999 23:41:59 +0200 Date: Mon, 19 Jul 1999 23:41:59 +0200 Message-Id: <199907192141.XAA03916@dumbo.fokus.gmd.de > To: dthaler@dthaler.microsoft.com Subject: Re: Roles config. in MASC Cc: malloc@catarina.usc.edu, smirnow@fokus.gmd.de X-Sun-Charset: US-ASCII Sender: owner-malloc@catarina.usc.edu Precedence: bulk OK, thanks a lot, > ... Everyone you have a potential connection to is called a "peer" > (whether internal or external, and whether parent, child, or sibling). > A peer just means someone you talk to. Maybe it's a bad term, > but it's the same term used in BGP and other related protocols. it is a bad term esp. for MASC where you define a role "internal-peer". You better then say that there are roles 1. internal peer 2. external peer further subdivided 2.1 child 2.2 parent 2.3 sibling or use "MASC connection" instead of peering (you have already "MASC topology"). It'll be also useful to know HOW a local node decides which role it is now in for this particular connection? Regards Michael From owner-malloc@catarina.usc.edu Mon Jul 19 19:25:55 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04377 for ; Mon, 19 Jul 1999 19:25:54 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id PAA11398 for malloc-list; Mon, 19 Jul 1999 15:57:26 -0700 Received: from dthaler.microsoft.com ([131.107.1.30]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id PAA11394 for ; Mon, 19 Jul 1999 15:57:21 -0700 Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id RAA03757; Mon, 19 Jul 1999 17:37:54 -0700 (PDT) (envelope-from dthaler) From: Dave Thaler Message-Id: <199907200037.RAA03757@dthaler.microsoft.com> Subject: Re: Roles config. in MASC In-Reply-To: <199907192141.XAA03916@dumbo.fokus.gmd.de > from Mikhail Smirnov at "Jul 19, 1999 11:41:59 pm" To: smirnow@fokus.gmd.de (Mikhail Smirnov) Date: Mon, 19 Jul 1999 17:37:53 -0700 (PDT) Cc: dthaler@dthaler.microsoft.com, malloc@catarina.usc.edu, smirnow@fokus.gmd.de X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit > It'll be also useful to know HOW a local node decides which role it is > now in for this particular connection? Configuration. It's not something that changes... it generally would match a contractual relationship, and as such is not something you want to be guessed at by an implementation. You want to make sure it's following the right policy, and so manual configuration here is a good thing. -Dave From owner-malloc@catarina.usc.edu Mon Jul 19 20:45:02 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05008 for ; Mon, 19 Jul 1999 20:45:01 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id RAA11816 for malloc-list; Mon, 19 Jul 1999 17:27:35 -0700 Received: from relay.sion.com (root@[200.43.36.4]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id RAA11812 for ; Mon, 19 Jul 1999 17:27:28 -0700 Received: from mail.sion.com (sion.com [209.14.106.3]) by relay.sion.com (8.9.3/8.9.3) with SMTP id VAA12127 for ; Mon, 19 Jul 1999 21:29:43 -0300 Message-Id: <199907200029.VAA12127@relay.sion.com> Received: from [200.42.27.68] by sion.com id 9ab40.wrk; Mon, 19 Jul 1999 19:22:16 EDT From: INTERNATIONAL PHONE To: INTERNET TELEPHONY Date: Mon, 19 Jul 1999 19:28:23 -0300 Subject: TELEFONIA VIA INTERNET Reply-To: international-phone@excite.com Organization: INTERNATIONAL PHONE MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Priority: 3 X-MIME-Autoconverted: from 8bit to quoted-printable by relay.sion.com id VAA12127 Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA05008 INTERNATIONAL PHONE international-phone@excite.com phone: 54-(011) 786-1857 lunes a viernes de 10 a 18 hs. ======================================================= PRESENTACION DE PRODUCTO INTERNET LINE JACK Diseñado para ser usado por empresas No importa el tamaño de su organización , utilizando una conexión a Internet , el Internet LineJACK convierte a su línea telefónica en una central telefonica de llamados GRATIS de larga distancia. · Conecte la red publica local de telefonia para realizar llamadas de voz a través de Internet · Realice teleconferencias de tres vias, entre llamadas en su red de telefonia local y llamdas de voz por Internet · Conecte el Internet LineJack directamente a su central telefónica y convierta a su conexión global de telefonia en un interno mas de su central telefónica. · Integración directa de servicos tales como, microsoft NetMeeting, ICQ, IDT Net2Phone y VocalTec Internet Phone · Instalacion Plug-and-Play para Window 95/98 · Diseñado con cancelación de eco automática · Provisto con protocolo H.323 de compresión y descompresión de audio El LineJACK es una interface abierta que permite conectar su línea local de teléfono, de la companias de telefonía publica a una dirección IP, lo que en la practica significa conectar su línea y su aparato standard de teléfono a una red de computadoras que bien podría ser Internet o su propia Intranet Al mismo tiempo el LineJACK permite conectar su central telefónica, es decir todos los internos y líneas externas a una dirección IP, por lo que la combinación de dos LineJACK en diferentes sitios con diferentes IP, (sin importar la distancia), permitirán utilizar ambas centrales telefónicas como una sola, pudiendo establecer comunicaciones entre internos y líneas externas indistintamente y con independencia de su ubicación geográfica LineJACK es diferente a otras interfaces porque: · Fue diseñado específicamente para aplicaciones de baja densidad (compresión 1-8) · Con un muy bajo costo puede entregar las mismas prestaciones que placas muy caras de Dialogic o Lucent · Es una placa standard y se utiliza en equipos standard · El LineJACK no es una tarjeta con tecnologías propietarias El LineJACK es ideal para usted sí... .. esta buscando una interface (gateway) para una línea telefónica, ya sea en su casa o en su oficina .. desea interactuar en forma remota desde una conexión de Internet con su central telefónica .. desea dar un acceso internacional a su central telefónica de ventas .. O si desea iniciarse en el negocio de los servicios telefónicos sobre IP Características y Beneficios del LineJACK · Llamadas de calidad sobre Internet o una línea de teléfono local · Utiliza aparatos telefónicos standard · Interactua con cualquier central telefónica · Utiliza un teléfono normal y su central telefónica (PBX), para recibir y generar llamado telefónicos sobre Internet · Puede hacer llamados PC a PC ,Teléfono a PC ,PC a teléfono y utilizar las aplicaciones más comunes de telefonía sobre Internet como IDT Net2Phone o Vocaltec o Microsoft NetMeeting. Utilizando una LineJACK usted puede administrar desde un simple teléfono, todas sus llamadas sean de telefonía local, larga distancia o sobre Internet Usted puede llamar a otros teléfonos, a gente usando PC sobre Internet, o usar Internet para reducir sus costos de telefonía de larga distancia llamando a través de Internet a companias que realice él ultimo tramo del llamado cerca del destino (ITSP) con tarifas realmente reducidas Utilizando el LineJACK los llamados son realizados en forma natural, es decir discando sobre los números del aparato y escuchando la campanilla al recibir. Usted lograra increíbles performance al utilizar una LineJACK integrándola con otros servicios y software de comunicaciones, como videoconferencia. Incremente su calidad de llamados sobre Internet · Hardware construido con cancelación de eco · Full-duplex, parlante y micrófono · Soporta toda clase de aparato telefónico, y centrales telefónicas La mayor parte del software para telefonía sobre Internet utiliza su tarjeta de sonido. Estas tarjetas no fueron diseñadas para conversaciones telefónicas en ambos sentidos, full-duplex, y por ese motivo las comunicaciones se parecen a las realizadas con equipos de radiofrecuencia pues ambas partes no pueden hablas al mismo tiempo, es decir no se puede hablar y escuchar a la vez. El LineJACK provee de cancelación de eco en ambas direcciones y audio de 16 bits por lo que logra una calidad optima para telefonía sobre Internet Conferencias de 3 vías entre la red de telefonía local (PSTN) e Internet El LineJACK le permite realizar conferencias tripartitas, ya sea entre llamadas de telefonía sobre Internet, llamadas de telefonía de la red publica o bien desde diferentes internos de su central, por lo que las teleconferencias de larga distancias se podrán realizar al costo de una comunicación local · Fácil de instalar · Es Plug and play · Reconoce sí su PC esta apagada para no interferir en la llamada de telefonía local · Trabaja independiente de la tarjeta de sonido · No debe modificar el IRQ de su PC en la tarjeta · Es compatible con Internet SwitchBoard · Esta diseñado para una rápida instalación sobre Windows 95/98 ============================================================== Para más información contáctese con nuestros ejecutivos de cuenta al (011) 4786-1857 y será para nosotros un placer ofrecerle una demostración gratuita. INTERNATIONAL PHONE Depto. de ventas SOLICITE INFORMES A ip-ar@excite.com SI LO DESEA ESPECIFIQUE SUS NECESIDADES ACTUALES EN MATERIA DE COMUNICACION Y LE HAREMOS UN PROYECTO SOBRE LAS MISMAS. Tel : (011) 4 786-1857 Sus datos fueron obtenidos de bases publicas de diversas fuentes. Si usted no desea volver a recibir información de productos novedosos por favor responda este mail a no_e_mail@excite.com y será eliminado automáticamente de nuestra base de datos. ------------------------------------------ This message was sent to you by Name: INTERNATIONAL PHONE Email Address: ip@excite.com IP Address: host027068.ciudad.com.ar ------------------------------------------ Using Aureate Group Mail Free Edition Find out more about this product and try it for free at: http://www.group-mail.com/ From owner-malloc@catarina.usc.edu Tue Jul 20 00:02:42 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA08628 for ; Tue, 20 Jul 1999 00:02:41 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id UAA12501 for malloc-list; Mon, 19 Jul 1999 20:34:42 -0700 Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id UAA12497; Mon, 19 Jul 1999 20:34:36 -0700 Received: from rumi (localhost [127.0.0.1]) by rumi.usc.edu (8.8.5/8.6.9) with ESMTP id UAA28615; Mon, 19 Jul 1999 20:34:35 -0700 (PDT) Message-Id: <199907200334.UAA28615@rumi.usc.edu> To: Dave Thaler cc: malloc@catarina.usc.edu Subject: Re: WG Last Call on Abstract API In-reply-to: Your message of "Mon, 05 Jul 1999 13:28:57 PDT." <199907052028.NAA10496@dthaler.microsoft.com> Date: Mon, 19 Jul 1999 20:34:35 -0700 From: Pavlin Ivanov Radoslavov Sender: owner-malloc@catarina.usc.edu Precedence: bulk > As a reminder, one of our WG goals is: > > Jul 99 Submit the abstract API document(s0 to the IESG for consideration > as Informational. > > > This message starts a WG last call on the Abstract API draft: > draft-ietf-malloc-api-06.txt > The last call will expire in 3 weeks. Please send comments > by July 26th. Some minor comments follow (comments are starting with "*****") Section 3: "Note that this interface is intended only for the allocation of dynamic multicast addresses, as used by the normal multicast service model [2]...." ****** "traditional" is probably a better word than "normal" Section 4: "- Time: An (absolute) event time...." ***** Shouldn't the "absolute time" be defined here as "number of seconds from Jan. 1970", or this will be specified in the concrete API? Section 5: "A "best-effort" attempt will be made to maintain multicast routing for the allocated multicast addresses during their lifetime, even if there are topology changes (such as a change of upstream provider) during this time..." ***** This sentence seems a little bit odd to me that it has to be in the API document. It is more like to belong to the malloc architecture document. "...However, because of the guarantee noted above, if an application needs to 'renumber', it will always know this in advance, at the time it acquired its current address(es)." ***** How would the application know? If the Lease Lifetime is shorter than the maxDesiredLifetime? Please explain in the text. Also, even if Lease Lifetime is shorter, later the application might succeed to extend the Lease Lifetime, so replace "needs" with something like "MIGHT need". "...Without advance allocation, it would be necessary to reserve an address for a long period of time - even when it will not be used..." ***** "reserve" should be replaced with "allocate". ***** On some ocasions the doc uses the term "multicast address", when it should use "multicast addressES" ***** The whole document needs some formatting to avoid things like single-word lines. ***** Should the document mention something like: "...because the allocation is "best effort", and does not guarantee that the same multicast address is not used by another application, an application that needs an additional "protection" against another application using and sending data to the same address should use an application-specific mechanism to discover such interference and filter out the unwanted data..." (well, by default any application should have the same property/protection ;) Thanks, Pavlin From owner-malloc@catarina.usc.edu Tue Jul 20 20:04:32 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13237 for ; Tue, 20 Jul 1999 20:04:32 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id QAA17290 for malloc-list; Tue, 20 Jul 1999 16:39:57 -0700 Received: (from pavlin@localhost) by catarina.usc.edu (8.6.10/8.6.9) id QAA17285 for malloc@catarina.usc.edu; Tue, 20 Jul 1999 16:39:54 -0700 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id QAA17264 for ; Tue, 20 Jul 1999 16:39:07 -0700 From: pavlin@isi.edu Received: from fra.isi.edu (fra-e.isi.edu [128.9.160.58]) by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id QAA14265 for ; Tue, 20 Jul 1999 16:39:06 -0700 (PDT) Date: Tue, 20 Jul 1999 16:39:26 -0700 Posted-Date: Tue, 20 Jul 1999 16:39:26 -0700 Message-Id: <199907202339.AA17756@fra.isi.edu> Received: by fra.isi.edu (5.65c/4.0.3-6) id ; Tue, 20 Jul 1999 16:39:26 -0700 To: malloc@catarina.usc.edu Subject: Email to malloc@catarina restricted to list members Sender: owner-malloc@catarina.usc.edu Precedence: bulk Because of the large amount of spam email sent to the ML, the posting now is restricted only to list members. All email by non-list members will go to the ML administrator (i.e. me) for approval. What does it mean? * No more spam to the ML (unless the spammer somehow successfully subscribes to the ML first ;) * If you are not-subscribed (and somehow are reading this ;), your email will be delayed until I approve it * If you are subscriber to the ML, but are sending from a different account and/or somehow your "From" address is different from the address majordomo has, then your email to the list will be delayed intil I approve it (hopefully this will be rare) * I still get all the spam ;) Any ideas/hints how to deal better with the problem are welcome. Thanks, Pavlin P.S. Sent from my non-subscriber account, and then approved P.P.S. This policy affects only malloc@catarina; other MLs on catarina are not affected From owner-malloc@catarina.usc.edu Fri Jul 23 17:16:30 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12507 for ; Fri, 23 Jul 1999 17:16:29 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA06309 for malloc-list; Fri, 23 Jul 1999 13:21:16 -0700 Received: (from pavlin@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA06303 for malloc@catarina.usc.edu; Fri, 23 Jul 1999 13:21:12 -0700 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id KAA05234 for ; Fri, 23 Jul 1999 10:16:28 -0700 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA24025 for ; Fri, 23 Jul 1999 10:16:20 -0700 (PDT) Received: from bcn.East.Sun.COM (bcn.East.Sun.COM [129.148.75.4]) by eastmail2.East.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA28326 for ; Fri, 23 Jul 1999 13:16:17 -0400 (EDT) Received: from sun.com (dhcp75-155 [129.148.75.155]) by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with ESMTP id NAA15753 for ; Fri, 23 Jul 1999 13:16:19 -0400 (EDT) Message-ID: <3798A283.C9CF5F9C@sun.com> Date: Fri, 23 Jul 1999 13:12:35 -0400 From: Steve Hanna Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: malloc Subject: Draft minutes for MALLOC @ IETF 45 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Here are draft minutes for the MALLOC session at IETF 45. Please look them over and get any comments back to me by 4 PM Monday, July 26. Thanks to Bob Quinn for taking very thorough notes! Thanks, Steve --------------- Minutes of MALLOC Working Group IETF 45 (Oslo, Norway) Thursday, July 15, 1999 Minutes reported by R. Quinn and S. Hanna. Agenda: Agenda Bashing Hanna Introduction & Document Status Hanna Architecture Document Update Thaler Static IPv4 Allocation Meyer Static IPv6 Allocation Haberman MASC Update Thaler MADCAP Update Hanna AAP Discussion Hanna MALLOC MIB Thaler I. Introduction and Document Status Steve Hanna gave an overview of the MALLOC architecture. Then he provided an update on MALLOC document status: - Architecture doc: Recently updated and in WG discussion - MADCAP doc: In IESG Review (near completion) - AAP doc: In WG Discussion - MASC doc: In WG Discussion (recently updated) - Scope Nesting doc: New revision coming soon - Abstract API doc: In WG Last Call - MALLOC MIB doc: In WG Discussion - Static Allocation: moved out of MALLOC into MBONED Most documents should be able to go to IESG by August. AAP will probably be later. MIB will have to wait for AAP. II. Architecture document update Dave Thaler described the changes in the latest version of the MALLOC architecture document (draft-ietf-malloc-arch-02.txt). The latest draft is more abstract. It removes focus on specific protocol details (MADCAP, AAP and MASC) and now references roles, which can also apply to alternative proposals (like static allocation). A party that announces addresses available within a domain is now known as a "prefix coordinator" instead of a "MASC server," for instance. Also, Dave has proposed that "large" scopes (which contain multiple allocation domains) now be called "divisible" and "small" scopes (which have a single allocation domain) now be called "indivisible." This idea was received with mixed emotions. Dave proposed a 2 week working group last call for this document beginning July 23. There was general agreement. III. IPv4 Static Allocation Dave Meyer described the current status of the IPv4 multicast address static allocation method described in draft-ietf-mboned-static-allocation-00.txt. The IANA just assigned the reserved multicast address range 233/8 for this proposal. These addresses are already being used by many ISPs. There are many calculators available for converting an AS number into static multicast address assignments and vice versa. See http://gigapop.uoregon.edu/glop Mark Handley asked how the MALLOC architecture would handle an AS (with a static allocation) that is larger than an allocation domain. It was agreed that you could use MASC or static configuration to break up the static allocation across multiple allocation domains. Mark agreed to help Dave Thaler add this to the Architecture document. IV. Allocation of Multicast Addresses in IPv6 Brian Haberman described the IPv6 multicast address static allocation scheme described in draft-haberman-malloc-static-ipv6-alloc-00.txt. An IPv6 multicast address contains a 16 bit prefix (with flags, scope, etc.) and a 112 bit group ID. An IPv6 unicast address contains a 64 bit network prefix and a 64 bit interface ID. The proposal is to statically allocate IPv6 multicast addresses to network prefixes by putting the unicast network prefix at the top of the group ID. This will provide 2^48 groups for each scope, prefix pair. A concern was raised about how often IPv6 unicast network prefixes might change (due to renumbering). If they change too often, this could cause problems for this scheme. The answer was that each prefix has a lifetime and an orderly transition should be done, with several weeks during which the old prefix is deprecated and the new one preferred. This should be OK. One open issue is how best to map IPv6 multicast addresses onto Ethernet multicast addresses. RFC 2373 to use only the low 32 bits of the group ID. It would probably be better to include more bits. Another open issue is which working group this draft should be in. ipng? malloc? This will be discussed with the ADs. V. MASC Update This presentation was prepared by Pavlin Radoslavov. However, Pavlin could not attend so Dave Thaler actually gave the presentation. A new MASC draft was posted today. This draft should be ready for working group Last Call by the end of July and will then be submitted to the IESG for publication as an Experimental RFC. This draft includes several bug fixes and other changes in light of Pavlin's implementation experience and suggestions from others. Here is a description of some of the most important changes: Bootup Operation When a MASC server comes up, it should establish the TCP connection to its parents before its siblings or children. This helps avoid the node learning about its own PREFIX_MANAGED from its siblings or children. Leaf vs. Non-Leaf MASC Domains Leaf and non-leaf MASC domains must behave differently. Leaf domains must advertise all addresses to their own allocation domain. Non-leaf domains must save some for themselves and leave others for their children. Clock Skew Work-around Clock skew can cause problems with MASC. However, these problems can be avoided. First, timestamps are used to resolve claim collisions. Clock skew may result in one node's claims winning unfairly. But this should be rare and is not a big problem. More problematic is the possibility that clock skew may cause claims to be expired prematurely. To avoid this problem, all claims should be held for an extra 24 hours. And claims with clock skew approaching 24 hours should be rejected with an error. Security Considerations When attempting to restore internal state after a reboot, information received from internal peers and parents should be preferred to information received from siblings or children. This prevents siblings or children from providing false state. A denial of service attack (too many collisions) by a single node can be identified by all its siblings, who can ignore that node's claims. A similar attack with multiple origin addresses can be prevented by accepting claims only through the parent. Sample Algorithms Appendix Many simulations that have been performed are described. An open issue was discussed. Currently, siblings with more than one common parent can multiplex all UPDATEs over a single TCP connection. This is too complicated and provides a negligible savings of a few TCP connections. Pavlin suggests opening a new TCP connection for each common pairing. There was general agreement that this sounded like a good idea. Dave Thaler asked whether separate port numbers would be needed for these connections. He will send email to Pavlin. MASC Implementation Status Pavlin has implemented MASC and performed detailed testing, refining, and bug fixing of MASC processing code through simulations. He has also added QUERY/RESPONSE debug messages for debugging. The question arose as to whether these messages should be added to an appendix of the MASC spec. After some discussion, it was agreed that either a MASC MIB should be defined or the messages should be documented. Pavlin is also working on implementing and testing the MASC-AAP interface. It would be helpful to him if someone who already has a MADCAP/AAP implementation could volunteer to do some testing with him. Nobody came forward. Deborah Estrin said that Pavlin has lots of experimental and simulation results. He will publish an Internet Draft on these. VI. MADCAP Update Steve Hanna described the current status of MADCAP. draft-ietf-malloc-madcap-04.txt went to the IESG in March. Since then, several rounds of comments have been received from the ADs. Draft -05 was published in May and draft -06 should be published very soon. After that, the spec should go to Proposed Standard status. The changes in -05 included: - adding an overview and glossary - INFORM now MUST include Option Request List - adding an Error option for NAK Draft -06 will include minor clarifications. Also, the INFORM message will be renamed to GETINFO. VII. AAP Discussion Steve Hanna led a discussion of the AAP protocol. He started off with a protocol overview, then a status update, and finally a discussion of open issues. AAP is designed to fit into the middle tier in three-tier MALLOC architecture (intradomain). It will be used by prefix coordinators to announce addresses available for allocation and by Multicast Address Allocation Servers (MAAS's) to coordinate and ensure that allocations do not conflict. All messages are UDP multicast to scope-relative addresses (in the Allocation Scope for "large" scopes, in the scope being allocated from for "small" scopes). The AAP spec was written by Mark Handley last year. It was based on SAP (the Session Announcement Protocol). Steve Hanna joined as a co-author in March, with high hopes to resolve open issues quickly and move to Last Call by August. However, other things have intervened and little progress has been made as of yet. The last "working draft" has been converted to ASCII and published as draft-ietf-malloc-aap-01.txt in June. Steve is now aiming to for Last Call in December. The protocol overview has been omitted here. See the protocol specification for details. The first open issue was whether to add failover support to AAP. In this context, failover means the ability for one MAAS to take over seamlessly if another one fails (able to renew leases issued by the failed MAAS, etc.). Implementing failover would introduce a lot more complexity: sending per-lease information to backup servers, detecting server failure or network partition, backing off to a safe mode, and resynchronizing to recover. It was generally agreed that we should wait on this for now and just get out a simple AAP spec and get some experience with that. Implementors can use proprietary protocols or other means to address this for now. And we can develop a standard protocol for it later, if need be. This is similar to what the dhc working group did with DHCP. The second open issue was whether to add support for MADCAP Server Mobility to AAP. We aren't sure how to do this at this point without introducing lots of complexity (like failover). We agreed to think about this for a few weeks. If we can't come up with a reasonably simple solution, we'll punt on it for now. VIII. MALLOC MIB Dave Thaler talked about the MALLOC MIB (draft-ietf-malloc-mib-01.txt). The initial MIB instrumented generic MAAS and objects. The WG consensus was that protocol-specific objects should be in the same document, so the MIB was updated in June. It now contains several different conformance groups that different entities will implement depending on which protocols they speak: mallocBasic: all entities mallocClient: clients mallocClientScope: clients (optional) madcapClient: clients that speak MADCAP mallocServer: MAASs madcapServer: MAASs that speak MADCAP aapServer: MAASs that speak AAP aapKeyServer: AAP key advertisers aapRangeServer: Prefix coordinators that speak AAP The MADCAP-specific groups contain various MADCAP config options as specified in MADCAP spec, as well as counters for each error type and counters for each packet type. The AAP-specific groups contain various AAP config options as specified in the AAP spec, as well as a write-only private key configuration entry with appropriate precautions, a read-only public key table, and a trap for when you stop hearing ASA messages. This draft also includes a few other changes. The scope table has been split onto a scope table and an allocation range table to support divisible ("large") scope better. And IPv6 support has been added by making address objects generic. The MIB should wait for all the protocol specs to go Proposed Standard. This means it will need to wait for AAP. However, the protocol documents don't need to wait for the MIB. Brian Haberman asked whether this MIB should use the generic object for IPv4/IPv6 address representation in MIBs that is being developed. Dave said that if this object is done soon enough, we'll use it. Otherwise, we will move ahead with the current proposal. From owner-malloc@catarina.usc.edu Fri Jul 23 18:28:57 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12844 for ; Fri, 23 Jul 1999 18:28:57 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id OAA06754 for malloc-list; Fri, 23 Jul 1999 14:50:29 -0700 Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id OAA06750 for ; Fri, 23 Jul 1999 14:50:23 -0700 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 4428B1E04E; Fri, 23 Jul 1999 17:50:22 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id RAA08148; Fri, 23 Jul 1999 17:50:21 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id OAA03959; Fri, 23 Jul 1999 14:50:20 -0700 (PDT) Message-Id: <199907232150.OAA03959@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: steve.hanna@sun.com Subject: Re: Draft minutes for MALLOC @ IETF 45 Cc: malloc@catarina.usc.edu Date: Fri, 23 Jul 1999 14:50:20 -0700 Versions: dmail (solaris) 2.2c/makemail 2.8t Sender: owner-malloc@catarina.usc.edu Precedence: bulk >One open issue is how best to map IPv6 multicast addresses onto >Ethernet multicast addresses. RFC 2373 to use only the low 32 bits of >the group ID. It would probably be better to include more bits. I think that the open issue is actually how this scheme interacts with the IPv6->ethernet group address mapping, which uses the low 32 bits of the group address. There aren't more bits available in the ethernet group address space, unless we want to redefine the mapping, and there are a max of 14 more bits available even if IPv6 multicast claims the entire "local use" ethernet multicast address space. The concern is more that RFC2373 says that you only use the low 32 bits of the IPv6 multicast address, in order to reduce the number of group address collisions (especially for layer-2 devices doing GMRP or mapped IGMP snooping). If we assign /80's as this proposal suggests, one obvious tendency is to start assigning group addresses starting at .1, meaning that there will be lots of groups using the ethernet group address 33:33:00:00:00:01. One of the suggestions was to hash (e.g. md5) the assigned range and pick 32 bits from the hash and start assigning with that address. This moves towards address allocator policy, though, and it's kind of hard to say exactly how much the group can specify. Bill From owner-malloc@catarina.usc.edu Fri Jul 23 20:21:28 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13861 for ; Fri, 23 Jul 1999 20:21:28 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id QAA07104 for malloc-list; Fri, 23 Jul 1999 16:54:31 -0700 Received: from flipper.cisco.com (flipper.cisco.com [171.69.63.10]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id QAA07100 for ; Fri, 23 Jul 1999 16:54:26 -0700 Received: (dino@localhost) by flipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id QAA18788; Fri, 23 Jul 1999 16:53:50 -0700 (PDT) Date: Fri, 23 Jul 1999 16:53:50 -0700 (PDT) Message-Id: <199907232353.QAA18788@flipper.cisco.com> From: Dino Farinacci To: fenner@research.att.com CC: steve.hanna@sun.com, malloc@catarina.usc.edu In-reply-to: <199907232150.OAA03959@windsor.research.att.com> (message from Bill Fenner on Fri, 23 Jul 1999 14:50:20 -0700) Subject: Re: Draft minutes for MALLOC @ IETF 45 Sender: owner-malloc@catarina.usc.edu Precedence: bulk >> I think that the open issue is actually how this scheme interacts with >> the IPv6->ethernet group address mapping, which uses the low 32 bits >> of the group address. There aren't more bits available in the ethernet >> group address space, unless we want to redefine the mapping, and there >> are a max of 14 more bits available even if IPv6 multicast claims the >> entire "local use" ethernet multicast address space. I think we should seriously consider redefining the mapping. We get endless worry requests from customers about the 32-to-1 mapping for IPv4. And it creates Havoc for switches when a video group maps to the OSPF or PIM group addresses. Dino From owner-malloc@catarina.usc.edu Sat Jul 24 12:27:53 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06435 for ; Sat, 24 Jul 1999 12:27:53 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id FAA09427 for malloc-list; Sat, 24 Jul 1999 05:28:31 -0700 Received: from usc.edu (usc.edu [128.125.253.136]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id FAA09423 for ; Sat, 24 Jul 1999 05:28:21 -0700 Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by usc.edu (8.8.8/8.8.8/usc) with ESMTP id EAA17251 for ; Sat, 24 Jul 1999 04:06:09 -0700 (PDT) Received: from corona.research.att.com (unknown [135.207.26.21]) by mail-green.research.att.com (Postfix) with ESMTP id 325C61E15A for ; Sat, 24 Jul 1999 00:39:31 -0400 (EDT) Received: (from fenner@localhost) by corona.research.att.com (980427.SGI.8.8.8/8.8.7) id VAA22618; Fri, 23 Jul 1999 21:38:03 -0700 (PDT) From: Bill Fenner Message-Id: <199907240438.VAA22618@corona.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: dino@cisco.com Subject: Re: Draft minutes for MALLOC @ IETF 45 Cc: fenner@research.att.com, malloc@catarina.usc.edu Date: Fri, 23 Jul 1999 21:38:03 -0700 Versions: dmail (irix) 2.2c/makemail 2.8t Sender: owner-malloc@catarina.usc.edu Precedence: bulk > I think we should seriously consider redefining the mapping. Any mapping is going to map 1,208,925,819,614,629,174,706,176 IPv6 addresses into a single ethernet address, unless you think we can use the remaining 14 bits of the local multicast ethernet address space, in which case it's only 73,786,976,294,838,206,464 IPv6 addresses for one ethernet address. This is what RFC2373's restriction on assignment of IPv6 addresses to have 80 bits of zero in the middle is about - it allows there to be a 1-1 mapping by only allowing the assignment of the unique part of the space. The new proposal for IPv6 multicast address assignment needs to address this part of the problem as well, and that's what I think the discussion in Oslo boiled down to. Bill From owner-malloc@catarina.usc.edu Mon Jul 26 09:31:45 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05170 for ; Mon, 26 Jul 1999 09:31:44 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id FAA16390 for malloc-list; Mon, 26 Jul 1999 05:47:24 -0700 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id FAA16386 for ; Mon, 26 Jul 1999 05:47:18 -0700 Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id IAA24300; Mon, 26 Jul 1999 08:47:06 -0400 Received: from tigers.raleigh.ibm.com (tigers.raleigh.ibm.com [9.37.176.195]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id IAA30642; Mon, 26 Jul 1999 08:47:06 -0400 Received: from raleigh.ibm.com (localhost.raleigh.ibm.com [127.0.0.1]) by tigers.raleigh.ibm.com (AIX4.3/UCB 8.8.8/8.7/RTP-ral-1.0) with ESMTP id IAA19744; Mon, 26 Jul 1999 08:47:16 -0400 Message-ID: <379C58D4.610D723E@raleigh.ibm.com> Date: Mon, 26 Jul 1999 08:47:16 -0400 From: Brian Haberman Organization: Routing Protocols X-Mailer: Mozilla 4.6 [en] (X11; U; AIX 4.3) X-Accept-Language: en MIME-Version: 1.0 To: Bill Fenner CC: dino@cisco.com, malloc@catarina.usc.edu Subject: Re: Draft minutes for MALLOC @ IETF 45 References: <199907240438.VAA22618@corona.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bill Fenner wrote: > > This is what RFC2373's restriction on assignment of IPv6 addresses to > have 80 bits of zero in the middle is about - it allows there to be a > 1-1 mapping by only allowing the assignment of the unique part of the > space. The new proposal for IPv6 multicast address assignment needs > to address this part of the problem as well, and that's what I think > the discussion in Oslo boiled down to. > Bill, After the MALLOC meeting, a few people discussed the issue of mapping. One idea was to use a portion of the network prefix as a seed to an md5 hash and then give that resulting value as a base address that the MADCAP servers would use for allocation. This will eliminate the concern that was raised about interaction with current users of RFC2373. In my opinion, there will really be two drafts based on this work, one in IPNG to update the multicast address architecture and one in MALLOC that lays out the usage rules/guidelines. Brian -- *----------------------------------- ----------------------------* | Brian K. Haberman / / | | Remote Access Products \ \ An unbreakable toy | | IBM Research Triangle Park, NC / / is useful, | | Internal Phone : 8-444-2673 \ \ for breaking other toys. | | External Phone : (919) 254-2673 / / | | email : haberman@raleigh.ibm.com \ \ | *----------------------------------- ----------------------------* From owner-malloc@catarina.usc.edu Mon Jul 26 09:51:57 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07301 for ; Mon, 26 Jul 1999 09:51:56 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id GAA16429 for malloc-list; Mon, 26 Jul 1999 06:00:57 -0700 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id GAA16425 for ; Mon, 26 Jul 1999 06:00:53 -0700 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA21278 for ; Mon, 26 Jul 1999 06:00:52 -0700 (PDT) Received: from bcn.East.Sun.COM (bcn.East.Sun.COM [129.148.75.4]) by eastmail2.East.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA15772 for ; Mon, 26 Jul 1999 09:00:49 -0400 (EDT) Received: from sun.com (dhcp75-155 [129.148.75.155]) by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with ESMTP id JAA22583 for ; Mon, 26 Jul 1999 09:00:50 -0400 (EDT) Message-ID: <379C5B20.6180DA26@sun.com> Date: Mon, 26 Jul 1999 08:57:04 -0400 From: Steve Hanna Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: malloc@catarina.usc.edu Subject: Re: Draft minutes for MALLOC @ IETF 45 References: <199907232150.OAA03959@windsor.research.att.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit This is certainly an interesting and worthwhile topic (how to map IPv6 multicast addresses onto Ethernet group addresses). I don't think we discussed this in any depth at the MALLOC meeting in Oslo. Maybe it was discussed more at MBONED. I don't know. But for the purposes of the MALLOC minutes, I suggest the following (revised) text: One open issue is how best to map IPv6 multicast addresses onto Ethernet group addresses. RFC 2373 uses only the low 32 bits of the group ID. There may be other schemes that would result in fewer collisions. Please let me know if you have concerns with this. As for my personal opinion on this issue, hashing seems like the simplest and most effective solution. MD5 would be fine, but I don't think we need a cryptographic hash. CRC should be OK, too. -Steve From owner-malloc@catarina.usc.edu Mon Jul 26 11:04:44 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12452 for ; Mon, 26 Jul 1999 11:04:43 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id HAA16671 for malloc-list; Mon, 26 Jul 1999 07:15:20 -0700 Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id HAA16667 for ; Mon, 26 Jul 1999 07:15:13 -0700 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 8498C4CE25; Mon, 26 Jul 1999 10:15:06 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id KAA21354; Mon, 26 Jul 1999 10:15:05 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id HAA21061; Mon, 26 Jul 1999 07:15:05 -0700 (PDT) Message-Id: <199907261415.HAA21061@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: steve.hanna@sun.com Subject: Re: Draft minutes for MALLOC @ IETF 45 Cc: malloc@catarina.usc.edu References: <199907232150.OAA03959@windsor.research.att.com> <379C5B20.6180DA26@sun.com> Date: Mon, 26 Jul 1999 07:15:05 -0700 Versions: dmail (solaris) 2.2c/makemail 2.8t Sender: owner-malloc@catarina.usc.edu Precedence: bulk > One open issue is how best to map IPv6 multicast addresses onto > Ethernet group addresses. RFC 2373 uses only the low 32 bits of > the group ID. There may be other schemes that would result in > fewer collisions. I would have said that the open issue was how this allocation scheme interacts with the existing mapping scheme; I'm guessing there will be a fair amount of resistance to changing the mapping due to existing implementations. Bill From owner-malloc@catarina.usc.edu Mon Jul 26 11:39:35 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13980 for ; Mon, 26 Jul 1999 11:39:34 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id IAA16931 for malloc-list; Mon, 26 Jul 1999 08:04:58 -0700 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id IAA16927 for ; Mon, 26 Jul 1999 08:04:54 -0700 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA05617; Mon, 26 Jul 1999 08:04:52 -0700 (PDT) Received: from bcn.East.Sun.COM (bcn.East.Sun.COM [129.148.75.4]) by eastmail2.East.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA13203; Mon, 26 Jul 1999 11:04:49 -0400 (EDT) Received: from sun.com (dhcp75-155 [129.148.75.155]) by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with ESMTP id LAA23334; Mon, 26 Jul 1999 11:04:50 -0400 (EDT) Message-ID: <379C7830.D33C6EEB@sun.com> Date: Mon, 26 Jul 1999 11:01:04 -0400 From: Steve Hanna Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bill Fenner CC: malloc@catarina.usc.edu Subject: Re: Draft minutes for MALLOC @ IETF 45 References: <199907232150.OAA03959@windsor.research.att.com> <379C5B20.6180DA26@sun.com> <199907261415.HAA21061@windsor.research.att.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bill Fenner wrote: > > One open issue is how best to map IPv6 multicast addresses onto > > Ethernet group addresses. RFC 2373 uses only the low 32 bits of > > the group ID. There may be other schemes that would result in > > fewer collisions. > > I would have said that the open issue was how this allocation scheme > interacts with the existing mapping scheme; I'm guessing there will > be a fair amount of resistance to changing the mapping due to existing > implementations. Good point. So you're saying that we should try to ensure that multicast addresses are allocated and used in such a way that collisions will be unlikely with the RFC 2373 mapping? I guess I missed that point originally. Thanks for pointing out the problem. Here's some revised text: One open issue is how this allocation scheme may interact with the technique used for mapping IPv6 multicast addresses to Ethernet group addresses. RFC 2464 uses only the low 32 bits of the multicast address. We should try to avoid collisions by attempting to ensure that the IPv6 multicast addresses in use map evenly over the Ethernet group address space. Note that I changed RFC 2373 to RFC 2464, since it is the latter which specifies the mapping from IPv6 multicast addresses to Ethernet group addresses. More comments? Thanks, Steve From owner-malloc@catarina.usc.edu Mon Jul 26 13:08:01 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16689 for ; Mon, 26 Jul 1999 13:08:00 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id JAA17294 for malloc-list; Mon, 26 Jul 1999 09:19:48 -0700 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id JAA17288 for ; Mon, 26 Jul 1999 09:19:29 -0700 Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA28288; Mon, 26 Jul 1999 12:19:10 -0400 Received: from tigers.raleigh.ibm.com (tigers.raleigh.ibm.com [9.37.176.195]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id MAA32940; Mon, 26 Jul 1999 12:19:10 -0400 Received: from raleigh.ibm.com (localhost.raleigh.ibm.com [127.0.0.1]) by tigers.raleigh.ibm.com (AIX4.3/UCB 8.8.8/8.7/RTP-ral-1.0) with ESMTP id MAA20450; Mon, 26 Jul 1999 12:19:21 -0400 Message-ID: <379C8A89.C4509B1B@raleigh.ibm.com> Date: Mon, 26 Jul 1999 12:19:21 -0400 From: Brian Haberman Organization: Routing Protocols X-Mailer: Mozilla 4.6 [en] (X11; U; AIX 4.3) X-Accept-Language: en MIME-Version: 1.0 To: Steve Hanna CC: Bill Fenner , malloc@catarina.usc.edu Subject: Re: Draft minutes for MALLOC @ IETF 45 References: <199907232150.OAA03959@windsor.research.att.com> <379C5B20.6180DA26@sun.com> <199907261415.HAA21061@windsor.research.att.com> <379C7830.D33C6EEB@sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Steve Hanna wrote: > > Bill Fenner wrote: > > > One open issue is how best to map IPv6 multicast addresses onto > > > Ethernet group addresses. RFC 2373 uses only the low 32 bits of > > > the group ID. There may be other schemes that would result in > > > fewer collisions. > > > > I would have said that the open issue was how this allocation scheme > > interacts with the existing mapping scheme; I'm guessing there will > > be a fair amount of resistance to changing the mapping due to existing > > implementations. > > Good point. So you're saying that we should try to ensure that multicast > addresses are allocated and used in such a way that collisions will be > unlikely with the RFC 2373 mapping? > > I guess I missed that point originally. Thanks for pointing out the > problem. > > Here's some revised text: > > One open issue is how this allocation scheme may interact with > the technique used for mapping IPv6 multicast addresses to > Ethernet group addresses. RFC 2464 uses only the low 32 bits of > the multicast address. We should try to avoid collisions by > attempting to ensure that the IPv6 multicast addresses in use map > evenly over the Ethernet group address space. > > Note that I changed RFC 2373 to RFC 2464, since it is the latter which > specifies the mapping from IPv6 multicast addresses to Ethernet group > addresses. > Steve, That sounds good to me. There are a few other points that I want to make : 1. There was concern voiced by a few IPv6 people as well as Tom Narten about interaction between this new scheme and existing implementations of RFC 2464. 2. I agree that CRC should work as well. MD5 was just mentioned as one possibility. Brian