Subject: [RAI] RAI reorganization

From: Jon Peterson <[email-masked]>
Date: Wed, 04 Feb 2009 14:00:08 -0800

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

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 04 Feb 2009 17:54:44 -0600

I am generally happy with the suggestions here.

That said, what I do not see is what will happen to existing SIP WG 
IDs that are going down a Standards track -- that do not directly 
relate to RFCs 3261-5.  This appears to be a fairly major gap in 
what's to occur to them - within the explanation below.

Let's take an example of one ID I'm writing on Location Conveyance, 
creating a new Geolocation header.  This is clearly not SIPCORE as 
defined, yet in some circles - especially around the the ECRIT and 
GEOPRIV WGs, this new header is quite necessary.

What's the happen with an ID such as Conveyance?

Or is this even more motivation to complete the work before March 09?

(once RFC 5378 issues are resolved (!!), of course)

;-)

James

At 04:00 PM 2/4/2009, Jon Peterson 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.
>
>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.
>
>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:
>
>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.
>
>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
>[email-masked]
>https://www.ietf.org/mailman/listinfo/rai

---

From: Jon Peterson <[email-masked]>
Date: Wed, 04 Feb 2009 16:11:46 -0800

Existing working group items will find a home somewhere as a part of the 
transition process. I don't think we yet have an exhaustive mapping of 
what will live where, but, we recognize that it may be necessary to 
grandfather chartered work into SIPCORE or DISPATCH in order to minimize 
disruption to ongoing efforts (we just wouldn't let those groups pick up 
new milestones/deliverables that fall outside their defined scope).

That much said, we hope that the process we are transitioning to will 
enable work like the location conveyance header to live more in the 
"edges" of the RAI area than in the core - in other words, for a WG like 
GEOPRIV to be capable of chartering a new header like this themselves 
and executing it in the scope of their group. Historically, this 
document exposed some of the more prominent flaws in our current 
separation of requirements and mechanisms into different administrative 
areas. It would be nice if those inefficiencies could become a thing of 
the past.

Jon Peterson
NeuStar, Inc.

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 04 Feb 2009 18:19:09 -0600

I like this answer (a lot)

James

At 06:11 PM 2/4/2009, Jon Peterson wrote:

>Existing working group items will find a home somewhere as a part of 
>the transition process. I don't think we yet have an exhaustive 
>mapping of what will live where, but, we recognize that it may be 
>necessary to grandfather chartered work into SIPCORE or DISPATCH in 
>order to minimize disruption to ongoing efforts (we just wouldn't 
>let those groups pick up new milestones/deliverables that fall 
>outside their defined scope).
>
>That much said, we hope that the process we are transitioning to 
>will enable work like the location conveyance header to live more in 
>the "edges" of the RAI area than in the core - in other words, for a 
>WG like GEOPRIV to be capable of chartering a new header like this 
>themselves and executing it in the scope of their group. 
>Historically, this document exposed some of the more prominent flaws 
>in our current separation of requirements and mechanisms into 
>different administrative areas. It would be nice if those 
>inefficiencies could become a thing of the past.
>
>Jon Peterson
>NeuStar, Inc.
>
>James M. Polk wrote:
>>

---

From: Dan York <[email-masked]>
Date: Wed, 4 Feb 2009 21:26:26 -0500

Jon and Cullen,

I dislike simply saying "I agree" or "+1" to James' comments... but,  
well...  I agree.

You have asked us this:

 >input from the community about the overall direction.

What is being proposed seems to make sense as a way to let work  
proceed along in a more efficient manner.   I'd say let's give it a  
try.  There will undoubtedly be edge cases that need to be sorted  
through, but I think it's worth trying .

My 2 cents,
Dan

On Feb 4, 2009, at 7:19 PM, James M. Polk wrote:

>> Existing working group items will find a home somewhere as a part  
>> of the transition process. I don't think we yet have an exhaustive  
>> will enable work like the location conveyance header to live more  
>> in the "edges" of the RAI area than in the core - in other words,  
>> for a WG like GEOPRIV to be capable of chartering a new header like  
>> this themselves and executing it in the scope of their group.  
>> Historically, this document exposed some of the more prominent  
>> flaws in our current separation of requirements and mechanisms into  
>>> >http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-peterson- 
>>> r ai-rfc3427bis-01a.txt
>>> >

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Build voice applications based on open standards.
Find out how at http://www.voxeo.com/free

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 4 Feb 2009 19:06:29 -0800

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" <[email-masked]> wrote:

Cullen & Jon

---

From: Tom Taylor <[email-masked]>
Date: Wed, 04 Feb 2009 22:16:13 -0500

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

Henry Sinnreich wrote:
> ------------------------------------------------------------------------
>

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 4 Feb 2009 19:19:11 -0800

>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" <[email-masked]> wrote:

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 04 Feb 2009 21:31:00 -0600

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?)
>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...

>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/
>SIP referencing in metadata is only one of many 
>problems caused by not having a single SIP standard document.
>On 2/4/09 4:00 PM, "Jon Peterson" 
><<[email-masked]>[email-masked]> wrote:
>
>
>
><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
>
><[email-masked]>[email-masked]

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 04 Feb 2009 21:35:53 -0600

I'd also like to know if there has been some decision if we are 
actually going down one of Gonzalo's paths (see what he presented in 
Minn at IETF73).  This seems now like a movement towards Option#3, 
without any mention of the clusters or cluster coordinators.  Is that 
something that's still a possibility or has that pretty much been 
ruled out at this point (and left for future consideration)?

At 08:26 PM 2/4/2009, Dan York wrote:
>>>> >http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-peterson 
>>>> - r ai-rfc3427bis-01a.txt
>>>> >

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 05 Feb 2009 10:06:16 +0200

Hi,

yes, the idea is to decentralize the process so that you can define your 
extensions without needing to interact with many other WGs.

Cheers,

Gonzalo

James M. Polk wrote:
>> order to minimize disruption to ongoing efforts (we just wouldn't let 
>> those groups pick up new milestones/deliverables that fall outside 
>> their defined scope).
>>
>> "edges" of the RAI area than in the core - in other words, for a WG 
>> like GEOPRIV to be capable of chartering a new header like this 
>> themselves and executing it in the scope of their group. Historically, 
>> this document exposed some of the more prominent flaws in our current 
>> separation of requirements and mechanisms into different 
>> administrative areas. It would be nice if those inefficiencies could 
>> become a thing of the past.
>>
>> Jon Peterson
>> NeuStar, Inc.
>>
>> James M. Polk wrote:
>>>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 05 Feb 2009 10:12:20 +0200

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:
>> 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?)
> 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.
> 
>> Metadata on the web enables powerful new services, but requires 
>> reference to a URI, such as a SIP RFC. See

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 5 Feb 2009 15:29:23 +0100

This is part of the discussion that Robert was tring to get going at the last SIP meeting, with no real consensus. I suggest not having this thread on RAI.

James said

> 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.
> 

If I follow tha argument, we should also pull INVITE into a separate document. There is no reason why all UAs need to support it.

Keith 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of James M. Polk
> Sent: Thursday, February 05, 2009 3:31 AM
> To: Henry Sinnreich; Jon Peterson; [email-masked]
> Subject: Re: [RAI] RAI reorganization
> 
> experienced 
> >with SIP today (unless my hopeless optimism is out of place):
> >
> 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.
> 
> >SIP referencing in metadata is only one of many problems 
> caused by not 
> >having a single SIP standard document.
> >certainly not the last step, we'd like some input from the 
> community on 
> >the following proposal and accompanying draft.
> >
> >revisions to the core SIP specifications (which we define here, 
> >somewhat arbitrarily, as RFC3261 through RFC3265). This 
> means that work 
> ><http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-pete
> rson-rai-r
> >fc3427bis-01a.txt>http://svn.resiprocate.org/rep/ietf-drafts/
> fluffy/dra
> >ft-peterson-rai-rfc3427bis-01a.txt
> >
> >this document also makes a significant change to the header 
> 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.
> >
> Comments on the

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 5 Feb 2009 09:40:56 -0600

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: [email-masked] [mailto:[email-masked]] On Behalf Of Gonzalo Camarillo
Sent: Thursday, February 05, 2009 2:12 AM
To: James M. Polk
Cc: Henry Sinnreich; [email-masked]
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:
>>    * Internet-centric Core SIP - happy to see the IETF works for the 
>>    * Mention of "running code" (is there a way to limit the I-Ds that 
>> don't have running code and test results?)

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 5 Feb 2009 09:58:37 -0600

Jon and Cullen,

Thanks for putting together this proposal. 

Overall, I really like this approach, in particular the evolution of
SIPPING into DISPATCH (for obvious reasons).  

I did have some initial confusion over how this would impact other SDOs
SIP requirements and had to re-read section 4, in particular reading RFC
5226 in detail. I am now quite comfortable with this approach, in
particular given that it does REQUIRE an expert review for the IANA
registrations and with the particular the two restrictions in section 4.
I think this will really help the other SDOs in terms of meeting their
requirements and avoiding the black hole that several documents have
fallen into in the SIPPING WG, as well as avoiding the infinite debates
on the "right" way for them to do what they want to do.  

In terms of overall RAI structure, as I mentioned at the RAI meeting in
Minn., I think that we already have the cluster concept and the right
place for designating the expert reviewers in the RAI review team.
Although, it's not clear to me whether DISPATCH takes on that role - it
might be a good idea since the current workload of the RAI review team
is very low and as has often been noted, the same people are involved.

My number one concern over RAI efficiency (and in-) is around people
resources and this proposal clearly helps in that we are streamlining
the process in SIPPING, as well as not ping ponging work between WGs.
We do spend way too much time at the f2f meetings debating where work
would happen, so I do think it will be helpful to do this once and be
done with it. I'm hoping this will also help folks in terms of bringing
in new work, since this proposal is far more clear about the process for
that - both for the chairs and document authors.  

As far as timeframe, I'm assuming the plan is to try out this approach
in SF?

Regards,
Mary.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jon Peterson
Sent: Wednesday, February 04, 2009 4:00 PM
To: [email-masked]
Subject: [RAI] RAI reorganization

http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-peterson-rai-rfc
3427bis-01a.txt

Cullen & Jon

---

From: Alan Johnston <[email-masked]>
Date: Thu, 05 Feb 2009 10:14:35 -0600

Jon,

I think this a very good approach and I fully support it.

As the editor of some of the documents that spent an incredibly long 
time in the SIP and SIPPING WGs, I believe this approach will help 
prevent this from happening in the future.  We also need to spend some 
time and energy focusing on the core SIP RFCs.  Also, it avoids some of 
the pointless arguments about whether a particular header must be a 
P-header or not.

Thanks,
Alan

Jon Peterson wrote:
> 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.
>
> 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.
>
> 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.
>

---

From: Adam Roach <[email-masked]>
Date: Thu, 05 Feb 2009 10:45:10 -0600

> 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. 

We need to be careful to distinguish between:

    * things that haven't been implemented, and
    * things that haven't been implemented yet

In some ways, SIP (and related technologies) is fairly mature (a point 
Jonathan has made a few different times); but, in many others, it is 
still very new -- we just got the documents for session mode messaging 
out the door a little over a year ago. And a lot of the features we 
developed into the protocol were very forward-looking. For example, 
adoption of TLS was quite slow initially; but, now, we have a pretty 
good TLS penetration (63% as of last April, based on what we see at 
SIPits). It would be a shame if we had decided to remove TLS from the 
protocol due to "lack of implementation" several years ago. The same 
holds true for IPv6 support and session timer.

So I propose that everyone with a crystal ball respond to the mailing 
list and let us know which features are never going to be implemented -- 
we can then eliminate them from future documents. (This is not aimed at 
Mary personally -- there have been a number of calls for deprecating 
useful and forward-looking features based on a lack of current 
deployment, and I think almost all of them are too aggressive in the 
features they nominate for removal).

/a

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 05 Feb 2009 18:50:02 +0200

Hi,

 > I think almost all of them are too aggressive in the

Yes. For example, we deprecated ANAT, and that is what folks are 
implementing now :o)

Cheers,

Gonzalo

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 5 Feb 2009 10:54:50 -0600

Correct.

And the result is as crappy as we envisioned, especially if
you have more than one media stream (say, voice and video). 

> Behalf Of Gonzalo Camarillo
> Sent: Thursday, February 05, 2009 08:50
> To: Adam Roach
> Yes. For example, we deprecated ANAT, and that is what folks 
> are implementing now :o)
> 
> Cheers,
> 
> Gonzalo
>

---

From: Eric Burger <[email-masked]>
Date: Tue, 10 Feb 2009 09:19:45 -0500

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.
>
> 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:
>>> SIP referencing in metadata is only one of many problems caused by  
>>> not
>>> they
>>> include
>>> SIP,
>>> somewhat
>>> begun
>>> <http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-peterson-rai-rfc3427bis-01a.txt 
>>> WG,
>>> registration
>>> the

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 10 Feb 2009 09:32:24 -0500

> new milestones/deliverables that fall outside their defined scope).

This could end up being a bad situation if we ended up having DISPATCH 
and SIPCORE full of old items, unable to spend time on their real, new 
charters.

I'd love to see a table which proposes an allocation of the existing 
SIP/SIPPING work to other groups (e.g., location conveyance -> geopriv). 
I'd also go so far as to propose that big, unfinished pieces of work in 
sipping (like the config framework documents) be immediately placed into 
a BoF/WG which meets in San Fran (formally or informally).

I think that exercise will give us a really good idea of how easy it 
will be to push work into other groups.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   111 Wood Avenue South
Cisco Fellow                                   Iselin, NJ 08830
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 10 Feb 2009 16:38:14 +0200

I would like to understand what happens with the documents that came from
other SDOs where the excitement in the IETF has faded away over time. With
the proposed revision of the SIP process what happens with these documents?
Are they pushed back to the source for completion or is the plan to finish
them in the IETF? 

Ciao
Hannes

>Behalf Of Jonathan Rosenberg
>Sent: 10 February, 2009 16:32
>To: Jon Peterson
>Cc: [email-masked]
>> those groups pick up new milestones/deliverables that fall 
>This could end up being a bad situation if we ended up having 
>DISPATCH and SIPCORE full of old items, unable to spend time 
>on their real, new charters.
>
>I'd love to see a table which proposes an allocation of the 
>existing SIP/SIPPING work to other groups (e.g., location 
>conveyance -> geopriv). 
>I'd also go so far as to propose that big, unfinished pieces 
>of work in sipping (like the config framework documents) be 
>immediately placed into a BoF/WG which meets in San Fran 
>(formally or informally).
>
>I think that exercise will give us a really good idea of how 
>easy it will be to push work into other groups.
>
>-Jonathan R.
>
>
>
>--

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 10 Feb 2009 10:58:17 -0800

> DISPATCH and SIPCORE full of old items, unable to spend time on 
> their real, new charters.

I agree.

One solution to that specific problem is to keep SIP and SIPPING
so they can conclude their existing work.  In conjunction, provide
a venue, as Jonathan suggests below, to evaluate some of their
larger items and kick them to focused working groups.

-d

> of work in

---

From: <[email-masked]>
Date: Tue, 10 Feb 2009 21:27:41 +0100

Hi,

Eric Burger wrote:
>As people use SIP for things
>other than POTS replacement,

Do they? I think this, rather than anything else, is the key question facing RAI. So far all large scale multi-vendor SIP deployments I've seen have been for POTS replacement. There are of course other things here and there but it all seems to be walled gardens and SIP *based* proprietary solutions.

Markus

PS. I like the re-organization proposal.

---

From: Adam Roach <[email-masked]>
Date: Tue, 10 Feb 2009 14:58:02 -0600

[email-masked] wrote:
> Do they? I think this, rather than anything else, is the key question facing RAI.

