Re: [RAI] RAI reorganization

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

I do agree that obsoleting stuff that hasn't been implemented is a really good idea, although I don't think that will make a tremendous difference in terms of the size of documents. 

On this topic of how many documents (or pages of specs) one must read, I will note that there are some wonderful books, written by our own experts, that folks can read to get a really good overview. I do think Hitchhikers guide is very useful for this, as well. But, for folks that need the big picture, the books are excellent.

I will also note that this is really no different (sorry) than other telecomm systems (both voice and data).  Back in the old days, everyone coveted their GSM books, which were far, far more compact than the 4 feet of protocol specs.  And, within Nortel, we had a book that described our DMS product (another coveted book) and you'd need a fair size library to house all of the detailed specs - I have about 1/4 of an 8x10 office with boxes stacked 2 high of documents describing the functionality and protocols that I developed (all associated with code that is still running in several commercial systems today ;) And, I think there are other protocols in IETF that are in the same situation (e.g., Mobile IP, which started with a single "simple" spec and also has some nice books). 

So, I don't know if we need any other overview documents. And, if folks really believe we do, I wonder if this wouldn't better be done by SIP Forum. 

IMHO, what we have now is the reality of commercial systems and we can debate till the cows come home as to whether this should be the case in IETF.  On the other hand, I do think documents like Henry's draft-sinnreich-sip-tools-04 is also appealing to a subset of users/developers. This dichotomy of views on how one should use SIP is due IMHO to the extensible, generally generic and reusable nature of the core SIP protocol (and extensions). It's been well stated at the RAI meeting in Minn. that we are the "victims of our own success"  

Regards,
Mary.  

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Gonzalo Camarillo
Sent: Thursday, February 05, 2009 2:12 AM
To: James M. Polk
Cc: Henry Sinnreich; [e-mail]
Subject: Re: [RAI] RAI reorganization

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

_______________________________________________
RAI mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rai