Re: [RAI] The Cluster Idea ... was RAI reorganization - Clusters

[Henry Sinnreich <[e-mail]>]

>often we can not get enough people to agree to the reduced scope

Very true.

At this point in time it is productive to look at what Henning has proposed:

==============================================

"informal rule that a document isn't done until there's nothing left to *take
out*, but now it's more like "somebody wants it, so it goes in".

Having a model where we publish a short early version, while working
on the full-blown version, might be better. This is also similar to
the newer software development models of "ship early, ship often",
rather than the extreme waterfall model we're practicing, with all the
"frameworks" and "requirements" documents along the way.

==============================================

I will add my two cents that majority from a "Groupthink" minded attendance has little to do with technical merits. The technical proposals can be only validated by testing.

Reduced scope, "ready when nothing can be taken out" and testing must be mandated by the RAI A-D in the reorganization to make it successful. If need be, get approval from the IESG for this mandate.

Henry


On 2/19/09 1:37 PM, "Cullen Jennings" <[e-mail]> wrote:



One of the problems at IETF comes from the need for rough consensus -
often we can not get enough people to agree to the reduced scope -
MSRP and XCAP might be an examples of that.  I do like to break things
into as small as independent chunks as possible - I think that gets
them finished sooner and it allows topics where one can't get
consensus to get dropped. I realize it is apple pie, but one thing
that could a help in RAI is people trying to make ideas smaller.

If draft-x gets published at RFC 1234, we can start on 1234bis the day
1234 is published to add more to it. To make this successful we need
the people sitting in the WG *not* to hum yes when asked if they would
like to include the kitchen-sink option in draft-sip-super-simple. I
note the RAI WGs almost always hum yes to taking on more work. We have
the  combination of people who aren't going to do the work getting to
hum yes that someone else should do the work combined with only
volunteers with fairly erratic time commitments do the work. This
combination is not an ideal combination for speedy work but it is what
we have so we need to figure out how to make the best of it.

One of the hopes of Dispatch is that it could quickly spin up a way to
get a small focused set of work done, such as config.

On Feb 18, 2009, at 3:11 , Elwell, John wrote:

> I agree this seems to be a core part of the problem, and perhaps we
> have
> to limit scope sometimes to get things done in a more timely manner.
> If
> necessary we can use the Experimental category.
>
> John
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]
>> Sent: 18 February 2009 10:06
>> To: [e-mail]; Elwell, John;
>> [e-mail]; [e-mail]
>> Cc: [e-mail]
>> Subject: RE: [RAI] The Cluster Idea ... was RAI
>> reorganization - Clusters
>>
>> Hi,
>>
>> Hannes wrote:
>>>> People who are enthusiastic when an activity starts up become
>>>> completely bored with it when it is still continuing 4, 5 or
>>> more years
>>>> later. Examples are the config framework (SIPPING) and
>> outbound (SIP).
>>>
>>> In general, I don't understand this either but every document
>>> has it's own history.
>>> I think it is hard to generalize it.
>>>
>>
>> It is indeed hard to generalize but I think there is
>> something in common in the two examples given by John:
>> * Everyone agrees that they address an extremely critical
>> issue in SIP for which IETF so far has no proper standard (UA
>> auto-configuration, NAT traversal, respectively)
>> * Rather than solving the most pressing issue at hand, both
>> drafts took a very comprehensive and thus complicated
>> approach to the problem (config framework addresses a lot of
>> different scenarios, outbound mixes NAT traversal with server
>> redundancy)
>> * Many people got scared that the full solution provided by
>> the drafts is too much and as the IETF work never got
>> finished most implementations solved the key problems on
>> their own ways (there are many autoconfig methods around,
>> similarly NAT keepalives are already well supported)
>> * Due to this development, it is no longer obvious if anyone
>> would care aout the IETF solutions even when they come out as
>> RFCs. And this explains the lack of enthusiams in the WGs
>> too, I think.
>>
>> The learning? IMHO: If there is a pressing issue, make a
>> point solution that is good enough rather than *only* work on
>> an all-encompassing framework to solve all related problems.
>> Because, we can never deliver those "full" solutions on time
>> before the market has already gone somewhere else. If the
>> full solution has real merit it will be adopted later on.
>>
>> Markus
>>

_______________________________________________
RAI mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rai