From owner-malloc@catarina.usc.edu Tue Dec 1 18:15:16 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id SAA29085 for ; Tue, 1 Dec 1998 18:15:15 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id OAA21268 for malloc-list; Tue, 1 Dec 1998 14:37:24 -0800 Received: from mailgate.nortel.ca (mailgate.nortel.ca [192.58.194.74]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id OAA21264 for ; Tue, 1 Dec 1998 14:37:13 -0800 Received: from zcard00n.ca.nortel.com by mailgate; Tue, 1 Dec 1998 17:36:21 -0500 Received: from zcard008.ca.nortel.com by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id XTT36QPD; Tue, 1 Dec 1998 17:36:20 -0500 Received: from zgtys001.ca.nortel.com by zcard008.bnr.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id XN64CZYR; Tue, 1 Dec 1998 17:36:19 -0500 Message-ID: <36646F64.3545CF86@americasm01.nt.com> Date: Tue, 01 Dec 1998 17:36:20 -0500 From: "Cheng-Yin Lee" Organization: Nortel X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.6 sun4u) MIME-Version: 1.0 To: Jason Morphett CC: Dave Thaler , finlayson@live.com, smirnow@fokus.gmd.de, malloc@catarina.usc.edu Subject: Re: malloc service model (was: MDHCP review) References: <199811271856.NAA11448@dip.eecs.umich.edu> Content-Type: multipart/alternative; boundary="------------664CE130FC26BAC0A5212F5E" Sender: owner-malloc@catarina.usc.edu Precedence: bulk --------------664CE130FC26BAC0A5212F5E Content-type: text/plain; charset="us-ascii" Jason, Or alternatively, you could take a look at Simple Multicast. It doesn't have the address allocation problems you listed below. OTOH, i'll be interested to hear about its other shortcomings :-) (wrt MALLOC in particular) thanks, cyl p.s if you're interested, the latest Simple Multicast draft-01 should be accessible on the IDMR Mailing List archive. Dave Thaler wrote: > Just to add to what Mark said... > > > As an application developer, I need to allocate (potentially) a lot of > > multicast addresses with the lowest possible latency in doing so. I > > don't want to 'hoard' X addresses and use X/10 of them for 50% of the > > time as that's not utilising the available address space. I need to be > > able to request and receive addresses in the *least possible time* and > > use them for anything varying from a few seconds to (potentially) hours. > > But, the key factor is latency in allocation. > > Right, this is typical. > > > Reading Mark Handley's AAP proposal. It states that I may have to wait > > for anything up to ANNOUNCE-WAIT (at best) before I get the address. > > How do the current offerings from MALLOC allow me to request and receive > > an address in under ANNOUNCE-WAIT? i.e. request-receive c.f. > > claim-collide? > > My opinion is that servers should always try to keep a small pool of > addresses reserved for allocation (the AITU message that Mark mentioned). > Anyone requesting a small number of addresses can then get them > immediately, with no advance notice. > > If you ask for a large number of addresses (more than the small pool > size), then you have to wait. If you ask for a really large number, > you may not get them at all unless you ask for them enough > in advance of when you need them. > > (You may be able to get a hotel room at the last minute, but > if you're trying to reserve a block of 1000, you'll > definitely be out of luck.) > > > BTW, the application is a large scale virtual environment using > > multicast addresses for 'groups' of inhabitants to use for > > audio/text/video etc.? Addresses are handed out as groups form (a > > highly dynamic activity). > > This sounds like a typical DIS-like scenario. You can either > a) allocate groups one-at-a-time on demand, or > b) pre-allocate a large block, and use some application-layer > mapping function to decide which one of the large block to use. > > The former is more efficient in terms of space utilization. > The latter is useful if groups are associated with things in > the virtual environment (e.g. rooms). > > -Dave -- leecy@nortel.com --------------664CE130FC26BAC0A5212F5E Content-type: text/html; charset="us-ascii" Content-transfer-encoding: 7bit Jason,
Or alternatively, you could take a look at Simple Multicast. It doesn't have the address allocation  problems you listed below.
OTOH, i'll be interested to hear about its other shortcomings :-) (wrt MALLOC in particular)

thanks,
cyl
p.s if you're interested, the latest Simple Multicast draft-01 should be accessible on the IDMR Mailing List archive.

Dave Thaler wrote:

Just to add to what Mark said...

> As an application developer, I need to allocate (potentially) a lot of
> multicast addresses with the lowest possible latency in doing so.  I
> don't want to 'hoard' X addresses and use X/10 of them for 50% of the
> time as that's not utilising the available address space.  I need to be
> able to request and receive addresses in the *least possible time* and
> use them for anything varying from a few seconds to (potentially) hours.
>  But, the key factor is latency in allocation.

Right, this is typical.

> Reading Mark Handley's AAP proposal.  It states that I may have to wait
> for anything up to ANNOUNCE-WAIT (at best) before I get the address.
> How do the current offerings from MALLOC allow me to request and receive
> an address in under ANNOUNCE-WAIT? i.e. request-receive c.f.
> claim-collide?

My opinion is that servers should always try to keep a small pool of
addresses reserved for allocation (the AITU message that Mark mentioned).
Anyone requesting a small number of addresses can then get them
immediately, with no advance notice.

If you ask for a large number of addresses (more than the small pool
size), then you have to wait.  If you ask for a really large number,
you may not get them at all unless you ask for them enough
in advance of when you need them.

(You may be able to get a hotel room at the last minute, but
if you're trying to reserve a block of 1000, you'll
definitely be out of luck.)

> BTW, the application is a large scale virtual environment using
> multicast addresses for 'groups' of inhabitants to use for
> audio/text/video etc.?  Addresses are handed out as groups form (a
> highly dynamic activity).

This sounds like a typical DIS-like scenario.  You can either
a) allocate groups one-at-a-time on demand, or
b) pre-allocate a large block, and use some application-layer
   mapping function to decide which one of the large block to use.

The former is more efficient in terms of space utilization.
The latter is useful if groups are associated with things in
the virtual environment (e.g. rooms).

