Re: [RAI] RAI processes for handling work effectively

[Mary Barnes <[e-mail]>]

On Wed, Jun 19, 2013 at 11:59 AM, Michael Hammer
<[e-mail]> wrote:
> Mary,
>
> Your description seems too broad.  Most WGs would see themselves doing what
> you describe.
[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]
>
> 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.
[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.
>
> Mike
>
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Mary
> Barnes
> Sent: Wednesday, June 19, 2013 12:55 PM
> To: Ben Campbell
> Cc: [e-mail]
> 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 <[e-mail]>
> wrote:
>> I'm not Brian but I'll go ahead and respond with my perspective [MB].
>>
>> Mary.
>>
>> On Wed, Jun 19, 2013 at 10:54 AM, Ben Campbell <[e-mail]> wrote:
>>> 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?
>> [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]
>>>
>>> Thanks!
>>>
>>> Ben.
>>>
>>> On Jun 19, 2013, at 8:05 AM, Brian Rosen <[e-mail]> wrote:
>>>
>>>> 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
> <[e-mail]> wrote:
>>>>
>>>>> 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)
>>>>>
>>>>> _______________________________________________
>>>>> RAI mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/rai
>>>>
>>>> _______________________________________________
>>>> RAI mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/rai
>>>
>>> _______________________________________________
>>> RAI mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rai
> _______________________________________________
> RAI mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rai