Subject: Re: [RAI] Making RAI work better

From: <[email-masked]>
Date: Wed, 1 Oct 2008 12:34:53 +0300

Hi,

Wrt. RAI originated technologies, standardization is an issue, but I'm
actually much more worried on how long it takes for many important
features/mechanisms to really hit the market, i.e. deployments or even
just implementations. As we have seen in various interoperability
discussions, the world is still full of problems that we have already
kind of solved in standards, but unfortunately people are not using
correctly. On the other hand, sometimes the market confusion clearly
seems to stem from slowness in standardization. For instance ICE and
SIP-outbound are things that we would have really needed a few years ago
already. But now, most networks have taken different approaches (mostly
SBC based hacks) and personally I can't anymore determine if ICE and
SIP-outbound will make any difference or not (I hope they will). I mean,
if running (== in use in real deployments) code was our guiding light
for RAI, we might need to do a few things differently from how we are
doing them currently. Just as an anecdote I could mention the MSRP NAT
traversal discussion in SIMPLE, where I have been involved. MSRP relays
are a nice thing, but if most of running code (deployments) are
something else, it won't make sense to base our future work on them, but
some other type of middlebox-traversal design.  

This concern is a bit off-the-topic here, but nevertheless very
important for anyone working with RAI standards (and worrying about how
they are put into use). I'm nowadays more inclined to support work that
tries to fix existing problems (although this is quite boring) rather
than doing some cool new stuff. 
 
Markus

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext Elwell, John
>Sent: 01 October, 2008 11:19
>To: Adam Roach; Dean Willis
>Cc: [email-masked]
>Subject: Re: [RAI] Making RAI work better
>
>Adam,
>
>I think you make good points. Theoretically the deliverable 
>dates should focus our attention on the ones with earlier 
>dates, but that doesn't seem to happen. Perhaps we should set 
>dates (i.e., achievable dates) only for a small number of 
>items per WG and push very hard to achieve those. I would not 
>want to throw out discussions on future topics altogether - 
>that is a recipe for stagnation - but due priority has to be 
>given to a small number of achievable targets. Others we can 
>keep in a pool and assign dates when resources become 
>available, i.e., when we have finished some other targets. If 
>technical difficulties arise with a particular deliverable, we 
>can of course delay that, and maybe promote something else to 
>take its place.
>
>As a participant, how these items are split between groups is 
>of less importance, but if Dean considers the chairs to be 
>overloaded (which I can believe), then by all means go for a 
>greater number of groups.
>
>The whole end-to-end process needs looking at, not just what 
>happens in the WG. To take a recent example, by my records 
>cc-transfer started WGLC in August 2005 and has only just gone 
>to IESG last call. I am sure there were delays from all 
>parties (WG members, WG chairs, editors and ADs), and I am 
>sure some valid technical concerns came up during that time.
>But 3 years!
>
>John
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of 
>> Adam Roach
>> Sent: 01 October 2008 03:32
>> To: Dean Willis
>> Cc: [email-masked]
>> Subject: Re: [RAI] Making RAI work better
>> 
>> I think the problem is that we're constantly increasing the 
>number of 
>> threads (documents) we're working on, while the number of CPU cores 
>> (key
>> participants) remains fairly constant. We're CPU bound. 
>> Increasing the
>> number of processes (working groups) so that they can each 
>have fewer 
>> threads in them (but still the same number of threads
>> overall) doesn't
>> change the fundamental problem that we're simply out of CPU cycles.
>> 
>> Given that we don't know how to increase the number of processor 
>> cores, the only thing we can usefully play around with is thread 
>> scheduling. Do we throw all the threads on the processor cores at 
>> once, so that they all make progress all the time, but take five to 
>> ten years each to complete? Or do we strictly limit the number of 
>> threads so that each one completes fairly rapidly and gets 
>out of the 
>> way for the next one?
>> 
>> I think the latter approach would be far more productive. 
>When I move 
>> between work items, I know I have to swap information back into my 
>> head to just have the context to think about the related 
>problems. For 
>> the past few years, most of my IETF work has been characterized by 
>> thrashing, in which I spend much more time re-learning the 
>context for 
>> a piece of work than I do actually thinking about the 
>problems related 
>> to that work. This is 100% because there's too much going 
>on, and it's 
>> all too tightly interconnected to focus on small niches.
>> 
>> Robert has pointed out that we can never say "no," only say 
>"not now." 
>> I agree with this statement; however, I would go one step further to 
>> argue that we don't even say "not now" nearly often enough. 
>And we've 
>> become highly inefficient for it.
>> 
>> /a
>> 
>> Dean Willis wrote:
>> >
>> > The main problem we have with RAI is that some of our
>> working groups
>> > have dozens of documents. Both the brainspace of the WG and the 
>> > attentions of the management team (aka, Keith and I, for SIP) are 
>> > consumed with swapping between documents trying to give "fair"
>> > treatment to all. Hence, the urgent is balanced against the
>> important,
>> > and we end up more and more fragmented.
>> >
>> > We have huge, eternal working groups that don't focus well. Our 
>> > meetings can't focus, our mailing lists can't focus, our 
>management 
>> > can't focus, and our participants can't focus. We're like 
>> > three-year-olds in a three-ring circus, too busy gawking at
>> the other
>> > clowns to get any work done.
>> >
>> > Several years ago, I proposed a reorganization (slides at
>> > 
>> http://www.ietf.org/proceedings/06mar/slides/raiarea-3/sld1.htm). The
>> > consensus at the time was simply to have more rigorous chairs. We 
>> > added Keith, who is  quite a rigorous chair, and it 
>helped, but not 
>> > enough. We've also tried more organized chairs, like Mary, in 
>> > SIPPING.  Again, this helped, but not enough.
>> >
>> > I maintain that what is needed is to reduce the size of a
>> chair's job
>> > so that it can be done well in a reasonable 4-6 hours per
>> week, rather
>> > than done badly with a workload more like 30 hours per week. The 
>> > easiest way to do this is to divide the problems up across more 
>> > chairs. Of course, getting rid of a few problems would help too.
>> >
>> > Towards this end, I recently suggested a reorganization (see 
>> > http://www.ietf.org/mail-archive/web/sip/current/msg23692.html).
>> >
>> > This reorg proposed replacing SIP and SIPPING with a couple
>> of smaller
>> > working groups with narrow charters, including (not nec. in
>> this order):
>> >
>> > 1) RAI Maintenance: Essential corrections to existing RFCs. No 
>> > semantic or functional changes, just bug fixes.
>> >
>> > 2) SIP Draft Standard: Whatever is needed to move the SIP
>> spec family
>> > to draft standard
>> >
>> > 3) Real-Time Operations: Deals with the questions of how to do "x" 
>> > with SIP and related specs
>> >
>> > 4) Real-Time Policies: Session policies, SAML, etc.
>> >
>> > 5) real-Time Identity Expression, for which I proposed a charter:
>> > http://www.ietf.org/mail-archive/web/sip/current/msg23899.html
>> >
>> > There are some other things that SIP is close to finishing
>> and should
>> > just be left there. I suspect the same is true of SIPPING. 
>> When done,
>> > we close those nuthouses down.
>> >
>> > Big, complex documents that have a lot of things depending on them 
>> > belong in their own dedicated working groups with a dedicated 
>> > management team.
>> >
>> > Related sets of documents with tight interdependencies also
>> belong in
>> > their own working groups. For example, the SIP Consent
>> Framework and
>> > the half-dozen drafts detailing how to use contact-lists
>> for various
>> > SIP requests  might have made for a reasonably chartered
>> working group
>> > with a reasonable 2-year lifespan. A working group that
>> could actually
>> > finish, go away, and free up resources for new work.
>> >
>> > Here's how I envision this working: If somebody dreams up 
>a new SIP 
>> > extension that does something the RTOps group can't figure
>> out how to
>> > do reasonably with what we have, then we run a BOF and see 
>if it is 
>> > worth working on. If so, then we charter a working group,
>> If not, we
>> > either pursue AD-sponsored individual informational
>> (assuming it does
>> > not need to be a STD track), or we don't work on it.  If we
>> have more
>> > WGs than meeting slots, some WGs don't meet, and we don't
>> charter new
>> > ones until the schedule is relieved.
>> >
>> >
>> > --
>> > Dean
>> >
>> >
>> >
>> > _______________________________________________
>> > RAI mailing list
>> > [email-masked]
>> > https://www.ietf.org/mailman/listinfo/rai
>> 
>> _______________________________________________
>> RAI mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/rai
>> 
>_______________________________________________
>RAI mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/rai
>
_______________________________________________
RAI mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rai

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 1 Oct 2008 08:48:35 -0400

Is the number of documents the problem at this point in all groups?  
Examples: SIMPLE has only two early (< 03) documents, SIP only a few  
more. Pressure on WG meeting discussion time in most WGs seems to have  
eased a bit. The problem, in my view, is finishing documents that are  
90%+ done, with essentially no major technical changes in the last few  
meeting cycles. Maybe we need the equivalent of a "closer", i.e.,  
somebody who is assigned by the chairs to work with the (often  
exhausted, having mentally moved on) editors and authors to get the  
document out the door. As noted in my other rant, maybe chairs should  
focus on the high-dependency and high-impact drafts first.

To pick on one RAI WG that traditionally has been very busy: According  
to http://www.ietf.org/proceedings/08jul/slides/sip-3.pdf, for  
example, the SIP WG only has 5 documents that are still in discussion.  
All the rest are in WGLC (7), IESG review (9) and the RFC editor queue  
(7). Thus, reducing the inflow into the WG isn't likely to help much  
at this point, although I'm certainly not advocating that we take on  
new second-order work.

Maybe it would be helpful if there's a state-of-RAI overview (by  
email) every few months, with an update on the statistics, similar to  
the RFC editor statistics presented at the plenary. That way, we'll  
have a better idea where the pipeline is clogged and where Draino is  
needed.

Henning
(who also has a few 90+% drafts that need finishing...)

On Oct 1, 2008, at 4:18 AM, Elwell, John wrote:

> Adam,
>
> I think you make good points. Theoretically the deliverable dates  
> should
> focus our attention on the ones with earlier dates, but that doesn't
> seem to happen. Perhaps we should set dates (i.e., achievable dates)
> only for a small number of items per WG and push very hard to achieve
> those. I would not want to throw out discussions on future topics
> altogether - that is a recipe for stagnation - but due priority has to
> be given to a small number of achievable targets. Others we can keep  
> in
> a pool and assign dates when resources become available, i.e., when we
> have finished some other targets. If technical difficulties arise  
> with a
> particular deliverable, we can of course delay that, and maybe promote
> something else to take its place.
>
> As a participant, how these items are split between groups is of less
> importance, but if Dean considers the chairs to be overloaded (which I
> can believe), then by all means go for a greater number of groups.
>
> The whole end-to-end process needs looking at, not just what happens  
> in
> the WG. To take a recent example, by my records cc-transfer started  
> WGLC
> in August 2005 and has only just gone to IESG last call. I am sure  
> there
> were delays from all parties (WG members, WG chairs, editors and ADs),
> and I am sure some valid technical concerns came up during that time.
> But 3 years!
>
> John
>
>> Behalf Of Adam Roach
>> I think the problem is that we're constantly increasing the number of
>> threads (documents) we're working on, while the number of CPU
>> cores (key
>> number of processes (working groups) so that they can each have fewer
>> Given that we don't know how to increase the number of
>> processor cores,
>> the only thing we can usefully play around with is thread
>> scheduling. Do
>> we throw all the threads on the processor cores at once, so that they
>> all make progress all the time, but take five to ten years each to
>> complete? Or do we strictly limit the number of threads so
>> that each one
>> completes fairly rapidly and gets out of the way for the next one?
>>
>> I think the latter approach would be far more productive. When I move
>> between work items, I know I have to swap information back
>> into my head
>> to just have the context to think about the related problems. For the
>> past few years, most of my IETF work has been characterized by
>> context for a
>> piece of work than I do actually thinking about the problems
>> related to
>> that work. This is 100% because there's too much going on,
>> and it's all
>> too tightly interconnected to focus on small niches.
>>
>> "not now." I
>> agree with this statement; however, I would go one step
>> further to argue
>> that we don't even say "not now" nearly often enough. And
>> we've become
>> highly inefficient for it.
>>
>> /a
>>
>> Dean Willis wrote:
>>>
>>> meetings can't focus, our mailing lists can't focus, our management
>>> added Keith, who is  quite a rigorous chair, and it helped, but not
>>> Here's how I envision this working: If somebody dreams up a new SIP
>>> do reasonably with what we have, then we run a BOF and see if it is

---

From: Adam Roach <[email-masked]>
Date: Wed, 01 Oct 2008 08:18:18 -0500

Henning Schulzrinne wrote:
> more. 

Breaking statistics down on a per-group basis is misleading, because the 
work has metastasized into many smaller groups, while the pool of people 
working on items has remained approximately constant in size. We could 
give every active document its own working group, and the problem would 
remain (even though any one working group's queue would never exceed one 
document).

This is a pan-RAI problem, and analyzing it as if each group were a 
disconnected entity will lead us to incorrect conclusions.

To reiterate: the key point I was trying to make in my earlier email is 
that the problem isn't the number of documents on a per-group basis -- 
it's the total number of adopted documents across all RAI working groups 
(which have fundamentally the same participant pool, with rare exception).

> (7).

I think WGLC is still very much part of the working phase of a document. 
And having seven documents in WGLC across all of RAI is a bit 
overwhelming, let alone seven in one group.

/a

---

From: "Mary Barnes" <[email-masked]>
Date: Wed, 1 Oct 2008 08:44:41 -0500

Here's my view of the problems, which contains many of the concerns
already raised and a few others:
1) The biggest blocking point IMHO in efficiently completing work items
is that many of the key authors have many work items underway and there
are often difficulties in priortizing these work items, in particular
with regards to day jobs. This has been an obvious problem in SIPPING
WG.  

2) RAI WGs tend to be slow and reluctant in dropping work items that may
no longer be relevant due to the delay in completing and the fact that
the market has already made other decisions. 

3) Related to 2, as time goes by, it is quite likely that the standards
we produce are far less likely to be implemented. This may not
necessarily be a problem for some work items that are intended for
specific scenarios that may not be so widespread.

4) Also, related to 2), changing consensus decisions tends to be a rule,
rather than an exception. Certainly, it's a good thing to recognize when
the group has made a poor decision and could well be viewed as an
attempt to accomplish 2), but it is usually around key decisions for key
documents and tends to just introduce further delays. 

5) Interfacing with other areas is not always optimal - we still seem to
get a fair number of Sec-dir DISCUSSES and the APPs and OPs folks are
not always happy with WG decisions.
 
6) Interfacing with other SDOs is not always optimal.  Obviously, in one
sense, it's a good thing to have our standards being used by other SDOs,
the problem comes when the requirements come in at the final hour (in
terms of SDO deadlines) and it does take WG and editor cycles to address
these requirements.

7) By the nature of the area, there is overlap and dependencies between
the various WGs that impacts completing work items in a timely manner
difficult. This impacts starting work items (i.e., which WG should it be
discussed in), as well as progressing work items that need to be
reviewed and discussed in multiple WGs.

We have actually made some improvements that have been helpful: 
1) Creating more WGs with more tightly scoped charters and reasonable
number of milestones. This has definitely decreased the volume of work
in the SIPPING WG.  Although, there is a downside per item one above. 

2) Increasing the number of cross area reviews and cross WG reviews by
RAI SMEs that haven't been involved in a work item.  Doing these earlier
has been helpful in fine tuning work items. So, the area has worked to
ameliorate problem 5) above. And, this should help to address problem 7)
above. 

Here's some suggestions of things we could do, some of which have
obviously been discussed in the past: 
1) Not taking on new work items until previous have been completed.
There are likely few WGs (at least in the ones that I'm most familiar)
that don't have documents that have been around since the formation of
the WG. There are several difficulties in achieving this: WGs have not
supported this approach, doing this could make problem 3) above worse. 

2) Further splitting the work in the most busy WGs for focus and
prioritizing work. I think Dean's suggestion for the split is a good
starting point for discussion.  This, in one sense, just spreads the
problem around and  problem 1) above still remains (and might be made
worse as then the editor has to deal with even more WGs in some cases).
Also, this could make problem 7) worse. But, it does allow more focused
WG sessions and would allow better prioritization of work items within a
WG.  Then, it's up to the ADs to prioritize within the area :)

3) Recruit more resources to contribute to work items. There is a very
small subset of people that attend the WG sessions that are authors of
active WG documents. The review process in SIPPING was an attempt to get
more folks involved, but in general, it's the same set of folks doing
the document reviews that chair other WGs and edit other WG documents.
So, I'm not sure the best way to do this, particularly given the current
business environment. But, we don't have a choice IMHO if we want to
make better progress, as this would help with the biggest problem - 1)
above. 

One suggestion for getting more contributors is for the current key
contributors to serve as mentors either for folks within their own
companies or other participants that want to become more involved. For
some folks, the bar is getting over the hurdle of editting documents in
XML - encouraging folks to attend the relevant training and offering to
do one on one tutorials in the terminal room during the meeting week
might be helpful.  It can be very intimidating for "new" folks to try to
get involved and most of the "old" folks tend to spend the meeting weeks
amongst themselves. 

There are also folks that have long been very active on the WG mailing
list that don't always attend every f2f meeting, but these folks would
likely make excellent editors. The key hurdle IMHO to spreading the work
around is that many authors are reluctant to give up "ownership" of the
work even after it becomes a WG document. It is very rare for a WG chair
to select an alternative author for a document once it becomes a WG
document.  If this became more common, this might really help improve
progress. When we have done this for WG documents that have become
hopelessly delayed, it has improved progress. 

Mary.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Cullen Jennings
Sent: Tuesday, September 30, 2008 10:37 AM
To: [email-masked]
Subject: [RAI] Making RAI work better

Over the past year or so, Jon and I have heard concerns about the
efficiency and organization of the RAI Area. We have both observed that
the larger working groups, particularly SIP and SIPPING, continue to
have difficulty tackling some of their more complex projects. The more
critical a document seems to be from a dependency perspective, the more
late surprises seem to emerge in its development and the longer it takes
to escape from the working group process. A relatively small number of
the working groups in the RAI Area seem to encompass the lion's share of
our documents in their scope, which may concentrate too much of our work
in too few areas and cause distracting parallelization.

Ultimately, these problems might result from any number of causes. There
might be structural problems with the manner the RAI Area is divided
into working groups, issues with chartering or focusing of the efforts,
snarls intrinsic to the technology, personnel problems at any number of
levels, questions of participant energy, or any of a number of
combinations thereof.

What we'd like to do is kick off a discussion about ways that we can
make RAI work better. As a part of that discussion we are reserving one
of our precious timeslots for a RAI Area open meeting in Minneapolis (at
least the Friday afternoon experiment will give us one more slot than
usual). In order to help set an agenda for that meeting, we'd like to
invite any comments and discussion on this list ([email-masked]), or if
necessarily in private correspondence to Jon and I. We're interested to
learn to what degree people believe there are problems that need to be
addressed, and what sorts of problems and potential solutions the
community can identify.

Cullen Jennings
Jon Peterson
RAI Area Directors

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 1 Oct 2008 10:43:20 -0500

I think you are correct about being CPU-bound, but I also
think the solution to the problem is actually really simple.

Instead of having group of enlighted individuals with the power
to say "not now" or "no", it would be a lot more efficient if 
individual authors were held accountable to finishing their draft
in a timely manner.

To do this, we would need to:
1) Respect the target set-up in the Charter. 
2) If a document becomes dormant or too inactive, it would be pulled
   out or given to another editor.
3) An editor should not be allowed to drive too many working group
   documents at the same time. I'm not sure exactly how to do this
   because the number may vary per author (depending on their
   time allocation as individuals to the IETF and capacity). Perhaps
   the chairs should have discretion on allowing an author to be editor
   based on the pace of progress on the other documents for which he is
   an editor.