One of the things that showed up at the most recent SIPit was an 
innovative portable real-time camera for remote collaboration. Its 
intended use is for remote locations, like off-shore oil drilling 
platforms. A field technician can use the camera to show an off-site 
engineer what's happening with equipment in the field. The engineer can 
then use a whiteboard application to draw on the image (e.g., "Can you 
zoom in on the part I just circled?"). There is also two-way voice.

And the whole session is managed using SIP -- nothing proprietary, just SIP.

I've seen a double-handful of other actually-deployed SIP devices that 
are nothing like POTS replacement (remote video monitoring, 
building-wide intercom systems, etc.), but that's the one that shows off 
SIP's potential for radical innovation better than any others I know about.

There is a tremendous pitfall in the fact that SIP has been picked up as 
a good protocol for POTS replacement. Because of the staggeringly huge 
deployed base of POTS users, the penetration of SIP in this application 
has been rapid and clearly visible. However, SIP has huge promise beyond 
this, and people **ARE** developing applications in radically innovative 
ways that have nothing to do with POTS. Like all technologies, these 
will take a bit of time to mature. Keep in mind that POTS has a 140-year 
head start on anything invented today.

If we start standardizing SIP as if these innovative applications are 
irrelevant, we will surely kill them before they mature. You can fulfill 
this dark prophesy if you work at it, and we seem to have quite a few 
otherwise intelligent people who seem hellbent on doing exactly that.

Please. Don't.

/a

---

From: Ted Hardie <[email-masked]>
Date: Tue, 10 Feb 2009 13:53:20 -0800

>and SIPCORE full of old items, unable to spend time on their real, new

Well, we can charter another group called "SAP (SIP Ancient Problems)" that
will either handle or dispatch anything more than 6 months old at the
time of the transition.  Certainly reflects the energy results, eh?

Oh, wait, that's a bad idea. 

>a BoF/WG which meets in San Fran (formally or informally).

I agree with that, with the caveat that the BoF/WG should be a ticket
that can be used when the travel budgets for the key participants permit.
That might not be SF for all problem spaces.

				Ted

---

From: Dan York <[email-masked]>
Date: Tue, 10 Feb 2009 17:56:01 -0500

Markus,

On Feb 10, 2009, at 3:27 PM, <[email-masked]> <[email-masked] 
 > wrote:
> Do they? I think this, rather than anything else, is the key  
> question facing RAI. So far all large scale multi-vendor SIP  
> deployments I've seen have been for POTS replacement. There are of  
> course other things here and there but it all seems to be walled  
> gardens and SIP *based* proprietary solutions.

Yes, people are using SIP for more than simply POTS replacement.

Sure, with our hosted infrastructure for voice apps, on the back end  
we (Voxeo) *do* use SIP for POTS replacement.  We have relationships  
with many of the major SIP service providers and connect our SIP cloud  
to theirs and from there out to the PSTN for very large volumes of  
simultaneous calls.

But on the front-end (facing our customers), we're seeing all sorts of  
fascinating integration going on over SIP between our app platform and  
customer systems.  In some cases it is customer contact/call center  
software using SIP to send calls over to an app on our platform and  
then we're sending it back.  In some cases we are receiving the call  
on our platform, executing some voice app and then potentially sending  
the call via SIP over to a contact center, sometimes via a SIP REFER  
to drop our platform out of the picture.  In both cases we're often  
seeing the passing of custom SIP headers to exchange information and  
create deeper integration than you could do over the PSTN.  All sorts  
of integration between business systems going on that couldn't easily  
be done with POTS/PSTN.

We're seeing other people use the premise version of our platform to  
create distributed systems using SIP over wide area networks,  
sometimes with hybrid failover into the hosted cloud... all using  
SIP.  I suppose you could build some of these configs over PSTN lines,  
but the cost would be significantly higher, the timeframe longer and  
flexibility limited.

There are lots of other apps I see, especially from startups, that are  
doing funky things with communications over SIP. People doing  
sometimes wacky - but very cool - stuff out there.

Beyond what we do here, I've seen a number of folks out there looking  
at ways to create a richer communication experience than what you can  
do over the PSTN - all using standard SIP.  Folks using wideband  
audio... or multi-modal communication... or collaboration apps over  
SIP....

Sure, the *majority* of the SIP deployments out there today are  
probably doing PSTN-line-replacement, but there are a *lot* of people  
experimenting on the edges and as more systems provide SIP  
interconnections, those experiments on the edge are starting to look  
like viable paths for businesses.

My 2 cents,
Dan

---

From: Jiri Kuthan <[email-masked]>
Date: Wed, 11 Feb 2009 12:18:00 +0100

> And the whole session is managed using SIP -- nothing proprietary, just 

Hi Adam,

do we need some additional standardization effort for such a camera?

> otherwise intelligent people who seem hellbent on doing exactly that.

So what do you think is the actual action we shall take?

> Please. Don't.

For the SIP/POTS replacement stuff -- it is just happening. The key 
motivation
is saving. We witness about 10% population's penetration in DE. Not 
suprisingly
IMS flavor of SIP is not appearing  (it doesn't seem to create savings 
on top of
vanilla SIP). It is running  on public Internet. There are no 
applications on it
other than voicemail. The economy in this case reassembles WallMart more 
than
rich Internet application as we know them from computers. (BTW: the biggest
operational problem I hear most frequent laments about is DTMF, fax, and 
various
other in-band applications like electronic payment systems and lift 
control :-) )

I agree too that cloning the POTS experience in exchange for saving
money doesn't sound attractive.

Nevertheless the apps don't seem to take off in the extent "Wallmart SIP"
does. It may be just a serialization problem -- apps lagging behind
the infrastructure and its perfection (like web apps were lagging until
web servers began to be wide-spread and forms were introduced).

The real question is though whether we can/should stimulate the apps within
the IETF. I actually don't see how applications could emerge from this 
venue.
They typically emerge from entrepreneurial or university environment which
is something completely different from standard making.  After which it
can be beneficial to standardize those.

Therefore I think IETF is a great place to specify the POTS replacement
and operational aspects of it (security, configuration, monitoring, under-
specification, etc.). I would be surprised if applications emerged from 
here.

The real action item  I can think of is to help educating and conserving 
SIP
as app-agnostic protocol that allows apps to emerge WITHOUT the
IETF standardization process. Particularly, discouraging techniques like 
ALGs
and other unsound designs would certainly be helpful.

-jiri

---

From: Adam Roach <[email-masked]>
Date: Wed, 11 Feb 2009 10:57:30 -0600

Jiri Kuthan wrote:
>> engineer what's happening with equipment in the field. The engineer 
>> can then use a whiteboard application to draw on the image (e.g., 
>> "Can you zoom in on the part I just circled?"). There is also two-way 
>> voice.
>>

Maybe, maybe not. I understand they were interoperating with other SIP 
devices at the SIPit.

But, for the sake of argument, let's imagine they did.

If they came to the IETF with some suggested protocol extensions to 
standardize, would they find RAI receptive to doing this work? Or would 
they find a group of people telling them to go away because the work 
required to standardize their extensions is not "proportional to the 
number of affected networks"? [1] Would they be shunned because their 
extension can't be made to work with existing deployed SBCs?

And the next inventive use of SIP -- will its inventor show up to 
standardize some aspect of a new application only to be told that the 
SIP feature they've used in their device was deprecated because it 
wasn't widely deployed in the current POTS replacement networks? [2]

There are several people -- many of whom have been working in the RAI 
area for over a decade now -- who used to wear "no TCAP" and "no circuit 
switching" pins and buttons. These people saw themselves as a 
revolutionary group of Young Turks who were going to completely change 
the way people communicated. We were going to break down the ossified 
telephony networks with new and innovative applications. Many of these 
are the exact same people who are arguing for the ossification of SIP 
into nothing but legacy applications. They have become the exact thing 
they were railing against in the first place.

Unless we reverse that course, then the revolution has failed -- undone, 
ironically enough, by the very revolutionaries who helped start it in 
the first place.

>> irrelevant, we will surely kill them before they mature. You can 
>> fulfill this dark prophesy if you work at it, and we seem to have 
>> quite a few otherwise intelligent people who seem hellbent on doing 
>> exactly that.
>

The key action is to halt efforts that propose to cripple new work so 
that it works through existing SBCs. The SBCs grew up around SIP to work 
with SIP, not the other way around. A lot of the recent RAI 
introspection has focused on how we can let the SBC tail wag the SIP dog.

> For the SIP/POTS replacement stuff -- it is just happening.

Yes, and that's great. But we can't let it dictate the future of SIP. 
Simply because some work isn't applicable to POTS replacement doesn't 
mean that it's worthless. In fact, the new stuff -- the stuff that isn't 
like POTS at all -- is where the real promise of SIP is and has aways been.

> The real action item  I can think of is to help educating and 
> conserving SIP
> IETF standardization process. Particularly, discouraging techniques 
> like ALGs

I think we're on the same page.

/a

[1] draft-rosenberg-rai-modest-proposal, section 4
[2] http://www.ietf.org/mail-archive/web/rai/current/msg00359.html: "it 
would be good to obsolete some of the RFCs that were never implemented"

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 11 Feb 2009 19:42:03 +0200

Hi Adam,

> wasn't widely deployed in the current POTS replacement networks? [2]

note that in my note I said "*never* implemented" and did not refer to 
POTS replacement at all. What I had in mind were things like early 
session. When we wrote that RFC in particular, we thought it was a good 
idea. Nowadays, the complexity of such solution has convinced most 
people it is not such a good idea. Obsoleting specs that were *never* 
implemented and that we now think should be implemented in different 
ways is a good thing, IMHO.

I agree with what you say in your message and am quite sure we are on 
the same page. I just wanted to clarify that the way you referenced my 
previous email was not in line with what I had in mind.

Cheers,

Gonzalo

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 11 Feb 2009 13:27:50 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam
> Roach
> Sent: Wednesday, February 11, 2009 11:58 AM
>

Replace the word "SBC" with "Firewall/NAT", and "SIP" with "IP".  What do you get?  Déjà vu.

-hadriel

---

From: Adam Roach <[email-masked]>
Date: Wed, 11 Feb 2009 13:01:33 -0600

Gonzalo Camarillo wrote:
> session. When we wrote that RFC in particular, we thought it was a 
> good idea. Nowadays, the complexity of such solution has convinced 
> most people it is not such a good idea. Obsoleting specs that were 
> *never* implemented and that we now think should be implemented in 
> different ways is a good thing, IMHO.

Thanks for the clarification; the example helps. A careful excision of 
honest-to-goodness cruft like that may be worthwhile, but we need to err 
on the side of keeping features if there is any question at all about 
their utility. My concern is that the current "let's focus on deployed 
networks" effort -- the one described in Jonathan's "Modest Proposal" 
draft -- is actively looking for babies to throw out with the bathwater.

/a

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 11 Feb 2009 16:33:12 -0500

>  
>  There is a tremendous pitfall in the fact that SIP has been picked up
>  as  a good protocol for POTS replacement. Because of the staggeringly
huge
>  deployed base of POTS users, the penetration of SIP in this
>  application  has been rapid and clearly visible.

Which means that SIP is now sitting in the center of about 80% of global
telecom revenues. Hense there are some vested interests in making sure that
SIP as a POTS replacement actually works as advertised. Some of our
colleagues would clearly like to maintain their employment.

>  fulfill  this dark prophesy if you work at it, and we seem to have quite
a few
>  otherwise intelligent people who seem hellbent on doing exactly that.

Well that's all fine and good but can we at least make sure what we have
actually works and what is broken right now is fixed first. The amount of
problems coming up now that there are substantive deployments is
substantial.

---

From: Adam Roach <[email-masked]>
Date: Wed, 11 Feb 2009 16:30:22 -0600

> problems coming up now that there are substantive deployments is

Of course we should fix anything we know doesn't work. But don't ruin it 
for non-POTS applications at the same time.

/a

---

From: Adam Roach <[email-masked]>
Date: Wed, 11 Feb 2009 16:35:45 -0600

Hadriel Kaplan wrote:
>> From: Adam Roach

The analogy, while superficially compelling, is imperfect. If you're 
comparing SBCs with an IP equivalent, you'd have to point to 
firewall/ALGs that block all traffic they don't understand. Sure, such 
beasts exist, but most of the world is better off without them -- and 
we're certainly not giving them any quarter in IETF protocols (unless 
you count RFC 3093).

/a

---

From: Jon Peterson <[email-masked]>
Date: Wed, 11 Feb 2009 14:41:44 -0800

The reorganization plan we put on the table does not really address this 
"refocusing" aspect of modest-proposal (though it does follow the 
suggestion in that document regarding P- headers). Attempting to 
constrain or prioritize work in the IETF is a non-trivial matter - we 
charter work that our participants form a consensus to undertake, and 
the energy of participants inevitably refuses to conform to 
administrative expectations. It is a peculiar but undeniable truth that 
the motivations of our contributors are often misaligned with the 
tactical needs of the marketplace - however, the only force that can 
hope to sway those contributors is grassroots consensus building, not 
proclamations from IETF leadership.

I think the best we can do, really, is to try to decentralize work as 
much as possible, so that participants who do not share complementary 
goals can work independently. This is the point of the DISPATCH 
incubator process and the move to avoid doing protocol work in the room 
everyone feels obliged to fill. Provided that we can realize this 
independence without sacrificing the core tenets of interoperability, we 
will probably have reached the most plausible compromise.

As an aside, I doubt that debating the propriety of SBCs in this thread 
will lead us to a better understanding of how the RAI area should be 
organized.

Jon Peterson
NeuStar, Inc.

---

From: Adam Roach <[email-masked]>
Date: Wed, 11 Feb 2009 17:28:21 -0600

Jon:

If you follow the thread back, this branch of it started from a 
challenge to Eric's assertion that SIP is used for more than POTS 
replacement. I'm boggled that we've come so far that such an assertion 
even needs to be given a voice, much less a defense. (Marcus' voice is 
not isolated; several key people have expressed equivalent sentiments.)

My aim is to ensure that any decisions we make regarding how to 
structure SIP work is based -- at least, in part -- on its promise for 
emerging and future applications, not just as ISUP with a different syntax.

The high-level proposal, as you described it in your initial message, 
seems sound to me. We need to make sure we don't trample innovation as 
we fill in the details.

/a

