Re: [RAI] RAI reorganization

[Gonzalo Camarillo <[e-mail]>]

Hi,

yes, the idea is to decentralize the process so that you can define your 
extensions without needing to interact with many other WGs.

Cheers,

Gonzalo

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