Hello Clarence and Ketan, Thanks for your replies. We have noted Clarence’s approval on the AUTH48 status page ( https://www.rfc-editor.org/auth48/rfc9830).
We now await approvals from Dhanendra, Paul, and Stefano. Once approvals are received, we will ask IANA to update their registries to match the edited document. Best regards, RFC Editor/kc > On Aug 1, 2025, at 1:28 AM, Clarence Filsfils (cfilsfil) <cfils...@cisco.com> > wrote: > > 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> > 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> 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> > > 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> 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> 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 > > (seehttps://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> > > > 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> 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 > > > inhttps://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 (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
