[RAI] RAI reorganization

[Jon Peterson <jon.peterson at neustar.biz>]

Since the open area meeting in Minneapolis, Cullen and I have given some 
thought to the best way to try to act on the discussion and suggested 
changes. As a continuing part of that process, though certainly not the 
last step, we'd like some input from the community on the following 
proposal and accompanying draft.

We have long heard concerns about the perennially overworked SIP and 
SIPPING WGs, to say nothing of the general structure of long-lived 
working groups that serve as a standing army to attack problems as they 
arise. The main drawback of this structure is that these groups assume 
responsibility for rosters of known "hard" problems which seemingly 
never complete, while easier and more tactical work struggles for 
attention and participate energy gradually depletes. One wouldn't have 
to look hard in either of those groups for evidence of this phenomenon.

Our proposal is therefore to end the current SIP and SIPPING working 
groups and replace them with a different structure. This will include 
one continuing long-lived working group called SIPCORE, but unlike SIP, 
SIPCORE will have a more narrow mandate of handling only updates or 
revisions to the core SIP specifications (which we define here, somewhat 
arbitrarily, as RFC3261 through RFC3265). This means that work 
previously tied to SIP, such as ongoing security work, would find a new 
home in this structure. In this proposal the SIPPING working group will 
be replaced by a more radical departure, a working group called 
DISPATCH. DISPATCH will function much more like the "open area" groups 
one sees in other areas - a forum where new issues and ideas can be 
presented. DISPATCH will be tasked with identifying the right venue for 
new work in the RAI area; the deliverables of the group might be a BoF 
charter or an initial problem statement document, but no protocol work 
as such. We hope to use the DISPATCH WG as an incubator for 
narrowly-scoped, short duration BoF or working group efforts to solve 
particular problems. Ideally, we could emulate structures like the 
RTPSEC BoF or the recent P2Pi workshop, both of which were far 
lighter-weight than a traditional WG, to address specific issues a more 
timely manner than we might have with our previous structure.

Since this proposal would require a revision to RFC3427, we have begun 
work on one, which can now be found here:

http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-peterson-rai-rfc3427bis-01a.txt

(Sorry, we can't submit this yet due to new RFC 5378 rules but will 
submit as soon as that gets fixed)

In addition to describing the new role of the SIPCORE and DISPATCH WG, 
this document also makes a significant change to the header registration 
policies, as was recommended in Jonathan's modest-proposal document. The 
"P-" header process is deprecated in RFC3427bis in favor of a more open 
IANA policy requiring only expert review for Informational headers - in 
a nutshell, this means that new proposals for headers that would have 
used the "P-" prefix are directed to omit it, and that these headers can 
be registered with the IANA without an Internet-Draft if desired. Note 
that this does not mean that we will rename PAID to AID - existing 
headers will continue as they are, only the process for new 
registrations would change. It is hoped that this change will enable 
more work to be done at the "edges" of the RAI area without depending on 
winning the approval of everyone at the core.

Before we undertake any change this radical, however, we'd like some 
input from the community about the overall direction. Comments on the 
document are also welcome, though do not consider this a last call 
review, but more of an overall conceptual read. We do aim to implement 
some changes before the end of March, however, to facilitate the 
transition to the new Area Director.

Cullen & Jon