NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)
RFC 5780

Note: This ballot was opened for revision 08 and is now closed.

(Magnus Westerlund) Yes

(Ron Bonica) No Objection

(Ralph Droms) No Objection

(Lisa Dusseault) (was Discuss) No Objection

Lars Eggert No Objection

(Adrian Farrel) No Objection

(Russ Housley) No Objection

Comment (2009-08-25 for -)
No email
send info
  Please consider the changes raised in the Gen-ART review by
  Pete McCann.  Pete reviewed -06, but the changes needed to address
  his comment were not made in -07.  The review can be found here:

  http://www.softarmor.com/rai/temp-gen-art/draft-ietf-behave-nat-behavior-discovery-06-mccann.txt

(Cullen Jennings) (was Discuss) No Objection

(Alexey Melnikov) No Objection

(Dan Romascanu) (was Discuss) No Objection

Comment (2009-08-27)
No email
send info
At the end of Section 1: 

   If a draft specifies the use of any portion of this STUN usage, that
   draft MUST document

Probably some other term than 'draft' should be used

(Robert Sparks) No Objection

Comment (2009-08-26 for -)
No email
send info
There are a few constants called out in the document (15 minutes for holding an unused port, not generating more than ten new transactions per second, etc.). Providing some motivation for the values you chose would be useful.

In section 6.1, "ensure that it does not generate a Response on a particular address" 
   should be
                "ensure that it does not generate a Response to a particular address"
   The sentence after that would really benefit from simplificaiton.

Nits: The end of section 2.2: "these two requirements" point back to a list of 3 things.
      2nd paragraph of 4.5: "Section Section"
      Just before 5.1: expand RTOs

(Tim Polk) Abstain

Comment (2009-09-03 for -)
No email
send info
[Note: I have moved from an open position to 'Abstain'.  On the telechat, I indicated I would
remain as an open position, but I later discovered that comments associated with open
positions are not displayed in some tracker interfaces. The change in position was designed
to ensure the comments were displayed to the authors just in case they decide to address
them.]

It seems clear that two of the conditions for NAT behavior discovery to be generally
useful are
(1) detecting the "correct" information a reasonably high percentage of the time; and
(2) unambiguous determination that the fallback mechanism should be invoked.

It was not clear from my reading that these issues are addressed.

The experiments as defined do not seem to determine (1); should this be added?

I could not find an algorithm for (2) in the document.  Is this as simple as "connection
failed, move to fallback" or is it application-dependent?  Note that the algorithm for
(2) can have false positives (i.e., scenarios that invoke the fallback unnecessarily)
as long as we don't have false negatives.