Subject: [AVT] Fwd: AVT restructuring discussion

From: Robert Sparks <[email-masked]>
Date: Fri, 19 Mar 2010 09:51:09 -0500

My original transmission of this message is still stuck in the moderator queue
because I attached a graphic large enough to trigger a filter.

Here's the text. The graphic is at
http://www.nostrum.com/~rjsparks/avt.png

RjS

Begin forwarded message:

> From: Robert Sparks <[email-masked]>
> Date: March 18, 2010 3:28:54 PM CDT
> To: [email-masked]
> Subject: AVT restructuring discussion
> 
> 
> The current charter text for AVT identifies four major types of work that this group
> has historically undertaken. Over the last several months, we've heard suggestions
> that these efforts are separable, and tracking them independently will make it less
> likely that a burst of energy in one area overbears progress on other areas, make it
> easier to notice when an effort is lagging due to lack of energy, and make it easier
> to manage meeting and list discussion times maintaining a balance of priorities.
> 
> We are considering chartering separate groups for these areas and are asking
> for community feedback on the following:
> 
> 1) Do we need a standing working group to handle payload format review?
>    For some time, the majority of reviews for those documents have been
>    performed by a small group of people. Would it be sufficient to set up
>    an expert review process for this instead?
> 
> 2) Can the kind of extension work exemplified by the fourth group be
>   performed in a separate from that responsible for maintenance of the 
>   core protocol? (We believe the currently specified work can be, and 
>   future work would need to be assessed to determine if it needed to
>   take place in the core group or not).
> 
> The structure we are currently considering is shown in the attached slide.
> Please send your comments to the list. We have some time set aside
> during the AVT meeting in Anaheim to talk about anything we haven't
> concluded between now and then.
> 
> Robert, Gonzalo, and Cullen.
>

---

From: Roni Even <[email-masked]>
Date: Mon, 22 Mar 2010 20:05:57 +0200

Hi,

Since I did not see any response yet on the list I would like to add my
input on the subject in order to stimulate the discussion.

I responded to each of the questions below.

Roni Even

Roni: My observation is that there is no clear answer. There are some
payload specification that did not attract much discussion while some other
did. The example for the ones that carried discussion from multiple parties
are the 3984bis and SVC drafts, and there are some who had less discussion.
So I am not sure that having just an expert review process is sufficient. We
can probably find a way to expedite payload specifications that are short
and have smaller impact. I had a good experience with RFC4573

Roni: I think that any new work which is not I the WG charter is going to
Dispatch. The fourth group is not general but very specific to RAMS. The
audio level work which was not in the charter came originally to AVT and the
authors were asked to go to Dispatch that decided to do it in AVT

 

Roni: My view is that there is no need to break AVT at the moment and use
Dispatch to decide where to do future work that is not in the charter. If
there is a worry about the fourth group than we can rephrase to clarify that
this is for RAMS only even though this was clear to me from the text.

---

From: Xavier Marjou <[email-masked]>
Date: Mon, 22 Mar 2010 20:07:00 +0100

> this is for RAMS only even though this was clear to me from the text.

+1

---

From: stephen botzko <[email-masked]>
Date: Mon, 22 Mar 2010 13:30:36 -0700

+1 also.

Though many packetization RFCs are quite simple, reasonably often this is
not the case.  So on that point in particular, I believe we still need a WG,
and should not move to expert review.

Stephen Botzko

On Mon, Mar 22, 2010 at 12:07 PM, Xavier Marjou <
[email-masked]> wrote:

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

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 23 Mar 2010 00:14:54 +0100

The fact that a payload description may have complexities that need to be understood does not change that from being an expert review item.

A WG should be defining a closed set of functionality, and when it has done that, it should cease to exist. Keeping a WG around so it can handle a payload description for any codec definition that may come along in the future means that existence is essentially for ever, and that is not the ethos of an IETF WG.

I would also note that while this is in a WG, any payload definition does not appear to be gaining widespread positive consensus in order to move forward. Rather we are seeing payload definitions being drafted and then inspected by two or three experts. I'm not saying that is wrong, but normally it does not need a WG to ensure that occurs.

So if expert review does not fulfil your needs, and we need to allow payload definitions to be defined at wish in the future, do you have some other model that allows them to occur.

regards

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of stephen botzko
Sent: Monday, March 22, 2010 8:31 PM
To: Xavier Marjou
Cc: [email-masked]
Subject: Re: [AVT] Fwd: AVT restructuring discussion

+1 also.

Though many packetization RFCs are quite simple, reasonably often this is not the case.  So on that point in particular, I believe we still need a WG, and should not move to expert review.

Stephen Botzko

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

---

From: Xavier Marjou <[email-masked]>
Date: Thu, 25 Mar 2010 01:44:47 +0100

Just to explain my comment about why "I think there is no need to
break AVT": I have attended most AVT meetings since some few years and
what I've seen is that the WG heavily depends on really few people,
the few ones who know all the specifications and the more than 15
years of discussions around RTP (ie: rtp, rtcp, unicast, multicast,
different codec specificities...). I think that splitting AVT into new
groups would be a mistake because it would be highly surprising that
these few people will participate in all the new groups. The risk is
thus that the new groups will be weaker than the current one.

---

From: "Christian Hoene" <[email-masked]>
Date: Thu, 25 Mar 2010 10:17:38 -0700

Hi,

>thus that the new groups will be weaker than the current one.

Sorry for my personal unqualified comments as an AVT outsider (However, I made my first RTP implementation 12 years ago as a student
of TU-Berlin. Since then, I am teaching RTP)

This discussion gives me the impression that it is time to restructure AVT (and RTP). If only 10 persons in world understand all AVT
drafts and RFC, things must be made more clear. RTP architecture is not like the theory of general relativity. It shall be
understand by many developers and implementers. 

In the last years, there were many RFC and draft which seems to extend RTP/RTCP with another (bug) fix and extension. Now, it seems,
that AVT becomes unmanageable (albeit the chairs do a fantastic good job).

Let me add some spice to the discussion by saying the restructuring the WG AVT group might be only the first step. It is rather time
for RTPv3, which fixes the many weaknesses of RTP to make things easier to manage, to standardize, to understand, to implement, and
to test.

As experts of RTP, you might know very well which things bother you the most - much better than I do. I just want to give here my
(unqualified) suggestions such as
- introducing new levels of abstraction with clear interfaces between them such as
  - separating unicast, multicasts, multipath, and bidirectional modes of operation
- defining a general payload format (or at least an automatic generator for RFC payload drafts)
- better feedback channels
- combing multiple multimedia streams and signaling and control message into the same packet flow...
- and many more

With best regards,

 Christian