Subject: [AVT] proposed AVT WG split

From: Stephan Wenger <[email-masked]>
Date: Wed, 12 Jan 2011 16:11:20 -0800

Hi IESG,

As already communicated in Maastricht, I continue to believe that this step
is a bad idea.  I didn't attend Beijing, and don't know whether there was
any discussion about the subject.  I didn't see anything mentioned in the
AVT minutes, though, nor did I see any discussion since Beijing on
ietf@ietf.  If there was, some of the points below may be redundant, and I
apologize in advance.

Essentially, you guys are suggesting to split one "eternal" WG into four.
I'm writing "eternal", because I don't see that any of the WGs can fulfill
its charter before other work items will likely get chartered with a similar
scope, and in the same WG.  For RTP core, RTP extensions, and RTP payloads
that is probably self-evident.  For the XR stuff: metrics pop up all the
time, like payload formats.  Metrics are also known to make people quick
bucks on patent licensing.  There will be more metric proposals.  If the
RTCP-XR metrics ever get momentum in the marketplace, that is.  Somehow, I
have my doubts.  But that's a different discussion.

The positive effects of the split could be
-chair workload is split among more people, and
-there are more meeting seconds for RTP related work at any given IETF
meeting.  

Assuming unlimited resources, both are good things.  Unfortunately,
resources are not unlimited.

The negative effects are IMO:
-the key knowledgeable people in AVT ideally would have to sit in all four
meetings so that all four groups can tap their experience.  But they may not
want to do so, because it leaves less time for cross-area involvement,
coordination, and draft-writing outside the AVT sessions, and whatnot.
Also, the burden for remote participants in far-away time zones goes up.  In
other words, the resource meeting-seconds for those people is not unlimited,
and they will have to prioritize differently.    The result could be that
what I called "key knowledgable people" would perhaps not attend the mere
RTCP-XR or Payload session; and the guys there may be wasting their time
doing work that does not make sense architecturally, just to see the hammer
coming down at IETF last call.
-more people get chair positions and are burdened with administrative stuff
-> less time to do real work
-WG scheduling gets more difficult
-AD load potentially goes up (someone needs to coordinate between those
groups, and the AD would seem to me the natural choice)
-there is no reason to believe that the overall manpower availability goes
up through this change, so all the inefficiencies introduced go straight
against the available cycles.

Some of these issues can be solved by joint WG meetings and/or careful chair
selection.  However, both options have drawbacks as well.  A joint session
would be counter-productive to the allocation of more meeting minutes.  And
when you have, say, 8 chairs for four WG, all of which know the RTP
architecture well enough, then you have pretty much exhausted, if not
overdrawn already, the pool of "key knowledgable people", and burdened them
with (in many cases: additional) chair duties.

No matter how I see it, splitting the group is not a good idea.

Other options to alleviate problems could come to mind:

If the problem to be solved is chair-workload: add more chairs (but not 6 of
them).
If the problem to be solved is meeting-second shortages: have interim
meetings, conf calls, etc.  In other words, stretch out the AVT meeting in
the interval between IETF meetings.  Require a web-ex presentation of every
draft to be discussed in the AVT session at least 4 weeks before the
meeting, with a two hour timeslot for Q/A.  Should I continue with this
brainstorm?

If the problem is something else, I would like to knowŠ

Thanks for your consideration, and apologies for the wordcount,

Stephan

---

From: Stephen Casner <[email-masked]>
Date: Wed, 12 Jan 2011 20:32:46 -0800 (PST)

+1, definitely.

When I was chair, I once thought that AVT should try to draw to a
close.  Later I realized that this was not only unlikely but also not
required.

                                                        -- Steve

On Wed, 12 Jan 2011, Stephan Wenger wrote:

> If the problem is something else, I would like to know?
>

---

From: Michael Speer <[email-masked]>
Date: Wed, 12 Jan 2011 22:28:42 -0800

+1, go for it.

On 1/12/11 8:32 PM, Stephen Casner wrote:
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

-- 
Michael Speer
Principal Software Engineer, Solaris Core OS
Oracle
e-mail: [email-masked]
phone: +1 408 276-6943

---

From: Stephen Casner <[email-masked]>
Date: Wed, 12 Jan 2011 23:30:39 -0800 (PST)

Hmmm, Michael's message makes me think mine may have not been clear.
By +1, I meant that I agree with Stephan that splitting AVT into four
WGs is a bad idea.

                                                        -- Steve

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 13 Jan 2011 09:55:22 +0100

I have to agree with much, if not all, of what Stephan says. It would help, of course, if those proposing the change could give a clear statement as to what they consider to be broken with the current arrangement. 

