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. --> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 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. --> 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. --> 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,... b) May we update to add spacing around the equals sign to match previous uses (for all similar cases as well)? --> 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. --> 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. --> 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]). --> 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. --> 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 destination address vs. Destination Address Hop limit vs. Hop Limit pseudocode vs. pseudo code upper-layer header vs. Upper-layer Header vs. Upper-Layer header For the following, we have updated to use the form on the right. Please let us know any objections. dataplane / data plane 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]). --> 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. 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 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 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. --> 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. --> 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. --> 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> --> 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. --> 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 -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