> Sent: Tuesday, September 30, 2008 19:32
> To: Dean Willis
> Cc: [email-masked]
> number of threads (documents) we're working on, while the 
> number of CPU cores (key
> Increasing the number of processes (working groups) so that 
> they can each have fewer threads in them (but still the same 
> number of threads overall) doesn't change the fundamental 
> problem that we're simply out of CPU cycles.
> 
> processor cores, the only thing we can usefully play around 
> with is thread scheduling. Do we throw all the threads on the 
> processor cores at once, so that they all make progress all 
> the time, but take five to ten years each to complete? Or do 
> we strictly limit the number of threads so that each one 
> When I move between work items, I know I have to swap 
> information back into my head to just have the context to 
> think about the related problems. For the past few years, 
> most of my IETF work has been characterized by thrashing, in 
> which I spend much more time re-learning the context for a 
> related to that work. This is 100% because there's too much 
> going on, and it's all too tightly interconnected to focus on 
> small niches.
> 
> "not now." I agree with this statement; however, I would go 
> one step further to argue that we don't even say "not now" 
> nearly often enough. And we've become highly inefficient for it.
> 
> /a
> 
> Dean Willis wrote:
> >

---

From: Ben Campbell <[email-masked]>
Date: Wed, 1 Oct 2008 11:09:43 -0500

[I'm responding to the whole thread, not just picking on Mary. I'm  
just jumping in here because hers is the latest email I've seen, and  
also the most comprehensive]

While I agree with Adam that adding more work groups does not increase  
the size of our worker pool, I also agree with Dean and others that it  
would increase the pool of _chairs_. The biggest problem I see is that  
RAI already has a nigh impossible scheduling problem for IETF  
meetings. If we have more work groups, we will have to resolve  
ourselves in advance to a good number of the groups not getting face  
to face time at any given IETF meeting. If we have to have more  
interim meetings to address this, then I think we loose most of the  
value of having more groups.

If we _do_ add more groups, I suggest we focus on charters that can  
conceivably complete--and close down. We've developed a culture of  
open-ended work groups. That's not what work groups are for--that's  
what _areas_ are for.

So it really comes down to managing the work we are willing to accept,  
and make it easier to cut work that languishes or otherwise becomes  
moot. One approach would be for any substantially new work that shows  
up in SIP or SIPPING (or other historically open ended groups) to go  
through the BoF process, and if successful get it's own work group.  
That group should be chartered with very clear winning (read:  
shutdown), and losing (also read: shutdown) conditions. Insufficient  
interest would be a shutdown conditions. The best measure of interest  
is work getting done on schedule, not the number of people who come to  
the mike and say "this is important".

You could take a similar approach to work items inside a work group.  
If  you can't get enough reviewers, you don't have sufficient  
interest. It doesn't matter how many important drafts depend on it, or  
what other SDOs depend on it--if you can't get reviews, assume no one  
cares. A WGLC that goes by without a reasonable quorum of reviews  
would be treated exactly as if it had gotten a lot of reviews saying  
that we should kill the work.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 1 Oct 2008 11:15:22 -0500

[Splitting out one of Mary's points that I think is too important to  
be buried in all the other controversy]

> documents and tends to just introduce further delays.

I agree with Mary in that we have a problem with the stickiness of  
decisions. As a prior editor of a controversial work group item, a big  
part of my pain was around having the same arguments keep coming back  
with no new information, but with the work group responding  
differently to them each time.

It's very difficult to go back over the fossil record and say "back on  
XXX date, someone made the exact argument, and the work group chose  
the direction in draft-yyyy" as that information is buried in email  
archives that are hard to search, wg minutes that look much more  
sketchy a year down the road than they seemed at the time of  
publication, and the conflicting memories of participants. Some sort  
of process/tool for capturing and organizing consensus points might be  
useful here.

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Wed, 1 Oct 2008 12:20:41 -0400

Ben,

Meeting Notes???

BTW, how do you document a hmmmmm?

Also, does it take a higher level of HMMMMM to overturn a decision?

Mike

> Behalf Of Ben Campbell
> Sent: Wednesday, October 01, 2008 12:15 PM
> To: Mary Barnes
> Cc: [email-masked]
> Subject: [RAI] Persistence of Consensus [apologies to 
> Salvador Dali] (wasRe: Making RAI work better))
> 
> [Splitting out one of Mary's points that I think is too 
> important to be buried in all the other controversy]
> 
> > 4) Also, related to 2), changing consensus decisions tends to be a 
> > rule, rather than an exception. Certainly, it's a good thing to 
> > recognize when the group has made a poor decision and could well be 
> > viewed as an attempt to accomplish 2), but it is usually around key 
> > decisions for key documents and tends to just introduce further 
> > delays.
> 
> I agree with Mary in that we have a problem with the 
> stickiness of decisions. As a prior editor of a controversial 
> work group item, a big part of my pain was around having the 
> same arguments keep coming back with no new information, but 
> with the work group responding differently to them each time.
> 
> It's very difficult to go back over the fossil record and say 
> "back on XXX date, someone made the exact argument, and the 
> work group chose the direction in draft-yyyy" as that 
> information is buried in email archives that are hard to 
> search, wg minutes that look much more sketchy a year down 
> the road than they seemed at the time of publication, and the 
> conflicting memories of participants. Some sort of 
> process/tool for capturing and organizing consensus points 
> might be useful here.
> 
>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 1 Oct 2008 12:44:37 -0500

> Meeting Notes???

That's what I meant by sketchy wg minutes.

---

From: "Mary Barnes" <[email-masked]>
Date: Wed, 1 Oct 2008 13:49:56 -0500

I do agree that WG minutes are not always as comprehensive or clear as
they should be.  We have a good example of ambiguity from the SIPPING WG
IETF-72 minutes (wrt updates to PAI), where there were two possible
interpretations. 

There are certainly recommendations for the contents of minutes (BCP
25), but there is certainly lots of potential for gaps in recollection
and interpretation of what occurs during a WG session. For most groups,
there are typically two notetakers and then one of the chairs (or
secretary) often puts together a summary typically including key
agreements and any actions.  And, often chairs use their own sets of
notes as a source.  

And, we usually make the minutes available before the deadline for the
proceedings, but I do wonder how many people comprehensively review and
compare against their recollections and notes?  When I do so (for other
WGs), for whatever reason, it's often well after the proceedings
deadline - my reading when they're posted is often very cursory. 

Not to be pedantic, but perhaps we need to ensure we get some response
on the WG mailing lists when we post preliminary notes and ensure that
everyone thinks they're comprehensive and capture their recollection of
events. This may not have avoided the problem in SIPPING, but could
avoid other problems in the future. I also feel this is really important
for the folks that weren't in the sessions as this is one of the key
ways that others learn about what we're doing. 

As far as tracking consensus, that is what we've tried to do with the
spreadsheets in SIPPING WG. The spreadsheets primarily include links to
the individual detailed reviews (and other key comments), but in the
cases of key issues that are more controversial, links (or imported
text) are included.  This gives us a little bit of history for specific
documents. 

When I need to backtrack, I do often go to past IETF presentations,
where it is typically a good idea for folks to summarize key issue
resolution since the last meeting and then discuss current key open
issues.  And, some folks do a good job of that in the "Summary of
changes" section of documents. 

If we could incorporate the issues and reviews into the ID tracker that
might be helpful, although, that might overload that tool.  However,
there is a comment field for each document on the tools page, that we
could perhaps use as a trial to either point to an issue tracker or
repository of issues for WG documents.  I was going to try to experiment
with that to see if it couldn't replace the spreadsheets I have for
SIPPING. Dan Wing is using that to track things like WGLC in BEHAVE WG. 

Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ben Campbell
Sent: Wednesday, October 01, 2008 12:45 PM
To: Mike Hammer (hmmr)
Cc: [email-masked]
Subject: Re: [RAI] Persistence of Consensus [apologies to Salvador Dali]
(wasRe: Making RAI work better))

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 1 Oct 2008 15:03:26 -0400

On Oct 1, 2008, at 2:49 PM, Mary Barnes wrote:

How about a Wiki for the WG, with a page for each document and a bit  
of common structure, such as "status", "current token", "open issues"?

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 01 Oct 2008 14:06:13 -0500

> IETF-72 minutes (wrt updates to PAI), where there were two possible
[...]
> events. 

Mary: ISTM that the IETF audio recordings could be used here (I
know I have used them many times in the past to recollect what
was said regarding some work that I am spear-heading.)  More
specifically, the WG secretary could splice the recording such
that each agenda item is either in its own audio file, or at the
very least, there is a minute marker posted that correlates the
agenda items to the audio recording.  We could go further and
post a minute marker for consensus discussions as well.

If such a resource could be made available immediately after the
meetings, then it can be included in the supplementary web site
(softarmor.com) as well as the official IETF proceedings web site.

If we do so, then tracking consensus will be as simple as
playing the recording.

Just a thought.

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}
WWW:   http://www.alcatel-lucent.com/bell-labs
_______________________________________________
RAI mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rai

---

From: Dan York <[email-masked]>
Date: Wed, 1 Oct 2008 15:17:38 -0400

> of common structure, such as "status", "current token", "open issues"?

DY> I would note that on some of the Working Group pages on the  
tools.ietf.org site there is already a link for a Wiki, but in a very  
quick survey of WG pages, I didn't see any of the Wiki pages being  
used.  Two at random:

http://trac.tools.ietf.org/wg/sip/trac/wiki
http://trac.tools.ietf.org/wg/p2psip/trac/wiki

DY> For whatever reason, the SIPPING WG page doesn't have a Wiki link  
on the top: http://tools.ietf.org/wg/sipping/  I didn't look at all  
RAI WGs, so perhaps one of the groups is doing something already with  
the Wiki.

DY> I think to a degree this actually speaks to the larger issue that  
RAI WGs seem to do things differently with regard to status pages,  
agendas, open issues, etc.  Some use the tools.ietf.org site...  some  
use other tools like the SIP WG with its supplemental wiki at: http://www.softarmor.com/sipwg/ 
  (which is quite useful).   When a meeting time comes around, each WG  
seems to have different agenda styles and formats (for example, on a  
basic level, whether or not I-Ds being discussed are hyperlinked from  
the agenda page), based on however the WG chairs want to do it.  I  
certainly understand and appreciate the value in giving WG leaders the  
right to structure the information flow of the WG in the way they want  
to do so... but it can make getting involved a bit challenging for  
newcomers as they need to sort through how the different WGs work.

My 2 cents,
Dan

-- 
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: "Peterson, Jon" <[email-masked]>
Date: Wed, 1 Oct 2008 18:25:00 -0400

I agree that the maintenance of consensus is a serious issue for the
IETF overall, but perhaps especially in RAI because there are so many
stakeholders interested in most decisions.

Personally, I have found myself increasingly skeptical about the
benefits of the level of oversight and review our publications currently
receive. Consensus is always a measure of a specific group of
individuals at a specific point in time (as a recent document Lisa wrote
argues), and thus its maintenance depends on persuading parties not
present at that date and time that they should respect its validity.
Unfortunately, we have no really good arguments why they should, not to
mention no real process obligation for them to do so (although we
sometimes pretend the contrary).

In our process, every decision made at an individual level, a design
team level, and a working group level is subject to oversight by outside
parties. A certain amount of this is undoubtedly healthy. We need to
recognize, however, that reviewers are tasked with improving documents,
which basically means finding problems and suggesting how they might be
corrected. Such a process inevitably questions existing consensus. One
of the roots of the consensus-maintenance problem is the inescapable
fact that consensus is sometimes objectively wrong - we may all agree in
a room sometime that a document should use a mechanism that has
limitations we didn't envision. Because overturning consensus sometimes
(often?) leads to higher document quality, it is impossible for us to
reject it outright.

However, the amount of review we aim at documents before WGLC, during
WGLC, during IETF LC, and during IESG review has steadily increased
during the years I've been on the IESG. It began from a notion that we
wanted to avoid "late surprises" and relocate the review function to an
earlier point in the process. Instead, the document review effort, and
the proposal of revisions required for advancement, is now repeated many
times during the document's lifecycle by completely unrelated reviewers
who are concerned with completely different issues. They find different
issues because of course they have different technical backgrounds and
so on, but moreover there is no objective measure of how good a document
needs to be in order to advance, no magic checklist of which issues are
blocking issues that need to be fixed and which are not. Instead, we
rely on editors, WG chairs, Ads, and hums of specific rooms at specific
times to judge which issues need to be addressed - generally, however,
if there's the slightest perception of a problem, the document will
block on its resolution. The result is that we now have both late
surprises and early surprises, and the latter is what brings documents
back for their 4th WGLC.

I bring all of this up because I don't want root issues to be missed
here by exploring one solution space. Frankly, I don't think adding
further bureaucracy to document the putative existence of a consensus in
Wikis or audio mp3's or what have you will significantly reduce the
problem. The problem is not that people are unaware that a consensus was
at some point measured and that we need better marketing for consensus.
The problem is that we have a culture of overturning consensus for good
reason, and we lack agreement on when a document is "good enough" that a
reviewer should let it pass unscathed. 

Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Vijay K. Gurbani
Sent: Wednesday, October 01, 2008 12:06 PM
To: Mary Barnes
Cc: [email-masked]
Subject: Re: [RAI] Persistence of Consensus [apologies to Salvador Dali]
(wasRe: Making RAI work better))

[...]

Just a thought.

Thanks,

- vijay

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 1 Oct 2008 19:58:36 -0400

It is true that in its infancy, RAI feasted on TSV and had a generous
helping of Apps for dessert.

The rationale at the time was that all of the groups it devoured were
frequented by the same traveling circus of WG contributors, and that it
made no sense for these groups to be divided between areas. That was the
initial unifying principle behind RAI. Subsequently we drafted some
language about "delay-intolerant personal communications" as its scope,
but that was a secondary impulse.

I think the presence of AVT in RAI may owe more to the scope language
than to the traveling circus. As such, I don't reject out of hand the
notion that some of this work could be split back into the TSV area, if
it can be established that the attendance of the traveling circus is not
required. BEHAVE, which was another corner case, has certainly done fine
in TSV for that reason. I might, however, question whether AVT is really
one of the places in RAI that is currently suffering or inflicting
problems that would be alleviated by transplating it. If it is so, then
I'd certainly give serious consideration to the move.

SIGTRAN remains open only for some liaison-related reasons, basically,
but is otherwise practically closed.

Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Lars Eggert
Sent: Wednesday, October 01, 2008 1:18 AM
To: ext Cullen Jennings
Cc: [email-masked]
Subject: Re: [RAI] Making RAI work better

Hi,

one way of improving RAI might be to focus, i.e., shrink, it a bit.  
RAI was created by collecting together related WGs that used to be in  
other areas, mostly in TSV. In hindsight, the split has worked out  
extremely well overall, but there may be one or two WGs or at least  
larger work items that could move somewhere else, thereby reducing  
load a bit.

A concrete example that I've mentioned to some folks is the RTP part  
of AVT, which to me at least could as well become a TSV-area work item  
somewhere. (Especially if AVT should decide to start work on some  
major new version of RTP.) SIGTRAN might be another example. Other  
such work items might exist where RAI intersects with other areas.

Note that I'm not pushing for any of this to happen, I'm merely  
bringing it up as a possibility for discussion, since you asked for  
input.

Lars

---

From: Dan York <[email-masked]>
Date: Wed, 1 Oct 2008 22:12:01 -0400

Being a relative newcomer to the IETF process in that I've only been  
attending IETF meetings for the past couple of years, I have to second  
Adam's comments here (and also say that it gave me quite a laugh).

At the first IETF I attended, IETF 66 up in Montreal, I was rather  
amused to see that as I travelled around from WG to WG in what would  
become the RAI Area, it was basically the same people attending the  
same WGs... more or less the same people standing up in front  
presenting the slides... essentially the same people standing up at  
the microphone asking questions or debating points... and some of the  
same people at the tables as chairs.  From reading the mailing lists,  
I had gathered a sense that there was a small core of folks who were  
the most actively involved, but it wasn't until attending a meeting  
that I realized just how many of folks from one RAI WG were just as  
active in almost every other RAI WG.  (And yes, in subsequent  
meetings, I, too, have been one of the "RAI groupies" who travels from  
room to room to whatever the current RAI group is, and who stands up  
at the microphone or is in the Jabber chat room.)

Having long been involved in leading various volunteer nonprofit  
organizations, I've definitely learned that you seem to inevitably  
wind up with a core of maybe 20% of the volunteers doing probably 80%  
of the work.  It just seems to be a fundamental part of human nature  
in organizations.  The tricky part is scaling and growing that core as  
the workload and agenda of the organization grows. Or in Adam's terms,  
growing the number of CPU cores.

It does seem like the "RAI" area is "CPU bound". And I think as more  
and more people in the wider industry want to do more and more with  
SIP, there are only going to be *increasing* demands on the RAI group  
as a whole.  I agree with comments flowing in that there are probably  
several steps we need to take:

1. RE-ORGANIZING/FOCUSING WGs - I agree with Deans' points that many  
of the existing WGs have become so large and are taking on so many  
issues that they *can't* adequately address all those issues. I think  
we do need to re-org into WGs that have smaller, focused, *attainable*  
charters, where WGs can start up, bite off an attainable bit of work,  
accomplish that, and then shut down. (And yes, I realize that sounds  
rather idealistic.)

2. FIGHTING WG SCOPE CREEP - Part of that would seem to require trying  
more to limit the "scope creep" of the WG's activities. Perhaps  
limiting discussion at meetings to (gasp!) only documents on the WG  
charter or those that, through mailing list debate, are viewed as  
strong candidates to be on the WG charter - rather than what often  
seems to be whatever documents WG members feel need to be discussed.

3. RECRUITING CO-AUTHORS - As Adam indicated, the pool of "key  
participants" who write the documents, champion the documents, etc. is  
rather small.  Yet at any meeting I've been at, any of the RAI WGs  
usually have 100 or more people in the room (sometimes many more than  
that).  Could there not be people out there in that group who could  
assist in this?  If there are key participants trying to handle 4 or 5  
major documents (or 10 or 12), could there not be a way to spin some  
of those out to other people to champion?  Yes, it would mean the  
document author would have to "let go" a little bit and let someone  
else in.  Yes, that new person might need time to come up to speed...  
but in the end might the result not be more people being able to work  
on more documents? (And as a bonus, the "key participant" might be  
able to better focus on the documents he/she is most interested in.)  
Could we somehow find a way to recruit more co-authors?

4. RECRUITING CO-CHAIRS - Similarly, could we find a way to recruit  
more co-chairs?  Dean and any number of the others in this thread have  
talked about the blocking going on by the lack of administrative  
resources.... about the fact that  chairs have too high a load.   What  
skills are we seeking in co-chairs?  I've often seen in the past that  
the skills that make someone an excellent chair/facilitator/group- 
leader are not necessarily the same skills that make someone an  
excellent technical leader (or document developer).  Out of the 100s  
that attend RAI sessions, could we find some folks there with great  
facilitation/administrative skills who can take on co-chair roles?   
Perhaps they would not have the deep technical knowledge (or have  
authored multiple RFCs), but they may be able to run WG sessions and  
mailing lists in professional manner and move the agenda along.  I  
realize that this, of all the items here, may be the hardest to  
consider as there is a certain understandable amount of prestige  
associated with being a "WG Chair".  Still, it may actually be one of  
the easier ways to bring people in and increase the size of the RAI  
core.  There's also the fact that if you create *more* RAI WGs that  
are smaller and more focused, this would provide an opportunity to  
bring in more co-chairs... and partner veteran co-chairs with newer  
participants.

I don't see the demand from the outside industry decreasing... the  
good news is that after 10 years SIP is finally getting some serious  
market attention... and more and more uses are being found for it -  
many of which then feed back into needing some standardization in some  
way.

I think ultimately RAI *does* need to figure out how to grow the  
number of key participants and, in Adam's terms, increase the number  
of CPU cores.

Separately, though, I think Adam has another point toward the end in  
that all of these various working groups *are* increasingly  
interconnected.  The reason we all are RAI groupies that move from WG  
to WG is that in many ways the issues of one WG do in fact relate to  
those of another (in many cases, anyway).  Perhaps a re-org like what  
Dean suggests could help reduce this inter-WG interconnection.   
Perhaps not.  Perhaps it's just an inherent part of RAI and we have to  
figure out some way outside of cloning the ADs to keep the different  
WG's in sync.

My 2 cents,
Dan

On Sep 30, 2008, at 10:31 PM, Adam Roach wrote:

