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.