Jon Peterson wrote:
>
> The reorganization plan we put on the table does not really address 
> this "refocusing" aspect of modest-proposal (though it does follow the 
> administrative expectations. It is a peculiar but undeniable truth 
> that the motivations of our contributors are often misaligned with the 
> incubator process and the move to avoid doing protocol work in the 
> room everyone feels obliged to fill. Provided that we can realize this 
> independence without sacrificing the core tenets of interoperability, 
> we will probably have reached the most plausible compromise.
>
> As an aside, I doubt that debating the propriety of SBCs in this 
> thread will lead us to a better understanding of how the RAI area 
> should be organized.
>
> Jon Peterson
> NeuStar, Inc.
>
> Adam Roach wrote:
>>
>> Gonzalo Camarillo wrote:
>> > Hi Adam,
>> >

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 11 Feb 2009 19:26:52 -0500

> From: Adam Roach [mailto:[email-masked]]
> Sent: Wednesday, February 11, 2009 5:36 PM
>
> Hadriel Kaplan wrote:

My guess is the reason we don't give them any quarter is they're not dominantly prevalent, and we can figure out ways around them.  It's a pragmatism thing - the analogy was not about function or behavior (SBC's are not like home NAT's obviously); the analogy was about how long do we ignore the world we live in versus the world we want to be?

If you think SBC-type systems/behavior only exists in PSTN-replacement applications, well, I got news for ya.  There're SBCs in IM applications, whiteboard apps, video conferencing, and video-share apps.  And those are only the ones I know of personally, because my company's boxes were sold for them; I don't know what the other SBC vendors have deployed into.

No one's suggesting we should *advocate* SBC-type behavior, just like we don't *advocate* NATs.  The question is if we should try to define any bounds for them whatsoever, such that we can make things work through them as much as possible; or even identify things that *won't* work.  For example, since we recognize NATs exist and some basic behavior, we can recognize what fundamentally won't work through them, even if we can't always tell what will work.

-hadriel

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 11 Feb 2009 18:44:07 -0700

The clusters seemed like an idea that most people liked at the last  
meeting and Jon and I have been thinking about them as an organization  
of the work. I believe it would help solve bottlenecks in both WG  
Chair and AD processing as well as it could make it easier to schedule  
more than two RAI WG at the same time. More importantly, it allow  
people to find pockets of like minded folks.

Right now, I'd paint the clusters as looking something like the  
attached file.

On Feb 4, 2009, at 8:35 PM, James M. Polk wrote:

> without any mention of the clusters or cluster coordinators.  Is  
> that something that's still a possibility or has that pretty much  
> been ruled out at this point (and left for future consideration)?

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 11 Feb 2009 18:54:50 -0700

The allocation is not easy - Here is a rough take. It's very draft. It  
proposes that some of the work get spun up as new small focused  
efforts at IETF 74. Specifically DISPATCH would spin up something on  
Info Framework, Config, and Overload. Jon is going to send some more  
email about this but here is *rough* list of all current WG items that  
have not been sent to the IESG and where they might map to.

SIP Milestones:

X.509 extended key usage for SIP
draft-ietf-sip-eku
--> SIPCORE

Termination of early dialog prior to final response
draft-ietf-sip-199
--> SIPCORE

Delivering request-URI and parameters to UAS via proxy
draft-rosenberg-sip-target-uri-delivery
--> SIPCORE

INFO package framework
draft-ietf-sip-info-events-03
--> Dispatch/Info

Guidelines for double route recording
draft-ietf-sip-record-route-fix
--> SIPCORE

X.509 Certificates for TLS use in SIP
draft-ietf-sip-domain-certs
--> SIPCORE

Using SAML for SIP
draft-ietf-sip-saml
--> OBE? (Overcome by events)

Location Conveyance with SIP
draft-ietf-sip-location-conveyance
--> GEOPRIV

MIME body handling in SIP
draft-ietf-sip-body-handling-05
--> SIPCORE

Example security flows
--> OBE?

Identify requirements for test matrix to move SIP to Draft Standard
--> SIPCORE

Essential corrections to RFC 3261 (1st batch)
draft-ietf-sip-ipv6-abnf-fix
--> SIPCORE

Mechanisms for UA initiated privacy
draft-ietf-sip-ua-privacy
--> AD Sponsor

SIPPING Milestones:

Presence Scaling Requirements to IESG
draft-ietf-sipping-presence-scaling-requirements
--> Dispatch/Overload

User Agent Profile for Media Policy
draft-ietf-sipping-media-policy-dataset (last updated May 2008)
--> Dispatch/Config

Schema and Guidelines for SIP User Agent Profile Datasets
draft-ietf-sipping-profile-datasets
--> Dispatch/Config

Overload Design Considerations
draft-ietf-sipping-overload-design
--> Dispatch/Overload

NAT Scenarios
  draft-ietf-sipping-nat-scenarios
--> MUSIC or Grandfather SIPCORE

On Feb 10, 2009, at 7:32 AM, Jonathan Rosenberg wrote:

> SIP/SIPPING work to other groups (e.g., location conveyance ->  
> geopriv). I'd also go so far as to propose that big, unfinished  
> pieces of work in sipping (like the config framework documents) be  
> immediately placed into a BoF/WG which meets in San Fran (formally  
> or informally).
>

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 11 Feb 2009 18:54:58 -0700

> As far as timeframe, I'm assuming the plan is to try out this approach

Yes, the goal is certainly IETF 74 - it's tight to get this is place  
but I think it's possible.

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 11 Feb 2009 20:15:45 -0600

>From my own perspective in Enterprise communications, 
the main driver for SIP is definitvely NOT POTS replacement
anymore. That was true 10 years ago.

POTS is becoming irrelevant as it falls into obsolescence and is
replaced by more modern communications services.

In short: I agree with with Adam.

> Behalf Of Adam Roach
> Sent: Wednesday, February 11, 2009 15:28
> To: Jon Peterson
> Cc: [email-masked]; [email-masked]; [email-masked]
> If you follow the thread back, this branch of it started from 
> a challenge to Eric's assertion that SIP is used for more 
> than POTS replacement. I'm boggled that we've come so far 
> that such an assertion even needs to be given a voice, much 
> less a defense. (Marcus' voice is not isolated; several key 
> people have expressed equivalent sentiments.)
> 
> My aim is to ensure that any decisions we make regarding how 
> to structure SIP work is based -- at least, in part -- on its 
> promise for emerging and future applications, not just as 
> ISUP with a different syntax.
> 
> The high-level proposal, as you described it in your initial 
> message, seems sound to me. We need to make sure we don't 
> trample innovation as we fill in the details.
> 
> /a
> 
> Jon Peterson wrote:
> >
> >> >> standardize some aspect of a new application only to be 
> told that 
> >> >> the SIP feature they've used in their device was deprecated 
> >> >> because it wasn't widely deployed in the current POTS 
> replacement 
> >> >> networks? [2]
> >> >
> >> > note that in my note I said "*never* implemented" and 
> did not refer 
> >> > to POTS replacement at all. What I had in mind were things like 
> >> > early session. When we wrote that RFC in particular, we 
> thought it 
> >> > was a good idea. Nowadays, the complexity of such solution has 
> >> > convinced most people it is not such a good idea. 
> Obsoleting specs 
> >> > that were
> >> Thanks for the clarification; the example helps. A careful 
> excision 
> >> of honest-to-goodness cruft like that may be worthwhile, 
> but we need 
> >> to err on the side of keeping features if there is any question at 
> >> all about their utility. My concern is that the current 
> "let's focus 
> >> on deployed networks" effort -- the one described in 
> Jonathan's "Modest Proposal"

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 11 Feb 2009 19:43:50 -0800

> Enterprise communications, the main driver for SIP is 
>definitvely NOT POTS replacement any more. That was true 10 years ago.

Francois is right: Employees and management want the same experience in the enterprise as they have home on the Internet. IT organizations will work to comply, just as they have done in past with the PC, LAN and Internet, at a time when the IT glasshouse was supposed to be all SNA, etc.

I plan to expand on this soon...

Henry

---

From: "Roni Even" <[email-masked]>
Date: Thu, 12 Feb 2009 08:45:23 +0200

I have no problem with the cluster structure even though I am not sure what
it means in term of actual work, and being more specific how it will help
solving the WG chairs and AD processing.

I strongly object to the idea of having more than two RAI WG at the same
time, there are relations between the WGs and even with the situation today
where we may have two RAI WG schedule at the same time I find it in some
cases disturbing people from participating in all the sessions they have
interest in. Note that people are spending money to come to the meetings and
would like to attend as many sessions as possible. I thought that adding
Friday afternoon is the price we pay for not having parallel sessions.

Roni Even 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Cullen
Jennings
Sent: Thursday, February 12, 2009 3:44 AM
To: James M Polk; [email-masked]
Subject: Re: [RAI] RAI reorganization - Clusters

The clusters seemed like an idea that most people liked at the last meeting
and Jon and I have been thinking about them as an organization of the work.
I believe it would help solve bottlenecks in both WG Chair and AD processing
as well as it could make it easier to schedule more than two RAI WG at the
same time. More importantly, it allow people to find pockets of like minded
folks.

Right now, I'd paint the clusters as looking something like the attached
file.

---

From: "Roni Even" <[email-masked]>
Date: Thu, 12 Feb 2009 08:57:13 +0200

I fully agree with Adam. I hope that the re-organization will not prevent
SIP from having the extra value and not focus mainly on POTS replacement. I
hope that we do not have to justify that SIP is more than that and it should
be reflected in the charter of the new WGs.

Roni Even 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam
Roach
Sent: Thursday, February 12, 2009 1:28 AM
To: Jon Peterson
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [RAI] RAI reorganization

Jon:

/a

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 12 Feb 2009 09:16:28 +0200

Hi,

I agree with Jon. At the end of the day, what matters is how people 
spend their time. If they spend their time specifying, discussing, and 
reviewing POTS-like specs, RAI will produce just that. If they spend 
their time on new innovative cool (put here your favorite adjective) 
applications, RAI will produce just that. That is the best way to 
influence the direction RAI will take at any given point.

The problem right now is that we do not have enough effective cycles 
available in RAI. We need more cycles from current contributors and new 
contributors.

Cheers,

Gonzalo

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 12 Feb 2009 02:06:49 -0700

> Friday afternoon is the price we pay for not having parallel sessions.

Thanks thats good feedback. (Particularly given we are about to start  
all the IETF 74 schedule conflict resolution)

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 12 Feb 2009 12:18:08 +0200

I would like to comment a bit on the usage of SIP. 

While it is technically true that SIP can be used for all sorts of things in
many deployments today it is used for voice. 

As example, I would like to draw your attention to presence and instant
messaging. How many of you use SIP in comparison to XMPP? 
We all have Jabber chatrooms for our working groups. 

When I look at my Wordpress based weblog then I have plugins that allow me
notifications to be distributed via XMPP (not SIP). 

I believe that there is a lack of usable open source SIP implementations
that do things other than voice. The developer community is not going to
pick something up if they have to spend a huge amount of time to get their
tiny new extension implemented. See http://tools.ietf.org/html/rfc5218

What does this mean for the standardization work? Most extensions appear to
make a lot of sense but there is so much dependency on other pieces before
they may eventually get deployed.

Ciao
Hannes

>Behalf Of Roni Even
>Sent: 12 February, 2009 08:57
>To: 'Adam Roach'; 'Jon Peterson'
>I fully agree with Adam. I hope that the re-organization will 
>not prevent SIP from having the extra value and not focus 
>mainly on POTS replacement. I hope that we do not have to 
>justify that SIP is more than that and it should be reflected 
>in the charter of the new WGs.
>
>Roni Even 
>
>a challenge to Eric's assertion that SIP is used for more than 
>POTS replacement. I'm boggled that we've come so far that such 
>an assertion even needs to be given a voice, much less a 
>defense. (Marcus' voice is not isolated; several key people 
>have expressed equivalent sentiments.)
>
>promise for emerging and future applications, not just as ISUP 
>with a different syntax.
>
>>> > note that in my note I said "*never* implemented" and did 
>not refer 
>>> Thanks for the clarification; the example helps. A careful excision

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 12 Feb 2009 12:28:03 +0200

Hi,

> I believe that there is a lack of usable open source SIP implementations

fully agreed. Efforts spent in that area would be most useful, IMHO... 
but the question here is, how the IETF could make that happen (or at 
least influence it).

Cheers,

Gonzalo

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 12 Feb 2009 14:05:19 +0200

> but the question here is, how the IETF could make that happen (or at 
I think Hannes mentioned one important aspect: 

"The developer community is not going to
pick something up if they have to spend a huge amount of time to get their
tiny new extension implemented."

even if I would say  that sip developers  have to spend a  huge amount 
of time and effort to get their tiny
new, and probably already implemented, sip extensions standardized: if 
they success!
That's not the only cause, but it is one

cheers
Sal

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 12 Feb 2009 08:17:48 -0500

The IETF as an organization can probably only help indirectly, but  
here are three possibilities:

- More senior members of the community can help mentor student  
software authors.

- Companies can release some of their software as open source.

- Companies can sponsor "summer-of-code" or "semester-of-code" efforts.

I'm happy to discuss these options off-line.

Henning

On Feb 12, 2009, at 5:28 AM, Gonzalo Camarillo wrote:

> fully agreed. Efforts spent in that area would be most useful,  
> IMHO... but the question here is, how the IETF could make that  
> happen (or at least influence it).
>
> Cheers,
>
> Gonzalo

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 12 Feb 2009 08:23:01 -0500

>
>
> even if I would say  that sip developers  have to spend a  huge  
> amount of time and effort to get their tiny
> new, and probably already implemented, sip extensions standardized:  
> if they success!

And the "tail end" delays and frustration are one part of that. Ever  
longer dependency chains of drafts (examples that affect my own  
drafts: SIP outbound, now nearing four years since *ietf*-00, and  
mDNS, stalled indefinitely) are probably not exactly helpful.

If there was a way to take a risk and simply allow "down references"  
to drafts that are technically complete, but wending their way through  
the IETF management chain, we'd be able to cut a year or two off the  
publication delay in some cases.

Henning

---

From: Eric Burger <[email-masked]>
Date: Thu, 12 Feb 2009 09:18:25 -0500

Sounds like a call to take SIP to Draft. That will weed out what  
really is not being used...

On Feb 11, 2009, at 12:42 PM, Gonzalo Camarillo wrote:

>> standardize some aspect of a new application only to be told that  
>> the SIP feature they've used in their device was deprecated because  
>> it wasn't widely deployed in the current POTS replacement networks?  
>> [2]
>
> note that in my note I said "*never* implemented" and did not refer  
> early session. When we wrote that RFC in particular, we thought it  
> convinced most people it is not such a good idea. Obsoleting specs  
> that were *never* implemented and that we now think should be  
> implemented in different ways is a good thing, IMHO.
>
> I agree with what you say in your message and am quite sure we are  
> on the same page. I just wanted to clarify that the way you  
> referenced my previous email was not in line with what I had in mind.
>
> Cheers,
>
> Gonzalo
>

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 12 Feb 2009 08:22:09 -0600

I think this is just what we should do. 

Mary. 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Eric Burger
Sent: Thursday, February 12, 2009 8:18 AM
To: Gonzalo Camarillo
Cc: [email-masked]
Subject: Re: [RAI] RAI reorganization

Sounds like a call to take SIP to Draft. That will weed out what really
is not being used...

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 12 Feb 2009 08:41:21 -0600

I understand the scheduling problem, but the reality is that some folks
work in multiple clusters.  I'm not sure there's really a way around
that problem, this just gets back to the resource issue - i.e., we do
not have enough people to actually drive and complete the work that
folks say they want to do in the various WGs (with of course, SIP and
SIPPING behind the biggest problems).  We can look at the authorlist for
RAI folks and see that it is not unusual for folks to work in multiple
clusters:
http://www.arkko.com/tools/stats/authactdistr.html
Perhaps this is only a subset of people, but these are the core
contributors. 

Also given that it's very likely that some companies will not get all
their usual folks to this meeting, some of us may have to attend RAI
sessions that we usually don't need to attend. And, I don't see this
particular problem going away anytime soon. 

Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Cullen Jennings
Sent: Thursday, February 12, 2009 3:07 AM
To: Roni Even
Cc: [email-masked]
Subject: Re: [RAI] RAI reorganization - Clusters

On Feb 11, 2009, at 11:45 PM, Roni Even wrote:

> I strongly object to the idea of having more than two RAI WG at the 
> same time, there are relations between the WGs and even with the 
> situation today where we may have two RAI WG schedule at the same time

> I find it in some cases disturbing people from participating in all 
> the sessions they have interest in. Note that people are spending 
> money to come to the meetings and would like to attend as many 
> sessions as possible. I thought that adding Friday afternoon is the 
> price we pay for not having parallel sessions.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 12 Feb 2009 16:41:27 +0200

Hi,

we need to think of the ratio benefit/effort. Given the (low) amount of 
cycles we have available in RAI, I can think of activities with higher 
ratios at this point.

Cheers,

Gonzalo

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 12 Feb 2009 08:47:35 -0600

Cullen Jennings wrote:
> of the work. I believe it would help solve bottlenecks in both WG Chair 
> and AD processing as well as it could make it easier to schedule more 
> than two RAI WG at the same time. More importantly, it allow people to 
> find pockets of like minded folks.
> 

Cullen: These look good.  One question, though: the "Serverless"
cluster has only one item -- p2psip.  If the intent is to reduce
the number of clusters, can the item be moved to the "User"
cluster instead?  Or is it the case that the second quadrant
is for distributed systems and thus far, p2psip is the only
instance of concrete work we have in this area?

If the latter, then maybe re-naming that cluster to something
more descriptive like "Autonomic" or "Self-organizing" or
maybe even "Distributed" may be a good idea.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 12 Feb 2009 08:52:14 -0600

I don't disagree that we could prioritize other things above this
certainly - it's just entirely unknown based on past experience whether
something that folks think is critical to work on one week is at all
important the next week. I have honestly yet to see the correlation
between good progress on work items that are considered high priority
and the amount of effort put in by folks in the WG - i.e., the
tediousness of finalizing details and working out the intracacies of
race conditions/corner cases dims compared to working on shiny new
things. 

That all said, I do think that spinning out the work into more discrete
groups and areas of responsibility will help, as that does allow a WG
chair to more easily direct the focus of the WG  since the charter is
naturally narrower in scope.   So, I do agree we should go forward with
this restructuring proposal and work from there. As we go forward, if
there's a champion for taking SIP to draft standard and they're willing
to put in the cycles and the champion can get decent WG input and
feedback (that's another HUGE problem), I don't think we should exclude
that work. 

Regards,
Mary. 

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]] 
Sent: Thursday, February 12, 2009 8:41 AM
To: Barnes, Mary (RICH2:AR00)
Cc: Eric Burger; [email-masked]
Subject: Re: [RAI] RAI reorganization

Hi,

Cheers,

Gonzalo

Mary Barnes wrote:
>> to

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 12 Feb 2009 06:49:56 -0800

This is an excellent point, and many companies are already doing it. Example:

http://opensource.adobe.com/wiki/display/site/Projects

The reverse is also true: How can RAI list such efforts?

Henry

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Thursday, February 12, 2009 7:18 AM
To: Gonzalo Camarillo
Cc: Hannes Tschofenig; [email-masked]; [email-masked]; Henry Sinnreich
Subject: Re: [RAI] RAI reorganization

Henning

---

From: Eric Burger <[email-masked]>
Date: Thu, 12 Feb 2009 09:51:34 -0500

And, in total agreement with Mary, I would offer the whole POINT of  
the IETF meeting is cross-area pollination.  If we cannot even have  
cross-cluster pollination within RAI, that does not bode well for the  
future of the group.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 12 Feb 2009 09:01:58 -0600

Hannes Tschofenig wrote:
> I believe that there is a lack of usable open source SIP
> implementations that do things other than voice.

I think this characterization is right on, and I also think
that the problem is not that there is a lack of open source
implementations -- at last count, I counted 13 -- but rather
that there isn't THE open source implementation that everyone
intrinsically gravitates towards.

HTTP had this in form of the Apache project, browsers had this
in form of Mozilla first, followed by Netscape and now Firefox.
These open source implementations were simply the best in
their class, outperforming even commercial implementations
in features and functionality.  Alas, we in SIP have been unable
to coalesce around one such open implementation.

It is also clear that the above two examples were motivated by
universities -- UIUC in both cases (at least until Netscape deviated
from Mozilla and formed its own corporation.)

Now, to Gonzalo's question:

> IMHO... but the question here is, how the IETF could make that happen
> (or at least influence it).

I like Henning's answer to the question and Columbia, being the
stick that stirred the primordial soup of SIP is in the best
position to spearhead an effort of this size.  I doubt that
commercial companies -- large or small -- will release their code
as open source, not because the technical principles in the
companies do not want to, but rather because it is often
encumbered with intellectual property, may provide a glimpse
of business process to competitor companies, and the people who
will be signing off on such an agreement most often do not have
the foresight to justify the benefits of open source.  But I
agree that companies can help sponsor "summer-of-code" and
the like.

Out of curiosity, did W3C or any other standards body provide
any form of impetus to Apache or Netscape?  Does anyone remember?
If so, that may be a potential model to look at when we examine
what the IETF can do to foster open source SIP implementations.

Thanks,

- vijay

---

From: Jon Peterson <[email-masked]>
Date: Thu, 12 Feb 2009 07:32:16 -0800

Pollination is something that happens naturally when you unleash the 
bees. I don't think we're in imminent danger of wanting for 
cross-cluster or cross-area input or review on documents - I think the 
danger today is that we have so much that the process of 
consensus-building is often a war of attrition waged against 
participants harboring assumptions that cannot be reconciled with your 
own. Only when those parties have grown so weary that they dismiss the 
offending work can documents advance - into a deafening silence that we 
generously take for assent. I am  frightened at how many examples of 
this leap to mind, at all levels of our process.

There are times, when basic interoperability is at stake, when these 
wars need to be fought. There are other times, around the periphery of 
the protocol, when we campaign needlessly. Clusters are one way of 
modeling the magnitude of change and the level of attention a proposal 
requires in order for it to escape our scope and enter the Last 
Call/IESG process - where it will accumulate all the pollen it might need.

Jon Peterson
NeuStar, Inc.

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 12 Feb 2009 10:02:34 -0600

Jon,

I can't disagree with what you say. IMHO, the deafening silences is
again a resource issue - there is a fairly small subset of key
contributors. While I currently appreciate the folks that volunteer to
do reviews of documents we are progressing in SIPPING, it doesn't seem
that feedback from around 4 people really constitutes consensus. We are
in the unfortunate position of that being the best we've got and in
order to make progress. So, I do think we need a way to bring new
contributors into the work in these new WGs - perhaps stating that if we
don't have anyone new that is willing to contribute in these new WGs, we
don't charter it and we set milestones such that if x amount of progress
is not made (e.g., requirements doc complete in 4 mos, framework in 8
mos and protocol within 12-18 mos), then we close the WG.  

A question that comes to my mind is whether we have any examples of
things that we've done right in terms of a reasonable consensus reached,
good feedback from the WG during all stages of progression, completion
within a reasonable timeframe, etc.?  Perhaps that will also help us
better model the structure of the work. I might say in SIPPING the
update-pai work was fairly effective, although in the end, functionality
that a subset of folks wanted in that document was removed. As you note
and per the recent thread of discussion, there are quite disparate
intents for the use of SIP, so trying to come to a true consensus based
agreement, where a majority is satisfied with the results is virtually
impossible. Over the years, folks have gotten more accepting of these
disparate usages, but it does naturally lend itself to difficulty in
getting a majority of the WG interested in the work items.  So, I think
we need to narrowly scope the new WGs, accepting that what we do in some
cases just isn't generally applicable (at least based on folks' current
requirements).  

