All, Thank you for your reviews and approvals. We have marked them on the AUTH48 status page for this document available below: https://www.rfc-editor.org/auth48/rfc9947
We only await Gyan's approval at this time. Note that we have updated Gyan’s email address in this thread to [email protected] <mailto:[email protected]> (as we received bounce messages from [email protected] <mailto:[email protected]>). We will also update Gyan's email address in this document accordingly. Please let us know if you have any questions in the meantime. Thank you, Kaelin Foody RFC Production Center > On Mar 9, 2026, at 9:15 AM, Independent Submissions Editor (Eliot Lear) > <[email protected]> wrote: > > Approved. > On 06.03.2026 21:58, Kaelin Foody wrote: >> Hi Giuseppe, >> >> Thank you for sending along your responses and an XML file. You may find the >> updated files at the end of this email. >> >> Please reach out with any further updates or with your approval of the >> document in its current form. We will await approvals from each party listed >> on the AUTH48 status page for this document prior to moving forward in the >> publication process. >> >> Please review the document carefully to ensure satisfaction as we do not >> make changes once it has been published as an RFC. >> >> The AUTH48 status page for this document is available here: >> https://www.rfc-editor.org/auth48/rfc9947 >> >> — FILES (please refresh): — >> >> The updated files have been posted here: >> https://www.rfc-editor.org/authors/rfc9947.txt >> https://www.rfc-editor.org/authors/rfc9947.pdf >> https://www.rfc-editor.org/authors/rfc9947.html >> https://www.rfc-editor.org/authors/rfc9947.xml >> >> Diff files showing changes made during AUTH48: >> https://www.rfc-editor.org/authors/rfc9947-auth48diff.html >> https://www.rfc-editor.org/authors/rfc9947-auth48rfcdiff.html (side by side) >> >> Diff files showing all changes: >> https://www.rfc-editor.org/authors/rfc9947-diff.html >> https://www.rfc-editor.org/authors/rfc9947-rfcdiff.html (side by side) >> >> Thank you, >> >> Kaelin Foody >> RFC Production Center >> >> >>> On Mar 4, 2026, at 10:15 AM, Giuseppe Fioccola >>> <[email protected]> wrote: >>> >>> Hi Kaelin, Sandy, >>> Please find attached the updated XML file. I have answered to your >>> questions and fixed minor nits in section 1.1 and 3.2. I also changed the >>> affiliation of two contributors. >>> >>> Looking forward to hearing from you. >>> >>> Regards, >>> >>> Giuseppe >>> >>> -----Original Message----- >>> From: [email protected] <[email protected]> >>> Sent: Tuesday, March 3, 2026 6:13 PM >>> To: Giuseppe Fioccola <[email protected]>; Tianran Zhou >>> <[email protected]>; [email protected]; >>> [email protected]; [email protected]; >>> [email protected] >>> Cc: [email protected]; [email protected]; >>> [email protected] >>> Subject: Re: AUTH48: RFC-to-be 9947 <draft-fz-spring-srv6-alt-mark-17> for >>> your review >>> >>> Authors, >>> >>> While reviewing this document during AUTH48, please resolve (as necessary) >>> the following questions, which are also in the source 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] Please consider the following with regard to the text >>> below. >>> >>> A) How may we update the instances below to clarify the RFC Editor's role >>> in the submission process? We believe the text should refer to the >>> Independent Submissions Editor instead. >>> >>> B) Is the goal to describe the results in an Internet-Draft for discussion >>> or for consideration for publication as an RFC, or both? Note that >>> Independent Submissions also get posted as Internet-Drafts. >>> >>> C) May we update "to help forward" to "to help progress" or perhaps "to >>> evolve"? >>> >>> Original: >>> Researchers are invited to submit their evaluations of this work to >>> the RFC Editor for consideration as independent submissions or to the >>> IETF SPRING working group as Internet-Drafts. >>> >>> ... >>> >>> The results of this experiment will be collected and shared with the >>> RFC Editor for consideration as independent submission or with the >>> IETF SPRING working group as Internet-Draft, to help forward the >>> discussions that will determine the correct development of Alternate >>> Marking Method solutions in SRv6 networks. >>> >>> >>> Perhaps: >>> Researchers are invited to submit their evaluations of this work to >>> the Independent Submissions Editor or to the IETF SPRING Working Group >>> as Internet-Drafts. >>> >>> ... >>> >>> The results of this experiment will be collected and shared with the >>> Independent Submissions Editor or with the IETF SPRING Working Group >>> as Internet-Drafts to help progress the >>> discussions that will determine the correct development of Alternate- >>> Marking Method solutions in SRv6 networks. >>> --> >>> >>> >>> 3) <!-- [rfced] We are having trouble parsing "the mechanism to carry." >>> Does the mechanism carry the headers? Perhaps this refers to the ability to >>> carry Alternate-Marking data? Please clarify. >>> >>> Original (sentence prior provided for context): >>> [RFC9343] defines the >>> standard for how the marking field can be encoded in a new TLV in >>> either Hop-by-hop or Destination Options Headers of IPv6 packets in >>> order to achieve Alternate Marking. The mechanism to carry is >>> equally applicable to Segment Routing for IPv6 (SRv6) networks >>> [RFC8402]. >>> --> >>> >>> >>> 4) <!-- [rfced] For clarity, please consider the following update to >>> indicate the purpose of the experiment. >>> >>> Original: >>> As >>> also highlighted in [I-D.bonica-gendispatch-exp], when two protocol >>> extensions are proposed to solve a single problem, an experiment can >>> be initiated and this is the purpose of this document. See Section 5 >>> for more details about the experimentation. >>> >>> Perhaps: >>> As >>> also highlighted in [IETF-EXPERIMENTS], when two protocol >>> extensions are proposed to solve a single problem, an experiment can >>> be initiated to gather operational experience and "determine which, >>> if either, of the protocols should be progressed to the standards >>> track." This is the purpose of this document. See Section 5 >>> for more details about the experiment. >>> --> >>> >>> >>> 5) <!-- [rfced] May we adjust "it is also allowed" as follows? >>> >>> Original: >>> In addition to the base data fields of [RFC9343], it is also allowed >>> the insertion of optional extended data fields which are not present >>> in [RFC9343]. >>> >>> Perhaps: >>> In addition to the base data fields of [RFC9343], the insertion of >>> optional extended data fields that are not present in [RFC9343] >>> are also allowed. >>> --> >>> >>> >>> 6) <!-- [rfced] For clarity, please consider the following update. >>> >>> Original: >>> Therefore, the experimentation of the Alternate Marking Method to >>> SRv6 MUST be deployed only within a controlled domain. >>> >>> Perhaps: >>> Therefore, the experiment of applying the Alternate-Marking Method to >>> SRv6 MUST only be deployed within a controlled domain. >>> --> >>> >>> >>> 7) <!-- [rfced] Should "of" be updated to "or" in the text below? >>> >>> Original: >>> Carefully bounding the domain reduces the risk of the experiment >>> leaking out and clashing with other experiments of causing unforeseen >>> consequences in wider deployments. >>> >>> Perhaps: >>> Carefully bounding the domain reduces the risk of the experiment >>> leaking out and clashing with other experiments or causing unforeseen >>> consequences in wider deployments. >>> >>> --> >>> >>> >>> 8) <!-- [rfced] FYI - We have adjusted the title of Figure 1 to avoid >>> multiple colons. Please review. >>> >>> Original: >>> >>> Figure 1: AltMark: SRH TLV for alternate marking >>> >>> Current: >>> >>> Figure 1: The AltMark SRH TLV for Alternate Marking >>> >>> --> >>> >>> >>> 9) <!-- [rfced] "Experimentation of this document" is a bit awkward. >>> Perhaps one of the suggested updates below is more clear? >>> >>> Original: >>> Experimentation of this document must coordinate >>> the value used by all implementations participating in the >>> experiment. >>> >>> Perhaps A: >>> Participants experimenting with applying the Alternate-Marking Method >>> to SRH must coordinate the value used. >>> >>> Perhaps B: >>> Deployment of this document must coordinate >>> the value used by all implementations participating in the >>> experiment. >>> >>> >>> Please consider whether this text may be updated in a similar manner. >>> >>> Original: >>> Experimentation of this document must use a code point chosen from >>> the Experimental range, as noted in Section 3, and should make it >>> possible for the operator to configure the value used in a deployment >>> such that it is possible to conduct multiple non-conflicting >>> experiments within the same network. >>> >>> Perhaps: >>> Experiment participants must use a code point ... >>> >>> --> >>> >>> >>> 10) <!-- [rfced] For readability, please consider the following update. >>> >>> Original: >>> The security requirement of >>> controlled domain applies to both this document and [RFC9343], and it >>> also confines this duplication to a single service provider networks. >>> However, duplication of the same information in different places >>> should be avoided and it is recommended to only analyze the use of >>> SRH AltMark TLV for the experimentation. >>> >>> Perhaps: >>> Both this document and [RFC9343] require a controlled domain for >>> security purposes, which confines this duplication to a >>> single service provider network. Duplication of the same >>> information in different places should be avoided, and analyzing >>> the use of only the SRH AltMark TLV is recommended as part of >>> this experiment. >>> --> >>> >>> >>> 11) <!-- [rfced] FYI - We have updated "comparing the use of" to "compared >>> to the use of" in the text below. Please review. >>> >>> Original: >>> Is the forwarding plane performance impacted across different >>> device architecture types comparing the use of SRH TLV and >>> Destination Option? >>> >>> Current: >>> * Is the forwarding plane performance impacted across different >>> device architecture types compared to the use of SRH TLV and >>> Destination Option? >>> --> >>> >>> >>> 12) <!-- [rfced] Terminology and Abbreviations: >>> >>> a) For consistency with RFC 9343, we have updated instances of "Alternate >>> Marking Method" to appear as "Alternate-Marking Method" throughout. We have >>> also hyphenated other instances where "Alternate Marking" is acting as an >>> adjective that precedes the nounn. Please let us know any objections. >>> >>> >>> b) We have added "Method" to a few instances of "the Alternate Marking" as >>> seen below. Please let us know if any corrections are needed. >>> >>> Original: >>> Section 2 covers the application of the Alternate Marking to SRv6... >>> >>> Application of the Alternate Marking to SRv6 >>> >>> >>> Current: >>> Section 2 covers the application of the Alternate Marking Method to SRv6... >>> >>> Application of the Alternate Marking Method to SRv6 >>> >>> >>> c) We have expanded the following abbreviation upon first use per Section >>> 3.6 of RFC 7322 ("RFC Style Guide"). Please review and let us know any >>> corrections. >>> >>> Differentiated Services Code Point (DSCP) >>> --> >>> >>> >>> 13) <!-- [rfced] Please review the "Inclusive Language" portion of the >>> online Style Guide >>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> >>> and let us know if any changes are needed. Updates of this nature typically >>> result in more precise language, which is helpful for readers. >>> >>> Note that our script did not flag any words in particular, but this should >>> still be reviewed as a best practice. >>> --> >>> >>> >>> Thank you. >>> >>> Kaelin Foody and Sandy Ginoza >>> RFC Production Center >>> >>> >>> >>> On Mar 3, 2026, at 9:07 AM, [email protected] wrote: >>> >>> *****IMPORTANT***** >>> >>> Updated 2026/03/03 >>> >>> 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/rfc9947.xml >>> https://www.rfc-editor.org/authors/rfc9947.html >>> https://www.rfc-editor.org/authors/rfc9947.pdf >>> https://www.rfc-editor.org/authors/rfc9947.txt >>> >>> Diff file of the text: >>> https://www.rfc-editor.org/authors/rfc9947-diff.html >>> https://www.rfc-editor.org/authors/rfc9947-rfcdiff.html (side by side) >>> >>> Diff of the XML: >>> https://www.rfc-editor.org/authors/rfc9947-xmldiff1.html >>> >>> >>> Tracking progress >>> ----------------- >>> >>> The details of the AUTH48 status of your document are here: >>> https://www.rfc-editor.org/auth48/rfc9947 >>> >>> Please let us know if you have any questions. >>> >>> Thank you for your cooperation, >>> >>> RFC Editor >>> >>> -------------------------------------- >>> RFC9947 (draft-fz-spring-srv6-alt-mark-17) >>> >>> Title : Application of the Alternate Marking Method to the Segment Routing >>> Header >>> Author(s) : G. Fioccola, T. Zhou, G. Mishra, X. Wang, G. Zhang, M. Cociglio >>> WG Chair(s) : >>> Area Director(s) : >>> >>> >>> >>> <rfc9947 GFv1.xml> >>> >> -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
