Re: [RAI] RAI reorganization

["Mary Barnes" <[e-mail]>]

Jon and Cullen,

Thanks for putting together this proposal. 

Overall, I really like this approach, in particular the evolution of
SIPPING into DISPATCH (for obvious reasons).  

I did have some initial confusion over how this would impact other SDOs
SIP requirements and had to re-read section 4, in particular reading RFC
5226 in detail. I am now quite comfortable with this approach, in
particular given that it does REQUIRE an expert review for the IANA
registrations and with the particular the two restrictions in section 4.
I think this will really help the other SDOs in terms of meeting their
requirements and avoiding the black hole that several documents have
fallen into in the SIPPING WG, as well as avoiding the infinite debates
on the "right" way for them to do what they want to do.  

In terms of overall RAI structure, as I mentioned at the RAI meeting in
Minn., I think that we already have the cluster concept and the right
place for designating the expert reviewers in the RAI review team.
Although, it's not clear to me whether DISPATCH takes on that role - it
might be a good idea since the current workload of the RAI review team
is very low and as has often been noted, the same people are involved.

My number one concern over RAI efficiency (and in-) is around people
resources and this proposal clearly helps in that we are streamlining
the process in SIPPING, as well as not ping ponging work between WGs.
We do spend way too much time at the f2f meetings debating where work
would happen, so I do think it will be helpful to do this once and be
done with it. I'm hoping this will also help folks in terms of bringing
in new work, since this proposal is far more clear about the process for
that - both for the chairs and document authors.  

As far as timeframe, I'm assuming the plan is to try out this approach
in SF?

Regards,
Mary.  



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Jon Peterson
Sent: Wednesday, February 04, 2009 4:00 PM
To: [e-mail]
Subject: [RAI] RAI reorganization


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-rfc
3427bis-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