Re: [RAI] RAI reorganization

["James M. Polk" <[e-mail]>]

I like this answer (a lot)

James

At 06:11 PM 2/4/2009, Jon Peterson wrote:

>Existing working group items will find a home somewhere as a part of 
>the transition process. I don't think we yet have an exhaustive 
>mapping of what will live where, but, we recognize that it may be 
>necessary to grandfather chartered work into SIPCORE or DISPATCH in 
>order to minimize disruption to ongoing efforts (we just wouldn't 
>let those groups pick up new milestones/deliverables that fall 
>outside their defined scope).
>
>That much said, we hope that the process we are transitioning to 
>will enable work like the location conveyance header to live more in 
>the "edges" of the RAI area than in the core - in other words, for a 
>WG like GEOPRIV to be capable of chartering a new header like this 
>themselves and executing it in the scope of their group. 
>Historically, this document exposed some of the more prominent flaws 
>in our current separation of requirements and mechanisms into 
>different administrative areas. It would be nice if those 
>inefficiencies could become a thing of the past.
>
>Jon Peterson
>NeuStar, Inc.
>
>James M. Polk wrote:
>>
>>I am generally happy with the suggestions here.
>>
>>That said, what I do not see is what will happen to existing SIP WG
>>IDs that are going down a Standards track -- that do not directly
>>relate to RFCs 3261-5.  This appears to be a fairly major gap in
>>what's to occur to them - within the explanation below.
>>
>>Let's take an example of one ID I'm writing on Location Conveyance,
>>creating a new Geolocation header.  This is clearly not SIPCORE as
>>defined, yet in some circles - especially around the the ECRIT and
>>GEOPRIV WGs, this new header is quite necessary.
>>
>>What's the happen with an ID such as Conveyance?
>>
>>Or is this even more motivation to complete the work before March 09?
>>
>>(once RFC 5378 issues are resolved (!!), of course)
>>
>>;-)
>>
>>James
>>
>>At 04:00 PM 2/4/2009, 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-r 
>> ai-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