Re: [auth48] AUTH48: RFC-to-be 9452 <draft-ietf-sfc-ioam-nsh-13> for your review

[Shwetha Bhandari <[e-mail]>]

Hello Sarah,

Thanks for all the edits. The document looks good to me too.

Thanks
Shwetha

On Mon, 14 Aug 2023, 7:19 pm Sarah Tarrant, <[e-mail]> wrote:

> Hello Frank,
>
> Thank you for your reply. We have marked your approval on the AUTH48
> status page for this document (see
> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9404__;!!MZ3Fw45to5uY!PbiZF46gCqWC6JubvBjVOEeHQBsXGkYEpa8fHBjM7zdw71xB11xUirYWDvhn2A24NoaPxIomzAIB6QWUNpzLhgFqQA$
> ).
>
> We will assume your assent to any further changes submitted by your
> coauthors unless we hear objection at that time. We will await approvals
> from each of the parties listed at the AUTH48 status page prior to moving
> this document forward in the publication process.
>
> Thank you,
> RFC Editor/st
>
> > On Aug 14, 2023, at 8:41 AM, Frank Brockners (fbrockne) <
> [e-mail]> wrote:
> >
> > Hi Sarah,
> >
> > Thanks for implementing all the changes we discussed. The document looks
> ready for publishing to me.
> >
> > Cheers, Frank
> >
> >> -----Original Message-----
> >> From: Sarah Tarrant <[e-mail]>
> >> Sent: Thursday, 10 August 2023 19:43
> >> To: Frank Brockners (fbrockne) <[e-mail]>
> >> Cc: RFC Editor <[e-mail]>;
> >> [e-mail]; [e-mail]; [e-mail]
> ;
> >> [e-mail]; [e-mail];
> >> [e-mail]; [e-mail]
> >> Subject: Re: AUTH48: RFC-to-be 9452 <draft-ietf-sfc-ioam-nsh-13> for
> your
> >> review
> >>
> >> Hello Frank,
> >>
> >> Thank you for your reply and guidance. We have updated the document
> >> accordingly.
> >>
> >> The files have been posted here (please refresh):
> >>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9452.xml__;!!MZ3Fw45to5uY!PbiZF46gCqWC6JubvBjVOEeHQBsXGkYEpa8fHBjM7zdw71xB11xUirYWDvhn2A24NoaPxIomzAIB6QWUNpyA_qJ1Ng$
> >>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9452.txt__;!!MZ3Fw45to5uY!PbiZF46gCqWC6JubvBjVOEeHQBsXGkYEpa8fHBjM7zdw71xB11xUirYWDvhn2A24NoaPxIomzAIB6QWUNpy622snag$
> >>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9452.html__;!!MZ3Fw45to5uY!PbiZF46gCqWC6JubvBjVOEeHQBsXGkYEpa8fHBjM7zdw71xB11xUirYWDvhn2A24NoaPxIomzAIB6QWUNpy50XqlGQ$
> >>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9452.pdf__;!!MZ3Fw45to5uY!PbiZF46gCqWC6JubvBjVOEeHQBsXGkYEpa8fHBjM7zdw71xB11xUirYWDvhn2A24NoaPxIomzAIB6QWUNpwoO7G95A$
> >>
> >> The relevant diff files have been posted here:
> >>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9452-diff.html__;!!MZ3Fw45to5uY!PbiZF46gCqWC6JubvBjVOEeHQBsXGkYEpa8fHBjM7zdw71xB11xUirYWDvhn2A24NoaPxIomzAIB6QWUNpx1bQUW5A$
> (comprehensive diff)
> >>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9452-rfcdiff.html__;!!MZ3Fw45to5uY!PbiZF46gCqWC6JubvBjVOEeHQBsXGkYEpa8fHBjM7zdw71xB11xUirYWDvhn2A24NoaPxIomzAIB6QWUNpx-QQ6M0g$
> (comprehensive
> >> rfcdiff)
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9452-auth48diff.html__;!!MZ3Fw45to5uY!PbiZF46gCqWC6JubvBjVOEeHQBsXGkYEpa8fHBjM7zdw71xB11xUirYWDvhn2A24NoaPxIomzAIB6QWUNpyVv_tB8g$
> >> (AUTH48 changes only)
> >>
> >> Please review the document carefully as documents do not change once
> >> published as RFCs.
> >>
> >> We will await any further changes you may have and approvals from each
> >> author prior to moving forward in the publication process.
> >>
> >> For the AUTH48 status of this document, please see:
> >>
> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9452__;!!MZ3Fw45to5uY!PbiZF46gCqWC6JubvBjVOEeHQBsXGkYEpa8fHBjM7zdw71xB11xUirYWDvhn2A24NoaPxIomzAIB6QWUNpw0syHLWQ$
> >>
> >> Thank you,
> >> RFC Editor/st
> >>
> >>> On Aug 9, 2023, at 8:17 AM, Frank Brockners (fbrockne)
> >> <[e-mail]> wrote:
> >>>
> >>> Hi Sarah,
> >>>
> >>> I replied earlier today (see attached). Did you receive my reply?
> >>>
> >>> Cheers, Frank
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Sarah Tarrant <[e-mail]>
> >>>> Sent: Wednesday, 9 August 2023 15:05
> >>>> To: RFC Editor <[e-mail]>
> >>>> Cc: Frank Brockners (fbrockne) <[e-mail]>;
> >>>> [e-mail]; [e-mail];
> >>>> [e-mail]; [e-mail];
> >>>> [e-mail]; [e-mail]
> >>>> Subject: Re: AUTH48: RFC-to-be 9452 <draft-ietf-sfc-ioam-nsh-13> for
> >>>> your review
> >>>>
> >>>> Greetings,
> >>>>
> >>>> Just a friendly weekly reminder that this document awaits your
> attention.
> >>>>
> >>>> Please see the document-specific questions and AUTH48 announcement
> >> in
> >>>> this thread and let us know if we can be of assistance as you begin
> >>>> the
> >>>> AUTH48 review process.
> >>>>
> >>>> Please note that the AUTH48 status page of this document is viewable
> >> at:
> >>>>
> https://urldefense.com/v3/__http://www.rfc-editor.org/auth48/rfc9452__;!!MZ3Fw45to5uY!PbiZF46gCqWC6JubvBjVOEeHQBsXGkYEpa8fHBjM7zdw71xB11xUirYWDvhn2A24NoaPxIomzAIB6QWUNpzntjGIHw$
> >>>>
> >>>> AUTH48 FAQs are available at
> https://urldefense.com/v3/__https://www.rfc-editor.org/faq/*auth48__;Iw!!MZ3Fw45to5uY!PbiZF46gCqWC6JubvBjVOEeHQBsXGkYEpa8fHBjM7zdw71xB11xUirYWDvhn2A24NoaPxIomzAIB6QWUNpwTQ_NpFA$
> .
> >>>>
> >>>> We look forward to hearing from you at your earliest convenience.
> >>>>
> >>>> Thank you.
> >>>> RFC Editor/st
> >>>>
> >>>>> On Jul 31, 2023, at 9:58 PM, [e-mail] 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 note that the title of the document has been
> >>>>> updated as follows ("In-situ" to "In Situ"):
> >>>>>
> >>>>> Original:
> >>>>> Network Service Header (NSH) Encapsulation for In-situ OAM (IOAM)
> >>>>> Data
> >>>>>
> >>>>> Current:
> >>>>> Network Service Header (NSH) Encapsulation for In Situ OAM (IOAM)
> >>>>> Data
> >>>>> -->
> >>>>>
> >>>>>
> >>>>> 2) <!-- [rfced] We are having trouble understanding "by means of
> >>>>> configuration."  Does the suggested text convey the intended meaning?
> >>>>> Also, does "encapsulating/decapsulating" mean "encapsulating and
> >>>>> decapsulating" or "encapsulating or decapsulating"?
> >>>>>
> >>>>> Original:
> >>>>> In an administrative domain where IOAM is used,  insertion of the
> >>>>> IOAM header in NSH is enabled at the NSH tunnel  endpoints, which
> >>>>> also serve as IOAM encapsulating/decapsulating nodes  by means of
> >>>>> configuration.
> >>>>>
> >>>>> Perhaps:
> >>>>> In an administrative domain where IOAM is used,  insertion of the
> >>>>> IOAM header in NSH is enabled at the NSH tunnel  endpoints, which
> >>>>> are also configured to serve as IOAM encapsulating and
> >>>>> decapsulating nodes.
> >>>>> -->
> >>>>>
> >>>>>
> >>>>> 3) <!-- [rfced] This text appears in and points to Section 3.  May
> >>>>> we delete "Section 3"?  Please review.
> >>>>>
> >>>>> Original:
> >>>>> The operator MUST ensure that SFC-aware  nodes along the Service
> >>>>> Function Path support IOAM, otherwise packets  might be dropped (see
> >>>>> Section 3 further below, as well as [RFC8300]  Section 2.2).
> >>>>>
> >>>>> Perhaps:
> >>>>> The operator MUST ensure that SFC-aware  nodes along the Service
> >>>>> Function Path support IOAM; otherwise, packets  might be dropped
> >>>>> (see more below, as well as Section 2.2 of [RFC8300]).
> >>>>> -->
> >>>>>
> >>>>>
> >>>>> 4) <!-- [rfced] Would it be helpful to expand MD for the reader?
> >>>>> Perhaps it
> >>>> could be added to list of abbreviations introduced in Section 2?
> >>>>>
> >>>>> -->
> >>>>>
> >>>>>
> >>>>> 5) <!-- [rfced] For readability, we have updated the text as
> >>>>> follows.  Please
> >>>> let us know if any corrections are needed.
> >>>>>
> >>>>> Original:
> >>>>> Per Section 2.2 of [RFC8300], packets with Next Protocol values not
> >>>>> supported SHOULD be silently dropped by default.
> >>>>>
> >>>>> Current:
> >>>>> Per Section 2.2 of [RFC8300], packets with unsupported Next
> >>>>> Protocol
> >>>> values
> >>>>> SHOULD be silently dropped by default.
> >>>>> -->
> >>>>>
> >>>>>
> >>>>> 6) <!-- [rfced] For readability, may we update the text as follows?
> >>>>>
> >>>>> Original:
> >>>>> IOAM is considered a "per domain" feature, where the operator
> >>>>> decides  on leveraging and configuring IOAM according to the
> >> operator's needs.
> >>>>>
> >>>>> Suggested:
> >>>>> IOAM is considered a "per domain" feature, where the operator
> >>>>> decides  how to leverage and configure IOAM according to the
> >> operator's needs.
> >>>>> -->
> >>>>>
> >>>>>
> >>>>> 7) <!-- [rfced] For clarity, may we update the text as follows?
> >>>>> Please let us
> >>>> know if any corrections are needed.
> >>>>>
> >>>>> Original:
> >>>>> Hardware and software friendly implementation: Hardware forwarders
> >>>>> benefit from an encapsulation that minimizes iterative look-ups of
> >>>>> fields within the packet: Any operation which looks up the value of
> >>>>> a  field within the packet, based on which another lookup is
> >>>>> performed,  consumes additional gates and time in an implementation
> >>>>> - both of  which are desired to be kept to a minimum.
> >>>>>
> >>>>> Current:
> >>>>> Hardware- and software-friendly implementation: Hardware forwarders
> >>>>> benefit from an encapsulation that minimizes iterative lookups of
> >>>>> fields within the packet. Any operation that looks up the value of a
> >>>>> field within the packet, based on which another lookup is performed,
> >>>>> consumes additional gates and time in an implementation, both of
> >>>>> which should be kept to a minimum.
> >>>>> -->
> >>>>>
> >>>>>
> >>>>> 8) <!-- [rfced] Terminology
> >>>>>
> >>>>> a) We note that Figure 1 contains “IOAM Option and Optional Data
> >>>>> Space”, while the text defines “IOAM Option and Data Space”. Please
> >>>>> review and let us know if these should be consistent.
> >>>>>
> >>>>>
> >>>>> b) These terms may be used inconsistently.  Please review and let us
> >>>>> know if the forms on the right (on the right of the arrow) should be
> >>>>> used consistently, or if any other updates are needed.
> >>>>>
> >>>>> IOAM-Data-fields & IOAM data fields -> IOAM-Data-Fields
> >>>>> IOAM-Option-Types -> IOAM Option-Type
> >>>>> -->
> >>>>>
> >>>>>
> >>>>> 9) <!-- [rfced] Please review the "Inclusive Language" portion of
> >>>>> the online Style Guide
> >>>>> <
> https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/*inclusive_language__;Iw!!MZ3Fw45to5uY!PbiZF46gCqWC6JubvBjVOEeHQBsXGkYEpa8fHBjM7zdw71xB11xUirYWDvhn2A24NoaPxIomzAIB6QWUNpzuNWn4_g$
> >
> >>>>> and let us know if any changes are needed.
> >>>>>
> >>>>> Note that our script did not flag any words in particular, but this
> >>>>> should still be reviewed as a best practice.
> >>>>> -->
> >>>>>
> >>>>>
> >>>>> Thank you.
> >>>>>
> >>>>> RFC Editor
> >>>>>
> >>>>>
> >>>>> On Jul 31, 2023, at 7:53 PM, [e-mail] wrote:
> >>>>>
> >>>>> *****IMPORTANT*****
> >>>>>
> >>>>> Updated 2023/07/31
> >>>>>
> >>>>> 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://urldefense.com/v3/__https://www.rfc-editor.org/faq/__;!!MZ3Fw45to5uY!PbiZF46gCqWC6JubvBjVOEeHQBsXGkYEpa8fHBjM7zdw71xB11xUirYWDvhn2A24NoaPxIomzAIB6QWUNpwhnyH1aw$
> ).
> >>>>>
> >>>>> 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://urldefense.com/v3/__https://trustee.ietf.org/license-info/__;!!MZ3Fw45to5uY!PbiZF46gCqWC6JubvBjVOEeHQBsXGkYEpa8fHBjM7zdw71xB11xUirYWDvhn2A24NoaPxIomzAIB6QWUNpwqIFrinQ$
> ).
> >>>>>
> >>>>> *  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://urldefense.com/v3/__https://authors.ietf.org/rfcxml-vocabulary__;!!MZ3Fw45to5uY!PbiZF46gCqWC6JubvBjVOEeHQBsXGkYEpa8fHBjM7zdw71xB11xUirYWDvhn2A24NoaPxIomzAIB6QWUNpx_M9NZkw$
> >.
> >>>>>
> >>>>> *  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
> >>>>>
> >>>>> *  [e-mail] (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).
> >>>>>
> >>>>> *  [e-mail], which is a new archival mailing
> list
> >>>>>    to preserve AUTH48 conversations; it is not an active discussion
> >>>>>    list:
> >>>>>
> >>>>>   *  More info:
> >>>>>
> >>>>>
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2US__;!!MZ3Fw45to5uY!PbiZF46gCqWC6JubvBjVOEeHQBsXGkYEpa8fHBjM7zdw71xB11xUirYWDvhn2A24NoaPxIomzAIB6QWUNpzmpH6tYA$
> >>>>> xI
> >>>>> Ae6P8O4Zc
> >>>>>
> >>>>>   *  The archive itself:
> >>>>>
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!MZ3Fw45to5uY!PbiZF46gCqWC6JubvBjVOEeHQBsXGkYEpa8fHBjM7zdw71xB11xUirYWDvhn2A24NoaPxIomzAIB6QWUNpy16-hL8g$
> >>>>>
> >>>>>   *  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,
> >>>>>      [e-mail] 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://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9452.xml__;!!MZ3Fw45to5uY!PbiZF46gCqWC6JubvBjVOEeHQBsXGkYEpa8fHBjM7zdw71xB11xUirYWDvhn2A24NoaPxIomzAIB6QWUNpyA_qJ1Ng$
> >>>>>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9452.html__;!!MZ3Fw45to5uY!PbiZF46gCqWC6JubvBjVOEeHQBsXGkYEpa8fHBjM7zdw71xB11xUirYWDvhn2A24NoaPxIomzAIB6QWUNpy50XqlGQ$
> >>>>>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9452.pdf__;!!MZ3Fw45to5uY!PbiZF46gCqWC6JubvBjVOEeHQBsXGkYEpa8fHBjM7zdw71xB11xUirYWDvhn2A24NoaPxIomzAIB6QWUNpwoO7G95A$
> >>>>>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9452.txt__;!!MZ3Fw45to5uY!PbiZF46gCqWC6JubvBjVOEeHQBsXGkYEpa8fHBjM7zdw71xB11xUirYWDvhn2A24NoaPxIomzAIB6QWUNpy622snag$
> >>>>>
> >>>>> Diff file of the text:
> >>>>>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9452-diff.html__;!!MZ3Fw45to5uY!PbiZF46gCqWC6JubvBjVOEeHQBsXGkYEpa8fHBjM7zdw71xB11xUirYWDvhn2A24NoaPxIomzAIB6QWUNpx1bQUW5A$
> >>>>>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9452-rfcdiff.html__;!!MZ3Fw45to5uY!PbiZF46gCqWC6JubvBjVOEeHQBsXGkYEpa8fHBjM7zdw71xB11xUirYWDvhn2A24NoaPxIomzAIB6QWUNpx-QQ6M0g$
> (side by
> >>>>> side)
> >>>>>
> >>>>> Diff of the XML:
> >>>>>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9452-xmldiff1.html__;!!MZ3Fw45to5uY!PbiZF46gCqWC6JubvBjVOEeHQBsXGkYEpa8fHBjM7zdw71xB11xUirYWDvhn2A24NoaPxIomzAIB6QWUNpwiGX8kzg$
> >>>>>
> >>>>> The following files are provided to facilitate creation of your own
> >>>>> diff files of the XML.
> >>>>>
> >>>>> Initial XMLv3 created using XMLv2 as input:
> >>>>>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9452.original.v2v3.xml__;!!MZ3Fw45to5uY!PbiZF46gCqWC6JubvBjVOEeHQBsXGkYEpa8fHBjM7zdw71xB11xUirYWDvhn2A24NoaPxIomzAIB6QWUNpxjWCt75Q$
> >>>>>
> >>>>> XMLv3 file that is a best effort to capture v3-related format
> >>>>> updates
> >>>>> only:
> >>>>>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9452.form.xml__;!!MZ3Fw45to5uY!PbiZF46gCqWC6JubvBjVOEeHQBsXGkYEpa8fHBjM7zdw71xB11xUirYWDvhn2A24NoaPxIomzAIB6QWUNpwzLdPn5A$
> >>>>>
> >>>>>
> >>>>> Tracking progress
> >>>>> -----------------
> >>>>>
> >>>>> The details of the AUTH48 status of your document are here:
> >>>>>
> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9452__;!!MZ3Fw45to5uY!PbiZF46gCqWC6JubvBjVOEeHQBsXGkYEpa8fHBjM7zdw71xB11xUirYWDvhn2A24NoaPxIomzAIB6QWUNpw0syHLWQ$
> >>>>>
> >>>>> Please let us know if you have any questions.
> >>>>>
> >>>>> Thank you for your cooperation,
> >>>>>
> >>>>> RFC Editor
> >>>>>
> >>>>> --------------------------------------
> >>>>> RFC9452 (draft-ietf-sfc-ioam-nsh-13)
> >>>>>
> >>>>> Title            : Network Service Header (NSH) Encapsulation for
> In-situ
> >> OAM
> >>>> (IOAM) Data
> >>>>> Author(s)        : F. Brockners, Ed., S. Bhandari, Ed.
> >>>>> WG Chair(s)      : Joel M. Halpern, Jim Guichard
> >>>>>
> >>>>> Area Director(s) : Alvaro Retana, John Scudder, Andrew Alston
> >>>>>
> >>>>>
> >>>
> >>> <Mail Attachment.eml>
> >
>
>