Regards,
Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jon Peterson
Sent: Thursday, February 12, 2009 9:32 AM
To: Eric Burger
Cc: [email-masked]
Subject: Re: [RAI] RAI reorganization - Clusters

Call/IESG process - where it will accumulate all the pollen it might
need.

Jon Peterson
NeuStar, Inc.

Eric Burger wrote:
> > I understand the scheduling problem, but the reality is that some 
> > folks work in multiple clusters.  I'm not sure there's really a way 
> > around that problem, this just gets back to the resource issue - 
> > i.e., we do not have enough people to actually drive and complete 
> > the work that folks say they want to do in the various WGs (with of 
> > course, SIP and SIPPING behind the biggest problems).  We can look 
> > at the authorlist for RAI folks and see that it is not unusual for 
> > folks to work in multiple
> > clusters:
> > Also given that it's very likely that some companies will not get 
> > all their usual folks to this meeting, some of us may have to attend

> > RAI sessions that we usually don't need to attend. And, I don't see 
> > this particular problem going away anytime soon.
> >
> > Mary.
> >
> > From: [email-masked] [mailto:[email-masked]] On Behalf 
> > Of Cullen Jennings

> > Thanks thats good feedback. (Particularly given we are about to 
> > start all the IETF 74 schedule conflict resolution)
> >

---

From: Tom Taylor <[email-masked]>
Date: Thu, 12 Feb 2009 11:10:03 -0500

The picture in AVT is very different. Except for matters of basic RTP/RTCP 
architecture, there isn't much that we do that will draw comments from very many 
people, and we accept that. We Chairs review documents to make sure they come up 
to standard, but our consensus often works on the basis of: "... if no one 
objects ...". Perhaps you need to sort out the routine from the fundamental 
stuff and apply the "if no one objects" principle to the routine stuff.

> cases just isn't generally applicable (at least based on folks' current
...

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 12 Feb 2009 19:04:59 +0200

Hi Vijay,
 
>their class, outperforming even commercial implementations in 
>features and functionality.  Alas, we in SIP have been unable 
>universities -- UIUC in both cases (at least until Netscape 
>deviated from Mozilla and formed its own corporation.)

I believe the important part is implementations that end users can actually
use. 

When I searched for IM/presence based clients then I did not run into a lot
of usable SIP implementations. If there many then maybe we should put them
someone on a Wiki page. 

The same is true for other extensions. 

>I like Henning's answer to the question and Columbia, being 
>the stick that stirred the primordial soup of SIP is in the 
>best position to spearhead an effort of this size.  I doubt 
>that commercial companies -- large or small -- will release 
>their code as open source, not because the technical 
>principles in the companies do not want to, but rather because 
>it is often encumbered with intellectual property, may provide 
>a glimpse of business process to competitor companies, and the 
>people who will be signing off on such an agreement most often 
>do not have the foresight to justify the benefits of open 
>source.  But I agree that companies can help sponsor 
>"summer-of-code" and the like.
>
>If so, that may be a potential model to look at when we 
>examine what the IETF can do to foster open source SIP implementations.

For example, I impressed by the folks producing OAUTH implementations (a BOF
that will happen at the next IETF meeting): http://oauth.net/code

I believe it is fair to say that many proposals that are being brought
forward are not supported by code. This is quite logical if you consider
what most folks have experienced. When you have code written already and you
bring your proposal forward then you will notice the following thing:
Whatever proposal you have it will get changed so much, even at very late
stages in the IETF process, so that your implementation work is only good
for the trashcan. Unfortunately, the reason for changes is often based on
philosophical grounds. I have had cases where ADs have essentially
"re-written" the output of a working group because they thought it could be
done differently. 

There are, unfortunately, many examples that support my statement. 

Ciao
Hannes

>
>Thanks,
>
>- vijay
>--
>Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 
>Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 12 Feb 2009 19:05:47 +0200

SIP to Draft topic: If the idea is to 
* fix bugs 
* remove functionality that has never been implemented 
* add clarifications 
then this sounds useful but I don't think that upgrading the status of
document as such is very useful by itself. 
 
I can share the experience we have made in DIME. We are about to finalize
the Diameter Base specification. We are working on a revision of the
previous specification. The changes are, as previously listed, focused on
these three items. 
I thought that the work was useful but it certainly consumed a lot of
resoures in the group but it was clearly necessary since folks (especially
outside the IETF) got confused about some aspects.  

Ciao
Hannes

>Behalf Of Mary Barnes
>Sent: 12 February, 2009 16:22
>To: Eric Burger; Gonzalo Camarillo
>Cc: [email-masked]
>Behalf Of Eric Burger
>Sounds like a call to take SIP to Draft. That will weed out 
>what really is not being used...
>
>told that the
>not refer to

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 12 Feb 2009 11:21:54 -0600

In my mind, the work items you suggest was what I was thinking we should
do.

Mary.

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Thursday, February 12, 2009 11:06 AM
To: Barnes, Mary (RICH2:AR00); 'Eric Burger'; 'Gonzalo Camarillo'
Cc: [email-masked]
Subject: SIP to Draft -- was [RAI] RAI reorganization

I can share the experience we have made in DIME. We are about to
finalize the Diameter Base specification. We are working on a revision
of the previous specification. The changes are, as previously listed,
focused on these three items. 
I thought that the work was useful but it certainly consumed a lot of
resoures in the group but it was clearly necessary since folks
(especially outside the IETF) got confused about some aspects.  

Ciao
Hannes

>Mary Barnes

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 12 Feb 2009 12:43:03 -0500

I think the W3C markup validation service (http://validator.w3.org/)  
is a useful example. For what it's worth, we're working on something  
vaguely similar for testing some aspects of SIP implementations (we  
mentioned this during the SIPForum interop lunch workshop a few IETFs  
ago), but it's a "hobby" project since this isn't something the NSF  
will fund.

W3C also has done work - http://www.w3.org/Status.html

I don't know if they act more like an umbrella organization, similar  
to the Apache Foundation, or actually have staff devoted to writing  
code. Their membership model obviously makes the latter more feasible.

Henning

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 12 Feb 2009 13:02:36 -0600

Henning, Hannes:

> code. Their membership model obviously makes the latter more

The closest we would have to the equivalent of the Apache
Foundation in our case would be the SIP Forum.  However, I doubt
that the SIP Forum would be interested in coming up with THE
canonical implementation of SIP.  Given that its operating
expenses derive from member companies, I doubt that the member
companies would want to contribute towards creating a state-
of-the-art canonical implementation that may prove to be an
impedance to their respective commercial implementations.

For better or worse, this has to be done by a university or
a university consortium.

Hannes Tschofenig  wrote:
> When I searched for IM/presence based clients then I did not run into
> a lot of usable SIP implementations.

Sure; I did not say that the all 13 implementations were
usable as general purpose SIP stacks, just that there were
a wide variety to choose from.

Given the trajectory of SIP -- its rapid ascent from academic-
industrial complex laboratories to the protocol of choice for
global service providers -- made it impossible for an impartial
entity to take a vested interest to create something durable.
That is why I think that an university consortium of some
sort will be the best place to provide a best-of-breed open
source SIP stack.

Ciao.

- vijay

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 12 Feb 2009 21:35:53 +0200

Something needs to be done. That's obvious.

It would be nice to just kick the ball to Henning (and later blame him in
case it did not work). 

Btw, RAI is not the only place with problems of open source code. I co-chair
the DIME working group and there we have the following problem: Diameter
(maintained in DIME) is the follow-up protocol of RADIUS (another IETF
protocol still developed in RADEXT). For RADIUS there is open source code
available (with the best implementation being FreeRADIUS) but for Diameter
the excitement by companies was rather limited to make their code available.
We have lots of commercial implementations and one open source
implementation, namely OpenDiameter, but the functionality provided by
FreeRADIUS is much larger and FreeRADIUS is more mature. Additionally, folks
got the impression that RADIUS is much simpler than Diameter. When Diameter
was developed in the IETF companies believed that their products will
generate them a lot of money (and Diameter was picked up by the 3GPP fairly
quickly as well). The current situation, in my view, is that in some market
segments there is essentially no Diameter deployment while in the larger
operator circles it finds excitement (although deployment takes a long time
there). 

Does this sound familiar? 

Ciao
Hannes

PS: We have not found out how to improve the open source Diameter situation
either. 

>Behalf Of Vijay K. Gurbani
>Sent: 12 February, 2009 21:03
>To: [email-masked]
>Foundation in our case would be the SIP Forum.  However, I 
>doubt that the SIP Forum would be interested in coming up with 
>THE canonical implementation of SIP.  Given that its operating 
>For better or worse, this has to be done by a university or a 
>university consortium.
>
>Hannes Tschofenig  wrote:
>usable as general purpose SIP stacks, just that there were a 
>wide variety to choose from.
>
>global service providers -- made it impossible for an 
>impartial entity to take a vested interest to create something durable.
>That is why I think that an university consortium of some sort 
>will be the best place to provide a best-of-breed open source 
>SIP stack.
>
>Ciao.
>
>- vijay
>--

---

From: Ben Campbell <[email-masked]>
Date: Thu, 12 Feb 2009 14:33:34 -0600

On Feb 11, 2009, at 5:28 PM, Adam Roach wrote:

> replacement. I'm boggled that we've come so far that such an  
> assertion even needs to be given a voice, much less a defense.  
> (Marcus' voice is not isolated; several key people have expressed  
> equivalent sentiments.)
>
> structure SIP work is based -- at least, in part -- on its promise  
> for emerging and future applications, not just as ISUP with a  
> different syntax.
>
> message, seems sound to me. We need to make sure we don't trample  
> innovation as we fill in the details.
>

I'm mainly adding my +1 to Adam's line of reasoning, with one  
additional comment:

If we _did_ decide to treat SIP as (primarily) a PSTN replacement  
protocol, then it would make better sense to transition it out of the  
IETF in general, and let us get back to this Internet thing. (Before  
anyone calls "strawman" or "reduction to absurdity"--yes, I fully  
realize I am doing both.)

There are telecom standards groups that know a lot more about  
developing telecom standards than we do. The whole reason for keeping  
IETF control over SIP in the first place is to keep it applicable in  
the Internet in general.

>> this "refocusing" aspect of modest-proposal (though it does follow  
>> the suggestion in that document regarding P- headers). Attempting  
>> to constrain or prioritize work in the IETF is a non-trivial matter  
>> - we charter work that our participants form a consensus to  
>> undertake, and the energy of participants inevitably refuses to  
>> conform to administrative expectations. It is a peculiar but  
>> undeniable truth that the motivations of our contributors are often  
>> misaligned with the tactical needs of the marketplace - however,  
>> the only force that can hope to sway those contributors is  
>> grassroots consensus building, not proclamations from IETF  
>> leadership.
>>
>> I think the best we can do, really, is to try to decentralize work  
>> as much as possible, so that participants who do not share  
>> complementary goals can work independently. This is the point of  
>> the DISPATCH incubator process and the move to avoid doing protocol  
>> work in the room everyone feels obliged to fill. Provided that we  
>> can realize this independence without sacrificing the core tenets  
>> of interoperability, we will probably have reached the most  
>> plausible compromise.
>>
>>> excision of

---

From: Ben Campbell <[email-masked]>
Date: Thu, 12 Feb 2009 14:38:23 -0600

On Feb 11, 2009, at 7:44 PM, Cullen Jennings wrote:

> meeting and Jon and I have been thinking about them as an  
> organization of the work. I believe it would help solve bottlenecks  
> in both WG Chair and AD processing as well as it could make it  
> easier to schedule more than two RAI WG at the same time. More  
> importantly, it allow people to find pockets of like minded folks.

It's not entirely clear to me how a "cluster" differs from an "area".  
Is it simply because we can procedurally create them more easily than  
we can "areas"?

[...]

---

From: Ben Campbell <[email-masked]>
Date: Thu, 12 Feb 2009 14:41:17 -0600

On Feb 12, 2009, at 3:06 AM, Cullen Jennings wrote:

>> same

With a few possible exceptions, add my +1 to Roni. Otherwise I fear we  
end up with SIP for p2p, SIP for peering, SIP for conferencing, etc.

---

From: Adam Roach <[email-masked]>
Date: Thu, 12 Feb 2009 14:45:53 -0600

The resiprocate project (http://www.resiprocate.org/) has long been a 
place where we've tried out new and emerging SIP extensions while 
they're still in draft, and we've taken feedback to relevant working 
groups on numerous occasions. (We actually caught something that was 
technically unimplementable in the SIP/SigComp work this way). The 
project encompasses not just SIP, but an entire infrastructure of 
protocols including STUN, TURN, and ICE (and new development on things 
like the p2psip protocols).

Some of the key contributors working on the resiprocate project include 
me, Robert Sparks, Cullen Jennings,  Rohan Mahy, Alan Hawrylyshen, Derek 
MacDonald, Jason Fischl, and Byron Campen. You may recognize us from the 
44 or so RAI-related RFCs with our names on them.

We have a lot of participation from non-IETF folks as well. Several 
companies do recontribute significant quantities of code back to the 
project -- and dozens (if not hundreds) more use the stack in 
commercially deployed products. It is released under licensing terms 
that are suitable for both open-source and proprietary development. We 
have regular, high-quality releases (thanks, Byron!), and a very 
responsive developer community.

If this isn't what you're looking for, please let us know why.

/a

Hannes Tschofenig wrote:
>>> code. Their membership model obviously makes the latter more 
>>>       
>> feasible.
>>
>>> When I searched for IM/presence based clients then I did not 
>>>       
>> run into 
>>

---

From: Adam Roach <[email-masked]>
Date: Thu, 12 Feb 2009 14:56:03 -0600

Adam Roach wrote:
>
> Some of the key contributors working on the resiprocate project 
> include me, Robert Sparks, Cullen Jennings,  Rohan Mahy, Alan 
> Hawrylyshen, Derek MacDonald, Jason Fischl, and Byron Campen. You may 
> recognize us from the 44 or so RAI-related RFCs with our names on them.

Sorry -- I left off EKR, who would bring that total up to 58.

/a

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 12 Feb 2009 16:12:05 -0500

Are we really lacking SIP stacks?

My perception is that what's lacking are more attractive, reliable and  
easy-to-use applications and, in some cases, easy-to-install servers  
(e.g., for IM, conferencing and presence).

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 12 Feb 2009 15:21:37 -0600

I completely agree with Henning.
 
SIP stacks are not the issue.

________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Henning Schulzrinne
	Sent: Thursday, February 12, 2009 13:12
	To: Vijay K. Gurbani
	Cc: [email-masked]
	Subject: Re: [RAI] RAI reorganization

	My perception is that what's lacking are more attractive, reliable and easy-to-use applications and, in some cases, easy-to-install servers (e.g., for IM, conferencing and presence).

		
		
		Ciao.
		
		- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 12 Feb 2009 15:38:00 -0600

> 44 or so RAI-related RFCs with our names on them.

Adam: Indeed, I do recognize some of the names ;-)

> If this isn't what you're looking for, please let us know why.

AFAICR, the last time I looked at resiprocate was circa 2000-01,
when it was tied to Vovida in some manner (I no longer recall
the exact nature, except my mind has maintained a close tie
between resiprocate and Vovida.)  Back then, compilation was
not a smooth process and after playing around with it a bit,
I continued to an internal stack we were developing at Bell Labs.
When I put TLS in our native stack around 2004-05, I did look at
some of the code for SAN matching, etc. from resiprocate but did
not download it in entirety and compile it.

I am sure that since then the code has evolved in a fairly
organized manner, especially given the marquee names associated
with it.  But even today, when someone asks me what is the
best open source SIP stack, somehow resiprocate does not
percolate to the top.  Given so many other open source SIP
stacks cropping up in the recent past (not 9-10 years ago),
what is lacking in resiprocate that others went ahead and
forged yet more open source SIP projects?  Why did it not get
picked by Asterisk, for instance, as the default SIP stack?

To answer your question "if this is not what you are looking
for, why?", I would have to revisit resiprocate in more detail now
and re-evaluate it on compilation, extensibility, installation,
reliability, and scalability, etc.

Thanks,

- vijay

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Thu, 12 Feb 2009 16:43:47 -0500

I agree.  Need an application that is super reliable, easy-to-use,
universal to any user on the Internet, where the technology is
transparent to any minimally educated end-users.  Hmmmm, how about
voice?

Oh yeah, I forgot, that is the POTS replacement thing.  Nevermind. ;)

Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Francois Audet
Sent: Thursday, February 12, 2009 4:22 PM
To: Henning Schulzrinne; Vijay K. Gurbani
Cc: [email-masked]
Subject: Re: [RAI] RAI reorganization

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Henning Schulzrinne
	Sent: Thursday, February 12, 2009 13:12
	To: Vijay K. Gurbani
	Cc: [email-masked]
	Subject: Re: [RAI] RAI reorganization

	My perception is that what's lacking are more attractive,
