Hi Megan, Thank you for integrating those last changes. The latest version looks all good to me.
I approve this document for publication. Many thanks again for all your work! Best regards, Francois On 27 Jun 2025 at 20:16:29, Megan Ferguson <[email protected]> wrote: > Hi Francois, > > We have adopted this version without further changes. Once we have your > approval, we can move forward in the publication process. > > Please review the files carefully as we do not make changes after > publication. > > The files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9800.txt > https://www.rfc-editor.org/authors/rfc9800.pdf > https://www.rfc-editor.org/authors/rfc9800.html > https://www.rfc-editor.org/authors/rfc9800.xml > > The relevant diff files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9800-diff.html (comprehensive diff) > https://www.rfc-editor.org/authors/rfc9800-auth48diff.html (AUTH48 > changes only) > https://www.rfc-editor.org/authors/rfc9800-lastdiff.html (last to current > version only) > https://www.rfc-editor.org/authors/rfc9800-lastrfcdiff.html (last to > current side by side) > > Please contact us with any further updates/questions/comments you may > have. > > The AUTH48 status page for this document is available here: > > https://www.rfc-editor.org/auth48/rfc9800 > > Thank you. > > RFC Editor/mf > > On Jun 27, 2025, at 2:34 AM, Francois Clad <[email protected]> wrote: > > > Hi Megan, > > > Thanks for integrating those changes! > > > I did another thorough review of the latest files and found a few minor > issues left (hopefully the last ones). Please find attached an updated XML > that fixes them. > > > Thanks, > > Francois > > > On 26 Jun 2025 at 16:24:48, Megan Ferguson <[email protected]> > wrote: > > > Hi Francois, > > > > > > We have updated to use the version you sent to fix the line length issue > and added the changes from “criteria” to “criterion”. > > > > > > Once you review and approve the document in its current state, we will > be ready to move it forward in the publication process (we have received > approvals from each of your coauthors). > > > > > > Please review the files carefully as we do not make changes after > publication. > > > > > > The files have been posted here (please refresh): > > > https://www.rfc-editor.org/authors/rfc9800.txt > > > https://www.rfc-editor.org/authors/rfc9800.pdf > > > https://www.rfc-editor.org/authors/rfc9800.html > > > https://www.rfc-editor.org/authors/rfc9800.xml > > > > > > The relevant diff files have been posted here (please refresh): > > > https://www.rfc-editor.org/authors/rfc9800-diff.html (comprehensive > diff) > > > https://www.rfc-editor.org/authors/rfc9800-auth48diff.html (AUTH48 > changes only) > > > https://www.rfc-editor.org/authors/rfc9800-lastdiff.html (last to > current version only) > > > https://www.rfc-editor.org/authors/rfc9800-lastrfcdiff.html (last to > current side by side) > > > > > > Please contact us with any further updates/questions/comments you may > have. > > > > > > The AUTH48 status page for this document is available here: > > > > > > https://www.rfc-editor.org/auth48/rfc9800 > > > > > > Thank you. > > > > > > RFC Editor/mf > > > > > >> On Jun 26, 2025, at 8:00 AM, Francois Clad (fclad) <[email protected]> > wrote: > > >> > > >> Dear RFC Editor, Megan, > > >> > > >> Please let us know if there’s anything else you need from the authors. > > >> > > >> Thanks, > > >> Francois > > >> > > >> From: Francois Clad <[email protected]> > > >> Date: Tuesday, 24 June 2025 at 10:28 > > >> To: Megan Ferguson <[email protected]> > > >> Cc: [email protected] <[email protected]>, > [email protected] <[email protected]>, cf(mailer > list) <[email protected]>, [email protected] <[email protected]>, > [email protected] <[email protected]>, [email protected] < > [email protected]>, Pablo Camarillo (pcamaril) <[email protected]>, > [email protected]<[email protected]>, > [email protected]<[email protected]>, Francois Clad > (fclad) <[email protected]>, [email protected] < > [email protected]> > > >> Subject: Re: AUTH48: RFC-to-be 9800 > <draft-ietf-spring-srv6-srh-compression-23> for your review > > >> > > >> Dear RFC Editor, Megan, > > >> > > >> Thank you for updating the document and keywords. > > >> > > >> Please find replies to your follow-up comments/questions inline below > ([FC]) and an updated XML attached. The only change in this attached XML > should be the line wrapping in code blocks. > > >> > > >> Thanks, > > >> Francois > > >> > > >> On 23 Jun 2025 at 21:38:38, Megan Ferguson < > [email protected]> wrote: > > >> Authors, > > >> > > >> Thank you for your replies and guidance. We have updated accordingly > and added the keywords suggested to our database. We have also recorded > the approvals we have received thus far at the AUTH48 status page for this > document (see below). > > >> > > >> We had the following questions/comments related to your replies to our > original set of queries: > > >> > > >> Q3: We have updated to your suggested sentence in Sections 4.1.2, > 4.1.3, 4.1.4, 4.1.6. Please review if “this criteria” should be “this > criterion” or “these criteria”. > > >> > > >> [FC] Should be singular (“this criterion”), sorry. > > >> > > >> > > >> > > >> Q5a: We will await your confirmation of this change (per your note: > "let me double check this particular point with my co-authors and get back > to you.”). > > >> > > >> [FC] I’ve checked and it’s all good. We can keep this change. > > >> > > >> > > >> > > >> Q5b: FYI: we have updated to use spaces around the equals sign when in > the body of the text but have not touched instances in the pseudocode. > Please review and confirm this is as intended. > > >> > > >> [FC] Looks good. Thanks! > > >> > > >> > > >> > > >> 10a: Regarding “upper-layer header”: please review the instances of > "(SR Upper-layer Header Error)” and let us know if/how to update these as > we were unsure if this change should apply there. > > >> > > >> [FC] Indeed, these should be left as "SR Upper-layer Header Error”. The > term is defined in Section 8 of RFC 8754 ( > https://www.rfc-editor.org/rfc/rfc8754.html#section-8) (and in the > corresponding IANA registry). > > >> > > >> > > >> > > >> 15: We are getting line-length errors as follows: > > >> > > >> (1130): Warning: Too long line found (L1199), 1 characters longer than > 72 characters: > > >> S01. Initialize a NEXT-CSID container equal to the first SID in the > > >> (1130): Warning: Too long line found (L1204), 3 characters longer than > 72 characters: > > >> container and the current SID LNFL is lower than or equal > to > > >> (1130): Warning: Too long line found (L1206), 1 characters longer than > 72 characters: > > >> S04. Copy the current SID Locator-Node and Function to the most > > >> (1130): Warning: Too long line found (L1217), 2 characters longer than > 72 characters: > > >> (following the series of compressible NEXT-CSID flavor > SIDs){ > > >> (1130): Warning: Too long line found (L1219), 3 characters longer than > 72 characters: > > >> S12. If S is advertised with a SID structure, and the > Locator-Block > > >> (1130): Warning: Too long line found (L1220), 3 characters longer than > 72 characters: > > >> of S matches that of the NEXT-CSID container, and the sum > of > > >> (1174): Warning: Too long line found (L1240), 2 characters longer than > 72 characters: > > >> S01. Initialize a REPLACE-CSID container in full SID format equal > to > > >> (1174): Warning: Too long line found (L1252), 3 characters longer than > 72 characters: > > >> significant remaining bits of the REPLACE-CSID > container > > >> (1174): Warning: Too long line found (L1257), 1 characters longer than > 72 characters: > > >> S11. Initialize a new REPLACE-CSID container in packed format > > >> (1174): Warning: Too long line found (L1260), 3 characters longer than > 72 characters: > > >> significant remaining bits of the REPLACE-CSID > container > > >> > > >> Note: Please feel free to update the line lengths in the edited XML > file if this is easier than describing to us via email. > > >> > > >> [FC] Oh, I see. These two code blocks are indented under an <li> > element and that reduces the character limit to 66 instead of 69. I’ve > rewrapped those lines in the attached XML. Let me know if that fixes the > issue. > > >> > > >> > > >> > > >> Please review the files carefully as we do not make changes after > publication. > > >> > > >> The files have been posted here (please refresh): > > >> https://www.rfc-editor.org/authors/rfc9800.txt > > >> https://www.rfc-editor.org/authors/rfc9800.pdf > > >> https://www.rfc-editor.org/authors/rfc9800.html > > >> https://www.rfc-editor.org/authors/rfc9800.xml > > >> > > >> The relevant diff files have been posted here (please refresh): > > >> https://www.rfc-editor.org/authors/rfc9800-diff.html (comprehensive > diff) > > >> https://www.rfc-editor.org/authors/rfc9800-auth48diff.html (AUTH48 > changes only) > > >> https://www.rfc-editor.org/authors/rfc9800-lastdiff.html (last to > current version only) > > >> > > >> Please contact us with any further updates/questions/comments you may > have. > > >> > > >> We will await approvals from each of the parties listed on the AUTH48 > status page prior to moving forward to publication. > > >> > > >> The AUTH48 status page for this document is available here: > > >> > > >> https://www.rfc-editor.org/auth48/rfc9800 > > >> > > >> Thank you. > > >> > > >> RFC Editor/mf > > >> > > >> > > >> > > >> On Jun 23, 2025, at 9:07 AM, [email protected] wrote: > > >> > > >> Hi RFC Editor/mf, François, > > >> > > >> Please find below a possible proposed change. > > >> Please check it as I’m not a native speaker. > > >> > > >> §3 > > >> OLD: > > >> Building upon, and fully compatible with, the mechanisms specified in > [RFC8754] and [RFC8986], the compressed segment list encoding leverages a > SID list compression logic at the SR source node (see Section 6) in > combination with new flavors of the SRv6 endpoint behaviors that process > the compressed SID list (see Section 4). > > >> > > >> NEW: > > >> Building upon, and fully compatible with the mechanisms specified in > [RFC8754] and [RFC8986], the compressed segment list encoding leverages a > SID list compression logic at the SR source node (see Section 6) in > combination with new flavors of the SRv6 endpoint behaviors that process > the compressed SID list (see Section 4). > > >> > > >> > > >> (The only change is :s/with, the/with the ) > > >> > > >> > > >> > > >> > > >> Regardless, > > >> I approve this RFC for publication. > > >> > > >> Thanks, > > >> Regards, > > >> --Bruno > > >> > > >> > > >> > > >> On Jun 23, 2025, at 8:30 AM, Francois Clad (fclad) <fclad= > [email protected]> wrote: > > >> > > >> Dear RFC Editor, > > >> > > >> Many thanks for your work on this document. > > >> > > >> Please find replies to your comments and questions inline below ([FC]) > and an updated XML attached. > > >> > > >> I also did a thorough review of all the changes and made a few minor > adjustments as listed below. > > >> > > >> • Add keyworks (Segment Routing, IPv6 Segment Routing, Compressed SID, > CSID, NEXT-CSID, REPLACE-SID, SRH Compression) > > >> • Add missing <tt> tags around Arg.FE2 in Sec 6.2. > > >> • Revert reference for End.X SID in Sec 7.1 to point to Section 4.2 of > RFC 8986 (more details below) > > >> • Minor rephrase of a modified sentence on “combined advertisement” > near the end of Sec 8 > > >> • Change reference labels “BGP-LS-SR” to “BGP-LS-SR-Policy” and > “SR-BGP” to “BGP-SR-Policy” > > >> > > >> Thanks, > > >> Francois > > >> > > >> On 21/06/2025, 03:46, "[email protected]" < > [email protected]> wrote: > > >> > > >> uthors, > > >> > > >> While reviewing this document during AUTH48, please resolve (as > necessary) the following questions, which are also in the XML file. > > >> > > >> 1) <!-- [rfced] Because this document updates RFC 8754, please > > >> review the errata reported for RFC 8754 > > >> (https://www.rfc-editor.org/errata_search.php?rfc=8754) > > >> and let us know if you feel any of them > > >> are relevant to the content of this document. > > >> --> > > >> > > >> [FC] Both errata (7081 and 7102) are relevant, but they don’t impact > the text of this document. > > >> > > >> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in > > >> the title) for use on https://www.rfc-editor.org/search. --> > > >> > > >> [FC] Added the following keywords in the XML file: Segment Routing, > IPv6 Segment Routing, Compressed SID, CSID, NEXT-CSID, REPLACE-SID, SRH > Compression > > >> > > >> 3) <!--[rfced] This list is a bit difficult to follow. How may we > update > > >> for parallel structure (and the ease of the reader)? > > >> Specifically, please clarify the "whichever comes first" (we have > > >> omitted that from our suggested text). Note that a similar > > >> sentence occurs near the end of Section 4.1.2, 4.1.3, 4.1.4, > 4.1.6, as well. > > >> > > >> Original: > > >> In addition, this pseudocode is executed before processing any > > >> extension header that is not an SRH, a Hop-by-Hop header or a > > >> Destination Options header, or before processing the upper-layer > > >> header, whichever comes first. > > >> > > >> Perhaps: > > >> In addition, this pseudocode is executed before processing: > > >> > > >> * any extension header that is not an SRH, > > >> * a Hop-by-Hop header or a Destination Options header, or > > >> * the upper-layer header. > > >> --> > > >> > > >> [FC] Would the text below be clearer? > > >> > > >> OLD: > > >> In addition, this pseudocode is executed before processing any > > >> extension header that is not an SRH, a Hop-by-Hop header or a > > >> Destination Options header, or before processing the upper-layer > > >> header, whichever comes first. > > >> > > >> NEW: > > >> In addition, this pseudocode is executed before processing the first > > >> header in the IPv6 extension header chain that is not an SRH, a Hop- > > >> by-Hop header, or a Destination Options header. If the IPv6 > > >> extension header chain does not include any header matching this > > >> criteria, this pseudocode is executed before processing the upper- > > >> layer header. > > >> > > >> 4) <!--[rfced] Should this instance of "USP" be "USD"? We do not see > USP > > >> in Section 4.16.3 of RFC 8986. > > >> > > >> Original: > > >> USD: The USP flavor defined in Section 4.16.3 of [RFC8986] is > > >> unchanged when combined with the NEXT-CSID flavor. > > >> > > >> Perhaps: > > >> USD: The USD flavor defined in Section 4.16.3 of [RFC8986] is > > >> unchanged when combined with the NEXT-CSID flavor. > > >> > > >> --> > > >> > > >> [FC] Yes, that’s a typo. Thanks for catching it! > > >> > > >> 5) <!--[rfced] We had two questions related to this text: > > >> > > >> a) Please review our edit to use "all zeros" instead of "all 0" in > > >> cases like the following and confirm this is not a meaning change. > > >> > > >> Original: > > >> > > >> When receiving a SID advertisement for a REPLACE-CSID flavor SID with > > >> LNL=16, FL=0, AL=128-LBL-LNFL, and the value of the Argument is all > > >> 0,... > > >> > > >> Current: > > >> When receiving a SID advertisement for a REPLACE-CSID flavor SID with > > >> LNL=16, FL=0, AL=128-LBL-LNFL, and all zeros as the value of the > Argument,... > > >> > > >> [FC] The change looks good to me, but let me double check this > particular point with my co-authors and get back to you. > > >> > > >> b) May we update to add spacing around the equals sign to match > > >> previous uses (for all similar cases as well)? > > >> --> > > >> > > >> [FC] Yes, please add spacing around the equal signs. > > >> > > >> 6) <!--[rfced] Can you clarify what "that address" (used twice) and > "this > > >> address" are referring to in Section 6? > > >> > > >> Original: > > >> The Destination Address used in the IPv6 pseudo-header (Section 8.1 > > >> of [RFC8200]) is that of the ultimate destination. > > >> > > >> At the SR source node, that address will be the Destination Address > > >> as it is expected to be received by the ultimate destination. When > > >> the last element in the compressed SID list is a CSID container, > > >> this address can be obtained from the last element in the > > >> uncompressed SID list or by repeatedly applying the segment > > >> behavior as described in Section 9.4. This applies regardless of > > >> whether an SRH is present in the IPv6 packet or omitted. > > >> > > >> At the ultimate destination(s), that address will be in the > > >> Destination Address field of the IPv6 header. > > >> > > >> > > >> --> > > >> > > >> [FC] Both occurrences of “that address” and the one occurrence of “this > address” all refer to “The Destination Address used in the IPv6 > pseudo-header”. Note that the phrasing in this section is mapped from the > first bullet in Section 8.1 of RFC 8200 ( > https://datatracker.ietf.org/doc/html/rfc8200#section-8.1), only updating > the terminology to align with the rest of the document and adding some > clarification. > > >> > > >> > > >> 7) <!-- [rfced] The following may require clarification: > > >> > > >> Current: > > >> | Other examples of local SID properties include the set of L3 > > >> | adjacencies of an End.X SID (Section 4.1 of [RFC8986]) and the > > >> | lookup table of an End.DT6 SID (Section 4.6 of [RFC8986]). > > >> > > >> We note that Section 4.1 of [RFC8986] is titled "End: Endpoint" while > > >> Section 4.2 of [RFC8986] is titled "End.X: L3 Cross-Connect". Section > > >> 4.2 may be the more appropriate section to reference in this case. > > >> Please advise. > > >> > > >> --> > > >> > > >> [FC] Yes, this should read “the set of L3 adjacencies of an End.X SID > (Section 4.2 of [RFC8986])”. > > >> Note that the text was correctly pointing to Section 4.2 in revision > -23… not sure how it got changed to 4.1. > > >> > > >> > > >> 8) <!--[rfced] Would it be helpful to the reader to clarify what part of > > >> the specification the node does not support (rather than the > > >> document itself)? > > >> > > >> Original: > > >> When a node that does not support this specification receives an > > >> advertisement of a SID of this document, it handles it as described > > >> in the corresponding control plane specification (e.g., Sections 7.2, > > >> 8.1, and 8.2 of [RFC9352], Sections 8, 9.1, and 9.2 of [RFC9513], and > > >> Section 3.1 of [RFC9252]). > > >> --> > > >> > > >> [FC] This could be rephrased as follows: > > >> > > >> OLD: > > >> When a node that does not support this specification receives an > > >> advertisement of a SID of this document, it handles it as described […]. > > >> > > >> NEW: > > >> When a node receives an advertisement of a SID of this document > > >> that it does not support, it handles the advertisement as described […]. > > >> > > >> 9) <!--[rfced] Please review our update to this text to try to make it > > >> more parallel to the paragraph that follows. > > >> > > >> Original: > > >> This document introduces two new flavors for some of the SRv6 endpoint > > >> behaviors defined in [RFC8986] and a method by which an SR source node > > >> may leverage the SIDs of these flavors to produce a compressed segment > > >> list encoding. > > >> > > >> > > >> Current: > > >> This document introduces two new flavors, NEXT-CSID and REPLACE-CSID, > for some o > > >> f the SRv6 endpoint behaviors defined in RFC 8986 and a method by which > an SR so > > >> urce node may leverage the SIDs of these flavors to produce a > compressed segment > > >> list encoding. > > >> > > >> --> > > >> > > >> [FC] This change looks good. Thanks! > > >> > > >> > > >> 10) <!--[rfced] We had the following questions related to terminology > used > > >> throughout the document: > > >> > > >> a) We see the following similar terms; should these be made uniform > > >> throughout? If so, please let us know which form is preferred. > > >> > > >> segment list vs. Segment List > > >> > > >> [FC] No, please leave the current capitalization as is. The lowercase > term “segment list” is plain English for a list of segments, while the > capitalized term “Segment List” refers to the field of the SRH (see Section > 2 of RFC 8754). Note that the capitalized version is always used as part of > “Segment List entry”, “SRH Segment List”, or followed by brackets in the > pseudocode. > > >> > > >> destination address vs. Destination Address > > >> > > >> [FC] Yes, please capitalize all occurrences of “Destination Address”. > > >> > > >> Hop limit vs. Hop Limit > > >> > > >> [FC] No, please leave the current capitalization as is. The fully > capitalized form “Hop Limit” refers the field of the IPv6 header (see > Section 3 of RFC 8200 > https://datatracker.ietf.org/doc/html/rfc8200#section-3), while the > partially capitalized form refers to the ICMPv6 error message “Hop limit > exceeded in transit” (see Section 3.3 of RFC 4443 > https://www.rfc-editor.org/rfc/rfc4443.html#section-3.3). > > >> > > >> pseudocode vs. pseudo code > > >> > > >> [FC] Yes, please make the terms “pseudocode” and “pseudo code” uniform, > using whichever form is most correct in English language. > > >> > > >> upper-layer header vs. Upper-layer Header vs. Upper-Layer header > > >> > > >> [FC] Yes, please use the lowercase form “upper-layer header” for all > occurrences. > > >> > > >> For the following, we have updated to use the form on the right. > > >> Please let us know any objections. > > >> > > >> dataplane / data plane > > >> > > >> [FC] No objection. This looks good, thanks! > > >> > > >> > > >> b) Is there another way to say "a ...SID of this document"? Later we > > >> see "the SIDs introduced in this document". Might that work here and > > >> for other occurrences (there are several) or can these be updated to > > >> NEXT-CSID and REPLACE-CSID (or is this not referring to the flavors)? > > >> Or is there another way to rephrase that you would prefer? > > >> > > >> Original: > > >> The SR segment endpoint node MUST set the SID Argument bits to 0 when > > >> advertising a locally instantiated SID of this document in the > > >> routing protocol (e.g., IS-IS [RFC9352], OSPF [RFC9513], or BGP-LS > > >> [RFC9514]). > > >> > > >> --> > > >> > > >> [FC] The term “a SID of this document” is defined in Section 4 ( > https://www.rfc-editor.org/authors/rfc9800.html#section-4-7). Is this > definition not clear or the term incorrect? > > >> > > >> > > >> 11) <!--[rfced] We had the following questions related to abbreviation > use > > >> throughout the document: > > >> > > >> a) As relates to CSID: > > >> > > >> i) CSID is expanded as both "Compressed SRv6 Segment List Encoding > > >> (CSID)" (in the title) and "Compressed-SID (CSID)" (in the document > > >> itself). Please review and let us know how we may make these > > >> expansions uniform. > > >> > > >> [FC] “Compressed-SID (CSID)” as it appears in the terminology section > is the correct expansion. The occurrence of “(CSID)” in the title is meant > to make it easier to search for and identify this document, but perhaps > such need would be better addressed with a “<keyword>CSID</keyword>” tag. > > >> > > >> ii) We suggest using CSID after first use to eliminate inconsistency > between the > > >> following and to follow the guidance at > https://www.rfc-editor.org/styleguide/part2/#exp_abbrev: > > >> > > >> Compressed SID vs. Compressed-SID vs. compressed SID > > >> > > >> [FC] We need to differentiate two terms: “Compressed-SID”, which should > be consistently abbreviated as “CSID” throughout the document, and > “compressed SID list”, which should remain lowercase (except where sentence > case or title case applies), non-hyphened, and non-abbreviated. I reviewed > all occurrences of this term in > https://www.rfc-editor.org/authors/rfc9800.html and they look correct. > > >> > > >> b) The following abbreviations were expanded in multiple places. To > > >> match the guidance at > > >> https://www.rfc-editor.org/styleguide/part2/#exp_abbrev, we will > > >> update to expand them on first use only and to use the abbreviation > > >> without expansion thereafter unless we hear objection. > > >> > > >> LBL > > >> AL > > >> GIB > > >> LIB > > >> > > >> [FC] Yes, sounds good. > > >> > > >> c) We note that most abbreviations that include "length" use the > > >> lowercased form. However, we see many instances of "Payload Length" > > >> throughout the document. Please review and let us know if any updates > > >> are necessary. > > >> > > >> --> > > >> > > >> [FC] “Payload Length” refers to the field of the IPv6 header (see > Section 3 of RFC 8200) and should remain capitalized. Other occurrences of > “length” should be lowercase. > > >> > > >> > > >> 12) <!-- [rfced] FYI - We updated artwork to sourcecode in Sections > 4.1.1, > > >> 4.1.2, 4.1.3, 4.1.4, 4.1.6, 4.2.1, 4.2.2, 4.2.3, 4.2.4, 4.2.6, > > >> 4.2.8, 6.2, 7.1.1, 7.1.2, 7.2.1, and 7.2.2 and Appendices A.1 - > > >> A.10. Please confirm that this is correct. > > >> > > >> In addition, please consider whether the "type" attribute of any > > >> sourcecode element should be set and/or has been set correctly. > > >> > > >> The current list of preferred values for "type" is available at > > >> <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>. > > >> If the current list does not contain an applicable type, feel free to > > >> suggest additions for consideration. Note that it is also acceptable > > >> to leave the "type" attribute not set. > > >> --> > > >> > > >> [FC] Yes that is correct, as well as the “pseudocode” value for the > “type” attribute. > > >> > > >> > > >> 13) <!--[rfced] The RFC Production Center is unable to edit SVG images. > > >> Please review your SVG output in the HTML *and* PDF to ensure > > >> both figures appear as expected (i.e., they are the same, and the > > >> formatting is as expected). > > >> > > >> IMPORTANT NOTE: In addition, where <artset> is used, please ensure > > >> that the SVG matches the artwork included the text file, as we have > > >> made edits there (but have not matched them with edits to the svg > > >> itself). > > >> > > >> Please feel free to insert updated SVG into the edited XML file > > >> directly. --> > > >> > > >> [FC] I have reviewed the SVG in both the HTML and PDF outputs, and > compared with the ASCII-arts. They all look good. Thanks! > > >> > > >> 14) <!--[rfced] Regarding some specialized formatting in the text: > > >> > > >> We have included a list of the terms enclosed in <tt> tags in this > > >> document (with duplicates removed). > > >> > > >> Please review to ensure the usage of <tt> is correct and consistent > > >> and let us know if each output (html and text) is acceptable or if any > > >> updates are needed. > > >> > > >> <tt>0x0010</tt> > > >> <tt>0x20010db800b1</tt> > > >> <tt>0xf123</tt> > > >> <tt>123</tt> > > >> <tt>[(128-ceiling(log_2(128/LNFL)))..127]</tt> > > >> <tt>2001:db8:b1:10::/64</tt> > > >> <tt>2001:db8:b1:10:f123::/80</tt> > > >> <tt>2001:db8:b1:10::</tt> > > >> <tt>2001:db8:b1:f123::/64</tt> > > >> <tt>2001:db8:b1:f123::</tt> > > >> <tt>2001:db8:b2:20:123::/80</tt> > > >> <tt>2001:db8:b2:20:123::</tt> > > >> <tt>2001:db8:b2:20:1::/80</tt> > > >> <tt>2001:db8:b2:20:1::</tt> > > >> <tt>Arg.FE2</tt> > > >> <tt>[(DA.Arg.Index-1)*LNFL..DA.Arg.Index*LNFL-1]</tt> > > >> <tt>[DA.Arg.Index*LNFL..(DA.Arg.Index+1)*LNFL-1]</tt> > > >> <tt>DA.Arg.Index</tt> > > >> <tt>DA.Argument</tt> > > >> <tt>[(LBL+LNFL)..127]</tt> > > >> <tt>Segment List[Segments Left][DA.Arg.Index-1]</tt> > > >> <tt>Segment List[Segments Left][DA.Arg.Index]</tt> > > >> > > >> > > >> --> > > >> > > >> [FC] Looks all good except two occurrences of “Arg.FE2” in Section 6.2 > that are not enclosed in <tt> tags (see attached XML). > > >> > > >> > > >> 15) <!--[rfced] We note that some of the text in this document exceeds > our > > >> line limits (72 characters for body of the text, 69 for code). > > >> Please review (and feel free to update in the edited XML file) so > > >> that these lines will fit within these restrictions. --> > > >> > > >> [FC] I’ve reviewed the pseudocode blocks, figures, and table, and they > all seem to fit within the 69 characters limit. Can you point me to one > line that exceeds the limit to help me figure it out? > > >> > > >> > > >> Thank you. > > >> > > >> RFC Editor/mf > > >> > > >> *****IMPORTANT***** > > >> > > >> Updated 2025/06/20 > > >> > > >> 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://www.rfc-editor.org/faq/). > > >> > > >> 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://trustee.ietf.org/license-info). > > >> > > >> * 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://authors.ietf.org/rfcxml-vocabulary>. > > >> > > >> * 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 > > >> > > >> * [email protected] (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). > > >> > > >> * [email protected], which is a new archival mailing > list > > >> to preserve AUTH48 conversations; it is not an active discussion > > >> list: > > >> > > >> * More info: > > >> > https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > > >> > > >> * The archive itself: > > >> https://mailarchive.ietf.org/arch/browse/auth48archive/ > > >> > > >> * 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, > > >> [email protected] 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://www.rfc-editor.org/authors/rfc9800.xml > > >> https://www.rfc-editor.org/authors/rfc9800.html > > >> https://www.rfc-editor.org/authors/rfc9800.pdf > > >> https://www.rfc-editor.org/authors/rfc9800.txt > > >> > > >> Diff file of the text: > > >> https://www.rfc-editor.org/authors/rfc9800-diff.html > > >> https://www.rfc-editor.org/authors/rfc9800-rfcdiff.html (side by > side) > > >> > > >> Diff of the XML: > > >> https://www.rfc-editor.org/authors/rfc9800-xmldiff1.html > > >> > > >> > > >> Tracking progress > > >> ----------------- > > >> > > >> The details of the AUTH48 status of your document are here: > > >> https://www.rfc-editor.org/auth48/rfc9800 > > >> > > >> Please let us know if you have any questions. > > >> > > >> Thank you for your cooperation, > > >> > > >> RFC Editor > > >> > > >> -------------------------------------- > > >> RFC9800 (draft-ietf-spring-srv6-srh-compression-23) > > >> > > >> Title : Compressed SRv6 Segment List Encoding (CSID) > > >> Author(s) : W. Cheng, C. Filsfils, Z. Li, B. Decraene, F. Clad > > >> WG Chair(s) : Bruno Decraene, Alvaro Retana, Joel M. Halpern > > >> > > >> Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde > > >> > > >> > > >> > > >> <rfc9800.xml> > > > > > <rfc9800.xml> > > >
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
