Re: [RAI] RAI processes for handling work effectively

[Mary Barnes <[e-mail]>]

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