> -----Original Message----- > From: dccp-bounces@xxxxxxxx [mailto:dccp-bounces@xxxxxxxx] On Behalf Of > Gorry Fairhurst > Sent: Monday, February 28, 2011 10:23 AM > To: dccp@xxxxxxxx; remi@xxxxxxxxxx > Subject: Re: WGLC for draft-ietf-dccp-udpencap > > Thanks for your comments, I can reply - but I will need others in the > WG > to chime-in on these topics. > > On 28/02/2011 10:58, RÃmi Denis-Courmont wrote: > > > > 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". > > > I need help from SDP people on this comment - the idea was that this > looked like DCCP to the app. > > > * An example SDP probably wouldn't hurt. > > > It would be really good, can someone offer such an example please? > > > * 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. > > > It has been mentioned in the past, and we could add some text to the > motivation to explain this. Any thoughts from others? > > > * 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 :-( > > > Indeed, and I'd assume any DCCP API could describe this. I hope you're > expecting me to say that this should be in another draft. > > > * 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. > > > This topic was discussed at length on the list, and resulted in the two > approaches outlined. I'm not sure what to add. > > > (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. > > > The assigned ports may be important for apps that don't use SDP and > need > to communicate with a listening server. I'm guessing that SDP-based > apps > may not need this. Please add text making that clear. Something along the lines of: The purpose of this IANA-assigned port is for the OS or a framework to receive and process DCCPoUDP messages for delivery to the DCCP stack on the host. This port SHOULD NOT be used by an application doing DCCPoUDP encapsulation, because it prevents another application from also doing the same thing. -d