I tend to have an interest in some, but not all, of the activities AVT is engaged in. Therefore, I tend to pay attention to only parts of AVT face-to-face sessions. It is not clear that the proposed split would make my participation easier - I suspect I would still be in a position of selecting particular topics from each of the WG sessions. If anything it would probably make things harder - 4 WGs would typically involve 4 face-to-face sessions, rather than the 2 that AVT typically holds, making conflicts with other WGs in the RAI area (or elsewhere, for that matter) more likely.

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Stephan Wenger
> Sent: 13 January 2011 00:11
> To: [email-masked]
> Cc: [email-masked]
> Subject: [AVT] proposed AVT WG split
> 
> Hi IESG,
> 
> As already communicated in Maastricht, I continue to believe 
> that this step is a bad idea.  I didn't attend Beijing, and 
> don't know whether there was any discussion about the 
> subject.  I didn't see anything mentioned in the AVT minutes, 
> though, nor did I see any discussion since Beijing on 
> ietf@ietf.  If there was, some of the points below may be 
> redundant, and I apologize in advance.
> 
> Essentially, you guys are suggesting to split one "eternal" 
> WG into four.  I'm writing "eternal", because I don't see 
> that any of the WGs can fulfill its charter before other work 
> items will likely get chartered with a similar scope, and in 
> the same WG.  For RTP core, RTP extensions, and RTP payloads 
> that is probably self-evident.  For the XR stuff: metrics pop 
> up all the time, like payload formats.  Metrics are also 
> known to make people quick bucks on patent licensing.  There 
> will be more metric proposals.  If the RTCP-XR metrics ever 
> get momentum in the marketplace, that is.  Somehow, I have my 
> doubts.  But that's a different discussion.  
> 
> -there are more meeting seconds for RTP related work at any 
> given IETF meeting.  
> 
> Assuming unlimited resources, both are good things.  
> Unfortunately, resources are not unlimited.
> 
> -the key knowledgeable people in AVT ideally would have to 
> sit in all four meetings so that all four groups can tap 
> their experience.  But they may not want to do so, because it 
> leaves less time for cross-area involvement, coordination, 
> and draft-writing outside the AVT sessions, and whatnot.  
> Also, the burden for remote participants in far-away time 
> zones goes up.  In other words, the resource meeting-seconds 
> for those people is not unlimited, and they will have to 
> prioritize differently.    The result could be that what I 
> called "key knowledgable people" would perhaps not attend the 
> mere RTCP-XR or Payload session; and the guys there may be 
> wasting their time doing work that does not make sense 
> architecturally, just to see the hammer coming down at IETF last call.
> -more people get chair positions and are burdened with 
> administrative stuff -> less time to do real work
> -AD load potentially goes up (someone needs to coordinate 
> between those groups, and the AD would seem to me the natural choice)
> -there is no reason to believe that the overall manpower 
> availability goes up through this change, so all the 
> inefficiencies introduced go straight against the available cycles.
> 
> Some of these issues can be solved by joint WG meetings 
> and/or careful chair selection.  However, both options have 
> drawbacks as well.  A joint session would be 
> counter-productive to the allocation of more meeting minutes. 
>  And when you have, say, 8 chairs for four WG, all of which 
> know the RTP architecture well enough, then you have pretty 
> much exhausted, if not overdrawn already, the pool of "key 
> knowledgable people", and burdened them with (in many cases: 
> additional) chair duties.
> 
> If the problem to be solved is chair-workload: add more 
> chairs (but not 6 of them).
> If the problem to be solved is meeting-second shortages: have 
> interim meetings, conf calls, etc.  In other words, stretch 
> out the AVT meeting in the interval between IETF meetings.  
> Require a web-ex presentation of every draft to be discussed 
> in the AVT session at least 4 weeks before the meeting, with 
> a two hour timeslot for Q/A.  Should I continue with this brainstorm?
> 
> If the problem is something else, I would like to know...
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 13 Jan 2011 19:59:20 +0100

This is AD initiated rather than WG chair initiated, although the ADs have been discussing it with the WG chairs, and indeed also with the other RAI chairs.

One of the issues we do have is WG chair load. Every time I do a review of the current status of our working group items, it takes me over 3 hours. That is just the sheer quantity of milestones we have. It therefore doesn't happen as often as it ought to because that is 3 hours away from doing other tasks.  

Currently in each meeting cycle we are starting the publication request process for on avaerage two documents each - i.e. AVT is forwarding 12 documents a year to IESG. That is also a heavy chair load.

The meeting load issues has already been discussed. I believe that the payload group would meet rarely. In formal IETF terms it is really doing an expert review process, but apparently needs a WG to do it, because we haven't been able to codify all the good practice that an expert review should take into account. We are not spending a lot of our current meeting time as AVT discussing new or revised payload types.

So your average 2 + 1 AVT sessions will probably turn into 1 + 1 + 1 working group sessions of the new groups if this goes ahead.

Keith

