Subject: [rtcweb] Uploaded unified minutes for both days of IETF 86 meetings

From: Ted Hardie <[email-masked]>
Date: Fri, 5 Apr 2013 13:28:45 -0700

Howdy,

We have now uploaded unified minutes with the corrections we received on
the list; thanks to all who reviewed.  If you have not yet done so, there
is still time to update, so please take a look.

thanks,

Ted Hardie, for the chairs.

---

From: Gaelle Martin-Cocher <[email-masked]>
Date: Mon, 8 Apr 2013 15:54:50 +0000

Dear all,

Some corrections made by Magnus and sent to the list on April 2nd were lost; page 3 the first changes under the VP8 IPR presentation should read:
VP8 IPR: http<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-10.pdf>://<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-10.pdf>www<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-10.pdf>.<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-10.pdf>ietf<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-10.pdf>.<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-10.pdf>org<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-10.pdf>/<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-10.pdf>proceedings<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-10.pdf>/86/<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-10.pdf>slides<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-10.pdf>/<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-10.pdf>slides<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-10.pdf>-86-<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-10.pdf>rtcweb<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-10.pdf>-10.<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-10.pdf>pdf<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-10.pdf>
Serge Lachapelle presenting

Gaelle reiterated that more details are needed on the recent announcement and noted that there are more patent holders for H.264 in the ITU-T database that are not part of MPEG-LA.  She asked if the IETF could send letters to solicit information from these IPR-holders.

Also, please see below some corrections/clarifications:
In the same section:
The MPEG-LA pool is a subset.  She re-iterated her view that in light of the answers provided by the area directors, the IETF is not the place for clarifying this.

In the section:
Mandatory to Implement Video Codec discussion
VP8 Technical: http<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-9.pdf>://<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-9.pdf>www<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-9.pdf>.<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-9.pdf>ietf<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-9.pdf>.<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-9.pdf>org<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-9.pdf>/<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-9.pdf>proceedings<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-9.pdf>/86/<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-9.pdf>slides<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-9.pdf>/<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-9.pdf>slides<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-9.pdf>-86-<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-9.pdf>rtcweb<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-9.pdf>-9.<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-9.pdf>pdf<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-9.pdf>
Harald Alvestrand presenting
....
Gaelle then spoke, saying that in light of the inaccuracy of the tests and related data the venue is wrong, that  MPEG is the right place to perform those tests and IETF should rely on MPEG results before making a decision.  She wants to be sure that the tests are accurate, and that the test set and methodology used in IETF are problematic.

In the last section:
It was clearly indicated that additional questions should not be the one that were already asked during the meeting or sent on the reflector. (Some of these are still pending answers).

Sense of the room query: http<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-14.pd>://<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-14.pd>www<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-14.pd>.<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-14.pd>ietf<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-14.pd>.<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-14.pd>org<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-14.pd>/<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-14.pd>proceedings<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-14.pd>/86/<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-14.pd>slides<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-14.pd>/<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-14.pd>slides<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-14.pd>-86-<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-14.pd>rtcweb<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-14.pd>-14.<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-14.pd>pd<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-14.pd>f
Robert Sparks (as a favor to the chairs)

The questions to be asked were put on the slides.  If you can't answer these question, think about what you really need.  Come articulate at the mic after the questions, issues or questions that have not already being posted on the reflector or that have not been raised during the meeting.

Thank you
Sincerely,
Gaëlle

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted Hardie
Sent: Friday, April 05, 2013 4:29 PM
To: [email-masked]
Subject: [rtcweb] Uploaded unified minutes for both days of IETF 86 meetings

Howdy,

We have now uploaded unified minutes with the corrections we received on the list; thanks to all who reviewed.  If you have not yet done so, there is still time to update, so please take a look.

thanks,

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Ted Hardie <[email-masked]>
Date: Mon, 8 Apr 2013 10:24:05 -0700

Thanks for pointing these out; they'll get fixed in the next update.

Ted

On Mon, Apr 8, 2013 at 8:54 AM, Gaelle Martin-Cocher <
[email-masked]> wrote:

