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
- Re: comments on your comments.... IETF NM-AD
- Re: comments on your comments.... IETF NM-AD
- Re: comments on your comments.... Marshall Rose
- Re: comments on your comments.... John C Klensin
- Re: comments on your comments.... stev
- Re: comments on your comments.... IETF NM-AD
- Re: comments on your comments.... John C Klensin
- Re: comments on your comments.... Joel Halpern