[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"?
- [rtcweb] Spencer Dawkins' Yes on draft-ietf-rtcwe… Spencer Dawkins
- Re: [rtcweb] Spencer Dawkins' Yes on draft-ietf-r… Magnus Westerlund