>  Dear all,****
>
> ** **
>
> Some corrections made by Magnus and sent to the list on April 2nd were
> lost; page 3 the first changes under the VP8 IPR presentation should read:
> ****
>
> VP8 IPR: http<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-10.pdf>
> :// <http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-10.pdf>www<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-10.pdf>
> . <http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-10.pdf>ietf<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-10.pdf>
> . <http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-10.pdf>org<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-10.pdf>
> / <http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-10.pdf>
> proceedings<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-10.pdf>
> /86/ <http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-10.pdf>
> slides <http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-10.pdf>
> / <http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-10.pdf>
> slides <http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-10.pdf>
> -86- <http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-10.pdf>
> rtcweb <http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-10.pdf>
> -10. <http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-10.pdf>
> pdf <http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-10.pdf>***
> *
>
> Serge Lachapelle presenting****
>
> ** **
>
> Gaelle reiterated that more details are needed on the recent announcement
> and noted that there are more patent holders for H.*264 in the ITU-T
> database* that are not *part of* MPEG*-LA*.  She asked if the IETF could
> send letters to solicit information from *these IPR-holders.*  ****
>
> ** **
>
> ** **
>
> Also, please see below some corrections/clarifications:****
>
> In the same section:****
>
> The MPEG-LA pool is a subset.  She re-iterated her view that* in light of
> the answers provided by the area directors*, the IETF is not the place
> for clarifying this.  ****
>
> ** **
>
> In the section:****
>
> Mandatory to Implement Video Codec discussion****
>
> VP8 Technical: http<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-9.pdf>
> :// <http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-9.pdf>www<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-9.pdf>
> . <http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-9.pdf>ietf<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-9.pdf>
> . <http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-9.pdf>org<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-9.pdf>
> / <http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-9.pdf>
> proceedings<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-9.pdf>
> /86/ <http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-9.pdf>
> slides <http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-9.pdf>/<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-9.pdf>
> slides <http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-9.pdf>
> -86- <http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-9.pdf>
> rtcweb <http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-9.pdf>
> -9. <http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-9.pdf>pdf<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-9.pdf>
> ****
>
> Harald Alvestrand presenting****
>
> ….****
>
> Gaelle then spoke, saying that *in light of the inaccuracy of the tests
> and related data* the venue is wrong, that  MPEG is the right place* to
> perform those tests and IETF should rely on MPEG results before making a
> decision*.  She wants to be sure that the tests are accurate, and that
> the test set and methodology used in IETF are problematic.****
>
> ** **
>
> In the last section:****
>
> It was clearly indicated that additional questions should not be the one
> that were already asked during the meeting or sent on the reflector. (Some
> of these are still pending answers).****
>
> ** **
>
> Sense of the room query: http<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-14.pd>
> :// <http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-14.pd>www<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-14.pd>
> . <http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-14.pd>ietf<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-14.pd>
> . <http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-14.pd>org<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-14.pd>
> / <http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-14.pd>
> proceedings<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-14.pd>
> /86/ <http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-14.pd>
> slides <http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-14.pd>/<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-14.pd>
> slides <http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-14.pd>
> -86- <http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-14.pd>
> rtcweb <http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-14.pd>
> -14. <http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-14.pd>pd<http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-14.pd>
> f****
>
> Robert Sparks (as a favor to the chairs)****
>
> ** **
>
> The questions to be asked were put on the slides.  If you can’t answer
> these question, think about what you really need.  Come articulate at the
> mic after the questions, *issues or questions that have not already being
> posted on the reflector or that have not been raised during the meeting*.
> ****
>
> ** **
>
> Thank you****
>
> Sincerely,****
>
> Gaëlle****
>
> ** **
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Ted Hardie
> *Sent:* Friday, April 05, 2013 4:29 PM
> *To:* [email-masked]
> *Subject:* [rtcweb] Uploaded unified minutes for both days of IETF 86
> meetings****
>
> ** **
>
> Howdy,
>
> Ted Hardie, for the chairs.****
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from
> your system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be
> unlawful.
>

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 8 Apr 2013 12:13:12 -0700