reliable and easy-to-use applications and, in some cases,
easy-to-install servers (e.g., for IM, conferencing and presence).

		
		That is why I think that an university consortium of
some
		sort will be the best place to provide a best-of-breed
open
		source SIP stack.
		
		Ciao.
		
		- vijay
		1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566
(USA)

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 12 Feb 2009 15:48:29 -0600

> Are we really lacking SIP stacks?

No; we are lacking the /best-of-breed/ open source SIP stack --
an Apache equivalent for SIP.  Is it Asterisk?  Is it OpenSER?
Is it resiprocate?

> (e.g., for IM, conferencing and presence).

The quest for attractive, reliable and easy-to-use
applications will always continue.  I think its more that SIP
is expansive enough that it fills many nooks and crannies.  Thus,
if I want a PBX solution, I look at Asterisk; if I want a SIP
stack with TLS and SRTP, I  look at minisip; if I want VoIP and
IM, I may look at Sofia-SIP and resiprocate; if I want p2p SIP, I
look at <insert favorite here>; and so on.

Thanks,

- vijay

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 13 Feb 2009 00:32:52 +0200

For some features we are not lacking quantity but quality. 

	From: [email-masked] [mailto:[email-masked]] On Behalf
Of Henning Schulzrinne
	Sent: 12 February, 2009 23:12
	To: Vijay K. Gurbani
	Cc: [email-masked]
	Subject: Re: [RAI] RAI reorganization

	My perception is that what's lacking are more attractive, reliable
and easy-to-use applications and, in some cases, easy-to-install servers
(e.g., for IM, conferencing and presence).

		
		
		Ciao.
		
		- vijay

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 13 Feb 2009 16:00:35 +0200

Hi,

> Or is it the case that the second quadrant

that was the idea when I presented the clusters in the last meeting (see 
Slide 11 of the presentation below).

http://www.ietf.org/proceedings/08nov/slides/raiarea-2/raiarea-2.htm

But that was a straw-man proposal... comments are very welcome!

Cheers,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 13 Feb 2009 16:03:47 +0200

Hi,

at the end of the 90s, I thought the Columbia implementation was going 
to become *the* reference SIP implementation. Even the name (sipd) was 
similar to Apache (httpd) :o). Unfortunately, as you pointed out, that 
did not happen.

Cheers,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 13 Feb 2009 16:24:51 +0200

+1

Gonzalo

Francois Audet wrote:
>     *From:* [email-masked] [mailto:[email-masked]] *On
>     Behalf Of *Henning Schulzrinne
>     *Sent:* Thursday, February 12, 2009 13:12
>     *To:* Vijay K. Gurbani
>     *Cc:* [email-masked]
>     *Subject:* Re: [RAI] RAI reorganization
> 
>     and easy-to-use applications and, in some cases, easy-to-install
>     servers (e.g., for IM, conferencing and presence).
> 
>>
>>
>>     [email-masked] <mailto:[email-masked]>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 13 Feb 2009 14:59:40 +0000

Cullen,

I am just curious about why BLISS is placed in the Peering cluster (and
why it is in black rather than white). Looking at much of what it does,
I would consider it nearer the top of the picture, i.e., more
user-centric.

John 

> Behalf Of Cullen Jennings
> Sent: 12 February 2009 01:44
> organization

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 13 Feb 2009 09:00:23 -0600

> longer dependency chains of drafts (examples that affect my own  drafts: 
> SIP outbound, now nearing four years since *ietf*-00, and  mDNS, stalled 
> indefinitely) are probably not exactly helpful.
>
> If there was a way to take a risk and simply allow "down references"  to 
> drafts that are technically complete, but wending their way through  the 
> IETF management chain, we'd be able to cut a year or two off the 

In March 2004, Scott Bradner proposed "Stable Snapshots" (SSS), and Dave 
Crocker, Charlie Perkins and I proposed "Working Group Snapshots" (WGS). SSS 
and WGS did not differ much (great minds think alike, apparently).

At least WGSs were stable references that a working group could checkpoint 
for any reason, including "working group thinks we're through, publication 
is requested". The point was that the references were stable, so in the 
cases where it was appropriate to do so, they could be down-referenced in 
other documents.

The IESG at that time didn't pursue these proposals, but the IESG population 
will have almost completely "turned over" after IETF 74, so maybe it's time 
to think about this again.

Speaking only for myself about MEDIACTRL, we have three drafts that are 
"stable", but we're still collecting implementation reports (this is not a 
bad thing) on all three, so if WGS or the moral equivalent was available, we 
might consider checkpointing WGS all three drafts, instead of (1) leaving 
them hanging for a couple of IETF cycles as drafts-like-any-others, or (2) 
requesting publication as Proposed Standards, knowing that we may be doing 
"-bis" versions fairly quickly.

Historical URLs are available at

http://www.watersprings.org/pub/id/draft-dawkins-newtrk-wgs-00.txt

http://www.watersprings.org/pub/id/draft-bradner-ietf-stds-trk-01.txt

Thanks,

Spencer

---

From: Eric Burger <[email-masked]>
Date: Fri, 13 Feb 2009 12:12:53 -0500

Although slightly dated, what about:
http://www.sipforum.org/content/category/6/39/193/

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 13 Feb 2009 18:37:08 -0500

Yeesh, that doesn't bode well for SIPCORE being any less than SIP today.

I thought in Jon's email he said part of this change would mean on-going security work would find a new home, but you have it all going to SIPCORE.
Is that an oversight?

-hadriel

> Sent: Wednesday, February 11, 2009 8:55 PM
> To: Jonathan Rosenberg; [email-masked]
> Subject: Re: [RAI] RAI reorganization - allocation of existing work
>
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 13 Feb 2009 18:53:22 -0500

If we're considering making new Header registration easier, can we also consider relaxing the rules for registering new option tags - to revert back to the rfc2543 model?

It has some of the same properties of the P-header experience.  (1) It hasn't prevented anyone from adding dozens of option tags, (2) it has caused some interop issues because they've been put into the wrong fields, and (3) there are some from different vendors which essentially do the same thing.

Problem (2) would be helped if it had an explanation of its purpose and expert review, because we'd catch cases where they need to put it in additional places (in particular, Proxy-Require), or in cases when they should not (eg, when they should put it in Supported but not Require).  Problem (3) would be helped because we'd find some that are actually useful and drive a standards-track one.

What's worse is that the current restrictions for option tags, and the time it takes to go through standards-track, are making some groups decide to avoid creating/using one when they really should.

-hadriel

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Jon
> Peterson
> Sent: Wednesday, February 04, 2009 5:00 PM
> To: [email-masked]

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 13 Feb 2009 17:59:29 -0600

Again, I think this is neighter necessary nor desireable. I also think
defining a new header or parameter or whatever is quite
masochistic.

Today, this is all handled through configuration on the
Service Provider side. I don't see any reason to change it
really, and doubt anybody will feel compelled to change their
code, if it already works. Even if we do add a parameter, 
I think the SP will still want to handle it with 
configuration as opposed to protocol on the wire.

If we really needed one, I'd pick the ;lr idea. 

> Behalf Of Hadriel Kaplan
> Sent: Friday, February 13, 2009 15:53
> To: Jon Peterson; [email-masked]
> Subject: [RAI] Option-tag registration
> 
> 
> If we're considering making new Header registration easier, 
> can we also consider relaxing the rules for registering new 
> option tags - to revert back to the rfc2543 model?
> 
> It has some of the same properties of the P-header 
> experience.  (1) It hasn't prevented anyone from adding 
> dozens of option tags, (2) it has caused some interop issues 
> because they've been put into the wrong fields, and (3) there 
> are some from different vendors which essentially do the same thing.
> 
> Problem (2) would be helped if it had an explanation of its 
> purpose and expert review, because we'd catch cases where 
> they need to put it in additional places (in particular, 
> Proxy-Require), or in cases when they should not (eg, when 
> they should put it in Supported but not Require).  Problem 
> (3) would be helped because we'd find some that are actually 
> useful and drive a standards-track one.
> 
> What's worse is that the current restrictions for option 
> tags, and the time it takes to go through standards-track, 
> are making some groups decide to avoid creating/using one 
> when they really should.
> 
> -hadriel
> 
> 
> 
> Behalf Of 
> > "edges" of the RAI area without depending on winning the

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 13 Feb 2009 19:08:31 -0500

What part do you think is neither necessary nor desireable?
Relaxing rules for option tag registration in SIP?

(I think you posted your reply on the wrong list - I sent this to *RAI* - this was a general comment about option tags, not specific about what may or may not be happening in some other industry forum - that other discussion just reminded me to send this email to IETF)

-hadriel

> Sent: Friday, February 13, 2009 6:59 PM
>

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 13 Feb 2009 18:14:18 -0600

You are absolutely correct.

I responded to the wrong message (from you), to the 
wrong list...

Ooops... (later Friday)

My appologies. Please discard my email.

> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: Friday, February 13, 2009 16:09
> To: Audet, Francois (SC100:3055); [email-masked]
> Subject: RE: [RAI] Option-tag registration
> 
> 
> (I think you posted your reply on the wrong list - I sent 
> this to *RAI* - this was a general comment about option tags, 
> not specific about what may or may not be happening in some 
> other industry forum - that other discussion just reminded me 
> to send this email to IETF)
> 
> -hadriel
> 
> 
> > defining a new header or parameter or whatever is quite masochistic.
> >
> > Today, this is all handled through configuration on the Service 
> > Provider side. I don't see any reason to change it really, 
> and doubt 
> > anybody will feel compelled to change their code, if it 
> already works. 
> > Even if we do add a parameter, I think the SP will still want to 
> > handle it with configuration as opposed to protocol on the wire.
> >
> > > Of Hadriel Kaplan
> > > If we're considering making new Header registration 
> easier, can we 
> > > also consider relaxing the rules for registering new 
> option tags - 
> experience.  (1) 
> > > It hasn't prevented anyone from adding dozens of option 
> tags, (2) it 
> > > has caused some interop issues because they've been put into the 
> > > wrong fields, and (3) there are some from different vendors which 
> > > essentially do the same thing.
> > >
> > > Problem (2) would be helped if it had an explanation of 
> its purpose 
> > > and expert review, because we'd catch cases where they 
> need to put 
> > > it in additional places (in particular, Proxy-Require), 
> or in cases 
> > > when they should not (eg, when they should put it in 
> Supported but 
> > > not Require).  Problem
> > > (3) would be helped because we'd find some that are 
> actually useful 
> > > and drive a standards-track one.
> > >
> tags, and 
> > > the time it takes to go through standards-track, are making some 
> > > groups decide to avoid creating/using one when they really should.
> > >
> > > -hadriel
> > >
>

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 14 Feb 2009 22:10:08 +0200

Hi Cullen, 

I never really understood the cluster idea. 

First, the concept has never really described in great detail and also Jon's
mail about the RAI organization was silent about this subject. I believe
more context would be useful to make a decision.  

Second, I am not sure clusters will help with the scheduling of the working
groups. As mentioned in other mails folks participate in various groups
spanning multiple clusters. Why not simply talk to the secretary and give
them more info on how to schedule the meetings in a proper fashion? 

Finally, I wonder if the **main idea** therefore is that there is another
layer of management in order to offload work from the ADs (or maybe also
from existing working group chairs). In
http://www.ietf.org/proceedings/08nov/slides/raiarea-2/raiarea-2.htm I see
the concept of a cluster manager (a sort of "super-working group chair").
There isn't really a description of the detailed tasks of this person. 

Ciao
Hannes

PS: I am not even sure folks at the last meeting actually liked the cluster
idea or any of the other ideas given that there wasn't enough time for a
discussion. 

>Sent: 12 February, 2009 03:44
>The clusters seemed like an idea that most people liked at the 
>last meeting and Jon and I have been thinking about them as an 
>organization of the work. I believe it would help solve 
>bottlenecks in both WG Chair and AD processing as well as it 
>could make it easier to schedule more than two RAI WG at the 
>same time. More importantly, it allow people to find pockets 
>of like minded folks.
>
>Right now, I'd paint the clusters as looking something like 
>the attached file.
>
>

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 14 Feb 2009 23:33:56 +0200

It is a start. 

See what other's are doing: http://www.jabber.org/web/Clients
The page is easy to understand, the links work (at least the onces I
checked), and the software is good. I am using Pidgin. 

Ciao
Hannes

PS: I know that not every client/server software offered on Jabber.org is
available as open source. 

>From: Eric Burger [mailto:[email-masked]] 
>Sent: 13 February, 2009 19:13
>To: Hannes Tschofenig
>Cc: [email-masked]
>Subject: Re: [RAI] Code -- was RE: RAI reorganization
>
>that the 
>>> problem is not that there is a lack of open source 
>implementations -- 
>>> at last count, I counted 13 -- but rather that there isn't THE open 
>>> source implementation that everyone intrinsically 
>gravitates towards.
>>>
>>> HTTP had this in form of the Apache project, browsers had this in 
>>> form of Mozilla first, followed by Netscape and now Firefox.
>>> These open source implementations were simply the best in their 
>>> class, outperforming even commercial implementations in 
>features and 
>>> functionality.  Alas, we in SIP have been unable to coalesce around 
>>> one such open implementation.
>>>
>deviated 
>> I believe the important part is implementations that end users can 
>> actually use.
>>
>> a lot of usable SIP implementations. If there many then maybe we 
>> should put them someone on a Wiki page.
>>
>the stick 
>>> that stirred the primordial soup of SIP is in the best position to 
>>> spearhead an effort of this size.  I doubt that commercial 
>companies 
>>> -- large or small -- will release their code as open source, not 
>>> because the technical principles in the companies do not 
>want to, but 
>>> rather because it is often encumbered with intellectual 
>property, may 
>>> provide a glimpse of business process to competitor companies, and 
>>> the people who will be signing off on such an agreement 
>most often do 
>>> not have the foresight to justify the benefits of open 
>source.  But I 
>>> agree that companies can help sponsor "summer-of-code" and the like.
>>>
>>> Out of curiosity, did W3C or any other standards body provide any 
>>> form of impetus to Apache or Netscape?  Does anyone remember?
>examine what 
>>> the IETF can do to foster open source SIP implementations.
>>
>> For example, I impressed by the folks producing OAUTH 
>implementations 
>> (a BOF that will happen at the next IETF meeting): 
>> http://oauth.net/code
>>
>>
>> forward are not supported by code. This is quite logical if you 
>> consider what most folks have experienced. When you have 
>code written 
>> already and you bring your proposal forward then you will notice the 
>> following thing:
>> Whatever proposal you have it will get changed so much, even at very 
>> late stages in the IETF process, so that your implementation work is 
>> only good for the trashcan. Unfortunately, the reason for changes is 
>> often based on philosophical grounds. I have had cases where 
>ADs have 
>> essentially "re-written" the output of a working group because they 
>> thought it could be done differently.
>>
>Lucent Lane, 
>>> Rm. 9C-533, Naperville, Illinois 60566 (USA)

---

From: <[email-masked]>
Date: Mon, 16 Feb 2009 00:54:59 +0100

Hi Adam, others,

>have expressed equivalent sentiments.)

Just to clarify where I stand:

I agree that communication over Internet should go far beyond what POTS has enabled, and of course this has happened already in many ways. I don't think anyone challenges that. Our goal should be to develop the best possible open standards that can deliver various kinds of real-time/messaging/multimedia apps.

The issue that is more controversial is the role of SIP and RAI area protocols in general in all of that. SIP is clearly taking the POTS/PBX replacement market and has quite good fundamentals for telephony and video. However, for other apps there are competing/complementary approaches, such as XMPP and web/AJAX-based mechanisms. For instance if I was today to create an open standard real-time communication app I could pick SIP for voice/video, XMPP for presence/IM and a web-based solution for some of the conferencing/collaboration features.

The question is where to focus the precious resources in RAI to create most *new* value. In addition to developing its own protocols it would be good for RAI to think how its protocols interact with these "external" protocols and what would be the best way to use them together to create the best possible solution for Internet users.

Markus

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 16 Feb 2009 07:43:00 +0000

>From this list it would seem SIPPING has relatively few work items. I
thought the exercise was partly aimed at reducing the load on SIP and
SIPPING.

John 

> Sent: 12 February 2009 01:55
> existing

---

From: Jiri Kuthan <[email-masked]>
Date: Sun, 15 Feb 2009 10:33:04 +0100

I think a much bigger problem is maintaining existing stuff
than creating now one. Sponsoring maintenance seems not only
useful but also safer -- one spends money on what is known
to work already. Maybe a good new mission for SIP Forum?

-jiri

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 17 Feb 2009 15:40:19 -0600

>SIP to Draft topic: If the idea is to

Mary -- is one of the bug fixes you had in mind fixing anywhere that 
there are multiple ways of doing a function - making sure there is 
ONE mandatory to implement (that everyone implements) way to do that function?