> Behalf Of Elwell, John
> Sent: Thursday, January 13, 2011 8:55 AM
> To: Stephan Wenger; [email-masked]
> Cc: [email-masked]
> Subject: Re: [AVT] proposed AVT WG split
> 
> I have to agree with much, if not all, of what Stephan says. 
> It would help, of course, if those proposing the change could 
> give a clear statement as to what they consider to be broken 
> with the current arrangement. 
> 
> I tend to have an interest in some, but not all, of the 
> activities AVT is engaged in. Therefore, I tend to pay 
> attention to only parts of AVT face-to-face sessions. It is 
> not clear that the proposed split would make my participation 
> easier - I suspect I would still be in a position of 
> selecting particular topics from each of the WG sessions. If 
> anything it would probably make things harder - 4 WGs would 
> typically involve 4 face-to-face sessions, rather than the 2 
> that AVT typically holds, making conflicts with other WGs in 
> the RAI area (or elsewhere, for that matter) more likely.
> 
> John
> 
> Behalf Of 
> > Stephan Wenger
> > As already communicated in Maastricht, I continue to 
> believe that this 
> > step is a bad idea.  I didn't attend Beijing, and don't 
> know whether 
> > there was any discussion about the subject.  I didn't see anything 
> > mentioned in the AVT minutes, though, nor did I see any discussion 
> > since Beijing on ietf@ietf.  If there was, some of the points below 
> > may be redundant, and I apologize in advance.
> > 
> that any of 
> > the WGs can fulfill its charter before other work items will likely 
> > get chartered with a similar scope, and in the same WG.  
> For RTP core, 
> > RTP extensions, and RTP payloads that is probably 
> self-evident.  For 
> > the XR stuff: metrics pop up all the time, like payload formats.  
> > Metrics are also known to make people quick bucks on patent 
> licensing.  
> > There will be more metric proposals.  If the RTCP-XR 
> metrics ever get 
> > momentum in the marketplace, that is.  Somehow, I have my 
> doubts.  But 
> > The positive effects of the split could be -chair workload is split 
> > among more people, and -there are more meeting seconds for 
> RTP related 
> > work at any given IETF meeting.
> > 
> sit in all 
> > four meetings so that all four groups can tap their 
> experience.  But 
> > they may not want to do so, because it leaves less time for 
> cross-area 
> > involvement, coordination, and draft-writing outside the 
> AVT sessions, 
> > and whatnot.
> zones goes 
> > up.  In other words, the resource meeting-seconds for those 
> people is 
> > not unlimited, and they will have to
> > called "key knowledgable people" would perhaps not attend the mere 
> > RTCP-XR or Payload session; and the guys there may be wasting their 
> > time doing work that does not make sense architecturally, 
> just to see 
> > the hammer coming down at IETF last call.
> administrative 
> > stuff -> less time to do real work -WG scheduling gets more 
> difficult 
> > -AD load potentially goes up (someone needs to coordinate between 
> > those groups, and the AD would seem to me the natural 
> choice) -there 
> > is no reason to believe that the overall manpower 
> availability goes up 
> > through this change, so all the inefficiencies introduced 
> go straight 
> and/or careful 
> > chair selection.  However, both options have drawbacks as well.  A 
> > joint session would be counter-productive to the allocation of more 
> > meeting minutes.
> know the 
> > RTP architecture well enough, then you have pretty much 
> exhausted, if 
> > not overdrawn already, the pool of "key knowledgable people", and 
> > burdened them with (in many cases:
> > If the problem to be solved is chair-workload: add more chairs (but 
> > not 6 of them).
> > meetings, conf calls, etc.  In other words, stretch out the AVT 
> > meeting in the interval between IETF meetings.
> > Require a web-ex presentation of every draft to be discussed in the 
> > AVT session at least 4 weeks before the meeting, with a two hour 
> > timeslot for Q/A.  Should I continue with this brainstorm?
> >

---

From: Roni Even <[email-masked]>
Date: Thu, 13 Jan 2011 21:59:19 +0200

Hi,

I agree with Stephan view. My experience in AVT is that the WG review
process depends on a number of individual that has a general interest in RTP
and since payloads and RTCP XR are discussed in the same WG are contributing
to this effort. Breaking the WG to 3 or 4 will not be helpful for these
persons. If the issue is load on chairs we can add one more chair to help
with document shepherding

As for the current proposal if there is a strong support for it I think that
the XR WG make sense bit should include the monitoring architecture document
to it.

As for RTP core and text this is an artificial division. We need one WG and
if there is work that is not in the charter it  should go to DISPATCH who
will decide if to have a new group or assign it to AVT.

The payload work should be part of the main AVT group since we want the
people who are interested in AVT but are following and helping the payload
work just because it is part of AVT to continue and not go away.

To summarize the only division I can see if for RTCP XR for monitoring WG.

Thanks

Roni Even as individual

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stephan Wenger
Sent: Thursday, January 13, 2011 2:11 AM
To: [email-masked]
Cc: [email-masked]
Subject: [AVT] proposed AVT WG split

Hi IESG,

If the problem is something else, I would like to know.

Stephan

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 5782 (20110112) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 5782 (20110112) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 5785 (20110113) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

---

From: Robert Sparks <[email-masked]>
Date: Thu, 13 Jan 2011 15:27:55 -0600

Stephan -

As I noted in response to your comments in Maastricht, I disagree.

There are separable streams of work in AVT - it is really multiple working groups in one shell at the moment.

While there are key people currently in AVT that would overlap these groups, they are not the majority of the contributors to the different types of activities.
The intended positive effect of this explicit division is to allow these different streams to better parallelize, on list between meetings, not just during the IETF
in-person meeting time. 

We'd like to try to channel these streams separately for a while. That will require some additional coordination work from the area directors and chairs, but
it will bring significant benefits, especially in being able to better prioritize work items within the streams.  I realize that for folks like you, who will actively participate 
in all of the efforts, the benefits are more limited.

I have had several participants express frustration, for example, with the way the RAMs work eclipsed basic architectural work in AVT. 
While that could be  managed in place  (we could have only one working group per area in the extreme), it has shown itself to be difficult 
with the set of things this group is working on.

I also expect  the separation will make it easier to evaluate when the energy for a particular effort (such as the XR metrics you point to below) exists, 
and when that level of energy changes.

Yes, conflicts between these working groups when they do meet in person will have to be managed carefully, but we have mechanisms for that. As Keith noted
separately, we do not anticipate this significantly increasing the number-of-minutes footprint on any given in-person IETF meeting. Also, your comments assume all 
four of these groups would have a session at each in-person meeting. I don't expect that to be the case.

RjS

On Jan 12, 2011, at 6:11 PM, Stephan Wenger wrote:

> Hi IESG,
> 
> As already communicated in Maastricht, I continue to believe that this step is a bad idea.  I didn't attend Beijing, and don't know whether there was any discussion about the subject.  I didn't see anything mentioned in the AVT minutes, though, nor did I see any discussion since Beijing on ietf@ietf.  If there was, some of the points below may be redundant, and I apologize in advance.
> 
> Essentially, you guys are suggesting to split one "eternal" WG into four.  I'm writing "eternal", because I don't see that any of the WGs can fulfill its charter before other work items will likely get chartered with a similar scope, and in the same WG.  For RTP core, RTP extensions, and RTP payloads that is probably self-evident.  For the XR stuff: metrics pop up all the time, like payload formats.  Metrics are also known to make people quick bucks on patent licensing.  There will be more metric proposals.  If the RTCP-XR metrics ever get momentum in the marketplace, that is.  Somehow, I have my doubts.  But that's a different discussion.  
> 
> -there are more meeting seconds for RTP related work at any given IETF meeting.  
> 
> Assuming unlimited resources, both are good things.  Unfortunately, resources are not unlimited.
> 
> -the key knowledgeable people in AVT ideally would have to sit in all four meetings so that all four groups can tap their experience.  But they may not want to do so, because it leaves less time for cross-area involvement, coordination, and draft-writing outside the AVT sessions, and whatnot.  Also, the burden for remote participants in far-away time zones goes up.  In other words, the resource meeting-seconds for those people is not unlimited, and they will have to prioritize differently.    The result could be that what I called "key knowledgable people" would perhaps not attend the mere RTCP-XR or Payload session; and the guys there may be wasting their time doing work that does not make sense architecturally, just to see the hammer coming down at IETF last call.
> -more people get chair positions and are burdened with administrative stuff -> less time to do real work
> -AD load potentially goes up (someone needs to coordinate between those groups, and the AD would seem to me the natural choice)
> -there is no reason to believe that the overall manpower availability goes up through this change, so all the inefficiencies introduced go straight against the available cycles.
> 
> Some of these issues can be solved by joint WG meetings and/or careful chair selection.  However, both options have drawbacks as well.  A joint session would be counter-productive to the allocation of more meeting minutes.  And when you have, say, 8 chairs for four WG, all of which know the RTP architecture well enough, then you have pretty much exhausted, if not overdrawn already, the pool of "key knowledgable people", and burdened them with (in many cases: additional) chair duties.
> 
> If the problem to be solved is chair-workload: add more chairs (but not 6 of them).
> If the problem to be solved is meeting-second shortages: have interim meetings, conf calls, etc.  In other words, stretch out the AVT meeting in the interval between IETF meetings.  Require a web-ex presentation of every draft to be discussed in the AVT session at least 4 weeks before the meeting, with a two hour timeslot for Q/A.  Should I continue with this brainstorm?
> 
> If the problem is something else, I would like to know…
>

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 13 Jan 2011 14:35:30 -0700

Stephan, I see this differently than you. I think you are assuming that four WG will take on more work in net than just one. First I don't think this is true, and even if it is, then I would see that as a good thing as it would be proof that the 1 WG was blocking useful work that the community wanted to do. Let me address your cons inline.

On Jan 12, 2011, at 5:11 PM, Stephan Wenger wrote:

> -the key knowledgeable people in AVT ideally would have to sit in all four meetings so that all four groups can tap their experience.

I view that as the current situation. Right now, given the times on the agenda move around in a meeting, everyone has to be at all the AVT related talks regardless if they want to see just some parts of them or all of them. It seem like the split would improve this. It can't make it worse. 

>  But they may not want to do so, because it leaves less time for cross-area involvement, coordination, and draft-writing outside the AVT sessions, and whatnot.  Also, the burden for remote participants in far-away time zones goes up.  In other words, the resource meeting-seconds for those people is not unlimited, and they will have to prioritize differently.    The result could be that what I called "key knowledgable people" would perhaps not attend the mere RTCP-XR or Payload session; and the guys there may be wasting their time doing work that does not make sense architecturally, just to see the hammer coming down at IETF last call.

Given the current chair bottlenecks, and the fact we have people that would like to do this, I view the bunch more chairs a pro not a con

> -WG scheduling gets more difficult

Having been very involved with scheduling RAI for several years, I strongly disagree. Right now you can't conflict AVT with anything, yet I bet you could conflict the XR metrics with say BLISS without too many problems. 

> -AD load potentially goes up (someone needs to coordinate between those groups, and the AD would seem to me the natural choice)

The AD is going to have to be aware of all the work related to RTP regardless of if it is split in one group or four. I know when I was AD for AVT I felt this split would make things easier for me. 

> -there is no reason to believe that the overall manpower availability goes up through this change, so all the inefficiencies introduced go straight against the available cycles.

I agree the manpower to do AVT technical work does not improve. However, having people who care less about 1 of the four stream be able to ignore theses meetings and go elsewhere would improve the manpower available available to other topics. The administrative work would go from two chairs and split over more. I don't think it significantly increases the total amount of admin-a-triva and having more people doing that is likely to reduce administrative delays. Now you might think the administrative delays have no impact on how many person hours are required to do the technical work but if an admin delay causes something to sit for 3 months, then all the technical people need to spend a bunch of time reloading the context in their brain and getting back up to speed on  where the technical work is. This decreases the efficiently of the the technical work. 

> If the problem to be solved is chair-workload: add more chairs (but not 6 of them).

The more chairs you have for a single WG, the more all chairs think some other chair will do it and nothing happens. See track record of sipping chairs for a concrete example of this and those were all chairs that had proven track record of being effect chairs in other WGs. I agree with your point that if all the top RTP architecture people were suddenly spending all their time doing admin work this would be a disaster. I'm sure the ADs won't do that and that theses people would not accept. But I do think we need to ask, is our pool of really top RTP people that get the architecture growing or shrinking? What can we do to grow it? Dropping in some keen and smart person as chair is a not bad way of growing deep expertise in an area. 

> If the problem to be solved is meeting-second shortages: have interim meetings, conf calls, etc.  In other words, stretch out the AVT meeting in the interval between IETF meetings.  Require a web-e…
( ahhgg I see all kinds of problems with that but lets ignore theses, this is all based on the idea that we want to do more work which I think is an orthogonal issue to the split proposal)

> Thanks for your consideration, and apologies for the wordcount,

When I read what you are saying, I think much of it can be tracked back to if we decide to try and do more work in the 4 groups than we were doing in one group, that may not be a good thing. I agree with that and think we need to manage that careful but that is equally true across the area as a whole as it is in any single WG. The IETF as a whole is familiar with managing that trade off.

---

From: Roni Even <[email-masked]>
Date: Thu, 13 Jan 2011 23:56:07 +0200

Hi Cullen,
I would like to point out that the AVT work was split between the two Ads so
maybe we need a third AD to help with the work.
I would also to state that I did not complain about work load. Some of the
work is limited by the editors and reviewers. 
As for you other comments, see inline.
Roni Even

> Cullen Jennings
> Sent: Thursday, January 13, 2011 11:36 PM
> To: Stephan Wenger
> Cc: [email-masked]; [email-masked]
> Stephan, I see this differently than you. I think you are assuming that
> four WG will take on more work in net than just one. First I don't
> think this is true, and even if it is, then I would see that as a good
> thing as it would be proof that the 1 WG was blocking useful work that
> the community wanted to do. Let me address your cons inline.
> 
> 
> > -the key knowledgeable people in AVT ideally would have to sit in all
> four meetings so that all four groups can tap their experience.
> 
> I view that as the current situation. Right now, given the times on the
> agenda move around in a meeting, everyone has to be at all the AVT
> related talks regardless if they want to see just some parts of them or
> all of them. It seem like the split would improve this. It can't make
> it worse.
[Roni Even] I see this as a pro since we get the relevant people in the
meeting while if we divide I believe that some of them will not follow the
payload and RTCP XR work.
> 
> >  But they may not want to do so, because it leaves less time for
> cross-area involvement, coordination, and draft-writing outside the AVT
> sessions, and whatnot.  Also, the burden for remote participants in
> far-away time zones goes up.  In other words, the resource meeting-
> seconds for those people is not unlimited, and they will have to
> prioritize differently.    The result could be that what I called "key
> knowledgable people" would perhaps not attend the mere RTCP-XR or
> Payload session; and the guys there may be wasting their time doing
> work that does not make sense architecturally, just to see the hammer
> Given the current chair bottlenecks, and the fact we have people that
> would like to do this, I view the bunch more chairs a pro not a con
> 
> Having been very involved with scheduling RAI for several years, I
> strongly disagree. Right now you can't conflict AVT with anything, yet
> I bet you could conflict the XR metrics with say BLISS without too many
> problems.
[Roni Even] The conflicts will continue wand will be bigger since more
chairs add conflicts (each chair has different preferences).
> those groups, and the AD would seem to me the natural choice)
> 
> The AD is going to have to be aware of all the work related to RTP
> regardless of if it is split in one group or four. I know when I was AD
> for AVT I felt this split would make things easier for me.
> 
> > -there is no reason to believe that the overall manpower availability
> goes up through this change, so all the inefficiencies introduced go
> straight against the available cycles.
> 
> I agree the manpower to do AVT technical work does not improve.
> However, having people who care less about 1 of the four stream be able
> to ignore theses meetings and go elsewhere would improve the manpower
> available available to other topics. The administrative work would go
> from two chairs and split over more. I don't think it significantly
> increases the total amount of admin-a-triva and having more people
> doing that is likely to reduce administrative delays. Now you might
> think the administrative delays have no impact on how many person hours
> are required to do the technical work but if an admin delay causes
> something to sit for 3 months, then all the technical people need to
> spend a bunch of time reloading the context in their brain and getting
> back up to speed on  where the technical work is. This decreases the
> efficiently of the technical work.
[Roni Even] Some of the delays is not due to the chairs but to the editors
of the drafts. This is mostly true for payload. It also depends on how many
items the Ads allow. We always have the DISPATCH WG for non chartered work.
> 
> >
> > Some of these issues can be solved by joint WG meetings and/or
> careful chair selection.  However, both options have drawbacks as well.
> A joint session would be counter-productive to the allocation of more
> meeting minutes.  And when you have, say, 8 chairs for four WG, all of
> which know the RTP architecture well enough, then you have pretty much
> exhausted, if not overdrawn already, the pool of "key knowledgable
> people", and burdened them with (in many cases: additional) chair
> duties.
> >
> The more chairs you have for a single WG, the more all chairs think
> some other chair will do it and nothing happens. See track record of
> sipping chairs for a concrete example of this and those were all chairs
> that had proven track record of being effect chairs in other WGs. I
> agree with your point that if all the top RTP architecture people were
> suddenly spending all their time doing admin work this would be a
> disaster. I'm sure the ADs won't do that and that theses people would
> not accept. But I do think we need to ask, is our pool of really top
> RTP people that get the architecture growing or shrinking? What can we
> do to grow it? Dropping in some keen and smart person as chair is a not
> bad way of growing deep expertise in an area.
> 
> meetings, conf calls, etc.  In other words, stretch out the AVT meeting
> in the interval between IETF meetings.  Require a web-ex presentation
> of every draft to be discussed in the AVT session at least 4 weeks
> before the meeting, with a two hour timeslot for Q/A.  Should I
> continue with this brainstorm?
> ( ahhgg I see all kinds of problems with that but lets ignore theses,
> this is all based on the idea that we want to do more work which I
> think is an orthogonal issue to the split proposal)
> 
> >
> When I read what you are saying, I think much of it can be tracked back
> to if we decide to try and do more work in the 4 groups than we were
> doing in one group, that may not be a good thing. I agree with that and
> think we need to manage that careful but that is equally true across
> the area as a whole as it is in any single WG. The IETF as a whole is
> familiar with managing that trade off.
> 
> >
> > Stephan
> >
> >
> >
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 5785 (20110113) __________
> 
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 5785 (20110113) __________
> 

