Re: [MBONED] addrarch: MADCAP to historic?
Thomas Narten <narten@us.ibm.com> Mon, 22 January 2007 14:22 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H904C-0005u2-Ol; Mon, 22 Jan 2007 09:22:36 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H904B-0005tw-LE for mboned@ietf.org; Mon, 22 Jan 2007 09:22:35 -0500
Received: from e4.ny.us.ibm.com ([32.97.182.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H904A-0004zr-A8 for mboned@ietf.org; Mon, 22 Jan 2007 09:22:35 -0500
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.13.8/8.12.11) with ESMTP id l0MEMWnu023575 for <mboned@ietf.org>; Mon, 22 Jan 2007 09:22:32 -0500
Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0MEMVV9080888 for <mboned@ietf.org>; Mon, 22 Jan 2007 09:22:31 -0500
Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0MEMVeu029799 for <mboned@ietf.org>; Mon, 22 Jan 2007 09:22:31 -0500
Received: from cichlid (wecm-9-67-89-110.wecm.ibm.com [9.67.89.110]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0MEMVxi029769; Mon, 22 Jan 2007 09:22:31 -0500
Received: from cichlid (localhost.localdomain [127.0.0.1]) by cichlid (8.13.8/8.12.5) with ESMTP id l0MEK7ir019919; Mon, 22 Jan 2007 09:20:08 -0500
Message-Id: <200701221420.l0MEK7ir019919@cichlid>
To: David Kessens <david.kessens@nokia.com>
Subject: Re: [MBONED] addrarch: MADCAP to historic?
In-reply-to: <20070119232141.GE13098@nokia.com>
References: <200701191358.l0JDwKxk001681@cichlid> <D7889EF97F07A0458785320F43C43B6B02B4A318@xmb-sjc-228.amer.cisco.com> <20070119232141.GE13098@nokia.com>
Comments: In-reply-to David Kessens <david.kessens@nokia.com> message dated "Fri, 19 Jan 2007 15:21:41 -0800."
Date: Mon, 22 Jan 2007 09:20:07 -0500
From: Thomas Narten <narten@us.ibm.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: mboned@ietf.org
X-BeenThere: mboned@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mail List for the Mboned Working Group <mboned.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/mboned>
List-Post: <mailto:mboned@ietf.org>
List-Help: <mailto:mboned-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=subscribe>
Errors-To: mboned-bounces@ietf.org
David Kessens <david.kessens@nokia.com> writes: > There is a little bit more to this: > Are these existing implementations actually being used (anybody on > this list?) ? This question (by itself) does not seem particularly relevant to me. (I'm serious.) If there were an alternative technology that people preferred, or if there were known shortcomings with this technology, that would be useful to discuss. But if no one is using it, that could simply mean that (gasp) multicast has not taken off generally, and this is just one more example of collatoral damage. It does not immediately follow that this technology is flawed and needs to be taken off Standards Track. > If not so, are we not sticking our head in the sand if we keep > recommending a particular solution that apparently doesn't address a > problem in the marketplace? If no one is using it, and no one seems to be confused by it being on the Standards Track, what harm is there in leaving well enough alone? We have plenty of more important things to do IMO, then reclassify documents when the status quo is not causing any problems. What problem needs fixing here? Aren't there more pressing things to do with our precious cycles? Thomas _______________________________________________ MBONED mailing list MBONED@ietf.org https://www1.ietf.org/mailman/listinfo/mboned
- [MBONED] addrarch: eGLOP and MADCAP to historic? Pekka Savola
- Re: [MBONED] addrarch: eGLOP and MADCAP to histor… David Meyer
- Re: [MBONED] addrarch: eGLOP and MADCAP to histor… David Kessens
- Re: [MBONED] addrarch: eGLOP and MADCAP to histor… Toerless Eckert
- Re: [MBONED] addrarch: eGLOP and MADCAP to histor… Marshall Eubanks
- Re: [MBONED] addrarch: eGLOP and MADCAP to histor… Toerless Eckert
- Re: [MBONED] addrarch: MADCAP to historic? Pekka Savola
- [MBONED] addrarch: IANA assignment policies and e… Pekka Savola
- Re: [MBONED] addrarch: MADCAP to historic? Thomas Narten
- RE: [MBONED] addrarch: MADCAP to historic? John Meylor (jmeylor)
- Re: [MBONED] addrarch: MADCAP to historic? David Kessens
- RE: [MBONED] addrarch: MADCAP to historic? Dave Thaler
- Re: [MBONED] addrarch: MADCAP to historic? Thomas Narten
- Re: [MBONED] addrarch: IANA assignment policies a… Leonard Giuliano
- Re: [MBONED] addrarch: IANA assignment policies a… Pekka Savola
- Re: [MBONED] addrarch: IANA assignment policies a… Leonard Giuliano
- Re: [MBONED] addrarch: IANA assignment policies a… Marshall Eubanks
- Re: [MBONED] addrarch: IANA assignment policies a… Toerless Eckert
- Re: [MBONED] addrarch: IANA assignment policies a… David Meyer
- Re: [MBONED] addrarch: IANA assignment policies a… Leonard Giuliano
- Re: [MBONED] addrarch: IANA assignment policies a… Toerless Eckert
- Re: [MBONED] addrarch: IANA assignment policies a… Leonard Giuliano
- Re: [MBONED] addrarch: IANA assignment policies a… Marshall Eubanks
- RE: [MBONED] addrarch: IANA assignment policies a… Manfredi, Albert E
- Re: [MBONED] addrarch: IANA assignment policies a… Dave Price
- Re: [MBONED] addrarch: IANA assignment policies a… Marshall Eubanks
- Re: [MBONED] addrarch: IANA assignment policies a… Toerless Eckert