Subject: [rtcweb] Proposed Agenda For WG Meetings

From: Eric Rescorla <[email-masked]>
Date: Wed, 20 Feb 2013 16:27:03 -0800

In the tradition of the Interim, I tried to sit down and work out an
agenda that reflects that I think the important concerns are, namely:

- Video codecs (as promised)
- Multiplexing of media flows
- Trickle ICE
- DataChannels

Two notes about cross-WG interaction:

- I'm assuming that most of the MMUSIC time will be used for
  RTCWEB-type stuff, though I left 30 min for other MMUSIC
  business on Tue.

- I don't know how much time AVTEXT needs given the AVTEXT/
  MMUSIC merger on Fri. We can reduce the draft-jennings-rtcweb-plan
  time accordingly based on agenda requests.

Hope this is useful. I'm of course happy to get on a call to discuss
this if that helps.

-Ekr

RTCWEB I: Tuesday 0900-1130
0900 - 0905  Administrivia
0905 - 1100  Video Codec MTI discussion
  - draft-alvestrand-rtcweb-vp8-00 (30 mins)
  -
draft-burman-rtcweb-h264-proposal-00+draft-dbenham-webrtcvideomti-00+draft-marjou-rtcweb-video-codec-00
(30 mins)
  - General discussion 30 min)
  - Call the question of which mandatory to implement video codec to select
(5 min)
  - Next steps (20 min)
 1100 - 1115  draft-ietf-rtcweb-use-cases-and-requirements (LC comments)
 1115 - 1130  draft-ietf-draft-ietf-rtcweb-overview (LC comments)

MMUSIC I: Tuesday 1520-1830
1520 - 1525  Administrivia
1525 - 1605  Trickle ICE (Ivov)
- Under what conditions can you do full trickle (discovery)
- When can checking stop? [UPDATE vs. in-band vs...?]
- SDP/SIP encoding for additional trickle candidates
1605 - 1650  - Bundle
 - draft-ejzak-mmusic-bundle-alternatives (15 min)
 - draft-ietf-mmusic-sdp-bundle-negotiation (15 min)
 - discussion/consensus calls (15 min)
1650 - 1700  [Break]
1700 - 1800  SDP attribute analysis for multiplexing
 - draft-nandakumar-mmusic-sdp-mux-attributes
1800 - 1830  [Other MMUSIC business]

RTCWEB II: Thursday 0900-1130
0900 - 0905  Administrivia
0905 - 1025  Data Channel negotiation
 - draft-jesup-rtcweb-data-protocol (15 min)
 - draft-thomson-rtcweb-data (15 min)
 - draft-marcon-rtcweb-data-channel-management (15 min)
 - Discussion (30 min)
 - Consensus call (5 min)
1025 - 1100 JSEP Update (Uberti)
 - draft-ietf-rtcweb-jsep
1100 - 1115  RTCP-XR (Westerlund)
1115 - 1130  RTP Concepts and relation
- daft-burman-rtcweb-mmusic-media-structure

MMUSIC II: Friday 0900-1100
0900 - 0905  Administrivia
0905 - 0925  Requirements (draft-jennings-mmusic-media-req)
0925 - 1015  PC-track to m-line mapping (draft-jennings-rtcweb-plan)
1015 - 1100  MSID changes to match multiplexing (draft-jennings-rtcweb-plan)

---

From: Suhas Nandakumar <[email-masked]>
Date: Wed, 20 Feb 2013 16:53:27 -0800

+1

Looks Neat !!

./Suhas

On Wed, Feb 20, 2013 at 4:27 PM, Eric Rescorla <[email-masked]> wrote:

>   - Call the question of which mandatory to implement video codec to
> select (5 min)
>   - Next steps (20 min)
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 21 Feb 2013 16:04:54 +0100

Focusing on one aspect....

>   - Call the question of which mandatory to implement video codec to 
I think this is an issue where all the people have most of the 
information required already, and new announcements that will make 
people change their minds are going to have to be fairly significant - 
and that if so, the amount of time required for pointing out that it's 
significant is short.

Therefore, I propose that we cut each presentation to 10 minutes, the 
general discussion to 15 minutes, and spend 5 minutes on calling the 
question.