http://www.eset.com

---

From: Roni Even <[email-masked]>
Date: Fri, 14 Jan 2011 00:04:24 +0200

Roberts,

I do not think that the RAMS work should be the motivation to split AVT.

1.       RAMS in today's structure should have gone to DISPATCH and not to
AVT

2.       The time it took was due to discussions on the correctness of the
general solution and not because of AVT load. It always was the high
priority work in AVT.

Roni Even

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert
Sparks
Sent: Thursday, January 13, 2011 11:28 PM
To: Stephan Wenger
Cc: IETF AVT WG; IESG IESG
Subject: Re: [AVT] proposed AVT WG split

Stephan -

There are separable streams of work in AVT - it is really multiple working
groups in one shell at the moment.

While there are key people currently in AVT that would overlap these groups,
they are not the majority of the contributors to the different types of
activities.

The intended positive effect of this explicit division is to allow these
different streams to better parallelize, on list between meetings, not just
during the IETF

in-person meeting time. 

We'd like to try to channel these streams separately for a while. That will
require some additional coordination work from the area directors and
chairs, but

it will bring significant benefits, especially in being able to better
prioritize work items within the streams.  I realize that for folks like
you, who will actively participate 

I have had several participants express frustration, for example, with the
way the RAMs work eclipsed basic architectural work in AVT. 

