Hi Ron and Erik*,
*Erik, as AD, please review and approve the change from “may” to “MAY” in the
third sentence of Section 4 (to align with first sentence). The change is best
viewed in this diff file:
https://www.rfc-editor.org/authors/rfc9805-auth48diff.html.
Ron, thank you for responding to our questions so quickly! We have updated the
document accordingly and have one followup question:
>> a) We note inconsistencies in the terms listed below. We chose the latter
>> form
>> (i.e., capitalized "Option"). Please let us know if you prefer
>> differently.
>>
>> Router Alert option
>> Router Alert Option
>> Note: The capitalized form with "Option" is used in RFCs 6398, 7506, and
>> 9673 (and is
>> more common in this document); the lowercase form with "option" is used
>> in RFCs 8504
>> and 9288.
>
> RB> Please standardize on Router Alert option.
>
>
>> b) We see the following forms used in the document. Are any updates needed,
>> or
>> are these okay as is?
>>
>> Router Alert Option
>> IP Router Alert Option
>> IPv6 Router Alert Option
>
> RB> Please standardize on IPv6 Router Alert Option, except for the one case
> of IP Router Alert Option. That is a direct quote from
> another RFC.
We’d like to clarify how to update based on your replies to the two questions
above.
Should instances of the following:
Router Alert Option
and
IPv6 Router Alert Option
Be updated to (with “IPv6” and lowercase “option”):
IPv6 Router Alert option
(We will not make changes to the single instance of "IP Router Alert Option”
per your request.)
— FILES (please refresh) —
Updated XML file:
https://www.rfc-editor.org/authors/rfc9805.xml
Updated output files:
https://www.rfc-editor.org/authors/rfc9805.txt
https://www.rfc-editor.org/authors/rfc9805.pdf
https://www.rfc-editor.org/authors/rfc9805.html
Diff file showing all changes made during AUTH48:
https://www.rfc-editor.org/authors/rfc9805-auth48diff.html
https://www.rfc-editor.org/authors/rfc9805-auth48rfcdiff.html (side by side)
Diff files showing all changes:
https://www.rfc-editor.org/authors/rfc9805-diff.html
https://www.rfc-editor.org/authors/rfc9805-rfcdiff.html (side by side)
https://www.rfc-editor.org/authors/rfc9805-alt-diff.html (diff showing
changes where text is moved or deleted)
For the AUTH48 status of this document, please see:
https://www.rfc-editor.org/auth48/rfc9805
Thank you,
RFC Editor/rv
> On Jun 13, 2025, at 7:42 AM, Ron Bonica
> <rbonica=40juniper....@dmarc.ietf.org> wrote:
>
> Responses inline....... RB>
>
> Once the changes mentioned in this email are applied, I approve the document
> for publication.
>
>
> Ron
>
>
>
>
> Juniper Business Use Only
> From: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>
> Sent: Friday, June 13, 2025 1:38 AM
> To: Ron Bonica <rbon...@juniper.net>
> Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>; 6man-...@ietf.org
> <6man-...@ietf.org>; 6man-cha...@ietf.org <6man-cha...@ietf.org>;
> bob.hin...@gmail.com <bob.hin...@gmail.com>; ek.i...@gmail.com
> <ek.i...@gmail.com>; auth48archive@rfc-editor.org
> <auth48archive@rfc-editor.org>
> Subject: Re: AUTH48: RFC-to-be 9805
> <draft-ietf-6man-deprecate-router-alert-13> for your review
>
> [External Email. Be cautious of content]
>
>
> Ron,
>
> While reviewing this document during AUTH48, please resolve (as necessary)
> the following questions, which are also in the XML file.
>
>
> 1) <!-- [rfced] May we update "between IP Router Alert packets of interest and
> unwanted IP Router Alerts" as follows to improve readability?
>
> Original:
> In a nutshell, the IP Router Alert Option does
> not provide a universal mechanism to accurately and reliably
> distinguish between IP Router Alert packets of interest and unwanted
> IP Router Alerts.
>
> Perhaps:
> In a nutshell, the IP Router Alert Option does
> not provide a universal mechanism to accurately and reliably
> distinguish between IP Router Alert packets that are of interest
> and those that are unwanted.
> -->
>
> RB> Please leave this one alone. It is a direct quote from RFC 6398
>
> 2) <!-- [rfced] Please confirm that "may" in last sentence is correct. Or
> should it
> be "MAY" to correspond with "MAY" in the first sentence?
>
> RB> It should be MAY. Good catch!
>
> Original:
> Protocols
> that use the Router Alert Option MAY continue to do so, even in
> future versions. However, new protocols that are standardized in the
> future MUST NOT use the Router Alert Option. Appendix A contains an
> exhaustive list of protocols that may continue to use the Router
> Alert Option.
>
> Perhaps:
> Protocols
> that use the Router Alert Option MAY continue to do so, even in
> future versions. However, new protocols that are standardized in the
> future MUST NOT use the Router Alert Option. Appendix A contains an
> exhaustive list of protocols that MAY continue to use the Router
> Alert Option.
> -->
>
>
> 3) <!-- [rfced] Informative reference RFC 3810 has been obsoleted by
> RFC 9777. We recommend replacing RFC 3810 with RFC 9777. However, if RFC
> 3810 must be referenced, we suggest mentioning RFC 9777 (e.g., RFC 3810 has
> been obsoleted by RFC 9777). See Section 4.8.6 in the RFC Style Guide (RFC
> 7322).
> -->
>
> RB> Please update the reference.
>
> 4) <!-- [rfced] Should "router alert" in this text in Table 1 be updated to
> "Router Alert Option"?
>
> RB> Yes! Again, good catch
>
> Original:
> MPLS PING (Use of router alert deprecated)
>
> Perhaps:
> MPLS Ping (Use of Router Alert Option is deprecated)
> -->
>
>
> 5) <!-- [rfced] Please review whether the note in Section 3
> should be in the <aside> element. It is defined as "a container for
> content that is semantically less important or tangential to the
> content that surrounds it"
> (https://urldefense.com/v3/__https://authors.ietf.org/en/rfcxml-vocabulary*aside__;Iw!!NEt6yMaO-gk!E1ZXl_420vkIhm0Jn6eV9pDuF893K_6mF_2cRkP8AcbBmSXpudAshcsEIv6ky-Zd9CkylA4ezj-wh0Xlw1jVsPaN$
> ).
>
> RB> Yes, it is an <aside>. I never know that such an XML feature existed!
>
> Original:
> NOTE: Many routers maintain separation between forwarding and control
> plane hardware. The forwarding plane is implemented on high-
> performance Application Specific Integrated Circuits (ASIC) and
> Network Processors (NP), while the control plane is implemented on
> general-purpose processors. Given this difference, the control plane
> is more susceptible to a Denial-of-Service (DoS) attack than the
> forwarding plane.
> -->
>
>
> 6) <!-- [rfced] Terminology
>
> a) We note inconsistencies in the terms listed below. We chose the latter form
> (i.e., capitalized "Option"). Please let us know if you prefer
> differently.
>
> Router Alert option
> Router Alert Option
> Note: The capitalized form with "Option" is used in RFCs 6398, 7506, and
> 9673 (and is
> more common in this document); the lowercase form with "option" is used in
> RFCs 8504
> and 9288.
>
>
> RB> Please standardize on Router Alert option.
>
>
> b) We see the following forms used in the document. Are any updates needed, or
> are these okay as is?
>
> Router Alert Option
> IP Router Alert Option
> IPv6 Router Alert Option
>
> RB> Please standardize on IPv6 Router Alert Option, except for the one case
> of IP Router Alert Option. That is a direct quote from
> another RFC.
>
> Hop-by-Hop Options header
> IPv6 Hop-by-Hop Options header
>
> RB> Please standardize on Hop-by-Hop Options Header
>
>
>
> c) Should "Hop-by-Hop options" here be updated to "Hop-by-Hop Options header"?
>
> Original:
> One approach would be
> to deprecate the Router Alert option, because current usage beyond
> the local network appears to be limited, and packets containing Hop-
> by-Hop options are frequently dropped.
>
> Perhaps:
> One approach would be
> to deprecate the Router Alert Option, because current usage beyond
> the local network appears to be limited and packets containing the Hop-
> by-Hop Options header are frequently dropped.
>
> RB> Please leave this one alone. It is a direct quote from
>
>
> d) We updated "PING" to "Ping" per usage in RFCs 7506, 8029, and 9570.
>
> RB> Good catch
>
>
> e) May we update "INTSERV" to either "Intserv" (RFCs 9522, 9064, and 7417) or
> "IntServ" (RFCs 9049 and 6007), both of which are more common in the RFC
> Series?
> -->
>
> RB> Please do
>
>
>
> 7) <!-- [rfced] FYI - We have added expansions for the following
> abbreviation(s)
> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
> expansion in the document carefully to ensure correctness.
>
> Operations, Administration, and Maintenance (OAM)
> -->
>
> RB> Good catch!
>
> 8) <!-- [rfced] Please review the "Inclusive Language" portion of the online
> Style Guide
> <https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/*inclusive_language__;Iw!!NEt6yMaO-gk!E1ZXl_420vkIhm0Jn6eV9pDuF893K_6mF_2cRkP8AcbBmSXpudAshcsEIv6ky-Zd9CkylA4ezj-wh0Xlw3AtDTFD$
> >
> and let us know if any changes are needed. Updates of this nature typically
> result in more precise language, which is helpful for readers.
>
> Note that our script did not flag any words in particular, but this should
> still be reviewed as a best practice.
> -->
>
>
> Thank you.
>
> RFC Editor/rv
>
>
>
> On Jun 12, 2025, at 10:31 PM, rfc-edi...@rfc-editor.org wrote:
>
> *****IMPORTANT*****
>
> Updated 2025/06/12
>
> RFC Author(s):
> --------------
>
> Instructions for Completing AUTH48
>
> Your document has now entered AUTH48. Once it has been reviewed and
> approved by you and all coauthors, it will be published as an RFC.
> If an author is no longer available, there are several remedies
> available as listed in the FAQ
> (https://urldefense.com/v3/__https://www.rfc-editor.org/faq/__;!!NEt6yMaO-gk!E1ZXl_420vkIhm0Jn6eV9pDuF893K_6mF_2cRkP8AcbBmSXpudAshcsEIv6ky-Zd9CkylA4ezj-wh0XlwwV_tTqH$
> ).
>
> You and you coauthors are responsible for engaging other parties
> (e.g., Contributors or Working Group) as necessary before providing
> your approval.
>
> Planning your review
> ---------------------
>
> Please review the following aspects of your document:
>
> * RFC Editor questions
>
> Please review and resolve any questions raised by the RFC Editor
> that have been included in the XML file as comments marked as
> follows:
>
> <!-- [rfced] ... -->
>
> These questions will also be sent in a subsequent email.
>
> * Changes submitted by coauthors
>
> Please ensure that you review any changes submitted by your
> coauthors. We assume that if you do not speak up that you
> agree to changes submitted by your coauthors.
>
> * Content
>
> Please review the full content of the document, as this cannot
> change once the RFC is published. Please pay particular attention to:
> - IANA considerations updates (if applicable)
> - contact information
> - references
>
> * Copyright notices and legends
>
> Please review the copyright notice and legends as defined in
> RFC 5378 and the Trust Legal Provisions
> (TLP –
> https://urldefense.com/v3/__https://trustee.ietf.org/license-info__;!!NEt6yMaO-gk!E1ZXl_420vkIhm0Jn6eV9pDuF893K_6mF_2cRkP8AcbBmSXpudAshcsEIv6ky-Zd9CkylA4ezj-wh0XlwyPdvjPl$
> ).
>
> * Semantic markup
>
> Please review the markup in the XML file to ensure that elements of
> content are correctly tagged. For example, ensure that <sourcecode>
> and <artwork> are set correctly. See details at
>
> <https://urldefense.com/v3/__https://authors.ietf.org/rfcxml-vocabulary__;!!NEt6yMaO-gk!E1ZXl_420vkIhm0Jn6eV9pDuF893K_6mF_2cRkP8AcbBmSXpudAshcsEIv6ky-Zd9CkylA4ezj-wh0Xlw3kdsNv1$
> >.
>
> * Formatted output
>
> Please review the PDF, HTML, and TXT files to ensure that the
> formatted output, as generated from the markup in the XML file, is
> reasonable. Please note that the TXT will have formatting
> limitations compared to the PDF and HTML.
>
>
> Submitting changes
> ------------------
>
> To submit changes, please reply to this email using ‘REPLY ALL’ as all
> the parties CCed on this message need to see your changes. The parties
> include:
>
> * your coauthors
>
> * rfc-edi...@rfc-editor.org (the RPC team)
>
> * other document participants, depending on the stream (e.g.,
> IETF Stream participants are your working group chairs, the
> responsible ADs, and the document shepherd).
>
> * auth48archive@rfc-editor.org, which is a new archival mailing list
> to preserve AUTH48 conversations; it is not an active discussion
> list:
>
> * More info:
>
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!NEt6yMaO-gk!E1ZXl_420vkIhm0Jn6eV9pDuF893K_6mF_2cRkP8AcbBmSXpudAshcsEIv6ky-Zd9CkylA4ezj-wh0Xlw8E4OC4P$
>
> * The archive itself:
>
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!NEt6yMaO-gk!E1ZXl_420vkIhm0Jn6eV9pDuF893K_6mF_2cRkP8AcbBmSXpudAshcsEIv6ky-Zd9CkylA4ezj-wh0Xlw49zdemR$
>
> * Note: If only absolutely necessary, you may temporarily opt out
> of the archiving of messages (e.g., to discuss a sensitive matter).
> If needed, please add a note at the top of the message that you
> have dropped the address. When the discussion is concluded,
> auth48archive@rfc-editor.org will be re-added to the CC list and
> its addition will be noted at the top of the message.
>
> You may submit your changes in one of two ways:
>
> An update to the provided XML file
> — OR —
> An explicit list of changes in this format
>
> Section # (or indicate Global)
>
> OLD:
> old text
>
> NEW:
> new text
>
> You do not need to reply with both an updated XML file and an explicit
> list of changes, as either form is sufficient.
>
> We will ask a stream manager to review and approve any changes that seem
> beyond editorial in nature, e.g., addition of new text, deletion of text,
> and technical changes. Information about stream managers can be found in
> the FAQ. Editorial changes do not require approval from a stream manager.
>
>
> Approving for publication
> --------------------------
>
> To approve your RFC for publication, please reply to this email stating
> that you approve this RFC for publication. Please use ‘REPLY ALL’,
> as all the parties CCed on this message need to see your approval.
>
>
> Files
> -----
>
> The files are available here:
>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9805.xml__;!!NEt6yMaO-gk!E1ZXl_420vkIhm0Jn6eV9pDuF893K_6mF_2cRkP8AcbBmSXpudAshcsEIv6ky-Zd9CkylA4ezj-wh0Xlw1ntkWnN$
>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9805.html__;!!NEt6yMaO-gk!E1ZXl_420vkIhm0Jn6eV9pDuF893K_6mF_2cRkP8AcbBmSXpudAshcsEIv6ky-Zd9CkylA4ezj-wh0Xlwwm6sqB_$
>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9805.pdf__;!!NEt6yMaO-gk!E1ZXl_420vkIhm0Jn6eV9pDuF893K_6mF_2cRkP8AcbBmSXpudAshcsEIv6ky-Zd9CkylA4ezj-wh0Xlw4gy4kLS$
>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9805.txt__;!!NEt6yMaO-gk!E1ZXl_420vkIhm0Jn6eV9pDuF893K_6mF_2cRkP8AcbBmSXpudAshcsEIv6ky-Zd9CkylA4ezj-wh0Xlw5kz983J$
>
> Diff file of the text:
>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9805-diff.html__;!!NEt6yMaO-gk!E1ZXl_420vkIhm0Jn6eV9pDuF893K_6mF_2cRkP8AcbBmSXpudAshcsEIv6ky-Zd9CkylA4ezj-wh0XlwzIa6zn_$
>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9805-rfcdiff.html__;!!NEt6yMaO-gk!E1ZXl_420vkIhm0Jn6eV9pDuF893K_6mF_2cRkP8AcbBmSXpudAshcsEIv6ky-Zd9CkylA4ezj-wh0Xlwx9DIeem$
> (side by side)
>
> Alt-diff of the text (allows you to more easily view changes
> where text has been deleted or moved):
>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9805-alt-diff.html__;!!NEt6yMaO-gk!E1ZXl_420vkIhm0Jn6eV9pDuF893K_6mF_2cRkP8AcbBmSXpudAshcsEIv6ky-Zd9CkylA4ezj-wh0Xlw4F6_iMu$
>
> Diff of the XML:
>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9805-xmldiff1.html__;!!NEt6yMaO-gk!E1ZXl_420vkIhm0Jn6eV9pDuF893K_6mF_2cRkP8AcbBmSXpudAshcsEIv6ky-Zd9CkylA4ezj-wh0Xlw5LG9FPU$
>
>
> Tracking progress
> -----------------
>
> The details of the AUTH48 status of your document are here:
>
> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9805__;!!NEt6yMaO-gk!E1ZXl_420vkIhm0Jn6eV9pDuF893K_6mF_2cRkP8AcbBmSXpudAshcsEIv6ky-Zd9CkylA4ezj-wh0Xlw4RJIEjK$
>
> Please let us know if you have any questions.
>
> Thank you for your cooperation,
>
> RFC Editor
>
> --------------------------------------
> RFC9805 (draft-ietf-6man-deprecate-router-alert-13)
>
> Title : Deprecation Of The IPv6 Router Alert Option For New
> Protocols
> Author(s) : R. Bonica
> WG Chair(s) : Bob Hinden, Jen Linkova
>
> Area Director(s) : Erik Kline, Éric Vyncke
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
