Hello, The document looks good to me and I approve its publication.
Cheers, Clarence From: Ketan Talaulikar <ketant.i...@gmail.com> Sent: Friday, August 1, 2025 7:40 AM To: Karen Moore <kmo...@staff.rfc-editor.org> Cc: Clarence Filsfils (cfilsfil) <cfils...@cisco.com>; dhanendra.i...@gmail.com; stef...@previdi.net; pamat...@microsoft.com; Megan Ferguson <mfergu...@staff.rfc-editor.org>; RFC Editor <rfc-edi...@rfc-editor.org>; idr-...@ietf.org; idr-chairs <idr-cha...@ietf.org>; Sue Hares <sha...@ndzh.com>; Roman Danyliw <r...@cert.org>; Shawn Zandi via auth48archive <auth48archive@rfc-editor.org> Subject: Re: AUTH48: RFC-to-be 9830 <draft-ietf-idr-sr-policy-safi-13> for your review Thanks Karen everything looks good to me. Thanks, Ketan On Fri, Aug 1, 2025 at 2:31 AM Karen Moore <kmo...@staff.rfc-editor.org<mailto:kmo...@staff.rfc-editor.org>> 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 > <ketant.i...@gmail.com<mailto:ketant.i...@gmail.com>> 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 > <kmo...@staff.rfc-editor.org<mailto:kmo...@staff.rfc-editor.org>> 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 > <ketant.i...@gmail.com<mailto:ketant.i...@gmail.com>> wrote: > > Hi Megan, > > Thanks for your response. Please check inline below. > > > On Tue, Jul 22, 2025 at 7:32 PM Megan Ferguson > <mfergu...@staff.rfc-editor.org<mailto:mfergu...@staff.rfc-editor.org>> 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 > > <ketant.i...@gmail.com<mailto:ketant.i...@gmail.com>> 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 > > <rfc-edi...@rfc-editor.org<mailto:rfc-edi...@rfc-editor.org>> 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 > > > > * rfc-edi...@rfc-editor.org<mailto: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<mailto: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<mailto: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
