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

[Cullen Jennings <[e-mail]>]

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
>>