-Dave

  
-- 
leecy@nortel.com
  --------------664CE130FC26BAC0A5212F5E-- From owner-malloc@catarina.usc.edu Wed Dec 2 23:40:05 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA17228 for ; Wed, 2 Dec 1998 23:40:04 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id TAA27888 for malloc-list; Wed, 2 Dec 1998 19:56:36 -0800 Received: from roble.intermedia.com.ar ([209.14.119.130]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id TAA27879; Wed, 2 Dec 1998 19:56:20 -0800 Received: from juan (ppp12.intermedia.com.ar [209.14.119.43]) by roble.intermedia.com.ar with SMTP id AAA17103; Thu, 3 Dec 1998 00:47:45 -0300 (EST) Message-ID: <009c01be1e70$2f130a60$8a1bfea9@juan> Reply-To: "Rava Sociedad de Bolsa S.A." To: From: "Rava Sociedad de Bolsa S.A." Subject: e-bolsa - Rava Sociedad de Bolsa S.A. Date: Thu, 3 Dec 1998 00:27:34 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0099_01BE1E57.09C5D260" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-malloc@catarina.usc.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0099_01BE1E57.09C5D260 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hola, que tal, bienvenido al mundo de la Bolsa v=EDa Internet !!!! =20 Si, la manera de llegar al Mercado de Valores de Buenos Aires a trav=E9s = de su PC sin moverse de su casa u oficina, no importando el lugar = distante que se encuentre de la city porte=F1a, ha llegado a la = Argentina, al igual que en Estados Unidos. =20 Porque desde este momento Ud. est=E1 invitado a operar a trav=E9s de = Rava Sociedad de Bolsa S.A., a trav=E9s de su exclusivo sistema e-bolsa, = implementado y dise=F1ado por nosotros, para brindarle toda la = informaci=F3n necesaria para realizar sus operaciones con =E9xito, sin = pisar nuestras oficinas, por medio de la red de redes. =20 A trav=E9s de e-bolsa Ud. conocer=E1 informaci=F3n diaria de balances, = su cartera de inversiones, su cuenta corriente, accesos a sitios de = empresas de inter=E9s, tendr=E1 acceso a programas shareware para = realizar an=E1lisis t=E9cnico y sus bases de datos para alimentarlos, y = todo lo referente para realizar operaciones de Bolsa con confimaci=F3n = en minutos del detalle de la misma. =20 Para ello, le env=EDo este e-mail con el objeto de verificar su casilla = de correo electr=F3nico al pedirle que me lo responda, invitarlo a = visitar nuestra p=E1gina de web para conocerla, y se registre si no lo = hizo. =20 Adem=E1s el objeto del mismo es darle a conocer la direcci=F3n de = nuestro web site, que se accede en www.ebolsa.com.ar y nuestro nuevo = e-mail, que se adapta a nuestro domino registrado: ebolsa@rava.com.ar , = en el cual responderemos cualquier inquietud. =20 Sin otro particular, y agradeciendo vuestra atenci=F3n, esperamos su = respuesta. =20 Juan Carlos Rava - Rava Sociedad de Bolsa S.A. e-mail: ebolsa@rava.com.ar home page: www.ebolsa.com.ar 25 de Mayo 277 - Piso 5 - (1002) Capital Federal - ARGENTINA TE: 343-9421/9605 - 342-0923/4158 =20 ------=_NextPart_000_0099_01BE1E57.09C5D260 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hola, que tal, bienvenido al mundo de la Bolsa = vía=20 Internet !!!!
 
Si, la manera de llegar al Mercado de Valores de = Buenos Aires=20 a través de su PC sin moverse de su casa u oficina, no importando = el=20 lugar distante que se encuentre de la city porteña, ha llegado a = la=20 Argentina, al igual que en Estados Unidos.
 
Porque desde este momento Ud. está invitado a = operar a=20 través de Rava Sociedad de Bolsa S.A., a través de su = exclusivo=20 sistema e-bolsa, implementado y diseñado por nosotros, para = brindarle=20 toda la información necesaria para realizar sus operaciones con=20 éxito, sin pisar nuestras oficinas, por medio de la red de=20 redes.
 
A través de e-bolsa Ud. conocerá=20 información diaria de balances, su cartera de inversiones, su = cuenta=20 corriente, accesos a sitios de empresas de interés, tendrá = acceso=20 a programas shareware para realizar análisis técnico y sus = bases=20 de datos para alimentarlos, y todo lo referente para realizar = operaciones de=20 Bolsa con confimación en minutos del detalle de la = misma.
 
Para ello, le envío este e-mail con el objeto = de=20 verificar su casilla de correo electrónico al pedirle que me lo = responda,=20 invitarlo a visitar nuestra página de web para conocerla, y se = registre=20 si no lo hizo.
 
Además el objeto del mismo es darle a conocer = la=20 dirección de nuestro web site,  que se accede en www.ebolsa.com.ar  y nuestro = nuevo=20 e-mail, que se adapta a nuestro domino registrado: ebolsa@rava.com.ar  , en el = cual=20 responderemos cualquier inquietud.
 
Sin otro particular, y agradeciendo vuestra = atención,=20 esperamos su respuesta.
 
Juan Carlos Rava - Rava = Sociedad de Bolsa=20 S.A.
e-mail: ebolsa@rava.com.ar
home page: = www.ebolsa.com.ar
25 de Mayo = 277 - Piso 5=20 - (1002) Capital Federal - ARGENTINA
TE: 343-9421/9605 -=20 342-0923/4158
 
------=_NextPart_000_0099_01BE1E57.09C5D260-- From owner-malloc@catarina.usc.edu Thu Dec 3 11:59:31 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25959 for ; Thu, 3 Dec 1998 11:59:30 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id IAA29862 for malloc-list; Thu, 3 Dec 1998 08:04:34 -0800 Received: from toccata.fugue.com ([204.152.188.25]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id IAA29858 for ; Thu, 3 Dec 1998 08:04:30 -0800 Received: from grosse.fugue.com (p5.tc2.newyo.NY.tiac.com [209.61.81.70]) by toccata.fugue.com (8.8.8/8.6.11) with ESMTP id IAA01285; Thu, 3 Dec 1998 08:03:17 -0800 (PST) Received: from grosse.fugue.com (localhost [127.0.0.1]) by grosse.fugue.com (8.8.8/8.6.11) with ESMTP id KAA22274; Thu, 3 Dec 1998 10:59:26 -0500 (EST) Message-Id: <199812031559.KAA22274@grosse.fugue.com> To: malloc@catarina.usc.edu Cc: droms@bucknell.edu Subject: Re: Feedback requested (re MDHCP) In-Reply-To: Your message of "Thu, 03 Dec 1998 07:30:38 EST." Date: Thu, 03 Dec 1998 10:59:26 -0500 From: Ted Lemon Sender: owner-malloc@catarina.usc.edu Precedence: bulk > Ralph Droms tells me that this is where the real DHCP implementors hang > out. Last week, I sent the following email to the dhcp-v4 list and have > received very little response. I would greatly appreciate any input you > folks could provide. I did read that, and didn't respond because I don't have a strong opinion, and I feel that too many weak opinions, occasionally including my own, are offered that simply add to the general noise level in the IETF. However, since Ralph hasn't seen any responses, I'll do what I can, based on what you've said in your message. Please understand that I haven't read the MDHCP draft, and don't have time to, so if you see errors in the following statement, that's why. From what you've said, you've removed irrelevant fields from the DHCP packet. This shouldn't make much difference. I don't know if you've changed the option format, or just the meanings of the codes. If the former, the benefits of code sharing are probably pretty small. If the latter, perhaps not so small. The meat of the DHCP code is the address allocation code, which is going to be somewhat different for MDHCP than for DHCP anyway, so that was going to have to be tweaked regardless. The next biggest piece of the code is the option processing code, but at least in the case of the ISC server, that is fairly generic, so changing the meaning of the option codes doesn't prohibit code sharing. The code that drives the sequencing of the protocol is actually trivial, at least in the server, because really it's the client that drives the protocol. So making changes to that really doesn't have any significant impact on code sharing. Making similar changes in the client would be harder, but still not very hard, IMHO. I suspect that the Internet Software Consortium DHCP server could currently be hacked to support MDHCP, but nobody's asked me for it or offered patches, so I'm not sure that matters. FYI, I am willing to accept such changes if offered, and if they're clean, and I'm willing to work with MDHCP people who need guidance in how to make the changes. Hopefully this tells you what can be shared. I leave it to you to figure out whether or not it's worth it... :') _MelloN_ From owner-malloc@catarina.usc.edu Tue Dec 15 14:36:41 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22954 for ; Tue, 15 Dec 1998 14:36:40 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id LAA18298 for malloc-list; Tue, 15 Dec 1998 11:05:57 -0800 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id LAA18294 for ; Tue, 15 Dec 1998 11:05:50 -0800 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA18599 for ; Tue, 15 Dec 1998 11:04:55 -0800 Received: from jurassic.eng.sun.com by sunmail1.Sun.COM (SMI-8.6/SMI-4.1) id LAA07526 for ; Tue, 15 Dec 1998 11:04:09 -0800 Received: from demure.eng.sun.com (demure [129.146.86.129]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with ESMTP id LAA15579 for ; Tue, 15 Dec 1998 11:04:15 -0800 (PST) Received: (from sangeeta@localhost) by demure.eng.sun.com (8.9.1b+Sun/8.9.1) id LAA19788 for malloc@catarina.usc.edu; Tue, 15 Dec 1998 11:02:06 -0800 (PST) Date: Tue, 15 Dec 1998 11:02:06 -0800 (PST) From: Sangeeta Mukherjee Message-Id: <199812151902.LAA19788@demure.eng.sun.com> To: malloc@catarina.usc.edu Subject: Re: Comment on MDHCP draft X-Sun-Charset: US-ASCII Sender: owner-malloc@catarina.usc.edu Precedence: bulk If one removes the opcode field how does one distinguish if the packet is client request or reply? ----- Begin Included Message ----- From shanna@bcn.east.sun.com Tue Dec 15 08:34:38 1998 Date: Tue, 15 Dec 1998 11:34:19 -0500 (EST) From: Steve Hanna Subject: Re: Comment on MDHCP draft To: Sangeeta.Mukherjee@Eng MIME-Version: 1.0 Content-MD5: cTGllOfM7iYyQKw2+gDpIQ== > However I am a bit confused about the opcode > field. Does it still exist. If so I recommend that > the names BOOTREQUEST and BOOTREPLY > changed to REQUEST and REPLY. The existing names > are appropriate for DHCP functionality but is not > for MDHCP. Right. We decided during the working group meeting to remove the opcode field, as well as many other unused or reserved fields in the header. Assuming this meets with approval on the mailing list, this should no longer be an issue. ----- End Included Message ----- From owner-malloc@catarina.usc.edu Tue Dec 15 15:35:33 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24225 for ; Tue, 15 Dec 1998 15:35:32 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id MAA18678 for malloc-list; Tue, 15 Dec 1998 12:02:37 -0800 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id MAA18674 for ; Tue, 15 Dec 1998 12:02:32 -0800 Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA08105 for ; Tue, 15 Dec 1998 12:02:00 -0800 Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id PAA05317; Tue, 15 Dec 1998 15:01:42 -0500 Received: from bcn.East.Sun.COM (bcn [129.148.75.4]) by suneast.East.Sun.COM (8.9.1b+Sun/8.8.8) with SMTP id PAA23701; Tue, 15 Dec 1998 15:01:41 -0500 (EST) Received: from pine by bcn.East.Sun.COM (SMI-8.6/SMI-SVR4) id PAA09002; Tue, 15 Dec 1998 15:01:39 -0500 Message-Id: <199812152001.PAA09002@bcn.East.Sun.COM> Date: Tue, 15 Dec 1998 15:01:40 -0500 (EST) From: Steve Hanna Reply-To: Steve Hanna Subject: Re: Comment on MDHCP draft To: Sangeeta.Mukherjee@eng.sun.com Cc: malloc@catarina.usc.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 13rUlLiUrySJ/0/Wg0wdAA== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-malloc@catarina.usc.edu Precedence: bulk You use the MDHCP Message Type option. -Steve > Date: Tue, 15 Dec 1998 11:02:06 -0800 (PST) > From: Sangeeta Mukherjee > To: malloc@catarina.usc.edu > Subject: Re: Comment on MDHCP draft > > > > If one removes the opcode field how does one > distinguish if the packet is client request or reply? > > ----- Begin Included Message ----- > > From shanna@bcn.east.sun.com Tue Dec 15 08:34:38 1998 > Date: Tue, 15 Dec 1998 11:34:19 -0500 (EST) > From: Steve Hanna > Subject: Re: Comment on MDHCP draft > To: Sangeeta.Mukherjee@Eng > MIME-Version: 1.0 > Content-MD5: cTGllOfM7iYyQKw2+gDpIQ== > > > > However I am a bit confused about the opcode > > field. Does it still exist. If so I recommend that > > the names BOOTREQUEST and BOOTREPLY > > changed to REQUEST and REPLY. The existing names > > are appropriate for DHCP functionality but is not > > for MDHCP. > > Right. We decided during the working group meeting to remove the opcode field, > as well as many other unused or reserved fields in the header. Assuming this > meets with approval on the mailing list, this should no longer be an issue. > > > ----- End Included Message ----- > From owner-malloc@catarina.usc.edu Fri Dec 18 17:32:06 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10014 for ; Fri, 18 Dec 1998 17:32:05 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id OAA00735 for malloc-list; Fri, 18 Dec 1998 14:07:44 -0800 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id OAA00731 for ; Fri, 18 Dec 1998 14:07:38 -0800 Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA12833 for ; Fri, 18 Dec 1998 14:07:06 -0800 Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id RAA03147; Fri, 18 Dec 1998 17:06:57 -0500 Received: from bcn.East.Sun.COM (bcn [129.148.75.4]) by suneast.East.Sun.COM (8.9.1b+Sun/8.8.8) with SMTP id RAA14461 for ; Fri, 18 Dec 1998 17:06:58 -0500 (EST) Received: from pine by bcn.East.Sun.COM (SMI-8.6/SMI-SVR4) id RAA21214; Fri, 18 Dec 1998 17:06:56 -0500 Message-Id: <199812182206.RAA21214@bcn.East.Sun.COM> Date: Fri, 18 Dec 1998 17:06:57 -0500 (EST) From: Steve Hanna Reply-To: Steve Hanna Subject: Draft minutes for IETF 43 To: malloc@catarina.usc.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: XfJGQgBkTDLF6FIs8+ojwQ== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-malloc@catarina.usc.edu Precedence: bulk Here are the draft minutes from last week's malloc working group meeting. Please send any comments to the list by end of day Tuesday, December 22. Thanks, Steve ------------- Minutes of MALLOC Working Group IETF 43 (Orlando, FL) Thursday, December 10, 1998 Minutes reported by B. Quinn and S. Hanna. Agenda: Agenda Bashing Hanna Architecture Hanna MASC Deployment Govindan Language Tags Hanna MDHCP Changes Shah MDHCP Issues Thaler I. MALLOC Architecture Steve Hanna described the malloc architecture, explaining why dynamic allocation of IP Multicast addresses is important, what the requirements are, and how those requirements are supported by the different parts of the malloc architecture. Steve also gave a document status update. MDHCP is expected to go to last call in January 1999. MASC, AAP, the malloc architecture, and the Abstract API should all go to last call in the spring. II. MASC Deployment Ramesh Govindan of USC/ISI gave a presentation on possible MASC deployment techniques. In the long run, each AS will probably be its own MASC domain, with a limited number of top-level domains functioning as peers (with children of those TLDs, etc.). However, we can start out with a single root domain that injects the address sets and a small number of well-known TLDs that are children of that root. This will be simple and good for debugging. Over time, we can move to a more decentralized model with children of the TLDs, shortcuts between the TLDs, and the eventual elimination of the root TLD. Ramesh briefly outlined the latest changes to the MASC protocol: refining processing of UPDATE messages and adding type-based ordering of exchanged messages after reestablishment of peering. Finally, Ramesh explained that a standalone implementation of MASC is being developed at USC/ISI. Alpha code should be ready by next IETF. Mark Handley announced that we have asked the IANA to allocate a range of multicast addresses for dynamic allocation with malloc. III. Language Tags Steve Hanna explained why language tags have been added to zone names and how they work. The problem is that zone names are user visible strings and different users speak different languages. For instance, a zone named "IBM Switzerland" would not be appropriate for someone who doesn't speak English. The solution we have adopted is to apply RFC 1766 language tags to zone names and allow more than one name per zone. This meets requirements of RFC 2277, which says (roughly) if you have user visible strings you need to have a way to indicate which language they are in and, when appropriate, support multiple languages. For MZAP, we have added a language tag for each zone name and added support for having more than one name per zone. We have also added a default flag, which indicates which name should be used if no language tag matches the user's preferences. A conflict in names (two routers configured with different names or language tags) indicates a configuration error. MASC and AAP are not affected by language tags on zone names since they do not deal with zone names. MDHCP has been modified to allow a host to specify a preferred language in the MDHCPINFORM message. The MDHCP server will return the best match for each zone. For multilingual hosts, the host should not specify a preferred language. In this case, the MDHCP server will return all names for each zone. The Abstract API has been changed to include all zone names in the Scope data type. The get_zone_name function fetches the zone name that best matches a given language tag from a given Scope. IV. MDHCP Munil Shah described the changes to the MDHCP specification since the last IETF. A new port number has been assigned by the IANA: 2535. The unused chaddr, sname and file fields have been removed. The MDHCP option space has been split off from the DHCP option space. And support for language tags has been added (as described above). V. MDHCP Issues Dave Thaler led a discussion of unresolved issues with MDHCP. The goal was to discuss these issues and achieve consensus, then confirm this consensus on the mailing list to allow us to take the spec to last call in January, as listed in our working group charter. Dave listed the issues scheduled for discussion and asked for any others. Two more were raised and added to the list (issues 6 and 7 below). Before beginning the issues discussion, Dave presented a summary of the answers to a questionnaire that Steve Hanna sent to the dhcp-v4 and dhcp-impl mailing lists. 5 DHCP implementors responded. Do you think that you might implement an MDHCP client or server? 3 Yes, 1 will accept mods, 1 if there's demand If you were to do so, would you attempt to share code with your DHCP client or server? 3 Yes, 1 Maybe, 1 Little Do you think that we should continue to maintain a similarity between MDHCP and DHCP? 3 Yes, 1 No Opinion, 1 Do The Right Thing *Issue 1* Unused Fields The first issue was whether the remaining reserved fields (op, htype, hlen, hops, secs, flags, ciaddr, yiaddr, siaddr, and giaddr) should be removed. The argument in favor of retaining them was to make it easier to reuse existing DHCP code. The argument in favor of removing them was that they are unnecessary and the savings due to reuse here is minimal. After much discussion, it was agreed to drop these unused fields. It was also agreed (at the suggestion of DHCP implementers) that we add a version number to the header. *Issue 2* Security The second issue was security. Dave Thaler summarized the problem by saying that our primary goal is to authenticate messages so we can check authorization. DHCP has a harder problem, since a DHCP client may not have a unicast address. The authors' proposal was to secure unicast messages with an existing security protocol (undecided which one), not secure the multicast INFORM message (used to request scope list), and require secure servers to ignore multicast DISCOVER and REQUEST messages (which would not be secured). Ted Tso and Bob Moskowitz (cochairs of the IPsec working group) summarized the advantages and disadvantages of several existing security protocols for this purpose. First, they confirmed their understanding that we want user-based security for UDP packets. The answer was yes, since we want to be able to base authorization on user identity. They explained that current implementations of IPsec provide host-based security. More work needs to be done on APIs and implementation before user-based IPsec will be ready. Also, installing IPsec requires OS-level modifications and IPsec is not yet widely available. Then they discussed other possible solutions. Of these, the most promising seemed to be TLS/SSL. TLS is user-based, but it is also TCP-based. Using TLS with MDHCP would require sending the payload that would normally be carried over UDP over an authenticated TCP connection. Another advantage of TLS over IPsec is wide availability and no OS-level modifications required. It was generally agreed that IPsec was probably the right decision long-term, but it would be difficult in the next few years to require all MDHCP clients to support IPsec. Support for user-level security in IPsec will also take a while to become available. It was agreed that we will go with IPsec for MDHCP security, but ask the IESG to not require security in all MDHCP implementations for the time being, since IPsec deployment is just beginning. Also, even perfect security in our multicast address allocation protocols can't keep somebody from just choosing an address and starting to use it. At least, not with current implementations of IP Multicast. *Issue 3* One-byte option length Currently, each MDHCP option includes a one byte length field. We expect to exceed this length with long scope lists or address block lists. DHCP will probably move to a two byte option length field in the future. Shall we move to it now? After some discussion, the general consensus was that we should. *Issue 4* Allocation scope referenced but not defined The current MDHCP draft says that clients looking for a server should first look in the local scope, then the scope from which they're trying to allocate, then the Allocation Scope. Unfortunately, there is no document defining Allocation Scope yet. The authors recommend removing all mention of Allocation Scope from the document. It was pointed out that this would require you to have an MDHCP server in each scope from which you want to allocate. Also, unless you use DHCP (or some other mechanism) to provide an MDHCP Server Multicast Address, you would need to have an MDHCP server in each local scope where you have MDHCP clients. It was also pointed out that providing MDHCP services for a scope when the server is not in that scope is very difficult. The server must know exactly which scopes the client is in and which addresses are available in those scopes. This is not easy and not recommended at this point. It was agreed to remove all mention of Allocation Scope from the document. Use of MDHCP with the Allocation Scope may be defined by a future RFC, once the Allocation Scope has been defined. *Issue 5* IPv6 support Currently, MDHCP only supports IPv4. The authors recommend adding address type fields to allow MDHCP to support IPv6. We quickly agreed to this recommendation. *Issue 6* One-byte option code Currently, each MDHCP option includes a one byte option code. Based on DHCP's experience of running low on option codes and their decision to move to a two byte option code in the future, we quickly agreed to move to a two byte option code for MDHCP. It was also suggested and agreed to number our options from 1 instead of attempting to match them to DHCP option numbers. *Issue 7* MDHCP Name Change Steve Deering suggested that since MDHCP has diverged from DHCP, it might make sense to change its name. After some discussion, this was agreed. Discussion of what the new name should be was moved to the list. From owner-malloc@catarina.usc.edu Mon Dec 21 17:20:11 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12782 for ; Mon, 21 Dec 1998 17:20:10 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA08589 for malloc-list; Mon, 21 Dec 1998 13:58:57 -0800 Received: from dip.eecs.umich.edu (thalerd@dip.eecs.umich.edu [141.212.99.5]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id NAA08585 for ; Mon, 21 Dec 1998 13:58:52 -0800 Received: (from thalerd@localhost) by dip.eecs.umich.edu (8.9.1/8.9.0) id QAA16552; Mon, 21 Dec 1998 16:58:47 -0500 (EST) From: Dave Thaler Message-Id: <199812212158.QAA16552@dip.eecs.umich.edu> Subject: Re: New name for MDHCP To: shanna@bcn.East.Sun.COM Date: Mon, 21 Dec 1998 16:58:47 -0500 (EST) Cc: malloc@catarina.usc.edu In-Reply-To: <199812212154.QAA28007@bcn.East.Sun.COM> from "Steve Hanna" at Dec 21, 98 04:54:28 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit > At the malloc working group meeting in Orlando, we agreed to change the name > of > the MDHCP protocol to something else. This was suggested because MDHCP is no > longer very similar to DHCP. Here are a few ideas that I have heard batted > around. Please send other suggestions to this list. > > Multicast Multicast Address Request Protocol (MARP) > Multicast Address Assignment Protocol (MAAP) > > Of these, I prefer the latter because the former was already used for my > proposal last spring. > > -Steve To add my two cents: I personally prefer a name which identifies it as the host-server protocol (as opposed to intra-domain or inter-domain). For example, it would be nice to see the word "host" or the word "client" somewhere in the name. -Dave From owner-malloc@catarina.usc.edu Mon Dec 21 17:26:17 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12958 for ; Mon, 21 Dec 1998 17:26:16 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA08552 for malloc-list; Mon, 21 Dec 1998 13:52:18 -0800 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id NAA08548 for ; Mon, 21 Dec 1998 13:52:12 -0800 Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA25698 for ; Mon, 21 Dec 1998 13:51:41 -0800 Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id QAA29280; Mon, 21 Dec 1998 16:51:31 -0500 Received: from bcn.East.Sun.COM (bcn [129.148.75.4]) by suneast.East.Sun.COM (8.9.1b+Sun/8.8.8) with SMTP id QAA22403 for ; Mon, 21 Dec 1998 16:51:33 -0500 (EST) Received: from pine by bcn.East.Sun.COM (SMI-8.6/SMI-SVR4) id QAA27985; Mon, 21 Dec 1998 16:51:31 -0500 Message-Id: <199812212151.QAA27985@bcn.East.Sun.COM> Date: Mon, 21 Dec 1998 16:51:32 -0500 (EST) From: Steve Hanna Reply-To: Steve Hanna Subject: Confirmation of rough consensus To: malloc@catarina.usc.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 9qA7EKUrsR6Nr2/3lwSiQQ== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-malloc@catarina.usc.edu Precedence: bulk I would like to confirm that we have reached rough consensus on the following decisions regarding MDHCP. These decisions were agreed to at the malloc working group meeting in Orlando (12/10/98). If you would like to raise any issues regarding them, please do so now. Thanks, Steve Hanna ----------- 1) Remove reserved fields and add version in header 2) Add security based on IPsec 3) Make option type and length two bytes long 4) Remove references to allocation scope 5) Add IPv6 support via address type fields 6) Renumber options to start with 1 7) Change name to something other than MDHCP From owner-malloc@catarina.usc.edu Mon Dec 21 17:36:35 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13127 for ; Mon, 21 Dec 1998 17:36:35 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA08564 for malloc-list; Mon, 21 Dec 1998 13:55:32 -0800 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id NAA08560 for ; Mon, 21 Dec 1998 13:55:19 -0800 Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA26489 for ; Mon, 21 Dec 1998 13:54:42 -0800 Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id QAA29820; Mon, 21 Dec 1998 16:54:28 -0500 Received: from bcn.East.Sun.COM (bcn [129.148.75.4]) by suneast.East.Sun.COM (8.9.1b+Sun/8.8.8) with SMTP id QAA22499 for ; Mon, 21 Dec 1998 16:54:29 -0500 (EST) Received: from pine by bcn.East.Sun.COM (SMI-8.6/SMI-SVR4) id QAA28007; Mon, 21 Dec 1998 16:54:27 -0500 Message-Id: <199812212154.QAA28007@bcn.East.Sun.COM> Date: Mon, 21 Dec 1998 16:54:28 -0500 (EST) From: Steve Hanna Reply-To: Steve Hanna Subject: New name for MDHCP To: malloc@catarina.usc.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: I8DazxutnweqKGw1+zb/Dg== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-malloc@catarina.usc.edu Precedence: bulk At the malloc working group meeting in Orlando, we agreed to change the name of the MDHCP protocol to something else. This was suggested because MDHCP is no longer very similar to DHCP. Here are a few ideas that I have heard batted around. Please send other suggestions to this list. Multicast Multicast Address Request Protocol (MARP) Multicast Address Assignment Protocol (MAAP) Of these, I prefer the latter because the former was already used for my proposal last spring. -Steve From owner-malloc@catarina.usc.edu Mon Dec 21 17:56:39 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13363 for ; Mon, 21 Dec 1998 17:56:38 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id OAA08682 for malloc-list; Mon, 21 Dec 1998 14:18:01 -0800 Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id OAA08678 for ; Mon, 21 Dec 1998 14:17:56 -0800 Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4) id RAA17472; Mon, 21 Dec 1998 17:17:51 -0500 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: Steve Hanna cc: malloc@catarina.usc.edu Subject: Re: New name for MDHCP In-reply-to: Your message of "Mon, 21 Dec 1998 16:54:28 EST." <199812212154.QAA28007@bcn.East.Sun.COM> Date: Mon, 21 Dec 1998 17:17:51 -0500 Message-ID: <17470.914278671@north.lcs.mit.edu> Sender: owner-malloc@catarina.usc.edu Precedence: bulk >At the malloc working group meeting in Orlando, we agreed to change the name o >f >the MDHCP protocol to something else. This was suggested because MDHCP is no >longer very similar to DHCP. Here are a few ideas that I have heard batted >around. Please send other suggestions to this list. > >Multicast Address Request Protocol (MARP) >Multicast Address Assignment Protocol (MAAP) > >Of these, I prefer the latter because the former was already used for my >proposal last spring. I prefer the former. The latter is sure to get confused with the existing multicast AAP. Besides, I think the work "Request" conveys something of the client-server nature of the protocol. In response to Dave's point, we could go for something like: Client Request Of Multicast Address (CROMA) Multicast Address Request by Client (MARC) (!) Multicast Address Request from Server (MARS) Client/server Address Request Protocol (CARP) Host Address Request Protocol (HARP) Multicast Address Client/Server Protocol (MACS) I'm sure the potential list is near infinite :-) Cheers, Mark From owner-malloc@catarina.usc.edu Tue Dec 22 00:14:31 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA24511 for ; Tue, 22 Dec 1998 00:14:30 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id UAA09671 for malloc-list; Mon, 21 Dec 1998 20:53:52 -0800 Received: from chmls05.mediaone.net (ne.mediaone.net [24.128.1.70]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id UAA09667 for ; Mon, 21 Dec 1998 20:53:46 -0800 Received: from rcq (rcq.ne.mediaone.net [24.128.34.53]) by chmls05.mediaone.net (8.8.7/8.8.7) with SMTP id XAA00971; Mon, 21 Dec 1998 23:53:39 -0500 (EST) Message-Id: <4.1.19981221233835.01d7d6b0@pop.tiac.net> X-Sender: rcq@pop.tiac.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 21 Dec 1998 23:50:01 -0500 To: Mark Handley From: Bob Quinn Subject: Re: New name for MDHCP Cc: Steve Hanna , malloc@catarina.usc.edu In-Reply-To: <17470.914278671@north.lcs.mit.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-malloc@catarina.usc.edu Precedence: bulk At 05:17 PM 12/21/98 -0500, Mark Handley wrote: > >>At the malloc working group meeting in Orlando, we agreed to change the name o >>f >>the MDHCP protocol to something else. This was suggested because MDHCP is no >>longer very similar to DHCP. Here are a few ideas that I have heard batted >>around. Please send other suggestions to this list. >> >>Multicast Address Request Protocol (MARP) >>Multicast Address Assignment Protocol (MAAP) >> >>Of these, I prefer the latter because the former was already used for my >>proposal last spring. > >I prefer the former. The latter is sure to get confused with the >existing multicast AAP. I also prefer the former for the same reason. >Besides, I think the work "Request" conveys >something of the client-server nature of the protocol. Another possibility that describes the nature of the request is "Lease." Hence a variation would be: "MALP: Multicast Address Lease Protocol." Regards, -- Bob Quinn rcq@stardust.com From owner-malloc@catarina.usc.edu Tue Dec 22 11:02:21 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00512 for ; Tue, 22 Dec 1998 11:02:21 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id HAA10891 for malloc-list; Tue, 22 Dec 1998 07:20:03 -0800 Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id HAA10887 for ; Tue, 22 Dec 1998 07:19:53 -0800 Received: from dumbo.fokus.gmd.de (dumbo [193.175.132.239]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id QAA10394; Tue, 22 Dec 1998 16:19:49 +0100 (MET) From: Mikhail Smirnov Received: (mis@localhost) by dumbo.fokus.gmd.de (SMI-8.6/8.6.12) id QAA03545; Tue, 22 Dec 1998 16:19:47 +0100 Date: Tue, 22 Dec 1998 16:19:47 +0100 Message-Id: <199812221519.QAA03545@dumbo.fokus.gmd.de > To: Cheng-Yin.Lee.leecy@nortelnetworks.com, carlberg@time.saic.com Subject: Re: comments on simple multicast Cc: idmr@cs.ucl.ac.uk, malloc@catarina.usc.edu X-Sun-Charset: US-ASCII Sender: owner-malloc@catarina.usc.edu Precedence: bulk On Tue Dec 22 15:57:26 1998 Ken Carlberg wrote > in very general terms, MASC (and the other complimentary protocols) involves > the allocation/distribution of multicast addresses. during this process, > there is a delay and a best-guess engineering incured in this schema. > granted, the delay is small, and the engineering will probably be adequate > for today's commonly used mcast applications. but there are other > applications that may need to (and indeed do) bypass this process. this is very much true, I believe. There was a discussion on a malloc list before the malloc bof (Chicago): based on analytical modelling it's possible to show that (additionally to the malloc architecture) there should be a mediation mechanism assuring that some multicast addresses are co-operatively hoarded (a word coined by Graham Phillips, ISI) across domains by these new family of applications (to guarantee more than best-effort m'cast addresses availability). Some very initial results are in draft-phillips-malloc-util-00.txt. Regards & Merry Christmas Michael From owner-malloc@catarina.usc.edu Tue Dec 22 11:15:17 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00833 for ; Tue, 22 Dec 1998 11:15:17 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id HAA10931 for malloc-list; Tue, 22 Dec 1998 07:48:52 -0800 Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id HAA10927 for ; Tue, 22 Dec 1998 07:48:47 -0800 Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4) id KAA18269; Tue, 22 Dec 1998 10:44:14 -0500 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: Mikhail Smirnov cc: Cheng-Yin.Lee.leecy@nortelnetworks.com, carlberg@time.saic.com, idmr@cs.ucl.ac.uk, malloc@catarina.usc.edu Subject: Re: comments on simple multicast In-reply-to: Your message of "Tue, 22 Dec 1998 16:19:47 +0100." <199812221519.QAA03545@dumbo.fokus.gmd.de > Date: Tue, 22 Dec 1998 10:44:14 -0500 Message-ID: <18267.914341454@north.lcs.mit.edu> Sender: owner-malloc@catarina.usc.edu Precedence: bulk >On Tue Dec 22 15:57:26 1998 Ken Carlberg wrote > >> in very general terms, MASC (and the other complimentary protocols) involves >> the allocation/distribution of multicast addresses. during this process, >> there is a delay and a best-guess engineering incured in this schema. >> granted, the delay is small, and the engineering will probably be adequate >> for today's commonly used mcast applications. but there are other >> applications that may need to (and indeed do) bypass this process. Yes, one of the intentions behind the architecture is that those rare applications with special needs can bypass the-protocol-formerly-known-as-MDHCP and actually be be MAAS's and speak AAP directly. Then, within *very* broad bounds set my MASC, they can do their own address management. We believe those applications are rare (normal apps use MDHCP), but fully expect that they will probably exist. Speaking AAP is a bit harder than speaking MDHCP, so you wouldn't want normal apps to have to do so, but if you need that degree of control, that's where you fit in the architecture. Cheers, Mark From owner-malloc@catarina.usc.edu Tue Dec 22 11:31:41 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01166 for ; Tue, 22 Dec 1998 11:31:40 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id HAA11004 for malloc-list; Tue, 22 Dec 1998 07:55:11 -0800 Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id HAA11000 for ; Tue, 22 Dec 1998 07:55:03 -0800 Received: from dumbo.fokus.gmd.de (dumbo [193.175.132.239]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id QAA11327; Tue, 22 Dec 1998 16:54:52 +0100 (MET) From: Mikhail Smirnov Received: (mis@localhost) by dumbo.fokus.gmd.de (SMI-8.6/8.6.12) id QAA03583; Tue, 22 Dec 1998 16:54:49 +0100 Date: Tue, 22 Dec 1998 16:54:49 +0100 Message-Id: <199812221554.QAA03583@dumbo.fokus.gmd.de > To: mjh@EAST.ISI.EDU Subject: Re: comments on simple multicast Cc: Cheng-Yin.Lee.leecy@nortelnetworks.com, carlberg@time.saic.com, idmr@cs.ucl.ac.uk, malloc@catarina.usc.edu, smirnow@fokus.gmd.de X-Sun-Charset: US-ASCII Sender: owner-malloc@catarina.usc.edu Precedence: bulk Mark, > Yes, one of the intentions behind the architecture is that those rare > applications with special needs can bypass > the-protocol-formerly-known-as-MDHCP and actually be be MAAS's and > speak AAP directly. Then, within *very* broad bounds set my MASC, > they can do their own address management. agree with that: the malloc architecture has broad bounds enough, but also agree that > .... Speaking AAP is a bit > harder than speaking MDHCP, so you wouldn't want normal apps to have > to do so, but if you need that degree of control, that's where you fit > in the architecture. and I'd add (now from apps viewpoint) that "normal apps" should delegate this direct AAP talk to a [Internet-based] middleware. regards Michael From owner-malloc@catarina.usc.edu Tue Dec 22 11:44:59 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01419 for ; Tue, 22 Dec 1998 11:44:59 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id IAA11045 for malloc-list; Tue, 22 Dec 1998 08:03:24 -0800 Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id IAA11041 for ; Tue, 22 Dec 1998 08:03:19 -0800 Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4) id LAA18346; Tue, 22 Dec 1998 11:02:53 -0500 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: Mikhail Smirnov cc: Cheng-Yin.Lee.leecy@nortelnetworks.com, carlberg@time.saic.com, idmr@cs.ucl.ac.uk, malloc@catarina.usc.edu Subject: Re: comments on simple multicast In-reply-to: Your message of "Tue, 22 Dec 1998 16:54:49 +0100." <199812221554.QAA03583@dumbo.fokus.gmd.de > Date: Tue, 22 Dec 1998 11:02:53 -0500 Message-ID: <18344.914342573@north.lcs.mit.edu> Sender: owner-malloc@catarina.usc.edu Precedence: bulk >> .... Speaking AAP is a bit >> harder than speaking MDHCP, so you wouldn't want normal apps to have >> to do so, but if you need that degree of control, that's where you fit >> in the architecture. > >and I'd add (now from apps viewpoint) that "normal apps" should delegate >this direct AAP talk to a [Internet-based] middleware. Yes, that's the purpose of the MALLOC abstract API and MDHCP. Mark From owner-malloc@catarina.usc.edu Tue Dec 22 12:43:00 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id MAA02582 for ; Tue, 22 Dec 1998 12:43:00 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id JAA11229 for malloc-list; Tue, 22 Dec 1998 09:17:05 -0800 Received: from smtpott1.nortel.ca (smtpott1.nortel.ca [192.58.194.78]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id JAA11225 for ; Tue, 22 Dec 1998 09:16:57 -0800 Received: from zcars01t by smtpott1; Tue, 22 Dec 1998 12:16:37 -0500 Received: from zcard00n.ca.nortel.com by zcars01t; Tue, 22 Dec 1998 12:16:01 -0500 Received: from zcard008.ca.nortel.com by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id ZHLXHAFK; Tue, 22 Dec 1998 12:16:02 -0500 Received: from zgtys001.ca.nortel.com by zcard008.bnr.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id ZBN49AT9; Tue, 22 Dec 1998 12:15:58 -0500 Message-ID: <367FD3D0.38D451B3@nortel.com> Date: Tue, 22 Dec 1998 12:16:00 -0500 From: "Cheng-Yin Lee" X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.6 sun4u) MIME-Version: 1.0 To: Mark Handley CC: Mikhail Smirnov , carlberg@time.saic.com, idmr@cs.ucl.ac.uk, malloc@catarina.usc.edu Subject: Re: comments on simple multicast References: <18267.914341454@north.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Mark Handley wrote: > Yes, one of the intentions behind the architecture is that those rare > applications with special needs can bypass > the-protocol-formerly-known-as-MDHCP and actually be be MAAS's and > speak AAP directly. Then, within *very* broad bounds set my MASC, > they can do their own address management. > > We believe those applications are rare (normal apps use MDHCP), but > fully expect that they will probably exist. Speaking AAP is a bit > harder than speaking MDHCP, so you wouldn't want normal apps to have > to do so, but if you need that degree of control, that's where you fit > in the architecture. This may be a case where Simple Multicast can an 'alternative' solution ... cyl From owner-malloc@catarina.usc.edu Tue Dec 22 13:31:40 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id NAA03198 for ; Tue, 22 Dec 1998 13:31:40 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id JAA11271 for malloc-list; Tue, 22 Dec 1998 09:44:25 -0800 Received: from VNET.IBM.COM (vnet.ibm.com [204.146.168.194]) by catarina.usc.edu (8.6.10/8.6.9) with SMTP id JAA11267 for ; Tue, 22 Dec 1998 09:44:20 -0800 Received: from IPNET by VNET.IBM.COM (IBM VM SMTP V2R4) with BSMTP id 9336; Tue, 22 Dec 98 12:42:13 2 E Received: by IPNET (XAGENTA 4.0) id 9610; Tue, 22 Dec 1998 12:42:14 -0500 Received: from zeus.tampa.advantis.com (zeus.tampa.advantis.com [164.120.65.184]) by dkpc2.tampa.advantis.com (AIX4.2/UCB 8.7/8.7/RTP-ral-1.0) with SMTP id MAA24162; Tue, 22 Dec 1998 12:42:12 -0500 (EST) Message-Id: <4.1.19981222122024.00b3fb80@www.tampa.advantis.com> X-Sender: krinos@www.tampa.advantis.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 22 Dec 1998 12:38:01 -0500 To: Steve Hanna From: "Dimitri Krinos" Subject: Re: Confirmation of rough consensus Cc: malloc@catarina.usc.edu In-Reply-To: <199812212151.QAA27985@bcn.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-malloc@catarina.usc.edu Precedence: bulk I don't agree that the name of MDHCP should be changed just because the protocol is diverging from DHCP. Multicast Dynamic Host Configuration Protocol is a functional description and IMHO does not need to imply a technical similarity to the DHC Protocol. So far, all the suggestions I have seen for new names do not properly convey a clear functional description like MDHCP does. When you remove the words DYNAMIC, HOST, and CONFIGURATION, you lose important meaning. Changing the name just for the sake of changing the name will end up with an acronym that is confusing and non-informative. I'll bet that if the name is changed, people will still use MDHCP to desribe the protocol anyway since there is so much familiarity with DHCP now. There's my two cents worth... Regards & Happy Holidays, Dimitri Krinos At 04:51 PM 12/21/98 -0500, Steve Hanna wrote: >I would like to confirm that we have reached rough consensus on the following >decisions regarding MDHCP. These decisions were agreed to at the malloc >working >group meeting in Orlando (12/10/98). If you would like to raise any issues >regarding them, please do so now. > >Thanks, > >Steve Hanna > >----------- > >1) Remove reserved fields and add version in header >2) Add security based on IPsec >3) Make option type and length two bytes long >4) Remove references to allocation scope >5) Add IPv6 support via address type fields >6) Renumber options to start with 1 >7) Change name to something other than MDHCP > From owner-malloc@catarina.usc.edu Tue Dec 22 14:26:54 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id OAA03993 for ; Tue, 22 Dec 1998 14:26:54 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id LAA11732 for malloc-list; Tue, 22 Dec 1998 11:02:15 -0800 Received: from motgate2.mot.com (motgate2.mot.com [129.188.136.102]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id LAA11728 for ; Tue, 22 Dec 1998 11:02:09 -0800 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (8.8.5/8.6.10/MOT-3.8) with ESMTP id NAA16425 for ; Tue, 22 Dec 1998 13:03:57 -0600 (CST) Comments: ( Received on motgate2.mot.com from client pobox.mot.com, sender Roger_Kermode-ARK008@email.mot.com ) Received: from m-il06-r4.mot.com (m-il06-r4.mot.com [129.188.137.196]) by pobox.mot.com (8.8.5/8.6.10/MOT-3.8) with ESMTP id NAA15482 for ; Tue, 22 Dec 1998 13:02:04 -0600 (CST) Received: from mail.ccrl.mot.com by m-il06-r4.mot.com with ESMTP for malloc@catarina.usc.edu; Tue, 22 Dec 1998 12:02:04 -0700 Received: from ccrl.mot.com ([182.1.14.12]) by mail.ccrl.mot.com (Netscape Messaging Server 3.6) with ESMTP id AAA38C1; Tue, 22 Dec 1998 13:02:02 -0600 Message-Id: <367FECAA.4573D899@ccrl.mot.com> Date: Tue, 22 Dec 1998 13:02:02 -0600 From: Roger Kermode-ARK008 X-Mailer: Mozilla 4.5 [en] (X11; I; HP-UX B.10.20 9000/735) X-Accept-Language: en MIME-Version: 1.0 To: Dimitri Krinos CC: malloc@catarina.usc.edu Subject: Re: Confirmation of rough consensus References: <4.1.19981222122024.00b3fb80@www.tampa.advantis.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Given that MDHCP 1) is all about hosts obtaining one or multicast addresses from a server, 2) is not about configuring a host, but a session or sessions that run on the host, and 3) is no longer syntactically equivalent with DHCP I think it appropriate to change the name to sonmething other than MDHCP. Like Mark I have reservations about adopting MAAP because it causes confusion with the AAP servers. For want of a better alternative I think we should go with Multicast Address Reservation Protocol (MARP) I have no objections to the other 6 items put forward. cheers, Roger -- Dr. Roger Kermode kermode@ccrl.mot.com tel : +1 847 538 4587 Digital Technology Research Laboratory fax : +1 847 538 4593 Motorola, 1301 East Algonquin Rd, MS IL02-2712, Schaumburg, IL 60196 USA Dimitri Krinos wrote: > I don't agree that the name of MDHCP should be changed just because the > protocol is diverging from DHCP. > > Multicast Dynamic Host Configuration Protocol is a functional description > and IMHO does not need to imply a technical similarity to the DHC Protocol. > > So far, all the suggestions I have seen for new names do not properly > convey a clear functional description like MDHCP does. When you remove the > words DYNAMIC, HOST, and CONFIGURATION, you lose important meaning. > Changing the name just for the sake of changing the name will end up with > an acronym that is confusing and non-informative. > > I'll bet that if the name is changed, people will still use MDHCP to > desribe the protocol anyway since there is so much familiarity with DHCP now. > > There's my two cents worth... > > Regards & Happy Holidays, > Dimitri Krinos > > At 04:51 PM 12/21/98 -0500, Steve Hanna wrote: > >I would like to confirm that we have reached rough consensus on the following > >decisions regarding MDHCP. These decisions were agreed to at the malloc > >working > >group meeting in Orlando (12/10/98). If you would like to raise any issues > >regarding them, please do so now. > > > >Thanks, > > > >Steve Hanna > > > >----------- > > > >1) Remove reserved fields and add version in header > >2) Add security based on IPsec > >3) Make option type and length two bytes long > >4) Remove references to allocation scope > >5) Add IPv6 support via address type fields > >6) Renumber options to start with 1 > >7) Change name to something other than MDHCP > > From owner-malloc@catarina.usc.edu Tue Dec 22 15:07:10 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id PAA05431 for ; Tue, 22 Dec 1998 15:07:10 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id LAA11860 for malloc-list; Tue, 22 Dec 1998 11:37:20 -0800 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id LAA11856 for ; Tue, 22 Dec 1998 11:37:14 -0800 Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA18739 for ; Tue, 22 Dec 1998 11:36:42 -0800 Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id OAA19294; Tue, 22 Dec 1998 14:36:30 -0500 Received: from bcn.East.Sun.COM (bcn [129.148.75.4]) by suneast.East.Sun.COM (8.9.1b+Sun/8.8.8) with SMTP id OAA12833 for ; Tue, 22 Dec 1998 14:36:16 -0500 (EST) Received: from pine by bcn.East.Sun.COM (SMI-8.6/SMI-SVR4) id OAA01276; Tue, 22 Dec 1998 14:36:13 -0500 Message-Id: <199812221936.OAA01276@bcn.East.Sun.COM> Date: Tue, 22 Dec 1998 14:36:14 -0500 (EST) From: Steve Hanna Reply-To: Steve Hanna Subject: Re: New name for MDHCP To: malloc@catarina.usc.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: whiN54r7MwlWd9r92Iq9EQ== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-malloc@catarina.usc.edu Precedence: bulk I would like to get Multicast Address in there somewhere. Client or host would be good too. Allocation would be ideal, since that's really the *main* point, although returning scope list is good too. As Mark has said, there are many choices. My favorite so far: Multicast ADdress Client Allocation Protocol (MADCAP) (thanks to Nair Venugopal ) -Steve From owner-malloc@catarina.usc.edu Tue Dec 22 15:57:11 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id PAA07027 for ; Tue, 22 Dec 1998 15:57:11 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id MAA12033 for malloc-list; Tue, 22 Dec 1998 12:16:08 -0800 Received: from mailhub.fokus.gmd.de ([193.174.154.14]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id MAA12029 for ; Tue, 22 Dec 1998 12:15:59 -0800 Received: from dumbo.fokus.gmd.de (dumbo [193.175.132.239]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id VAA17753; Tue, 22 Dec 1998 21:15:51 +0100 (MET) From: Mikhail Smirnov Received: (mis@localhost) by dumbo.fokus.gmd.de (SMI-8.6/8.6.12) id VAA03680; Tue, 22 Dec 1998 21:15:47 +0100 Date: Tue, 22 Dec 1998 21:15:47 +0100 Message-Id: <199812222015.VAA03680@dumbo.fokus.gmd.de > To: krinos@VNET.IBM.COM, Roger_Kermode-ARK008@email.mot.com Subject: Re: Confirmation of rough consensus Cc: malloc@catarina.usc.edu X-Sun-Charset: US-ASCII Sender: owner-malloc@catarina.usc.edu Precedence: bulk On Tue Dec 22 20:05:35 1998 Roger Kermode wrote: ... > Like Mark I have reservations about adopting MAAP because it causes > confusion with the AAP servers. For want of a better alternative I think we > should go with Multicast Address Reservation Protocol (MARP) Two comments against MARP: 1. it sounds very much like Multicast Address Resolution Protocol (ION WG spells MARP as "ATMARP" but MARS (rfc2022) is known to be applicable to NBMA other than ATM only), 2. There is S. Hanna's draft (draft-hanna-marp-00.txt) on Multicast Address Request Protocol (MARP) Regards Michael From owner-malloc@catarina.usc.edu Wed Dec 23 00:52:21 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id AAA19319 for ; Wed, 23 Dec 1998 00:52:21 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id VAA13262 for malloc-list; Tue, 22 Dec 1998 21:28:29 -0800 Received: from proxy4.ba.best.com (root@proxy4.ba.best.com [206.184.139.15]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id VAA13258 for ; Tue, 22 Dec 1998 21:28:24 -0800 Received: from mg130-105.ricochet.net (mg130-105.ricochet.net [204.179.130.105]) by proxy4.ba.best.com (8.9.1/8.9.0/best.out) with SMTP id VAA29720 for ; Tue, 22 Dec 1998 21:27:39 -0800 (PST) Message-Id: <3.0.5.16.19981222212635.303f1e5a@shell7.ba.best.com> X-Sender: rsf@shell7.ba.best.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (16) Date: Tue, 22 Dec 1998 21:26:35 To: malloc@catarina.usc.edu From: Ross Finlayson Subject: Re: New name for MDHCP In-Reply-To: <199812221936.OAA01276@bcn.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-malloc@catarina.usc.edu Precedence: bulk At 02:36 PM 12/22/98 -0500, Steve Hanna wrote: >My favorite so far: > >Multicast ADdress Client Allocation Protocol (MADCAP) I like this, too. (Perhaps the "D" could stand for "Dynamic"?) Ross. From owner-malloc@catarina.usc.edu Wed Dec 23 09:43:47 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id JAA29327 for ; Wed, 23 Dec 1998 09:43:47 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id GAA14358 for malloc-list; Wed, 23 Dec 1998 06:09:19 -0800 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id GAA14354 for ; Wed, 23 Dec 1998 06:09:15 -0800 Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA11540; Wed, 23 Dec 1998 06:08:43 -0800 Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id JAA23640; Wed, 23 Dec 1998 09:08:35 -0500 Received: from bcn.East.Sun.COM (bcn [129.148.75.4]) by suneast.East.Sun.COM (8.9.1b+Sun/8.8.8) with SMTP id JAA26204; Wed, 23 Dec 1998 09:08:36 -0500 (EST) Received: from pine by bcn.East.Sun.COM (SMI-8.6/SMI-SVR4) id JAA04719; Wed, 23 Dec 1998 09:08:34 -0500 Message-Id: <199812231408.JAA04719@bcn.East.Sun.COM> Date: Wed, 23 Dec 1998 09:08:35 -0500 (EST) From: Steve Hanna Reply-To: Steve Hanna Subject: Re: New name for MDHCP To: finlayson@live.com Cc: malloc@catarina.usc.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: e41quTgNr5RLbNgboJx/bA== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-malloc@catarina.usc.edu Precedence: bulk > >My favorite so far: > > > >Multicast ADdress Client Allocation Protocol (MADCAP) > > I like this, too. (Perhaps the "D" could stand for "Dynamic"?) Good idea. -Steve From owner-malloc@catarina.usc.edu Wed Dec 23 12:33:25 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id MAA03002 for ; Wed, 23 Dec 1998 12:33:25 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id JAA14654 for malloc-list; Wed, 23 Dec 1998 09:06:44 -0800 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id JAA14650 for ; Wed, 23 Dec 1998 09:06:39 -0800 Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA24049 for ; Wed, 23 Dec 1998 09:06:06 -0800 Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id MAA27559; Wed, 23 Dec 1998 12:01:29 -0500 Received: from bcn.East.Sun.COM (bcn [129.148.75.4]) by suneast.East.Sun.COM (8.9.1b+Sun/8.8.8) with SMTP id MAA01505 for ; Wed, 23 Dec 1998 12:01:21 -0500 (EST) Received: from pine by bcn.East.Sun.COM (SMI-8.6/SMI-SVR4) id MAA05304; Wed, 23 Dec 1998 12:01:20 -0500 Message-Id: <199812231701.MAA05304@bcn.East.Sun.COM> Date: Wed, 23 Dec 1998 12:01:20 -0500 (EST) From: Steve Hanna Reply-To: Steve Hanna Subject: malloc minutes submitted To: malloc@catarina.usc.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: eylserwOiVSMtEzqwwI37w== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-malloc@catarina.usc.edu Precedence: bulk I did not receive any comments on the draft minutes for the malloc working group at IETF 43 that I sent out last Friday. Therefore, I have submitted this draft to the IETF as the final minutes for our meeting. I have also posted the minutes to the malloc web site at the following URL: http://north.east.isi.edu/malloc/minutes.98.12.html -Steve From owner-malloc@catarina.usc.edu Thu Dec 24 14:17:56 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id OAA13483 for ; Thu, 24 Dec 1998 14:17:55 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id KAA17466 for malloc-list; Thu, 24 Dec 1998 10:53:06 -0800 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id KAA17462 for ; Thu, 24 Dec 1998 10:52:56 -0800 Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA10336 for ; Thu, 24 Dec 1998 10:52:24 -0800 Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id NAA15167; Thu, 24 Dec 1998 13:52:15 -0500 Received: from bcn.East.Sun.COM (bcn [129.148.75.4]) by suneast.East.Sun.COM (8.9.1b+Sun/8.8.8) with SMTP id NAA21611 for ; Thu, 24 Dec 1998 13:52:17 -0500 (EST) Received: from pine by bcn.East.Sun.COM (SMI-8.6/SMI-SVR4) id NAA09216; Thu, 24 Dec 1998 13:52:16 -0500 Message-Id: <199812241852.NAA09216@bcn.East.Sun.COM> Date: Thu, 24 Dec 1998 13:52:17 -0500 (EST) From: Steve Hanna Reply-To: Steve Hanna Subject: New version of MDHCP/MADCAP To: malloc@catarina.usc.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: QM57EmnjI8EdNrgqjg7DEg== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-malloc@catarina.usc.edu Precedence: bulk A new draft of the host-client protocol specification is now available from http://north.east.isi.edu/malloc/draft-ietf-malloc-madcap-02.txt. This draft has also been submitted to internet-drafts@ietf.org, so it should be available from the IETF eventually. Munil, Baiju, and I have made the changes agreed to at the malloc meeting at IETF 43. We have also made several other changes and simplifications requested by reviewers. A change log is included in Appendix B. Please review this draft and get comments to the list ASAP. I will make any necessary changes and post a draft for Working Group Last Call (in early January, I hope). Thanks, Steve P.S. I'm going with MADCAP as the name for now, since I haven't heard any objections to that name. If you have objections, please raise them. P.P.S. I will probably not be reading email until Monday, January 4.