While that could be  managed in place  (we could have only one working group
per area in the extreme), it has shown itself to be difficult 

I also expect  the separation will make it easier to evaluate when the
energy for a particular effort (such as the XR metrics you point to below)
exists, 

Yes, conflicts between these working groups when they do meet in person will
have to be managed carefully, but we have mechanisms for that. As Keith
noted

separately, we do not anticipate this significantly increasing the
number-of-minutes footprint on any given in-person IETF meeting. Also, your
comments assume all 

four of these groups would have a session at each in-person meeting. I don't
expect that to be the case.

RjS

Hi IESG,

Stephan

http://www.eset.com

http://www.eset.com

---

From: Stephan Wenger <[email-masked]>
Date: Thu, 13 Jan 2011 17:18:59 -0800

On 1.13.2011 13:35 , "Cullen Jennings" <[email-masked]> wrote:

>four WG will take on more work in net than just one. First I don't think
>this is true, and even if it is, then I would see that as a good thing as
>it would be proof that the 1 WG was blocking useful work that the
>community wanted to do. Let me address your cons inline.

Actually, that's not my assumption.  Quite the opposite.  My main argument
is that handling the same number of docs in a larger number of groups
naturally leads to less efficiency.  Also a few additional replies inline.

>all of them. It seem like the split would improve this. It can't make it
>worse.

