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

RFC Errata System <rfc-editor@rfc-editor.org> Thu, 15 May 2025 15:46 UTC

Return-Path: <wwwrun@rfcpa.rfc-editor.org>
X-Original-To: behave@ietf.org
Delivered-To: behave@mail2.ietf.org
Received: from rfcpa.rfc-editor.org (unknown [167.172.21.234]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id EA14928EA003; Thu, 15 May 2025 08:46:32 -0700 (PDT)
Received: by rfcpa.rfc-editor.org (Postfix, from userid 461) id B178A1E71B5; Thu, 15 May 2025 08:46:32 -0700 (PDT)
To: rfc-editor@rfc-editor.org
From: RFC Errata System <rfc-editor@rfc-editor.org>
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20250515154632.B178A1E71B5@rfcpa.rfc-editor.org>
Date: Thu, 15 May 2025 08:46:32 -0700
Message-ID-Hash: ZFXSOPDO5TROQBN3SL77ROXHJIRRUKBX
X-Message-ID-Hash: ZFXSOPDO5TROQBN3SL77ROXHJIRRUKBX
X-MailFrom: wwwrun@rfcpa.rfc-editor.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-behave.ietf.org-0; header-match-behave.ietf.org-1; header-match-behave.ietf.org-2; header-match-behave.ietf.org-3; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: mlepage@google.com, philip_matthews@magma.ca, behave@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [BEHAVE] [Editorial Errata Reported] RFC6146 (8416)
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/behave/befzgbSvShawMyTZLFe7BkiBkxA>
List-Archive: <https://mailarchive.ietf.org/arch/browse/behave>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Owner: <mailto:behave-owner@ietf.org>
List-Post: <mailto:behave@ietf.org>
List-Subscribe: <mailto:behave-join@ietf.org>
List-Unsubscribe: <mailto:behave-leave@ietf.org>

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 <mlepage@google.com>

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