Hi Adrian, We marked your approval on the AUTH48 status page for this document (see https://www.rfc-editor.org/auth48/rfc9837).
Thank you! RFC Editor/rv > On Aug 8, 2025, at 1:39 PM, Adrian Farrel <[email protected]> wrote: > > I approve. > > Thanks for the work. > > Adrian > > -----Original Message----- > From: Rebecca VanRheenen <[email protected]> > Sent: 08 August 2025 19:28 > To: Ron Bonica <[email protected]>; [email protected]; > [email protected]; [email protected]; [email protected] > Cc: RFC Editor <[email protected]>; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected] > Subject: Re: AUTH48: RFC-to-be 9837 <draft-ietf-6man-vpn-dest-opt-11> for > your review > > 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://www.rfc-editor.org/authors/rfc9837.xml > > Updated output files: > https://www.rfc-editor.org/authors/rfc9837.txt > https://www.rfc-editor.org/authors/rfc9837.pdf > https://www.rfc-editor.org/authors/rfc9837.html > > Diff file showing all changes made during AUTH48: > https://www.rfc-editor.org/authors/rfc9837-auth48diff.html > https://www.rfc-editor.org/authors/rfc9837-auth48rfcdiff.html (side by side) > > Diff files showing all changes: > https://www.rfc-editor.org/authors/rfc9837-diff.html > https://www.rfc-editor.org/authors/rfc9837-rfcdiff.html (side by side) > https://www.rfc-editor.org/authors/rfc9837-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/rfc9837 > > Thank you, > > RFC Editor/rv > > > >> On Aug 8, 2025, at 7:18 AM, Ron Bonica >> <[email protected]> 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 <[email protected]> >> Sent: Friday, August 8, 2025 5:20 AM >> To: [email protected] <[email protected]>; Ron Bonica >> <[email protected]>; [email protected] <[email protected]>; >> [email protected] <[email protected]>; [email protected] >> <[email protected]> >> Cc: [email protected] <[email protected]>; [email protected] >> <[email protected]>; [email protected] <[email protected]>; >> [email protected] <[email protected]>; [email protected] >> <[email protected]> >> 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 -- [email protected] To unsubscribe send an email to [email protected]
