Re: [MMUSIC] 1 Week WGLC for draft-ietf-mmusic-rtsp-nat-evaluation-06

[Magnus Westerlund <[e-mail]>]

Thanks Ari,

I will try to role a new version within the next few days addressing
your comments. If there are any issues in implementing them I will come
back with such discussion.

Cheers

Magnus

On 2013-05-17 17:49, Ari Keränen wrote:
> Hi,
> 
> I had a quick read over the draft and have a few comments:
> 
> 3.  Requirements on NAT-Traversal
> 
>    1.  Must work for all flavors of NATs, including NATs with address
>        and port restricted filtering.
> 
> The term used by RFC 4787 is "Address and Port-Dependent Filtering"
> 
> 
> 3.  Requirements on NAT-Traversal
> 
>    The list of feature requirements for RTSP NAT solutions are given
>    below:
> 
> I guess this should say "RTSP NAT traversal solutions".
> 
> 
>        *  Address discovery for NAT traversal should take automatically,
>           if possible
> 
> I assume this means the discovery of the address assigned by the NAT?
> Maybe say that explicitly, e.g., "Discovery of the address(es) assigned
> by NAT should happen automatically if possible".
> 
> 
> 4.7.4.  Security Considerations
> 
>    An ALG will not work whit deployment of end-to-end RTSP signaling
> 
> Typo: whit
> 
> 
> 4.9.1.  [TURN] Introduction
> 
>    On the external side this is
>    limited to the source address/port pair of the first packet arriving
>    on the binding.  After the first packet has arrived the mapping is
>    "locked down" to that address.  Packets from any other source on this
>    address will be discarded.
> 
> This doesn't sound right. This behavior was changed (eventually into
> using permissions) somewhere back in draft-rosenberg-midcom-turn-06. See
> http://tools.ietf.org/html/rfc5766#section-2.3 for up-to-date behavior.
> Check also steps 5 & 7 in the next section and section 4.9.4 for more
> lock down text.
> 
> 
> 6.  Comparison of NAT traversal techniques
> 
>    C2:  How Robust is the solution to changing NAT behaviors
> 
> Since the answer is yes/no, maybe this should be "is the solution
> robust..."
> 
> 
> 10.  Informative References
> 
>    [STUN-IMPL]
>               "Open Source STUN Server and Client, http://
>               www.vovida.org/applications/downloads/stun/index.html",
>               June 2007.
> 
> This site seems to be unavailable nowadays. Better reference would be
> "http://sourceforge.net/projects/stun/". And of course, there are plenty
> of other open source STUN implementations, but likewise there are for
> ICE (PJNATH, libnice, ice4j, etc.) if we want to use that as an argument.
> 
> 
> Cheers,
> Ari (as individual)
> 


-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------