Subject: [RAI] RAI processes for handling work effectively

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 19 Jun 2013 10:03:22 +0300

Folks,

as you know, in the RAI area we have always considered having effective
processes to help us produce relevant and timely specifications a very
important issue. When our environment has changed, we have sometimes
modified or fine tuned our processes in order to continue being
effective. A few examples (among many others) of such changes were the
introduction of mentors, the old SIPPING process, P headers, and the
current DISPATCH process.

It is time for us to look at the current state of affairs and discuss
whether or not we need to do certain things in a different way.

In particular, we currently have a few groups (e.g., RTCWeb and CLUE)
that work on higher-level constructions, which use elements developed in
other working groups. For example, CLUE could potentially specify a
mechanism that used mechanisms developed in MMUSIC or AVTEXT such as the
offer/answer model and a number of RTP extensions.

Note that what we called "higher-level constructions" above are referred
to by different names by different people: architectures, applications,
frameworks, etc. It does not really matter how we call them because this
discussion is not about terminology and it is fairly clear what this
type of work is about.

The way this type of work is currently done in RAI requires the
high-level WGs and the WGs developing the individual pieces to
communicate often. Those communications are not always easy, since
different WGs sometimes have different views on priorities,
requirements, use cases, etc.

What we would like to get your feedback on is: do we need a better way
to handle this type of work in RAI or our current process is as good as
it gets?

Note that we are interested in getting constructive feedback and ideas
on how to improve things. Please, focus your feedback on those aspects.

Thanks,

Gonzalo
(on behalf of both RAI ADs)

---

From: Brian Rosen <[email-masked]>
Date: Wed, 19 Jun 2013 09:05:24 -0400

Suppose we treated this as a mini-WG
1. The chairs and ADs work out a charter, with a limited WG time period to discuss. No IESG participation.
2. One chair is appointed from among the affected WG chairs
3. A new email list is created
4. Discussion is held during one of the WG meeting slots.  It can alternate perhaps between the affected groups.  The mini-group doesn't get a slot, but of course it may result in a WG asking for two slots for a particular meeting.
5. If there are cross AD issues, one AD is selected

Put a cap on this effort, and make it short - 2 meeting cycles maybe.  If they can't agree, then most likely each of the WGs will need to come up with their own solutions.
The mini-WG milestone may not be a submitted draft, it could be a mature draft, that would be finished in one of the affected WGs.  It could even be a general agreement on the solution, rather than an actual mature draft.  At the end, the mail list is closed., further discussion if any happens in the WGs.

Brian
On Jun 19, 2013, at 3:03 AM, Gonzalo Camarillo <[email-masked]> wrote:

> _______________________________________________
> RAI mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rai

---

From: Mary Barnes <[email-masked]>
Date: Wed, 19 Jun 2013 09:35:16 -0500

I like Brian's suggestion as one of the big issues here is that we
have debated some of these issues for eons so it would be good to set
a deadline.  I would strongly suggest that a WG chair that has a
vested interest in a particular proposal (i.e., as an author or
perhaps even with colleagues as co-authors) should NOT be one of the
WG chairs for this joint activity.

Thanks for raising this issue.

Mary.

---

From: John Leslie <[email-masked]>
Date: Wed, 19 Jun 2013 10:43:29 -0400

> offer/answer model and a number of RTP extensions.

   There is a very obvious three-way interaction among CLUE, RTCWeb, and
