Re: RPC working group

IETF NM-AD <mrose.iesg@dbc.mtview.ca.us> Wed, 01 March 1995 18:40 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07806; 1 Mar 95 13:40 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07802; 1 Mar 95 13:40 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10804; 1 Mar 95 13:40 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07781; 1 Mar 95 13:40 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07777; 1 Mar 95 13:40 EST
Received: from ppp.dbc.mtview.ca.us by CNRI.Reston.VA.US id aa10793; 1 Mar 95 13:40 EST
Received: from dbc.mtview.ca.us by dbc.mtview.ca.us (5.65/3.1.090690) id AA29450; Wed, 1 Mar 95 10:39:56 -0800
X-Orig-Sender: iesg-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: IETF NM-AD <mrose.iesg@dbc.mtview.ca.us>
To: Mike O'Dell <mo@uunet.uu.net>
Cc: iesg@CNRI.Reston.VA.US
Subject: Re: RPC working group
In-Reply-To: Your message of "Tue, 28 Feb 1995 18:33:30 EST." <QQyfcg06555.199502282333@rodan.UU.NET>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Id: <29389.794083093.1@dbc.mtview.ca.us>
Date: Wed, 01 Mar 1995 10:38:15 -0800
Message-Id: <29404.794083095@dbc.mtview.ca.us>
X-Orig-Sender: mrose@dbc.mtview.ca.us

> I've been ruminating on your call to arms and am stuck on a point, so
> maybe you can help me out here.

here we go...


> I claim the only way the working group could have been validly
> chartered is that it's work output must be subject to the RFC1602
> process definition, which was in place at the time.  That is, RFC 1602
> contains the terms and conditions of the contract and the RPC working
> group was no different in this respect.  Therefore, any work output
> progressing was *known* to be contingent upon successful satisfaction
> of the requirements in RFC1602 when the WG was chartered.

i think that you are putting procedures before process.  1602 is a set
of rules that was supposed to reflect the IETF's goals of progress,
openness, fairness, concensus.  1602 is now proven to be a poor
reflection of that.

when confronted with such a dilemna, the IESG can either blindly follow
broken rules, or it can get work done.

thus, the correct path for the IESG is to proceed in a fashion which
fosters progress and honors openness, fairness, and concensus.


> Given this, I have a little trouble with the claim that because the
> requirements were not met there is a violation of "honor" with respect
> to letting the WG proceed in spite of failing to meet RFC1602.

not really honor, but rather competence (that's why the word was in
quotation marks).


> It was known by all concerned going into it that this WG was the first
> time the 1602 transfer process was going to be executed, and for
> experienced protocol designers to express surprise and aggrevation
> when a bug was found in the first execution of a complex protocol
> is just a tad curious.

the rule *follows* procedure, it does not dictate it.  that is the key
issue the majority of the IESG is unable to grasp.


> I do understand the feelings about this having taken a long time.  I had
> initially agreed to chair the ONC WG, so I think it's clear that I'm not
> exactly disinterested in the outcome.
> 
> However, unless someone wishes to claim *directly* that some party was
> acting in bad faith, and wishes to back up that statement, the only
> conclusion I can reach is that

with respect to bad faith, the smoking gun is quite clear: the IESG
allowed this to drag on, and on, and on.  the community doesn't care
about excuses, it cares about results.  the IESG isn't doing its job.
its job is to get results, not to make like the energizer bunny.


> 	(1) people worked hard, in good faith, trying to reach
> 	    a satisfactory conclusion, but....
> 
> 	(2) the 1602 process is hoplessly screwed and will not ever
> 	    produce the desired result, so it must be changed.
> 
> If someone wishes to argue
> 
> 	"You shoulda given up sooner"
> 
> then I claim that's an easy thing to say in hindsight, albeit
> possibly true in retrospect. 

fix the problem, not the blame.  it's the IESG's job to make things
work.  cowering behind the skirts of 1602, or the legendary incompetence
of the ISOc, isn't exactly what i would view as a good defense.


> 
> But the culture is one where people continue to work on hard
> problems attempting to resolve them, and they don't give up easily.

with the exception, of course, of the IESG.


> I think that this time the culture worked against us.
> But that's no reason to jettison the culture.

the thrashing that the IESG is taking is entirely consistent with the
way things are done in the community...

/mtr