Re: [AVT] I-D Action:draft-ietf-avt-ports-for-ucast-mcast-rtp-08.txt - my review

[Roni Even <[e-mail]>]

Hi,
I read this version of the draft and read all the email exchange from the
last weeks.
I will provide my view and not address a specific issue.
I am doing it as an individual


1. The introduction section just before figure 1 has the following sentence
"This solution allows receivers to choose their desired UDP ports for RTP
and RTCP in every unicast session when they are running RTP applications
using both unicast and multicast services, and offer/answer exchange is not
available.". My view and I agree with Tom on this one is that this is the
only use case. I am not sure why the Magnus added the need for offer answer
since if there is an offer answer exchange the answer can provide the
unicast address and port for receiving the unicast stream. For example if
you take the example in figure 7, the unicast m-line in the answer with
mid=2 will provide the transport address for the unicast retransmission. I
am wondering if the motivation is to have "yet another ICE"

2. A nit in section 3.1 second paragraph second sentence add "token" so it
will say "When a token request" .

3. Section 4 defines Token verification failure message. Maybe it should be
mentioned in section 3 that discuss the new messages.

4. In section 4 third paragraph you use RFC 4585 for discussion the RTCP
message scheduling, why not reference RFC 6051

5. Section 4.3 says " Currently, the following RTCP messages are REQUIRED
to be accompanied by a Token Verification Request message:". I have some
questions here"

   5.1 Is this true all the time or only if a token is used. 
   5.2 I understand that it is always required for RAMS but not always for
NACK, BYE and CCM. Some text is needed to explain when to send it.


6. A nit in section 6 second paragraph "The server first applies the its own
procedure". Delete the "the".

7. In section 6 you do not mention the case when the server expected a token
and did not get one.

8. In section 7.1 the draft suggests that the portmapping-req attribute can
be a media or session level. So if used at the session level does it relate
also to the multicast session when used in a grouping of a unicast and
multicast retransmission definition. That will be inconsistent if the
attribute provides only a port for a multicast session there is a problem
according to next section (see my next comment).  So either it MUST have the
optional address parameter if specified at the session level or only allow
it at the media level. I think that this attribute is relevant only for the
unicast session and the text should say that if used at the session level
MUST have the address parameter.

9. In section 7.1 " In the optional address value, only unicast addresses
are allowed; multicast addresses SHOULD NOT be used ...". I see this as
contradiction between the two parts of the sentence and I am not sure why
not say "multicast address MUST NOT be used".

10. In section 7.2 I have some questions on the following requirements:

   o  The RTP/AVPF profile  [RFC4585] - the current text with offer answer
which in my view is very open can allow it to work with AVT profile.

   o  The RTCP extensions for SSM sessions with unicast feedback  [RFC5760]
- The introduction says that it is relevant also for any source multicast,
so why is this required.

   o  The 'multicast-rtcp'  attribute [I-D.ietf-avt-rtcp-port-for-ssm] - can
you explain why?


11. In section 7.3 maybe rephrase the sentence "Since there is no address
indiciated in this line, the client needs to retrieve  the Token from the
address specified in the "c" line."  to  " Since there is no address
indicated in this line, the client needs to send the token request to the
address specified in the "c" line."

There is also a typo in "indiciated"



Roni Even as individual









> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> [e-mail]
> Sent: Saturday, December 11, 2010 7:30 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: [AVT] I-D Action:draft-ietf-avt-ports-for-ucast-mcast-rtp-
> 08.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Audio/Video Transport Working Group of
> the IETF.
> 
> 
> 	Title           : Port Mapping Between Unicast and Multicast RTP
> Sessions
> 	Author(s)       : A. Begen, et al.
> 	Filename        : draft-ietf-avt-ports-for-ucast-mcast-rtp-08.txt
> 	Pages           : 33
> 	Date            : 2010-12-11
> 
> This document presents a port mapping solution that allows RTP
> receivers to choose their own ports for an auxiliary unicast session in
> RTP applications using both unicast and multicast services.  The
> solution provides protection against denial-of-service attacks that
> could be used to cause one or more RTP packets to be sent to a victim
> client.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-avt-ports-for-ucast-
> mcast-rtp-08.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.