Hi Ron, Thanks for the quick reply. We have marked your approval on the AUTH48 status page for this document (see https://www.rfc-editor.org/auth48/rfc9837).
Best regards, RFC Editor/rv > On Aug 8, 2025, at 12:27 PM, Ron Bonica <[email protected]> wrote: > > I approve this text. > > > Juniper Business Use Only > From: Rebecca VanRheenen <[email protected]> > Sent: Friday, August 8, 2025 2:27 PM > To: Ron Bonica <[email protected]>; [email protected] > <[email protected]>; [email protected]<[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] <[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 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.com/v3/__https://www.rfc-editor.org/authors/rfc9837.xml__;!!NEt6yMaO-gk!DHqqjTOr248380mzN_8YWTkTXNWAQZtP1hmT3Euk24aguDSIPruP90S100Jux8SsjyVI4xEb1aQS_M8hGKb2hJm16JVmETo$ > > Updated output files: > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9837.txt__;!!NEt6yMaO-gk!DHqqjTOr248380mzN_8YWTkTXNWAQZtP1hmT3Euk24aguDSIPruP90S100Jux8SsjyVI4xEb1aQS_M8hGKb2hJm1FGaqxgI$ > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9837.pdf__;!!NEt6yMaO-gk!DHqqjTOr248380mzN_8YWTkTXNWAQZtP1hmT3Euk24aguDSIPruP90S100Jux8SsjyVI4xEb1aQS_M8hGKb2hJm1n7ue9MQ$ > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9837.html__;!!NEt6yMaO-gk!DHqqjTOr248380mzN_8YWTkTXNWAQZtP1hmT3Euk24aguDSIPruP90S100Jux8SsjyVI4xEb1aQS_M8hGKb2hJm1T6g-YCw$ > > Diff file showing all changes made during AUTH48: > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9837-auth48diff.html__;!!NEt6yMaO-gk!DHqqjTOr248380mzN_8YWTkTXNWAQZtP1hmT3Euk24aguDSIPruP90S100Jux8SsjyVI4xEb1aQS_M8hGKb2hJm1mlPB-bw$ > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9837-auth48rfcdiff.html__;!!NEt6yMaO-gk!DHqqjTOr248380mzN_8YWTkTXNWAQZtP1hmT3Euk24aguDSIPruP90S100Jux8SsjyVI4xEb1aQS_M8hGKb2hJm17Jd6HdI$ > (side by side) > > Diff files showing all changes: > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9837-diff.html__;!!NEt6yMaO-gk!DHqqjTOr248380mzN_8YWTkTXNWAQZtP1hmT3Euk24aguDSIPruP90S100Jux8SsjyVI4xEb1aQS_M8hGKb2hJm1GaCWAm0$ > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9837-rfcdiff.html__;!!NEt6yMaO-gk!DHqqjTOr248380mzN_8YWTkTXNWAQZtP1hmT3Euk24aguDSIPruP90S100Jux8SsjyVI4xEb1aQS_M8hGKb2hJm1oWgIjNM$ > (side by side) > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9837-alt-diff.html__;!!NEt6yMaO-gk!DHqqjTOr248380mzN_8YWTkTXNWAQZtP1hmT3Euk24aguDSIPruP90S100Jux8SsjyVI4xEb1aQS_M8hGKb2hJm1KbuVeaY$ > (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/rfc9837__;!!NEt6yMaO-gk!DHqqjTOr248380mzN_8YWTkTXNWAQZtP1hmT3Euk24aguDSIPruP90S100Jux8SsjyVI4xEb1aQS_M8hGKb2hJm14UOtx-g$ > > 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]
