Hi Gorry, Thanks for the close read and the comments. See inline... Tom P. > -----Original Message----- > From: dccp-bounces@xxxxxxxx [mailto:dccp-bounces@xxxxxxxx] On Behalf Of > Gorry Fairhurst > Sent: Tuesday, August 31, 2010 2:42 PM > To: 'dccp' working group > Cc: Phelan, Tom > Subject: Review in WGLC for draft-ietf-dccp-udpencap-02.txt. > > > I have read the latest version of this specification during the WGLC and > believe this is an important topic to publish a document. > > The current draft appears to have addressed issues I think were > important and would seem nearly ready for publication, however I do have > some queries, as listed below. > > Best wishes, > > Gorry > > --- > Section 3.3 > - I think some sections miss context on why the decision was made, e.g. > in 3.3, please do say briefly why the WG chose to do this. [TomP] I'm not sure what you mean here. Do you mean that we chose not to support partial checksums? > --- > Section 3.3.1: > - Have you thought about whether this section should also reaffirm that > the checksum value in the encapsulated DCCP header is always zero? > - replace /Chesksums/ with /Checksums/ [TomP] I don't see a reason to say that receiver should verify that the DCCP checksum is zero. I've fixed the typo. > --- > Section 6: > /The option is a binary one however; either allow all DCCP > applications or allow none./ > - This seems a little harsh. The options based on the UDP-header are as > stated. A firewall than interprets this specification could in principle > look inside the UDP encaps and filter based on DCCP information. > > It doesn't sound that implausible given the sophistication of many > current firewalls, however it would be extra complexity that would need > to be justified. In my opinion, we should encourage this, so that > firewalls can open pin-holes for DCCP in the same way as they do for > other transports. > [TomP] Well, I do think that will be the case in many situations, and it is the case with security implications, so I think it should be mentioned. How about adding a parenthetical, "(unless the firewall supports flexible deep packet inspection rules)". > --- > - I see the value of the IANA-specified destination port for a client > server app using a NAPT, where the NAPT changes only the src port as it > leaves the client, and does this differently for each sender address > behind the NAPT. What is the expected port usage at the receiver? Does > it listen on the IANA port bound to any source port? Can you say more > here? > [TomP] So section 3.1 says: Source and Dest(ination) Ports: 16 bits each These fields identify the UDP ports on which the source and destination (respectively) of the packet are listening for incoming DCCP-UDP packets (normally both are the default port to be assigned by IANA). Note that they do not identify the DCCP source and destination ports. I don't know that I see any necessary changes here, except it should probably mention that the port values can be changed along the way by NAPT boxes. You say, "Does it listen on the IANA port bound to any source port?" I assume by this you mean will it accept an incoming packet with any source port? Do we need to open this UDP can of worms? > --- > References > > - The references have not been split between normative and informative, > the normative refs should have been agreed by the WGLC. > > - I think the following are not normative to this specification: > RFC4787, RFC5597, RFC5238, RFC5596, RFC5595 [TomP] My first take was that these were normative, but I think I see your point. I'll make them informative. > --- > UPDATES Line? > - The document explicitly says this updates RFC 5762, but the boilere > text at the head of the ID does not identify this as an update. Please > add a boiler plate line that explicitly states what is updated by this > specification. > > - Are there issues with an Experimental RFC updating a standards-track > RFC??? > [TomP] I see your issue. We probably should not update a standards track RFC with an experimental one. Does anyone have any advice? Extends rather than updates? Adds capabilities to those specified in RFC 5762? > - Is this intended to update RFC 4340? - if so, same question as above. > [TomP] It was not my intention to update RFC 4340. > ---- > Note: > /(default port awaiting IANA action)/ > - As I understand the IETF procedure, this could now be allocated by an > IANA request. I'm assuming this is a "registered" port, rather than a > "well-known" port? > - The RFC-to-be can then say this document allocates port XX for use by > this method. > [TomP] OK > ---- > > The following additional comments seem to be NiTs: > > --- > 3. DCCP-UDP > /insert a UDP ([RFC0768]) / > ^ ^ > -The brackets around the citation seem odd to me. [TomP] You mean '()' not '[]' right? I agree. > --- > /and there are no other IP addresses embedded./ > - There are no other IP addresses embedded in the encapsulation header, > there could be in the DCCP application data, with all that implies. [TomP] OK > --- > | Application Data Area | Variable length (could be 0) > - I prefer straight /Application Data/ > rather than /Application Data Area/ > - but I recall both being used in RFC 4340, so I guess this is personal > preference. [TomP] RFC 4340 uses "Application Data Area" in the basic packet format definition, so I'll stick with that. > --- > > > -- > Prof Gorry Fairhurst, School of Engineering, University of Aberdeen. > The University of Aberdeen is a charity registered in Scotland, > No SC013683.
