Hi Kaelin I have reviewed the updates and I approve.
Thank you Gyan On Mon, Mar 9, 2026 at 11:22 AM Kaelin Foody <[email protected]> wrote: > 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 <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]
