Re: [RAI] RAI reorganization

[Jon Peterson <[e-mail]>]

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-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
>