Hi Rebecca and all, I also checked the document and approve it. Thank you. One quick thing -- my company name changed last month. So please change my affiliation/contact information as below (e-mail is not changed though):
Yuji Kamite NTT DOCOMO BUSINESS Chiyoda-ku, Tokyo Japan Email: y.kam...@ntt.com Best regards, -Yuji -----Original Message----- From: Rebecca VanRheenen <rvanrhee...@staff.rfc-editor.org> Sent: Tuesday, August 12, 2025 12:03 PM To: Jalil, Luay <luay.ja...@verizon.com>; Ron Bonica <rbonica=40juniper....@dmarc.ietf.org>; adr...@olddog.co.uk; x...@cernet.edu.cn; Yuji Kamite（上手祐治） <y.kam...@ntt.com>; luay.ja...@one.verizon.com Cc: RFC Editor <rfc-edi...@rfc-editor.org>; 6man-...@ietf.org; 6man-cha...@ietf.org; bob.hin...@gmail.com; ek.i...@gmail.com; auth48archive@rfc-editor.org Subject: Re: [E] AUTH48: RFC-to-be 9837 <draft-ietf-6man-vpn-dest-opt-11> for your review Hi Luay, We marked your approval on the AUTH48 status page for this document (see https://www.rfc-editor.org/auth48/rfc9837). Once we receive approval from Yuji, we can move this document forward. Thank you! RFC Editor/rv > On Aug 11, 2025, at 10:13 AM, Jalil, Luay <luay.ja...@verizon.com> wrote: > > I approve this text > > Thanks & Regards, > Luay > > > On Fri, Aug 8, 2025 at 1:27 PM Rebecca VanRheenen > <rvanrhee...@staff.rfc-editor.org> wrote: > Hi Adrian and other authors, > > Adrian - Thank you for addressing all of our questions. We have updated the > document accordingly. > > All - Please review the document carefully to ensure satisfaction as we do > not make changes once it has been published as an RFC. Contact us with any > further updates or with your approval of the document in its current form. We > will await approvals from each author prior to moving forward in the > publication process. > > — FILES (please refresh) — > > Updated XML file: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor. > org_authors_rfc9837.xml&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6_ > _0PomBTQ&r=7yfE7g9ZjpRzGkNuVTidj5c7H2bMIhCLfUwl8WcELSY&m=gO9zA0ffe2t_4 > NV2T2AksRFFs-YSXO8LuLCC31R30lYa6cZ2CONXjAvMbLE5fZOh&s=31koYsVpRkIZcHhh > s7Rw-qt9zfswAdKgXPDRAn2-RqU&e= > > Updated output files: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9837.txt&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=7yfE7g9ZjpRzGkNuVTidj5c7H2bMIhCLfUwl8WcELSY&m=gO9zA0ffe2t_4NV2T2AksRFFs-YSXO8LuLCC31R30lYa6cZ2CONXjAvMbLE5fZOh&s=47Jmyl9yzLvGBqO14yHzGYEPKdgB0iUlFgeBXjMMmQo&e= > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9837.pdf&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=7yfE7g9ZjpRzGkNuVTidj5c7H2bMIhCLfUwl8WcELSY&m=gO9zA0ffe2t_4NV2T2AksRFFs-YSXO8LuLCC31R30lYa6cZ2CONXjAvMbLE5fZOh&s=_cmMp_eGiwaDz1k8vNf3JZOi1nontw_uKKg69pJt7Bk&e= > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor. > org_authors_rfc9837.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6 > __0PomBTQ&r=7yfE7g9ZjpRzGkNuVTidj5c7H2bMIhCLfUwl8WcELSY&m=gO9zA0ffe2t_ > 4NV2T2AksRFFs-YSXO8LuLCC31R30lYa6cZ2CONXjAvMbLE5fZOh&s=dMRfft8g4gXIYtq > dC4FERBb39rL7vOpLYRIM5eHGaWA&e= > > Diff file showing all changes made during AUTH48: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9837-2Dauth48diff.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=7yfE7g9ZjpRzGkNuVTidj5c7H2bMIhCLfUwl8WcELSY&m=gO9zA0ffe2t_4NV2T2AksRFFs-YSXO8LuLCC31R30lYa6cZ2CONXjAvMbLE5fZOh&s=1W6czM0dLiWFlpmxXvautxJj6mriLi80cUWrIclMJKU&e= > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor. > org_authors_rfc9837-2Dauth48rfcdiff.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UH > pJlPps3mZ3LRxpb6__0PomBTQ&r=7yfE7g9ZjpRzGkNuVTidj5c7H2bMIhCLfUwl8WcELS > Y&m=gO9zA0ffe2t_4NV2T2AksRFFs-YSXO8LuLCC31R30lYa6cZ2CONXjAvMbLE5fZOh&s > =TVbTpRj5cLe5BmZqvCVaBizTOM-NlG8Tm6GBRwG7vw8&e= (side by side) > > Diff files showing all changes: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9837-2Ddiff.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=7yfE7g9ZjpRzGkNuVTidj5c7H2bMIhCLfUwl8WcELSY&m=gO9zA0ffe2t_4NV2T2AksRFFs-YSXO8LuLCC31R30lYa6cZ2CONXjAvMbLE5fZOh&s=f7hmZTD7zCqSYtS8Qo2zSffT55mLWr2OPGrdqhweJAA&e= > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9837-2Drfcdiff.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=7yfE7g9ZjpRzGkNuVTidj5c7H2bMIhCLfUwl8WcELSY&m=gO9zA0ffe2t_4NV2T2AksRFFs-YSXO8LuLCC31R30lYa6cZ2CONXjAvMbLE5fZOh&s=J8HLXR-mraB-riDjCzyltZ5Fbv-N6wpi0w10b78f0rE&e= > (side by side) > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor. > org_authors_rfc9837-2Dalt-2Ddiff.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJl > Pps3mZ3LRxpb6__0PomBTQ&r=7yfE7g9ZjpRzGkNuVTidj5c7H2bMIhCLfUwl8WcELSY&m > =gO9zA0ffe2t_4NV2T2AksRFFs-YSXO8LuLCC31R30lYa6cZ2CONXjAvMbLE5fZOh&s=1W > owecHEKNW6iy-9SKhh-fnBH_POxjavgv6S7ITwsb4&e= (diff showing changes > where text is moved or deleted) > > For the AUTH48 status of this document, please see: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor. > org_auth48_rfc9837&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0Pom > BTQ&r=7yfE7g9ZjpRzGkNuVTidj5c7H2bMIhCLfUwl8WcELSY&m=gO9zA0ffe2t_4NV2T2 > AksRFFs-YSXO8LuLCC31R30lYa6cZ2CONXjAvMbLE5fZOh&s=ss_fyRM6UnkMgeJnQtaPT > b6sVXWFS62ymwHdmJN_r_U&e= > > Thank you, > > RFC Editor/rv > > > > > On Aug 8, 2025, at 7:18 AM, Ron Bonica > > <rbonica=40juniper....@dmarc.ietf.org> wrote: > > > > Folks, > > > > I defer to Adrian on all points. He is a native speaker of English. I speak > > only American. > > > > Ron > > > > > > Juniper Business Use Only > > From: Adrian Farrel <adr...@olddog.co.uk> > > Sent: Friday, August 8, 2025 5:20 AM > > To: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>; Ron > > Bonica <rbon...@juniper.net>; x...@cernet.edu.cn > > <x...@cernet.edu.cn>; y.kam...@ntt.com <y.kam...@ntt.com>; > > luay.ja...@one.verizon.com <luay.ja...@one.verizon.com> > > Cc: 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 9837 > > <draft-ietf-6man-vpn-dest-opt-11> for your review [External Email. > > Be cautious of content] > > > > > > Hi there, > > > > Definitive responses should come from Ron, but in the interest of moving > > things along, here are my thoughts... > > > > > 1) <!-- [rfced] Should the note in Section 3 of this document be > > > in the <aside> element? The <aside> element 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!Ae-Fqk-UK1M6PbWK49f_lRu5SAO9yvxT4nagRabnlIaDeDRjmPOTjNARh5BhMsFcQr9cT66Je9rLsD3P0w$ > > > ). > > > > > > Original: > > > NOTE: For this experiment, the Option Type is set to '01011110', > > > i.e., 0x5E. The highest-order two bits are set to 01 indicating that > > > the required action by a destination node that does not recognize the > > > option is to discard the packet. The third highest-order bit is set > > > to 0 indicating that Option Data cannot be modified along the path > > > between the packet's source and its destination. The remaining low- > > > order bits are set to '11110' to indicate the single IPv6 Destination > > > Option Type code point available in the registry for experimentation. > > > --> > > > > No, I don't think this is an aside. It is a "Nota Bene" type of "NOTE", not > > to be glossed over by the reader. > > > > > 2) <!-- [rfced] FYI - We updated this sentence as follows to > > > clarify "in the registry". We also moved "for experimentation" to > > > earlier in the sentence. Let us know any concerns. > > > > > > Original: > > > The remaining low- > > > order bits are set to '11110' to indicate the single IPv6 Destination > > > Option Type code point available in the registry for experimentation. > > > > > > Perhaps: > > > The remaining low-order bits are set to '11110' to indicate the single > > > IPv6 Destination Option Type code point available for experimentation > > > in the "Destination Options and Hop-by-Hop Options" registry [V6MSG]. > > > --> > > > > The pedant in me (which will not die!) says that we don't do > > experimentation in the registry :-Z But, if you, as a native speaker, find > > this clearer, I don't object. > > > > > 3) <!-- [rfced] Would you like to update these list items to avoid > > > repetition of "Defined in"? Or do you prefer the current? > > > > > > Original: > > > The IPv6 header contains: > > > > > > * Version - Defined in [RFC8200]. MUST be equal to 6. > > > > [snip] > > > > > The IPv6 Destination Options Extension Header contains: > > > > > > * Next Header - Defined in [RFC8200]. MUST identify the protocol of > > > the customer data. > > > > [snip] > > > > > Perhaps (remove "Defined in"): > > > The IPv6 header contains: > > > > > > * Version [RFC8200]. MUST be equal to 6. > > > > [snip] > > > > > Or (include [RFC8200] in introductory text): > > > The IPv6 header contains the following (all defined in [RFC8200]): > > > > > > * Version - MUST be equal to 6. > > > > [snip] > > > > > The IPv6 Destination Options Extension Header contains the following > > > (both defined in [RFC8200]): > > > > > > * Next Header - MUST identify the protocol of > > > the customer data. > > > > [snip] > > > > I prefer this second formulation (with the two pieces of > > introductory text) > > > > > --> > > > > > 4) <!-- [rfced] Terminology > > > > > > a) We see the following forms in the document. Should these be > > > consistent? If so, please let us know which form is preferred. > > > > > > IPv6 VPN Service Option > > > VPN Service Option > > > > I see only one "IPv6 VPN Service option" [sic] which is in Section 7. > > Thus, please change that to "VPN Service Option". > > > > But there is also "IPv6 VPN Service Destination Option" > > > > The document title should remain as it is (qualifying the VPN Service > > Option to IPv6). > > The other cases (Sections 5 and 7) can all change to "VPN Service Option". > > > > > Destination Options header > > > IPv6 Destination Options Extension Header > > > > I only found one " IPv6 Destination Options Extension Header" (in Section > > 4). > > It serves as a sub-heading and contrasts with "IPv6 header" above the > > previous bullets, so I think it is good. > > On the other hand, please s/IPv6 header/IPv6 Header/ in that previous > > sub-header. > > > > > b) Please review "Destination Options" in this sentence. Is this > > > correct, or should this be updated to "Destination Options > > > headers" or "IPv6 Destination Options"? > > > > > > Original: > > > It MAY also contain any legal > > > combination of other Destination Options. > > > > Correct as written in the original. > > > > > c) We see the following forms in the document: > > > > > > IPv6 VPN Service Destination Option (5 instances, including in > > > document title) VPN Service Destination Option (1 instance) > > > > > > The abstract notes that "The experimental IPv6 Destination Option > > > is called the VPN Service Option." We see instances of "VPN > > > Service Option" and "IPv6 Destination Option" throughout the document. > > > > > > Should instances of "IPv6 VPN Service Destination Option" be > > > updated to "VPN Service Option"? Please review and let us know if > > > any updates are needed for clarity. > > > > > > Original: > > > IPv6 VPN Service Destination Option > > > > > > Perhaps: > > > VPN Service Option > > > > This overlaps with part of point a). > > I believe it is fully covered there, but please come back if it is unclear. > > > > > d) We have updated the abbreviated title (appears in the running > > > header at the top of each page in the pdf output) as follows. Let > > > us know if any further updates are needed per the question above. > > > > > > Original: > > > Svc. Dest. Opt. > > > > > > Updated: > > > Service Destination Option > > > > > > Perhaps: > > > VPN Service Option > > > > Would ideally be "VPN Service Destination Option", but if that is too long, > > "VPN Service Option". > > > > > --> > > > > > 5) <!-- [rfced] FYI - We have added expansions for the following > > > abbreviations per Section 3.6 of RFC 7322 ("RFC Style Guide"). > > > Please review each expansion in the document carefully to ensure > > > correctness. > > > > > > Segment Routing over IPv6 (SRv6) > > > Network Virtualization over Layer 3 (NVO3) Operations, > > > Administration, and Maintenance (OAM) > > > > All fine, but really is time to make these three "well known" :-) > > > > > --> > > > > > 6) <!-- [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!Ae-Fqk-UK1M6PbWK49f_lRu5SAO9yvxT4nagRabnlIaDeDRjmPOTjNARh5BhMsFcQr9cT66Je9rAh-eLIg$ > > > > 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. > > > > I looked again, and found nothing of concern. > > > > > --> > > > > > > Thank you. > > > > No! Thank you. > > > > Best, > > Adrian > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
