Re: [RAI] RAI reorganization

[Gonzalo Camarillo <[e-mail]>]

Hi,

having a good guide to the documents, it does not make much difference 
if one has to read one or five documents; the number of pages is going 
to be roughly the same. The problem is the amount of stuff one has to 
read (regardless of how we structure that stuff) in order to understand 
SIP. Right now, it is a lot of pages. So, in addition to having a guide, 
it would be good to obsolete some of the RFCs that were never 
implemented... or highlight in the guide which RFCs are widely 
implemented and which ones are not. That would allow new implementors to 
focus on the most relevant documents and get up to speed more quickly.

Cheers,

Gonzalo

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