> I think the problem is that we're constantly increasing the number  
> of threads (documents) we're working on, while the number of CPU  
> cores (key participants) remains fairly constant. We're CPU bound.  
> Increasing the number of processes (working groups) so that they can  
> each have fewer threads in them (but still the same number of  
> threads overall) doesn't change the fundamental problem that we're  
> simply out of CPU cycles.
>
> threads so that each one completes fairly rapidly and gets out of  
> the way for the next one?
>
> I think the latter approach would be far more productive. When I  
> move between work items, I know I have to swap information back into  
> my head to just have the context to think about the related  
> problems. For the past few years, most of my IETF work has been  
> characterized by thrashing, in which I spend much more time re- 
> learning the context for a piece of work than I do actually thinking  
> about the problems related to that work. This is 100% because  
> there's too much going on, and it's all too tightly interconnected  
> to focus on small niches.
>
> Robert has pointed out that we can never say "no," only say "not  
> now." I agree with this statement; however, I would go one step  
> further to argue that we don't even say "not now" nearly often  
> enough. And we've become highly inefficient for it.
>
> /a
>
> Dean Willis wrote:
>>
>> The main problem we have with RAI is that some of our working  
>> groups have dozens of documents. Both the brainspace of the WG and  
>> the attentions of the management team (aka, Keith and I, for SIP)  
>> are  consumed with swapping between documents trying to give "fair"  
>> important, and we end up more and more fragmented.
>>
>> can't focus, and our participants can't focus. We're like three- 
>> year-olds in a three-ring circus, too busy gawking at the other  
>> Several years ago, I proposed a reorganization (slides at http://www.ietf.org/proceedings/06mar/slides/raiarea-3/sld1.htm) 
>> . The consensus at the time was simply to have more rigorous  
>> chairs. We added Keith, who is  quite a rigorous chair, and it  
>> helped, but not enough. We've also tried more organized chairs,  
>> like Mary, in SIPPING.  Again, this helped, but not enough.
>>
>> I maintain that what is needed is to reduce the size of a chair's  
>> job so that it can be done well in a reasonable 4-6 hours per week,  
>> rather than done badly with a workload more like 30 hours per week.  
>> The easiest way to do this is to divide the problems up across more  
>> Towards this end, I recently suggested a reorganization (see http://www.ietf.org/mail-archive/web/sip/current/msg23692.html) 
>> .
>>
>> This reorg proposed replacing SIP and SIPPING with a couple of  
>> smaller working groups with narrow charters, including (not nec. in  
>> this order):
>>
>> 2) SIP Draft Standard: Whatever is needed to move the SIP spec  
>> family to draft standard
>>
>> There are some other things that SIP is close to finishing and  
>> should just be left there. I suspect the same is true of SIPPING.  
>> When done, we close those nuthouses down.
>>
>> Related sets of documents with tight interdependencies also belong  
>> in their own working groups. For example, the SIP Consent Framework  
>> and the half-dozen drafts detailing how to use contact-lists for  
>> various SIP requests  might have made for a reasonably chartered  
>> working group with a reasonable 2-year lifespan. A working group  
>> that could actually finish, go away, and free up resources for new  
>> work.
>>
>> extension that does something the RTOps group can't figure out how  
>> to do reasonably with what we have, then we run a BOF and see if it  
>> is worth working on. If so, then we charter a working group, If  
>> not, we either pursue AD-sponsored individual informational  
>> (assuming it does not need to be a STD track), or we don't work on  
>> it.  If we have more WGs than meeting slots, some WGs don't meet,  
>> and we don't charter new ones until the schedule is relieved.
>>
>>
>> -- 
>> Dean
>>
>>
>>

---

From: Dean Willis <[email-masked]>
Date: Wed, 1 Oct 2008 23:08:54 -0500

> simply out of CPU cycles.

We're more starved for chair cycles than we are for author/reviewer  
cycles, although that may be an artifact of the fact that as author/ 
reviewers do less work per document, the chairs have to do more.

I don't know how to get more author/reviewers, but I do know how to  
get more chairs. And that is "more working groups".

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 1 Oct 2008 23:12:48 -0500

On Oct 1, 2008, at 3:18 AM, Lars Eggert wrote:

> RAI was created by collecting together related WGs that used to be  
> in other areas, mostly in TSV. In hindsight, the split has worked  
> out extremely well overall, but there may be one or two WGs or at  
> least larger work items that could move somewhere else, thereby  
> reducing load a bit.
>
> of AVT, which to me at least could as well become a TSV-area work  
> item somewhere. (Especially if AVT should decide to start work on  
> some major new version of RTP.) SIGTRAN might be another example.  
> Other such work items might exist where RAI intersects with other  
> areas.
>

I endorse SIGTRAN to TSV 100%, and agree that RTP could also be  
reasonably split out as its own TSV group.

I also think that some of the RAI work items, like perhaps SPEERMINT,  
are really Operations area problems.

However, inasmuch as many of the participants of things like AVT and  
SPEERMINT are also involved in RAI, having them all in the same area  
has proven a useful way of preventing scheduling conflicts. If we  
schedule block on one set of ADs, it gives us a single thread of  
meetings throughout the week. That has been very helpful.

---

From: "Greg Herlein" <[email-masked]>
Date: Wed, 1 Oct 2008 21:14:23 -0700

Something I've always wanted to know:  what percentage of chairs and
contributors have IETF work as part of their normal job duties, and how many
are doing it purely as volunteer?  I can speak for myself that I rarely have
time to do more than lurk due to my day job duties.

Greg

---

From: Dean Willis <[email-masked]>
Date: Wed, 1 Oct 2008 23:20:29 -0500

On Oct 1, 2008, at 7:48 AM, Henning Schulzrinne wrote:

> more. Pressure on WG meeting discussion time in most WGs seems to  
> have eased a bit. The problem, in my view, is finishing documents  
> that are 90%+ done, with essentially no major technical changes in  
> the last few meeting cycles. Maybe we need the equivalent of a  
> "closer", i.e., somebody who is assigned by the chairs to work with  
> the (often exhausted, having mentally moved on) editors and authors  
> to get the document out the door. As noted in my other rant, maybe  
> chairs should focus on the high-dependency and high-impact drafts  
> first.

We did apply a "closer"  to "outbound", and it helped immensely. Of  
course, it's still stuck in the process, but now out of the WG.

> To pick on one RAI WG that traditionally has been very busy:  
> According to http://www.ietf.org/proceedings/08jul/slides/sip-3.pdf,  
> for example, the SIP WG only has 5 documents that are still in  
> discussion. All the rest are in WGLC (7), IESG review (9) and the  
> RFC editor queue (7). Thus, reducing the inflow into the WG isn't  
> likely to help much at this point, although I'm certainly not  
> advocating that we take on new second-order work.

The SIP queue is shrinking because I'm trying to conclude our charter  
items and close the working group rather than re-charter with another  
50 items. Over the last year, I've been much more assertive about  
avoiding new work. However, from a chair perspective, the stuff "under  
discussion" is the easy part -- WGLC, IETFLC, and nursing along RFCEd  
states is much more time consuming.

> email) every few months, with an update on the statistics, similar  
> to the RFC editor statistics presented at the plenary. That way,  
> we'll have a better idea where the pipeline is clogged and where  
> Draino is needed.

I'm the clog. I don't have the time to push every blocked draft every  
day and every way, both in the WG and in the IESG. Judging by what I  
see happening, the same is true for all the SIP, SIPPING, GEOPRIV, and  
SIMPLE chairs. P2PSIP seems to be the exception here, although this  
may have to do with the overlap between chairs and authors.

---

From: Adam Roach <[email-masked]>
Date: Wed, 01 Oct 2008 23:23:07 -0500

> get more chairs. And that is "more working groups".

Grab a sheet of paper. Write down everyone who you think would be both 
capable and willing to be a RAI area WG chair. Now, cross off everyone 
who is already chairing a group. For anyone authoring a key document, 
consider whether giving them the extra work of chairing a group would 
cause substantial disruption to progressing their document and any work 
citing it as a reference; if the disruption would be substantial, cross 
them off also.

When you're done, describe your sheet of paper to us.

/a

---

From: Dean Willis <[email-masked]>
Date: Wed, 1 Oct 2008 23:25:01 -0500

On Oct 1, 2008, at 11:09 AM, Ben Campbell wrote:
> So it really comes down to managing the work we are willing to  
> accept, and make it easier to cut work that languishes or otherwise  
> becomes moot. One approach would be for any substantially new work  
> that shows up in SIP or SIPPING (or other historically open ended  
> groups) to go through the BoF process, and if successful get it's  
> own work group. That group should be chartered with very clear  
> winning (read: shutdown), and losing (also read: shutdown)  
> conditions. Insufficient interest would be a shutdown conditions.  
> The best measure of interest is work getting done on schedule, not  
> the number of people who come to the mike and say "this is important".

I believe this is exactly what I've been trying to say.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 1 Oct 2008 23:40:06 -0500

On Oct 1, 2008, at 11:23 PM, Adam Roach wrote:

> Grab a sheet of paper. Write down everyone who you think would be  
> both capable and willing to be a RAI area WG chair. Now, cross off  
> everyone who is already chairing a group. For anyone authoring a key  
> document, consider whether giving them the extra work of chairing a  
> group would cause substantial disruption to progressing their  
> document and any work citing it as a reference; if the disruption  
> would be substantial, cross them off also.
>

Not to name names, but I did go through this exercise a while back on  
a call with Cullen, and we have a fair number of folks out there who  
could probably be fine chairs that aren't editing too many documents.  
We also have some past contributors whose budgets have pulled them  
away, but that could probably be brought back on for a "chair" role.

A little history:

I got stuck as as the "new chair" with SIP after my 3rd IETF meeting  
in-a-row, and having written very few drafts. Why? Because I was  
actively settling debates, NOT writing drafts, and had just paid my  
own way to an international IETF meeting because my employer didn't  
have the budget. This apparently showed commitment. I had the  
privilege of co-chairing with the more-experienced Rosenberg and Rosen  
(odd coincidence, eh?) before getting my own "junior" chairs to train  
up.

There are LOTS of people out there more qualified than I was when SIP  
started. Arguably, there are many who are better qualified than I am  
now. Bring 'em on!

--
Dean

---

From: "Hisham Khartabil" <[email-masked]>
Date: Thu, 2 Oct 2008 15:28:12 +1000

I believe one fundamental problem is commitment. As drafts take longer to
complete, WG participants lose interest in that draft. This results
in delays as the WG starves for commitment from the community to finish that
draft. This leaves the author stranded and hungry for feedback.

Reasons that I see causing drafts to take long and participants to lose
interest include:
- People bringing up issues during face-to-face meetings only
- People bringing up issues on the mailing list only and don't participate
in face-to-face meetings
- People with hidden agendas deliberately holding off on bringing up issues
- People with employer interest at heart versus people with community and
technology interest at heart
- Academics versus product developments people. The latter requiring quick
decisions while the former requiring perfection
- Author's/Editor's commitment. Some drafts only get updated weeks prior to
a face-to-face meeting

All those reasons make people go "eeeeeeeeeeeeeeehhh, a new draft? This will
take years. I'll look at it when it becomes a WG item. Or I'll let others
work on it". Hence new, and possibly, import work suffers.

The list above needs to be addressed, perhaps by creating processes,
policies and rules. For example, an editor must roll out a new version of a
draft every month. Or show us running code before we accept your argument
that something is broken (this also shows commitment).

I also believe that we need to do something to get bored people interested
and committed again. A reward or recognition of some sort perhaps.

Regards,
Hisham

On 01/10/2008, Cullen Jennings <[email-masked]> wrote:
> snarls intrinsic to the technology, personnel problems at any number
> of levels, questions of participant energy, or any of a number of
> combinations thereof.
>
> invite any comments and discussion on this list ([email-masked]),
> or if necessarily in private correspondence to Jon and I. We're
> interested to learn to what degree people believe there are problems
> that need to be addressed, and what sorts of problems and potential
> solutions the community can identify.
>
> Cullen Jennings
> Jon Peterson
> RAI Area Directors

---

From: Dean Willis <[email-masked]>
Date: Thu, 2 Oct 2008 01:40:50 -0500

On Oct 2, 2008, at 12:28 AM, Hisham Khartabil wrote:
>
> I also believe that we need to do something to get bored people  
> interested and committed again. A reward or recognition of some sort  
> perhaps.
>
>

I know! Let's ask for a big bailout from the government!

--
Dean

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 2 Oct 2008 08:38:02 -0400

I think that's a false dichotomy for many participants. I suspect most  
fall into the category that producing/editing/shepherding IETF  
documents isn't their main occupation, but it fits well within their  
broad job scope. In other words, they won't get fired for writing a  
draft on the clock, but may not get a raise, either. After all,  
technical professionals hopefully have some choices of how they create  
value for their employer. Given that most take on more than they can  
reasonably handle, it then becomes a matter of "nearest deadline  
first" and "most rewarding first". We see the first principle in  
action in the draft editing activity; if the effort-reward time  
interval gets measured in decades, this is unlikely to attract those  
looking for rewarding activities with a bounded time commitment.

After all, lots of researchers in academia and industry labs volunteer  
to organize technical conferences or review papers, and there's  
usually no direct payback for that, either.

Henning

On Oct 2, 2008, at 12:14 AM, Greg Herlein wrote:

> contributors have IETF work as part of their normal job duties, and  
> how many are doing it purely as volunteer?  I can speak for myself  
> that I rarely have time to do more than lurk due to my day job duties.
>
> Greg

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 2 Oct 2008 08:24:13 -0500

The starving for chairs versus authors/reviewers problem is unique per
each WG. In my view, the biggest challenge in SIPPING is author/editor
cycles followed by reviewer cycles.  It still comes down that there
aren't enough of our core resources (as I noted before the reviewers are
more often the same folks that author docs and chair WG sessions, just
as they are also the meeting notetakers).

Mary.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Dean Willis
Sent: Wednesday, October 01, 2008 11:09 PM
To: Adam Roach
Cc: [email-masked]
Subject: Re: [RAI] Making RAI work better

On Sep 30, 2008, at 9:31 PM, Adam Roach wrote:

> (key participants) remains fairly constant. We're CPU bound.
> each have fewer threads in them (but still the same number of threads 
> overall) doesn't change the fundamental problem that we're simply out 
> of CPU cycles.

I don't know how to get more author/reviewers, but I do know how to get
more chairs. And that is "more working groups".

--
Dean

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 02 Oct 2008 16:14:22 +0200

Hisham Khartabil wrote:
> - Author's/Editor's commitment. Some drafts only get updated weeks prior 
> to a face-to-face meeting
>  

 From my own experience as editor of drafts, I consider that an author 
is committed to editing a draft when such draft is updated at least 
twice between IETF cycles. This isn't hard, believe me. Still, I believe 
most of our RAI drafts get a single update (typically a day before the 
deadline) to, probably, avoid expiration.

Chairs should notice this event and should change editors when the 
condition arises. This has happened just a few times, although I must 
say, fortunately more and more often in the recent times.

/Miguel
-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: "Marshall Eubanks" <[email-masked]>
Date: Thu, 2 Oct 2008 15:03:30 -0400

On Wed, Oct 1, 2008 at 12:15 PM, Ben Campbell <[email-masked]> wrote:

> [Splitting out one of Mary's points that I think is too important to be
> buried in all the other controversy]
>
> decisions. As a prior editor of a controversial work group item, a big part
> of my pain was around having the same arguments keep coming back with no new
> information, but with the work group responding differently to them each
> time.
>

It seems to me that this is the responsibility of the WG Chairs and,
ultimately, but not on a point by point basis, the ADs.

Regards
Marshall

> It's very difficult to go back over the fossil record and say "back on XXX
> date, someone made the exact argument, and the work group chose the
> direction in draft-yyyy" as that information is buried in email archives
> that are hard to search, wg minutes that look much more sketchy a year down
> the road than they seemed at the time of publication, and the conflicting
> memories of participants. Some sort of process/tool for capturing and
> organizing consensus points might be useful here.
>
>

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 2 Oct 2008 14:20:16 -0500

I think Jon pointed out in a subsequent response to this thread that the
WG chairs are actually gathering what they feel is true consensus to
change past decisions:
http://www.ietf.org/mail-archive/web/rai/current/msg00222.html
 
I can't disagree with anything Jon said in this thread and he certainly
has broad visibility into this situation. It's not clear to me either if
we can avoid this problem. It's my personal opinion that many times the
end results are positive, it's just the delay that is problematic IMHO.
And, I know others sometimes feel that way about other
reviews/suggestions that are generally provided outside the scope of WG
activity (e.g., Gen-ART reviews). 
 
Mary. 

________________________________

From: Marshall Eubanks [mailto:[email-masked]] 
Sent: Thursday, October 02, 2008 2:04 PM
To: Ben Campbell
Cc: Barnes, Mary (RICH2:AR00); [email-masked]
Subject: Re: [RAI] Persistence of Consensus [apologies to Salvador Dali]
(was Re: Making RAI work better))

	

		4) Also, related to 2), changing consensus decisions
tends to be a rule,
		rather than an exception. Certainly, it's a good thing
to recognize when
		the group has made a poor decision and could well be
viewed as an
		attempt to accomplish 2), but it is usually around key
decisions for key
		documents and tends to just introduce further delays.

	I agree with Mary in that we have a problem with the stickiness
of decisions. As a prior editor of a controversial work group item, a
big part of my pain was around having the same arguments keep coming
back with no new information, but with the work group responding
differently to them each time.

Regards
Marshall

	It's very difficult to go back over the fossil record and say
"back on XXX date, someone made the exact argument, and the work group
chose the direction in draft-yyyy" as that information is buried in
email archives that are hard to search, wg minutes that look much more
sketchy a year down the road than they seemed at the time of
publication, and the conflicting memories of participants. Some sort of
process/tool for capturing and organizing consensus points might be
useful here.

---

From: Dean Willis <[email-masked]>
Date: Thu, 2 Oct 2008 19:10:33 -0500

On Oct 2, 2008, at 7:38 AM, Henning Schulzrinne wrote:

> I think that's a false dichotomy for many participants. I suspect  
> most fall into the category that producing/editing/shepherding IETF  
> draft on the clock, but may not get a raise, either.

I simply don't get paid when doing IETF activity. It's generally "off  
the clock" non-billable time. Now, it's arguable that the time I spend  
on IETF work increases the value of my billable time, but that doesn't  
get the rent paid.

So, can I afford to spend 20+ hours a week shepherding a really big  
working group with lots of docs? That's a question I ask myself every  
day. I'd certainly like to cut it down to 4 hours a week or so . . .

---

From: <[email-masked]>
Date: Fri, 3 Oct 2008 10:34:28 +0300

Hi,

Related to what Miguel and Hisham are saying and to the fact that there
are "too many" drafts in RAI area in progress in parallel: Has it been
considered that WGs could have an *official* two-level categorization of
WG drafts: critical vs. ordinary. 

Critical drafts would be something that are seen fundamental, such as
new base protocols, significant new functionality or having a lot of
forward-dependencies, and more than just a couple of real contributors.
The expectation with critical drafts would be that the editor(s) create
updates relatively often (and if this doesn't happen, editors would be
reassigned), there is sufficient face-to-face time for them, reviews
would be focused on them etc. The ordinary drafts would run with lesser
expectations on update cycle, agenda slots and so on. They would be the
typical cases where 2-4 people work on them while others wait for WGLC
to read them. It would also be that there could be only max N critical
drafts in WG or area at the same time. On the other hand, ordinary
drafts could be taken more easily.

In some sense this kind of categorization is done in any case, but would
it help to make it more official by briefly describing the criteria and
expectations. At least now different people may have very different
views on which documents are essential in the WG, and it seems that it
is hard to get some work done faster than the other. The tricky thing
would be to determine which drafts are critical and which are not, but I
suppose the normal consensus process would apply.  
 
Markus

