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

[Magnus Westerlund <[e-mail]>]

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