Inline......
Juniper Business Use Only ________________________________ From: Rebecca VanRheenen <rvanrhee...@staff.rfc-editor.org> Sent: Friday, June 13, 2025 7:29 PM To: Ron Bonica <rbon...@juniper.net>; ek.i...@gmail.com <ek.i...@gmail.com>; 6man-...@ietf.org <6man-...@ietf.org> Cc: RFC Editor <rfc-edi...@rfc-editor.org>; 6man-cha...@ietf.org <6man-cha...@ietf.org>; bob.hin...@gmail.com <bob.hin...@gmail.com>; auth48archive@rfc-editor.org <auth48archive@rfc-editor.org> Subject: [AD] Re: AUTH48: RFC-to-be 9805 <draft-ietf-6man-deprecate-router-alert-13> for your review [External Email. Be cautious of content] 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://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9805-auth48diff.html__;!!NEt6yMaO-gk!G9f5eMrgpWuzcDgFdTkkdBmb_tziTDcbcwttombPkBlVSFbWs0R2ZsuN5OdNO26ZIUg2q43ov3ftbpF4iUvdxrAqCRhZFt4$ . 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 RB> Yes (We will not make changes to the single instance of "IP Router Alert Option” per your request.) RB> Perfect — FILES (please refresh) — Updated XML file: https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9805.xml__;!!NEt6yMaO-gk!G9f5eMrgpWuzcDgFdTkkdBmb_tziTDcbcwttombPkBlVSFbWs0R2ZsuN5OdNO26ZIUg2q43ov3ftbpF4iUvdxrAqTnU7Rcs$ Updated output files: https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9805.txt__;!!NEt6yMaO-gk!G9f5eMrgpWuzcDgFdTkkdBmb_tziTDcbcwttombPkBlVSFbWs0R2ZsuN5OdNO26ZIUg2q43ov3ftbpF4iUvdxrAqKbcy4Pc$ https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9805.pdf__;!!NEt6yMaO-gk!G9f5eMrgpWuzcDgFdTkkdBmb_tziTDcbcwttombPkBlVSFbWs0R2ZsuN5OdNO26ZIUg2q43ov3ftbpF4iUvdxrAqP9FjQ7I$ https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9805.html__;!!NEt6yMaO-gk!G9f5eMrgpWuzcDgFdTkkdBmb_tziTDcbcwttombPkBlVSFbWs0R2ZsuN5OdNO26ZIUg2q43ov3ftbpF4iUvdxrAqCLxFKCg$ Diff file showing all changes made during AUTH48: https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9805-auth48diff.html__;!!NEt6yMaO-gk!G9f5eMrgpWuzcDgFdTkkdBmb_tziTDcbcwttombPkBlVSFbWs0R2ZsuN5OdNO26ZIUg2q43ov3ftbpF4iUvdxrAqCRhZFt4$ https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9805-auth48rfcdiff.html__;!!NEt6yMaO-gk!G9f5eMrgpWuzcDgFdTkkdBmb_tziTDcbcwttombPkBlVSFbWs0R2ZsuN5OdNO26ZIUg2q43ov3ftbpF4iUvdxrAqGJvULuU$ (side by side) Diff files showing all changes: https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9805-diff.html__;!!NEt6yMaO-gk!G9f5eMrgpWuzcDgFdTkkdBmb_tziTDcbcwttombPkBlVSFbWs0R2ZsuN5OdNO26ZIUg2q43ov3ftbpF4iUvdxrAqBxW2AfU$ https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9805-rfcdiff.html__;!!NEt6yMaO-gk!G9f5eMrgpWuzcDgFdTkkdBmb_tziTDcbcwttombPkBlVSFbWs0R2ZsuN5OdNO26ZIUg2q43ov3ftbpF4iUvdxrAqaCEx0tA$ (side by side) https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9805-alt-diff.html__;!!NEt6yMaO-gk!G9f5eMrgpWuzcDgFdTkkdBmb_tziTDcbcwttombPkBlVSFbWs0R2ZsuN5OdNO26ZIUg2q43ov3ftbpF4iUvdxrAq5e1TsYw$ (diff showing changes where text is moved or deleted) For the AUTH48 status of this document, please see: https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9805__;!!NEt6yMaO-gk!G9f5eMrgpWuzcDgFdTkkdBmb_tziTDcbcwttombPkBlVSFbWs0R2ZsuN5OdNO26ZIUg2q43ov3ftbpF4iUvdxrAqDCx_7I8$ 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