>Behalf Of ext Miguel A. Garcia
>Sent: 02 October, 2008 17:14
>To: Hisham Khartabil
>Cc: [email-masked]
>> - Author's/Editor's commitment. Some drafts only get updated weeks 
>> prior to a face-to-face meeting
>>  
>
> From my own experience as editor of drafts, I consider that 
>an author is committed to editing a draft when such draft is 
>updated at least twice between IETF cycles. This isn't hard, 
>believe me. Still, I believe most of our RAI drafts get a 
>single update (typically a day before the
>Chairs should notice this event and should change editors when 
>the condition arises. This has happened just a few times, 
>although I must say, fortunately more and more often in the 
>recent times.
>
>/Miguel
>--
>Miguel A. Garcia
>+34-91-339-3608
>Ericsson Spain

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Fri, 03 Oct 2008 12:47:34 +0200

I like Markus' idea. Unofficially, this way of working was done in the 
past with great success. Think of the team who worked in creating RFC 
3261. That was a critical document.

So, if we have done it in the past, it should be fairly easy to create a 
process to categorize drafts into critical or ordinary.

/Miguel

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 3 Oct 2008 08:26:53 -0500

In general, I think this is a good idea. Although, we will encounter
problems in terms of SDO specific work (we often give those items high
priority in terms of getting initial docs in front of the WG and agenda
time, but then these docs often languish - e.g., Service ID). And, of
course, we do get the categorization from several of the SDOs (e.g.,
Hannes spreadsheet that we regularly review). 

I(n SIPPING, I think it's likely to be difficult in many cases, due to
the disperate nature of the work items - hence, Dean's and other's
suggestions to split the work into separate work groups and BoFing new
work items. 

However, I will make a first pass at this concept in the spreadsheet
updates that I'm working on right now - we do have obvious priority
items. Although, again some of our priorities are based on other doc
dependencies, time to market in terms of folks are awaiting our solution
(versus there already being many proprietary ways, thus the potential
for a work item to impact the market is less), etc.  However, one way to
prioritize would be as others have suggested, work items that have
running code should be the highest priority. 

Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Miguel A. Garcia
Sent: Friday, October 03, 2008 5:48 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [RAI] Making RAI work better -- categorizing WG drafts

/Miguel

[email-masked] wrote:
> Hi,
> 
> Related to what Miguel and Hisham are saying and to the fact that 
> there are "too many" drafts in RAI area in progress in parallel: Has 
> it been considered that WGs could have an *official* two-level 
> categorization of WG drafts: critical vs. ordinary.
> 
> The expectation with critical drafts would be that the editor(s) 
> create updates relatively often (and if this doesn't happen, editors 
> would be reassigned), there is sufficient face-to-face time for them, 
> reviews would be focused on them etc. The ordinary drafts would run 
> with lesser expectations on update cycle, agenda slots and so on. They

> would be the typical cases where 2-4 people work on them while others 
> wait for WGLC to read them. It would also be that there could be only 
> max N critical drafts in WG or area at the same time. On the other 
> hand, ordinary drafts could be taken more easily.
> 
> In some sense this kind of categorization is done in any case, but 
> would it help to make it more official by briefly describing the 
> criteria and expectations. At least now different people may have very

> different views on which documents are essential in the WG, and it 
> seems that it is hard to get some work done faster than the other. The

> tricky thing would be to determine which drafts are critical and which

> are not, but I suppose the normal consensus process would apply.
>  
> Markus
> 
> 

>> ext Miguel A. Garcia

>> twice between IETF cycles. This isn't hard, believe me. Still, I 
>> believe most of our RAI drafts get a single update (typically a day 
>> before the

---

From: <[email-masked]>
Date: Fri, 3 Oct 2008 16:48:57 +0300

Hi,

Mary Barnes wrote: 

> 
>6) Interfacing with other SDOs is not always optimal.  
>Obviously, in one sense, it's a good thing to have our 
>standards being used by other SDOs, the problem comes when the 
>requirements come in at the final hour (in terms of SDO 
>deadlines) and it does take WG and editor cycles to address 
>these requirements.
>

<snip>

>
>3) Recruit more resources to contribute to work items.

I have quite a lot of experience with the other SDO's interfacing with
IETF in RAI related protocols. One of the biggest problems, which is
related to Mary's two points above, is that we still should get more of
the people working on those SDOs to contribute directly to IETF.
Currently the situation is often that there are many people e.g. in 3GPP
working on something that is important for them. Then they realize that
some of the work actually needs to be done in IETF, but only a small
fraction of the people (or even totally different people -- in which
case the whole point of what the other SDO really wants and *why* may
get convoluted) come to IETF to work with the issue. This is mostly what
companies having people both in IETF and those other SDOs should fix,
but based on my experience it is not improving. This leads to
frustration on both sides.

I don't unfortunately have good solutions to offer, except that we
should think how to encourage more participation. Perhaps the
two-category approach to drafts could be used here as well. IETF could
regularly inform that some drafts with SDO dependency have been
assigned/dropped to a lower priority category, due to lack of
contribution, and would solicit more activity to make the work move
faster. But somehow we should also show to such new contributors that
their activity can make a difference. 

Markus

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 3 Oct 2008 13:19:58 -0400

I tend to agree with Lars, Mary, Dean, and others on the scope reduction
point.  Several RAI WGs are quite large and wide in scope.  It would be
helpful to narrow scopes, create some focused new WGs as needed, and try
to increase focus.

Jason 

> Behalf Of Lars Eggert
> Sent: Wednesday, October 01, 2008 4:18 AM
> To: ext Cullen Jennings
> Cc: [email-masked]
> RAI was created by collecting together related WGs that used 
> to be in other areas, mostly in TSV. In hindsight, the split 
> has worked out extremely well overall, but there may be one 
> or two WGs or at least larger work items that could move 
> somewhere else, thereby reducing load a bit.
> 
> A concrete example that I've mentioned to some folks is the 
> RTP part of AVT, which to me at least could as well become a 
> TSV-area work item somewhere. (Especially if AVT should 
> decide to start work on some major new version of RTP.) 
> SIGTRAN might be another example. Other such work items might 
> exist where RAI intersects with other areas.
> 
> Note that I'm not pushing for any of this to happen, I'm 
> merely bringing it up as a possibility for discussion, since 
> you asked for input.
> 
> Lars
>

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 3 Oct 2008 13:37:49 -0400

> If we _do_ add more groups, I suggest we focus on charters 
> that can conceivably complete--and close down. We've 
> developed a culture of open-ended work groups. That's not 
> what work groups are for--that's what _areas_ are for.

This is an excellent point I think.  It is difficut to apply this in
practice sometimes, however, due to document editors having other
priorities that delays I-D revisions.  In these cases, WG chairs perhaps
need to be more aggressive about replacing editors to keep work moving.
We also can improve the distribution of workload by encouraging and
supporting document editors that are new to the community or are less
frequent contributors -- as an effort to widen the pool of contributors
overall. 

In my own (limited) experience trying to pull in people who are not
regular contributors, they often feel they lack the knowledge of some of
the more prodigious RAI doc authors and just need support and
encouragement.  

If we agree that getting more authors and editors that are outside of
the group of regulars, then we should actively make this an RAI-wide
priority, and we should talk about it a great deal at IETF 73 so people
understand why we're doing it, support it, and it encourages people to
start to step up.  I believe we will then be able to slowly gain more
contributors and, at the same time, those in my microphone queue may be
a bit more gentle with these less experienced contributors*.

Jason

* Do not underestimate the fact that many potential contributors find
presenting and defending drafts for the first time terribly intimidating
- many among our community are more comfortable spending time with
computers than with people.  ;-)
_______________________________________________
RAI mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rai

---

From: Randall Gellens <[email-masked]>
Date: Thu, 2 Oct 2008 15:07:19 -0700

At 11:15 AM -0500 10/1/08, Ben Campbell wrote:

>  [Splitting out one of Mary's points that I think is too important 
> to be buried in all the other controversy]
>
>>  rather than an exception. Certainly, it's a good thing ...
>
> decisions. As a prior editor of a controversial work group item, a 
> big part of my pain was around having the same arguments keep 
> coming back with no new information, but with the work group 
> responding differently to them each time.

Speaking generally of my IETF experience (that is, not specifically 
to RAI groups), previously-considered issues often get raised again, 
sometimes by new people, sometimes by people forgetting that an issue 
was already discussed, and sometimes because people's views change as 
their experience changes.  In some cases, and in some groups, it's 
rare for a decision to change, because the issue seems fairly clear 
to enough people that overall consensus doesn't change.  (An example 
might be DRUMS, where old issues kept getting raised again, but 
consensus didn't change.)  But in other situations, the issue isn't 
as clear, and the decision really comes down to which specific people 
happen to be paying attention at the moment.  Ask the same question 
an hour later and likely get a different answer.

>  It's very difficult to go back over the fossil record and say "back 
> on XXX date, someone made the exact argument, and the work group 
> email archives that are hard to search, wg minutes that look much 
> more sketchy a year down the road than they seemed at the time of 
> publication, and the conflicting memories of participants. Some 
> sort of process/tool for capturing and organizing consensus points 
> might be useful here.

I think your point about email threads being hard to search is an 
important observation.  I've certainly had the experience of 
remembering that an issue had been discussed, but not being able to 
easily find the specific discussion (perhaps because the exact words 
I'm using as search terms weren't used then, or because the words 
have too many other occurrences).   So, I'm not sure how much new 
processes or tools can really help.

>  deadline - my reading when they're posted is often very cursory.

It's nice to read that I'm not the only one guilty of this!

>  sometimes pretend the contrary).

Indeed so.  A good point.

>  problem.

Indeed.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
There are advantages to having a sane person run a government.
                            --Character in TV series "Wiseguy"
_______________________________________________
RAI mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rai

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Mon, 6 Oct 2008 18:00:04 +0200

Hanging on the last mail in the thread, and not specifically replying to
that rather than any other.

I think people have missed the main issue. The IETF structure of working
groups and indeed the overall IETF architecture is built around defining
a relatively small protocol for each function, and then allocating that
protocol to a working group.

SIP does not fulful that model, and therefore all talk of separating out
further working groups to discuss SIP is doomed to failure. All you do
is divide the people that are attempting to work on that one protocol
into multiple shared entities where they all try and work in these
multiple working groups, with the downside that people fail to
understand which group they should communicate with in order to solve a
particular problem.

Examples of this include:

-	the protocol is too big to reissue, so we seem unable to correct
faults. Other protocols roll in changes and reissue every few years.

-	we have no objective of following the IETF process to obtain
draft, because people regard it as too big and therefore requiring too
many resources to sucessfully achieve.

Therefore we need to do one of two things:

-	Rearchitect SIP so that it conforms to the IETF model. This
means splitting it into multiple individual protocols, each fulfulling
the rules of a protocol in their own right, e.g. coding rules,
compatibility rules, state machines that act independently of each
other, etc. Inherently this means a replacement for SIP that is not
compatible with SIP 2.0. Given that, I think it stands very little
chance of success at this point of time. Resources are fully committed
to deploying existing SIP, and people will not thank us for doing what
is essentially a U turn on the protocol.

-	Change or modify the working procedures to deal with the
elephant we have created. Again I suspect we have some fundamental
problems here, but I would favour at least the following:

	a)	consolidation of WG rather than splitting, and give them
more time. Note that part of the excuse of splitting the working groups
was to get over the rule that WG could have more than two sessions. We
should scrap that rule. In some ways the last thing we want is more
chairmen - what we need is potentially a single point of contact of the
documentation in progress, and then find some way of offloading some of
the chair tasks.

	b)	we need to find a way to get corrections and extensions
into the protocol in a more flexible manner. Smaller protocols do this
by republishing frequently - other SDOs republish their large
specifications as often as every three months. They do this by meeting
in a single session for up to a week. Frequently it takes an AD longer
to even open the document after a publish request than three months. 

Note that I do accept many of the problems identified prior in this
thread are valid. Particularly we do seem to have had a problem of
consensus building, and then sticking to that consensus.

Regards

Keith

> Behalf Of Livingood, Jason
> Sent: Friday, October 03, 2008 6:38 PM
> To: Ben Campbell; Mary Barnes
> Cc: [email-masked]
> This is an excellent point I think.  It is difficut to apply 
> this in practice sometimes, however, due to document editors 
> having other priorities that delays I-D revisions.  In these 
> cases, WG chairs perhaps need to be more aggressive about 
> replacing editors to keep work moving.
> We also can improve the distribution of workload by 
> encouraging and supporting document editors that are new to 
> the community or are less frequent contributors -- as an 
> effort to widen the pool of contributors overall. 
> 
> In my own (limited) experience trying to pull in people who 
> are not regular contributors, they often feel they lack the 
> knowledge of some of the more prodigious RAI doc authors and 
> just need support and encouragement.  
> 
> If we agree that getting more authors and editors that are 
> outside of the group of regulars, then we should actively 
> make this an RAI-wide priority, and we should talk about it a 
> great deal at IETF 73 so people understand why we're doing 
> it, support it, and it encourages people to start to step up. 
>  I believe we will then be able to slowly gain more 
> contributors and, at the same time, those in my microphone 
> queue may be a bit more gentle with these less experienced 
> contributors*.
> 
> Jason
> 
> * Do not underestimate the fact that many potential 
> contributors find presenting and defending drafts for the 
> first time terribly intimidating
> - many among our community are more comfortable spending time 
> with computers than with people.  ;-)

---

From: Henry Sinnreich <[email-masked]>
Date: Mon, 06 Oct 2008 09:38:11 -0700

Keith,

Wow! I don't believe my eyes and agree with your basic assessment.

> further working groups to discuss SIP is doomed to failure.

Where I do disagree is that either the technology basics or the market care
about the IETF SIP/RAI process. We have to change the process (running code,
measurements of results, advanced application software, etc.).

> Particularly we do seem to have had a problem of

Why would anyone care about consensus by a group of people who have happened
to have the resources to attend IETF SIP meetings? The very people who have
created the situation you describe?

The better protocols and software are not selected by any consensus
anywhere. Group think will also kill any possible innovation as well.

Henry

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 6 Oct 2008 14:22:57 -0400

I will note that the HTTPbis effort seems to be splitting RFC 2616  
into about half a dozen pieces. I'm also not sure that other core  
application standards get re-issued all that often. We're now seeing  
the third revision of RFC 822 (RFC 5321 & 5322). RFC 2822 was  
published in 2001, RFC 822 in 1982.

A larger WG could work with additional delegation, e.g., having small  
review committees, so that the WG chair would have more of a process  
supervision role, but not necessarily get involved with each document.  
This is similar to the way that large scientific conferences are  
organized - the technical program chair doesn't read every paper and  
relies on various committees to select and review papers. The chair  
may review the reviews.

The notion that two individuals (either for a WG or a whole area) can,  
between them, read and review every document just doesn't scale. In  
academia, tenure committees don't review every paper that somebody has  
written. In industry, one would hope that a CEO of anything except the  
smallest company doesn't get involved in decisions about product  
packaging (Steve Jobs may be an exception). In legal systems, appeals  
courts don't review every piece of evidence or re-hear the witnesses.

Otherwise, there's the famous bicycle shed problem in management. (See http://en.wikipedia.org/wiki/Color_of_the_bikeshed)

Henning

---

From: Dean Willis <[email-masked]>
Date: Mon, 6 Oct 2008 23:31:39 -0500

On Oct 6, 2008, at 1:22 PM, Henning Schulzrinne wrote:
>
> A larger WG could work with additional delegation, e.g., having  
> small review committees, so that the WG chair would have more of a  
> process supervision role, but not necessarily get involved with each  
> document. This is similar to the way that large scientific  
> conferences are organized - the technical program chair doesn't read  
> every paper and relies on various committees to select and review  
> papers. The chair may review the reviews.
>

In IETF, we call that superdelegation an "area", which has "area  
directors". Individual topic sessions are "working groups", which have  
"chairs".

Imagine that each working group is expected to supervise one to three  
technical papers.

The working groups recommend papers up to the area, and the area  
directors selectively review the production.

--
Dean

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 7 Oct 2008 10:55:34 -0400

Concrete Proposal:

There is one SIP group.  It has two chairs.
There is a technical directorate: It consists of around 6-8 people.  They
are the folks like Jonathan, Henning, Paul Kizviat, etc. who have the big
picture.

There are another 5-8 subgroup leaders.  These are document shepherds.  We
try to flexibly change the scope of the subgroups so that there is roughly
even amount of work for the subgroup leaders.  There is one mailing list,
but see below.

A document is proposed.  If it seems interesting, a slot is assigned during
a meeting, and we have the usual process for accepting it.  Once accepted,
it's assigned to a subgroup leader.

Documents are assigned a keyword.  You submit an email to the (single) list
using a process that gets the subgroup name and the document keyword in the
Subject.  This allows flexible filtering for WG members.

Before WGLC, the document is submitted to the technical directorate.  The
directorate recommends changes and generally vets the mechanism in the
context of the whole protocol.  The directorate can effectively veto, but
there is an appeal process. 

The subgroup leaders move the documents assigned to them through the
process.

Documents normally have 12 months to make it through the WG.  A document
that is not WGLC in 12 months must be reauthorized.

There is a weekly conference call. Document authors request slots in the
call to move open issues through.  They forward requests to subgroup
leaders, who prioritize, and work with the chairs to schedule the calls.
Agenda's are frozen at least one week in advance.

SIP sessions at meetings are one entire day, say Tuesday.  Documents
normally only get slots in 3 circumstances:
1. Chairs decide to have the above "acceptance" discussion
2. Subgroup leaders propose, and chairs decide, that some open issue
requires f2f WG discussion time. The bar for "open issues" is high.  Slots
might be 15-20 min.
3. The technical directorate vetoes, and the document author appeals.  The
work group decides, and the threshold is high
4. Documents that time out (12 months) must be reauthorized.  The threshold
is high.

There is a living document.  It has 3-4 editors.  Think of it as RFC3261 +
"Hitchhiker's Guide" on steroids.  When a document exits the process as an
RFC, this document is updated.  It has a summary of the mechanism, cast in
the context of the entire protocol.  With cross references and tables, a new
document adds between 1-4 pages to this document.  It's not an RFC (it
doesn't ever go through the IESG or RFC Editor).  You have to be an editor
on this document before being considered for the technical directorate.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean
Willis
Sent: Tuesday, October 07, 2008 12:32 AM
To: Henning Schulzrinne
Cc: [email-masked]
Subject: Re: [RAI] Making RAI work better

--
Dean

---

From: Ben Campbell <[email-masked]>
Date: Tue, 7 Oct 2008 10:06:01 -0500

Other than some procedural differences, you've just described an  
_area_, if not the entire IETF :-)

---

From: "Mary Barnes" <[email-masked]>
Date: Tue, 7 Oct 2008 10:13:16 -0500

And, in looking at the procedural differences, the primary one that I
see is regular conference calls for more work items. In the SIPPING WG,
the overload design team has those and in the past these are what helped
to progress the configuration framework. We have tried to keep the
deliverables within a one year time frame, but that is often not
feasible due to many factors - lack of feedback from the WG, lack of
cycles for the document editors, slowness in feedback from chairs/AD in
terms of the the direction of the work in the case that issues arise.  

Personally, I think we already have the directorate approach implemented
(somewhat) in the form of review teams for RAI (and SIPPING WG) and I
think loosely in other WGs - i.e., chairs often call upon specific
experts to review work.  However, this approach too runs into the top
issue already identified in past threads - resources.

Mary.   

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ben Campbell
Sent: Tuesday, October 07, 2008 10:06 AM
To: Brian Rosen
Cc: [email-masked]
Subject: Re: [RAI] Making RAI work better

Other than some procedural differences, you've just described an _area_,
if not the entire IETF :-)

On Oct 7, 2008, at 9:55 AM, Brian Rosen wrote:

> are the folks like Jonathan, Henning, Paul Kizviat, etc. who have the 
> big picture.
>
> There are another 5-8 subgroup leaders.  These are document shepherds.

> We try to flexibly change the scope of the subgroups so that there is 
> roughly even amount of work for the subgroup leaders.  There is one 
> mailing list, but see below.
>
> A document is proposed.  If it seems interesting, a slot is assigned 
> during a meeting, and we have the usual process for accepting it.  
> Once accepted, it's assigned to a subgroup leader.
>
> using a process that gets the subgroup name and the document keyword 
> in the Subject.  This allows flexible filtering for WG members.
>
> Before WGLC, the document is submitted to the technical directorate.  
> The directorate recommends changes and generally vets the mechanism in

> the context of the whole protocol.  The directorate can effectively 
> veto, but there is an appeal process.
>
> Documents normally have 12 months to make it through the WG.  A 
> document that is not WGLC in 12 months must be reauthorized.
>
> There is a weekly conference call. Document authors request slots in 
> the call to move open issues through.  They forward requests to 
> subgroup leaders, who prioritize, and work with the chairs to schedule

> the calls.
> 1. Chairs decide to have the above "acceptance" discussion 2. Subgroup

> leaders propose, and chairs decide, that some open issue
> 3. The technical directorate vetoes, and the document author appeals.

> The work group decides, and the threshold is high 4. Documents that 
> time out (12 months) must be reauthorized.  The threshold is high.
>
> "Hitchhiker's Guide" on steroids.  When a document exits the process 
> as an RFC, this document is updated.  It has a summary of the 
> mechanism, cast in the context of the entire protocol.  With cross 
> references and tables, a new document adds between 1-4 pages to this 
> document.  It's not an RFC (it doesn't ever go through the IESG or RFC

> Editor).  You have to be an editor on this document before being 
> considered for the technical directorate.
>
> Brian
>

>> supervision role, but not necessarily get involved with each

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 7 Oct 2008 11:21:57 -0400

Not really.

Subgroups aren't WGs.  They don't have separate agendas, charters, mail
lists, etc.  They are simply a mechanism for evenly parsing out document
shepherd duties.

There is no technical directorate in an area

There is no "big picture" living document in an area

We don't do conference calls.

It does really fit the definition of one (big) work group

Brian
-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Tuesday, October 07, 2008 11:06 AM
To: Brian Rosen
Cc: [email-masked]
Subject: Re: [RAI] Making RAI work better

On Oct 7, 2008, at 9:55 AM, Brian Rosen wrote:

> during
> in the
> document
> the
> as an

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 7 Oct 2008 11:31:10 -0400

There is a big difference in a review team organized for a single document
and a standing directorate.

Differentiating between a work group co-chair, which is a management job and
a document shepherd, which is more technical and less management, is also
significant.  More document shepherds will help the process, and if that's
ALL you do, it should be closer to the hours per week instead of days per
week that chairs encounter.  Getting rid of the façade of multiple WGs with
independent charters is also a process change.

If the year deadline had teeth, it becomes more important.  The point of the
"re-up" is to put teeth in the deadline.  You can "try" to move documents,
but without a forcing function, it doesn't happen.  I would give chairs
-some- flexibility here.

Brian
-----Original Message-----
From: Mary Barnes [mailto:[email-masked]] 
Sent: Tuesday, October 07, 2008 11:13 AM
To: Ben Campbell; Brian Rosen
Cc: [email-masked]
Subject: RE: [RAI] Making RAI work better

Mary.

---

From: "Mary Barnes" <[email-masked]>
Date: Tue, 7 Oct 2008 10:32:14 -0500

I agree with Ben that this is still really fairly equivalent to our
current structure. Hitchhiker's guide is somewhat of a big picture
document. And, the procedure for making it living means that we just
publish a bis annually and obsolete the previous one.  

Per my note, we have conference calls for selected areas and I agree
100% that this would allow us to be more effective, but again, this is
likely a huge resource issue. One example I have of that is that a lead
for one of the design teams was a member of the other design team and
ended up no longer being able to serve as editor for a document in the
2nd design team. Our biggest issue is resources - after that I do agree
it's an issue of organization and focus. 

In my mind, the big work group approach brings us eerily close to CN1 in
3GPP. And, while I'm on the topic of other SDOs, while I may not agree
with their architecture approaches, they do show us that no model of
dividing or scheduling work is optimal.  And, in terms of volumes of
documents, in the early days of GSM, I'm recalling folks having a shelf
full (standard Herman Miller 4 ft cubical shelf) of documents. And, in
those days we didn't have the power of the search tools we have today. 

And, while I'm not against some positive changes, I sense we may well
get into the "the more things changes, the more they stay the same"
mode.

Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian Rosen
Sent: Tuesday, October 07, 2008 10:22 AM
To: 'Ben Campbell'
Cc: [email-masked]
Subject: Re: [RAI] Making RAI work better

