What about: Formal IAB appeal: IESG paralysis and inactivity

"Erik Huizer (SURFnet BV)" <Erik.Huizer@surfnet.nl> Wed, 01 March 1995 08:57 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00454; 1 Mar 95 3:57 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00450; 1 Mar 95 3:57 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa00915; 1 Mar 95 3:57 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00442; 1 Mar 95 3:57 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00438; 1 Mar 95 3:57 EST
Received: from survis.surfnet.nl by CNRI.Reston.VA.US id aa00910; 1 Mar 95 3:57 EST
Received: from survival.surfnet.nl by survis.surfnet.nl with SMTP (PP); Wed, 1 Mar 1995 09:50:12 +0100
To: IESG <iesg@CNRI.Reston.VA.US>
Subject: What about: Formal IAB appeal: IESG paralysis and inactivity
Organisation: SURFnet bv
Address: Cluetinckborch, P.O. Box 19035, 3501 DA Utrecht, NL
Phone: +31 30 310290
Telefax: +31 30 340903
Date: Wed, 01 Mar 1995 09:50:05 +0100
X-Orig-Sender: iesg-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Erik Huizer (SURFnet BV)" <Erik.Huizer@surfnet.nl>
Message-ID: <9503010357.aa00910@CNRI.Reston.VA.US>

I suggest that the iesg come out with a statement asap, otherwise we prove
Marshall's point by inaction.

As I realise we cannot get unanimity on the subject, I suggest we send out
at least something like Joel's line of reasoning. I know Marshal disagrees
with tyhat, and has good reasons to. It at least shows that it is not just
the iesg to blame.

We have to take part of the blame in this, regardless of the fact that the
same person who is now slinging mud was part of the iesg when the mess was
created. 

My position is that we send out a statement shortly saying:

1- We took too long, and have erred (In American: we f..ked up)
2- The process as described in RFC 1602 is to restrictive for this issue 
   to be resolved formally. This is the IESG's axcuse
3- We cannot wait for the RFC1602 to resolve itself (although this should
   happen)
4- We will ask the community what it thinks about the issues:
   - not whole RPC
   - patent issue
   - quality of RPC (do we need it)
   during the iesg plenary
5- We will act on a clear concensus of the IETF community, regardless of RFC
   1602.


Your comments please.

Erik
(Who couldn't care less about SUNs RPC personally, but as an IESG member
thinks this needs to be resolved quickly).