Hi, the document looks good to me.
thanks. s. > On Jul 31, 2025, at 11:01 PM, Karen Moore <[email protected]> wrote: > > Hi Ketan, > > Thank you for the clarifications and for working closely with us on the > terminology; we have noted your approval of the document on the AUTH48 status > page. Note that we updated our files to reflect “long SR Policy name” and > have included “SR” for “Policy Name”, “Policy Candidate Path”, and the TLV > names with policy in them (excluding "Explicit NULL Label Policy” as > previously mentioned). > > We also changed “Policy Color” to “Color”, and we updated the SR Policy SAFI > NLRI as follows; if that is not correct, please let us know. > > Original: > SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint> > > Current: > SR Policy SAFI NLRI: <Distinguisher, Color, Endpoint> > > Please review the updated files and let us know if any other updates are > needed. > > --FILES (please refresh)-- > > The files have been posted here: > https://www.rfc-editor.org/authors/rfc9830.txt > https://www.rfc-editor.org/authors/rfc9830.pdf > https://www.rfc-editor.org/authors/rfc9830.html > https://www.rfc-editor.org/authors/rfc9830.xml > > The relevant diff files have been posted here: > https://www.rfc-editor.org/authors/rfc9830-diff.html > https://www.rfc-editor.org/authors/rfc9830-rfcdiff.html (side by side) > https://www.rfc-editor.org/authors/rfc9830-auth48diff.html > https://www.rfc-editor.org/authors/rfc9830-auth48rfcdiff.html (side by side) > > These diff files show only the changes made during the last edit round: > https://www.rfc-editor.org/authors/rfc9830-lastdiff.html > https://www.rfc-editor.org/authors/rfc9830-lastrfcdiff.html (side by side) > > We will await approvals from each party listed at this document’s AUTH48 > status page (see https://www.rfc-editor.org/auth48/rfc9830) and the > completion of AUTH48 of this document’s companion documents (see > https://www.rfc-editor.org/cluster_info.php?cid=C534) prior to moving forward > in the publication process. > > Best regards, > RFC Editor/kc > > >> On Jul 31, 2025, at 5:36 AM, Ketan Talaulikar <[email protected]> wrote: >> >> Hi Karen, >> >> That one instance left about "long policy name" is also about the "SR >> Policy". >> >> Moreover, the names like Policy Name and Policy Candidate Path name should >> be changed to "SR Policy ..." for consistency. This also applies to the >> TLV/sub-TLV names that have "Policy" in it. The only exception is perhaps >> Figure 1 and its field explanations where we can change "Policy Color" to >> "Color" so it aligns with the "Endpoint" that is used without that prefix. >> >> I have reviewed all other changes in the diff and please consider this email >> as my approval for publication. >> >> Thanks, >> Ketan >> >> >> On Thu, Jul 31, 2025 at 12:22 AM Karen Moore <[email protected]> >> wrote: >> Hi Ketan, >> >> We have made the changes discussed below. Please review the updated files >> and let us know if any further updates are needed or if the current text is >> agreeable. >> >> Note that we left one instance of "policy" here: "The Policy Name sub-TLV >> may exceed 255 bytes in length due to a long policy name". If that is not >> correct and it should be "SR Policy", please let us know. >> >> --FILES (please refresh)-- >> >> The files have been posted here: >> https://www.rfc-editor.org/authors/rfc9830.txt >> https://www.rfc-editor.org/authors/rfc9830.pdf >> https://www.rfc-editor.org/authors/rfc9830.html >> https://www.rfc-editor.org/authors/rfc9830.xml >> >> The relevant diff files have been posted here: >> https://www.rfc-editor.org/authors/rfc9830-diff.html >> https://www.rfc-editor.org/authors/rfc9830-rfcdiff.html (side by side) >> https://www.rfc-editor.org/authors/rfc9830-auth48diff.html >> https://www.rfc-editor.org/authors/rfc9830-auth48rfcdiff.html (side by side) >> >> These diff files show only the changes made during the last edit round: >> https://www.rfc-editor.org/authors/rfc9830-lastdiff.html >> https://www.rfc-editor.org/authors/rfc9830-lastrfcdiff.html (side by side) >> >> We will await approvals from each party listed at this document’s AUTH48 >> status page (see https://www.rfc-editor.org/auth48/rfc9830) and the >> completion of AUTH48 of this document’s companion documents (see >> https://www.rfc-editor.org/cluster_info.php?cid=C534) prior to moving >> forward in the publication process. >> >> Best regards, >> RFC Editor/kc >> >> On Jul 27, 2025, at 6:59 AM, Ketan Talaulikar <[email protected]> wrote: >> >> Hi Megan, >> >> Thanks for your response. Please check inline below. >> >> >> On Tue, Jul 22, 2025 at 7:32 PM Megan Ferguson >> <[email protected]> wrote: >> Hi Ketan, >> >> Thank you for your reply and guidance! >> >> A few followups below with comments in [rfced]: >> >> >>>> 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... >>>> >>>> >>>> --> >>>> >>>> KT> It should be "4 octets carrying and unsigned ..." >> >> [rfced] We made this “4 octets carrying an unsigned…” (“an" instead of >> “and"). If this is in error, please let us know. >> >> KT> Agree >> >> >> >>> 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 >> [rfced] We have not made any updates to uses of simply “policy”. If there >> are places where it should be changed to “SR Policy”, please let us know. >> >> KT> Thanks for bringing this to my attention. Except for the following >> instances, all other uses of "policy" should be replaced by "SR Policy" for >> clarity and consistency. There are quite a lot of places where we have >> missed this. >> >> "local policy" or "one possible policy" or "registration policy" ... where >> the use is as in the English word policy and not the technical term SR Policy >> "explicit null label policy" >> >> >>> >>> KT> SR Policy per RFC9256 >>> >>> BGP UPDATE message vs. BGP update message vs. BGP Update >>> >>> KT> BGP UPDATE message per RFC4271 when referring to the message >> >> [rfced] Please carefully review our updates to these and let us know if >> further changes are necessary (as we tried to take clues from the context in >> some places). >> >> KT> Looks good to me >> >>> >>> [snip] >>> >>> Color vs. color >>> >>> KT> Color >>> >>> Endpoint vs. endpoint >>> >>> KT> endpoint >> >> [rfced] As color and endpoint are often in a tuple and used similarly, we >> wondered if they should be treated the same for capitalization — so we ended >> up capping Endpoint as this also seemed to match the use in RFC 9256. Please >> review the text as it stands and let us know if you would like further >> updates. >> >> KT> The capitalization is correct where Color and Endpoint are used together >> (or SRv6 Endpoint Behavior) - that is a technical term. However, there are >> only a few other places where the word is used as an English word and should >> not be capitalized (e.g. "link endpoints", "endpoint/node addresses"). >> >>> >>> [snip] >>> >>> "Drop Upon Invalid" behavior vs. "drop upon invalid" config >>> >>> KT> Drop-Upon-Invalid per RFC9256 >> >> [rfced] We assume no change from “config” to “behavior” is desired. Please >> correct us if that is in error. Also, please see the related updates to the >> IANA Considerations sections and let us know any objections to the changes >> there (as the name of the I-Flag). >> >> KT> Looks good except that there is still one use of "config" in that >> context that should be changed to "behavior" for consistency. >> >> >> >> [rfced] With regard to ENLP (mentioned in both questions 15 and 16 in our >> previous mail), we see variance between the following when we look for the >> sub-TLV name: >> >> ENLP sub-TLV >> Explicit NULL Label Policy (ENLP) sub-TLV >> >> Please let us know if/how these may be made consistent. >> >> KT> The expanded form should be there on first use (also on section title >> and IANA) and rest of the text we can use the acronym as per usual practice. >> >> Thanks again, >> Ketan >> >> >> >> >> All other requested changes have been incorporated and the files have been >> reposted (please be sure to refresh). >> >> The files have been posted here: >> https://www.rfc-editor.org/authors/rfc9830.txt >> https://www.rfc-editor.org/authors/rfc9830.pdf >> https://www.rfc-editor.org/authors/rfc9830.html >> https://www.rfc-editor.org/authors/rfc9830.xml >> >> The relevant diff files have been posted here: >> https://www.rfc-editor.org/authors/rfc9830-diff.html >> https://www.rfc-editor.org/authors/rfc9830-rfcdiff.html (side by side) >> https://www.rfc-editor.org/authors/rfc9830-auth48diff.html >> https://www.rfc-editor.org/authors/rfc9830-auth48rfcdiff.html (side by >> side) >> >> Please review carefully as we do not make changes once the document is >> published as an RFC. >> >> We will await the resolution of the issues above, approvals from each party >> listed at this document’s AUTH48 status page (see >> https://www.rfc-editor.org/auth48/rfc9830), and the completion of AUTH48 of >> this document’s companion documents (see >> https://www.rfc-editor.org/cluster_info.php?cid=C534) prior to moving >> forward in the publication process. >> >> Thank you. >> >> RFC Editor/mf >> >> >> >> >>> On Jul 18, 2025, at 11:10 AM, Ketan Talaulikar <[email protected]> >>> wrote: >>> >>> Hi Megan, >>> >>> Thanks for your help on this document. Please check inline below for >>> responses. >>> >>> >>> On Thu, Jul 17, 2025 at 4:33 AM <[email protected]> wrote: >>> 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. >>> >>> --> >>> >>> KT> Option B is better. >>> >>> >>> >>> 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. >>> >>> >>> KT> How about the following? >>> >>> The distinguisher has no semantic value. It is used by the SR Policy >>> originator to form unique NLRIs in the following situations: >>> - to differentiate multiple candidate paths of the same SR Policy >>> - to differentiate candidate paths meant for different headends but having >>> the same Color and Endpoint >>> >>> >>> >>> --> >>> >>> >>> 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. --> >>> >>> KT> Yes, please update to match RFC4456 >>> >>> >>> >>> 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... >>> >>> >>> --> >>> >>> KT> It should be "4 octets carrying and unsigned ..." >>> >>> >>> >>> 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. >>> --> >>> >>> KT> It should be (but please feel free to improve): >>> >>> If one or more route targets are present, and none matches the >>> local BGP Identifier, then, while the SR Policy NLRI is valid, the SR >>> Policy NLRI is 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. >>> >>> KT> Looks good to me >>> >>> >>> 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. >>> >>> KT> I would check on this with the IANA team on their preference >>> >>> >>> c) Would you like to add section pointers to the corresponding >>> subsections where the actions are further described? >>> >>> KT> I don't think this is necessary as they are easy to locate just by >>> looking at the index. However, there is no concern if they were included as >>> well. I would go with your recommendation. >>> >>> >>> 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 >>> >>> KT> This looks like an action that IANA does on its own when something new >>> gets added to the IANA SAFI registry group. Please check the note in >>> https://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml and as >>> such this document does not need to say anything in this regard. I am happy >>> to be corrected by the IANA team. >>> >>> >>> >>> 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 >>> >>> KT> I think what we have currently looks good to me. Please let me know if >>> the IANA team feels otherwise. >>> >>> >>> 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"? >>> >>> KT> This is related to (7)(b) and I would let the IANA team take the call >>> if a change is needed. >>> >>> >>> >>> --> >>> >>> >>> 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? >>> >>> KT> Yes please - IETF is the change controller for all of them. >>> >>> >>> 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 >>> >>> KT> Ack >>> >>> --> >>> >>> >>> 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 >>> >>> KT> Ack >>> >>> >>> 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. >>> >>> KT> The names of the segments (titles) are to be "Segment Type X" while the >>> name of the sub-TLVs are to be "Type X Segment sub-TLV" (I've seen both >>> sub-TLV and Sub-TLV - either is OK but we should have been consistent). The >>> "Type-1" is actually "Type A Segment sub-TLV". >>> >>> >>> 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. >>> >>> KT> I don't think any update is necessary as they were not assigned by this >>> document but the other draft-ietf-idr-bgp-sr-segtypes-ext which is also in >>> the RFC Editor Q. Please do cross-check with IANA as well though. >>> >>> >>> --> >>> >>> >>> 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. >>> >>> --> >>> >>> KT> This too is related to draft-ietf-idr-bgp-sr-segtypes-ext and so it is >>> the same as the previous comment. >>> >>> >>> >>> 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 >>> >>> KT> We can make it "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. >>> >>> --> >>> >>> KT> Ack >>> >>> >>> >>> 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). --> >>> >>> KT> I would prefer to process them together for publication. They were a >>> single document and the authors were made to split them. >>> >>> >>> >>> 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. >>> >>> KT> Please change [SR-BGP-LS] to [BGP-LS-SR-POLICY]. Everything else looks >>> good to me. >>> >>> >>> 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. >>> >>> KT> Ack >>> >>> >>> 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? >>> >>> KT> Yes >>> >>> >>> --> >>> >>> >>> 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 >>> >>> KT> SR Policy per RFC9256 >>> >>> BGP UPDATE message vs. BGP update message vs. BGP Update >>> >>> KT> BGP UPDATE message per RFC4271 when referring to the message >>> >>> Route Target Extended Community vs. route target extended community >>> >>> KT> Route Target extended community >>> >>> Tunnel Type vs. Tunnel-Type vs. Tunnel-type >>> >>> KT> Tunnel Type >>> >>> Flags field vs. Flag octect (singular and field vs. octet) >>> >>> KT> Flags field >>> >>> Color vs. color >>> >>> KT> Color >>> >>> Endpoint vs. endpoint >>> >>> KT> endpoint >>> >>> Length field vs. length field (and simply length) >>> >>> KT> Length field >>> >>> "Drop Upon Invalid" behavior vs. "drop upon invalid" config >>> >>> KT> Drop-Upon-Invalid per RFC9256 >>> >>> Segment Type vs. segment type vs. Segment Types sub-TLV (plural) >>> >>> KT> That would vary by context - capitalized when referring to the name and >>> lowercase otherwise >>> >>> Explicit NULL Label vs. Explicit NULL label >>> >>> KT> That would vary by context - same as the previous one >>> >>> >>> 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 >>> >>> KT> I think we can skip the quotes. >>> >>> >>> >>> --> >>> >>> >>> 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. --> >>> >>> KT> No change is needed - they are clear to the reader in the respective >>> context >>> >>> >>> >>> 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. >>> --> >>> >>> KT> Thanks for the check. >>> >>> Thanks, >>> Ketan >>> >>> >>> >>> 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 >>> >>> * [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/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 -- [email protected] To unsubscribe send an email to [email protected]
