Re: [rtcweb] Working Group Last Call: JSEP

Colin Perkins <csp@csperkins.org> Tue, 25 October 2016 17:42 UTC

Return-Path: <csp@csperkins.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59E1C129871 for <rtcweb@ietfa.amsl.com>; Tue, 25 Oct 2016 10:42:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYGKSfm3xs2M for <rtcweb@ietfa.amsl.com>; Tue, 25 Oct 2016 10:42:42 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0679129863 for <rtcweb@ietf.org>; Tue, 25 Oct 2016 10:42:42 -0700 (PDT)
Received: from [130.209.247.112] (port=52094 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <csp@csperkins.org>) id 1bz5kE-0005dP-DU; Tue, 25 Oct 2016 18:42:40 +0100
Content-Type: multipart/alternative; boundary="Apple-Mail=_F4D33ECE-2B42-4A49-A04B-50FA1132FCB1"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <CA+9kkMBLcUFs-sdpSnTEHfGVwwG1iDsWpsk1ONHrq2M7LV4g3w@mail.gmail.com>
Date: Tue, 25 Oct 2016 18:42:32 +0100
Message-Id: <18EF5EAF-81FF-4917-93DE-B25F20913216@csperkins.org>
References: <CA+9kkMBLcUFs-sdpSnTEHfGVwwG1iDsWpsk1ONHrq2M7LV4g3w@mail.gmail.com>
To: Ted Hardie <ted.ietf@gmail.com>
X-Mailer: Apple Mail (2.3124)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/FgiHMrQf6RPnn1Fg5Lrgdp1yUNY>
Cc: Cullen Jennings <fluffy@cisco.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Working Group Last Call: JSEP
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Oct 2016 17:42:45 -0000

Hi,

This is a well written draft. I think Section 6 needs work, along the lines of the recent discussion and updates to BUNDLE, but the rest of the document seems to be in good shape.

Section 6 says:

   Note: The following algorithm does not yet have WG consensus but is
   included here as something concrete for the working group to discuss.

I don’t think what’s written here is right yet. The RTP specification has rules for forming RTP packets into RTP streams based on their SSRC, and for associating RTCP packets with RTP streams. Similarly, BUNDLE, as of -35, has rules for mapping RTP streams to m= sections based on the MID. This section seems to be trying to replicate these, rather than building on them. 

I think this section should leave the mapping from RTP/RTCP packets to RTP streams to RTP, and the mapping from RTP streams to m= sections to SDP (and BUNDLE, if used). It should talk instead about how RTP streams associated with m= sections are mapped onto RtpSenders and RtpReceivers. This may sound like just a terminology difference, but I think it’s important to get the layering and division of responsibilities right, if the protocol is to be maintainable and extensible.


I also had some minor nits on the rest of the document:

- Section 5.1.1, 1st paragraph: The list of mandatory to implement standards is “derived from the requirements outlined in [I-D.ietf-rtcweb-rtp-usage]”. Should the draft say somewhere that “RTP media transport MUST be implemented according to [I-D.ietf-rtcweb-rtp-usage]”? 

- Section 5.1.1: It’s easy to skim-read R-5 this as “MUST”, since all the other requirements are MUST. It might be more visually distinct if written as  “SHALL NOT” rather than “MUST NOT”.

- Section 5.1.1: R-16 should be removed.

- Section 5.2.1, top of page 38: The header extension is in Section 14 of BUNDLE, not Section 11 (also second bullet point on page 39).

- Section 5.8, 3rd bullet on page 60: I suggest changing “If the MID header extension is supported, prepare to demux RTP data intended for this media section“ to “…prepare to demux RTP streams intended…”, to match the recent discussion around terminology in BUNDLE.

Colin




> On 21 Oct 2016, at 20:25, Ted Hardie <ted.ietf@gmail.com> wrote:
> 
> The chairs would like to start a working group last call on draft-ietf-rtcweb-jset-17 to end on November 9th, 2016, 17:00 KST.
>   
> Please review thoroughly, as working through the last comments will be the major effort of our working group meeting in Seoul.
> 
> From a process perspective, we will be working through the comments as issues against the github repo.  In order to accommodate folks who do not use github, the chairs will enter a new issue for any issue raised on the mailing list.  That means that if you are raising a new issue, please send it to the list with a new subject line so that the chairs catch it.
> 
> If you prefer, you may also enter the issues at https://github.com/rtcweb-wg/jsep <https://github.com/rtcweb-wg/jsep>.  If you do so, please send a copy of the issue to the mailing list so that conversation and resolution occurs here.
> 
> This has been a long road, but this a very major milestone.  Thanks to the authors for their work so far.
> 
> regards,
> 
> Ted, Cullen, Sean
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Real-Time Communication in WEB-browsers of the IETF.
> 
>         Title           : Javascript Session Establishment Protocol
>         Authors         : Justin Uberti
>                           Cullen Jennings
>                           Eric Rescorla
>         Filename        : draft-ietf-rtcweb-jsep-17.txt
>         Pages           : 94
>         Date            : 2016-10-21
> 
> Abstract:
>    This document describes the mechanisms for allowing a Javascript
>    application to control the signaling plane of a multimedia session
>    via the interface specified in the W3C RTCPeerConnection API, and
>    discusses how this relates to existing signaling protocols.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/ <https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/>
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-17 <https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-17>
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-jsep-17 <https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-jsep-17>
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org <mailto:rtcweb@ietf.org>
> https://www.ietf.org/mailman/listinfo/rtcweb <https://www.ietf.org/mailman/listinfo/rtcweb>
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb



-- 
Colin Perkins
https://csperkins.org/