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
