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.