Skip to main content

Media Transport and Use of RTP in WebRTC
draft-ietf-rtcweb-rtp-usage-26

Yes

(Alissa Cooper)
(Terry Manderson)

No Objection

(Alia Atlas)
(Alvaro Retana)
(Benoît Claise)
(Brian Haberman)
(Deborah Brungard)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)

Note: This ballot was opened for revision 23 and is now closed.

Alissa Cooper Former IESG member
Yes
Yes (for -23) Unknown

                            
Ben Campbell Former IESG member
Yes
Yes (2015-06-08 for -24) Unknown
Edit: Meta-Comment: The notify field for this draft seems sparse.


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
Spencer Dawkins Former IESG member
Yes
Yes (2015-06-10 for -24) Unknown
This draft looks very helpful, and I could understand it pretty well, I think.

I did have a few comments.

Am I reading this correctly? 

   The following RTP and RTCP features are sometimes omitted in limited
   functionality implementations of RTP, but are REQUIRED in all WebRTC
   Endpoints:
   
... skipping down to ...   
   
   o  Support for sending and receiving RTCP SR, RR, SDES, and BYE
      packet types, with OPTIONAL support for other RTCP packet types
      unless mandated by other parts of this specification.  
      
Is this saying that OPTIONAL support is REQUIRED unless some other part of the spec says it's a MUST? or a MUST NOT? or something else entirely?

In this text,

   Signalled bandwidth limitations, such as SDP "b=AS:" or
   "b=CT:" lines received from the peer, MUST be followed when sending
   RTP packet streams.  A WebRTC Endpoint receiving media SHOULD signal
                                                          ^^^^^^
could you help me understand why this is a SHOULD, and not a MUST?                 
                                                          
   its bandwidth limitations.  These limitations have to be based on
                                                 ^^^^^^^^^^^^^^^^^^^
   known bandwidth limitations, for example the capacity of the edge
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^
   links.
   
S0, not a 2119 MUST/REQUIRED ... is this simply recognizing that the signaled limitation has to be based on something, and the capacity of the edge links is the best upper limit that is easily available without probing? Or is it saying something else? I'd think the capacity of the edge links wouldn't be a great plan if you end up with a multi-unicast mesh with no middleboxes, for instance (but I could be wrong about that), but you might be saying that's still as good a limit as anything else.

In this text,

   However, implementations that can use
   detailed performance monitoring data MAY generate RTCP XR packets as
   appropriate; the use of such packets SHOULD be signalled in advance.
   
I wouldn't ask this question except that the draft has an entire section on dodgy implementations, but ... is there an unstated assumption that if the use of RTCP XR packets is signaled, the sender would respond to this information? I'm guessing "yes", and that could be fine, but I wanted to ask.

I think Section 9.  WebRTC Use of RTP: Future Extensions is very good, but I wonder if the first paragraph needs to be as 2119-heavy as it is. The second paragraph says what it needs to say without 2119 language.

In this text, I think there's a nit.

      whereas it would it all three participants were part of a single
                       ** I'm guessing this is "if"?
Terry Manderson Former IESG member
Yes
Yes (for -24) Unknown

                            
Alia Atlas Former IESG member
No Objection
No Objection (for -24) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (for -24) Unknown

                            
Barry Leiba Former IESG member
No Objection
No Objection (2015-06-10 for -24) Unknown
Well written -- thanks!
I just have a small comment:

   This document uses the terminology from
   [I-D.ietf-avtext-rtp-grouping-taxonomy] and
   [I-D.ietf-rtcweb-overview].

I'm not making this a DISCUSS, but I think that definitions of terminology that are necessary for the understanding of the document need to be normative references.  I think that makes those two references normative, not informative.
Benoît Claise Former IESG member
No Objection
No Objection (for -24) Unknown

                            
Brian Haberman Former IESG member
No Objection
No Objection (for -24) Unknown

                            
Deborah Brungard Former IESG member
No Objection
No Objection (for -24) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -24) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -24) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (2015-06-09 for -24) Unknown
Thank you for your work on this well-written draft.  The SecDir review picked up on a number of nits that should be corrected, tow in the Security considerations section in particular.
The full review can be found here: http://www.ietf.org/mail-archive/web/secdir/current/msg05759.html

And the specific fixes for the security considerations text is as follows:
The security considerations section was comprehensive and security impacts were taken into account throughout this draft.  I have two small NIT’s about the security section that I would like improved, and I feel these are rather small:  First, in the paragraph in the security section that starts “RTCP packets convey a Canonical Name…”  the authors state that the CNAME generation algorithm in described in section 4.9 – it isn’t, section 4.9 references RFC7022 for the generation algorithm.  Second, the last paragraph on page 39, starting with “Providing source authentication in multi-party…” ends the page with a large security warning.   Please include a reference in that paragraph in the security considerations and possibly to the appropriate draft/RFC which discusses that issue in some more depth.
Martin Stiemerling Former IESG member
No Objection
No Objection (for -24) Unknown