[BEHAVE] [Editorial Errata Reported] RFC5780 (7971)

[RFC Errata System <[e-mail]>]

The following errata report has been submitted for RFC5780,
"NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7971

--------------------------------------
Type: Editorial
Reported by: Forest <[e-mail]>

Section: 4.4

Original Text
-------------
This will also require at most three tests.

[...]

If
the client receives a response, the current behavior is Address-
Dependent Filtering; if no response is received, the current behavior
is Address and Port-Dependent Filtering.

Corrected Text
--------------
This will require at most four tests.

[...]

If the client receives a response, the current behavior is
Address-Dependent Filtering.

If no response is received, test IV must be performed to distinguish
between Address and Port-Dependent Filtering and lack of connectivity
with the STUN server's alternate address.  For example, a server
might be configured with a private OTHER-ADDRESS or reside behind an
interfering firewall.  In test IV, the client sends a Binding Request
(without a CHANGE-REQUEST attribute) to the alternate address, but
primary port.  If the client receives a response, the current
behavior is Address and Port-Dependent Filtering; if no response is
received, the client knows that it does not have UDP connectivity
with the server's alternate address, and therefore cannot use the
current server to determine the current filtering behavior.

Notes
-----
I am suggesting this change after encountering several public STUN
servers with an OTHER-ADDRESS (or CHANGED-ADDRESS) set to 0.0.0.0,
10.x.x.x, 172.x.x.x, or 192.168.x.x. With such a server, a client
following this RFC as currently written (version 08) will incorrectly
assume it has discovered Address and Port-Dependent Filtering.

I would also note in section 4.5 (Combining and Ordering Tests) that
filtering behavior test IV is the same as the mapping behavior test
II, allowing them to be combined so long as the filtering tests are
done before the mapping tests (to preserve prior NAT state).

In support of that ordering, I would ideally have this RFC present
the filtering tests before presenting the mapping tests, by swapping
section 4.4 with 4.3 and swapping 3.2 with 3.1. This would make
things easier for people implementing the spec, as they would
intuitively follow the optimal ordering simply by following the RFC's
presented order, and would no longer have to mentally reorder the
written steps whenever validating or reasoning about their code.
Swapping those sections would, of course, affect external references
to those section numbers; I don't know if that would too disruptive a
change without assigning a new RFC number.

Instructions:
-------------
This erratum is currently posted as "Reported". (If it is spam, it 
will be removed shortly by the RFC Production Center.) Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
will log in to change the status and edit the report, if necessary.

--------------------------------------
RFC5780 (draft-ietf-behave-nat-behavior-discovery-08)
--------------------------------------
Title               : NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)
Publication Date    : May 2010
Author(s)           : D. MacDonald, B. Lowekamp
Category            : EXPERIMENTAL
Source              : Behavior Engineering for Hindrance Avoidance
Stream              : IETF
Verifying Party     : IESG