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

[Henry Sinnreich <[e-mail]>]

Christian,

>- Keep Test Standard simple, to motivate implementation (as precondition for proceeding to proposed standard).
>- Force a proof of concept before further progress

I totally agree, just not only for "Test Standards" but for all standards. Incidentally, one measure of good laws in society is they should be simple enough to be understood by everybody. Good governance - IETF RAI in case - also requires the number of laws to be as limited as possible :-)

>- Reduce the number of proposed standards, which are never deployed.

The above will contribute to this anyway, though deprecating older SIP standards, including those developed for closed networks that contradict e2e, transparency and threaten privacy must be deprecated IMO to keep SIP viable on the Internet.
Every SIP standard or informational RFC that includes intermediaries beyond the trapezoid model fall in this category.
Why "SIP server clouds" are computationally questionable is another topic we must give serious consideration - not to be confused with using cloud computing for SIP that seems to have been totally overlooked in SIP/RAI work.

Thanks for your good points,
Henry


On 2/20/09 1:59 AM, "Schmidt, Christian 1. (NSN - DE/Munich)" <[e-mail]> wrote:

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