Furthermore, I suggest we put this last on the last day's agenda.

40 minutes is enough, given that it's essentially yielding 1.5 bits of 
information.
(1 bit = decision yes/no; if yes, what the decision was)

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 21 Feb 2013 07:43:46 -0800

Harald,

Thanks for highlighting this. When I wrote this, I just basically took
the same time allocations from the Atlanta meeting and trimmed
them to fit.

That said, I do think there is merit in having a longer discussion
for a number of reasons:

1. I expect a number of the presentations to focus on quality,
and that's genuinely new information which hasn't been covered
before.

2. I'm of the school that on controversial issues it's important to
allow extensive discussion, so people have a sense of closure.
I realize others may disagree with this theory.

WRT to where it goes in the meeting, this seems like it's pretty
distracting, so I'd like to have it out of the way so people can
focus on the remaining complicated technical issues. If the
only reason is to keep it short, presumably the chairs can
manage that.

Best,
-Ekr

On Thu, Feb 21, 2013 at 7:04 AM, Harald Alvestrand <[email-masked]>wrote:
>>   - draft-burman-rtcweb-h264-**proposal-00+draft-dbenham-**
>> webrtcvideomti-00+draft-**marjou-rtcweb-video-codec-00 (30 mins)
> information required already, and new announcements that will make people
> change their minds are going to have to be fairly significant - and that if
> so, the amount of time required for pointing out that it's significant is
> short.
>

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Thu, 21 Feb 2013 15:54:49 +0000

I'm going to again object to having the video codec discussion in the IETF venue. The choice of mandatory video codecs within the browser context is a presentation-layer choice and highly related to a discussion that has already happened in the W3C context for video playback.

Arguing that because the codecs produce bits and those bits go on the wire and then somehow that makes it an IETF issue is specious. The text of the JavaScript sent to the browser also goes "on the wire" and is also out of scope for the IETF.

If the relevant browser vendors and other interested parties would like to have this discussion, it should happen within the W3C.

Matthew Kaufman

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Thursday, February 21, 2013 7:44 AM
To: Harald Alvestrand
Cc: [email-masked]
Subject: Re: [rtcweb] Time allocation for video discussion (Re: Proposed Agenda For WG Meetings)

Harald,

Best,
-Ekr

On Thu, Feb 21, 2013 at 7:04 AM, Harald Alvestrand <[email-masked]<mailto:[email-masked]>> wrote:

RTCWEB I: Tuesday 0900-1130
0900 - 0905  Administrivia
0905 - 1100  Video Codec MTI discussion
  - draft-alvestrand-rtcweb-vp8-00 (30 mins)
  - draft-burman-rtcweb-h264-proposal-00+draft-dbenham-webrtcvideomti-00+draft-marjou-rtcweb-video-codec-00 (30 mins)
  - General discussion 30 min)
  - Call the question of which mandatory to implement video codec to select (5 min)
  - Next steps (20 min)
I think this is an issue where all the people have most of the information required already, and new announcements that will make people change their minds are going to have to be fairly significant - and that if so, the amount of time required for pointing out that it's significant is short.

Therefore, I propose that we cut each presentation to 10 minutes, the general discussion to 15 minutes, and spend 5 minutes on calling the question.

40 minutes is enough, given that it's essentially yielding 1.5 bits of information.
(1 bit = decision yes/no; if yes, what the decision was)

---

From: Ted Hardie <[email-masked]>
Date: Thu, 21 Feb 2013 14:26:01 -0800

On Thu, Feb 21, 2013 at 7:54 AM, Matthew Kaufman (SKYPE)
<[email-masked]> wrote:
> I’m going to again object to having the video codec discussion in the IETF
> venue. The choice of mandatory video codecs within the browser context is a
> presentation-layer choice and highly related to a discussion that has
> already happened in the W3C context for video playback.
>
>
>
> Arguing that because the codecs produce bits and those bits go on the wire
> and then somehow that makes it an IETF issue is specious. The text of the
> JavaScript sent to the browser also goes “on the wire” and is also out of
> scope for the IETF.
>
>
>
> If the relevant browser vendors and other interested parties would like to
> have this discussion, it should happen within the W3C.
>
Hi Matthew,