Your analysis would be correct if the number of meeting seconds for the
(currently two) AVT sessions is similar to the proposed four successor
WG's sessions.  Somehow I doubt that would be the case in the long term,
even if you guys would succeed to enforce it in the short term...

>>far-away time zones goes up.  In other words, the resource
>>meeting-seconds for those people is not unlimited, and they will have to
>>Payload session; and the guys there may be wasting their time doing work
>>that does not make sense architecturally, just to see the hammer coming
>>down at IETF last call.

Really?  At almost every plenary I hear folks whining about how difficult
it is to get *qualified* chairs.  (Some would say that AVT, in its present
incarnation, clearly shows that difficulty)

>strongly disagree. Right now you can't conflict AVT with anything, yet I
>bet you could conflict the XR metrics with say BLISS without too many
>problems.

Perhaps.  You are way more experienced than I am on these matters.

>for AVT I felt this split would make things easier for me.

Interesting.  I didn't know you like multiparty coordination so much :-)
Your insight is not intuitive, though, at least not to me.

>I agree the manpower to do AVT technical work does not improve. However,
>having people who care less about 1 of the four stream be able to ignore
>theses meetings and go elsewhere would improve the manpower available
>available to other topics. The administrative work would go from two
>chairs and split over more. I don't think it significantly increases the
>total amount of admin-a-triva and having more people doing that is likely
>to reduce administrative delays. Now you might think the administrative
>delays have no impact on how many person hours are required to do the
>technical work but if an admin delay causes something to sit for 3
>months, then all the technical people need to spend a bunch of time
>reloading the context in their brain and getting back up to speed on
>where the technical work is. This decreases the efficiently of the the
>technical work.

Roni has answered this point already, and I concur: things are not slow
because of admin delays.  Things are slow because parts of AVT's work is
highly contentious.  That's natural, to me at least.

> 
>
>> 
>> Some of these issues can be solved by joint WG meetings and/or careful
>>chair selection.  However, both options have drawbacks as well.  A joint
>>session would be counter-productive to the allocation of more meeting
>>minutes.  And when you have, say, 8 chairs for four WG, all of which
>>know the RTP architecture well enough, then you have pretty much
>>people", and burdened them with (in many cases: additional) chair duties.
>> 
>The more chairs you have for a single WG, the more all chairs think some
>other chair will do it and nothing happens. See track record of sipping
>chairs for a concrete example of this and those were all chairs that had
>proven track record of being effect chairs in other WGs. I agree with
>your point that if all the top RTP architecture people were suddenly
>spending all their time doing admin work this would be a disaster. I'm
>sure the ADs won't do that and that theses people would not accept. But I
>do think we need to ask, is our pool of really top RTP people that get
>the architecture growing or shrinking? What can we do to grow it?
>Dropping in some keen and smart person as chair is a not bad way of
>growing deep expertise in an area.
>
>>in the interval between IETF meetings.  Require a web-ex presentation of
>>every draft to be discussed in the AVT session at least 4 weeks before
>>the meeting, with a two hour timeslot for Q/A.  Should I continue with
>>this brainstorm?
>this is all based on the idea that we want to do more work which I think
>is an orthogonal issue to the split proposal)
>
>> 
>think we need to manage that careful but that is equally true across the
>area as a whole as it is in any single WG. The IETF as a whole is

---

From: Stephan Wenger <[email-masked]>
Date: Thu, 13 Jan 2011 17:27:08 -0800

Hi Robert,

We have exchanged these arguments before.  I guess it's most efficient for
both of us to agree to disagree, and continue with our day jobŠ (which in
your case may require making a decision I don't like, but I still hope for
what I consider common sense :-).

Just one word on the RAMS example: if you have two major contributing
companies at each other's throat, combined with cultural differences, and a
couple of difficult individuals to spice up the broth, it does not matter a
bit how many groups you have: things are going to be slow in this group.
More importantly for this discussion, slowdown will also occur in related
groups.  Overspill happens.  Horse-trading happens.  Retaliation by blocking
happens.  It's IMO naïve to assume a good set of chair can prevent any of
these deplorable events.

Stephan

From:  "[email-masked]" <[email-masked]>
Date:  Thu, 13 Jan 2011 15:27:55 -0600
To:  Stephan Wenger <[email-masked]>
Cc:  IETF AVT WG <[email-masked]>, IESG IESG <[email-masked]>
Subject:  Re: [AVT] proposed AVT WG split

Stephan -

RjS

On Jan 12, 2011, at 6:11 PM, Stephan Wenger wrote:

> Hi IESG,
> 
> As already communicated in Maastricht, I continue to believe that this step is
> a bad idea.  I didn't attend Beijing, and don't know whether there was any
> discussion about the subject.  I didn't see anything mentioned in the AVT
> minutes, though, nor did I see any discussion since Beijing on ietf@ietf.  If
> there was, some of the points below may be redundant, and I apologize in
> advance.
> 
> Essentially, you guys are suggesting to split one "eternal" WG into four.  I'm
> writing "eternal", because I don't see that any of the WGs can fulfill its
> charter before other work items will likely get chartered with a similar
> that is probably self-evident.  For the XR stuff: metrics pop up all the time,
> like payload formats.  Metrics are also known to make people quick bucks on
> patent licensing.  There will be more metric proposals.  If the RTCP-XR
> metrics ever get momentum in the marketplace, that is.  Somehow, I have my
> coordination, and draft-writing outside the AVT sessions, and whatnot.  Also,
> the burden for remote participants in far-away time zones goes up.  In other
> words, the resource meeting-seconds for those people is not unlimited, and
> they will have to prioritize differently.    The result could be that what I
> called "key knowledgable people" would perhaps not attend the mere RTCP-XR or
> Payload session; and the guys there may be wasting their time doing work that
> does not make sense architecturally, just to see the hammer coming down at
> IETF last call.
> -there is no reason to believe that the overall manpower availability goes up
> through this change, so all the inefficiencies introduced go straight against
> the available cycles.
> 
> meetings, conf calls, etc.  In other words, stretch out the AVT meeting in the
> interval between IETF meetings.  Require a web-ex presentation of every draft
> to be discussed in the AVT session at least 4 weeks before the meeting, with a
> two hour timeslot for Q/A.  Should I continue with this brainstorm?
> 

