Subject: RE: engineering discipline WAS: stats from the text conferencing experiment

From: Andy Bierman <[email-masked]>
Date: Wed, 04 Dec 2002 16:00:01 -0800

At 05:16 PM 12/4/2002 -0600, Spencer Dawkins wrote:
>Sorry - I should have kept typing - 
>
>and one of the things we talked about in Atlanta was the desirability of using Experimental as a jumping-off point to Proposed Standard. 
>
>The recently-approved ABC draft includes an IESG note that says "this is Experimental, because it's TCP and we hate it when the Internet collapses, but if we get deployment experience that ABC DOESN'T collapse the Internet, we'll put it on the standards track" (the actual text is more formal, but you get the idea).
>
>Do we have a common view as to whether this is a good thing (based on the observation that many RFCs don't move past Proposed Standard, no matter how widely deployed the technology)?

This sounds like a valid case for sometimes publishing as Experimental 
instead of Proposed Standard, but this has nothing to do with the
WG process changes in Frank's proposal.  This is the statement in
Frank's email I object to:

    ...   The working group is there to provide 
    feedback and alternative views that X must consider 
    but need not adopt. for the most part, the decision is
    solely X's. <handwave-mode>Some things that the WG
    raises, X must adopt -- where those things are 'critical'
    to the Internet architecture/etc</handwave-mode>

This means that for all but the most critical decisions, the WG
consensus is not a significant factor in the output of the WG.
This is more power than even the WG Chair has now. The WG Editor
should write words that express the consensus of the WG, not decide
(or worse override) the consensus of the WG.

>Spencer

Andy

>> -----Original Message-----
>> From: Spencer Dawkins 
>> Sent: Wednesday, December 04, 2002 4:45 PM
>> To: [email-masked]
>> Subject: RE: engineering discipline WAS: stats from the text
>> conferencing experiment
>> 
>> 
>> If I got the drift from Frank's note, the idea was that we 
>> have experimental RFCs, not standards, when we can't agree on 
>> one alternative.
>> 
>> Spencer 
>> 
>> > -----Original Message-----
>> > From: Andy Bierman [mailto:[email-masked]]
>> > Sent: Wednesday, December 04, 2002 4:08 PM
>> > To: Randy Bush
>> > Cc: Frank Kastenholz; [email-masked]
>> > Subject: RE: engineering discipline WAS: stats from the text
>> > conferencing experiment
>> > 
>> > I think the notion of placing a document author in charge
>> > of the standards process for that document will lead to
>> > closed, rubber-stamped standards.  This idea would give
>> > the author too much power.  The author could effectively
>> > say "agree with me or we'll end up shutting down the WG
>> > or wasting a lot of time starting up and then choosing
>> > between alternative proposals."  In all but the most
>> > monumental, show-stopper deadlocks, the WG will let the
>> > author/dictator win every time, rather than face
>> > a restart or shutdown situation.
>> > 
>> > 
>> > >randy
>> > 
>> > Andy
>> > 
>> > 
>> > 
>> > 
>>

---

From: "Dean Willis" <[email-masked]>
Date: Wed, 4 Dec 2002 19:05:44 -0600

Andy objected to:
> Frank proposed:
> This means that for all but the most critical decisions, the 
> WG consensus is not a significant factor in the output of the 
> WG. This is more power than even the WG Chair has now. The WG 
> Editor should write words that express the consensus of the 
> WG, not decide (or worse override) the consensus of the WG.

Let's be realistic about how authorship works today. X publishes the doc
as an individual effort, goes through three or four revs as individual,
then gets the nod to make it a WG effort, revises it a little, and gets
a "stamp of approval" from the WG. If he doesn't get the nods, then the
doc either dies or wanders off into individual-land.

This is VERY different from the communal-drafting model of 3GPP, where
some poor sod gets "elected" editor, slaps some text together, and then
further progress is made by group review of individually-contributed
(and tracked) "change requests" or shared-screen "drafting sessions".
It's not fun. It's downright painful. I'd have to get PAID to do
something like that -- I certainly wouldn't VOLUNTEER. If we go that
route, I'm not just quitting, I'm doing something dramatic like changing
my name, pretending the Internet never happened, and raising goats in
the desert somewhere. Goat cheese, anybody?

--
Dean

---

From: Andy Bierman <[email-masked]>
Date: Wed, 04 Dec 2002 17:33:43 -0800

>doc either dies or wanders off into individual-land.

I think it's probably rare that a clueful and interested WG
agrees with every single technical decision made in an
individual submission.  It's also possible that multiple
individual submissions exist, and the WG needs to choose
between different solutions to the same problem.  That's
the WG's job.  In the event the WG is able to establish
consensus for a specific solution, then that solution should
be adopted.  That's the purpose of the IETF WG process.

>the desert somewhere. Goat cheese, anybody?

You misinterpreted my objection.  I said nothing about documentation
by committee. I don't care how 3GPP does its job. If WG consensus exists, 
then it should be honored. Otherwise, why bother using the WG process at all?  

Andy

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 04 Dec 2002 23:27:28 -0500

Andy Bierman wrote:
> individual submission. 

Definitely. However, I believe Dean is right that frequently, the 
author/editor is the primary technical driver of the work, and the 
working group serves as a point of review and input. Frequently they 
want things changed or fixed, but I have found that those changes are 
often at relatively low levels of detail. To make progress in the 
current model, where most of the work is done in the mailing list, you 
really need to start with general agreement on a document which serves 
as the foundation for the work, where the document is at the point of 
80-90% completion. That is to say, the working group consensus is, more 
or less, "that document is what we want", and the mailing list is used 
to facilitate review and help decide on a few remaining details and open 
issues.  Designing documents from the ground up on the mailing list is 
guaranteed to either fail completely or take forever. I have seen it 
tried on a few occassions (the early work in IMPP was one example) with 
bitter results.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com