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

[<[e-mail]>]

Hi Cullen,

Cullen Jennings wrote:
>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.

There is one good reason why people want their favorite kitchen-sink options to be included in the base spec. That's because they are worried that if the feature does not get in and a new draft needs to be started, it means at least 3 years more waiting, however trivial the extension might be. So to be succesful with your model we would need two things:
a) be very critical of adding new features (that are such that they *can* be added later on) to our core specs.
b) make it easy to add such niche features later on without having to convince two WGs and five review teams that the feature is really needed. (Often we end up in debates where there is essentially nothing wrong with the original proposal but other people are able to point out that there are two other ways of doing the same.) --> in this sense the RAI reorg proposal is heading to the absolutely right direction!

The downside of this minimum baseline + "unleashed" extensions approach is that we get even more RFCs than before, something that people already complain about. But maybe it's still better than the current situation where people often still implement some subset of an RFC that has too much in it.

For instance wrt. XCAP it seems that most people would be fine to implement PUT/GET/DELETE for the "full documents" while they see the subdocument operations complicated with limited value (which is kind of true -- as long as the document sizes are small it does not matter that much. And if you omit the subdocument stuff no-one can claim XCAP complicated -- it's plain HTTP with some resouce naming rules). That approach is kind of possible with the XCAP RFC too, but there seems to be confusion around for instance how the client would know if the server only does full documents. Well, it's easy to be wise now...

Markus


>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On
>Behalf Of ext Cullen Jennings
>Sent: 19 February, 2009 21:37
>To: [e-mail]
>Cc: Isomaki Markus (Nokia-CIC/Espoo)
>Subject: Re: [RAI] The Cluster Idea ... was RAI reorganization
>- Clusters
>
>
>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
>