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

[Christian Huitema <[e-mail]>]

This errata is definitely not editorial. RFC 5780 is an experimental 
RFC, published 14 years ago. Its status is experimental. The authors 
described an experimental mechanism to characterize NAT behavior, using 
the knowledge available at the time. Forest asserts that some of the 
experimental mechanisms in that RFC do no always perform as expected in 
2010. This is not what erratas are for. Since this is an experimental 
RFC, the remedy should be to write a draft that proposes a better 
solution, and have it progress as appropriate.

-- Christian Huitema


On 6/7/2024 11:34 AM, Rebecca VanRheenen wrote:
> Hi Francesca and Zahed,
> 
> We are unable to verify this erratum that the submitter marked as editorial, so we changed the Type to “Technical”. As Stream Approver, please review and set the Status and Type accordingly (see the definitions at https://www.rfc-editor.org/errata-definitions/)
> 
> Note that the behave WG has concluded (as has the Transport Area), so we are sending this to you as ADs of the WIT Area.
> 
> You may review the report at:
> https://www.rfc-editor.org/errata/eid7971
> 
> Information on how to verify errata reports can be found at:
> https://www.rfc-editor.org/how-to-verify/
> 
> Further information on errata can be found at:
> https://www.rfc-editor.org/errata.php
> 
> Thank you.
> 
> RFC Editor/rv
> 
> 
> 
>> On Jun 5, 2024, at 12:46 PM, RFC Errata System <[e-mail]> wrote:
>>
>> 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
>>
> 
> _______________________________________________
> Behave mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]