MMUSIC. The process is dangerously close to stalled because there's no
hope of reaching agreement on which roadblock needs to be cleared first.

   :^( :^( :^(

> discussion is not about terminology and it is fairly clear what this

   Alas, it's not as clear as you think.

> requirements, use cases, etc.

   That's not the problem. Communication among the WGs is quite good:
there are essentially no arguments which piece belongs in which WG.
The problem perhaps stems from all three WGs needing to follow the work
of both RTCWeb and MMUSIC (thus including folks who otherwise wouldn't
pay attention); but the actual problem is that the dependencies are
too strict.

   My advice, when this sort of situation occurs, is to chop out the
strict dependencies. In this case, MMUSIC seems unable to resolve
"Plan A" vs. "Plan B". Thus, management should find a way to make
that choice no longer gating on RTCWeb and CLUE.

   Perhaps it's not obvious how to do that; but once you give your
attention to _that_ as the problem, several approaches should become
apparent.

> to handle this type of work in RAI or our current process is as good as

   This doesn't strike me as a "process" question exactly. But we do
need some mechanism to find a way to decouple issues which deserve to
be settled in a different WG without requiring everyone to join that
other WG.

   (This is particularly painful to me right now, since I find myself
unable to give enough attention to both RTCWeb and MMUSIC, when what
I really want is to make progress in CLUE.)

   I'm not going to make any particular recommendation on how to
decouple these issues in this email; but I'm willing to do so in a
different email if Gonzalo asks for it.

--
John Leslie <[email-masked]>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 19 Jun 2013 10:54:34 -0500

Hi Brian,

It's not clear to me what scope you intend for the mini-wg. Does it handle the "higher-level constructions"? Is it responsible for breaking the interdependency logjams? Something else?

What keeps the min-wg from becoming the union of all interested parties from all the existing wgs? (Or was that what you intended?)

Thanks!

Ben.

---

From: Mary Barnes <[email-masked]>
Date: Wed, 19 Jun 2013 11:53:31 -0500

I'm not Brian but I'll go ahead and respond with my perspective [MB].

Mary.

> It's not clear to me what scope you intend for the mini-wg. Does it handle the "higher-level constructions"? Is it responsible for breaking the interdependency logjams? Something else?
[MB] I believe the "higher-level constructions" (which are
"applications" in my mind) are the responsibility of the group
chartered to create that solution based on existing protocols as well
as any new protocols the specific WG deems necessary.  The new mini-WG
is intended to deal with the solution requirements that may need to
change existing protocols. [/MB]
> What keeps the min-wg from becoming the union of all interested parties from all the existing wgs? (Or was that what you intended?)
[MB] The new mini-WG would be the union of all the parties that are
interested in reusing and changing existing protocols. This doesn't
impact the existing WGs chartered to define the solution for the
"higher-level constructions" - this does impact some of the existing
protocol building blocks that they may need to reuse and extend.
While we have WGs that are explicitly chartered to define new
extensions (e.g., MMUSIC for SDP), it's impossible to isolate the
solution aspects (from the "higher-level construct" WGs) and
requirements from the extensions that might be needed in the other WG.
 This gets to be particularly problematic in the case where you have
two WGs defining new "applications".  The big issue is figuring out
who is responsible for guiding the work in the existing WG where
extensions need to be defined.  Again, it's impossible to do the work
and have sensible discussions without understanding some aspects
required by the solution (and why they are required). While it's
tempting for the chairs of the WG where extensions need to be defined
to suggest that "application" discussions are out of scope, that just
doesn't work.  By having chairs from all the WGs involved represented
in the new mini-WG, everyone has "equal stakes" so to speak in
ensuring that a solution is reached.  Setting a specific deadline is
extremely helpful as it helps deal with deadlock situations and the
reality that the new "applications" may not be able to use the same
extensions, for example.
[/MB]

---

From: Mary Barnes <[email-masked]>
Date: Wed, 19 Jun 2013 11:54:49 -0500

BTW, if you want a real live example as to the extent of the current
problem, just listen to the first 25 minutes of the MMUSIC virtual
interim held this past Monday.

Mary.

---

From: Michael Hammer <[email-masked]>
Date: Wed, 19 Jun 2013 16:59:59 +0000

Mary,

Your description seems too broad.  Most WGs would see themselves doing what
you describe.

The issue seems to be more architectural, when two or more WGs think that
the subject matter falls within their domain.
So, it seems the mini-WG is there to scale back the scopes of the WGs so as
to make them mutually exclusive.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mary
Barnes
Sent: Wednesday, June 19, 2013 12:55 PM
To: Ben Campbell
Cc: [email-masked]
Subject: Re: [RAI] RAI processes for handling work effectively

BTW, if you want a real live example as to the extent of the current
problem, just listen to the first 25 minutes of the MMUSIC virtual interim
held this past Monday.

Mary.

On Wed, Jun 19, 2013 at 11:53 AM, Mary Barnes <[email-masked]>
wrote:
>> It's not clear to me what scope you intend for the mini-wg. Does it
handle the "higher-level constructions"? Is it responsible for breaking the
interdependency logjams? Something else?
>> What keeps the min-wg from becoming the union of all interested 
>> parties from all the existing wgs? (Or was that what you intended?)
>>> Suppose we treated this as a mini-WG 1. The chairs and ADs work out 
>>> a charter, with a limited WG time period to discuss. No IESG
participation.
>>> 2. One chair is appointed from among the affected WG chairs 3. A new 
>>> email list is created 4. Discussion is held during one of the WG 
>>> meeting slots.  It can alternate perhaps between the affected groups.
The mini-group doesn't get a slot, but of course it may result in a WG
asking for two slots for a particular meeting.
>>> Put a cap on this effort, and make it short - 2 meeting cycles maybe.
If they can't agree, then most likely each of the WGs will need to come up
with their own solutions.
>>> The mini-WG milestone may not be a submitted draft, it could be a mature
draft, that would be finished in one of the affected WGs.  It could even be
a general agreement on the solution, rather than an actual mature draft.  At
the end, the mail list is closed., further discussion if any happens in the
WGs.
>>>> as you know, in the RAI area we have always considered having 
>>>> effective processes to help us produce relevant and timely 
>>>> specifications a very important issue. When our environment has 
>>>> changed, we have sometimes modified or fine tuned our processes in 
>>>> order to continue being effective. A few examples (among many 
>>>> others) of such changes were the introduction of mentors, the old 
>>>> SIPPING process, P headers, and the current DISPATCH process.
>>>>
>>>> It is time for us to look at the current state of affairs and 
>>>> discuss whether or not we need to do certain things in a different way.
>>>>
>>>> In particular, we currently have a few groups (e.g., RTCWeb and 
>>>> CLUE) that work on higher-level constructions, which use elements 
>>>> developed in other working groups. For example, CLUE could 
>>>> potentially specify a mechanism that used mechanisms developed in 
>>>> MMUSIC or AVTEXT such as the offer/answer model and a number of RTP
extensions.
>>>>
>>>> Note that what we called "higher-level constructions" above are 
>>>> referred to by different names by different people: architectures, 
>>>> applications, frameworks, etc. It does not really matter how we 
>>>> call them because this discussion is not about terminology and it 
>>>> is fairly clear what this type of work is about.
>>>>
>>>> What we would like to get your feedback on is: do we need a better 
>>>> way to handle this type of work in RAI or our current process is as 
>>>> good as it gets?
>>>>
>>>> Note that we are interested in getting constructive feedback and 
>>>> ideas on how to improve things. Please, focus your feedback on those
aspects.

---

From: Mary Barnes <[email-masked]>
Date: Wed, 19 Jun 2013 12:09:00 -0500

> Your description seems too broad.  Most WGs would see themselves doing what
[MB] Yes, but on a scale that the existing protocol is being much less
impacted and with the WGs doing "application" stuff being much more
discrete solutions. So, we haven't encountered this problem nearly to
the degree we are right now.  Again, listen to the first 25 minutes of
the MMUSIC interim on Monday and consider that there was no conclusion
(yet again) on that topic.  [/MB]
> to make them mutually exclusive.
[MB] I can kind of see your point BUT for that to work, you need a
very clear understanding of what parts of the application can be
removed from scope - if we could do that, we wouldn't have the problem
we do right now. For example, CLUE still hasn't decided how much we
will signal in SDP versus in a specific CLUE channel.  The more we do
in SDP, the more dependency we have on what is being defined in MMUSIC
to support RTCWEB.   I won't even try to explain where RTCWEB is - you
can scan the archives there and see for yourself.