I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-behave-nat-behavior-discovery-06 Reviewer: Pete McCann Review Date: 30 March 2009 IETF LC End Date: 31 March 2009 IESG Telechat date: unknown Summary: Ready for publication as an Experimental RFC. Major issues: NONE Minor issues: The Abstract incorrectly defines STUN to be: Simple Traversal Underneath Network Address Translators Later in the draft, STUN is correctly expanded to: Session Traversal Utilities for NAT End of Section 2.2: apocryphal evidence Did you mean "anecdotal evidence"? Section 6.1 states: If the Request contained a PADDING attribute, PADDING MUST be included in the Binding Response. The server SHOULD use a length of PADDING equal to the MTU on the outgoing interface. Section 7.7 states: PADDING MUST NOT be longer than the length that brings the total IP datagram size to 64K and SHOULD be an even multiple of four bytes. Because STUN messages with PADDING are intended to test the behavior of UDP fragments, they are an exception to the usual rule that STUN messages be less than the MTU of the path. These two statements are not incompatible; however, I wonder if you wanted to mandate literally "length of PADDING equal to the MTU". Together with other fields, this would bring the total length up to something above the MTU, so fragmentation would happen (as desired). It might help the reader to repeat the SHOULD from 6.1 in the text in 7.7. Nits/editorial comments: Section 8: This draft defines new STUN response code. SHOULD BE: This draft defines two new STUN response codes. _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