Not really.

Brian

---

From: "Mary Barnes" <[email-masked]>
Date: Tue, 7 Oct 2008 10:38:35 -0500

I agree that ADs using the PROTO process more would be helpful. That said, in my experience chairs quite often do allow the primary editors to do a lot of the shepherding once the AD gets the doc. 

Per the façade point, see my note on this looking far more like CN1 in 3GPP and my opinion that there really is not an optimal way of organizing work.  I personally can't see this big WG being more effective than what we have now - indeed I'm in the camp of more crisply defining deliverables and closure dates for current WGs, in particular SIP and SIPPING (per the past proposal to BoF new work items).

In SIPPING, we have done the re-prioritization in terms of docs not meeting deadlines, they go back to the end of the Q.  However, you have made a good point (that has already been discussed) is that we rarely drop work that isn't making progress. But, again, I think we're back to resources, as it's not that the work isn't important, it's just no one has the time to properly focus on it.  In my recent update of SIPPING work items, I tried to think of a way to prioritize, but I'm not certain we can do that given the variable nature of priorities - other SDOs, time to market, real code, almost done, etc. If we could find a way to prioritize these things (e.g., working code docs come first, then ttm, then almost done, then other SDOs) maybe that would help. Although, again the resource issues. 

Mary. 

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, October 07, 2008 10:31 AM
To: Barnes, Mary (RICH2:AR00); 'Ben Campbell'
Cc: [email-masked]
Subject: RE: [RAI] Making RAI work better

There is a big difference in a review team organized for a single document and a standing directorate.

Differentiating between a work group co-chair, which is a management job and a document shepherd, which is more technical and less management, is also significant.  More document shepherds will help the process, and if that's ALL you do, it should be closer to the hours per week instead of days per week that chairs encounter.  Getting rid of the façade of multiple WGs with independent charters is also a process change.

If the year deadline had teeth, it becomes more important.  The point of the "re-up" is to put teeth in the deadline.  You can "try" to move documents, but without a forcing function, it doesn't happen.  I would give chairs
-some- flexibility here.

Brian
-----Original Message-----
From: Mary Barnes [mailto:[email-masked]]
Sent: Tuesday, October 07, 2008 11:13 AM
To: Ben Campbell; Brian Rosen
Cc: [email-masked]
Subject: RE: [RAI] Making RAI work better

And, in looking at the procedural differences, the primary one that I see is regular conference calls for more work items. In the SIPPING WG, the overload design team has those and in the past these are what helped to progress the configuration framework. We have tried to keep the deliverables within a one year time frame, but that is often not feasible due to many factors - lack of feedback from the WG, lack of cycles for the document editors, slowness in feedback from chairs/AD in terms of the the direction of the work in the case that issues arise.  

Personally, I think we already have the directorate approach implemented
(somewhat) in the form of review teams for RAI (and SIPPING WG) and I think loosely in other WGs - i.e., chairs often call upon specific experts to review work.  However, this approach too runs into the top issue already identified in past threads - resources.

Mary.   

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben Campbell
Sent: Tuesday, October 07, 2008 10:06 AM
To: Brian Rosen
Cc: [email-masked]
Subject: Re: [RAI] Making RAI work better

Other than some procedural differences, you've just described an _area_, if not the entire IETF :-)

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Tue, 7 Oct 2008 12:09:32 -0400

WRT the Hitchhiker's Guide:

I have heard folks say that they "support SIP".  What exactly does that
mean?

I usually ask if they mean just RFC 3261?  Or that, plus some
permutation of the 50-odd related RFCs?

In other SDOs that have fairly large systems, they frequently have
Revision numbers that identify some set of features that are included in
either mandatory or optional fashion, with operators using that to
specify what they need.

Would the H-Guide play that sort of role:  SIP-2008, SIP-2009, etc. ?

Seems like some sort of baselining would help.

Mike

> Behalf Of Mary Barnes
> Sent: Tuesday, October 07, 2008 11:32 AM
> To: Brian Rosen; Ben Campbell
> Cc: [email-masked]
> I agree with Ben that this is still really fairly equivalent 
> to our current structure. Hitchhiker's guide is somewhat of a 
> big picture document. And, the procedure for making it living 
> means that we just publish a bis annually and obsolete the 
> previous one.  
> 
> Per my note, we have conference calls for selected areas and 
> I agree 100% that this would allow us to be more effective, 
> but again, this is likely a huge resource issue. One example 
> I have of that is that a lead for one of the design teams was 
> a member of the other design team and ended up no longer 
> being able to serve as editor for a document in the 2nd 
> design team. Our biggest issue is resources - after that I do 
> agree it's an issue of organization and focus. 
> 
> In my mind, the big work group approach brings us eerily 
> close to CN1 in 3GPP. And, while I'm on the topic of other 
> SDOs, while I may not agree with their architecture 
> approaches, they do show us that no model of dividing or 
> scheduling work is optimal.  And, in terms of volumes of 
> documents, in the early days of GSM, I'm recalling folks 
> having a shelf full (standard Herman Miller 4 ft cubical 
> shelf) of documents. And, in those days we didn't have the 
> power of the search tools we have today. 
> 
> And, while I'm not against some positive changes, I sense we 
> may well get into the "the more things changes, the more they 
> stay the same"
> mode.
> 
> Mary. 
> 
> Behalf Of Brian Rosen
> Subgroups aren't WGs.  They don't have separate agendas, 
> charters, mail lists, etc.  They are simply a mechanism for 
> evenly parsing out document shepherd duties.
> 
> > There is a technical directorate: It consists of around 6-8 
> people.   
> > They
> 2. Subgroup
> > requires f2f WG discussion time. The bar for "open issues" 
> is high.   
> > Slots
> > might be 15-20 min.

---

From: Dan York <[email-masked]>
Date: Tue, 7 Oct 2008 12:22:37 -0400

Mike,

This is largely what the SIP Forum has been aiming to do with its  
"SIPconnect" initiative:

http://www.sipforum.org/content/view/290/290/

Although that is currently only focused on the scope of "SIP trunking"  
between premise equipment and a SIP Service Provider.

I think the challenge is that there are so many different and varied  
uses of SIP that it becomes hard to truly define what it means to  
"support SIP".  I do agree there's value in defining a set of SIP RFCs  
for interop purposes, but is that something that we can do within the  
IETF? Or is that something another group should do? (Such as what SIP  
Forum is doing or what the WiFi Alliance has done with IEEE 802.11  
specifications.)

Dan

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 7 Oct 2008 11:25:12 -0500

One might argue that the IETF would be a better place to do this 
than the SIP Forum.

> Behalf Of Dan York
> Sent: Tuesday, October 07, 2008 09:23
> To: Mike Hammer (hmmr)
> Cc: [email-masked]
> This is largely what the SIP Forum has been aiming to do with 
> its "SIPconnect" initiative:
> 
> I think the challenge is that there are so many different and 
> varied uses of SIP that it becomes hard to truly define what 
> it means to "support SIP".  I do agree there's value in 
> defining a set of SIP RFCs for interop purposes, but is that 
> something that we can do within the IETF? Or is that 
> something another group should do? (Such as what SIP Forum is 
> doing or what the WiFi Alliance has done with IEEE 802.11
> specifications.)
> 
> Dan
> 
> 
> > I have heard folks say that they "support SIP".  What exactly does 
> > that mean?
> >
> > Revision numbers that identify some set of features that 
> are included 
> > in either mandatory or optional fashion, with operators 
> using that to 
> > specify what they need.
> >
> >> Mary Barnes
> >> 100% that this would allow us to be more effective, but 
> again, this 
> >> is likely a huge resource issue. One example I have of 
> that is that a 
> >> lead for one of the design teams was a member of the other design 
> >> team and ended up no longer being able to serve as editor for a 
> >> document in the 2nd design team. Our biggest issue is resources - 
> >> after that I do agree it's an issue of organization and focus.
> >>
> close to CN1 
> >> in 3GPP. And, while I'm on the topic of other SDOs, while 
> I may not 
> >> agree with their architecture approaches, they do show us that no 
> >> model of dividing or scheduling work is optimal.  And, in terms of 
> >> volumes of documents, in the early days of GSM, I'm 
> recalling folks 
> >> Subgroups aren't WGs.  They don't have separate agendas, charters, 
> >> mail lists, etc.  They are simply a mechanism for evenly 
> parsing out 
> >> document shepherd duties.
> >>
> >>> leaders propose, and chairs decide, that some open issue requires 
> >>> f2f WG discussion time. The bar for "open issues"
> >> is high.
> >>> Slots
> >>> might be 15-20 min.

---

From: "Mary Barnes" <[email-masked]>
Date: Tue, 7 Oct 2008 11:22:34 -0500

My experience is that when folks say they support SIP, they usually have
some sort of document that describes their level of support, along with
references to all the docs they purport to support. Also, I do think
SIPit provides a good summary of what is really supported.  Maybe we
just do a 3261bis and remove everything else. 

Also, note Henry's doc on "simple" SIP:
http://tools.ietf.org/id/draft-sinnreich-sip-tools-03.txt
I'd be curious to know how many implementations closely match that. 

That all said, it likely is quite reasonable and workable to just rev
H-guide regularly. Also, maybe have a few companion guides (while I
didn't initially agree with the need for one in BLISS, it might be
useful there in the end). Also, there is a doc that describes all the
3GPP p-headers:
http://tools.ietf.org/id/draft-drage-sipping-rfc3455bis-01.txt

Mary. 

-----Original Message-----
From: Mike Hammer (hmmr) [mailto:[email-masked]] 
Sent: Tuesday, October 07, 2008 11:10 AM
To: Barnes, Mary (RICH2:AR00); Brian Rosen; Ben Campbell
Cc: [email-masked]
Subject: RE: [RAI] Making RAI work better

Mike

> likely a huge resource issue. One example I have of that is that a 
> lead for one of the design teams was a member of the other design team

> and ended up no longer being able to serve as editor for a document in

> the 2nd design team. Our biggest issue is resources - after that I do 
> In my mind, the big work group approach brings us eerily close to CN1 
> in 3GPP. And, while I'm on the topic of other SDOs, while I may not 
> volumes of documents, in the early days of GSM, I'm recalling folks 
> shelf) of documents. And, in those days we didn't have the power of 
> the search tools we have today.
> 
> mail lists, etc.  They are simply a mechanism for evenly parsing out

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Tue, 7 Oct 2008 12:39:53 -0400

My concern would be that SIP could be balkanized if every group using
SIP (even within the IETF) came up with its own macro-SIP documents.  It
also begs the question about how E2E SIP will be moving forward.

Mike

> Sent: Tuesday, October 07, 2008 12:23 PM
> To: Mike Hammer (hmmr); Brian Rosen; Ben Campbell
> Cc: [email-masked]
> My experience is that when folks say they support SIP, they 
> usually have some sort of document that describes their level 
> of support, along with references to all the docs they 
> purport to support. Also, I do think SIPit provides a good 
> summary of what is really supported.  Maybe we just do a 
> 3261bis and remove everything else. 
> 
> That all said, it likely is quite reasonable and workable to 
> just rev H-guide regularly. Also, maybe have a few companion 
> guides (while I didn't initially agree with the need for one 
> in BLISS, it might be useful there in the end). Also, there 
> is a doc that describes all the 3GPP p-headers:
> I have heard folks say that they "support SIP".  What exactly 
> does that mean?
> 
> In other SDOs that have fairly large systems, they frequently 
> have Revision numbers that identify some set of features that 
> are included in either mandatory or optional fashion, with 
> operators using that to specify what they need.
> 
> again, this is

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 7 Oct 2008 13:06:04 -0400

The crucial difference between the conference process and the IETF  
process is a time-bound: There's typically at most a week or two  
between the closing of the review process and the decision, and a very  
definite deadline after which your (accepted) paper will no longer be  
published if you don't produce an update. We see that the 3-times-a- 
year I-D deadlines seem pretty successful, compared to anything else,  
at producing progress. Maybe we need more of that kind in the later  
stages, in the spirit to what Brian suggested. Default time-outs may  
also help, i.e., if there's no objection by management within a  
certain time period, it passes to the next stage.

Re-labeling working groups and reducing the number of chairs seems  
like a secondary issue; we don't seem to suffer from too much  
management capacity.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 7 Oct 2008 14:03:02 -0400

We seem to have identified several different reasons for limited  
(reviewer and author/editor) resources:

- Not enough people participate (or are asked/encouraged) to  
participate;

- Active participants get involved in too many documents;

- Active participants get discouraged due to the long process delays,  
late surprises and the mental swap-in costs that go along with that.

Concrete proposals and experiments to help with these might be useful,  
rather than just relabeling the org-chart. (I suspect that the third  
issue has a strong causal relationship with the first two.)

Henning

On Oct 7, 2008, at 11:38 AM, Mary Barnes wrote:

> But, again, I think we're back to resources, as it's not that the  
> work isn't important, it's just no one has the time to properly  
> focus on it.  In my recent update of SIPPING work items, I tried to  
> think of a way to prioritize, but I'm not certain we can do that  
> given the variable nature of priorities - other SDOs, time to  
> market, real code, almost done, etc. If we could find a way to  
> prioritize these things (e.g., working code docs come first, then  
> ttm, then almost done, then other SDOs) maybe that would help.  
> Although, again the resource issues.
>

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 7 Oct 2008 16:31:45 -0400

If the SIPConnect work were in the IETF it would never get done at all or
simply take too long. That is the problem this thread is confronting.

IETF doesn't do "profiles" "versions" etc. SIPforum can and that is what
SIPconnect is, a "profile" of the existing SIP standards specific to the
problem of SIPtrunking.

Those of us interested in the SIP Trunking problem realized that it had to
be addressed outside the scope of the IETF ( though we closely follow IETF
procedure ) if the commercial needs of the market were addressed with a
implementable specification in a rational and timely fashion. 

>  Francois Audet
>  Sent: Tuesday, October 07, 2008 12:25 PM
>  To: Dan York; Mike Hammer (hmmr)
>  Cc: [email-masked]
>  One might argue that the IETF would be a better place to do thise
>  than the SIP Forum.
>  
>  
>  
>  charters,
>  requires

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 7 Oct 2008 16:33:36 -0400

>  Mike Hammer (hmmr)
>  Sent: Tuesday, October 07, 2008 12:40 PM
>  To: Mary Barnes; Brian Rosen; Ben Campbell
>  Cc: [email-masked]

E2E SIP what is that?  :-)  I heard about that concept once ...

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Tue, 7 Oct 2008 17:35:25 -0600

This thread has gone in many interesting directions, from scope
management, to project management with deliverables, timelines and
stakeholders to discussing whether IETF should do system specs or
profiles.

A few random comments:
 - first, SIP and RAI are victims of their own success: a lot of
   complex things have been accomplished, published and implemented
   with SIP.  Credits should be given to the authors, contributors
   and to developers for sure.

 - folks want to do everything with SIP: anything is a dialog/session
   from key presses, events to IPsec tunnels and may be DTMF one day,
   let alone the assertion of pstn identities and other weird things.
   There lies the problem.  Saying no to new things is not easy when
   you have a group hum in favor of the work item, and limited folks
   who later contribute... 

 - SIP is a big but other groups find ways to fix and issue new
   versions:  look at the httpbis wg and how HTTP is being broken into
   multiple parts.  Look at the long lists of authors there and the
   number of pages.  Not sure this would work but seems interesting when
   SIP came from ... HTTP? 
   Having said that, taking months of several people's life to
   issue a revision of SIP is considerable and it does help get cycles
   for other work.

 - Agile vs. the old software dvpt process:
   Folks write requirement docs (for years), then define a solution
which
   by the time it gets implemented is sometimes too late. It would be
   good to see a more iterative process where something comes out
faster,
   and gets revised.
   What would have been wrong with call diversion header = RFC X,
   History=RFC Z?  easier said that done, I admit, but the "customers of
   SIP" are the implementers who cannot wait to ship products.  They
   are not SDOs that can wait on liaison responses and an RFC number
   for a future spec revision.

 - What is needed the most?  A hitchhiker's guide for external
   consumption or a SIP roadmap for internal RAI prioritization?
   Given the huge body of work and the interdependencies, I personally
   find it hard to understand what item is more important to the group
   to get done than others.  Everyone has its own weighting algorithm
   but I think it would help to say: in the next 12 months, "this" is
   what needs to get out; agree on it; track it, say no to new
   things or agree to drop existing things.  
   
Finally...
While everyone has witnessed dysfunctions, I'm not sure a major re-org
will change things.  As we had discussed in the past, an option may be
good to test a few things here and there (conf calls in one group or
for some deliverables, roadmap there, strong prioritization scheme
here, scope cutter roles, directorate, etc.).  Any solution will
likely require some iterations and motivated doers -- not managers imo.

Jean-Francois.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 08 Oct 2008 16:13:03 +0300

Hi,

there are a few areas where we can improve the current situation: 
editing resources, management resources, management structure, and 
processes.

When I read some of the emails in the thread proposing to mainly focus 
on the last three areas, I could not help thinking of the joke about the 
Japanese Rowing team (I am sure all of you have heard it before). The 
links below contain two variations of the joke:

http://www.ahajokes.com/japan_jokes.html
http://www.jokething.com/jokes/14/14064

In short, the joke is about the Japanese Rowing team, which has 8 people 
rowing and 1 person steering, competing against another team (in the 
links above is the American team but I have seen other nationalities 
used as well) that has 1 person rowing and 8 people steering. The latter 
team chooses to reorganize the boat's management structure instead of 
adding more rowers! :o)

Any time management program has participants log their activities for a 
few days to understand how much effective time a week they really have. 
Almost always, people are surprised to figure out how little effective 
time they have. The same way, we should first asses the level of 
management and editing resources we have in RAI in order to understand 
how much work we can really tackle during, say, a year within the area. 
This type of assessment will also help us understand where the 
bottlenecks are. We will be able to figure out whether, at a given 
point, we need more management resources or more editing resources.

In SIPPING, we can asses the current situation through our status 
spreadsheets, and it seems that what we need most of the time is more 
editing resources. In other WGs the situation could be different; the 
bottleneck could be the chairs.

This type of assessment is nothing new, by the way. The IESG has been 
working on something similar for the whole IETF. For a given draft, the 
following tool gives you a rough idea of where delays come from.

http://www.arkko.com/tools/lifecycle/drafts.html
See the following link for an example:
http://www.arkko.com/tools/lifecycle/draft-ietf-sipping-config-framework-timing.html

The advantage of performing an assessment (even if it is a very simple 
one) of the situation is that we will avoid going through the same 
discussions we had a few years ago (and we are having again in this 
thread), where some people think we need more editors and some people 
think we need more chairs but nobody provides data backing up their 
statements.

There are some things we can do in the four areas above:

1) Editing resources:

We should both increase the amount of resources and use them in a better 
way.

Increase the amount of editing resources:
We can restart the mentoring program we used some time ago. A junior 
editor works with a more senior editor on a spec in order to get up to 
speed as soon as possible. This type of arrangement has worked well with 
some people but has failed with others. In any case, I think we should 
continue doing it.

Use our editing resources in a better way:
o Prioritize potential work items and work on the most important ones. 
So far, we have used "hum" levels to asses the importance of different 
drafts. In an environment with a lot of ideas and little resources to 
work on them, supporting a draft should take more than just "humming". I 
think we should move to an incentive-based system where you can support 
a draft by doing something the WG needs. So, if I believe a WG should 
work on a given draft, I can review a WG item, become an editor, or 
implement the draft (i.e., running code). We would need to work out the 
details, but the basic idea is to provide incentives for people to do 
work for the WG.

o Delegate work to other areas. There are a few items we could move out 
from RAI, but I do not think the amount of work we will be able to 
delegate this way will be significant (e.g., Sigtran is still in RAI but 
is effectively dormant).

o Change editor when needed. The problem with changing editors is that 
it does not happen often enough. Therefore, if an editor is fired, he or 
she will feel offended. That is why most chairs do not change editors; 
they want to avoid personal conflicts. We should make changing editors 
part of our culture. Changing editor when the current editor does not 
have enough cycles to work on the draft needs to be perceived as the 
rule rather than the exception.

o More deadlines. We need more deadlines because deadlines drive work. 
The fact that we have three draft deadlines a year is the reason why 
most drafts get revised three times a year. If an editor misses a 
deadline, the draft losses priority. We have done this in SIPPING and is 
typically a good incentive for editors to meet those deadlines.

o Continuous measurement of interest. If a draft is not relevant any 
longer (e.g., the market went in other direction) or nobody has the time 
to work on it any longer, we should drop the draft. Burning our precious 
resources working on something that is going to be useless just because 
at some point we thought it was important is a great mistake.

o Clarify our scope. It needs to be clearer what type of work is outside 
of the scope of a given WG. For example, SIP can be used as a generic 
rendezvous mechanism for a number of applications. Do we want SIP to be 
used for anything or only for inter-personal communications?

2) Management resources:

We should both increase the amount of resources and use them in a better 
way.

Increase the amount of management resources:
We had mentoring programs for new chairs in the past. New chairs used to 
  have a more senior co-chair during a few meetings in order to get them 