_______________________________________________ Audio/Video Transport
Working Group [email-masked] https://www.ietf.org/mailman/listinfo/avt

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 13 Jan 2011 18:19:36 -0800

I do believe that some re-organization along the lines proposed by the ADs might help with the unnecessarily long delays for important specs like RAMS. 

If you ask my opinion, RAMS draft was finished rather slowly: my personal target was to finish it in a year. While we had urgency since other organizations were waiting for us, starting the wglc process and completing it took almost a year. We did more than 20 revisions btw. So, editors were not the blocking factor here. 

Yet, many avt-seasoned people told me that 2 years was actually quite a big success for a spec like RAMS. They are probably right, but often a late spec is almost as good as no spec, if not worse, especially if another organization does something that would break something like RTP. It is often impossible to clean up the mess once the damage is done.
 
I don't think the process can get much slower if some form of splitting happens. I am sure you know this better than I do but many other organizations are afraid to bring their work to the IETF in general or seek approval because they are concerned about the delays. If AVT wants to stay relevant in related standards, I think we need to address this problem.

-acbegen

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Sparks
> Sent: Thursday, January 13, 2011 10:28 PM
> To: Stephan Wenger
> it will bring significant benefits, especially in being able to better prioritize work items within the streams.  I realize that for
> folks like you, who will actively participate
> 	As already communicated in Maastricht, I continue to believe that this step is a bad idea.  I didn't attend Beijing, and
> don't know whether there was any discussion about the subject.  I didn't see anything mentioned in the AVT minutes, though,
> nor did I see any discussion since Beijing on ietf@ietf.  If there was, some of the points below may be redundant, and I
> apologize in advance.
> 
> 	Essentially, you guys are suggesting to split one "eternal" WG into four.  I'm writing "eternal", because I don't see that
> any of the WGs can fulfill its charter before other work items will likely get chartered with a similar scope, and in the same
> WG.  For RTP core, RTP extensions, and RTP payloads that is probably self-evident.  For the XR stuff: metrics pop up all the
> time, like payload formats.  Metrics are also known to make people quick bucks on patent licensing.  There will be more
> metric proposals.  If the RTCP-XR metrics ever get momentum in the marketplace, that is.  Somehow, I have my doubts.  But
> that's a different discussion.
> 
> 	-the key knowledgeable people in AVT ideally would have to sit in all four meetings so that all four groups can tap
> their experience.  But they may not want to do so, because it leaves less time for cross-area involvement, coordination, and
> draft-writing outside the AVT sessions, and whatnot.  Also, the burden for remote participants in far-away time zones goes
> up.  In other words, the resource meeting-seconds for those people is not unlimited, and they will have to prioritize
> differently.    The result could be that what I called "key knowledgable people" would perhaps not attend the mere RTCP-XR
> or Payload session; and the guys there may be wasting their time doing work that does not make sense architecturally, just to
> see the hammer coming down at IETF last call.
> 	-there is no reason to believe that the overall manpower availability goes up through this change, so all the
> 	Some of these issues can be solved by joint WG meetings and/or careful chair selection.  However, both options have
> drawbacks as well.  A joint session would be counter-productive to the allocation of more meeting minutes.  And when you
> have, say, 8 chairs for four WG, all of which know the RTP architecture well enough, then you have pretty much exhausted, if
> not overdrawn already, the pool of "key knowledgable people", and burdened them with (in many cases: additional) chair
> duties.
> 
> 	If the problem to be solved is meeting-second shortages: have interim meetings, conf calls, etc.  In other words,
> stretch out the AVT meeting in the interval between IETF meetings.  Require a web-ex presentation of every draft to be
> discussed in the AVT session at least 4 weeks before the meeting, with a two hour timeslot for Q/A.  Should I continue with
> this brainstorm?
>

---

From: Roni Even <[email-masked]>
Date: Fri, 14 Jan 2011 05:30:52 +0200

Hi Ali,
I think that some work can be spawned as a separate group using the dispatch
WG to do so.
As for the time it took I suggest you look at the port mapping draft, when
it started and how the discussion led to changes even late in the process.
This draft and the cname and ssrc ports were the ones delaying the RAMS work
and not the main body
Roni Even