this is a bug IMO for many capabilities in SIP

---

From: "Mary Barnes" <[email-masked]>
Date: Tue, 17 Feb 2009 17:25:51 -0600

James,

Response below - [MB].

Mary.

-----Original Message-----
From: James M. Polk [mailto:[email-masked]] 
Sent: Tuesday, February 17, 2009 3:40 PM
To: Barnes, Mary (RICH2:AR00); Hannes Tschofenig; Eric Burger; Gonzalo
Camarillo
Cc: [email-masked]
Subject: Re: [RAI] SIP to Draft -- was RAI reorganization

At 11:21 AM 2/12/2009, Mary Barnes wrote:
>In my mind, the work items you suggest was what I was thinking we 
>should do.
>
>Mary.
>

Mary -- is one of the bug fixes you had in mind fixing anywhere that
there are multiple ways of doing a function - making sure there is ONE
mandatory to implement (that everyone implements) way to do that
function?

[MB] If there are cases where the text is so loose such that multiple
ways of doing something are valid, then yes, we should pick one.   And,
I think these cases exist given that we have several BCPs in SIPPING to
clarify the text - e.g., offer-answer and race (although the
offer-answer issues also cover other RFCs - 3264, 3262).  [/MB] 

this is a bug IMO for many capabilities in SIP
[MB] I think these can be viewed as bugs in the spec in terms of not
being explicit enough or not considering the details for all these cases
- it's not necessarily a bug in the protocol, because the protocol can
be made to work multiple ways. So, some folks might just consider some
of these clarifications.  [/MB]

> >really

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 17 Feb 2009 18:47:55 -0800

On Feb 14, 2009, at 12:10 , Hannes Tschofenig wrote:

> groups.
I regret suggesting clusters would help with scheduling. RAI will have  
to deal with the "more time vs more conflicts" trade off. All the  
comments I have received both off and on list have made the point we  
need to avoid conflicts.

> As mentioned in other mails folks participate in various groups
> them more info on how to schedule the meetings in a proper fashion
>
>
>
> I see

Certainly part of this was to try and reduce bottlenecks at both chair  
and AD level.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 17 Feb 2009 18:51:16 -0800

It would be great if a new WG on topics such as SIP security spun up.  
However, it would be the wrong direction to be delaying things that  
were already WG drafts while we sort out a new WG. It would just add  
delay and unlikely to improve the final RFCs. I also don't want the  
discussion about should we change the way SIP can be modified to get  
derailed on the topic of should we continue work on some particular  
working group draft that is lacking energy.

So my goal is to find a home for everything that is currently a WG  
item. This results in SIP not changing much on day one but a key goal  
of the transition transition is to allow much of the work that would  
have to happen in SIP today to migrate or be done in working groups  
outside SIPCORE in the future.

On Feb 13, 2009, at 15:37 , Hadriel Kaplan wrote:

> I thought in Jon's email he said part of this change would mean on- 
> going security work would find a new home, but you have it all going  
> to SIPCORE.
> Is that an oversight?
>
> -hadriel
>
>
> Of

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 17 Feb 2009 19:01:57 -0800

The black/white had no meaning at all - that was just my typing.

For just about any of the WGs, one could ask why here? I mostly just  
stole this from the previous slides Gonzalo presented in last rai-area  
meeting along with a some comments I got about changing names of  
things. The topics that BLISS is working on largely seemed to be a  
somewhat centralized type of design with large amount of thought  
around interaction with traditional PBXs. It's also worth thinking  
about what people participate in the WG and what skills does it need.  
That might have been some of the factors in thinking about where to  
group it.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 17 Feb 2009 22:32:31 -0500

>>
>
> Certainly part of this was to try and reduce bottlenecks at both  
> chair and AD level.
>>
>>

I think that would be helpful, as the "span-of-control" of the IETF is  
far larger than is generally considered healthy, but it only works if  
decisions at the lower layers are not re-reviewed at the higher  
layers. Otherwise, all we've accomplished is add more stages to the  
pipeline, which surely is long enough as is.

Henning

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 17 Feb 2009 22:06:59 -0600

At 08:47 AM 2/12/2009, Vijay K. Gurbani wrote:
>cluster has only one item -- p2psip.

I'd like to second Vijay here (that P2PSIP go in the User group of WGs)

>If the intent is to reduce

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 18 Feb 2009 09:11:52 +0000

This might not be the right sub-thread, but I feel I need to make an
observation.

A lot of the problems in RAI are to do with energy, and perhaps more so
in some WGs (e.g., SIP/SIPPING) than others (e.g., AVT/MMUSIC). I can't
help drawing some parallel between this lack of energy and the
extraordinary long time it often takes to get anything published in the
IETF. People who are enthusiastic when an activity starts up become
completely bored with it when it is still continuing 4, 5 or more years
later. Examples are the config framework (SIPPING) and outbound (SIP).
Although WG charters have target dates, these are regularly slipped. And
then, when a document leaves the WG, there is often much delay in
getting the document approved. Hence I certainly agree with Henning's
concern below.

If we contrast the IETF with many other SDOs, other SDOs very often pay
greater attention to meeting the timescales, and while there are
slippages, these tend to be in months rather than years. It is often a
case of making a decision and sticking to it, whereas in the IETF/RAI we
so often see old decisions re-opened. Whether the IETF method leads to
better quality or not, I don't know. I suspect not, because those with
the initial vision are not the ones doing the final review, and
inconsistencies creep in.

So one of the benefits I hope will arise from the proposed restructuring
in RAI will be smaller WGs that can focus on a limited number of work
items and hopefully get them done quicker. But we must ensure that any
increased speed in the WGs is not negated by delays in the subsequent
approval process.

John

> Sent: 18 February 2009 03:33
> To: Cullen Jennings
> Cc: [email-masked]
> Subject: Re: [RAI] The Cluster Idea ... was RAI 
> reorganization - Clusters
> 
> >>
> >

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 18 Feb 2009 11:28:45 +0200

I agree with Henning and I would like to add that instead of "instantly"
liking the cluster idea I would like challenge folks to think about the
tradeoffs and other alternatives. 

If we believe that there are issues with bottlenecks at the WG chair and AD
level then we should analyse those a bit more. I haven't seen any detailed
discussion on this side but I am happy to change my work style as a WG chair
if there are some good ideas. 

Ciao
Hannes

>Sent: 18 February, 2009 05:33
>To: Cullen Jennings
>Cc: Hannes Tschofenig; [email-masked]
>Subject: Re: [RAI] The Cluster Idea ... was RAI reorganization 
>- Clusters
>
>>>
>>
>I think that would be helpful, as the "span-of-control" of the 
>IETF is far larger than is generally considered healthy, but 
>it only works if decisions at the lower layers are not 
>re-reviewed at the higher layers. Otherwise, all we've 
>accomplished is add more stages to the pipeline, which surely 
>is long enough as is.
>
>Henning
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 18 Feb 2009 10:43:57 +0100

> Behalf Of Elwell, John
> Sent: Wednesday, February 18, 2009 11:12 AM
> To: Henning Schulzrinne; Cullen Jennings
> Cc: [email-masked]
> This might not be the right sub-thread, but I feel I need to 
> make an observation.
> 
> A lot of the problems in RAI are to do with energy, and 
> perhaps more so in some WGs (e.g., SIP/SIPPING) than others 
> (e.g., AVT/MMUSIC). I can't help drawing some parallel 
> between this lack of energy and the extraordinary long time 
> it often takes to get anything published in the IETF. People 
> who are enthusiastic when an activity starts up become 
> completely bored with it when it is still continuing 4, 5 or 
> more years later. Examples are the config framework (SIPPING) 
> and outbound (SIP).
> Although WG charters have target dates, these are regularly 
> slipped. And then, when a document leaves the WG, there is 
> often much delay in getting the document approved. Hence I 
> certainly agree with Henning's concern below.
> 
> If we contrast the IETF with many other SDOs, other SDOs very 
> often pay greater attention to meeting the timescales, and 
> while there are slippages, these tend to be in months rather 
> than years. It is often a case of making a decision and 
> sticking to it, whereas in the IETF/RAI we so often see old 
> decisions re-opened. Whether the IETF method leads to better 
> quality or not, I don't know. I suspect not, because those 
> with the initial vision are not the ones doing the final 
> review, and inconsistencies creep in.
> 

I agree that this is a serious problem for the whole IETF and not only
in RAI. We have discussed it also in the IESG, but here is the big
question - what to do with WGs that are chronically late in delivering
relative to their charters? Should we be more aggressive and shut down
activities that take longer than - say, six months - than chartered,
even if they may be important and the reasons of the delay are not
always depending on the authors or WG chairs? Should we prevent the WG
from chartering new work items before all current ones are executed,
even if these new items may be key for the development of the technology
that the WG is chartered with? Inputs are welcome. 

Dan

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 18 Feb 2009 11:48:34 +0200

Hi John, 

>(e.g., AVT/MMUSIC). I can't help drawing some parallel between 
>this lack of energy and the extraordinary long time it often 
>takes to get anything published in the IETF. People who are 
>enthusiastic when an activity starts up become completely 
>bored with it when it is still continuing 4, 5 or more years 

In general, I don't understand this either but every document has it's own
history. 
I think it is hard to generalize it. 

>slipped.

The problem is the following: 

* the chairs propose new milestones. Nobody cares to give a rough estimate.
The chair picks. 
* the chair has very little tools to "force" the working group to really
make progress on something. There are only volunteers. There are some tools
but many of them are often not very effective or create a different set of
problems (e.g. firing the document editor, for example). 

> And then, when a document leaves the WG, there is 
>often much delay in getting the document approved.

And these delays are often not visible to the working group. I have to note
that the reason for the delay is not necessarily the AD; it could also be
the author not responding to reviews or so. 

> Hence I 
>than years.

The reason for this is that they would even publish something that is
half-finished. In the IETF we wouldn't do that. You would not get through
the IESG with this type of argument. 

In some cases, however, it would be more helpful to publish something early
even though not fully technically worked out and to let of folks play around
with it. Later, when the implementation feedback comes along then the
document could be updated. 

This seems to be the workstyle the XMPP guys have. 

. It is often a case of making a decision and 
>decisions re-opened.

If there are years between the decisions it isn't super surprising that
these issues get reopen as the world is somewhat different. 

 Whether the IETF method leads to better 
>So one of the benefits I hope will arise from the proposed 
>restructuring in RAI will be smaller WGs that can focus on a 
>limited number of work items and hopefully get them done 
>quicker. But we must ensure that any increased speed in the 
>WGs is not negated by delays in the subsequent approval process.

I don't think that this will help. 

I believe it would be more useful to publish documents, for example, as
Experimental RFCs faster. Then, to get these document moved to Standards
Track later on when there is implementation/deployment feedback. 

The problem with this approach is that the current review teams, the Ads,
Working Group Chairs and also the community are somewhat unfamiliar with a
faster workstyle and hence it still wouldn't work. 

For example, when we tried the RFC 5111 (Exploratory Group) experiment with
RUCUS the promise of the entire stuff was to copy the concept of IEEE study
groups; groups that get setup quickly and then prepare the groundwork for a
subsequent BOF. 

What did happen? Nobody understood it and did not react in a way that would
have been appropriately for a Exploratory Group.

By now, I would say that the RFC 5111 experiment totally failed. 

Hence, I believe that just creating more and smaller groups will not help.
In fact they could even make the situation worse if you suddenly have to
create a new working group for every tiny piece. 

This, btw, turned out to be one of the problems with the Early Warning BOF
that is scheduled for the next IETF meeting. We don't have too many
documents that we would be working on, the community is the same as in ECRIT
and we intially planned todo the work in ECRIT. Now, we have a BOF. It got
delayed once. It took some time to setup. Let's see how long it will take to
even create a group. I would say we managed to work well on a 1 year delay
-- if not more.  

Ciao
Hannes

>> Henning Schulzrinne
>> Subject: Re: [RAI] The Cluster Idea ... was RAI reorganization - 
>> Clusters
>> 
>> >>
>> >

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 18 Feb 2009 11:59:50 +0200

Hi Dan, 

>> A lot of the problems in RAI are to do with energy, and perhaps more 
>> so in some WGs (e.g., SIP/SIPPING) than others (e.g., AVT/MMUSIC). I 
>> can't help drawing some parallel between this lack of energy and the 
>> extraordinary long time it often takes to get anything published in 
>> the IETF. People who are enthusiastic when an activity starts up 
>> become completely bored with it when it is still continuing 4, 5 or 
>> more years later. Examples are the config framework (SIPPING) and 
>> outbound (SIP).
>> Although WG charters have target dates, these are regularly slipped. 
>> And then, when a document leaves the WG, there is often much 
>delay in 
>> If we contrast the IETF with many other SDOs, other SDOs very often 
>> pay greater attention to meeting the timescales, and while there are 
>> case of making a decision and sticking to it, whereas in the 
>IETF/RAI 
>> we so often see old decisions re-opened. Whether the IETF 
>method leads 
>> to better quality or not, I don't know. I suspect not, because those 
>> with the initial vision are not the ones doing the final review, and 
>I agree that this is a serious problem for the whole IETF and 
>not only in RAI. We have discussed it also in the IESG, but 
>here is the big question - what to do with WGs that are 
>chronically late in delivering relative to their charters? 

As a chair I would then always add 1 year to any milestone date. 
Hence, the dates up there also become pretty irrelevant. 

For example, with DIME I tried to submit very aggressive milestones to have
something I can point to when I talk to folks in the group. (Hopefully
nobody on this list is also in DIME since otherwise I have just revealed my
plan.)

>Should we be more aggressive and shut down activities that 
>take longer than - say, six months - than chartered, even if 
>they may be important and the reasons of the delay are not 
>always depending on the authors or WG chairs?

I am not sure that this helps a lot. 

The reason for delay can come in many flavors. For example, in KEYPROV we
had a group of people who were unfamiliar with the IETF progress. Hence,
this took us some time. 
Additionally, we needed feedback from XML experts in the IETF and that did
not came instantly either. 

In DIME we also had many new folks in the group and therefore we had to
build-up experience from scratch. 

WGs in the RAI area have other reasons for delays. Working in GEOPRIV I have
often noticed "disagreements" between the WG members. You bet that this
caused delays -- still is. What can you do as a chair with such a
challenging group? Luckily I am not chairing GEOPRIV. 

> Should we 
>prevent the WG from chartering new work items before all 
>current ones are executed,

In the extreme form, this does not make sense for me either since there is
often very little dependency between the individual items. 

I understand that new work cannot be added when there is no progress or when
the main items are unfinished. 

I believe that this also needs to be dealt with in a case-by-case fashion. 

> even if these new items may be key 
>for the development of the technology that the WG is chartered 
>with? Inputs are welcome. 

Ciao
Hannes

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 18 Feb 2009 12:04:38 +0200

Hi Cullen, 

I agree that we want to avoid conflicts. I guess everyone does. 

BUT: How do clusters help? If a cluster is only a slide that says "These
groups belong together and avoid scheduling these meetings in parallel." and
you send this slide to the secretariat then I agree. Good idea. Should have
been done several years ago already.

But I have seen descriptions of the cluster being more than just that. Could
you describe in more detail what the cluster idea consists of? 

Ciao
Hannes

>From: Cullen Jennings [mailto:[email-masked]] 
>Sent: 18 February, 2009 04:48
>To: Hannes Tschofenig
>Cc: [email-masked]
>Subject: Re: The Cluster Idea ... was [RAI] RAI reorganization 
>- Clusters
>
>
>> First, the concept has never really described in great 
>detail and also 
>> Jon's mail about the RAI organization was silent about this 
>subject. I 
>> believe more context would be useful to make a decision.
>>
>> Second, I am not sure clusters will help with the scheduling of the 
>> working groups.
>>
>I regret suggesting clusters would help with scheduling. RAI 
>will have to deal with the "more time vs more conflicts" trade 
>off. All the comments I have received both off and on list 
>have made the point we need to avoid conflicts.
>
>> spanning multiple clusters. Why not simply talk to the secretary and 
>> give them more info on how to schedule the meetings in a proper 
>> fashion
>>
>>
>>
>> Finally, I wonder if the **main idea** therefore is that there is 
>> another layer of management in order to offload work from 
>the ADs (or 
>> maybe also from existing working group chairs). In 
>Certainly part of this was to try and reduce bottlenecks at 
>both chair and AD level.
>>
>>
>> Ciao
>> Hannes
>>

---

From: <[email-masked]>
Date: Wed, 18 Feb 2009 11:06:09 +0100

Hi,

Hannes wrote:
>>People who are enthusiastic when an activity starts up become
>more years
>In general, I don't understand this either but every document
>has it's own history.

It is indeed hard to generalize but I think there is something in common in the two examples given by John:
* Everyone agrees that they address an extremely critical issue in SIP for which IETF so far has no proper standard (UA auto-configuration, NAT traversal, respectively)
* Rather than solving the most pressing issue at hand, both drafts took a very comprehensive and thus complicated approach to the problem (config framework addresses a lot of different scenarios, outbound mixes NAT traversal with server redundancy)
* Many people got scared that the full solution provided by the drafts is too much and as the IETF work never got finished most implementations solved the key problems on their own ways (there are many autoconfig methods around, similarly NAT keepalives are already well supported)
* Due to this development, it is no longer obvious if anyone would care aout the IETF solutions even when they come out as RFCs. And this explains the lack of enthusiams in the WGs too, I think.

