[Gen-art] AD Followup: draft-ietf-v6ops-framework-md-ipv6only-underlay-24

[Mahesh Jethanandani <[e-mail]>]

Authors,

Thanks for the work on -24 — it cleaned up essentially everything from my earlier review (RFC 6052 Table 1, the PE/RFC 4026 definition, the Operational Considerations section, and several other items). I've now also read the five directorate reviews from Last Call (INTDIR/Jinmei, GENART/Bryant, TSVART/Trammell, OPSDIR/Chown, SECDIR/Lonvick), thank you to all of them. Before I can send this to the IESG, I'd like the following addressed. None of these rise to a blocking technical issue for an Informational document, but I want them closed out in a -25.

1. Mapping rule exchange mechanism (INTDIR, major)
Section 5.2 explicitly leaves the address-mapping-rule exchange mechanism open ("other protocols," "non-routing mechanisms... outside the scope of this document") while the rest of the framework's interoperability depends on it. I'm not asking you to mandate MP-BGP normatively, but please add a short paragraph stating the properties any exchange mechanism needs to satisfy — e.g., that it must convey the Forwarding Type field from Section 4.1, and that it must scale across multiple independently-administered operators. Right now, a reader can't tell what "done right" looks like for anything other than the IDR draft.

2. Likely typo in Section 4.2
"[I-D.ietf-idr-mpbgp-extension-4map6] can be implemented in PE1 and PE2..." — the worked example throughout is PE1 (ingress) to PE3 (egress), and the very next sentence correctly says "from PE3 to PE1." Please confirm and fix (PE2 doesn't appear elsewhere in this scenario).

3. ECN / Traffic Class handling (TSVART, major)
Section 7 cites RFC 7915 Section 1.4 and Section 4.2/5.2 for MTU and ICMP handling, but doesn't mention Traffic Class/ECN, which RFC 7915 Section 4.1/5.1 covers separately. Those sections 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. Please add a sentence alongside the existing MTU guidance pointing to Section 4.1/5.1 and noting this interaction.

4. Cross-domain MTU framing (TSVART, major)
Worth two things here: first, per Section 4.2, only the ingress/egress PEs convert packets — intermediate P routers just forward, so the 20/40-byte overhead is incurred once, not per-AS-hop. It would help to state that explicitly, since it directly addresses Brian's "each hop adds a penalty" framing. Second, the real multi-domain-specific risk is Path MTU Discovery reliability — an ICMPv6 Packet Too Big from a P router in one operator's AS has to reach the originating IPv4 host across administrative boundaries with independent ICMP-filtering policies. That's a materially different risk than single-domain PMTUD and is exactly what this framework's multi-operator scope introduces. A couple of sentences on cross-domain PMTUD/ICMP reachability would close this out.

Nothing further needed:

GENART's UDP zero-checksum comment is already covered by reference — RFC 7915 Section 4.5 has SHOULD-level guidance for this, and Section 5.3 already says translation complies with RFC 7915. You can note this in your response to Stewart without touching the document.

Everything else from the five directorate reviews (Section 3's AS/NP wording, the CAPEX acronym, the default-rule forward reference, the OPTIONAL/MUST split in 8.3, the Section 8.2 boilerplate for SECDIR) is already fixed in -24 and needs no further action.

A handful of NITs (subject-verb agreement in Section 3, a comma splice and a contraction in Section 4.1, and "one default address mapping rule" wording in 5.2) are in the attached review file — pick these up whenever convenient, no need to report back on them.

Happy to discuss any of the above. Once a -25 addresses items 1–5, I'll move this to IESG evaluation.

Thanks.

Mahesh Jethanandani
[e-mail]