[BEHAVE] Re: [Editorial Errata Reported] RFC6146 (8416)

[Madison Church <[e-mail]>]

Hi Mike and Gorry,

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 this document comes from the Behavior Engineering for Hindrance Avoidance (behave) Working Group, which is now concluded.

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

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/mc

> On May 15, 2025, at 10:46 AM, RFC Errata System <[e-mail]> wrote:
> 
> The following errata report has been submitted for RFC6146,
> "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid8416
> 
> --------------------------------------
> Type: Editorial
> Reported by: Marc Lepage <[e-mail]>
> 
> Section: 3.5.1.1
> 
> Original Text
> -------------
> In all cases, the allocated IPv4 transport address (T,t) MUST NOT be in use in another entry in the same BIB, but can be in use in other BIBs (e.g., the UDP and TCP BIBs).
> 
> Corrected Text
> --------------
> In all cases, the allocated IPv4 transport address (T,t) MUST NOT be in use in another entry in the same BIB, but can be in use in other BIBs (e.g., the TCP and ICMP BIBs).
> 
> Notes
> -----
> The confusing wording appears in section 3.5.1.1 (regarding UDP BIB) and 3.5.2.3 (regarding TCP BIB).
> 
> It's possible and reasonable to interpret section 3.5.1.1's text
> 
>    "but can be in use in other BIBs (e.g., the UDP and TCP BIBs)"
> 
> as if the text were:
> 
>    "but can be in use in other BIBs (i.e., can be in use in the other BIBs, which in this case are the UDP and TCP BIBs)."
> 
> This looks like an error, because when *this* BIB is the UDP BIB, the *other* BIBs are the TCP and ICMP BIBs, not the UDP and TCP BIBs.
> 
> This interpretation is reasonable because use of the Latin "e.g." ("for example") makes it seem like the given BIBs are examples of "other BIBs."
> 
> Similarly, in section 3.5.2.3, *this* BIB is the TCP BIB, the *other* BIBs are the UDP and ICMP BIBs, but the text mentions UDP and TCP BIBs in the parenthetical example, and again looks like an error.
> 
> If this is the correct interpretation, then each section simply requires the correct *other* example BIBs in the parenthetical. [Section 3.5.1.1 corrected text given above; section 3.5.2.3 would be corrected in a similar manner.]
> 
> However, there is another possible interpretation, in which the given BIBs are correctly stated, but the wording is unclear as to what is denoted by the parenthetical example. In this interpretation, section 3.5.1.1 is intended as if the text were:
> 
>    "but can be in use in other BIBs (i.e., the same address can be used in entries in both the UDP and TCP BIBs),"
> 
> or
> 
>    ""but can be in use in other BIBs (i.e., the UDP and TCP BIBs can have an entry using the same address)."
> 
> If this interpretation is intended, then it should be made clearer, and probably should use the Latin "i.e." ("that is") for the clarifying situation. [Again, in sections 3.5.1.1 and 3.5.2.3.]
> 
> Either way, because interpretation of the text is ambiguous in a way that affects its normative meaning, it should be clarified.
> 
> 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.
> 
> --------------------------------------
> RFC6146 (draft-ietf-behave-v6v4-xlate-stateful-12)
> --------------------------------------
> Title               : Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers
> Publication Date    : April 2011
> Author(s)           : M. Bagnulo, P. Matthews, I. van Beijnum
> Category            : PROPOSED STANDARD
> Source              : Behavior Engineering for Hindrance Avoidance
> Stream              : IETF
> Verifying Party     : IESG