The learning? IMHO: If there is a pressing issue, make a point solution that is good enough rather than *only* work on an all-encompassing framework to solve all related problems. Because, we can never deliver those "full" solutions on time before the market has already gone somewhere else. If the full solution has real merit it will be adopted later on.

Markus

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 18 Feb 2009 11:09:16 +0000

> Sent: 18 February 2009 09:49
> To: Elwell, John; 'Henning Schulzrinne'; 'Cullen Jennings'
> Cc: [email-masked]
> Subject: RE: [RAI] The Cluster Idea ... was RAI 
> has it's own
[JRE] I agree that delays can be attributed to a number of reasons.

> the IESG with this type of argument. 
[JRE] Well, half finished could mean poor quality, but it could instead
mean limited scope. Do a little at a time, and then enhance later.

> Track later on when there is implementation/deployment feedback. 
[JRE] Yes, I agree this sounds promising.

> create a new working group for every tiny piece. 
[JRE] Yes, I understand this concern. I was trying to be positive about
the reorganisation, but I am not sure it gets to the root of the
problem.
The idea of doing requirements and solution in the same group, on the
other hand (e.g., moving location-conveyance into GEOPRIV), does seem to
be beneficial.

John

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 18 Feb 2009 11:11:05 +0000

I agree this seems to be a core part of the problem, and perhaps we have
to limit scope sometimes to get things done in a more timely manner. If
necessary we can use the Experimental category.

John 

> From: [email-masked] [mailto:[email-masked]] 
> Sent: 18 February 2009 10:06
> To: [email-masked]; Elwell, John; 
> [email-masked]; [email-masked]
> Cc: [email-masked]
> It is indeed hard to generalize but I think there is 
> something in common in the two examples given by John:
> * Everyone agrees that they address an extremely critical 
> issue in SIP for which IETF so far has no proper standard (UA 
> auto-configuration, NAT traversal, respectively)
> * Rather than solving the most pressing issue at hand, both 
> drafts took a very comprehensive and thus complicated 
> approach to the problem (config framework addresses a lot of 
> different scenarios, outbound mixes NAT traversal with server 
> redundancy)
> * Many people got scared that the full solution provided by 
> the drafts is too much and as the IETF work never got 
> finished most implementations solved the key problems on 
> their own ways (there are many autoconfig methods around, 
> similarly NAT keepalives are already well supported)
> * Due to this development, it is no longer obvious if anyone 
> would care aout the IETF solutions even when they come out as 
> RFCs. And this explains the lack of enthusiams in the WGs 
> too, I think.
> 
> The learning? IMHO: If there is a pressing issue, make a 
> point solution that is good enough rather than *only* work on 
> an all-encompassing framework to solve all related problems. 
> Because, we can never deliver those "full" solutions on time 
> before the market has already gone somewhere else. If the 
> full solution has real merit it will be adopted later on.
> 
> Markus
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 18 Feb 2009 14:31:13 +0200

Hi,

we already have a three-tier model: proposed, draft, and full standard. 
In reality, though, we do not use this model and most stuff remains as 
PS for ever.

Cheers,

Gonzalo

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 18 Feb 2009 07:12:17 -0600

... and just to emphasize what Gonzalo said, RFC 2026 is pretty clear that 
Proposed Standard was NOT supposed to be the end of the line - we just 
haven't used the three-tier model the way it was designed.

>From 2026:

4.1.1  Proposed Standard

   The entry-level maturity for the standards track is "Proposed
   Standard".  A specific action by the IESG is required to move a
   specification onto the standards track at the "Proposed Standard"
   level.

   A Proposed Standard specification is generally stable, has resolved
   known design choices, is believed to be well-understood, has received
   significant community review, and appears to enjoy enough community
   interest to be considered valuable.  However, further experience
   might result in a change or even retraction of the specification
   before it advances.

   Usually, neither implementation nor operational experience is
   required for the designation of a specification as a Proposed
   Standard.  However, such experience is highly desirable, and will
   usually represent a strong argument in favor of a Proposed Standard
   designation.

   The IESG may require implementation and/or operational experience
   prior to granting Proposed Standard status to a specification that
   materially affects the core Internet protocols or that specifies
   behavior that may have significant operational impact on the
   Internet.

   A Proposed Standard should have no known technical omissions with
   respect to the requirements placed upon it.  However, the IESG may
   waive this requirement in order to allow a specification to advance
   to the Proposed Standard state when it is considered to be useful and
   necessary (and timely) even with known technical omissions.

   Implementors should treat Proposed Standards as immature
   specifications.  It is desirable to implement them in order to gain
   experience and to validate, test, and clarify the specification.
   However, since the content of Proposed Standards may be changed if
   problems are found or better solutions are identified, deploying
   implementations of such standards into a disruption-sensitive
   environment is not recommended.

So, publishing a half-finished Proposed Standard would be the exception, 
althought the IESG is explicitly allowed to approve a specification with 
known technical omissions if it's the right thing to do, but publishing a 
limited Proposed Standard seems very much in line with our stated (but 
unobserved) process.

Thanks,

Spencer

> Hi,
>
> we already have a three-tier model: proposed, draft, and full standard. In 
> reality, though, we do not use this model and most stuff remains as PS for 
> ever.
>
> Cheers,
>
> Gonzalo
>
>
> Elwell, John wrote:
>>> From: [email-masked] [mailto:[email-masked]] Sent: 
>>> 18 February 2009 10:06
>>> To: [email-masked]; Elwell, John; [email-masked]; 
>>> [email-masked]
>>> Cc: [email-masked]
>>> Subject: RE: [RAI] The Cluster Idea ... was RAI reorganization - 
>>> Clusters
>>>
>>> Hi,
>>>
>>> Hannes wrote:
>>> * Everyone agrees that they address an extremely critical issue in SIP 
>>> for which IETF so far has no proper standard (UA auto-configuration, NAT 
>>> traversal, respectively)
>>> * Rather than solving the most pressing issue at hand, both drafts took 
>>> a very comprehensive and thus complicated approach to the problem 
>>> (config framework addresses a lot of different scenarios, outbound mixes 
>>> NAT traversal with server redundancy)
>>> * Many people got scared that the full solution provided by the drafts 
>>> is too much and as the IETF work never got finished most implementations 
>>> solved the key problems on their own ways (there are many autoconfig 
>>> methods around, similarly NAT keepalives are already well supported)
>>> * Due to this development, it is no longer obvious if anyone would care 
>>> aout the IETF solutions even when they come out as RFCs. And this 
>>> explains the lack of enthusiams in the WGs too, I think.
>>>
>>> The learning? IMHO: If there is a pressing issue, make a point solution 
>>> that is good enough rather than *only* work on an all-encompassing 
>>> framework to solve all related problems. Because, we can never deliver 
>>> those "full" solutions on time before the market has already gone 
>>> somewhere else. If the full solution has real merit it will be adopted 
>>> later on.
>>>
>>> Markus
>>>

---

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 18 Feb 2009 14:23:40 +0100

Perhaps for certain cases, we need a four-tier model and a new
expression for the
"half-finished Proposed Standard"?

What about Beta-Proposed Standard (BPS) or Preliminary Standard (PrS)?

Christian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Spencer Dawkins
Sent: Wednesday, February 18, 2009 2:12 PM
To: Gonzalo Camarillo; Elwell, John
Cc: [email-masked]; [email-masked]
Subject: Re: [RAI] The Cluster Idea ... was RAI reorganization -
Clusters

... and just to emphasize what Gonzalo said, RFC 2026 is pretty clear
that 
Proposed Standard was NOT supposed to be the end of the line - we just 
haven't used the three-tier model the way it was designed.

4.1.1  Proposed Standard

known technical omissions if it's the right thing to do, but publishing
a 
limited Proposed Standard seems very much in line with our stated (but 
unobserved) process.

Thanks,

Spencer

Sent: 
>>> It is indeed hard to generalize but I think there is something in
common 
>>> in the two examples given by John:

---

From: Michael Procter <[email-masked]>
Date: Wed, 18 Feb 2009 13:37:11 +0000

To expand on an earlier suggestion, why not use 'Experimental' and
provide a route from there to the Standards Track?  It could be a
convenient half-way house, and we could choose to promote the ones that
seem to gain widespread approval to Proposed Standard.

Michael

Schmidt, Christian 1. (NSN - DE/Munich) wrote:
>> we already have a three-tier model: proposed, draft, and full
>>     
> standard. In 
>   
>> reality, though, we do not use this model and most stuff remains as PS
>>     
> for 
>   
>> ever.
>>
>> Cheers,
>>
>> Gonzalo
>>
>>
>> Elwell, John wrote:
>>     
>>> I agree this seems to be a core part of the problem, and perhaps we
>>>       
> have
>   
>>> to limit scope sometimes to get things done in a more timely manner.
>>>       
> If
>   
>>>>>> later. Examples are the config framework (SIPPING) and
>>>>>>             
>>>> outbound (SIP).
>>>>         
>>>> * Everyone agrees that they address an extremely critical issue in
>>>>         
> SIP 
>   
>>>> for which IETF so far has no proper standard (UA auto-configuration,
>>>>         
> NAT 
>   
>>>> traversal, respectively)
>>>> * Rather than solving the most pressing issue at hand, both drafts
>>>>         
> took 
>   
>>>> (config framework addresses a lot of different scenarios, outbound
>>>>         
> mixes 
>   
>>>> * Many people got scared that the full solution provided by the
>>>>         
> drafts 
>   
>>>> is too much and as the IETF work never got finished most
>>>>         
> implementations 
>   
>>>> * Due to this development, it is no longer obvious if anyone would
>>>>         
> care 
>   
>>>> The learning? IMHO: If there is a pressing issue, make a point
>>>>         
> solution 
>   
>>>> framework to solve all related problems. Because, we can never
>>>>         
> deliver 
>   
>>>> somewhere else. If the full solution has real merit it will be
>>>>         
> adopted 
>   
>>>> later on.
>>>>
>>>> Markus
>>>>
>>>>

---

From: Dan York <[email-masked]>
Date: Wed, 18 Feb 2009 08:49:02 -0500

A big +1 to Markus' point here:

> solution that is good enough rather than *only* work on an all- 
> encompassing framework to solve all related problems. Because, we  
> can never deliver those "full" solutions on time before the market  
> has already gone somewhere else. If the full solution has real merit  
> it will be adopted later on.

The mantra of is it "good enough" needs to be adopted.  In far too  
many cases than I can name within RAI groups, I've watched discussions  
on various lists morph into giant discussions that wind up  
incorporating edge cases and then getting solutions more complex to  
meet all the various requirements and concerns out there.  Too much  
scope creep.  Let's standardize the "good enough" solutions even when  
they may only hit 80% of the applicable situations... but at least get  
that out there and then iterate through how to solve the remaining  
20%.  Otherwise, as Markus points out, while we are working on the  
100% coverage solution (or 90 or 95%), players in the market come up  
with multiple different solutions to address that 80% need and there  
is no standardization.

My 2 cents,
Dan

On Feb 18, 2009, at 5:06 AM, <[email-masked]> wrote:

> common in the two examples given by John:
> SIP for which IETF so far has no proper standard (UA auto- 
> configuration, NAT traversal, respectively)
> took a very comprehensive and thus complicated approach to the  
> problem (config framework addresses a lot of different scenarios,  
> outbound mixes NAT traversal with server redundancy)
> drafts is too much and as the IETF work never got finished most  
> implementations solved the key problems on their own ways (there are  
> many autoconfig methods around, similarly NAT keepalives are already  
> well supported)
> care aout the IETF solutions even when they come out as RFCs. And  
> this explains the lack of enthusiams in the WGs too, I think.
>
> solution that is good enough rather than *only* work on an all- 
> encompassing framework to solve all related problems. Because, we  
> can never deliver those "full" solutions on time before the market  
> has already gone somewhere else. If the full solution has real merit  
> it will be adopted later on.
>
> Markus

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 18 Feb 2009 08:56:44 -0500

We probably also get into a spiral: since documents take 4-5 years,  
might as well pack everything in, since there won't be another chance,  
thus further delaying the process. Also, it seems almost impossible to  
get editors/authors to drop controversial or complicated items from a  
document. (I've made these arguments for config for years, for  
example. See recent arguments about RPH in ECRIT.)

In the IEEE, there's a strong voting system that requires strong  
consensus for adding features, I believe. We used to have the informal  
rule that a document isn't done until there's nothing left to *take  
out*, but now it's more like "somebody wants it, so it goes in".

Having a model where we publish a short early version, while working  
on the full-blown version, might be better. This is also similar to  
the newer software development models of "ship early, ship often",  
rather than the extreme waterfall model we're practicing, with all the  
"frameworks" and "requirements" documents along the way.

For config, this probably would have gotten us a standardized non- 
event model a few years ago, rather than the proliferation of vendor- 
specific stuff we have now.

The full version may never happen, but at least we get something.

Maybe we could have the equivalent of "short papers" at conferences -  
10 pages, say, of spec length and needs to be finished within one  
year. In general, we might be able to learn from the conference model:  
set up a review team ahead of time, submission deadline, and revision  
deadline.

Henning

On Feb 18, 2009, at 7:31 AM, Gonzalo Camarillo wrote:

> standard. In reality, though, we do not use this model and most  
> stuff remains as PS for ever.

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 18 Feb 2009 16:09:39 +0200

Hi Markus, 

Got your point. 

There are certainly some high priority items that require immediate
attention. For some reason, there seems to be the desire among people to
solve the most generic approach and that takes forever. This is a generic
IETF problem. 

For most documents in the RAI area I do, however, get the impression that
there is no real urgency to get them finished quickly. It is nice but nobody
would get hurt if it does not happen. 

The problem is with identifying the important items, as Jonathan has been
mentioning in his presentation at the last IETF meeting. Everyone has
different priorities, obviously. 

There might also be a management problem: If the community recognizes that
something is really important (and they actually say it) then the chairs
need to push the authors to finish the stuff asap. Why did this happen?
(Some of the stuff is still not finished, btw.) 

You and John mentioned 
* SIP Outbound 
* NAT traversal
* Auto-configuration

What else is urgent?

Ciao
Hannes

>Sent: 18 February, 2009 12:06
>To: [email-masked]; [email-masked]; 
>Subject: RE: [RAI] The Cluster Idea ... was RAI reorganization 
>- Clusters
>
>Hi,
>
>Hannes wrote:
>has it's 
>>own history.
>It is indeed hard to generalize but I think there is something 
>in common in the two examples given by John:
>drafts took a very comprehensive and thus complicated approach 
>to the problem (config framework addresses a lot of different 
>scenarios, outbound mixes NAT traversal with server redundancy)
>the drafts is too much and as the IETF work never got finished 
>most implementations solved the key problems on their own ways 
>(there are many autoconfig methods around, similarly NAT 
>keepalives are already well supported)
>RFCs. And this explains the lack of enthusiams in the WGs too, I think.
>
>solution that is good enough rather than *only* work on an 
>all-encompassing framework to solve all related problems. 
>before the market has already gone somewhere else. If the full 
>solution has real merit it will be adopted later on.
>
>Markus
>

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 18 Feb 2009 16:33:12 +0200

>mean limited scope. Do a little at a time, and then enhance later.

Maybe. On the other hand it does not help if a document is 100% great
according to all IETF directorates when it does not get deployed. When a
document is hanging around too long then you will notice that the wisdom in
protocol design changes and you suddently find yourself always trying to fix
the specification according to the latest trend. 

>other hand (e.g., moving location-conveyance into GEOPRIV), 

It is certainly a good idea to have the requirements and the solution in the
same group. 

In fact, I largely doubt that the splitting things up into requirements,
problem statement, terminology, solution, framework, etc. is part of the
problem. Most of the stuff is quite simple that you don't need to write 5
documents. If the work needs 5 documents to get explained then maybe it is
too complex already. 

Another effect typically happens: if you pipeline requirements, framework
and solution then things take ages. If you don't then you find yourself
back-patching the requirements document as you work on the solution. In most
cases nobody cares about the requirements anymore after the work is
finished. I rarely ever observed that the solution design exactly tried todo
what was written in the requirements. Requirements documents are often a
place-holder for solution discussions. 

Ciao
Hannes

---

From: "Roni Even" <[email-masked]>
Date: Wed, 18 Feb 2009 16:48:47 +0200

I think that versions may be one way to address the delivery time issue. 
This may mean that there will be a strict time schedule and contents for
versions but there will also be a need for a version number for a protocol
that will enable the parties to know which version is supported by the other
side and the solution may need to verify backward interoperability.
One negative aspect we had in H.323 is that intermediaries may run older
version then the parties reducing the common functionality. 

Roni Even

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Henning Schulzrinne
Sent: Wednesday, February 18, 2009 3:57 PM
To: Gonzalo Camarillo
Cc: [email-masked]
Subject: Re: [RAI] The Cluster Idea ... was RAI reorganization - Clusters

Henning

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 18 Feb 2009 09:25:55 -0800

> We used to have the informal  

> This is also similar to  

Very true. These are key insights. 
Now how can we update the process accordingly?

Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henning Schulzrinne
Sent: Wednesday, February 18, 2009 7:57 AM
To: Gonzalo Camarillo
Cc: [email-masked]
Subject: Re: [RAI] The Cluster Idea ... was RAI reorganization - Clusters

Henning

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 18 Feb 2009 09:44:05 -0600

> On the other hand it does not help if a document is 100% great
> according to all IETF directorates 

My comment here does not target anyone in particular:

Documents not backed up by code, measurements and personal skin in the
project are IMO worse than spam. The better such documents are written, the
more dangerous they are as well. 

The worst case scenario is when such a well written document gets consensus
from a like minded attendance (travel paid) suffering of Groupthink.

Updating the RAI process should target these flaws first and foremost and be
as simple as possible. Maybe keep the original IETF processes that
originated the Internet. It's actual the Internet e2e architecture and
technology that matters.

Broken architecture and technology (contradicting the Internet principles)
cannot be fixed by any process. If in doubt read the IAB documents.

My two cents (outside the Groupthink),

Henry

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 18 Feb 2009 12:29:59 -0500

I agree wholeheartedly.  Except for trying things as Experimental.  That would be the kiss of death.  Customers don't deploy Experimental.  (and I'm not convinced any word-smithing of the name will help, either; it's RFC or bust)

-hadriel

> Elwell, John
> Sent: Wednesday, February 18, 2009 6:11 AM
> To: [email-masked]; [email-masked];

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 18 Feb 2009 12:00:40 -0600

Hi, Hadriel,

I agree with your "RFC or bust" thought, but note that Experimental 
specifications are published as RFCs... and it's not clear to me that some 
customers pay much attention to various types of RFCs.

Thanks,

Spencer

>I agree wholeheartedly.  Except for trying things as Experimental.  That 
>would be the kiss of death.  Customers don't deploy Experimental.  (and I'm 
>not convinced any word-smithing of the name will help, either; it's RFC or 
>bust)
>
> -hadriel

