Re: [RAI] RAI reorganization

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

At 09:06 PM 2/4/2009, Henry Sinnreich wrote:
>Content-Language: en
>Content-Type: multipart/alternative;
>         boundary="_000_C5AFB3D5B32Dhsinnreiadobecom_"
>
>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?

This seems like the discussion about whether or 
not to bis 3261, or progress 3261 to DS.  And -- 
that brings up the idea of just how many other 
RFCs ought to be folded back into this grand-unifying-doc RFC.

Also... IMO -- as useful as 3265 is, I'm not sure 
SUB/NOT should be mandated for any and every 
implementation that wants to claim to be *this 
new (merged) RFC number* compliant, and have some customer ask for proof.

now, I could be wrong here...


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