NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)
draft-ietf-behave-nat-behavior-discovery-08
Yes
(Magnus Westerlund)
No Objection
(Adrian Farrel)
(Alexey Melnikov)
(Cullen Jennings)
(Lars Eggert)
(Lisa Dusseault)
(Ralph Droms)
(Ron Bonica)
Abstain
(Tim Polk)
Note: This ballot was opened for revision 08 and is now closed.
Magnus Westerlund Former IESG member
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
()
Unknown
Alexey Melnikov Former IESG member
No Objection
No Objection
()
Unknown
Cullen Jennings Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
(was Discuss)
No Objection
No Objection
(2009-08-27)
Unknown
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
Lars Eggert Former IESG member
No Objection
No Objection
()
Unknown
Lisa Dusseault Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Ralph Droms Former IESG member
No Objection
No Objection
()
Unknown
Robert Sparks Former IESG member
No Objection
No Objection
(2009-08-26)
Unknown
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
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(2009-08-25)
Unknown
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
Tim Polk Former IESG member
Abstain
Abstain
(2009-09-03)
Unknown
[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.