---

From: Michael Procter <[email-masked]>
Date: Wed, 18 Feb 2009 18:06:34 +0000

Some customers deploy draft-ietf-whatever.  At least with an
Experimental RFC, you get an RFC number to quote, rather than a draft
revision number.

Michael

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 18 Feb 2009 20:55:02 +0200

Hi,

folks were so confused with all the RFC types out there that the whole 
RFC series is being revised so that it will now include the concept of 
different streams. I agree with Spencer that many customers have no idea 
what types and classes or RFCs there are.

Cheers,

Gonzalo

Spencer Dawkins wrote:
> specifications are published as RFCs... and it's not clear to me that 
> some customers pay much attention to various types of RFCs.
> 
> Thanks,
> 
> Spencer
> 
> 
>> I agree wholeheartedly.  Except for trying things as Experimental.  
>> That would be the kiss of death.  Customers don't deploy 
>> Experimental.  (and I'm not convinced any word-smithing of the name 
>> will help, either; it's RFC or bust)
>>
>> -hadriel 
> 
>

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 18 Feb 2009 19:48:34 +0000

And certainly better than an expired draft, such as the Diversion draft.

John 

> From: Michael Procter [mailto:[email-masked]] 
> Sent: 18 February 2009 18:07
> To: Hadriel Kaplan
> Cc: Elwell, John; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> > I agree wholeheartedly.  Except for trying things as 
> Experimental.  That would be the kiss of death.  Customers 
> don't deploy Experimental.  (and I'm not convinced any 
> word-smithing of the name will help, either; it's RFC or bust)
> >
> > -hadriel
> >
> >

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 18 Feb 2009 19:49:53 +0000

Henry,

By keeping something simple and limiting its scope, there is greater
chance of code and interoperability.

John 

> From: Henry Sinnreich [mailto:[email-masked]] 
> Sent: 18 February 2009 15:44
> To: 'Hannes Tschofenig'; Elwell, John; 'Henning Schulzrinne'; 
> 'Cullen Jennings'
> Cc: [email-masked]

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 18 Feb 2009 12:57:59 -0800

Thanks John and agreed.
Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Elwell, John
Sent: Wednesday, February 18, 2009 1:50 PM
To: [email-masked]; Hannes Tschofenig; Henning Schulzrinne; Cullen Jennings
Cc: [email-masked]
Subject: Re: [RAI] The Cluster Idea ... was RAI reorganization - Clusters

Henry,

John

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 18 Feb 2009 22:05:17 -0500

Right, sorry forgot it even got an RFC number.  But they do care.  They don't seem to care that much about standards-track vs. informational, bizarrely, but experimental is like a scarlet letter A (or a scarlet E as it were).  I don't think this is unique in RAI either - when I was in routing the same behavior applied.  Don't take my word for it, ask a product manager or sales engineer at your company.

-hadriel

> From: Spencer Dawkins [mailto:[email-masked]]
> Sent: Wednesday, February 18, 2009 1:01 PM
> To: Hadriel Kaplan; Elwell, John; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 19 Feb 2009 11:37:09 -0800

One of the problems at IETF comes from the need for rough consensus -  
often we can not get enough people to agree to the reduced scope -  
MSRP and XCAP might be an examples of that.  I do like to break things  
into as small as independent chunks as possible - I think that gets  
them finished sooner and it allows topics where one can't get  
consensus to get dropped. I realize it is apple pie, but one thing  
that could a help in RAI is people trying to make ideas smaller.

If draft-x gets published at RFC 1234, we can start on 1234bis the day  
1234 is published to add more to it. To make this successful we need  
the people sitting in the WG *not* to hum yes when asked if they would  
like to include the kitchen-sink option in draft-sip-super-simple. I  
note the RAI WGs almost always hum yes to taking on more work. We have  
the  combination of people who aren't going to do the work getting to  
hum yes that someone else should do the work combined with only  
volunteers with fairly erratic time commitments do the work. This  
combination is not an ideal combination for speedy work but it is what  
we have so we need to figure out how to make the best of it.

One of the hopes of Dispatch is that it could quickly spin up a way to  
get a small focused set of work done, such as config.

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 19 Feb 2009 11:43:38 -0800

You may be right about experimental but some times, I don't even think  
anyone even cares about that. For example, Lars points out that,  
RFC3708 (DSACK) is implemented in Vista and on by default. I believe  
it's implemented in several other major TCP stacks as well. RFC4138 (F- 
RTO) is implemented in Vista and on by default, too

On Feb 18, 2009, at 19:05 , Hadriel Kaplan wrote:

> Right, sorry forgot it even got an RFC number.  But they do care.   
> They don't seem to care that much about standards-track vs.  
> informational, bizarrely, but experimental is like a scarlet letter  
> A (or a scarlet E as it were).  I don't think this is unique in RAI  
> either - when I was in routing the same behavior applied.  Don't  
> take my word for it, ask a product manager or sales engineer at your  
> company.
>
> -hadriel
>
> Experimental.  That
> > >would be the kiss of death.  Customers don't deploy  
> Experimental.  (and
> > I'm
> > >not convinced any word-smithing of the name will help, either;  
> it's RFC
> > or
> > >bust)
> > >
> > > -hadriel
> >
>

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 19 Feb 2009 12:11:15 -0800

>often we can not get enough people to agree to the reduced scope

Very true.

At this point in time it is productive to look at what Henning has proposed:

==============================================

"informal rule that a document isn't done until there's nothing left to *take
out*, but now it's more like "somebody wants it, so it goes in".

==============================================

I will add my two cents that majority from a "Groupthink" minded attendance has little to do with technical merits. The technical proposals can be only validated by testing.

Reduced scope, "ready when nothing can be taken out" and testing must be mandated by the RAI A-D in the reorganization to make it successful. If need be, get approval from the IESG for this mandate.

Henry

On 2/19/09 1:37 PM, "Cullen Jennings" <[email-masked]> wrote:

---

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 20 Feb 2009 08:59:16 +0100

Hi Henry,
 
so what about the following four-tier model:
- Test Standard
- Proposed Standard
- Draft Standard
- Standard
 
To change status from Test Standard to Proposed Standard,  at least 2
independent implemenations are requested.
 
This could achieve the following:
- Keep Test Standard simple, to motivate implemenation (as precondition
for proceeding to proposed standard).
- Force a proof of concept before further progress
- Reduce the number of proposed standards, which are never deployed.
- Could in total reduce work load in RAI.
 
What do you think about?
 
Christian

expression for the

Christian

From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Henry Sinnreich
Sent: Thursday, February 19, 2009 9:11 PM
To: Cullen Jennings; [email-masked]; HenningSchulzrinne
Cc: Markus Isomaki
Subject: Re: [RAI] The Cluster Idea ... was RAI reorganization -
Clusters

Very true.

At this point in time it is productive to look at what Henning has
proposed:

"informal rule that a document isn't done until there's nothing left to
*take 
out*, but now it's more like "somebody wants it, so it goes in".

I will add my two cents that majority from a "Groupthink" minded
attendance has little to do with technical merits. The technical
proposals can be only validated by testing.

Reduced scope, "ready when nothing can be taken out" and testing must be
mandated by the RAI A-D in the reorganization to make it successful. If
need be, get approval from the IESG for this mandate.

Henry

	
	
	One of the problems at IETF comes from the need for rough
consensus - 
	often we can not get enough people to agree to the reduced scope
- 
	MSRP and XCAP might be an examples of that.  I do like to break
things 
	into as small as independent chunks as possible - I think that
gets 
	them finished sooner and it allows topics where one can't get 
	consensus to get dropped. I realize it is apple pie, but one
thing 
	that could a help in RAI is people trying to make ideas smaller.
	
	If draft-x gets published at RFC 1234, we can start on 1234bis
the day 
	1234 is published to add more to it. To make this successful we
need 
	the people sitting in the WG *not* to hum yes when asked if they
would 
	like to include the kitchen-sink option in
draft-sip-super-simple. I 
	note the RAI WGs almost always hum yes to taking on more work.
We have 
	the  combination of people who aren't going to do the work
getting to 
	hum yes that someone else should do the work combined with only 
	volunteers with fairly erratic time commitments do the work.
This 
	combination is not an ideal combination for speedy work but it
is what 
	we have so we need to figure out how to make the best of it.
	
	One of the hopes of Dispatch is that it could quickly spin up a
way to 
	get a small focused set of work done, such as config.

---

From: <[email-masked]>
Date: Fri, 20 Feb 2009 10:42:56 +0100

Hi Cullen,

Cullen Jennings wrote:
>1234 is published to add more to it. To make this successful
>we need the people sitting in the WG *not* to hum yes when
>asked if they would like to include the kitchen-sink option in
>draft-sip-super-simple.

There is one good reason why people want their favorite kitchen-sink options to be included in the base spec. That's because they are worried that if the feature does not get in and a new draft needs to be started, it means at least 3 years more waiting, however trivial the extension might be. So to be succesful with your model we would need two things:
a) be very critical of adding new features (that are such that they *can* be added later on) to our core specs.
b) make it easy to add such niche features later on without having to convince two WGs and five review teams that the feature is really needed. (Often we end up in debates where there is essentially nothing wrong with the original proposal but other people are able to point out that there are two other ways of doing the same.) --> in this sense the RAI reorg proposal is heading to the absolutely right direction!

The downside of this minimum baseline + "unleashed" extensions approach is that we get even more RFCs than before, something that people already complain about. But maybe it's still better than the current situation where people often still implement some subset of an RFC that has too much in it.

For instance wrt. XCAP it seems that most people would be fine to implement PUT/GET/DELETE for the "full documents" while they see the subdocument operations complicated with limited value (which is kind of true -- as long as the document sizes are small it does not matter that much. And if you omit the subdocument stuff no-one can claim XCAP complicated -- it's plain HTTP with some resouce naming rules). That approach is kind of possible with the XCAP RFC too, but there seems to be confusion around for instance how the client would know if the server only does full documents. Well, it's easy to be wise now...

Markus

>Behalf Of ext Cullen Jennings
>Sent: 19 February, 2009 21:37
>To: [email-masked]
>Cc: Isomaki Markus (Nokia-CIC/Espoo)
>consensus - often we can not get enough people to agree to the
>reduced scope - MSRP and XCAP might be an examples of that.  I
>do like to break things into as small as independent chunks as
>possible - I think that gets them finished sooner and it
>allows topics where one can't get consensus to get dropped. I
>realize it is apple pie, but one thing that could a help in
>RAI is people trying to make ideas smaller.
>
>1234 is published to add more to it. To make this successful
>we need the people sitting in the WG *not* to hum yes when
>asked if they would like to include the kitchen-sink option in
>draft-sip-super-simple. I note the RAI WGs almost always hum
>yes to taking on more work. We have the  combination of people
>who aren't going to do the work getting to hum yes that
>someone else should do the work combined with only volunteers
>with fairly erratic time commitments do the work. This
>is what we have so we need to figure out how to make the best of it.
>
>One of the hopes of Dispatch is that it could quickly spin up
>a way to get a small focused set of work done, such as config.
>
>> have to limit scope sometimes to get things done in a more timely
>> manner.
>> If
>>>> In general, I don't understand this either but every document has
>>>> it's own history.
>>> SIP for which IETF so far has no proper standard (UA
>>> Because, we can never deliver those "full" solutions on time before
>>> the market has already gone somewhere else. If the full
>solution has

---

From: Dan York <[email-masked]>
Date: Fri, 20 Feb 2009 04:55:41 -0500

On Feb 20, 2009, at 4:42 AM, <[email-masked]> wrote:

> The downside of this minimum baseline + "unleashed" extensions  
> approach is that we get even more RFCs than before, something that  
> people already complain about. But maybe it's still better than the  
> current situation where people often still implement some subset of  
> an RFC that has too much in it.

I agree that having a zillion RFCs isn't really helpful to  
implementors (and winds up requiring something like the Hitchhiker's  
Guide in order for them to actually sort through those zillion RFCs),  
but I'd mention:

1. (Agreeing with Markus) Having smaller, more focused RFCs will  
increase interoperability in that it will avoid the implementing  
subsets of RFCs that Markus mentions.

2. At least with RFCs, vendors can assemble a checklist for testing of  
which RFCs they need to comply with.

3. In the absence of actual RFCs, many vendors implement various  
Internet-Drafts, winding up with incompatibilities because various  
vendors implement I-Ds at different times in the I-D lifecycle.  If  
the process of getting to RFC were known to be quicker, perhaps  
vendors would be less inclined to implement I-Ds.

Dan

---

From: Henry Sinnreich <[email-masked]>
Date: Fri, 20 Feb 2009 07:03:49 -0800

Christian,

>- Keep Test Standard simple, to motivate implementation (as precondition for proceeding to proposed standard).

I totally agree, just not only for "Test Standards" but for all standards. Incidentally, one measure of good laws in society is they should be simple enough to be understood by everybody. Good governance - IETF RAI in case - also requires the number of laws to be as limited as possible :-)

>- Reduce the number of proposed standards, which are never deployed.

The above will contribute to this anyway, though deprecating older SIP standards, including those developed for closed networks that contradict e2e, transparency and threaten privacy must be deprecated IMO to keep SIP viable on the Internet.
Every SIP standard or informational RFC that includes intermediaries beyond the trapezoid model fall in this category.
Why "SIP server clouds" are computationally questionable is another topic we must give serious consideration - not to be confused with using cloud computing for SIP that seems to have been totally overlooked in SIP/RAI work.

Thanks for your good points,
Henry

On 2/20/09 1:59 AM, "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]> wrote:

Hi Henry,

To change status from Test Standard to Proposed Standard,  at least 2 independent implemenations are requested.

- Keep Test Standard simple, to motivate implemenation (as precondition for proceeding to proposed standard).

What do you think about?

Christian

expression for the

Christian

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Henry Sinnreich

Very true.

Henry

---

From: Lars Eggert <[email-masked]>
Date: Fri, 20 Feb 2009 17:41:46 +0200

> so what about the following four-tier model:

The last thing we need is more standards levels.

> To change status from Test Standard to Proposed Standard,  at least  
> 2 independent implemenations are requested.

This is our *current* requirement to go from PS to DS!

Lars

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 20 Feb 2009 22:43:58 +0200

Hi,

I am with Lars here. We have a three-tier model but we only use one 
level... and to resolve the situation, we want to create even more 
levels :o)

Cheers,

Gonzalo

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Fri, 20 Feb 2009 16:00:22 -0500

The way it works in some groups is to take a stand:  We will put the
document out by this deadline!

Then ask:  How many kitchen sinks can get fit into that deadline?

Mike

> [email-masked]
> Sent: Friday, February 20, 2009 4:43 AM
> To: Cullen Jennings (fluffy); [email-masked]
Clusters
> There is one good reason why people want their favorite kitchen-sink
> options to be included in the base spec. That's because they are
worried
> that if the feature does not get in and a new draft needs to be
started,
> it means at least 3 years more waiting, however trivial the extension
> might be. So to be succesful with your model we would need two things:
> a) be very critical of adding new features (that are such that they
*can*
> be added later on) to our core specs.
> b) make it easy to add such niche features later on without having to
> convince two WGs and five review teams that the feature is really
needed.
> (Often we end up in debates where there is essentially nothing wrong
with
> the original proposal but other people are able to point out that
there
> are two other ways of doing the same.) --> in this sense the RAI reorg
> proposal is heading to the absolutely right direction!
> 
approach is
> that we get even more RFCs than before, something that people already
> complain about. But maybe it's still better than the current situation
> where people often still implement some subset of an RFC that has too
much
> in it.
> 
> For instance wrt. XCAP it seems that most people would be fine to
> implement PUT/GET/DELETE for the "full documents" while they see the
> subdocument operations complicated with limited value (which is kind
of
> true -- as long as the document sizes are small it does not matter
that
> much. And if you omit the subdocument stuff no-one can claim XCAP
> complicated -- it's plain HTTP with some resouce naming rules). That
> approach is kind of possible with the XCAP RFC too, but there seems to
be
> confusion around for instance how the client would know if the server
only
> does full documents. Well, it's easy to be wise now...
> 
> Markus
> 
> 
before