Re: [RAI] RAI reorganization

[Henry Sinnreich <[e-mail]>]

This proposal looks very timely and can solve most problems experienced with SIP today (unless my hopeless optimism is out of place):


 *   Internet-centric Core SIP - happy to see the IETF works for the Internet and not for closed networks, legacy emulation, etc.
 *   Mention of "running code" (is there a way to limit the I-Ds that don't have running code and test results?)
 *   Most of all: Only 5 (five) core SIP RFCs 3261-3265.

So  please forgive my naïve question: Why not consolidate the 5 core SIP RFCs into one single document?

Here is an example why a single SIP RFC would be beneficial:
Metadata on the web enables powerful new services, but requires reference to a URI, such as a SIP RFC. See
http://metadata-stds.org/
http://en.wikipedia.org/wiki/Extensible_Metadata_Platform
SIP referencing in metadata is only one of many problems caused by not having a single SIP standard document.
There are plenty of other.

How about having a deliverable a single SIP standard document?

Henry


On 2/4/09 4:00 PM, "Jon Peterson" <[e-mail]> 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