On Fri, Jun 13, 2025 at 6:29 PM Rebecca VanRheenen < rvanrhee...@staff.rfc-editor.org> wrote:
> 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. > LGTM, thank you. 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
