[rtcweb] Spencer Dawkins' Yes on draft-ietf-rtcweb-rtp-usage-24: (with COMMENT)

"Spencer Dawkins" <spencerdawkins.ietf@gmail.com> Thu, 11 June 2015 03:07 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
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 DD8C11A876F; Wed, 10 Jun 2015 20:07:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham
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 l03NxSgJz-Py; Wed, 10 Jun 2015 20:07:17 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A41E1A0078; Wed, 10 Jun 2015 20:07:17 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.3.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150611030717.14942.21451.idtracker@ietfa.amsl.com>
Date: Wed, 10 Jun 2015 20:07:17 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/r8mOYYDkyQJ11h2ZGYXgrCQMC_E>
Cc: rtcweb@ietf.org
Subject: [rtcweb] Spencer Dawkins' Yes on draft-ietf-rtcweb-rtp-usage-24: (with COMMENT)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 11 Jun 2015 03:07:19 -0000

Spencer Dawkins 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:
----------------------------------------------------------------------

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"?