Re: [AVT] comments on draft-ietf-avt-rapid-acquisition-for-rtp-09

["Ali C. Begen (abegen)" <[e-mail]>]

Hi Dan,
 
> 1.
> 
> Section 9,
> 
>    a.  See UDP traffic sent from RTP_Rx (which is on the 'inside' of the
>        NAT) to BRS (which is on the 'outside' of the NAT).  This traffic
>        is sent to the same transport address as the subsequent response
> .......^^^^^^^^^^
> .........."has"         (because it needs the same source address,
>                          source port, destination address, destination
>                          port, and protocol=UDP).  Easiest way is "has
>                          same transport address".)

OK.
 
> 2.
> 
> Section 9,
> 
>    When RTP_Rx sends a RAMS-R message to FT as unicast feedback in the
> .......................^^^^^^^^^^^^^^
>    primary multicast RTP session, and the request is received by FT, a
> ......................................^^^^^^^^^^^
> 
> 
> I suppose "RAMS-R message" and "the request" are the same thing.  Can
> the same terminology be used?

Yes, will fix this.

> 3.
> 
> Section 9,
> 
>    When RTP_Rx sends a RAMS-R message to FT as unicast feedback in the
> ........^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> This says a message is sent to FT.
> 
>    primary multicast RTP session, and the request is received by FT, a
>    new unicast burst RTP session will be established between BRS and
>    RTP_Rx.
> 
>    While the FT and BRS ports on RS are already signaled via out-of-band
> .............^^^^^^^^^^^^^^^^^^^^^^
> This says a message is sent to the FT ports on the RS.  The highlighted
> sentence in the paragraph above is written differently.  Is this
> difference intentional?

Yes, RAMS-R message goes to the FT port but session is established on the BRS port.
  
> 4.
> 
> Section 9,
> 
>    While the FT and BRS ports on RS are already signaled via out-of-band
>    means (e.g., SDP), RTP_Rx needs to convey the RTP and RTCP ports it
>    wants to use on its side for the new session.  Since there are two
>    RTP sessions involved during this process and one of them is
> ...^^^^^^^^^^^^^^^^^^^^^
> Add a paranthetical statement that the two RTP sessions are the
> unicast and multicast sessions (which is what I think is intended),

Will do.

> or that they are the RTP and the RTCP sessions (which is mentioned
> in the previous sentence, causing me to ask for clarification).
> 
> 
> 5.
> 
> Section 9,
> 
>    applies to scenarios where the RTP media is multicast in an SSM
>    session, and an RTP receiver requests retransmission from a local
> ...................^^^^^^^^^^^^
>             should that be "RTP_Rx"?  If not, why not?

Good catch.
 
> 
> 6.
> 
>    Applications using RAMS MUST support this solution both on the RS and
> ........................................^^^^^^^^^^^^^
>                                which solution is "this"?  Is "this"
>                    referring to draft-ietf-avt-ports-for-ucast-mcast-rtp
>                                    in the previous paragraph?  If
>                   so, please reword and make it clearer; "this" could
>                   be referring to "this document" (RAMS).

Will refer to the cookie solution.

> 
>    RTP_Rx side to allow RTP receivers to use their desired ports and to
>    support RAMS behind NAT devices.
> 
> 
> 7.
> 
> Section 6,
> 
>    6. Rapid Acquisition of Multicast RTP Sessions
> 
>    We start this section with an overview of the rapid acquisition of
>    multicast sessions (RAMS) method.
> 
> Oh, so this document *defines* RAMS.  How about adding "(RAMS)" to
> the end of Section 6's title.  Or the document's title?

Will add it to section 6's title and the short title on page headers.

> 
> 
> 8.
> 
> Security Considerations:
> 
>    First of all, much of the session description information is
>    available in the SDP descriptions that are distributed to the media
>    senders, retransmission servers and RTP receivers.  Adequate security
>    measures are RECOMMENDED to ensure the integrity and authenticity of
>    the SDP descriptions so that transport addresses of the media
>    senders, distribution sources, feedback targets as well as other
>    session-specific information can be authenticated.
> .......................................^^^^^^^^^^^^^
>                                        protected

OK.
 
> 
> 9.
> 
> Security Considerations:
> 
>    To reduce the impact of
>    DTLS-SRTP overhead when communicating with different feedback targets
>    on the same retransmission server, it is RECOMMENDED that RTP
>    receivers and the retransmission server both support TLS Session
>    Resumption without Server-side State [RFC5077].
> 
> If the retransmission server needs to send a lot of the same information,
> unicast, to a lot of RTP_Rx devices, you might also encourage implementors to
> consider draft-ietf-avt-srtp-ekt.

Sounds good. 

Thanks,
-acbegen
 
> 
> -d