Re: [AVT] draft-ietf-avt-ports-for-ucast-mcast-rtp-04: Review Comments [csp]

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

Hi Colin,

> - Introduction, 1st paragraph: suggest clarifying that the ports "are a shared resource that is defined declaratively"?

The first paragraph is concerned about the multicast applications and it does not mention "shared" in the text. Could you clarify your comment?
 
> - Section 3.2, 1st paragraph, begins "We illustrate the second step with an example", but it's not clear what is "the second
> step" being referred to here.

Reworded.
 
> - Section 3.2 is written as an example, but uses RFC 2119 language, and contains many normative requirements. I would
> suggest that Section 3 be split into two Sections: one giving the motivating example, and another giving normative
> requirements for use of the port mapping extensions to RTCP.

Good idea, done.
 
> - Section 3.2, 1st bullet point on page 8 ("Port P3 denotes..."): the draft should clarify that the client may send any type of
> RTCP packet to the feedback target, any not just RTCP feedback messages, receiver, and extended reports.

Fixed.
 
> - Section 3.2, 3rd bullet on page 8, sub-point 1: it's not clear what is meant by "When the retransmission server sends unicast
> packets for a long period of time, this can exceed that timeout". Would it be clearer to say "when the gap between
> retransmission requests (or other traffic sent from client to server) is long, this can exceed that timeout"?

Good suggestion.
 
> - Section 3.2, 4th bullet on page 8: the discussion of how the token may remain valid for multiple sessions is unclear. It may
> be clearer to say that the token is valid for that port on the server until its expiration time, irrespective of what that port is

Yes, reworded as requested.

> used for. Following on from this, would it be appropriate to add a warning that the server port SHOULD NOT be reused for
> other RTP sessions until the expiration time of the tokens issued?

Not sure why we would need this.

> - Section 3.2, step 4 on page 9: the draft needs to give a normative list of which RTCP packet types require an associated
> token.

Reworded as: The client needs to provide the Token to the server using a new RTCP message, called Token Verification Request, whenever the client sends an RTCP feedback message for triggering or controlling a unicast session (See Section 5.3).

> - Section 3.2, step 1-5 on pages 9 and 10: these need to be moved out of the example, into a separate normative section.

Done.
 
> - Section 5: The RTCP extensions defined here are exchanged in order to setup a unicast session, rather than to provide
> feedback on an existing session. Accordingly, it's not clear that they should be sent as RTCP Feedback messages. Would it be
> appropriate to define new RTCP packet types to convey this information, rather than trying to shoehorn this into transport
> layer feedback packets (this would also avoid the problem of how to set the SSRCs)?

We did not do this for RAMS-R, either. I am not very keen on changing this at this stage. Does anybody feel strong about this?
 
> - Section 5: Does the nonce have to be 64 bits? If a 56 bit nonce were sufficient, the feedback packets could be packed much
> more efficiently.

Nope, it does not. Changed it to 56.
 
> - Section 5.3 should give a normative list of which RTCP packet types require the token verification messages. Does the RTCP
> BYE packet need this?

I don’t think BYE messages need a Token. NACKs, RAMS-R and RAMS-T require Tokens.

There could be some future packet formats or message types that might require a Token. How could we word this better? Any ideas?
 
> - Section 5.4: it would be useful to include the nonce from the token that failed in the verification failure message, so the
> client can match up the failure to the token used.

OK.
 
> - Section 5 should discuss timings and failure modes. RTCP is not a timely or reliable protocol. What is the expected
> behaviour if these messages are lost and/or delayed? (e.g., that's the retransmission behaviour).

Just before 5.1, added:

Note that RTCP is not a timely or reliable protocol. The RTCP packets might get lost or re-ordered in the network. When a client sends a Port Mapping Request or Token Verification Request message but it does not receive a response back from the server (either a Port Mapping Response or Token Verification Failure message), it MAY resend its request when it is eligible to do so based on the timer rules defined in RFC 4585.

> - Section 6: is this section normative, or an example of how the server can generate a token? There seems little requirement
> for it to be normative.

Magnus made a similar comment. We will keep as an example.
 
> - Section 6: why base-64 encode the output? RTCP is a binary protocol.

:) Good point. Fixed. 

> - Section 7: it would seem appropriate to always send the verification failure RTCP message, even if another error response
> has been delivered.

Done.

Thanks much.
-acbegen