Bullets 4 and 5 of the RTCWEB charter call out this work of this type
as in-scope, with codecs
mentioned specifically.  If working group participants are persuaded
by your argument, though, I point out
that the W3C has already sent a liaison statement on this topic
(http://datatracker.ietf.org/liaison/1215/).
If the working group wishes to be guided by the W3C on this topic, in
other words, it can use this liaison statement
as guidance.

regards,

Ted Hardie

---

From: "Mandyam, Giridhar" <[email-masked]>
Date: Thu, 21 Feb 2013 22:36:42 +0000

Ted:
> I point out that the W3C has already sent a liaison statement on this topic (http://datatracker.ietf.org/liaison/1215/). If the working group wishes to be guided by the W3C on this topic, in other words, it can use this liaison statement as guidance.

Note that the W3C did not consult with member companies in forming the referenced liaison statement. I do not consider this statement to be indicative of any kind of discussion ever having taken place within the W3C in which member companies were allowed to be involved.

-Giri Mandyam, Qualcomm Innovation Center

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted Hardie
Sent: Thursday, February 21, 2013 2:26 PM
To: Matthew Kaufman (SKYPE)
Cc: [email-masked]
Subject: Re: [rtcweb] Time allocation for video discussion (Re: Proposed Agenda For WG Meetings)

On Thu, Feb 21, 2013 at 7:54 AM, Matthew Kaufman (SKYPE) <[email-masked]> wrote:
> I'm going to again object to having the video codec discussion in the 
> IETF venue. The choice of mandatory video codecs within the browser 
> context is a presentation-layer choice and highly related to a 
> discussion that has already happened in the W3C context for video playback.
>
>
>
> Arguing that because the codecs produce bits and those bits go on the 
> wire and then somehow that makes it an IETF issue is specious. The 
> text of the JavaScript sent to the browser also goes "on the wire" and 
> is also out of scope for the IETF.
>
>
>
> If the relevant browser vendors and other interested parties would 
> like to have this discussion, it should happen within the W3C.
>
Hi Matthew,

Bullets 4 and 5 of the RTCWEB charter call out this work of this type as in-scope, with codecs mentioned specifically.  If working group participants are persuaded by your argument, though, I point out that the W3C has already sent a liaison statement on this topic (http://datatracker.ietf.org/liaison/1215/).
If the working group wishes to be guided by the W3C on this topic, in other words, it can use this liaison statement as guidance.

regards,

Ted Hardie

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 21 Feb 2013 17:11:22 -0800

This message didn't make it through the Microsoft email system (looked 
like spam), so I'm replying on-thread from my personal account...

On 2/21/2013 2:26 PM, Ted Hardie wrote:
> mentioned specifically.

I think you mean bullet 6, as neither 4 nor 5 is applicable in the copy 
of the charter here: http://datatracker.ietf.org/wg/rtcweb/charter/

But just because the charter mistakenly calls this out as something for 
the IETF to solve doesn't mean that the IETF is the right place to have 
the discussion. I will note that several other IETF protocols for A/V 
interoperability, such as SIP, have enjoyed wide success without wasting 
any valuable meeting time trying to standardize on a single audio and 
video codec... and there's certainly many other unresolved issues within 
the IETF that are blocking a final W3C API specification.

>   If working group participants are persuaded

I will second the note that no W3C member companies contributed to this 
liason statement, nor was it discussed in any WEBRTC meeting that I or 
any of my coworkers has attended, and so this isn't super helpful as 
guidance... misleading, in fact.

My employer's position is outlined in blog posts such as 
http://blogs.windows.com/windows/b/bloggingwindows/archive/2010/05/19/another-follow-up-on-html5-video-in-ie9.aspx

Nothing has changed since this and related postings were made. The codec 
that has been submitted as an alternative to H.264 is still not the 
product of any standards body activity (and so does not enjoy any of the 
IPR protections for users that it might otherwise have) and the company 
who has submitted this has not changed their license agreement in any 
substantial way (to, for instance, include indemnification).

If there is a plan for a substantial change along these lines to be 
announced prior to the (inappropriate) discussion at the upcoming IETF 
meeting, I hope it can be made public with sufficient time for our large 
legal department to review it, otherwise I don't see how anyone could 
expect a revised opinion at that time.

Matthew Kaufman

---

From: Stefan Håkansson LK <[email-masked]>
Date: Fri, 22 Feb 2013 10:18:03 +0100

> expect a revised opinion at that time.

I agree. Any input related to legal or licensing aspects would have to 
come real soon to be able to have a meaningful discussion at the 
upcoming meeting for the reason Matthew gives.

Stefan

---

From: Ted Hardie <[email-masked]>
Date: Fri, 22 Feb 2013 07:42:50 -0800

Hi Matthew,

> But just because the charter mistakenly calls this out as something for the
> IETF to solve doesn't mean that the IETF is the right place to have the
> discussion. I will note that several other IETF protocols for A/V
> interoperability, such as SIP, have enjoyed wide success without wasting any
> valuable meeting time trying to standardize on a single audio and video
> codec...

You may have heard the chairs use the term "negotiation failure" in the context
of selecting mandatory to implement codecs.   This phrase was taken from one of
Henning's talking points on practical interoperability in SIP contexts
(see, for example,
http://www.ietf.org/mail-archive/web/ecrit/current/msg07453.html).  I
think Henning
knows a bit about SIP and the practical interoperability challenges it
has faced.  It
has also been pointed out by Hadriel (and several others) that the
cost of negotiation failure
in the case of video is much higher than it is for VoIP.  I understand
that you disagree,
but the charter is pretty clear that this is in scope, and, speaking
personally, I believe
the advantages of having an MTI are pretty clear.

> and there's certainly many other unresolved issues within the IETF
> that are blocking a final W3C API specification.

On this point, at least, I think there is broad agreement.  We are
working on the agenda now
to make sure we get the priorities for the work in order, and I hope
everyone takes the time
to contribute to that discussion.

regards,

Ted Hardie

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 22 Feb 2013 08:18:28 -0800

> Henning's talking points on practical interoperability in SIP contexts

Yes, but it is also a good description for what's going to happen when 
this actually gets discussed. There are parties in the room who cannot 
under any circumstances ship one of the two options, and parties in the 
room who cannot under any circumstances ship the other. At least given 
the current IPR issues associated with each option.

Despite the charter, ultimately the W3C specification will need to be 
ratified, and having a pointer in there to an IETF document which 
mandates a codec which some of the parties in the room cannot use will 
be a blocking issue, and thus a subject of W3C discussion anyway, 
whether or not we take up valuable IETF meeting time discussing it again.

Matthew Kaufman

---

From: Ron <[email-masked]>
Date: Sat, 23 Feb 2013 23:04:17 +1030

On Fri, Feb 22, 2013 at 08:18:28AM -0800, Matthew Kaufman wrote:
> Yes, but it is also a good description for what's going to happen
> when this actually gets discussed. There are parties in the room who
> cannot under any circumstances ship one of the two options, and
> parties in the room who cannot under any circumstances ship the
> other. At least given the current IPR issues associated with each
> option.

You still seem to be conflating "cannot" and "will not" as if they are
somehow equivalent and positions of equal merit.  And for extra irony,
doing it in the same breath as you accuse a liaison statement that
simply outlines "a few background facts" of being misleading.

VP8 offers the same poison-pill indemnity as Opus.  Since we've already
seen people who were around since the very beginning of the CODEC WG
(to strenuously oppose its formation, and resist its later progress)
submit very late (and also apparently very spurious) IPR claims against
it, I don't see how the real world situation is actually any different
between them.

Both offer stronger protection against hostile IPR assertions, equally
to *all* users, than H.264 does - and neither fundamentally excludes
the enormous market of developers whose distribution model makes it
impossible to track and count and extort royalties from users.

That's a very different and more intractable problem to "my company
doesn't like or want to support that developer model".  Since it
already uses that model too for some of its products, saying that it
"cannot under any circumstances support it", goes beyond misleading
to plainly disingenuous.

It's fine for different groups to have different preferences, and
for organisations to want to protect their profit mechanisms.
But that is not a relevant concern of the IETF - while underwriting
the success prospects of a standard through broad availability and
best practice for interoperability, quite definitely is.

  Ron