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

Magnus Westerlund <> Tue, 09 June 2015 08:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 125B71B2AAE; Tue, 9 Jun 2015 01:51:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9vFIFVd1E1Qw; Tue, 9 Jun 2015 01:51:16 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 78C901B2AAC; Tue, 9 Jun 2015 01:51:15 -0700 (PDT)
X-AuditID: c1b4fb30-f799f6d000000faf-4d-5576a900e772
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id F8.BE.04015.009A6755; Tue, 9 Jun 2015 10:51:12 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Tue, 9 Jun 2015 10:51:12 +0200
Message-ID: <>
Date: Tue, 09 Jun 2015 10:51:10 +0200
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Ben Campbell <>, The IESG <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUyM+JvrS7DyrJQg3eTDCzmd55mt5jxZyKz xdp/7ewOzB5Llvxk8pi18wlLAFMUl01Kak5mWWqRvl0CV8a7zZeZC2ZoVky8c4GxgbFHsYuR k0NCwESiacJfNghbTOLCvfVANheHkMBRRonupefYIZxljBJn350Bq+IV0Ja4tWczUxcjBweL gIrE9DfeIGE2AQuJmz8awUpEBaIkpj5exwJRLihxcuYTMFtEwEZi+cGXYDXMAqISrx5OYQax hQViJKZcXsoOYgsJOEg8fzGNFcTmFHCU2L9rFlS9hcTM+ecZIWx5ieats5kh6rUlGpo6WCcw Cs5Csm4WkpZZSFoWMDKvYhQtTi1Oyk03MtJLLcpMLi7Oz9PLSy3ZxAgM3INbfhvsYHz53PEQ owAHoxIP7wKPslAh1sSy4srcQ4zSHCxK4rwzNueFCgmkJ5akZqemFqQWxReV5qQWH2Jk4uCU amA0+S0udbwrNIer9czRnf5lgdt2iVx//Opo9K9frkyO92PmPN/anCPu3fHTv37qVQXnM6cU Gu7G6Z3mf6N8PUEyj8ms4/ZWz3T7llNynz83VD54/936ZtNau7Adj5YkeHH+ibHdmqnWsP7D M4EF88p/L6nyn3IoiydZp+IXD/d5rjC7VCetpbeUWIozEg21mIuKEwHk9d/hPQIAAA==
Archived-At: <>
Subject: Re: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-rtp-usage-24: (with COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 09 Jun 2015 08:51:18 -0000

Hi Ben,

Thanks for the review, some inline comments. Will address these after 
Thursday when we know the rest of IESGs views.

Ben Campbell skrev den 2015-06-09 05:04:
> 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
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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.)

Do I understand that you want a reference in the second paragraph at the 
mentioning of RTCPeerConnection? As it is reference in the previous 
paragraph, I assumed that people would not be confused on what we talk 

I guess the second issue is that the reference is classified as 
informative and should be normative. Changing the classification is 
simple, it will however create a need to ensure that the publication of 
this document is held until the W3C document reaches Recommendation 
status if I understand the rules and recommendations correctly.

> -- 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.

I do understand the reasoning behind your comment. I personally do not 
agree the need for using normative references for documents that import 
a term for a concept. We already had this discussion around the 
topologies document's status.

I have no issue with reclassifying the reference, but I do note that we 
will have to re-run the IETF last call as this will now be a down-ref.

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

As we have no standardized congestion control yet, we can't point to 
anything. But, an implementation must implement something, even if 
completely proprietary.

> -- 11, 2nd paragraph from end:
> It seems like the msid reference should be normative.

Our intention was to keep this informative. Therefore the chosen style 
of writing that sentence. The actual normative inclusion of MSID into 
the WebRTC solution is done by JSEP.

> -- 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.

The TSVWG document referenced do normatively reference the DART 
document. But, we could include the DART document in the same sentence 
as the TSVWG document.

> -- 13: 3rd paragraph:
> Isn't that security solution MTU as well as MTI? If so, it might be worth
> mentioning it here.

You mean Mandatory to Use, not Maximum Transmission Unit, don't you? 
Yes, it is mandatory to use, we can make that clear.

Will deal with the editorials
> 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


Magnus Westerlund

Services, Media and Network features, Ericsson Research EAB/TXM
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: