Thanks to Chongfeng and the other authors for addressing my previous blocking DISCUSS issues (see https://mailarchive.ietf.org/arch/msg/v6ops/o-R9edbNTwZWoJYxfD8mMbcMZQo/).

There are still many BCP14 "SHOULD" that could either be "MUST" or "should" (if not linked to interoperability) or be accompanied with the BCP14 guidance though.

## COMMENTS (previous for Discussion)

I see changes in -29 (that were made in an earlier revision). These are sufficient to change my position for my  previous comments on Section 7. For completeness, the original reviewed text read:
  "In addition, section 4.1 and section 5.1 of
   [RFC7915] give translators a SHOULD-level option to zero the TOS/
   Traffic Class octet entirely on translation ("administrative
   bleaching"), which silently kills ECN if an operator enables it for
   DSCP hygiene."

(1) Is it possible to avoid terms such as "DSCP hygiene", avoid "kills" (blocks?) and avoid/clarify that the term "TOS/Traffic Class octet" is Historic. I note that RFC 7915 refers to the former ToS Field" and introduces ToS semantics, this detail should be clarified in the present document, because such a policy is no longer applicable in 2026. 

(2) I would like to discuss if this I-D can clearly state that other fields in the IPv4/IPv6 header ought to be mapped to corresponding values, in particular the DiffServ Field (subject to the filtering and update considerations of [RFC2475]) and the ECN Field. As per 
https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc6146-bis/

## COMMENTS (non-blocking)

### Section 7:  Operational Considerations

“Therefore, network providers must handle MTU and fragmentation issues, for example, by configuring appropriate MSS
clamping,"
- This is a TCP-specific mechanism, it would be super helpful to indicate that this is for "TCP".

Thank for addressing the above concerns.

Gorry

Original DISCUSS: https://mailarchive.ietf.org/arch/msg/v6ops/9qcdB1zAfbSchu_EFu0Q_gmh5b8/

Thank to the author team for resolving all my DISCUSS points: https://mailarchive.ietf.org/arch/msg/v6ops/V6ugy9ErNl1dVANMy74sHTeMcuU/

Be well,
G/

Thanks to the authors and the WG for their work on this document.

As someone that supports IPv6 and especially IPv6-only underlay deployments, 
I fully support this work now that its scope has been clarified.

My thanks to Chongfeng/co-authors for all the discussions and working
through the updates as well as their patience as we went through
this process. I hope this helps make this document very clear in its
positioning and support the proposed BGP routing work.

# IESG review of draft-ietf-v6ops-framework-md-ipv6only-underlay-27

CC @MikeBishop

## Comments

### Section 2, paragraph 1

This section expands common abbreviations, but doesn't point to
definitions of the expanded terms.

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 1, paragraph 2
```
-    IETF work focusing on IPv6 optimization”[IAB-statement].  To ensure
+    IETF work focusing on IPv6 optimization” [IAB-statement].  To ensure
+                                            +
```