Re: comments on your comments....

John C Klensin <klensin@mail1.reston.mci.net> Thu, 02 March 1995 12:26 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01256; 2 Mar 95 7:26 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01252; 2 Mar 95 7:26 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03434; 2 Mar 95 7:26 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01245; 2 Mar 95 7:26 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01241; 2 Mar 95 7:26 EST
Received: from mail1.Reston.mci.net by CNRI.Reston.VA.US id aa03429; 2 Mar 95 7:26 EST
Received: from klensin (klensin.Reston.mci.net) by MAIL1.RESTON.MCI.NET (PMDF V4.3-10 #8388) id <01HNNHT8Y928000HWO@MAIL1.RESTON.MCI.NET>; Thu, 02 Mar 1995 07:26:20 -0500 (EST)
Date: Thu, 02 Mar 1995 07:26:27 -0500
X-Orig-Sender: iesg-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: John C Klensin <klensin@mail1.reston.mci.net>
Subject: Re: comments on your comments....
X-Sender: klensin@mail1.reston.mci.net
To: IETF NM-AD <mrose.iesg@dbc.mtview.ca.us>, Mike O'Dell <mo@uunet.uu.net>
Cc: iesg@CNRI.Reston.VA.US
Message-id: <01HNNHTA9I0Y000HWO@MAIL1.RESTON.MCI.NET>
X-Envelope-to: iesg@CNRI.Reston.VA.US
MIME-version: 1.0
X-Mailer: Windows Eudora Version 2.0.3
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7BIT

Marshall,

AT&T has never sued me.

And _my_ boss thinks, most of the time, that  the IETF is the greatest thing
since sliced bread.

And I find myself feeling, ever more strongly, that, if a deal with Sun
can't be cut using the 1602 procedures, the right path is to fix 1602 and
then do a deal under 1602bis, rather than doing an exceptional deal.    If
there is really strong community consensus behind exceptional arrangements,
then it ought to be possible, in rather short order, to alter 1602 to
recognize such exceptional situations and bring them within the framework.

In that regard, everyone has been assuming that "revising 1602" implies that
we open it up and go through all of the identified loose ends and problems
and that doing so requires reactivating POISED and waiting for it to do its
thing.  I think that is the right thing to do under reasonable and normal
circumstances.  But the circumstances are arguably not "reasonable and
normal" if, indeed, the delay on ONR/RPC has created a real problem for the
community or a real block to the advancement and spread of the Intenet.
While I'm very irritated at the delay in doing  _something_ about this, I
just haven't seen the symptoms of protocol-damage or Internet-improvement
damage due to delay.  But I may not be looking in the right places.

In any event, if the aspects of 1602 that are involved in this problem is a
crisis that is more important that other 1602 problems, we even have a
history and procedure for dealing with that type of situation:  some
individual or design team puts together a document that proposes a specific
modification to 1602, posts it as an I-D, has some mailing list discussion
to focus community consensus, and then gets a Last Call issued.   If IESG
declined to handle that proposal/request in a timely way, e.g., on the
grounds that POISED 2 needed to review it, there would be clear grounds for
an appeal within the 1602 procedures.

For all I know, we should institutionalize a procedure for getting a mob
together to accept something in the name of the community whenever the more
regular procedures are, in the opinion of the mob or its leaders, too slow.
We might even be able to figure out how large the mob had to be to decide it
constituted community consensus.  It might provide a better safety valve
than periodic instances of "warpaths" or "bloodbaths".     But let's see if
there is really community consensus behind that notion, rather than
discarding both our procedures and our meta-procedures for making procedures
when they become inconvenient or too tedious.

     john