Latest Informational Draft
Joel Halpern <jhalpern@us.newbridge.com> Wed, 27 March 1996 15:47 UTC
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17335; 27 Mar 96 10:47 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa17331; 27 Mar 96 10:47 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08343; 27 Mar 96 10:47 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17323; 27 Mar 96 10:47 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa17319; 27 Mar 96 10:47 EST
Received: from ns.newbridge.com by CNRI.Reston.VA.US id aa08338; 27 Mar 96 10:47 EST
Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id KAA03293 for <iesg@cnri.reston.va.us>; Wed, 27 Mar 1996 10:47:14 -0500
Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma003252; Wed Mar 27 10:46:59 1996
Received: from mako.us.Newbridge.com (mako.us.newbridge.com [138.120.85.99]) by kanmaster (8.6.12/8.6.12) with SMTP id KAA14718 for <iesg@cnri.reston.va.us>; Wed, 27 Mar 1996 10:46:52 -0500
Received: from lobster.newbridge by mako.us.Newbridge.com (4.1/SMI-4.0) id AA09176; Wed, 27 Mar 96 10:36:56 EST
Received: by lobster.newbridge (5.0/SMI-SVR4) id AA00498; Wed, 27 Mar 1996 10:43:49 +0500
Date: Wed, 27 Mar 1996 10:43:49 +0500
X-Orig-Sender: iesg-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Joel Halpern <jhalpern@us.newbridge.com>
Message-Id: <9603271543.AA00498@lobster.newbridge>
To: iesg@CNRI.Reston.VA.US
Subject: Latest Informational Draft
X-Sun-Charset: US-ASCII
Content-Length: 2289
We have been handed the notice (reproduced after this message) about an internet draft called "Introduction to IP Multicast Routing". It is written by two individuals at 3Com. Its primary focus is ostensibly to describe the protocols for mutlicast routing, most of which are under development within the IDMR working group. Neither the IDMR nor the MOSPF working groups have ever seen this document which claims to be describing their work. My strongest basis for asking that this be completely refused publication is that it would be an RFC which claims to document a protocol, before that protocol has been published in RFC form. The document describes DVMRP, including heirarchical DVMRP, and PIM. These are under development and subject to change before they are published as RFCs. (The fact that even then they may get experimental status is irrelevant for now.) Further, the level of detailed correctness review which should be applied to this document is entirely in-appropriate for the form of submission. If the working groups had felt that a document of this type were necessary, they would have proposed writing it. I would feel it was an in-appropriate imposition on the working group to tell them "you must review this proposal for correctness." Stepping back for a moment, if Steve Deering had submitted this, I would probably be willing to go ask him why he was taking this route. I suppose one could argue that I should do the same with these authors. However, since this is a document which is even less useful than the classic "much needed gap", I am loath to put effort into trying to determine how to make it useful. [Such aspects as the fact that it omits CBT from its sequential descriptions of actual protocols would be a problem to be dealt with if publication were necessary.] Is there any way to just say no? Or can Joe random person walk in, write a summary of other work going on in the IETF, and get it published as an informational RFC? Yours, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. PS Yes, if I were told that Steve Deering and Deborah Estrin had been consulted beforehand, I would be more confident of the technical correctness of this document. But I would still be uncomfortable with its publication.
- Latest Informational Draft Joel Halpern
- Re: Latest Informational Draft Joel Halpern