Re: [RAI] RAI reorganization

[Henry Sinnreich <[e-mail]>]

>How about the Hitchhiker's Guide as your single reference?

It has about 150 references.

Henry


On 2/4/09 9:16 PM, "Tom Taylor" <[e-mail]> wrote:

How about the Hitchhiker's Guide as your single reference?

Henry Sinnreich wrote:
> 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
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> RAI mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rai