[rtcweb] Review of draft-ietf-rtcweb-overview-10

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 18 July 2014 01:09 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 009281A0328 for <rtcweb@ietfa.amsl.com>; Thu, 17 Jul 2014 18:09:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 ykLhf1BjdzMW for <rtcweb@ietfa.amsl.com>; Thu, 17 Jul 2014 18:09:34 -0700 (PDT)
Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 729951A014E for <rtcweb@ietf.org>; Thu, 17 Jul 2014 18:09:34 -0700 (PDT)
Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta08.westchester.pa.mail.comcast.net with comcast id TcGD1o0010Fqzac58d9aQx; Fri, 18 Jul 2014 01:09:34 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id Td9Z1o00i3ZTu2S3Ud9Z4R; Fri, 18 Jul 2014 01:09:33 +0000
Message-ID: <53C873CD.7080308@alum.mit.edu>
Date: Thu, 17 Jul 2014 21:09:33 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1405645774; bh=HaCw1dGsW3KOGRT5nQx/JD+J6B6dUChoRnSzW+2bpD4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hS6kAVrlS8rHDSWAl6sSaICvPG9vEHHQIJ5tXP5nfjmuwzgFwJncDjTNg05g/nWjK p4Sa7aluxJsB1ytEdx9kCjZZtpIUDzI9h1IeoeNsdO9mA5XlXqnYqxpKE1IES7GOnf 13dvgkooSNJdIU8imNmESwUlivUrGRJDnbCalOdWrUopcXWu4Ndowb0zlnH7Ep+lAe j3/Z5ZHF2MZLAZ9GOh45KEg3iQPk+WYeFU9sTyXAJCAiy6AkHU52ReW+wGVLpIQZbh 4yX9nUSaTypW/QoEQl1TzAmlkPIIdEXWi33CWwe4UxtSdVT/1pWX4+mcXb1PLauOM4 +IUdWgrtrcckQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/21PILsCMZPk8KvLvcafV9Unan6c
Subject: [rtcweb] Review of draft-ietf-rtcweb-overview-10
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Fri, 18 Jul 2014 01:09:36 -0000

I haven't read the overview carefully in a long time. This time I did.
I came away with the following thoughts:

Terminology:

    Media path:  The path that media data follows from one browser to
       another.

I don't think this is quite right by restricting to browsers. I think 
you mean:

    Media path:  The path that media data follows from one WebRTC device
       to another.

The intent is clear (e.g. from figure 2) but the definition doesn't say it.

Also, why aren't "WebRTC browser" and "WebRTC device" included in the 
Terminology section? Seems like they should be.

Section 5:

    Considerations for the transfer of data that is not in RTP format is
    described in [I-D.ietf-rtcweb-data-channel], and a supporting
    protocol is described in [I-D.ietf-rtcweb-data-protocol].  Webrtc
    devices MUST implement these two specifications.

Actually ietf-rtcweb-data-protocol only describes a protocol used for 
data channel *establishment*. As such, I think it is technically a 
Connection management protocol. This becomes more evident when you 
consider all the discussion on how to establish channels via SDP.

In principle I think ietf-rtcweb-data-protocol should be referenced from 
section 7. If that seems heretical, then how about at least saying:

    Considerations for the transfer of data that is not in RTP format is
    described in [I-D.ietf-rtcweb-data-channel], and a supporting
    protocol for establishing individual data channels is described in
    [I-D.ietf-rtcweb-data-protocol].  Webrtc devices MUST implement
    these two specifications.

Otherwise this document is remarkably clear.

	Thanks,
	Paul