Re: [RAI] RAI reorganization

[Eric Burger <[e-mail]>]

While tempting to combine the core SIP documents, I would offer it  
would be a mistake, from an engineering and a practical perspective.  
 From an engineering perspective, many of the features stand alone,  
even within core SIP.  As people use SIP for things other than POTS  
replacement, we will see more implementations that use less of the  
spec.  If you want to build a messaging appliance, for example, you do  
not need INVITE and probably do not need PUB/SUB.  The computer  
engineering world is littered with projects where people took  
monolithic architectures and spent lots of effort to break them  
apart.  Since we had the foresight/luck to start that way, let us not  
lose that advantage.

The practical perspective is easy: instead of 5 core documents of 269,  
14, 17, 25, and 38 pages, we would have one document with  
269+14+17+25+38 pages, probably with five chapters.  OK, so I  
exaggerate: the combined document would be 8 pages shorter due to  
consolidated boilerplate.

On Feb 5, 2009, at 10:40 AM, Mary Barnes wrote:

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