> Ali C. Begen (abegen)
> Sent: Friday, January 14, 2011 4:20 AM
> To: Robert Sparks; Stephan Wenger
> I do believe that some re-organization along the lines proposed by the
> ADs might help with the unnecessarily long delays for important specs
> like RAMS.
> 
> If you ask my opinion, RAMS draft was finished rather slowly: my
> personal target was to finish it in a year. While we had urgency since
> other organizations were waiting for us, starting the wglc process and
> completing it took almost a year. We did more than 20 revisions btw.
> So, editors were not the blocking factor here.
> 
> Yet, many avt-seasoned people told me that 2 years was actually quite a
> big success for a spec like RAMS. They are probably right, but often a
> late spec is almost as good as no spec, if not worse, especially if
> another organization does something that would break something like
> RTP. It is often impossible to clean up the mess once the damage is
> done.
> 
> I don't think the process can get much slower if some form of splitting
> happens. I am sure you know this better than I do but many other
> organizations are afraid to bring their work to the IETF in general or
> seek approval because they are concerned about the delays. If AVT wants
> to stay relevant in related standards, I think we need to address this
> problem.
> 
> -acbegen
> 
> Robert Sparks
> > There are separable streams of work in AVT - it is really multiple
> working groups in one shell at the moment.
> >
> > While there are key people currently in AVT that would overlap these
> groups, they are not the majority of the contributors to
> > the different types of activities.
> > The intended positive effect of this explicit division is to allow
> these different streams to better parallelize, on list between
> > meetings, not just during the IETF
> > in-person meeting time.
> >
> > We'd like to try to channel these streams separately for a while.
> That will require some additional coordination work from
> > the area directors and chairs, but
> > it will bring significant benefits, especially in being able to
> better prioritize work items within the streams.  I realize that for
> > I have had several participants express frustration, for example,
> with the way the RAMs work eclipsed basic architectural
> > work in AVT.
> > While that could be  managed in place  (we could have only one
> working group per area in the extreme), it has shown itself
> > to be difficult
> > I also expect  the separation will make it easier to evaluate when
> the energy for a particular effort (such as the XR metrics
> > you point to below) exists,
> > Yes, conflicts between these working groups when they do meet in
> person will have to be managed carefully, but we have
> > mechanisms for that. As Keith noted
> number-of-minutes footprint on any given in-person IETF
> > meeting. Also, your comments assume all
> > 	As already communicated in Maastricht, I continue to believe that
> this step is a bad idea.  I didn't attend Beijing, and
> > don't know whether there was any discussion about the subject.  I
> didn't see anything mentioned in the AVT minutes, though,
> > nor did I see any discussion since Beijing on ietf@ietf.  If there
> was, some of the points below may be redundant, and I
> > apologize in advance.
> >
> > 	Essentially, you guys are suggesting to split one "eternal" WG
> into four.  I'm writing "eternal", because I don't see that
> > any of the WGs can fulfill its charter before other work items will
> likely get chartered with a similar scope, and in the same
> > WG.  For RTP core, RTP extensions, and RTP payloads that is probably
> self-evident.  For the XR stuff: metrics pop up all the
> > time, like payload formats.  Metrics are also known to make people
> quick bucks on patent licensing.  There will be more
> > metric proposals.  If the RTCP-XR metrics ever get momentum in the
> marketplace, that is.  Somehow, I have my doubts.  But
> > 	-the key knowledgeable people in AVT ideally would have to sit in
> all four meetings so that all four groups can tap
> > their experience.  But they may not want to do so, because it leaves
> less time for cross-area involvement, coordination, and
> > draft-writing outside the AVT sessions, and whatnot.  Also, the
> burden for remote participants in far-away time zones goes
> > up.  In other words, the resource meeting-seconds for those people is
> not unlimited, and they will have to prioritize
> > differently.    The result could be that what I called "key
> knowledgable people" would perhaps not attend the mere RTCP-XR
> > or Payload session; and the guys there may be wasting their time
> doing work that does not make sense architecturally, just to
> careful chair selection.  However, both options have
> > drawbacks as well.  A joint session would be counter-productive to
> the allocation of more meeting minutes.  And when you
> > have, say, 8 chairs for four WG, all of which know the RTP
> architecture well enough, then you have pretty much exhausted, if
> burdened them with (in many cases: additional) chair
> > duties.
> >
> interim meetings, conf calls, etc.  In other words,
> > stretch out the AVT meeting in the interval between IETF meetings.
> Require a web-ex presentation of every draft to be
> > discussed in the AVT session at least 4 weeks before the meeting,
> with a two hour timeslot for Q/A.  Should I continue with
> > this brainstorm?
> >

http://www.eset.com

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 14 Jan 2011 10:27:11 +0100

> incarnation, clearly shows that difficulty)

In this regard I do think splitting it does help. I will publicly state
that I have volunteered to be a candidate to chair AVTCORE and AVTEXT.
For me this is easier to take on as I at least don't need to handle also
the documents of PAYLOAD and XR. I do still remember my 3 years as AVT
chair. When we for a number of meeting had around 600000 words of AVT
documents. I would be much more hesitant to take on the non-split AVT.

In general I think this split is clearly worth trying out. We might
realize down the road that it is over splitting things, and that some
groups can merge or simply close. But lets gather some experience on this.

Yes, it will have downsides, it also will have positive effects. Lets
try this somewhat different trade-off.

I do think smaller groups with less content might allow for a more
focused work in the groups. But it will require the chairs to use the
smaller scope of each group to speed up things. I also agree that when
there is contention on how to do things, things take longer time. And
that needs to be taken into account, and for example do more virtual
interim meetings etc to give the subject more focus.

In conclusion, I think this proposal is well worth trying out. And if it
becomes misery and pain with no gain, then the AD can change things again.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 14 Jan 2011 10:32:56 -0800

I guess you missed my point. Dependencies do cause delay and RAMS is only now being delayed due to the drafts you mentioned. I was not referring to those delays in my email below.

-acbegen

> From: Roni Even [mailto:[email-masked]]
> Sent: Friday, January 14, 2011 4:31 AM
> To: Ali C. Begen (abegen); 'Robert Sparks'; 'Stephan Wenger'
> Cc: 'IETF AVT WG'; 'IESG IESG'
> Subject: RE: [AVT] proposed AVT WG split
> 
> Hi Ali,

---

From: Roni Even <[email-masked]>
Date: Sat, 15 Jan 2011 15:08:04 +0200

Magnus,
I understand your position but what you stated is reflecting my concern
about who will review payloads. You know that most payload drafts authors
are not IETF participants and they may attend only where their documents are
in a review stages to progress the work and afterwards they dropout
Roni

> Sent: Friday, January 14, 2011 11:27 AM
> To: Stephan Wenger
> Cc: Cullen Jennings; [email-masked]; [email-masked]
> work
> >>> stuff -> less time to do real work
> >>

http://www.eset.com

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 17 Jan 2011 11:05:20 +0200

Hi,

> maybe we need a third AD to help with the work.

yes, I have been taking care of a few AVT documents... but AD load is
not the main reason for this split. I think we have already discussed
all the main arguments and counter arguments before and again in this
thread. We probably need running code to understand all the actual prons
and cons of the split... and we will only get it by actually trying this
out.

Cheers,

Gonzalo