Re: [RAI] RAI reorganization

[Alan Johnston <[e-mail]>]

Jon,

I think this a very good approach and I fully support it.

As the editor of some of the documents that spent an incredibly long 
time in the SIP and SIPPING WGs, I believe this approach will help 
prevent this from happening in the future.  We also need to spend some 
time and energy focusing on the core SIP RFCs.  Also, it avoids some of 
the pointless arguments about whether a particular header must be a 
P-header or not.

Thanks,
Alan


Jon Peterson wrote:
>
> 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
> _______________________________________________
> RAI mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rai
>