Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
1) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 2) <!--[rfced] Should "itself" be "themselves"? If neither of the following capture your intended meaning, please rephrase. Original: Alternatively, a BGP egress router may advertise SR Policies that represent paths terminating on itself. Perhaps A: Alternatively, a BGP egress router may advertise SR Policies that represent paths terminating on themselves. Perhaps B: Alternatively, a BGP egress router may advertise SR Policies that represent paths that terminate on it. --> 3) <!--[rfced] The following sentence is long and difficult to parse. In particular, what is being made unique? How may we rephrase? Original: The distinguisher has no semantic value and is solely used by the SR Policy originator to make unique (from an NLRI perspective) both for multiple candidate paths of the same SR Policy as well as candidate paths of different SR Policies (i.e. with different segment lists) with the same Color and Endpoint but meant for different headends. --> 4) <!-- [rfced] We note that [RFC4456] uses the term "ORIGINATOR_ID" rather than "Originator ID". Please review and let us know if any updates are necessary. --> 5) <!--[rfced] Please review the following for how "4 octets" connects to the rest of the sentence (perhaps text is missing as we generally see "octets of foo" in previous descriptions)? Original: Weight: 4 octets an unsigned integer value indicating the weight associated with a segment list... --> 6) <!--[rfced] Please clarify "it" in the following text: Original: If one or more route targets are present and none matches the local BGP Identifier, then, while the SR Policy NLRI is valid, it is not usable on the receiver node. Perhaps: If one or more route targets are present, and none matches the local BGP Identifier, then, while the SR Policy NLRI is valid, the route targets are not usable on the receiver node. --> 7) <!--[rfced] We note that the IANA Considerations section (Section 6) starts with a summary of all of the actions that follow in the subsections. We had a few questions/comments related to this section: a) Note that we have consolidated mentions of the registry group names in the introductory text for each type of action in order to reduce redundancy. Please review these changes and let us know any objections. b) To further reduce redundancy, might it be agreeable to delete the registry group names from the subsections that follow? They were used inconsistently in the original, and the reader would be able to find that information in Section 6 itself if desired. c) Would you like to add section pointers to the corresponding subsections where the actions are further described? d) Please note that any changes to text that appears in any IANA registries mentioned in this document will be communicated to IANA by the RPC prior to publication but after the completion of AUTH48. --> 8) <!--[rfced] We had a few questions regarding Section 6.1 and the BGP SAFI Code Point: a) We received the following note from IANA. We do not see mention of this update in the IANA Considerations section of this document. Should anything be added? IANA's Note: NOTE: We've also updated the associated iana-routing-types YANG module to reflect the new description and enum variable. Please see https://www.iana.org/assignments/iana-routing-types b) We don't see any mention of "BGP" in the corresponding IANA registry. Should the title of Table 1 be updated? Currently in the document: Table 1: BGP SAFI Code Point At https://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml: SR Policy SAFI c) The title of this section is "Subsequent Address Family Identifiers (SAFI) Parameters". This is the title of registry group. Subsequent subsections in the document are titled using the subregistry. Should the title of Section 6.1 be updated to "SAFI Values"? --> 9) <!--[rfced] We had the following questions/comments regarding Section 6.3: a) We note that the corresponding IANA registry (https://www.iana.org/assignments/bgp-tunnel-encapsulation/bgp-tunnel-encapsulation.xhtml#tunnel-sub-tlvs) also has a "Change Controller" column in which some of the code points listed by this document contain information (i.e., IETF). Should any mention of this be made in Table 3? b) Please review our update to the title of Table 3 and let us know any objections. Original: Table 3: BGP Tunnel Encapsulation Attribute Code Points Current: Table 3: BGP Tunnel Encapsulation Attribute Sub-TLV Code Points --> 10) <!--[rfced] We had the following questions/comments related to Table 5: a) Please review our update to the title to include "Sub-TLV". Original: Table 5: SR Policy Segment List Code Points Current: Table 5: SR Policy Segment List Sub-TLV Code Points b) We note that Table 5 includes "Segment Type A sub-TLV". Elsewhere in the document, we see "Type A Segment Sub-TLV" (note the word order change). Further, we see Type-1 (using a hyphen while lettered types do not). Please review all of these differences and let us know if/how these should be made consistent. c) In the document, we see points 3-8 as "Unassigned". At https://www.iana.org/assignments/bgp-tunnel-encapsulation/bgp-tunnel-encapsulation.xhtml#color-extended-community-flags, we see Segment Type C - Type H sub-TLVs. The same is true for points 14-16 (this document includes them in the 14-255 "Unassigned"). Please review and let us know what, if any, updates are necessary. --> 11) <!--[rfced] We had the following questions/comments regarding Section 6.8 and the corresponding IANA registry at https://www.iana.org/assignments/bgp-tunnel-encapsulation/bgp-tunnel-encapsul ation.xhtml#sr-policy-segment-flags: a) This document lists Bits 1-2 as "Unassigned" while the IANA registry lists entries for these values (the A-Flag and S-Flag). Please review and let us know what, if any, updates need to be made for consistency. --> 12) <!--[rfced] We had the following questions/comments related to Section 6.10 and its corresponding registry at: https://www.iana.org/assignments/segment-routing/segment-routing.xhtml#sr-policy-enlp-values: a) There is a slight difference in the Description of Code Point 0. Please let us know if/how these may be made consistent. This document: Reserved (not to be used) IANA registry: Reserved --> 13) <!--[rfced] In the following, how may we update to correct the connection between "address families" and "SAFI"? If our suggested text does not correctly capture your intent, please let us know how to rephrase. Original: BGP peering sessions for address-families other than SR Policy SAFI may be set up to routers outside the SR domain. Perhaps: BGP peering sessions for address families other than those that use the SR Policy SAFI may be set up to routers outside the SR domain. --> 14) <!--[rfced] We note that this document has an Informative Reference entry to draft-ietf-idr-bgp-sr-segtypes-ext-07, which is moving through the RFC Editor queue simultaneously. We have updated this reference entry to use its RFC-to-be form as we assume the intent is to publish them together. However, since this dependency is not normative, please indicate if your preference is not to wait (if draft-ietf-idr-bgp-sr-segtypes-ext-07 has not completed AUTH48 prior to this document; in which case, we would revert to the I-D version of the reference entry). --> 15) <!-- [rfced] We had the following questions/comments related to abbreviation use throughout the document: a) FYI - We have added expansions for abbreviations upon first use per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness. b) We will update to have the abbreviation expanded upon first use and then use the abbreviation thereafter (per the guidance at https://www.rfc-editor.org/styleguide/part2/#exp_abbrev) *except when in a sub-TLV name* for the following abbreviations unless we hear objection. Segment Routing (SR) candidate path (CP) subsequent address family (SAFI) Route Reflectors (RR) Binding SID (BSID) Explicit NULL Label Policy (ENLP) c) May we expand NH as Next Hop? --> 16) <!--[rfced] We had the following questions related to terminology use throughout the document. a) Should the following terms be made consistent with regard to capitalization, hyphenation, etc.? If so, please let us know how to update. SR Policy vs. SR policy vs. policy BGP UPDATE message vs. BGP update message vs. BGP Update Route Target Extended Community vs. route target extended community Tunnel Type vs. Tunnel-Type vs. Tunnel-type Flags field vs. Flag octect (singular and field vs. octet) Color vs. color Endpoint vs. endpoint Length field vs. length field (and simply length) "Drop Upon Invalid" behavior vs. "drop upon invalid" config Segment Type vs. segment type vs. Segment Types sub-TLV (plural) Explicit NULL Label vs. Explicit NULL label b) We see that some field names are in double quotes. Should this be made uniform throughout? If so, are quotation marks or no quotation marks preferred? For example: "Flags" field vs. Flags field --> 17) <!--[rfced] Please review uses of the slash character "/" in the body of the document and consider whether "and", "or", or "and/or" might be clearer for the reader. --> 18) <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> 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. --> Thank you. RFC Editor/mf *****IMPORTANT***** Updated 2025/07/16 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/rfc9830.xml https://www.rfc-editor.org/authors/rfc9830.html https://www.rfc-editor.org/authors/rfc9830.pdf https://www.rfc-editor.org/authors/rfc9830.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9830-diff.html https://www.rfc-editor.org/authors/rfc9830-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9830-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9830 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9830 (draft-ietf-idr-sr-policy-safi-13) Title : Advertising Segment Routing Policies in BGP Author(s) : S. Previdi, C. Filsfils, K. Talaulikar, P. Mattes, D. Jain WG Chair(s) : Susan Hares, Keyur Patel, Jeffrey Haas 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
