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 <fclad.i...@gmail.com> 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 <mfergu...@staff.rfc-editor.org> > 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) <fc...@cisco.com> wrote: >>> >>> Dear RFC Editor, Megan, >>> >>> Please let us know if there’s anything else you need from the authors. >>> >>> Thanks, >>> Francois >>> >>> From: Francois Clad <fclad.i...@gmail.com> >>> Date: Tuesday, 24 June 2025 at 10:28 >>> To: Megan Ferguson <mfergu...@staff.rfc-editor.org> >>> Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, >>> chengweiqi...@chinamobile.com <chengweiqi...@chinamobile.com>, cf(mailer >>> list) <c...@cisco.com>, lizhen...@huawei.com <lizhen...@huawei.com>, >>> spring-...@ietf.org <spring-...@ietf.org>, spring-cha...@ietf.org >>> <spring-cha...@ietf.org>, Pablo Camarillo (pcamaril) <pcama...@cisco.com>, >>> gunter.van_de_ve...@nokia.com<gunter.van_de_ve...@nokia.com>, >>> auth48archive@rfc-editor.org<auth48archive@rfc-editor.org>, Francois Clad >>> (fclad) <fc...@cisco.com>, bruno.decra...@orange.com >>> <bruno.decra...@orange.com> >>> 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 <mfergu...@staff.rfc-editor.org> >>> 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, bruno.decra...@orange.com 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=40cisco....@dmarc.ietf.org> 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, "rfc-edi...@rfc-editor.org" >>> <rfc-edi...@rfc-editor.org> 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 >>> >>> * 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://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, >>> 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://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 -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
