The current problems originate from the way in which routers are required to action a Router Alert. I understand this I-D does not change any existing RFC, but seeks to restrict usage in new specifications. Thank you, it is well written. 

Note: It is a little sad that the I-D does not offer an alternative to identify packets sent by future protocols (such as protocols operating like RSVP would in future be identified in a network that wished to use this type of signalling to nodes on the path), this is presumably part of any future work.

I am in support for the discuss from Ketan and Med. 

Thank you for putting together this draft, it's well written and does a great job explaining the motivation behind the proposed deprecation.

One small note: the way "deprecation" is used in the draft doesn’t fully align with how IANA typically handles the term in registry language (=use is not recommended). For reference, RFC 8126, Section 9.6 (https://datatracker.ietf.org/doc/html/rfc8126#section-9.6) offers some helpful guidance, and additional aspects on the distinction between deprecated and obsolete status in IANA registries. For this document the usage of the code points is still perfectly good, hence "use is not recommended" does not really apply. However, if there is a new application that intends to request a code-point then that will be frowned upon going forward.

relevant RFC 8126 text
"
   Specific entries in a registry can be marked as "obsolete" (no longer
   in use) or "deprecated" (use is not recommended).
"

From this perspective, i support the proposal from Ketan to have this document explicit reserve the unassigned/experimental code points as suggested in Ketan's DISCUSS#2 as that will align the draft understanding of the term "deprecated" with the IANA understanding of the term "deprecated"

I also feel that the title could be made slightly more clear as both Med and Eric V observed in their ballot reviews.

Thanks to the authors for addressing my discussion points.

For the benefit of the authors and the responsible AD, I am listing below the major comments that I would appreciate being clarified/update.

< Related to IANA - so deferring to IANA team mostly >

1) Should the Router Alert Options values registry be "closed" or should all the unassigned and experimental values be marked "reserved" so no further allocations can be made.

2) The tag of "deprecated" on the Router Alert Option seems incorrect since in this case, it is not "not recommended to be used". In this case, it is "not recommended to be used for new protocols" and therefore, IMHO, we need "deprecated for new protocols" in the IANA. This is new/different but this situation is different.

< for the authors >

3) The title of the draft should include "... for New Protocols" . Refer comments by Med and Eric.

I support Ketan's and by reference Med's DISCUSS points.

In Section 1, should "Router Option" be "Router Alert Option"?

In Section 3, don't present it as "One approach would be to" do the thing in this draft which "would allow" certain benefits; if this is going to RFC, we've clearly decided this is the path forward. Be less conditional and focus on the present and future: "Because..., deprecation allows...."

In Section 4, consider s/may continue to use/are currently known to use/, since it's not guaranteed you have an exhaustive list of niche and rarely deployed protocols. Similarly, in Appendix A, I'd suggest "that are known to use" rather than "that use".

In Section 6, I question whether marking something as deprecated in itself mitigates all security issues with it. There are still steps routers need to take to protect themselves, as previously described, because they can't rely on attackers to comply with this RFC. I'd suggest instead referencing those RFCs for existing security considerations and stating that routers can mitigate attacks by ignoring the option unless explicitly configured to inspect it.

Thank you to Mallory Knodel for the GENART review.

** Section 7
   IANA is requested to mark the Router Alert Option as "Deprecated" in
   the Destination Options and Hop-by-hop Options Registry (
   https://www.iana.org/assignments/ipv6-parameters/
   ipv6-parameters.xhtml#ipv6-parameters-2) and add a pointer to this
   document.

To aid the reader, be explicit that marking something as being “Deprecated” means renaming the code point by adding a suffix of “(DEPRECATED)”. 
 
It’s a curious, but undocumented convention which isn’t covered by RFC8200, RFC2780, or RFC9673 which manage this registry.  Not to be done in this document, but an explicit column could be added to these registries in this group.  Some notion of status in a distinct column is a common practice in other registries.

# Éric Vyncke, INT AD, comments for draft-ietf-6man-deprecate-router-alert-09
CC @evyncke

Thank you for the work put into this document even if I wonder whether RFC 8200 stance about HbH being optional to parse is not enough.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Bob Hinden for the shepherd's detailed write-up including the WG consensus _but it lacks_ the justification of the intended status.

Other thanks to Bob Halley , the Internet directorate reviewer (at my request):
https://datatracker.ietf.org/doc/review-ietf-6man-deprecate-router-alert-08-intdir-telechat-halley-2025-03-08/

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS (non-blocking)

### Title

Like Med Boucadair, strongly suggest to make the title clearer with "Deprecation of the IPv6 Router Alert Option Use by New Protocols".

### Obsoleting RFC 2711

As router alert will become deprecated and not historic, I wonder whether this I-D can/should update RFC 2711 rather than obsoleting it.

### Section 1

Please note that IANA uses "protocol number" or extension header type in https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#extension-header rather than `each one identified by a distinct Next Header value`.

While English is not my primary language, what about s/the Router Alert Option introduces many issues/the Router Alert Option *has introduced* many issues/

What about adding "future versions" in `Implementers of protocols that continue to use the Router Option can continue to reference [RFC2711] for Router Alert Option details.` to match the abstract and be more useful/practical ?

### Section 6

It seems that `This document mitigates all security considerations` is too strong as current use of router alert can continue. Strongly suggest adding "for future protocols".

### Section 7

I support Med Boucadair's and Roman Danyliw's issues about being stricter and more precise for the IANA.