Subject: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-rtp-usage-24: (with COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Mon, 08 Jun 2015 20:02:46 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-rtcweb-rtp-usage-24: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I found this in general to be informative and well written, given the
rather large scope of information. I do have a few comments/questions:

Substantive:

-- 4.9: The discussion of RTCPeerConnection in this section seems to need
a normative reference to [W3C.WD-webrtc-20130910] (or a local
explanation, if there are issues normatively referencing that doc.)

-- 5.1: This section seems to need a normative reference to
topologies-update. There is normative language here to the effect of
“Don’t do these things” where it seems like one needs to read that doc to
understand what the “things” mean.

-- 7.1, first paragraph: "applications MUST also implement congestion
control to
   allow them to adapt to changes in network capacity."
   
   Is that the aformentioned not-yet-standardized congestion control
algorithm, or something else? 
   
-- 11, 2nd paragraph from end:

It seems like the msid reference should be normative.

-- 12.1.3:

seems like a mention of draft-ietf-dart-dscp-rtp might be in order now.
IIRC, when I did a gen-art review on a much older version, the thought
was that if draft-ietf-dart-dscp-rtp was far enough along when it was
time to publish this draft, it would make sense to add a mention. It's in
the RFC editor queue now, in MISSREF on a dependency that I think this
draft shares.

-- 13: 3rd paragraph:

Isn't that security solution MTU as well as MTI? If so, it might be worth
mentioning it here.
   
Editorial:

-- 11, paragraph 3: "...can be feeding multiple..."

Consider "... can feed multiple ..."

paragraph 4: "This is motivating the discussion..."

consider "This motivates the discussion..."  (or possibly "motivated")

paragraph 5: "... each of different MediaStreamTracks ..."

missing "the"

paragraph 6: "... relay/forward ..."

consider "... relay or forward ..."

-- 12.1, last sentence "... ways in which WebRTC Endpoints can configure
and use
   RTP sessions is outlined."
   
s/is/are