Hi,Here is my review. I'm afraid I can't contribute much regarding Section 5 because I don't know enough about this stuff (but reading this was educational, it made me follow some references and print them :-) next time I'm equipped!). Anyway, it's good to see that this has already been commented on.
I generally found the document well written, and I only found some nits, below - definitely no show-stoppers:
- sec 3.4 par 1: s/implementations/implementationand: this paragraph sounds as if it's talking about a tunnel endpoint (because of the use of "transfer"), which the document otherwise is not.
Also about sec 3.4: it would be good to give an example. When I read this, my first thought was "huh? Aren't *network layer* options meant for the *network layer* ?" On second thought, Quick-Start came to my mind (I suspect that was also on your mind) - so, as a service to the reader, it would help to just mention e.g. Quick-Start as an example.
sec 3.8: "NAT/NAPT topologies" => did you really mean to use "topologies" here? (I guess you meant technologies)
sec 3.9 par 2 sentence 1: s/apply/applies (I think?!) sec 5 very end: missing "." sec 5.1 par 2 sentence 2 should be: "Following [RFC5762], this document..." sec 5.2 par 2: the comma after "media level attribute" seems strange to me.sec 6 par 3: I found the phrase "tunnel encapsulation" confusing, when the document starts out, in section 3 par 1, by stating that "this is not a tunneling approach". Maybe best to just remove the word "tunnel" here (in sec 6).
par 5 sentence 1 should be: "A firewall _that_ interprets this specification could inspect the _encasulated_ DCCP..."
sec 7.1 par 1 sent 2: double use of "section" hereReferences ICE-TCP and ICMP: I guess it would be good to provide the draft names.
Author addresses: empy URI / http at the very end of Colin should be removed (picky, ain't I :-) ) Cheers, Michael On 6/15/11 9:42 AM, Pasi Sarolahti wrote:
Hi,
In DCCP WG we are soon concluding draft-ietf-dccp-udpencap ("Datagram Congestion Control Protocol (DCCP) Encapsulation for NAT Traversal (DCCP-UDP)"). This draft has parts related to the work done in MMUSIC (especially Section 5), and it was presented in the MMUSIC meeting in last IETF. The authors have modified the text based on the input received, and we are now looking for volunteer(s) from MMUSIC to review whether the new text (mostly in Section 5) looks ok, before moving forward with the draft.
The draft can be found at http://tools.ietf.org/html/draft-ietf-dccp-udpencap-08
- Pasi
