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

[Ben Campbell <[e-mail]>]

Hi Magnus,

Your responses address all of my concerns.

Thanks!

/Ben



On May 13, 2014, at 10:07 AM, Magnus Westerlund <[e-mail]> 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  [phone]
> Färögatan 6                 | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------