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

["Mike Hammer (hmmr)" <[e-mail]>]

The way it works in some groups is to take a stand:  We will put the
document out by this deadline!

Then ask:  How many kitchen sinks can get fit into that deadline?

Mike


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> [e-mail]
> Sent: Friday, February 20, 2009 4:43 AM
> To: Cullen Jennings (fluffy); [e-mail]
> Subject: Re: [RAI] The Cluster Idea ... was RAI reorganization -
Clusters
> 
> 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
> >
> _______________________________________________
> RAI mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rai