Re: [RAI] RAI reorganization

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

I'd also like to know if there has been some decision if we are 
actually going down one of Gonzalo's paths (see what he presented in 
Minn at IETF73).  This seems now like a movement towards Option#3, 
without any mention of the clusters or cluster coordinators.  Is that 
something that's still a possibility or has that pretty much been 
ruled out at this point (and left for future consideration)?

At 08:26 PM 2/4/2009, Dan York wrote:
>Jon and Cullen,
>
>I dislike simply saying "I agree" or "+1" to James' comments... but,
>well...  I agree.
>
>You have asked us this:
>
> >Before we undertake any change this radical, however, we'd like some
> >input from the community about the overall direction.
>
>What is being proposed seems to make sense as a way to let work
>proceed along in a more efficient manner.   I'd say let's give it a
>try.  There will undoubtedly be edge cases that need to be sorted
>through, but I think it's worth trying .
>
>My 2 cents,
>Dan
>
>On Feb 4, 2009, at 7:19 PM, 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
>
>--
>Dan York, CISSP, Director of Emerging Communication Technology
>Office of the CTO    Voxeo Corporation     [e-mail]
>Phone: [phone]  Skype: danyork  http://www.voxeo.com
>Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com
>
>Build voice applications based on open standards.
>Find out how at http://www.voxeo.com/free
>
>
>
>