Re: [RAI] RAI reorganization

[Dan York <[e-mail]>]

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