Re: [rtcweb] WGLC review of draft-ietf-rtcweb-rtp-usage-13

Ben Campbell <ben@nostrum.com> Tue, 13 May 2014 15:28 UTC

Return-Path: <ben@nostrum.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 7E9441A0117 for <rtcweb@ietfa.amsl.com>; Tue, 13 May 2014 08:28:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 8ZkYfZCCs1sv for <rtcweb@ietfa.amsl.com>; Tue, 13 May 2014 08:28:09 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0866C1A00E3 for <rtcweb@ietf.org>; Tue, 13 May 2014 08:28:08 -0700 (PDT)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s4DFRvFp005196 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 May 2014 10:27:59 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <53723549.1040200@ericsson.com>
Date: Tue, 13 May 2014 10:27:58 -0500
X-Mao-Original-Outgoing-Id: 421687678.277234-758e7991d4f38dc34d665bdc2e2a88dc
Content-Transfer-Encoding: quoted-printable
Message-Id: <27EF9E34-2BAE-4B05-B602-9C502EDF4896@nostrum.com>
References: <B01CF683-847B-43AF-AE91-7BE50D13C0D4@nostrum.com> <53723549.1040200@ericsson.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ATECBVwrG_cFMlSTUDsdnR-jEj8
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] WGLC review of draft-ietf-rtcweb-rtp-usage-13
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: Tue, 13 May 2014 15:28:10 -0000

Hi Magnus,

Your responses address all of my concerns.

Thanks!

/Ben



On May 13, 2014, at 10:07 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:

> Hi Ben,
> 
> Thanks for the review, please see reply inline.
> 
> On 2014-05-09 23:56, Ben Campbell wrote:
>> Hi,
>> 
>> This draft seems well constructed. I don't have much in the way of
>> technical comments, but do have a few extremely minor/editorial
>> comments:
>> 
>> Thanks!
>> 
>> /Ben
>> 
>> ----------------------
>> 
>> -- 4.1, 2nd to last bullet:
>> 
>> Can there be a reference for " RTCP timer reconsideration "
> 
> Yes we can add a section reference into RFC 3550 for this.
>> 
>> -- 4.3, last paragraph: "RTP receivers MUST follow the
>> recommendations in Section 4.3 of [RFC7160] in order to support ..."
>> 
>> I assume that you mean that receivers MUST support the
>> recommendations because they need to support multiple clock rates. A
>> strained interpretation could assume that, if they want to support
>> multiple clock rates, they MUST support..."
> 
> Correct, will look at reformulating this. Because I believe an WebRTC
> receiver must be required to support multiple clock rates.
>> 
>> -- 4.5, first paragraph: " ... support for multiplexing RTP data
>> packets and RTCP control packets on a single transport-layer flow for
>> each RTP session is REQUIRED, provided it is negotiated in the
>> signalling channel ..."
>> 
>> I assume the intent is that support...is REQUIRED, but only _used_ if
>> negotiated? As written, it seems to say _support_ is both REQUIRED
>> and negotiated.
> 
> Yes, required to implement support for, use based on negotiation. Will
> take a look at proposing another formulation.
> 
>> 
>> (A similar construction occurs in 4.6, 2nd paragraph)
> 
> Will take a look at that too.
> 
>> 
>> -- 5.2.2, last paragraph:
>> 
>> If I understand 6904 correctly, you signal the use of encryption for
>> each header you want to encrypt, right? If so, then how is
>> "explicitly disabled through ... signalling" different than "not
>> signalled"? If it's the same thing, then this comes perilously close
>> saying "... RECOMMENDED that the encryption be used ... unless you
>> don't want to."
> 
> Yes, you are correct, assuming that signalling is SDP. Which not all on
> this mailing list assumes. One way to resolve this is to actually tease
> the two parts apart. First of all it is recommended to encrypt it.
> Secondly, this may be controlled through an API or signalling.
> 
> 
>> 
>> (I have no objection to the "explicitly disabled through the API" )
>> 
>> -- Figures 1 and 2:
>> 
>> Any chance of centering these?
> 
> This is an bug in the version 2.0 of XML2RFC. Can't do anything about
> until someone fixes this, or hand adjust it.
> 
>> 
>> -- 12.1.3:
>> 
>> How does (or will) DART fit in here? Seems like it might have
>> something to say, but I'm not sure how the timing relates.
> 
> So this text is the high level teaser to DART work from my perspective.
> The Dart work will have to get into some of the more subtler issues. To
> my understanding the DART output will be part of the reference chain
> here. This document reference [I-D.ietf-tsvwg-rtcweb-qos]
> which in its turn will reference DART. You will also likely to be able
> to reach the DART document through draft-ietf-rtcweb-transports.
> 
> If the DART document becomes available and seen as ready prior to this
> having gone to far down the publication process we can reconsider if
> this should have a direct reference or not. For now I would leave it out.
> 
> Cheers
> 
> 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: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------