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

["Schmidt, Christian 1. (NSN - DE/Munich)" <[e-mail]>]

Hi Henry,
 
so what about the following four-tier model:
- Test Standard
- Proposed Standard
- Draft Standard
- Standard
 
To change status from Test Standard to Proposed Standard,  at least 2
independent implemenations are requested.
 
This could achieve the following:
- Keep Test Standard simple, to motivate implemenation (as precondition
for proceeding to proposed standard).
- Force a proof of concept before further progress
- Reduce the number of proposed standards, which are never deployed.
- Could in total reduce work load in RAI.
 
What do you think about?
 
Christian
 
 
Perhaps for certain cases, we need a four-tier model and a new

expression for the

"half-finished Proposed Standard"?

What about Beta-Proposed Standard (BPS) or Preliminary Standard (PrS)?

Christian


________________________________

From: [e-mail] [mailto:[e-mail]] On Behalf Of
ext Henry Sinnreich
Sent: Thursday, February 19, 2009 9:11 PM
To: Cullen Jennings; [e-mail]; HenningSchulzrinne
Cc: Markus Isomaki
Subject: Re: [RAI] The Cluster Idea ... was RAI reorganization -
Clusters


>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