Re: [auth48] [ADs] AUTH48: RFC-to-be 9359 <draft-ietf-ippm-ioam-conf-state-10> for your review

[Greg Mirsky <[e-mail]>]

Hi Megan,
thank you for your kind consideration of my notes and for thoughtfully
addressing them. I agree with all updates and approve the current version
of the document.

Regards,
Greg

On Mon, Mar 20, 2023 at 1:10 PM Megan Ferguson <[e-mail]> wrote:

> Hi Greg and Xiao Min,
>
> Thank you for sending along these updates.  We have incorporated them into
> our files and reposted (below).  Please review these changes carefully as
> we do not make changes to the document once it has been published as an RFC.
>
> Note also that we have received a bounce message for [e-mail]
> (which is the same address we see in the datatracker for Lei Bo).  If
> anyone has a contact information update, we would appreciate it.
>
>   The files have been posted here (please refresh):
>    https://www.rfc-editor.org/authors/rfc9359.txt
>    https://www.rfc-editor.org/authors/rfc9359.pdf
>    https://www.rfc-editor.org/authors/rfc9359.html
>    https://www.rfc-editor.org/authors/rfc9359.xml
>
>   The relevant diff files have been posted here (please refresh):
>    https://www.rfc-editor.org/authors/rfc9359-diff.html (comprehensive
> diff)
>    https://www.rfc-editor.org/authors/rfc9359-rfcdiff.html (comprehensive
> rfcdiff)
>    https://www.rfc-editor.org/authors/rfc9359-auth48diff.html (all AUTH48
> changes)
>    https://www.rfc-editor.org/authors/rfc9359-lastdiff.html (last version
> to this)
>    https://www.rfc-editor.org/authors/rfc9359-lastrfcdiff.html (last
> version to this rfcdiff)
>
>  The AUTH48 status page for this document is viewable here:
>     http://www.rfc-editor.org/auth48/rfc9359
>
> Thank you.
>
> RFC Editor/mf
>
>
> > On Mar 20, 2023, at 2:43 AM, [e-mail] wrote:
> >
> > Hi Megan,
> >
> >
> >
> > Thanks a lot.
> >
> > To make this document consistent with RFC 9197, below two changes are
> suggested.
> >
> > s/Proof-of-Transit/Proof of Transit/g
> >
> > s/Pre-Allocated/Pre-allocated/g
> >
> >
> >
> > Best Regards,
> >
> > Xiao Min
> >
> > Original
> > From: MeganFerguson <[e-mail]>
> > To: Greg Mirsky <[e-mail]>;肖敏10093570;
> > Cc: [e-mail] <[e-mail]>;
> [e-mail] <[e-mail]>;[e-mail] <
> [e-mail]>;[e-mail] <[e-mail]>;
> [e-mail] <[e-mail]>;Martin Duke <
> [e-mail]>;[e-mail] <
> [e-mail]>;
> > Date: 2023年03月18日 11:18
> > Subject: Re: [ADs] AUTH48: RFC-to-be 9359
> <draft-ietf-ippm-ioam-conf-state-10> for your review
> > Greg and Xiao Min (and *ADs),
> >
> > [*ADs - please note that we will await your response to question 9 in
> our previous email prior to moving this document forward in the publication
> process.]
> >
> > Thank you for your replies and guidance.  We have updated the document
> as requested.  Please these updates carefully as we do not make updates
> once the document is published as an RFC.
> >
> >   The files have been posted here (please refresh):
> >    https://www.rfc-editor.org/authors/rfc9359.txt
> >    https://www.rfc-editor.org/authors/rfc9359.pdf
> >    https://www.rfc-editor.org/authors/rfc9359.html
> >    https://www.rfc-editor.org/authors/rfc9359.xml
> >
> >   The relevant diff files have been posted here (please refresh):
> >    https://www.rfc-editor.org/authors/rfc9359-diff.html (comprehensive
> diff)
> >    https://www.rfc-editor.org/authors/rfc9359-rfcdiff.html
> (comprehensive rfcdiff)
> >    https://www.rfc-editor.org/authors/rfc9359-auth48diff.html (AUTH48
> changes only)
> >
> >   The AUTH48 status page is viewable at:
> >    https://www.rfc-editor.org/auth48/rfc9359
> >
> > Thank you.
> >
> > RFC Editor/mf
> >
> >
> > > On Mar 9, 2023, at 8:43 PM, Greg Mirsky <[e-mail]> wrote:
> > >
> > > Hi Xiao Min,
> > > thank you for your kind consideration of my answers.
> > >
> > > Dear RFC Editor,
> > > it seems like Xiao Min and I have agreed on our responses to your
> questions. Please advise of any further steps we need to make.
> > >
> > > Regards,
> > > Greg
> > >
> > > On Thu, Mar 9, 2023 at 5:31 PM <[e-mail]> wrote:
> > > Thank you for the reply, Greg.
> > >
> > > Please see inline...
> > >
> > > Original
> > > From: GregMirsky <[e-mail]>
> > > To: [e-mail] <[e-mail]>;
> > > Cc: [e-mail] <[e-mail]>;[e-mail] <
> [e-mail]>;[e-mail] <[e-mail]>;
> [e-mail] <[e-mail]>;
> [e-mail] <[e-mail]>;
> [e-mail] <[e-mail]>;肖敏10093570;
> > > Date: 2023年03月10日 06:21
> > > Subject: Re: [ADs] AUTH48: RFC-to-be 9359
> <draft-ietf-ippm-ioam-conf-state-10> for your review
> > > Dear RFC Editor,
> > > thank you for your thoughtful questions. Please find my answers
> in-line below under the GIM>> tag. I have two alternative proposals. Please
> let me know if you have any questions.
> > >
> > > Regards,
> > > Greg
> > >
> > > On Tue, Mar 7, 2023 at 7:13 PM <[e-mail]> wrote:
> > > Dear RFC Editor,
> > >
> > >
> > >
> > > Many thanks for your effort.
> > >
> > > Please see inline...
> > >
> > > Original
> > > From: [e-mail] <[e-mail]>
> > > To: 肖敏10093570;[e-mail] <[e-mail]>;
> [e-mail] <[e-mail]>;
> > > Cc: [e-mail] <[e-mail]>;
> [e-mail] <[e-mail]>;[e-mail] <
> [e-mail]>;[e-mail] <[e-mail]
> >;[e-mail] <[e-mail]>;
> [e-mail] <[e-mail]>;
> > > Date: 2023年03月07日 11:50
> > > Subject: Re: [ADs] AUTH48: RFC-to-be 9359
> <draft-ietf-ippm-ioam-conf-state-10> for your review
> > > Authors and *ADs,
> > >
> > > [*ADs - please see question 9 below.]
> > >
> > > While reviewing this document during AUTH48, please resolve (as
> necessary) the following questions,
> > >  which are also in the XML file.
> > >
> > > 1) <!-- [rfced] We had the following questions regarding the
> document's title.
> > >
> > > a) Please note that the title of the document has been
> > >      updated as follows to more similarly match related recently
> > >      published RFCs.
> > >
> > > Original:
> > > Echo Request/Reply for Enabled In-situ OAM Capabilities
> > >
> > > Current:
> > > Echo Request/Reply for Enabled In Situ OAM (IOAM) Capabilities
> > > [XM]>>> This change looks good to me.
> > >
> > > GIM>> I agree with the proposed update of the title.
> > >
> > >
> > > b) Please review the short title of the document as "Ping" is only
> mentioned
> > > briefly in this document.
> > >
> > > Original:
> > > Ping Enabled IOAM Capabilities
> > > [XM]>>> "Ping" is used widely, so I lean to remain it as is.
> > >
> > > GIM>> "Ping" is synonymous with Echo Request/Reply and traditionally
> used as a shorter version. I think that is quite fitting for the short
> title.
> > > -->
> > >
> > >
> > >
> > > 2) <!-- [rfced] Please insert any keywords (beyond those that appear
> in the
> > > title) for use on https://www.rfc-editor.org/search.
> > > [XM]>>> IPv6, MPLS, SFC, BIER.
> > >
> > > GIM>> I agree with Xiao Min's proposal.
> > > -->
> > >
> > >
> > >
> > > 3) <!-- [rfced] FYI, to avoid run-on sentence structure, we updated
> this
> > > following paragraph (adding "and" in "... NETCONF Client, and each IOAM
> > > ...." and adding "so" in "... NETCONF Server, so complexity can be
> > > ...."). Please let us know any objections.
> > >
> > > Original:
> > >    *  When NETCONF/YANG is used in this scenario, each IOAM
> > >       encapsulating node (including the host when it takes the role of
> > >       an IOAM encapsulating node) needs to implement a NETCONF Client,
> > >       each IOAM transit and IOAM decapsulating node (including the host
> > >       when it takes the role of an IOAM decapsulating node) needs to
> > >       implement a NETCONF Server, the complexity can be an issue.
> > >       Furthermore, each IOAM encapsulating node needs to establish a
> > >       NETCONF Connection with each IOAM transit and IOAM decapsulating
> > >       node, so scalability can be an issue.
> > >
> > > Current:
> > >    *  When NETCONF/YANG is used in this scenario, each IOAM
> > >       encapsulating node (including the host when it takes the role of
> > >       an IOAM encapsulating node) needs to implement a NETCONF Client,
> > >       and each IOAM transit and IOAM decapsulating node (including the
> host
> > >       when it takes the role of an IOAM decapsulating node) needs to
> > >       implement a NETCONF Server, so complexity can be an issue.
> > >       Furthermore, each IOAM encapsulating node needs to establish a
> > >       NETCONF Connection with each IOAM transit and IOAM decapsulating
> > >       node, so scalability can be an issue.
> > > [XM]>>> No objection.
> > >
> > > GIM>> I agree with the proposed update; thank you.
> > > -->
> > >
> > >
> > >
> > > 4) <!--[rfced] This text may need some clarification.  If the
> "perhaps"
> > >      text does not convey the intended meaning, please rephrase.
> > >
> > > Original:
> > >    SoP (Size of POT) field has two bits, which means the size of
> "PktID"
> > >    and "Cumulative" data that are specified in Section 4.5 of
> [RFC9197].
> > >
> > > Perhaps:
> > >    The SoP (Size of POT) field has two bits, which means the size of
> > >    "PktID" and "Cumulative" data are those that are specified in
> > >    Section 4.5 of [RFC9197].
> > > [XM]>>> How about:
> > >
> > >    The SoP (Size of POT) field has two bits, which means the size of
> > >    "PktID" and "Cumulative" data, the two data are specified in
> > >    Section 4.5 of [RFC9197].
> > >
> > > GIM>> I would propose another editorial update:
> > > OLD TEXT:
> > >    SoP (Size of POT) field has two bits, which means the size of
> "PktID"
> > >    and "Cumulative" data that are specified in Section 4.5 of
> [RFC9197].
> > > NEW TEXT:
> > >    SoP (Size of POT) field has two bits that indicate the size of
> "PktID"
> > >    and "Cumulative" data, which are specified in Section 4.5 of
> [RFC9197].
> > > WDYT?
> > >
> > > [XM-2]>>> The new text proposed by Greg looks good to me.
> > >
> > > -->
> > >
> > >
> > >
> > > 5) <!-- [rfced] FYI - we have updated this text to use a list format
> for
> > >      the ease of the reader.  Please let us know any objections.
> > >
> > > Original:
> > >    Once the IOAM encapsulating node is triggered to discover the
> enabled
> > >    IOAM capabilities of each IOAM transit and IOAM decapsulating node,
> > >    the IOAM encapsulating node will send echo requests that include the
> > >    IOAM Capabilities Query Container.  First, with TTL equal to 1 to
> > >    reach the closest node, which may be an IOAM transit node or not.
> > >    Then with TTL equal to 2 to reach the second-nearest node, which
> also
> > >    may be an IOAM transit node or not.  And further, increasing by 1
> the
> > >    TTL every time the IOAM encapsulating node sends a new echo request,
> > >    until the IOAM encapsulating node receives an echo reply sent by the
> > >    IOAM decapsulating node, which contains the IOAM Capabilities
> > >    Response Container including the IOAM Edge-to-Edge Capabilities
> > >    Object or the IOAM End-of-Domain Object.
> > >
> > > Current:
> > >    Once the IOAM encapsulating node is triggered to discover the
> enabled
> > >    IOAM capabilities of each IOAM transit and IOAM decapsulating node,
> > >    the IOAM encapsulating node will send echo requests that include the
> > >    IOAM Capabilities Query Container as follows:
> > >
> > >    *  First, with TTL equal to 1 to reach the closest node (which may
> or
> > >       may not be an IOAM transit node).
> > >
> > >    *  Then, with TTL equal to 2 to reach the second-nearest node (which
> > >       also may or may not be an IOAM transit node).
> > >
> > >    *  Then, further increasing by 1 the TTL every time the IOAM
> > >       encapsulating node sends a new echo request, until the IOAM
> > >       encapsulating node receives an echo reply sent by the IOAM
> > >       decapsulating node (which contains the IOAM Capabilities Response
> > >       Container including the IOAM Edge-to-Edge Capabilities Object or
> > >       the IOAM End-of-Domain Object).
> > > [XM]>>> No objection. And I suggest to separate "Alternatively, if the
> IOAM encapsulating node...without TTL expiration." from the following
> paragraph, into a new paragraph.
> > >
> > > GIM>> I agree with the proposed update. And I support the update
> proposed by Xuiao Min.
> > > -->
> > >
> > >
> > >
> > > 6) <!--[rfced] We do not see "RFC Required" mentioned at
> > >
> https://www.iana.org/assignments/ioam-capabilities/ioam-capabilities.xhtml
> ..
> > >
> > > Please let us know if the registry needs an update of if the following
> text in this
> > > document needs an update.
> > >
> > > Original:
> > >    New registries in this group can be created via RFC Required process
> > >    as per [RFC8126].
> > > [XM]>>> Please remove this sentence.
> > > GIM>> I agree with Xiao Min's resolution.
> > > -->
> > >
> > >
> > > 7) <!-- [rfced] FYI, to make the hierarchy of phrases ("whether ...",
> "whether
> > > ....", and "once ...") more clear, we updated the example in the
> sentence
> > > to the following. Please let us know any objections.
> > >
> > > Original:
> > >    An implementation can also check whether the fields in received echo
> > >    requests and replies strictly conform to the specifications, e.g.,
> > >    whether the list of IOAM Namespace-IDs includes duplicate entries,
> > >    whether the received Namespace-ID is an operator-assigned or IANA-
> > >    assigned one, once a check fails, an exception event indicating the
> > >    checked field should be reported to the management.
> > >
> > > Current:
> > >    An implementation can also check whether the fields in received echo
> > >    requests and replies strictly conform to the specifications, e.g.,
> > >    whether the list of IOAM Namespace-IDs includes duplicate entries
> > >    and whether the received Namespace-ID is an operator-assigned or
> IANA-
> > >    assigned one, once a check fails, an exception event indicating the
> > >    checked field should be reported to the management.
> > > [XM]>>> No objection.
> > >
> > > GIM>> I agree with the proposed update.
> > > -->
> > >
> > >
> > >
> > > 8) <!-- [rfced] For the reference entry for [I-D.ietf-bier-ping], the
> > >      first author's name appears differently in various locations. How
> > >      may we update for accuracy and consistency?
> > >
> > > "N. Kumar" in original
> > > "N.K. Nainar" in current (xi:include)
> > > "N. Nainar" in past RFCs
> > > [XM]>>> I believe the current one is up-to-date.
> > >
> > > GIM>> I've checked published RFCs, e.g., RFC 8029. It appears that N.
> Kumar is the right form.
> > >
> > > [XM-2]>>> I checked the latest one RFC 9214, where "N. Nainar" is
> used. Considering his full name "Nagendra Kumar Nainar", I believe "N.K.
> Nainar" is up-to-date. Anyway, either one works for me. :)
> > >
> > > -->
> > >
> > >
> > >
> > > 9) <!-- [rfced] *ADs - please review and approve the changes to
> Sections
> > >      1, 2.2, 3.2, 3.2.1, 3.2.2, 3.2.3, 3.2.4, 3.2.5, and 3.2.6 that
> > >      were submitted by the authors while this document was in our
> > >      queue. They are as follows:
> > >
> > >
> > > Section 1:
> > >
> > > a)
> > > Original:
> > >       Furthermore, each IOAM encapsulating node needs to establish
> > >       NETCONF Connection with each IOAM transit and IOAM decapsulating
> > >       node, the scalability can be an issue.
> > >
> > > Updated:
> > >       Furthermore, each IOAM encapsulating node needs to establish a
> > >       NETCONF Connection with each IOAM transit and IOAM decapsulating
> > >       node, so scalability can be an issue.
> > >
> > > b)
> > > Original:
> > >    Fate sharing is a common requirement for all kinds of active OAM
> > >    packets, echo request is among them, in this document that means
> echo
> > >    request is required to traverse a path of IOAM data packet.  This
> > >    requirement can be achieved by, e.g., applying same explicit path or
> > >    ECMP processing to both echo request and IOAM data packet.
> Specific
> > >    to apply same ECMP processing to both echo request and IOAM data
> > >    packet, one possible way is to populate the same value(s) of ECMP
> > >    affecting field(s) in the echo request.
> > >
> > > Updated:
> > >    Fate sharing is a common requirement for all kinds of active OAM
> > >    packets including echo request.  In this document that means echo
> > >    request is required to traverse the path of an IOAM data packet.
> > >    This requirement can be achieved by, e.g., applying the same
> explicit
> > >    path or ECMP processing to both echo request and IOAM data packets.
> > >    Specifically, the same ECMP processing can be applied to both echo
> > >    request and IOAM data packets, by populating the same value(s) in
> > >    ECMP affecting field(s) of the packets.
> > >
> > > ......
> > >
> > > Section 2.2:
> > >
> > > Added to Abbreviations List:
> > >    SoP: Size of POT
> > >    TSF: TimeStamp Format
> > > ......
> > >
> > > Section 3.2:
> > >
> > > Original:
> > >    A list of IOAM capabilities objects (one
> > >    or more objects) which contains the enabled IOAM capabilities MUST
> be
> > >    included in this container of echo reply except the sender
> encounters
> > >    an error (e.g., no matched Namespace-ID).
> > >
> > > Updated:
> > >    A list of IOAM capabilities objects (one
> > >    or more objects) which contains the enabled IOAM capabilities MUST
> be
> > >    included in this container of echo reply unless the sender
> encounters
> > >    an error (e.g., no matched Namespace-ID).
> > >
> > > ......
> > >
> > > Sections 3.2.1, 3.2.2, 3.2.3, 3.2.4, and 3.2.5:
> > >
> > > Original:
> > >    Reserved field is reserved for future use and MUST be set to zero,
> > >    and MUST be ignored when non-zero.
> > >
> > > Updated:
> > >    Reserved field MUST be zeroed on transmission and ignored on
> receipt.
> > >
> > > ......
> > >
> > > Section 3.2.6:
> > >
> > > a)
> > > Original (in table):
> > >    Must Be Zero
> > >
> > > Updated:
> > >    Reserved
> > >
> > > b)
> > > Original:
> > >    When the IOAM
> > >    edge-to-edge function is enabled at the IOAM decapsulating node,
> it's
> > >    RECOMMENDED to include only the IOAM Edge-to-Edge Capabilities
> Object
> > >    but not the IOAM End-of-Domain Object.
> > >
> > > Updated:
> > >    When the IOAM
> > >    edge-to-edge function is enabled at the IOAM decapsulating node,
> > >    including only the IOAM Edge-to-Edge Capabilities Object but not the
> > >    IOAM End-of-Domain Object is RECOMMENDED.
> > >
> > > c)
> > > Added paragraph at end of section:
> > >    Reserved field MUST be zeroed on transmission and ignored on
> receipt.
> > >
> > > ......
> > >
> > > Acknowledgements:
> > >    Added "Donald Eastlake")
> > >
> > > Original:
> > >    The authors would like to acknowledge Tianran Zhou, Dhruv Dhody,
> > >    Frank Brockners, Cheng Li, Gyan Mishra, Marcus Ihlar, Martin Duke,
> > >    Chris Lonvick, Eric Vyncke, Alvaro Retana, Paul Wouters, Roman
> > >    Danyliw, Lars Eggert, Warren Kumari, John Scudder, Robert Wilton,
> > >    Erik Kline, Zaheduzzaman Sarker and Murray Kucherawy for their
> > >    careful review and helpful comments.
> > >
> > > Updated:
> > >    The authors would like to acknowledge Tianran Zhou, Dhruv Dhody,
> > >    Frank Brockners, Cheng Li, Gyan Mishra, Marcus Ihlar, Martin Duke,
> > >    Chris Lonvick, Eric Vyncke, Alvaro Retana, Paul Wouters, Roman
> > >    Danyliw, Lars Eggert, Warren Kumari, John Scudder, Robert Wilton,
> > >    Erik Kline, Zaheduzzaman Sarker, Murray Kucherawy, and Donald
> Eastlake
> > >    for their careful review and helpful comments.
> > > -->
> > >
> > >
> > > 10) <!--[rfced] Terminology: we had the following questions related to
> the use of terminology
> > > throughout the document.
> > >
> > > a) IOAM domain: we see "IOAM-Domain" in RFC 9197.  Please let us know
> if this term should be
> > > updated in this document.
> > > [XM]>>> Yes, this term should be updated in this document.
> > >
> > > GIM>> Thank you for pointing this out. You're correct, should use
> IOM-Domain.
> > >
> > >
> > > b) Please review the use of both "Object Header" and "object header"
> in the body of Section 3.2.
> > > Should the capping scheme be made uniform there?  Note also that we
> see "Object" capped in the first sentence of all of the 3.2.* subsections.
> Please confirm that this should not be made "object" or updated to the full
> name (e.g., in Section 3.2.6: "When the IOAM End-of-Domain Object is
> present...").
> > > [XM]>>> Please do s/Object Header/object header in the body of Section
> 3.2. Please do s/Object/the-full-name in the first sentence of all of the
> 3.2.* subsections.
> > >
> > > GIM>> It seems to me that in
> > >    Similar to the container, each object has an object header that is
> > >    used to identify the type and length of the object payload.
> > > "object header" refers to the field by its shortened name. If that is
> right, I think that capitalization is needed. WDYT?
> > >
> > > [XM-2]>>> Make sense to me. To RFC Editor, Please do s/object
> header/Object Header in the body of Section 3.2. Please do
> s/Object/the-full-name in the first sentence of all of the 3.2.*
> subsections.
> > >
> > >
> > >
> > > Cheers,
> > >
> > > Xiao Min
> > >
> > >
> > >
> > > c) Should IOAM be added here?
> > >
> > > Original:
> > >    ...the End-of-Domain Object MUST be present in the IOAM Capabilities
> > >    Response Container sent by an IOAM decapsulating node.
> > >
> > > Perhaps:
> > >    ...the IOAM End-of-Domain Object MUST be present in the IOAM
> Capabilities
> > >    Response Container sent by an IOAM decapsulating node.-->
> > > [XM]>>> Yes, IOAM should be added here.
> > > GIM>> I agree as well.
> > >
> > >
> > > Best Regards,
> > >
> > > Xiao Min
> > >
> > >
> > >
> > > Thank you.
> > >
> > > RFC Editor/st/mf
> > >
> > > *****IMPORTANT*****
> > >
> > > Updated 2023/03/06
> > >
> > > 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
> > >
> > >    *  [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://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,
> > >         [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://www.rfc-editor.org/authors/rfc9359.xml
> > >    https://www.rfc-editor.org/authors/rfc9359.html
> > >    https://www.rfc-editor.org/authors/rfc9359.pdf
> > >    https://www.rfc-editor.org/authors/rfc9359.txt
> > >
> > > Diff file of the text:
> > >    https://www.rfc-editor.org/authors/rfc9359-diff.html
> > >    https://www.rfc-editor.org/authors/rfc9359-rfcdiff.html (side by
> side)
> > >
> > > Diff of the XML:
> > >    https://www.rfc-editor.org/authors/rfc9359-xmldiff1.html
> > >
> > > The following files are provided to facilitate creation of your own
> > > diff files of the XML.
> > >
> > > Initial XMLv3 created using XMLv2 as input:
> > >    https://www.rfc-editor.org/authors/rfc9359.original.v2v3.xml
> > >
> > > XMLv3 file that is a best effort to capture v3-related format updates
>
> > > only:
> > >    https://www.rfc-editor.org/authors/rfc9359.form.xml
> > >
> > >
> > > Tracking progress
> > > -----------------
> > >
> > > The details of the AUTH48 status of your document are here:
> > >    https://www.rfc-editor.org/auth48/rfc9359
> > >
> > > Please let us know if you have any questions.
> > >
> > > Thank you for your cooperation,
> > >
> > > RFC Editor
> > >
> > > --------------------------------------
> > > RFC9359 (draft-ietf-ippm-ioam-conf-state-10)
> > >
> > > Title            : Echo Request/Reply for Enabled In-situ OAM
> Capabilities
> > > Author(s)        : X. Min, G. Mirsky, L. Bo
> > > WG Chair(s)      : Marcus Ihlar, Tommy Pauly
> > > Area Director(s) : Martin Duke, Zaheduzzaman Sarker
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
>
>