up to speed as soon as possible. We should continue doing this. In any 
case, when an active editor becomes a chair, we gain management 
resources but lose editing resources. We should only do that when the 
situation we are in requires more management but has enough editors.

Use our management resources in a better way:
Secretaries: in the IETF, the chair role typically involves some 
technical work in addition to the purely administrative work. Chairs are 
supposed to understand technical discussions to a certain level and be 
aware of the trade-offs involved in the decisions the WG makes. That is 
why some technical leaders that could serve as editors end up as chairs. 
Secretaries are a good way to have these chairs delegate their 
administrative tasks. In SIPPING, we have used a secretary for many 
years and we are very happy with him.

Design teams: chairs can also delegate some functions to the leaders of 
the WG's design teams.

3) Management structure:

Part of the work of RAI is done by the same people even if it is 
distributed across different WGs. However, some WGs have their own set 
of people. That is why splitting WGs or consolidating WGs cannot be the 
solution for the whole RAI. Some WGs should be consolidated while others 
should be split. In general, we should try to:

Minimize discussions on which draft goes to which WG. This is a source 
of inefficiencies and author frustration.

Minimize inefficient transactions between WGs (e.g., when SIPPING sends 
requirements to SIP so that SIP works on a solution).

Enough face-to-face time to discuss everything. If we need more 
face-to-face time, we can remove the restriction of two-slots per WG. 
Creating a new WG just to get more slots does not seem to be the best 
solution.

Focused efforts. If we need a focused effort, we can either form a new 
WG or a new design team within an existing WG. Design teams are more 
light-weight; they can be formed more quickly and easily... but if it is 
a sufficiently scoped topic, a WG may be the right solution.

Long-lived WGs are very controversial within the IETF. There have been 
discussions within the IESG and the IAB about when they are appropriate 
and when they are not. There are advantages and disadvantages that 
should be discussed separately. My personal opinion is that some of the 
stuff we do in RAI should be done in separate WGs but having a 
long-lived WG with well-scoped design teams is useful as well (i.e., 
something like SIP nowadays, which does protocol maintenance).

4) Processes

We should continue improving our processes and providing input to the 
tools team so that our tools get better and better. Regarding a RAI 
directorate, we already have the RAI review team. Should we identify the 
need, we could form a directorate taking as a base that team fairly quickly.

My two cents...

Cheers,

Gonzalo

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 8 Oct 2008 11:09:31 -0500

> part of our culture. Changing editor when the current editor does not have 
> enough cycles to work on the draft needs to be perceived as the rule 
> rather than the exception.

We really need to figure out how to make this change something that's OK to 
suggest - status quo is that we have authors who have been made editors, 
which is a completely different skill set (something about starting vs 
finishing), and one editor revision per IETF cycle on too many drafts...

Thanks,

Spencer

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 08 Oct 2008 09:50:03 -0700

Jean-Francois (and the other contributors today),

All these are excellent points regarding the process, but where is the
running code part of the Internet logo (roughly):
"We believe in running code and rough consensus"
Also "We don't believe in kings".

Can you help me understand why my insistence on running code has been mostly
ignored in this discussion? Is the topic too painful to discuss?

Henry

---

From: <[email-masked]>
Date: Wed, 8 Oct 2008 22:01:15 +0300

Hi,

This argument about running code comes up a lot. So, it would be useful
to understand what we mean by it, and how it is expected to make any
difference in the standards process. 

To me it can mean two different kinds of things:
1.) Something like what the OAuth folks (who are setting up a BOF for
the next IETF) have. They have running code to show that their protocol
works and also they have deployment to show that it indeed solves a real
problem. 
2.) Someone has some piece of code in the lab, perhaps even open source.
Not that anyone is really using it for anything. This shows that
something actually works (if the code matches the spec...). However, it
doesn't tell if it's a good idea or if there is any use for it.

The scary thing with SIP is that stuff like SBCs, OPTIONS for NAT
keepalive, various usages of INFO etc. are clearly in category 1. So, if
we believed in our own myths, we should definitely take those things as
the core of our standards. 

On the other hand, I would really love to see any kind of running code
on things like the consent framework, SDP capability negotiation, config
framework. Those things make my head hurt and it would make me feel
better if I knew that someone had actually implemented them and showed
that they work. (I'm really glad we do have a few implementations on
ICE. Also, implementations on XCAP helped a lot in fixing issues with
such a complex protocol.)

But the very basic question remains: How exactly is running code
factored into our standards process? Does it make us adopt new WG items?
Does it make us pass WG last calls?

Markus

>Behalf Of ext Henry Sinnreich
>Sent: 08 October, 2008 19:50
>To: Jean-Francois Mule; [email-masked]
>All these are excellent points regarding the process, but 
>where is the running code part of the Internet logo (roughly):
>Can you help me understand why my insistence on running code 
>has been mostly ignored in this discussion? Is the topic too 
>painful to discuss?
>
>Henry
>
>

---

From: "Mary Barnes" <[email-masked]>
Date: Wed, 8 Oct 2008 14:35:15 -0500

My experience is that there are a couple other variations as to what
folks might mean by "running code" - maybe break this into 1a. and then
1b. would be two separate implementations that do interwork as I'm
recalling that's what was done for HELD (clients) in Philadelphia (and
in my mind that's the "gold standard" for IETF).  Then I see a 2b. where
the code is in a real product that has been deployed or at least is in
beta test at a potential customer site - that's what we had for
History-Info while I was spending the years progressing the document and
I was able to get feedback from real implementers while the document was
in process. 

Also, we do have the data for SIP from SIPiTs of what folks have
implemented and how much of it does interop. 

As far as using 1a (someone has it implemented and can show it works)
I'm not sure that will help us make progress. It certainly did not for
MIDCOM, where we all brought in what we all had working in our products
at that point in time - 7 years later the "interim" (i.e., STUN/TURN)
solutions are still not entirely completed. And, based on the last SIPit
summary only 16% of folks are supporting STUNbis:
https://www.sipit.net/SIPit22_Summary

As to your basic questions, my experience has been that "running code"
does not factor very high in terms of whether we adopt a new WG item or
whether it relates at all to passing WGLCs.

I do think we would drop a whole lot of work if we required the running
code, however, it would be problematic for other SDOs whose process is
to write the specs years before anyone is even thinking about
implementing them. 

Mary.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Wednesday, October 08, 2008 2:01 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [RAI] Making RAI work better -- running code

Hi,

Markus

>ext Henry Sinnreich
>Can you help me understand why my insistence on running code has been 
>mostly ignored in this discussion? Is the topic too painful to discuss?
>
>Henry
>
>

---

From: Eric Burger <[email-masked]>
Date: Wed, 8 Oct 2008 15:41:01 -0400

Running code is mandatory for progressing a protocol to Draft  
Standard. I would offer the problem is not "we do not have running  
code" per se, it is "gosh, we do not want to progress SIP to Draft  
Standard."

Are there nefarious, hidden agendas behind not wanting to progress  
SIP? Or, is it really that SIP really is too hard to progress? Is it  
that we are spending so much time extending SIP that we do not have  
time to see that what we have already is working or useful?

On Oct 8, 2008, at 3:01 PM, <[email-masked]> <[email-masked] 
 > wrote:

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 08 Oct 2008 13:44:12 -0600

> difference in the standards process. 

I think we need an I-D on this. I've been meaning to write one since the
thread on [email-masked] a while back, but time is short.

> works and also they have deployment to show that it indeed solves a real

I think that is code as a running service. Very useful and important.

> doesn't tell if it's a good idea or if there is any use for it.

I think that is code as an implemented specification. Less useful and
important.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Mary Barnes" <[email-masked]>
Date: Wed, 8 Oct 2008 14:53:27 -0500

Gonzalo has made some good points and I don't think anyone can disagree
that there is more work to be done than there are people hours to do the
work. That's been evidenced by the number of pages of RAI documents that
are on the agendas for the meetings - I don't recall the rate, but it
was a humanly impossible rate at which folks would need to read the
documents (considering reading 24 hours a day).  I had the same thought
in terms of if we decided to schedule teleconferences - the logistics of
that likely would not accommodate very many activities due to timezones,
availability of folks, etc. However, perhaps defining a pool of times
and having those slots be fcfs in terms of allocating to design
teams/WGs would be helpful. 

No matter how we re-arrange things, it's not feasible to get all the
work done in a timely manner to meet milestones. We have tried putting
deadlines on documents earlier than the cut-off dates, but 9 times out
of 10, the dates are not met (the usual 90% of the documents are
submitted just before the deadline).  In my mind, there's no reason why
a doc that has been accepted as a WG doc can't be submitted as a -00
very soon after IETF meetings (obviously, incorporating any comments
received on the individual version). And, yes, I realize that a doc
doesn't have to have a WG name to be a WG document, but my experience is
that when it is a WG document, more folks do pay attention.  Thus, the
suggestion to revisit whether a doc should be a WG document could be
done x weeks after the meetings and if there isn't sufficient support
(i.e., x number of folks that will review and a committed editor to
update the doc by the deadlines), then we drop the work item.  But, I
also don't think the idea of not meeting deadlines is unique to RAI -
it's the volume of work that makes this a bigger problem. 

As far as face-to-face time, I'm not certain we can manage this during
IETF weeks, so I personally think more interims are a better alternative
- either f2f or some of the 1/2-1 day conf calls.  Also, perhaps
stealing a few days before the IETF meeting to have some longer working
sessions would be useful.  And, yes, I realize that this can cause
problems for some folks in terms of time away from the office and
families and other meeting conflicts, but in the past when we've had
such meetings for design teams, it has made the WG sessions far more
effective. These smaller group sessions typically just involve the
primary interested parties and the additional time on specific areas
tends to minimize the thrashing during the WG sessions.  It also gives
folks time to think about some of the agreements prior to the (shorter)
WG session, so the discussion can be far more focused on key issues. 

Overall, I do think it's worthwhile to try a few of these ideas and
SIPPING WG might be a good guinea pig since we are down to having fewer
work items and we have been one of the problem groups in terms of the
never ending addition of new work items and having some of the oldest
work items (including the individual documents lifetimes). 

Regards,
Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Gonzalo Camarillo
Sent: Wednesday, October 08, 2008 8:13 AM
To: [email-masked]
Subject: Re: [RAI] Making RAI work better

Hi,

http://www.arkko.com/tools/lifecycle/drafts.html
See the following link for an example:
http://www.arkko.com/tools/lifecycle/draft-ietf-sipping-config-framework
-timing.html

1) Editing resources:

2) Management resources:

3) Management structure:

4) Processes

need, we could form a directorate taking as a base that team fairly
quickly.

My two cents...

Cheers,

Gonzalo

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 08 Oct 2008 13:01:10 -0700

> thread on [email-masked] a while back, but time is short.

Count me as a supporter.  If authoring an I-D is "Talk the talk", then
writing the running code is "Walk the walk".

“Code then spec not Spec then Code” Motto of Itojun

http://www.ietf.org/proceedings/08mar/slides/SAMRG-7.pdf

-- 
Marc Petit-Huguenin           [                                 ]
Home: [email-masked] [RFC1855-compliant space for rent ]
Work: [email-masked]            [                                 ]
[                                                               ]
_______________________________________________
RAI mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rai

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 8 Oct 2008 16:12:10 -0400

Before this line of argument advances much farther, I'd like to submit
that our current IETF process, not just the RAI process, is completely
out of joint with the original vision of a standards track (Proposed,
Draft, Full). Attempts to remedy this so far have, for various reasons,
failed. I don't think it's a matter that nefarious influences reject the
idea that SIP should progress to Draft - rather, I think most of us
suspect that the effort of achieving that title is far, far greater than
the benefits it confers.

The rules that govern the advancement of specifications in the standards
track make it very difficult, some have argued prohibitively difficult,
to advance a document like the SIP specification, largely because of its
huge number of normative statements and references. Even assessing the
interoperability of SIP implementations against the standard is a
Herculean labor. And what exactly would that effort yield? While I can
understand an argument that SIP adoption has been slowed because of
imperfect specifications, I would be much more skeptical of an argument
that SIP's advancement in the marketplace probably has been impeded by
the fact that it is not yet a Draft Standard.

I am definitely sympathetic to Henry's core point here, but the fact
remains that the IETF is a document-producing organization, not a code
foundry (tools team excepted). Our participants need to be actively
implementing SIP if we are to truly understand the consequences of our
design decisions. However, I don't think the IETF as such can
effectively oversee those development efforts as an aspect of its
document advancement regimen. This is a place where there probably is a
role for some other organization. 

Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Eric Burger
Sent: Wednesday, October 08, 2008 12:41 PM
To: <[email-masked]>
Cc: Henry Sinnreich; [email-masked]
Subject: Re: [RAI] Making RAI work better -- running code

On Oct 8, 2008, at 3:01 PM, <[email-masked]>
<[email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 8 Oct 2008 13:48:26 -0700

> time to see that what we have already is working or useful?

Let's look at a protocol we are all familiar with - SMTP, and see
how long it took:

    RFC821, Standard, August 1982, 68 pages
    RFC2821, Proposed Standard, April 2001, 79 pages
    RFC5321, Draft Standard, October 2008, 94 pages

That's 19 years between RFC821 and RFC2821, and 7 years between RFC2821 and
RFC5321.  

RFC3261 is a proposed standard -- so it is something most akin to RFC2821.
But RFC3261 is 269 pages -- roughly 3 times larger than RFC2821's 79 pages.
It took 7 years for RFC2821 to get from Proposed Standard to Draft Standard.

Why am I not interested in progressing SIP to Draft Standard?  Because 7*3 =
21.

I'm sure someone has a more optimistic estimate of how long it would take.
Let's avoid the "We are motivated" or "Those SMTP guys just weren't working
fast enough" arguments.  Are there other RFCs, in a similar application space
as SIP, which were progressed from Proposed to Draft faster than 7 years?

-d

---

From: Tom Taylor <[email-masked]>
Date: Wed, 08 Oct 2008 19:49:33 -0400

Just a thought on the conferencing. In the ITU-T context I have run successfully 
a conference by E-mail, that took place over a couple of weeks. This works for a 
very focussed effort, such as getting a document into shape for WGLC. Basically 
we worked our way through the document section by section according to a 
timetable. If someone raised a point, I added it to a tracking spreadsheet -- I 
suppose a Wiki would be a more up-to-date approach. Other people could comment 
on the comments until we had no further discussion. If a point stayed quiet for 
a couple of days, it was considered settled.

I found I had to moderate the pace after a few days -- I was generating a lot of 
the comments, then had to add them to the tracker. I was trying to keep to a 
schedule that accommodated the majority European participation, which left me a 
bit short of sleep. So now I take a more realistic view of how quickly one can move.

Mary Barnes wrote:
...
>... >
...

---

From: Colin Perkins <[email-masked]>
Date: Thu, 9 Oct 2008 10:16:50 +0100

On 8 Oct 2008, at 21:48, Dan Wing wrote:
...
> I'm sure someone has a more optimistic estimate of how long it  
> would take. Let's avoid the "We are motivated" or "Those SMTP guys  
> just weren't working fast enough" arguments.  Are there other RFCs,  
> in a similar application space as SIP, which were progressed from  
> Proposed to Draft faster than 7 years?

It took six years to get RTP from Proposed to Draft, including four  
years working on the interoperability and implementation report, and  
the supporting testing strategies document. This effort certainly  
improved the protocol, but it's not clear that we couldn't have made  
the same improvements in a more incremental way, cycling at proposed  
more frequently, with less pain.

-- 
Colin Perkins
http://csperkins.org/

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 10 Oct 2008 07:01:50 +0100

Just picking up on the deadlines point that Gonzalo and others have
mentioned. I don't have data to back up this hunch, but in my opinion,
of the new drafts posted in the 2-3 months after an IETF meeting, the
proportion of RAI-related drafts is quite low, whereas during the week
or two before the deadline the proportion is a lot higher. This suggests
that RAI leaves more to the last minute than other areas. If a new draft
appears among the rush of drafts, I am unlikely to have time to read it,
particularly if it is not a 00 draft. To illustrate this, I was able to
take a short time to read through the two updated sip drafts
domain-certs and eku recently posted by Vijay, but if they had appeared
at the last minute, I probably would not have done so. We need deadlines
to work to - the present cut-off dates alone are insufficient.

John

> Behalf Of Gonzalo Camarillo
> Sent: 08 October 2008 14:13
> To: [email-masked]

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 13 Oct 2008 22:21:10 +0300

Hi,

I think running code is important and I also agree that in RAI we have 
gotten too far from the code. In fact, I think this is one of the 
biggest problem in the RAI area. But it is good to understand where 
"running code" can fit into our process to make them better. There are a 
number of issues that we need to take into consideration.

For example, having running code should not be a replacement for using 
common sense. If a WG agrees that there is no value in working on 
something for a number of good technical reasons, the fact that someone 
has coded that idea should not change the WG's decision. We all know 
that it is possible to implement really bad ideas (I am sure all of you 
can come up with many examples ;o) ).

However, once the WG decides to work on something, it is *really* useful 
to have running code. In addition to working on the RAI area, I chair a 
WG in the Internet area (the HIP WG). In that WG, folks typically write 
specifications and code at the same time. It takes us longer to write a 
particular spec, but the quality is typically higher... and having 
several people coding the same spec usually means that the specification 
is relevant. Otherwise, they would not be bothered implementing it.

In any case, even if this way of writing specs is great for some WGs, 
there are a number of issues we need to work on in order to use it in 
some of the RAI WGs.

1) We have the problem of the maturity levels. In some WGs, a PS means 
that several people have coded the spec. In others, it means that 
someone, eventually, may decide to implement the spec. This could be a 
valid way of working if we were using the three maturity levels. 
However, since most of our work remains a PS for ever, we should be 
looking into having a more homogeneous view of what a PS means or 
recycle specs as PS more often once they are implemented. In short, what 
we need is a mechanism to reflect our implementation experience in our 
specs without having to go through a huge process. The problem of 
advancing a spec to draft is that the incentive is generally too small 
for the pain you need to suffer to get there.

2) Some of the technologies developed in RAI are very complex. This 
makes it more difficult to follow the processes used by some smaller WGs 
(e.g., HIP) where implementers are the ones writing the specs. 
Implementers of a complex system do not have the time to come to the 
IETF because coming to the IETF is an activity that requires too much 
energy for them. So, we need to find better ways to either get those 
people to come to the IETF or, at least, get their inputs.

3) We interact with other SDOs that like to write specs before starting 
writing any code. We need to understand how to work with them while 
using our "running code" value.

I am convinced that if we work on these issues and manage to go back to 
our "running code" value, the quality and relevancy of our 
specifications will increase significantly.

Cheers,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 13 Oct 2008 22:27:46 +0300

Hi Spencer,

if we make this a part of our culture, of our typical process, no one 
will take it personally if he or she is replaced by another editor. For 
example, at the IETF face-to-face meeting, we get ETAs for all our WG 
items. If we agree that any editor that is late by more than, say, 3 
weeks with respect to the agreed plan will be replaced, and we execute 
the change systematically, editors that fail to edit a draft in time 
will not take it personally. That will make it easier for WG chairs to 
replace non-performing editors, in my opinion. Nowadays replacing an 
editor is such a rare event that the replaced editor will most likely 
get quite angry with the chairs. The replacement decision needs to be 
seen as a rule that most WGs follow, not as a random decision by a chair.

Cheers,

Gonzalo

Spencer Dawkins wrote:
>> it does not happen often enough. Therefore, if an editor is fired, he 
>> or she will feel offended. That is why most chairs do not change 
>> editors; they want to avoid personal conflicts. We should make 
>> changing editors part of our culture. Changing editor when the current 
>> editor does not have enough cycles to work on the draft needs to be 
>> perceived as the rule rather than the exception.
> 
> We really need to figure out how to make this change something that's OK 
> to suggest - status quo is that we have authors who have been made 
> editors, which is a completely different skill set (something about 
> starting vs finishing), and one editor revision per IETF cycle on too 
> many drafts...
> 
> Thanks,
> 
> Spencer
>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 14 Oct 2008 10:57:17 -0700

> is relevant. Otherwise, they would not be bothered implementing it.

I would suggest to base the decision of accepting an I-D as WG item not
only on consensus but also on running code.  Somebody wanting to have an
I-D accepted as WG item should put the effort of developing or convince
other people to develop code for this I-D.  On an IETF meeting session,
a hum can be followed by a show of hand of people who are willing to
develop an implementation for it.  This would be the decision of the
Chair to ask for this, as having an implementation is not meaningful for
all I-D.  Obviously implementing code that nobody can see is useless, so
only code releasing under an OSI approved license should count.

> people to come to the IETF or, at least, get their inputs.

Yes the technologies developed in RAI are complex, and this is one of
the problem to develop an implementation as proof of concept of an I-D.
  Even a 2 pages I-D on a SIP or RTP extension cannot be implemented
