IETF Last Call Review of draft-ietf-v6ops-claton-12
review-ietf-v6ops-claton-12-intdir-lc-thaler-2025-11-13-00

I am the assigned int-dir reviewer for this draft. These comments were written
with the intent of improving the Internet area aspects of the IETF drafts.
Please treat these comments just like any other last call comments. For background
on int-dir, please see the [FAQ](https://wiki.ietf.org/en/group/intdir).

I found the document well written and easy to read.  Thanks to the authors and
the WG for that.  I mostly found a number of typos and grammatical
issues that I classify as nits.  The non-nit is that there were a couple
cases of SHOULDs where it wasn't clear why they weren't MUSTs, i.e., when
might you *not* want to do it and what would be acceptable to do instead.  Most
SHOULDs are already clear in the document.

First case, section 4:
> A node may have multiple IPv6-only interfaces (for example, a mobile
> phone can be connected to an IPv6-only Wi-Fi network and to an
> IPv6-only mobile network).  In that case the node SHOULD run an
> independent, dedicated CLAT instance on each interface connected to a
> network equipped with PLAT.  Consequently, each CLAT instance SHOULD
> install a separate default IPv4 route on each CLAT-enabled interface.

For those two SHOULDs, what is ok instead?  Is it ever okay to run
a common instance across multiple interfaces?  Or is the only legal
alternative to just run one CLAT instance on one interface?  Similarly
for the second SHOULD, does that mean it's compliant to run separate
CLAD instances but only one default IPv4 route?  is it compliant to
run a shared CLAT instance across multiple interfaces, but with default
routes on both interfaces with some load sharing?  It seems to me that
there are potential landmines here hence my questions to verify
intended behavior.

Case two:
> Any delay in enabling CLAT on an IPv6-only node would be impactful
> for IPv4-only applications, as such applications cannot benefit from
> 464XLAT until CLAT is operational.  Therefore it is desirable that
> the node enables CLAT as soon as network support for PLAT is detected
> while native IPv4 connectivity is not yet detected.  The node SHOULD
> enable CLAT after discovering the NAT64 prefix, unless by that time
> the node has already obtained a non-link-local IPv4 address.

Same question about why this is only a SHOULD, rather than a conditional
MUST since it doesn't seem independent of previous SHOULDs.  I might
suggest something like the following.

OLD:
   The node SHOULD
   enable CLAT after discovering the NAT64 prefix, unless by that time
   the node has already obtained a non-link-local IPv4 address.
NEW:
   Unless configured otherwise, the node MUST
   enable CLAT if the node has not already obtained a non-link-local
   IPv4 address by the time it discovers the NAT64 prefix.

I also see statements like in section 5:
> Unless explicitly configured otherwise, the node SHOULD
> disable CLAT immediately upon obtaining a native IPv4 default
> gateway.

So to verify: if the node has NOT been explicitly configured,
it's still compliant to leave CLAT running when receiving an IPv4
native default gateway?   Why is this not a MUST?  This is a case
where the alternative to the SHOULD is (I think) clear but the
rationale is not and it seems potentially problematic to me.  I
get the case for explicit configuration. If intentional, perhaps
the case WG had in mind is some box that is marketed as only being
applicable for a specific case (maybe a special link layer so it's
not deployable in general environments?) where it's known to not
be problematic?  Still seems dangerous to me, so want to verify
this is intentional by the WG and understand the case for SHOULD
here in the non-configured case.

A copy with my editorial nits marked up inline is at 
https://1drv.ms/b/c/dc2b364f3f06fea8/EeBKe9TYbvJBhajRGP8w7egBU7j2VvMl35llZD2OwJBw6Q?e=QZ84d5

Dave