Ted --
I have gone over the minutes from the DataChannel sessions.  It appears to me that there are some issues with the minutes.  Comments below on Randell's session.  More to follow. 
Presenter: Randell Jesep Slides:http://www.ietf.org/proceedings/86/slides/slides86rtcweb5.pdf
[BA] What specific drafts did this presentation relate to?  I think it's quite important to be specific, since comments during the session need a context.  For example, did this presentation relate to the individual submission draft-jesup-rtcweb-data-protocol, the RTCWEB WG work item draft-ietf-rtcweb-data-channel, or the MMUSIC WG work item draft-ietf-mmusic-sctp-sdp?  Since the presentation refers to SDP,  at least the MMUSIC WG work item seems relevant, no? 
Richard Ejzak asked what is our bottom line? He sees this as going backwardsfrom interim. SDP negotiation removed
[BA] Randell's proposal did not propose to remove all SDP negotiation.  It leaves negotiation of DTLS port and SCTP associations in SDP, but removes SDP negotiation of streams.   It seems important to be specific about what was being discussed (e.g. modifications to draft-ietf-mmusic-sctp-sdp), so as to be able to understand what commenters were referring to. 
Peter Thatcher commented that he thinks the presenter's proposal is great
[BA] It is hard for me to understand what Peter meant without some additional context (e.g. was the comment only about the proposal to remove stream negotiation from SDP, or potentially a comment about draft-jesup-rtcweb-data-protocol?)
Randell added that the solution DO have a protocol parameter with this still.
[BA] What "solution" is being referred to here?  The proposal in draft-jesup-rtcweb-data-protocol?   A post to the mailing list?   The participants were discussing how streams are set up, but it wasn't clear to me what was being referred to. 
Harald Alverstrand stated that he Agree with this. Glad got data channel negotiation out of the document. 
[BA] Specifically I believe Harald was referring to Randell's proposal to remove stream negotiation from draft-ietf-mmusic-sctp-sdp.  Since stream negotiation is still in the document, "got" is not correct.  
Salvatore Loreto stated that he like this proposal  should negotiate only one way and should not use SDP.
[BA] Again, I believe that this meant "should not use SDP for stream negotiation".  
Jerome Marcon added that the draft does not really contain all this material now, therefore text needs to be added. Randell agreed that there need to be added
[BA] What does "the draft" refer to here?  draft-ietf-mmusic-sctp-sdp?  That makes the most sense to me since stream negotiation was still in there. 
Chairs asked how many had read the draft, which was couple of dozen. Chairsurge people to read and report new issues to the mailing list. Request thatRandell takes the open issues in separate emails to the list.
[BA] Again what is "the draft" referring to here?  Since draft-ietf-mmusic-sctp-sdp didn't contain the material that was presented, was this what the chairs were referring to?  Or did they mean draft-ietf-rtcweb-data-channel?  I have read all the above docs, and have gone over the MeetEcho session, and still don't understand what was being referred to here, (or even why it was relevant). 
Salvatore commented that one open issue is if we are going to defineprioritization between channels. Randell responded that prioritization istricky as it interacts with congestion control
[BA] Prioritization is discussed in draft-jesup-rtcweb-data-protocol, but not in the other documents, so was Salvatore referring to that document here?  
Randell responded that he has no issue of adding this to the list of open issues.
[BA] Open issues on what document?

Date: Fri, 5 Apr 2013 13:28:45 -0700
From: [email-masked]
To: [email-masked]
Subject: [rtcweb] Uploaded unified minutes for both days of IETF 86 meetings

Howdy,

thanks,

_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Randell Jesup <[email-masked]>
Date: Mon, 08 Apr 2013 16:30:01 -0400

On 4/8/2013 3:13 PM, Bernard Aboba wrote:
> Ted --
>
> I have gone over the minutes from the DataChannel sessions.  It 
> appears to me that there are some issues with the minutes.  Comments 
> below on Randell's session.  More to follow.
>
> Presenter: Randell Jesep Slides:
> http://www.ietf.org/proceedings/86/slides/slides86rtcweb5.pdf