without an existing full implementation of SIP or RTP, which is a major
obstacle. This is one of the reason my employer sponsored the
development of Zap (http://www.croczilla.com/zap), a free and open
source SIP client.  I wanted it to be a platform that researchers and
I-D authors can use to easily extend protocols (Zap uses the Mozilla
platform, so it is designed for extensibility and portability).  For
example enum.at (http://ecrit.labs.nic.at/cgi-bin/trac.cgi) used it to
implements ECRIT protocols.  We recently rebooted the effort, and we now
have two developers working full time on Zap, and we recently released
code for TURN and ICE in the public repository.  My current TURN URI I-D
is implemented in Zap and the code publicly released, my other I-D
(stun-pmtud) is also implemented in Zap but still unreleased.

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 14 Oct 2008 22:16:30 +0300

> In addition to working on the RAI area, I 
> chair a WG in the Internet area (the HIP WG). In that WG, folks 
> typically write specifications and code at the same time. It takes us 
> longer to write a particular spec, but the quality is typically 
> higher... and having several people coding the same spec usually means 
> that the specification is relevant.

I noticed in various discussions that there is the temptation to assume
implementation equals deployment. 
For some reasons it is not that easy. 

It would be interesting to analyse some of the protocols developed in the
past, particularly with relevance to the RAI area (such as the presence/IM
case), to determine whether it is still possible to influence the fate of
some of them. 

The mentiond HIP case is a bit special here since it falls into the area of
research where you can always find some folks to implement it (since they
can publish papers). However, this unfortunately does not lead to
deployment, which is what you really want. 

I know a number of protocols that have been implemented (and they are
available as open source) but unfortunately they have not found widespread
usage. The story for each of them is slightly different but potentially
there is something to learn.

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 14 Oct 2008 14:20:55 -0500

Yes, it's not only running code but also tools like zap that are essential
if we are to change the ways and elevate the work of RAI from using pencil,
paper, discussions, hums and consensus as a replacement for running software
and tools and such as zap. http://www.croczilla.com/zap

For those interested in distributed applications "in the network" (I am
still a fan of apps the endpoints), the recent posting by Pamela Zave shows:

>http://www.research.att.com/~pamela/sip.html.

>Of the 13 race conditions in the sipping draft, 6 of them are out of
>the scope of the Spin model.
...snip...
>Of the remaining 7, all of them are in the Spin model, handled the
>same way.

>In addition, the Spin model shows 42 additional race conditions.
>This count is subject to a lot of interpretation, so I estimate a
>possible error of about 20%.

This demonstrates IMO how much more effective a tool can be compared to
endless discussions.

Clearly it is high time for RAI to move ahead from being a discussion forum
(strangely, I love it) and document factory to a rigorous engineering
oriented standards organization that uses software, tools and testing; open
and freely available.

Reigning in our prolific serial I-D writers is also part of the challenge.
Writing I-Ds without open software, tools and testing should be permitted by
the chairs only in exceptional cases.

Henry

On 10/14/08 12:57 PM, "Marc Petit-Huguenin" <[email-masked]> wrote:

> I-D authors can use to easily extend protocols

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 15 Oct 2008 09:55:53 +0300

Hi Hannes,

yes, that is a good point. It relates to Markus's comment on the 
different types of code we find. Of course, the end goal is to have 
deployments, but prototype and proof-of-concept implementations can help 
us increase the quality of our specs as we write them. We can see 
prototypes as a means to an end, which is having "real" deployments out 
there.

Also, with respect to having deployments, there are different types of 
deployments and there have been many discussions in the past about what 
the scope of the IETF in general and of the RAI area in particular 
should be. We have deployments on the Internet but we also have 
deployments that use RAI technologies on IP networks that are not the 
Internet (e.g., enterprise and operator networks).

Cheers,

Gonzalo

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 15 Oct 2008 08:18:30 -0400

While not disagreeing with the tenor of the discussion, I'll note one  
danger of "running code": It can cause early freeze-in of inferior  
solutions as the builders of code are reluctant to change their  
implementation. Also, unfortunately many of the real problems, such as  
difficulty configuring protocols or an excessive number of options,  
won't show up in such early prototypes.

I think there's also another issue: We sometimes have a tendency to  
favor complex solutions that differ from current industry customs to  
(supposedly) save a few bytes or a few processor cycles. I think it  
would be quite helpful if we required those proposing such tweaks to  
prove that they actually make an overall difference, not just improve  
performance by 20% in a component that accounts for 10% of the overall  
run-time.

Henning

On Oct 15, 2008, at 2:55 AM, Gonzalo Camarillo wrote:

> deployments, but prototype and proof-of-concept implementations can  
> help us increase the quality of our specs as we write them. We can  
> see prototypes as a means to an end, which is having "real"  
> deployments out there.
>
> Also, with respect to having deployments, there are different types  
> of deployments and there have been many discussions in the past  
> about what the scope of the IETF in general and of the RAI area in  
> particular should be. We have deployments on the Internet but we  
> also have deployments that use RAI technologies on IP networks that  
> are not the Internet (e.g., enterprise and operator networks).
>
> Cheers,
>
> Gonzalo

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 16 Oct 2008 11:14:10 -0400

Gonzalo,

I like this joke, and I think it captures part of what I think our main 
problem is.

Our main problem is, as folks have pointed out, we have a fairly small 
number of individuals who do the work - the same folks who post on the 
list, who speak at meetings, etc. We have had some infusion of new 
participants over the years, but the cadre changes slowly, and tends to 
suffer from burn-out as time investment from that core group slowly 
diminishes.

So, why is THAT? Why is it, that we have this small core with few new 
folks, and they are spending decreasing time on it? My view is, because 
that work is simply not important to them in the grand scheme of things. 
And its not important because its not related to their day jobs. And 
therein lies the key.

SIP now is way different than SIP when we started. When we started, SIP 
was an idea, and its participants were driven by vision. This is the 
early adopter phase, if you will. Now, SIP is a smashing success. Its 
widely deployed, with gazillions of implementations, minutes, and so on. 
However, the SIP group and RAI area still act primarily like its the 
early adopter phase. We work on cool new things, we are driven by new 
ideas that have not yet been adopted, and so on. That stuff is not of 
much interest to the large number of folks out there who are doing real 
software development, and running real networks with real SIP problems.

So, in my view, the way to increase our resources is to increase the 
relevancy of our work to the industry at large. That means moving away 
from cool new stuff, and focusing on solving real problems in real 
networks. If we focus on problems that matter to companies, my hope is, 
those companies will contrihute resources and they will help, because 
the work MATTERS to them.

Not that we should stop doing more new-ish kind of innovative work 
(p2psip being one example). But, we need to apportion our time 
commitment to work that has the biggest need.

So, some thoughts on that:

* we take a bunch of our work that is in the category of more 
investigative and forward looking - stuff that isn't in a network yet - 
and make it informational or experimental and just wrap it up and 
publish it.

* we revisit that awesome list of problems we got from that SIP forum 
luncheon a few meetings back, and start working on that stuff

* we recognize that the SIP that is, is not the same as the SIP that was 
originally envisioned. THe network is full of B2BUAs of various sorts, 
loaded with phone numbers, and there is a great scarcity of inter-domain 
SIP over the Internet. So, lets stop denying these things, and make sure 
that new stuff we develop is actually designed for the reality that SIP 
is. Otherwise, our work is entirely academic. Its OK for some of it to 
be, but our focus should be on fixing what is out there today.

In other words, SIP has entered the transition from early to late 
majority, and our processes need to evolve to meet that.

Some other thoughts:

* A few mails on the thread have mentioned telecon calls. I still think 
this would help immensely. IETF overall and RAI in particular operate 
based on the three-times-a-year impulse function. By having fixed RAI 
calls that mimick mini-IETFs, scheduled WAY in advance, we can add to 
the number of impulses and do more work incrementally. Drafts can be 
scheduled into slots in those calls, and if editors don't have updates 
in advance, then they will be highly embarrassed and that will drive 
work - REAL deadlines.

* I am totally in favor of restrictions on number of drafts one can 
edit, and only allowing editors to take new ones when they finish off an 
old one, or do a review, or something like that.

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

---

From: <[email-masked]>
Date: Fri, 17 Oct 2008 16:12:26 +0300

Hi,

I'm amazed how close to mine Jonathan's views are. So, I support pretty
much everything below. 

I agree that the most pressing issues are all related to
interoperability and telephony, as most people are using SIP for
telephony (certain things out of ECRIT/GEOPRIV and BLISS are critical
but not all). And they are deploying B2BUAs. 

I've observed some momentum for things like presence and video. Various
other stuff that RAI is doing does not appear to be that much on
anyone's product or deployment roadmaps, as far as I can tell. (But
that's just a single viewpoint.)

Markus

>Behalf Of ext Jonathan Rosenberg
>Sent: 16 October, 2008 18:14
>To: Gonzalo Camarillo
>Cc: [email-masked]
>I like this joke, and I think it captures part of what I think 
>our main problem is.
>
>Our main problem is, as folks have pointed out, we have a 
>fairly small number of individuals who do the work - the same 
>folks who post on the list, who speak at meetings, etc. We 
>have had some infusion of new participants over the years, but 
>the cadre changes slowly, and tends to suffer from burn-out as 
>time investment from that core group slowly diminishes.
>
>So, why is THAT? Why is it, that we have this small core with 
>few new folks, and they are spending decreasing time on it? My 
>view is, because that work is simply not important to them in 
>the grand scheme of things. 
>And its not important because its not related to their day 
>jobs. And therein lies the key.
>
>SIP now is way different than SIP when we started. When we 
>started, SIP was an idea, and its participants were driven by 
>vision. This is the early adopter phase, if you will. Now, SIP 
>is a smashing success. Its widely deployed, with gazillions of 
>implementations, minutes, and so on. 
>However, the SIP group and RAI area still act primarily like 
>its the early adopter phase. We work on cool new things, we 
>are driven by new ideas that have not yet been adopted, and so 
>on. That stuff is not of much interest to the large number of 
>folks out there who are doing real software development, and 
>running real networks with real SIP problems.
>
>So, in my view, the way to increase our resources is to 
>increase the relevancy of our work to the industry at large. 
>That means moving away from cool new stuff, and focusing on 
>solving real problems in real networks. If we focus on 
>problems that matter to companies, my hope is, those companies 
>will contrihute resources and they will help, because the work 
>MATTERS to them.
>
>Not that we should stop doing more new-ish kind of innovative 
>work (p2psip being one example). But, we need to apportion our 
>time commitment to work that has the biggest need.
>
>investigative and forward looking - stuff that isn't in a 
>network yet - and make it informational or experimental and 
>just wrap it up and publish it.
>
>* we revisit that awesome list of problems we got from that 
>SIP forum luncheon a few meetings back, and start working on that stuff
>
>* we recognize that the SIP that is, is not the same as the 
>SIP that was originally envisioned. THe network is full of 
>B2BUAs of various sorts, loaded with phone numbers, and there 
>is a great scarcity of inter-domain SIP over the Internet. So, 
>lets stop denying these things, and make sure that new stuff 
>we develop is actually designed for the reality that SIP is. 
>Otherwise, our work is entirely academic. Its OK for some of 
>it to be, but our focus should be on fixing what is out there today.
>
>
>In other words, SIP has entered the transition from early to 
>late majority, and our processes need to evolve to meet that.
>
>
>Some other thoughts:
>

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Fri, 17 Oct 2008 15:20:11 +0200

I think we, the authors, should also be responsible, and if we don't get 
the time or strength to complete a draft, or if we a burn of ideas, so, 
unable to progress the draft in duly time, we should ask our chair to 
find a replacement editor.

/Miguel

Gonzalo Camarillo wrote:
>>> changing editors part of our culture. Changing editor when the 
>>> current editor does not have enough cycles to work on the draft needs 
>>> to be perceived as the rule rather than the exception.
>>
>> We really need to figure out how to make this change something that's 
>> OK to suggest - status quo is that we have authors who have been made

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 18 Oct 2008 12:09:54 +0300

Hi,

yes, there are definitively different types of contributors in RAI, as 
Jonathan pointed out. Some contributors feel frustrated when a WG deals 
with new cool stuff because their priority is to have a solution ready 
to deploy asap and dealing with new stuff while some old stuff still has 
some problems is considered a waste of time. Other contributors could 
not care less about old stuff, even if it is not perfect, and prefer to 
focus on new exciting things. Probably separating work in different WGs 
would allow individuals to focus on whatever type of work they prefer. I 
think the idea has merit because it would allow us to have different 
sets of contributors (even if we would have some overlap) in different 
WGs and to manage those different WGs using different approaches.

Cheers,

Gonzalo

---

From: "Hisham Khartabil" <[email-masked]>
Date: Mon, 20 Oct 2008 10:57:13 +1100

Gonzalo,

You took the words right out of my mouth. I support the idea of separate SIP
WGs for fixing problems and new cool stuff. Perhaps SIPPING could also be
split, one WG is formed to discuss validity and requirements for fixing a
problem, while discussing requirements for new cool stuff is done in a
separate WG.

You might actually see different sets of people participating in those
groups.

Thanks,
Hisham

On 18/10/2008, Gonzalo Camarillo <[email-masked]> wrote:
> Jonathan pointed out. Some contributors feel frustrated when a WG deals with
> new cool stuff because their priority is to have a solution ready to deploy
> asap and dealing with new stuff while some old stuff still has some problems
> is considered a waste of time. Other contributors could not care less about
> old stuff, even if it is not perfect, and prefer to focus on new exciting
> things. Probably separating work in different WGs would allow individuals to
> focus on whatever type of work they prefer. I think the idea has merit
> because it would allow us to have different sets of contributors (even if we
> would have some overlap) in different WGs and to manage those different WGs
> using different approaches.
>
> Cheers,
>
> Gonzalo
>
>>> ext Jonathan Rosenberg
>>> number of individuals who do the work - the same folks who post on the list,
>>> who speak at meetings, etc. We have had some infusion of new participants
>>> over the years, but the cadre changes slowly, and tends to suffer from
>>> burn-out as time investment from that core group slowly diminishes.
>>>
>>> folks, and they are spending decreasing time on it? My view is, because that
>>> work is simply not important to them in the grand scheme of things. And its
>>> not important because its not related to their day jobs. And therein lies
>>> the key.
>>>
>>> was an idea, and its participants were driven by vision. This is the early
>>> adopter phase, if you will. Now, SIP is a smashing success. Its widely
>>> deployed, with gazillions of implementations, minutes, and so on. However,
>>> the SIP group and RAI area still act primarily like its the early adopter
>>> phase. We work on cool new things, we are driven by new ideas that have not
>>> yet been adopted, and so on. That stuff is not of much interest to the large
>>> number of folks out there who are doing real software development, and
>>> relevancy of our work to the industry at large. That means moving away from
>>> cool new stuff, and focusing on solving real problems in real networks. If
>>> we focus on problems that matter to companies, my hope is, those companies
>>> will contrihute resources and they will help, because the work MATTERS to
>>> them.
>>>
>>> (p2psip being one example). But, we need to apportion our time commitment to
>>> work that has the biggest need.
>>>
>>> investigative and forward looking - stuff that isn't in a network yet - and
>>> make it informational or experimental and just wrap it up and publish it.
>>>
>>> loaded with phone numbers, and there is a great scarcity of inter-domain SIP
>>> over the Internet. So, lets stop denying these things, and make sure that
>>> new stuff we develop is actually designed for the reality that SIP is.
>>> Otherwise, our work is entirely academic. Its OK for some of it to be, but
>>> our focus should be on fixing what is out there today.
>>>
>>>
>>> this would help immensely. IETF overall and RAI in particular operate based
>>> on the three-times-a-year impulse function. By having fixed RAI calls that
>>> mimick mini-IETFs, scheduled WAY in advance, we can add to the number of
>>> impulses and do more work incrementally. Drafts can be scheduled into slots
>>> in those calls, and if editors don't have updates in advance, then they will
>>> be highly embarrassed and that will drive work - REAL deadlines.
>>>
>>> * I am totally in favor of restrictions on number of drafts one can edit,
>>> and only allowing editors to take new ones when they finish off an old one,
>>> or do a review, or something like that.
>>>
>>>
>>>
>>> Thanks,
>>> Jonathan R.
>>>
>>>
>>>
>>>
>>> Gonzalo Camarillo wrote:
>>>
>>>> Hi,
>>>>
>>>> When I read some of the emails in the thread proposing to
>>>>
>>> mainly focus
>>>
>>>> on the last three areas, I could not help thinking of the
>>>>
>>> joke about the
>>>
>>>> Japanese Rowing team (I am sure all of you have heard it
>>>>
>>> before). The
>>>
>>>> In short, the joke is about the Japanese Rowing team, which
>>>>
>>> has 8 people
>>>
>>>> links above is the American team but I have seen other nationalities used as
>>>> well) that has 1 person rowing and 8 people
>>>>
>>> steering. The latter
>>>
>>>> team chooses to reorganize the boat's management structure
>>>>
>>> instead of
>>>
>>>> adding more rowers! :o)
>>>>
>>>> Any time management program has participants log their
>>>>
>>> activities for a
>>>
>>>> few days to understand how much effective time a week they
>>>>
>>> really have.
>>>
>>>> Almost always, people are surprised to figure out how little
>>>>
>>> effective
>>>
>>>> management and editing resources we have in RAI in order to
>>>>
>>> understand
>>>
>>>> how much work we can really tackle during, say, a year
>>>>
>>> within the area.
>>>
>>>> bottlenecks are. We will be able to figure out whether, at a given point, we
>>>> need more management resources or more editing resources.
>>>>
>>>> spreadsheets, and it seems that what we need most of the
>>>>
>>> time is more
>>>
>>>> editing resources. In other WGs the situation could be
>>>>
>>> different; the
>>>
>>>> This type of assessment is nothing new, by the way. The IESG
>>>>
>>> has been
>>>
>>>> working on something similar for the whole IETF. For a given
>>>>
>>> draft, the
>>>
>>>> The advantage of performing an assessment (even if it is a
>>>>
>>> very simple
>>>
>>>> discussions we had a few years ago (and we are having again in this thread),
>>>> where some people think we need more editors and
>>>>
>>> some people
>>>
>>>> We should both increase the amount of resources and use them
>>>>
>>> in a better
>>>
>>>> way.
>>>>
>>>> editor works with a more senior editor on a spec in order to
>>>>
>>> get up to
>>>
>>>> speed as soon as possible. This type of arrangement has
>>>>
>>> worked well with
>>>
>>>> some people but has failed with others. In any case, I think
>>>>
>>> we should
>>>
>>>> continue doing it.
>>>>
>>>> o Prioritize potential work items and work on the most
>>>>
>>> important ones.
>>>
>>>> So far, we have used "hum" levels to asses the importance of
>>>>
>>> different
>>>
>>>> drafts. In an environment with a lot of ideas and little
>>>>
>>> resources to
>>>
>>>> work on them, supporting a draft should take more than just
>>>>
>>> "humming". I
>>>
>>>> think we should move to an incentive-based system where you
>>>>
>>> can support
>>>
>>>> a draft by doing something the WG needs. So, if I believe a
>>>>
>>> WG should
>>>
>>>> implement the draft (i.e., running code). We would need to
>>>>
>>> work out the
>>>
>>>> details, but the basic idea is to provide incentives for
>>>>
>>> people to do
>>>
>>>> work for the WG.
>>>>
>>>> o Delegate work to other areas. There are a few items we
>>>>
>>> could move out
>>>
>>>> delegate this way will be significant (e.g., Sigtran is
>>>>
>>> still in RAI but
>>>
>>>> is effectively dormant).
>>>>
>>>> o Change editor when needed. The problem with changing
>>>>
>>> editors is that
>>>
>>>> it does not happen often enough. Therefore, if an editor is
>>>>
>>> fired, he or
>>>
>>>> she will feel offended. That is why most chairs do not
>>>>
>>> change editors;
>>>
>>>> they want to avoid personal conflicts. We should make
>>>>
>>> changing editors
>>>
>>>> part of our culture. Changing editor when the current editor
>>>>
>>> does not
>>>
>>>> o More deadlines. We need more deadlines because deadlines
>>>>
>>> drive work.
>>>
>>>> most drafts get revised three times a year. If an editor misses a deadline,
>>>> the draft losses priority. We have done this in
>>>>
>>> SIPPING and is
>>>
>>>> longer (e.g., the market went in other direction) or nobody
>>>>
>>> has the time
>>>
>>>> to work on it any longer, we should drop the draft. Burning
>>>>
>>> our precious
>>>
>>>> resources working on something that is going to be useless
>>>>
>>> just because
>>>
>>>> o Clarify our scope. It needs to be clearer what type of
>>>>
>>> work is outside
>>>
>>>> of the scope of a given WG. For example, SIP can be used as
>>>>
>>> a generic
>>>
>>>> rendezvous mechanism for a number of applications. Do we
>>>>
>>> want SIP to be
>>>
>>>> We should both increase the amount of resources and use them
>>>>
>>> in a better
>>>
>>>> way.
>>>>
>>>> We had mentoring programs for new chairs in the past. New
>>>>
>>> chairs used to
>>>
>>>>  have a more senior co-chair during a few meetings in order
>>>>
>>> to get them
>>>
>>>> up to speed as soon as possible. We should continue doing
>>>>
>>> this. In any
>>>
>>>> resources but lose editing resources. We should only do that
>>>>
>>> when the
>>>
>>>> technical work in addition to the purely administrative
>>>>
>>> work. Chairs are
>>>
>>>> supposed to understand technical discussions to a certain
>>>>
>>> level and be
>>>
>>>> aware of the trade-offs involved in the decisions the WG
>>>>
>>> makes. That is
>>>
>>>> why some technical leaders that could serve as editors end
>>>>
>>> up as chairs.
>>>
>>>> administrative tasks. In SIPPING, we have used a secretary for many years
>>>> and we are very happy with him.
>>>>
>>>> Design teams: chairs can also delegate some functions to the
>>>>
>>> leaders of
>>>
>>>> the WG's design teams.
>>>>
>>>>
>>>> 3) Management structure:
>>>>
>>>> distributed across different WGs. However, some WGs have
>>>>
>>> their own set
>>>
>>>> of people. That is why splitting WGs or consolidating WGs
>>>>
>>> cannot be the
>>>
>>>> solution for the whole RAI. Some WGs should be consolidated
>>>>
>>> while others
>>>
>>>> Minimize discussions on which draft goes to which WG. This
>>>>
>>> is a source
>>>
>>>> Minimize inefficient transactions between WGs (e.g., when
>>>>
>>> SIPPING sends
>>>
>>>> face-to-face time, we can remove the restriction of
>>>>
>>> two-slots per WG.
>>>
>>>> Creating a new WG just to get more slots does not seem to be
>>>>
>>> the best
>>>
>>>> solution.
>>>>
>>>> Focused efforts. If we need a focused effort, we can either
>>>>
>>> form a new
>>>
>>>> light-weight; they can be formed more quickly and easily...
>>>>
>>> but if it is
>>>
>>>> Long-lived WGs are very controversial within the IETF. There
>>>>
>>> have been
>>>
>>>> discussions within the IESG and the IAB about when they are
>>>>
>>> appropriate
>>>
>>>> should be discussed separately. My personal opinion is that
>>>>
>>> some of the
>>>
>>>> We should continue improving our processes and providing
>>>>
>>> input to the
>>>
>>>> directorate, we already have the RAI review team. Should we
>>>>
>>> identify the
>>>
>>>>> efficiency and organization of the RAI Area. We have both
>>>>>
>>>> observed that
>>>
>>>>> have difficulty tackling some of their more complex
>>>>>
>>>> projects. The more
>>>
>>>> critical a document seems to be from a dependency
>>>>>
>>>> perspective, the more
>>>
>>>> late surprises seem to emerge in its development and the
>>>>>
>>>> longer it takes
>>>
>>>> to escape from the working group process. A relatively
>>>>>
>>>> small number of
>>>
>>>> the working groups in the RAI Area seem to encompass the
>>>>>
>>>> lion's share of
>>>
>>>> our documents in their scope, which may concentrate too
>>>>>
>>>> much of our work
>>>
>>>>> Ultimately, these problems might result from any number of
>>>>>
>>>> causes. There
>>>
>>>>> into working groups, issues with chartering or focusing of
>>>>>
>>>> the efforts,
>>>
>>>>> make RAI work better. As a part of that discussion we are
>>>>>
>>>> reserving one
>>>
>>>> of our precious timeslots for a RAI Area open meeting in
>>>>>
>>>> Minneapolis (at
>>>
>>>> least the Friday afternoon experiment will give us one more
>>>>>
>>>> slot than
>>>
>>>> usual). In order to help set an agenda for that meeting,
>>>>>
>>>> we'd like to
>>>

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 24 Oct 2008 14:49:30 -0400

Jonathan makes some excellent points.  We are way past early adoption
and there are multi-billion-dollar businesses built on SIP-based
"stuff."  So where are groups like "SIP Ops" or something like that to
focus exclusively on large SIP application provider operational problems
and solutions?  Some of the existing WGs seem so broad and so focused on
the "new" despite the fact that so many organizations using SIP are not
as focused on those things.  Certainly one real operator problem has
been in SIP Peering (inter-domain), which SPEERMINT is attempting to
solve, but I suspect there are many other implementer-specific things
RAI could do that would begin to attract the countless engineers working
on SIP-related things around the world.

Anyway, I agree with all of Jonathan's suggestions below, and think they
merit serious consideration.

Jason

> Behalf Of Jonathan Rosenberg
> Sent: Thursday, October 16, 2008 11:14 AM
> To: Gonzalo Camarillo
> Cc: [email-masked]
> I like this joke, and I think it captures part of what I 
> think our main problem is.
> 
> have had some infusion of new participants over the years, 
> but the cadre changes slowly, and tends to suffer from 
> few new folks, and they are spending decreasing time on it? 
> My view is, because that work is simply not important to them 
> in the grand scheme of things. 
> vision. This is the early adopter phase, if you will. Now, 
> SIP is a smashing success. Its widely deployed, with 
> gazillions of implementations, minutes, and so on. 
> are driven by new ideas that have not yet been adopted, and 
> so on. That stuff is not of much interest to the large number 
> of folks out there who are doing real software development, 
> and running real networks with real SIP problems.
> 
> problems that matter to companies, my hope is, those 
> companies will contrihute resources and they will help, 
> because the work MATTERS to them.
> 
> work (p2psip being one example). But, we need to apportion 
> our time commitment to work that has the biggest need.
> 
> is a great scarcity of inter-domain SIP over the Internet. 
> So, lets stop denying these things, and make sure that new 
> stuff we develop is actually designed for the reality that 
> SIP is. Otherwise, our work is entirely academic. Its OK for 
> some of it to be, but our focus should be on fixing what is 
> out there today.
> 
>

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 24 Oct 2008 14:53:42 -0400

Another approach would be a clean break with the past.  By which I mean,
some of those WGs wrap up I-Ds in flight, and no more I-Ds are added as
WG items.  Basically, we close out what is in process.  Then, in
parallel, cleanly charter and design the new WG focus areas that the
community believes are important (not that this would necessarily be
easy in and of itself).  
 
Jason

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hisham Khartabil
	Sent: Sunday, October 19, 2008 7:57 PM
	To: Gonzalo Camarillo
	Cc: [email-masked]; [email-masked]
	Subject: Re: [RAI] Making RAI work better

	Gonzalo,
	 
	You took the words right out of my mouth. I support the idea of
separate SIP WGs for fixing problems and new cool stuff. Perhaps SIPPING
could also be split, one WG is formed to discuss validity and
requirements for fixing a problem, while discussing requirements for new
cool stuff is done in a separate WG.
	 
	You might actually see different sets of people participating in
those groups.
	 
	Thanks,
	Hisham

	On 18/10/2008, Gonzalo Camarillo
<[email-masked]> wrote: 

		Hi,
		
		yes, there are definitively different types of
contributors in RAI, as Jonathan pointed out. Some contributors feel
frustrated when a WG deals with new cool stuff because their priority is
to have a solution ready to deploy asap and dealing with new stuff while
some old stuff still has some problems is considered a waste of time.
Other contributors could not care less about old stuff, even if it is
not perfect, and prefer to focus on new exciting things. Probably
separating work in different WGs would allow individuals to focus on
whatever type of work they prefer. I think the idea has merit because it
would allow us to have different sets of contributors (even if we would
have some overlap) in different WGs and to manage those different WGs
using different approaches.
		
		Cheers,
		
		Gonzalo 

			Hi,
			
			I'm amazed how close to mine Jonathan's views
are. So, I support pretty
			much everything below. 
			I agree that the most pressing issues are all
related to
			interoperability and telephony, as most people
are using SIP for
			telephony (certain things out of ECRIT/GEOPRIV
and BLISS are critical
			but not all). And they are deploying B2BUAs. 
			I've observed some momentum for things like
presence and video. Various
			other stuff that RAI is doing does not appear to
be that much on
			anyone's product or deployment roadmaps, as far
as I can tell. (But
			that's just a single viewpoint.)
			
			Markus

				-----Original Message-----
				From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext Jonathan Rosenberg
				Sent: 16 October, 2008 18:14
				To: Gonzalo Camarillo
				Cc: [email-masked]
				Subject: Re: [RAI] Making RAI work
better
				
				Gonzalo,
				
				I like this joke, and I think it
captures part of what I think our main problem is.
				
				Our main problem is, as folks have
pointed out, we have a fairly small number of individuals who do the
work - the same folks who post on the list, who speak at meetings, etc.
We have had some infusion of new participants over the years, but the
cadre changes slowly, and tends to suffer from burn-out as time
investment from that core group slowly diminishes.
				
				So, why is THAT? Why is it, that we have
this small core with few new folks, and they are spending decreasing
time on it? My view is, because that work is simply not important to
them in the grand scheme of things. And its not important because its
not related to their day jobs. And therein lies the key.
				
				SIP now is way different than SIP when
we started. When we started, SIP was an idea, and its participants were
driven by vision. This is the early adopter phase, if you will. Now, SIP
is a smashing success. Its widely deployed, with gazillions of
implementations, minutes, and so on. However, the SIP group and RAI area
still act primarily like its the early adopter phase. We work on cool
new things, we are driven by new ideas that have not yet been adopted,
and so on. That stuff is not of much interest to the large number of
folks out there who are doing real software development, and running
real networks with real SIP problems.
				
				So, in my view, the way to increase our
resources is to increase the relevancy of our work to the industry at
large. That means moving away from cool new stuff, and focusing on
solving real problems in real networks. If we focus on problems that
matter to companies, my hope is, those companies will contrihute
resources and they will help, because the work MATTERS to them.
				
				Not that we should stop doing more
new-ish kind of innovative work (p2psip being one example). But, we need
to apportion our time commitment to work that has the biggest need.

				* we take a bunch of our work that is in
the category of more investigative and forward looking - stuff that
isn't in a network yet - and make it informational or experimental and
just wrap it up and publish it.
				
				* we revisit that awesome list of
problems we got from that SIP forum luncheon a few meetings back, and
start working on that stuff
				
				* we recognize that the SIP that is, is
not the same as the SIP that was originally envisioned. THe network is
full of B2BUAs of various sorts, loaded with phone numbers, and there is
a great scarcity of inter-domain SIP over the Internet. So, lets stop
denying these things, and make sure that new stuff we develop is
actually designed for the reality that SIP is. Otherwise, our work is
entirely academic. Its OK for some of it to be, but our focus should be
on fixing what is out there today.

				In other words, SIP has entered the
transition from early to late majority, and our processes need to evolve
to meet that.

				Some other thoughts:
				
				* A few mails on the thread have
mentioned telecon calls. I still think this would help immensely. IETF
overall and RAI in particular operate based on the three-times-a-year
impulse function. By having fixed RAI calls that mimick mini-IETFs,
scheduled WAY in advance, we can add to the number of impulses and do
more work incrementally. Drafts can be scheduled into slots in those
calls, and if editors don't have updates in advance, then they will be
highly embarrassed and that will drive work - REAL deadlines.
				
				* I am totally in favor of restrictions
on number of drafts one can edit, and only allowing editors to take new
ones when they finish off an old one, or do a review, or something like
that.

				Thanks,
				Jonathan R.

				
				Gonzalo Camarillo wrote:

				Hi,
				
				there are a few areas where we can
improve the current situation: editing resources, management resources,
management structure, and processes.
				
				When I read some of the emails in the
thread proposing to 

				mainly focus 

				on the last three areas, I could not
help thinking of the 

				joke about the 

				Japanese Rowing team (I am sure all of
you have heard it 

				before). The 

				links below contain two variations of
the joke:

				In short, the joke is about the Japanese
Rowing team, which 

				has 8 people 

				rowing and 1 person steering, competing
against another team (in the links above is the American team but I have
seen other nationalities used as well) that has 1 person rowing and 8
people 

				steering. The latter 

				team chooses to reorganize the boat's
management structure 

				instead of 

				adding more rowers! :o)
				
				Any time management program has
participants log their 

				activities for a 

				few days to understand how much
effective time a week they 

				really have. 

				Almost always, people are surprised to
figure out how little 

				effective 

				time they have. The same way, we should
first asses the level of management and editing resources we have in RAI
in order to 

				understand 

				how much work we can really tackle
during, say, a year 

				within the area. 

				This type of assessment will also help
us understand where the bottlenecks are. We will be able to figure out
whether, at a given point, we need more management resources or more
editing resources.
				
				In SIPPING, we can asses the current
situation through our status spreadsheets, and it seems that what we
need most of the 

				time is more 

				editing resources. In other WGs the
situation could be 

				different; the 

				This type of assessment is nothing new,
by the way. The IESG 

				has been 

				working on something similar for the
whole IETF. For a given 

				draft, the 

				following tool gives you a rough idea of
where delays come from.

	
http://www.arkko.com/tools/lifecycle/draft-ietf-sipping-config-
				framework-timing.html 

				The advantage of performing an
assessment (even if it is a 

				very simple 

				one) of the situation is that we will
avoid going through the same discussions we had a few years ago (and we
are having again in this thread), where some people think we need more
editors and 

				some people 

				think we need more chairs but nobody
provides data backing up their statements.

				There are some things we can do in the
four areas above:
				
				1) Editing resources:
				
				We should both increase the amount of
