Hello,
One of the DCCP charis asked me to review draft-ietf-dccp-udpencap-06.
So here comes a bunch of comments:
* The SDP support really ought to use a different protocol in the m=field.
This "stuff" is not "DCCP".
* An example SDP probably wouldn't hurt.
* This specification is relevant not only to NAT(/firewall) traversal, but
also to implementating DCCP within an "application" with support from the
TCP/IP stack. This seems entirely absent.
* A proposed integration with the socket API would not hurt either. Then
again, it is true that there is no proposed socket API for DCCP at all in
IETF :-(
* I find the two pairs of port numbers objectionable. Inner port numbers
make sense for network-layer tunneling (e.g. Teredo, IPsec over UDP...).
But it is counter-intuitive and needless complicated for transport-layer
encapsulation.
Existing RTP/SDP applications (the main use case for DCCP) have no
provisions for two pairs of port numbers, and two layers of demultiplexing.
(For example, VLC media player parses the SDP m= and c= lines into a
sockaddr, this is impossible with two level of port numbers).
* I don't see much value for a standardized IANA port allocation here. In
fact, it might do more harm than good with some braindead "port-preserving"
NATs: random source port are more likely to work there.
Best regards,
--
Rémi Denis-Courmont
http://www.remlab.net
http://fi.linkedin.com/in/remidenis
