Skip to main content

IETF Last Call Review of draft-ietf-v6ops-claton-12
review-ietf-v6ops-claton-12-opsdir-lc-dodge-2025-11-22-00

Request Review of draft-ietf-v6ops-claton
Requested revision No specific revision (document currently at 16)
Type IETF Last Call Review
Team Ops Directorate (opsdir)
Deadline 2025-11-21
Requested 2025-11-07
Requested by Mohamed Boucadair
Authors Lorenzo Colitti , Jen Linkova , Tommy Jensen
I-D last updated 2026-06-15 (Latest revision 2026-03-05)
Completed reviews Dnsdir IETF Last Call review of -12 by Nicolai Leymann (diff)
Intdir IETF Last Call review of -12 by Dave Thaler (diff)
Opsdir IETF Last Call review of -12 by Menachem Dodge (diff)
Genart IETF Last Call review of -12 by Robert Sparks (diff)
Tsvart IETF Last Call review of -12 by Wesley Eddy (diff)
Dnsdir Telechat review of -13 by Nicolai Leymann (diff)
Assignment Reviewer Menachem Dodge
State Completed
Request IETF Last Call review on draft-ietf-v6ops-claton by Ops Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/ops-dir/KAnhxjzAepyZl8WSebiz5KLR1BY
Reviewed revision 12 (document currently at 16)
Result Has nits
Completed 2025-11-22
review-ietf-v6ops-claton-12-opsdir-lc-dodge-2025-11-22-00
Hi,

I have been selected as the Operational Directorate (opsdir) reviewer for this
Internet-Draft.

The Operational Directorate reviews all operational and management-related
Internet-Drafts to ensure alignment with operational best practices and that
adequate operational considerations are covered.

A complete set of _"Guidelines for Considering Operations and Management in
IETF Specifications"_ can be found at
https://datatracker.ietf.org/doc/draft-opsarea-rfc5706bis/.

While these comments are primarily for the Operations and Management Area
Directors (Ops ADs), the authors should consider them alongside other feedback
received.

- Document: draft-ietf-v6ops-claton-12

- Reviewer: Menachem Dodge

- Review Date: 22 November 2025

- Intended Status: Standards Track

 This document compliments and updates [RFC6877] and [RFC8585].
 It further defines CLAT node behavior and IPv6 Customer Edge Routers and
 supports IPv4-as-a-Service by providing recommendations for the node
 developers on enabling and disabling CLAT.

  The document is well written and provides good explanations. No major issues
  are found.

  I suggest that the introduction should either include a diagram or refer to
  the diagrams in RFC 6877.

  Section 9 describes the changes in text to RFC 8585, should there be a
  similar section describing changes to the text in RFC 6877 ?

## Summary

- Has Nits: This document is basically ready for publication but has nits that
should be considered prior to publication.

Nits:
=====

Section 4: Missing word 'to'.

OLD --->
   If the node does not receive a PREF64 from the network, the node is
   allowed use other mechanisms to detect the PLAT presence and obtain
   the NAT64 prefix (such as [RFC7050]).

SUGGESTED --->
   If the node does not receive a PREF64 from the network, the node is
   allowed to use other mechanisms to detect the PLAT presence and obtain
   the NAT64 prefix (such as [RFC7050]).

Best Regards,
Menachem