resources and use them 

				in a better 

				way.
				
				Increase the amount of editing
resources:
				We can restart the mentoring program we
used some time ago. A junior editor works with a more senior editor on a
spec in order to 

				get up to 

				speed as soon as possible. This type of
arrangement has 

				worked well with 

				some people but has failed with others.
In any case, I think 

				we should 

				continue doing it.
				
				Use our editing resources in a better
way:
				o Prioritize potential work items and
work on the most 

				important ones. 

				So far, we have used "hum" levels to
asses the importance of 

				different 

				drafts. In an environment with a lot of
ideas and little 

				resources to 

				work on them, supporting a draft should
take more than just 

				"humming". I 

				think we should move to an
incentive-based system where you 

				can support 

				a draft by doing something the WG needs.
So, if I believe a 

				WG should 

				work on a given draft, I can review a WG
item, become an editor, or implement the draft (i.e., running code). We
would need to 

				work out the 

				details, but the basic idea is to
provide incentives for 

				people to do 

				work for the WG.
				
				o Delegate work to other areas. There
are a few items we 

				could move out 

				from RAI, but I do not think the amount
of work we will be able to delegate this way will be significant (e.g.,
Sigtran is 

				still in RAI but 

				is effectively dormant).
				
				o Change editor when needed. The problem
with changing 

				editors is that 

				it does not happen often enough.
Therefore, if an editor is 

				fired, he or 

				she will feel offended. That is why most
chairs do not 

				change editors; 

				they want to avoid personal conflicts.
We should make 

				changing editors 

				part of our culture. Changing editor
when the current editor 

				does not 

				have enough cycles to work on the draft
needs to be perceived as the rule rather than the exception.
				
				o More deadlines. We need more deadlines
because deadlines 

				drive work. 

				The fact that we have three draft
deadlines a year is the reason why most drafts get revised three times a
year. If an editor misses a deadline, the draft losses priority. We have
done this in 

				SIPPING and is 

				typically a good incentive for editors
to meet those deadlines.
				
				o Continuous measurement of interest. If
a draft is not relevant any longer (e.g., the market went in other
direction) or nobody 

				has the time 

				to work on it any longer, we should drop
the draft. Burning 

				our precious 

				resources working on something that is
going to be useless 

				just because 

				at some point we thought it was
important is a great mistake.
				
				o Clarify our scope. It needs to be
clearer what type of 

				work is outside 

				of the scope of a given WG. For example,
SIP can be used as 

				a generic 

				rendezvous mechanism for a number of
applications. Do we 

				want SIP to be 

				used for anything or only for
inter-personal communications?

				2) Management resources:
				
				We should both increase the amount of
resources and use them 

				in a better 

				way.
				
				Increase the amount of management
resources:
				We had mentoring programs for new chairs
in the past. New 

				chairs used to 

				 have a more senior co-chair during a
few meetings in order 

				to get them 

				up to speed as soon as possible. We
should continue doing 

				this. In any 

				case, when an active editor becomes a
chair, we gain management resources but lose editing resources. We
should only do that 

				when the 

				situation we are in requires more
management but has enough editors.
				
				Use our management resources in a better
way:
				Secretaries: in the IETF, the chair role
typically involves some technical work in addition to the purely
administrative 

				work. Chairs are 

				supposed to understand technical
discussions to a certain 

				level and be 

				aware of the trade-offs involved in the
decisions the WG 

				makes. That is 

				why some technical leaders that could
serve as editors end 

				up as chairs. 

				Secretaries are a good way to have these
chairs delegate their administrative tasks. In SIPPING, we have used a
secretary for many years and we are very happy with him.
				
				Design teams: chairs can also delegate
some functions to the 

				leaders of 

				the WG's design teams.

				3) Management structure:
				
				Part of the work of RAI is done by the
same people even if it is distributed across different WGs. However,
some WGs have 

				their own set 

				of people. That is why splitting WGs or
consolidating WGs 

				cannot be the 

				solution for the whole RAI. Some WGs
should be consolidated 

				while others 

				should be split. In general, we should
try to:
				
				Minimize discussions on which draft goes
to which WG. This 

				is a source 

				of inefficiencies and author
frustration.
				
				Minimize inefficient transactions
between WGs (e.g., when 

				SIPPING sends 

				requirements to SIP so that SIP works on
a solution).
				
				Enough face-to-face time to discuss
everything. If we need more face-to-face time, we can remove the
restriction of 

				two-slots per WG. 

				Creating a new WG just to get more slots
does not seem to be 

				the best 

				solution.
				
				Focused efforts. If we need a focused
effort, we can either 

				form a new 

				WG or a new design team within an
existing WG. Design teams are more light-weight; they can be formed more
quickly and easily... 

				but if it is 

				a sufficiently scoped topic, a WG may be
the right solution.
				
				Long-lived WGs are very controversial
within the IETF. There 

				have been 

				discussions within the IESG and the IAB
about when they are 

				appropriate 

				and when they are not. There are
advantages and disadvantages that should be discussed separately. My
personal opinion is that 

				some of the 

				stuff we do in RAI should be done in
separate WGs but having a long-lived WG with well-scoped design teams is
useful as well (i.e., something like SIP nowadays, which does protocol
maintenance).

				4) Processes
				
				We should continue improving our
processes and providing 

				input to the 

				tools team so that our tools get better
and better. Regarding a RAI directorate, we already have the RAI review
team. Should we 

				identify the 

				need, we could form a directorate taking
as a base that team fairly quickly.
				
				My two cents...
				
				Cheers,
				
				Gonzalo

				
				Cullen Jennings wrote:

				Over the past year or so, Jon and I have
heard concerns about the
				efficiency and organization of the RAI
Area. We have both 

				observed that

				the larger working groups, particularly
SIP and SIPPING, continue to
				have difficulty tackling some of their
more complex 

				projects. The more

				critical a document seems to be from a
dependency 

				perspective, the more

				late surprises seem to emerge in its
development and the 

				longer it takes

				to escape from the working group
process. A relatively 

				small number of

				the working groups in the RAI Area seem
to encompass the 

				lion's share of

				our documents in their scope, which may
concentrate too 

				much of our work

				in too few areas and cause distracting
parallelization.
				
				Ultimately, these problems might result
from any number of 

				causes. There

				might be structural problems with the
manner the RAI Area is divided
				into working groups, issues with
chartering or focusing of 

				the efforts,

				snarls intrinsic to the technology,
personnel problems at any number
				of levels, questions of participant
energy, or any of a number of
				combinations thereof.
				
				What we'd like to do is kick off a
discussion about ways that we can
				make RAI work better. As a part of that
discussion we are 

				reserving one

				of our precious timeslots for a RAI Area
open meeting in 

				Minneapolis (at

				least the Friday afternoon experiment
will give us one more 

				slot than

				usual). In order to help set an agenda
for that meeting, 

				we'd like to

				invite any comments and discussion on
this list ([email-masked]),
				or if necessarily in private
correspondence to Jon and I. We're
				interested to learn to what degree
people believe there are problems
				that need to be addressed, and what
sorts of problems and potential
				solutions the community can identify.
				
				Cullen Jennings
				Jon Peterson
				RAI Area Directors

	

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

---

From: Dean Willis <[email-masked]>
Date: Fri, 24 Oct 2008 18:02:38 -0500

On Oct 24, 2008, at 1:53 PM, Livingood, Jason wrote:

> Another approach would be a clean break with the past.  By which I  
> mean, some of those WGs wrap up I-Ds in flight, and no more I-Ds are  
> added as WG items.  Basically, we close out what is in process.   
> Then, in parallel, cleanly charter and design the new WG focus areas  
> that the community believes are important (not that this would  
> necessarily be easy in and of itself).
>

That is exactly what I have been trying to do. Wrap up the old,  
charter the new. And keep the new charters clean, concise, and  
concludable.

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 27 Oct 2008 10:52:04 +0000

Yes, it is an excellent draft. Another activity (not in the IETF) is the
SIP Forum SIPconnect 1.1 work, which has attracted a reasonable number
of enthusiastic participants. That activity is following the "less is
more" principle in trying to keep the bar low for implementing and
deploying a basic PBX-SP interface. But it can only do this by breaking
some of the basic architectural premises of SIP, notably by recognising
there will be B2BUAs, and also the unusual use of REGISTER. It reflects
what people are doing today, and tries to converge these to an accepted
standard. This won't be achieved by ignoring what is done today and
trying to impose a different architecture.

John 

> Sent: 24 October 2008 19:50
> To: Jonathan Rosenberg; Gonzalo Camarillo
> Cc: [email-masked]