Sigh.  I was waiting for that misspelling to occur.... :-(

>
> [BA] What specific drafts did this presentation relate to?  I think 
> it's quite important to be specific, since comments during the session 
> need a context.  For example, did this presentation relate to the 
> individual submission draft-jesup-rtcweb-data-protocol, the RTCWEB WG 
> work item draft-ietf-rtcweb-data-channel, or the MMUSIC WG work item 
> draft-ietf-mmusic-sctp-sdp?  Since the presentation refers to SDP,  at 
> least the MMUSIC WG work item seems relevant, no?

draft-jesup-rtcweb-data-protocol (as stated right above what you copied, 
on the other side of a page break).  It *impacts* 
draft-ietf-mmusic-sctp-sdp.

> Richard Ejzak asked what is our bottom line? He sees this as going 
> backwards
> from interim. SDP negotiation removed
>
> [BA] Randell's proposal did not propose to remove all SDP negotiation. 
>  It leaves negotiation of DTLS port and SCTP associations in SDP, but 
> removes SDP negotiation of streams. It seems important to be specific 
> about what was being discussed (e.g. modifications to 
> draft-ietf-mmusic-sctp-sdp), so as to be able to understand what 
> commenters were referring to.

Correct.  "Initial SDP negotiation of individual DataChannels removed" 
would be more accurate.

> [BA] It is hard for me to understand what Peter meant without some 
> additional context (e.g. was the comment only about the proposal to 
> remove stream negotiation from SDP, or potentially a comment about 
> draft-jesup-rtcweb-data-protocol?)

The implied context in the room was that what was presented and in the 
draft (data-protocol) was great.

> [BA] What "solution" is being referred to here?  The proposal in 
> draft-jesup-rtcweb-data-protocol?   A post to the mailing list?   The 
> participants were discussing how streams are set up, but it wasn't 
> clear to me what was being referred to.

I think this quote is confused.  (We're talking about the whole RTT 
thing here mostly).  I *think* I said we *do* have a protocol parameter 
on channels, and so that can be used to handle channels created after 
the initial offer/answer.  I also stated earlier that I'd responded to a 
very similar comment on the list with a more detailed response (the 
previous night, so people might not have read it yet).

> [BA] Specifically I believe Harald was referring to Randell's proposal 
> to remove stream negotiation from draft-ietf-mmusic-sctp-sdp.  Since 
> stream negotiation is still in the document, "got" is not correct.

Yes, given this wasn't a joint session and we didn't update the other 
draft in time for the cutoff, technically that's correct, but in 
practice the SDP is the way to do negotiation for DataChannels as 
defined in rtcweb, so regardless if the change had been formally applied 
yet they're linked.

> [BA] Again, I believe that this meant "should not use SDP for stream 

Correct.  (And Salvatore is the other author on the mmusic draft.)

>
> Jerome Marcon added that the draft does not really contain all this 
> material now, therefore text needs to be added. Randell agreed that 
> there need to be added
>
> [BA] What does "the draft" refer to here?  draft-ietf-mmusic-sctp-sdp? 
>  That makes the most sense to me since stream negotiation was still in 
> there.

Unclear, but it may well refer to the mmusic stuff, and might also refer 
to the even/odd details.

>
> Chairs asked how many had read the draft, which was couple of dozen. 
> Chairs
> urge people to read and report new issues to the mailing list. Request 
> that
> Randell takes the open issues in separate emails to the list.
>
> [BA] Again what is "the draft" referring to here?  Since 
> draft-ietf-mmusic-sctp-sdp didn't contain the material that was 
> presented, was this what the chairs were referring to?  Or did they 
> mean draft-ietf-rtcweb-data-channel?  I have read all the above docs, 
> and have gone over the MeetEcho session, and still don't understand 
> what was being referred to here, (or even why it was relevant).

draft-jesup-data-protocol (again, stated above the page-break in the 
notes, and on the title page of my slides)

>
> Salvatore commented that one open issue is if we are going to define
> prioritization between channels. Randell responded that prioritization is
> tricky as it interacts with congestion control
>
> [BA] Prioritization is discussed in draft-jesup-rtcweb-data-protocol, 
> but not in the other documents, so was Salvatore referring to that 
> document here?
>

Ditto the comments above.  draft-jesup-data-protocol

-- 
Randell Jesup
[email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 9 Apr 2013 09:11:54 +0200

Bernard,

We definitely should try to improve the minutes with the context. But, I
do have to make an observation. We are commonly this poor at being exact
in referencing and being specific when discussing at the mic. Just
something for everyone to think about. That would help and reduce the
risk that a note-taker or chair cleaning up minutes to wrongly attribute
statements to the wrong context.

It would be good if the persons who actually made statements around this
could help clarify what was intended to be referenced.

Thanks

Magnus

On 2013-04-08 21:13, Bernard Aboba wrote:
> Ted --
> 
> I have gone over the minutes from the DataChannel sessions.  It appears
> to me that there are some issues with the minutes.  Comments below on
> Randell's session.  More to follow. 
> 
> [BA] What specific drafts did this presentation relate to?  I think it's
> quite important to be specific, since comments during the session need a
> context.  For example, did this presentation relate to the individual
> submission draft-jesup-rtcweb-data-protocol, the RTCWEB WG work item
> draft-ietf-rtcweb-data-channel, or the MMUSIC WG work item
> participants were discussing how streams are set up, but it wasn't clear
> to me what was being referred to. 
> 
> Chairs asked how many had read the draft, which was couple of dozen. Chairs
> urge people to read and report new issues to the mailing list. Request that
> presented, was this what the chairs were referring to?  Or did they mean
> draft-ietf-rtcweb-data-channel?  I have read all the above docs, and
> have gone over the MeetEcho session, and still don't understand what was
> being referred to here, (or even why it was relevant). 
> 
> ------------------------------------------------------------------------
> the list; thanks to all who reviewed.  If you have not yet done so,
> there is still time to update, so please take a look.
> 
> thanks,
> 
> _______________________________________________ rtcweb mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb
> 
> 

-- 

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: Magnus Westerlund <[email-masked]>
Date: Thu, 18 Apr 2013 11:39:00 +0200

Hi,

I have now updated the minutes trying to clarify the context and the
corrections. Please check if you think this makes it clearer. If not I
am happy to introduce additional clarifications, but please be explicit
about what should be changed.

http://www.ietf.org/proceedings/86/minutes/minutes-86-rtcweb

cheers

Magnus Westerlund

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 19 Apr 2013 18:04:06 -0700

> http://www.ietf.org/proceedings/86/minutes/minutes-86-rtcweb

Peter Thatcher commented that he thinks the presenter's proposal(draftjesuprtcwebdataprotocol04)  is great.
[BA] My impression was that this remark more related to the presentation suggestions relating to removing of stream negotiation from SDP, which isn't covered in draft-jesup-rtcweb-data-protocol-04.
Harald Alvestrand stated that he Agree with this. Glad got data channelnegotiation out of the document. 
[BA]  Since draft-jesup-rtcweb-data-protocol is about setting up data channels this doesn't make sense to me.  Was Harald perhaps referring to getting data channel negotiation "out of SDP"?

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 22 Apr 2013 16:14:54 +0200

Harald and Peter,

Can you bring any clarity on what you supported?

Cheers

Magnus

On 2013-04-20 03:04, Bernard Aboba wrote:
> Peter Thatcher commented that he thinks the presenter's proposal
> (draftjesuprtcwebdataprotocol04)  is great.
> 
> [BA] My impression was that this remark more related to the presentation
> suggestions relating to removing of stream negotiation from SDP, which
> isn't covered in draft-jesup-rtcweb-data-protocol-04.
> 
> [BA]  Since draft-jesup-rtcweb-data-protocol is about setting up data
> channels this doesn't make sense to me.  Was Harald perhaps referring to
> getting data channel negotiation "out of SDP"?  
> 
> 
> 
> 

-- 

Magnus Westerlund

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 23 Apr 2013 00:22:14 +0200

It clearly wasn't clear to Bernard either :-)

I supported what draft-jesup was suggesting - negotiating usage of SCTP in
SDP, and not mentioning individual data channels in the SDP.

---

From: Peter Thatcher <[email-masked]>
Date: Tue, 23 Apr 2013 11:05:06 -0700

I support the proposal that we agreed to in Orlando, and which includes
what Harald just said:

- SCTP is in SDP only to set up the transport, and individual data channels
are not mentioned in the SDP.
- The send and receive SID are the same for a given data channel.
- The JS can specify the SID, and an even/odd mechanism is used by the
browser for selecting the SID if not chosen by the JS.
- There is an in-band "OPEN" message, but it is optional.

That's what I support.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 24 Apr 2013 09:44:04 +0200

Ok,

so what do you want me to put in the minutes? Do you consider this to be
captured in the slide set, or some slides or in the actual draft?

Just want to be clear and maybe discourage these blanket +1 or I support
statements on the mic without making clear what one supports.

Cheers

Magnus

On 2013-04-23 20:05, Peter Thatcher wrote:
> - SCTP is in SDP only to set up the transport, and individual data
> channels are not mentioned in the SDP.
> On Mon, Apr 22, 2013 at 3:22 PM, Harald Alvestrand <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     I supported what draft-jesup was suggesting - negotiating usage of
>     SCTP in SDP, and not mentioning individual data channels in the SDP.
> 
> 
> 
>     On Mon, Apr 22, 2013 at 4:14 PM, Magnus Westerlund
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>         Harald and Peter,
> 
>         > Harald Alvestrand stated that he Agree with this. Glad got
>         data channel
>         > negotiation out of the document.
>         >
>         <tel:%2B46%2010%207148287>
>         <tel:%2B46%2073%200949079>
>         <mailto:[email-masked]>

-- 

Magnus Westerlund

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 24 Apr 2013 17:17:49 -0700

I considered the slides to represent what I support.  I'll try to be more
specific at the mic next time.  But I guess if I could go back I would say
"I support the symmetric SID, the option for JS to choose the SID, the
optional in-band OPEN message, and the fact that SDP only negotiates the
existence and transport of data channels, not individual data channels".

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 25 Apr 2013 09:36:06 +0200

Hi,

I have uploaded new minutes with the paragraph in question now reading:

Peter Thatcher commented that he thinks the presenter's proposal
(draft-jesup-rtcweb-data-protocol-04)  is great. (After the meeting
Peter has clarified that is was the content of the slides and to be
precise “I support the symmetric SID, the option for JS to choose the
SID, the optional in-band OPEN message, and the fact that SDP only
negotiates the existence and transport of data channels, not individual
data channels”.)

Harald Alvestrand stated that he Agree with this (Afterwards clarified
as: “I supported what draft-jesup was suggesting - negotiating usage of
SCTP in SDP, and not mentioning individual data channels in the SDP.”).
Glad got data channel negotiation out of the document. There are no
existing implementation this has to interwork with - this is all new.
Any protocol has to define how to work on top of this and map. Not
RTCWEB business to define this.

Are everyone satisfied now?

The possibility make any more changes to the minutes closes on the first
of May.

Cheers

Magnus

On 2013-04-25 02:17, Peter Thatcher wrote:
> I considered the slides to represent what I support.  I'll try to be
> more specific at the mic next time.  But I guess if I could go back I
> would say "I support the symmetric SID, the option for JS to choose the
> SID, the optional in-band OPEN message, and the fact that SDP only
> negotiates the existence and transport of data channels, not individual
> data channels".
> 
> 
> On Wed, Apr 24, 2013 at 12:44 AM, Magnus Westerlund
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
>     Ok,
> 
>     <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     >     <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>     >
>     >         Harald and Peter,
>     >
>     >         >> I have now updated the minutes trying to clarify the
>     context
>     >         and the
>     >         >> corrections. Please check if you think this makes it
>     clearer.
>     >         If not I
>     >         > [BA]  Since draft-jesup-rtcweb-data-protocol is about
>     setting
>     >         up data
>     >         <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     >        

-- 

Magnus Westerlund

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 25 Apr 2013 10:37:20 -0700

I'm happy with that.

On Thu, Apr 25, 2013 at 12:36 AM, Magnus Westerlund <
[email-masked]> wrote:

> >     >         >> am happy to introduce additional clarifications, but
> please
> >     >         be explicit
> >     >         > [BA] My impression was that this remark more related to
> the
> >     >         presentation
> >     >         > suggestions relating to removing of stream negotiation
> from
> >     >         SDP, which
> >     >         > channels this doesn't make sense to me.  Was Harald
> perhaps
> >     >         referring to