Re: [auth48] AUTH48: RFC-to-be 9533 <draft-ietf-ippm-otwamp-on-lag-08> for your review

[Greg Mirsky <[e-mail]>]

Hi Megan,
thank you for your thoughtful help in improving the document. I agree and
support all the updates.

Regards,
Greg

On Fri, Jan 26, 2024 at 9:04 AM Megan Ferguson <[e-mail]> wrote:

> All,
>
> Thank you for your replies.  Sounds like leaving the “micro” terms as they
> were will work.
>
> We have updated the AUTH48 status page with all of the approvals we have
> received thus far:
>
> https://www.rfc-editor.org/auth48/rfc9533
>
> Once we have approval from Greg, this should be good to go.
>
> Thank you.
>
> RFC Editor/mf
>
> > On Jan 25, 2024, at 6:07 PM, [e-mail] wrote:
> >
> > Hello Greg and all,
> >
> > Since the current wording is consistent and concise, and Greg can live
> with it, I prefer the current wording.
> > Many thanks to our editor Megan and coauthor Greg.
> >
> > Best Regards,
> > Zhenqiang Li
> > China Mobile
> > [e-mail]
> >
> > From: Greg Mirsky
> > Date: 2024-01-26 03:44
> > To: Megan Ferguson
> > CC: Rakesh Gandhi (rgandhi); Tianran Zhou; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; Zhukeyi(Kaiyin,Datacom Standard&Patent)
> > Subject: Re: AUTH48: RFC-to-be 9533 <draft-ietf-ippm-otwamp-on-lag-08>
> for your review
> > Hi Megan,
> > your thorough analysis is exceptional, thank you! I see the situation
> more clearly now. I added my proposals below mapping to all open cases:
> > micro sessions -> micro-sessions
> > micro OWAMP/TWAMP/STAMP session -> OWAMP/TWAMP/STAMP micro-session
> > micro OWAMP/TWAMP/STAMP-Test -> OWAMP/TWAMP/STAMP-Test micro-session
> > micro OWAMP/TWAMP-Control -> OWAMP/TWAMP-Control of a micro-session
> > micro none/OWAMP/TWAMP/STAMP Session-Sender -> none/OWAMP/TWAMP/STAMP
> Session-Sender of a micro-session
> > micro none/TWAMP/STAMP Session-Reflector -> none/TWAMP/STAMP
> Session-Reflector of a micro-session
> > micro OWAMP Session-Reciever-> OWAMP Session-Receiver of a micro-session
> >
> > If other authors prefer current wording, I can live with that.
> >
> > Regards,
> > Greg
> >
> > On Thu, Jan 25, 2024 at 10:59 AM Megan Ferguson <[e-mail]>
> wrote:
> > Hi Greg,
> >
> > Thanks for raising this question.
> >
> > Currently, we see “micro" appearing with a hyphen in names of fields and
> TLVs.  The open form is used when talking about the sessions generally.
> So, in this way, the use is consistent.
> >
> > Current use of “micro" looks like the following in RFCs-to-be 9533 and
> 9534:
> >
> > The following are open:
> > -----------------------
> > micro sessions
> > micro OWAMP session
> > micro TWAMP session
> > micro STAMP session
> > micro OWAMP-Test
> > micro TWAMP-Test
> > micro STAMP-Test
> > micro TWAMP-Control
> > micro OWAMP-Control
> > micro Session-Sender
> > micro Session-Reflector
> > micro TWAMP Session-Sender
> > micro OWAMP Session-Sender
> > micro STAMP Session-Sender
> > micro OWAMP Session-Receiver
> > micro TWAMP Session-Reflector
> > micro STAMP Session-Reflector
> >
> > While the following are hyphenated:
> > ----------------------------------
> > Micro-session ID field
> > Micro-session ID TLV
> > Sender Micro-session ID field
> > Reflector Micro-session ID field
> >
> >
> > That said, if we change “micro session” to “micro-session”:
> >
> > -we would still see “micro" used as a standalone instead of a combining
> form in the other instances listed above.  Hyphenating “micro" in those
> other instances above may not actually be helpful to the reader due to
> length and possible capping confusion (e.g.,
> “micro-STAMP-Session-Reflector” and “micro-Session-Sender” vs.
> “micro-session”).
> >
> > -would we need to change “micro OWAMP session” to “OWAMP micro-session”
> (same for TWAMP and STAMP)? If so, things get kind of strange with “micro
> OWAMP Session-Sender” (i.e., is it really “OWAMP micro-session
> Session-Sender)?
> >
> > With the above info/concerns, please let us know how you’d like to
> proceed.
> > Thank you.
> >
> > RFC Editor/mf/jm
> >
> >
> > > On Jan 24, 2024, at 1:33 PM, Greg Mirsky <[e-mail]>
> wrote:
> > >
> > > Dear, Megan et al.,
> > > I was reviewing this AUTH48 RFC-to-be 9533 and noticed that there are
> two forms: "micro-session" and "micro session". Checked back AUTH48
> RFC-to-be-9534 to realize that both forms are used there as well. I think
> that it would be helpful to converge on using one form in both documents.
> Personally, I slightly prefer the "micro-session" form, but I can live with
> the other. WDYT?
> > >
> > > Regards,
> > > Greg
> > >
> > > On Wed, Jan 24, 2024 at 10:27 AM Megan Ferguson <[e-mail]>
> wrote:
> > > Hi Rakesh,
> > >
> > > Thanks for sending this along.  We’ve added this update to the current
> version.
> > >
> > >   The files have been posted here (please refresh):
> > >    https://www.rfc-editor.org/authors/rfc9533.txt
> > >    https://www.rfc-editor.org/authors/rfc9533.pdf
> > >    https://www.rfc-editor.org/authors/rfc9533.html
> > >    https://www.rfc-editor.org/authors/rfc9533.xml
> > >
> > >   The diff files have been posted here (please refresh):
> > >    https://www.rfc-editor.org/authors/rfc9533-diff.html (all changes)
> > >    https://www.rfc-editor.org/authors/rfc9533-rfcdiff.html (all
> changes side-by-side)
> > >    https://www.rfc-editor.org/authors/rfc9533-auth48diff.html (AUTH48
> changes only)
> > >
> > > Thank you.
> > >
> > > RFC Editor/mf
> > >
> > >
> > > > On Jan 24, 2024, at 11:16 AM, Rakesh Gandhi (rgandhi) <
> [e-mail]> wrote:
> > > >
> > > > Thanks Megan and authors for the review and edits.
> > > >
> > > > One minor comment:
> > > > Could you please update my affiliate to - Cisco Systems, Inc.
> > > >
> > > > Thanks,
> > > > Rakesh
> > > >
> > > >
> > > > From: Megan Ferguson <[e-mail]>
> > > > Date: Wednesday, January 24, 2024 at 12:55 PM
> > > > To: Tianran Zhou <zhoutianran=[e-mail]>
> > > > Cc: [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>,
> Rakesh Gandhi (rgandhi) <[e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>,
> Zhukeyi(Kaiyin,Datacom Standard&Patent) <[e-mail]>
> > > > Subject: Re: AUTH48: RFC-to-be 9533
> <draft-ietf-ippm-otwamp-on-lag-08> for your review
> > > >
> > > > Tianran,
> > > >
> > > > Thank you for the prompt reply!  We have updated the document based
> on your responses.
> > > > Please review carefully as we do not make updates once the document
> is published.
> > > >
> > > >   The files have been posted here (please refresh):
> > > >    https://www.rfc-editor.org/authors/rfc9533.txt
> > > >    https://www.rfc-editor.org/authors/rfc9533.pdf
> > > >    https://www.rfc-editor.org/authors/rfc9533.html
> > > >    https://www.rfc-editor.org/authors/rfc9533.xml
> > > >
> > > >   The diff files have been posted here (please refresh):
> > > >    https://www.rfc-editor.org/authors/rfc9533-diff.html (all
> changes)
> > > >    https://www.rfc-editor.org/authors/rfc9533-rfcdiff.html (all
> changes side-by-side)
> > > >    https://www.rfc-editor.org/authors/rfc9533-auth48diff.html
> (AUTH48 changes only)
> > > >
> > > > We will await approvals from each author listed at the AUTH48 status
> page prior to moving
> > > > this document forward in the publication process:
> > > >
> > > > https://www.rfc-editor.org/auth48/rfc9533
> > > >
> > > > Thank you.
> > > >
> > > > RFC Editor/mf
> > > >
> > > > > On Jan 24, 2024, at 1:03 AM, Tianran Zhou <zhoutianran=
> [e-mail]> wrote:
> > > > >
> > > > > Hi Editor,
> > > > >
> > > > > Thanks very much for this revision.
> > > > > Please see in line with my confirmation.
> > > > >
> > > > > Best,
> > > > > Tianran
> > > > >
> > > > > -----Original Message-----
> > > > > From: [e-mail] [mailto:[e-mail]]
>
> > > > > Sent: Wednesday, January 24, 2024 2:45 AM
> > > > > To: [e-mail]; Tianran Zhou <[e-mail]>;
> [e-mail]; [e-mail]; [e-mail]
> > > > > Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> > > > > Subject: Re: AUTH48: RFC-to-be 9533
> <draft-ietf-ippm-otwamp-on-lag-08> for your review
> > > > >
> > > > > Authors,
> > > > >
> > > > > 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 related to the
> document's
> > > > >     title:
> > > > >
> > > > > a) Please note that we would like to update the title of the
> document as follows:
> > > > >
> > > > > -Remove abbreviations for brevity/continuity (they are each
> expanded in the Abstract)
> > > > >
> > > > > -Reword the title to clarify the slash.
> > > > >
> > > > > Original:
> > > > > One-way/Two-way Active Measurement Protocol Extensions for
> Performance Measurement on LAG
> > > > >
> > > > > Perhaps:
> > > > > One-Way and Two-Way Active Measurement Protocol Extensions for
> Performance Measurement on a Link Aggregation Group
> > > > >
> > > > > b) Regarding the short/abbreviated title (that appears in the
> running header of the pdf): there was enough room to fit both OWAMP and
> TWAMP, so we have updated as follows.  Please let us know any objections.
> > > > >
> > > > > Original:
> > > > > O/TWAMP PM on LAG
> > > > >
> > > > > Current:
> > > > > OWAMP/TWAMP PM on LAG
> > > > > -->
> > > > >
> > > > > ZTR> Agreed.
> > > > >
> > > > > 2) <!-- [rfced] Please insert any keywords (beyond those that
> appear in the title) for use on https://www.rfc-editor.org/search. -->
> > > > >
> > > > > ZTR> TWAMP, OWAMP, Performance Measurement, LAG, Micro Session
> > > > >
> > > > > 3) <!-- [rfced] Section 1. We would like to clarify the use of
> "tuple" in
> > > > >     the sentences below and make its use more similar to uses in
> > > > >     other RFCs:
> > > > >
> > > > > Current:
> > > > > With either method, one test session over the LAG can measure the
> performance of a member link with fixed five tuples.  Or it can measure an
> average of some/all member links of the LAG by varying the five tuples.
> > > > >
> > > > > Perhaps:
> > > > > With either method, one test session over the LAG can measure the
> performance of a member link using its fixed 5-tuples, or it can measure an
> average of some or all member links of the LAG by specifying their 5-tuples.
> > > > >
> > > > > -->
> > > > >
> > > > > ZTR> May revise like Greg's suggestion on RFC-to-be 9534
> (draft-ietf-ippm-stamp-on-lag-06), as follows:
> > > > > With either method, one test session over the LAG can be used to
> measure the performance of a member link using specially-constructed
> 5-tuple. The session can be used to measure an average of some or all
> member links of the LAG by varying one or more elements  of that 5-tuple.
> > > > >
> > > > >
> > > > > 4) <!--[rfced] In the following text, is the redundant phrase "of
> a LAG"
> > > > >     and "of the LAG" confusing?  Might a rephrase here be easier to
> > > > >     parse?  If our suggestion does not capture your intent, please
> > > > >     suggest another rephrase.
> > > > >
> > > > > Original:
> > > > >   All micro sessions of a LAG share the same Sender IP Address and
> > > > >   Receiver IP Address of the LAG.
> > > > >
> > > > > Perhaps A:
> > > > >   All micro sessions of a LAG share the same Sender IP Address and
> > > > >   Receiver IP Address.
> > > > >
> > > > > Perhaps B:
> > > > >   All micro sessions share the LAG's same Sender IP Address and
> > > > >   Receiver IP Address.
> > > > > -->
> > > > >
> > > > > ZTR> A is preferred.
> > > > >
> > > > > 5) <!--[rfced] This document has a sentence very similar to one in
> > > > >     RFC-to-be 9534 (draft-ietf-ippm-stamp-on-lag-06).  May we
> update
> > > > >     this document to match the use in that document (i.e., layer
> becomes
> > > > >     port)?
> > > > >
> > > > > Original:
> > > > > As for the UDP layer, the micro
> > > > > sessions may share the same Sender Port and Receiver Port...
> > > > >
> > > > > Perhaps:
> > > > > As for the UDP port, the micro
> > > > > sessions may share the same Sender Port and Receiver Port...
> > > > > -->
> > > > >
> > > > > ZTR> Agreed.
> > > > >
> > > > > 6) <!--[rfced] We had a few questions about the paragraph
> immediately
> > > > >     following Figure 3.
> > > > >
> > > > > a) Should we update this text to make "field" plural?  Note this
> question also applies to the text following Figure 5 in Section 4.2.3.
> > > > >
> > > > > Original:
> > > > > Except for the Sender/Reflector Micro-session ID field,...
> > > > >
> > > > > Perhaps:
> > > > > Except for the Sender and Reflector Micro-session ID fields,...
> > > > >
> > > > > Or perhaps:
> > > > > Except for the Sender Micro-session ID field and the Reflector
> Micro-session ID field,...
> > > > >
> > > > > ZTR> I prefer the later one.
> > > > >
> > > > > b) The citations in the text below are somewhat
> convoluted/stacked. How can something be (basically) "..defined in Section
> 4.1.2 of [RFC5357]...which is defined in Section 4.1.2 of [RFC4656]...so it
> follows Section 4.1.2 of [RFC5357]"?  Please clarify.
> > > > >
> > > > > Original:
> > > > > ...all the other fields are the same as defined in Section 4.1.2
> of TWAMP [RFC5357], which is defined in Section 4.1.2 of OWAMP [RFC4656].
> > > > > Therefore, it follows the same procedure and guidelines as defined
> in Section 4.1.2 of TWAMP [RFC5357].
> > > > >
> > > > > Perhaps:
> > > > > ...all the other fields depecited in Figure 3 are the same as
> defined for OWAMP in Section 4.1.2 of [RFC4656], which is further built on
> for TWAMP in Section 4.1.2 of [RFC5357]; the same procedure and guidelines
> defined in Section 4.1.2 of [RFC5357] apply.
> > > > >
> > > > > c) The text before Figure 2 seems very similar to the text we
> point out in b) above.  Should this text be made more similar (i.e., Section
> > > > > 4.1.2 of RFC 5357 seems to build on Section 4.1.2 of RFC 4656 as
> well, right?)?
> > > > >
> > > > > Original:
> > > > > The micro TWAMP Session-Sender packet format is based on the TWAMP
> Session-Sender packet format as defined in Section 4.1.2 of [RFC5357].
> > > > > Two new fields (Sender Micro-session ID and Reflector Micro-session
> > > > > ID) are added to carry the LAG member link identifiers.
> > > > >
> > > > > Perhaps:
> > > > > The micro TWAMP Session-Sender packet format is based on the TWAMP
> Session-Sender packet format described in Section 4.1.2 of [RFC5357], which
> is based on the OWAMP format in Section 4.1.2 of [RFC4656].  Two new fields
> (Sender Micro-session ID and Reflector Micro-session ID) are added to carry
> the LAG member link identifiers.
> > > > >
> > > > > Note: for b) and c) above, we could also simply point the reader
> to Section 4.1.2 of RFC 5357 and let them follow the citations in that
> document to RFC 4656 (i.e., remove mentions of RFC 4656).
> > > > > -->
> > > > >
> > > > > ZTR> I agree with the Note. For both b and c, we can simplify the
> description. Your interpretation is correct. Section 4.1.2 of TWAMP
> [RFC5357] does not actually gives the specification, it just refers to
> Section 4.1.2 of OWAMP [RFC4656].
> > > > >
> > > > > 7) <!--[rfced] For Figures 4 and 5, we note that the "bit ruler"
> at the
> > > > >     top is aligned differently than appears in Figures 2 and 3.  We
> > > > >     note that these figures seem to be copies of the figures in
> > > > >     Section 4.2.1 of RFC 5357.  May we adjust Figures 4 and 5 to
> match
> > > > >     Figures 2 and 3?-->
> > > > >
> > > > >
> > > > > ZTR> Yes, you are right. We should shift the bit ruler. We adjust
> Figures 4 and 5 to match Figures 2 and 3.
> > > > >
> > > > > 8) <!--[rfced] We had two questions based on reviewing Figure 5:
> > > > >
> > > > > a) In RFC 5357, the figure that Figure 5 is based on is introduced
> with "For authenticated and encrypted modes".  Please confirm that this
> document should use only "For authenticated mode".
> > > > >
> > > > > b) We note that the figure in RFC 5357 uses "MBZ (6 octets)"
> following "Error Estimate" while this document does not mention the number
> of octets in that position (but does mention octet counts for the other two
> MBZ entries).  Please review if an update should be made.
> > > > >
> > > > > -->
> > > > >
> > > > > ZTR> For a), it should be "authenticated and encrypted modes", not
> only figure 5, but also figure 3.
> > > > >           For b), no need for update. The proposal just uses the
> later 4 octet for Sender Micro-session ID and Reflector Micro-session ID.
> > > > >
> > > > > 9) <!--[rfced] [IEEE802.1AX] 802.1AX-2008 has been superseded by
> 802.1AX-2014. Would you like to update the reference?
> > > > >
> > > > > Current:
> > > > >   [IEEE802.1AX]
> > > > >              IEEE, "IEEE Standard for Local and metropolitan area
> > > > >              networks - Link Aggregation", IEEE Std 802.1AX-2008,
> > > > >              DOI 10.1109/IEEESTD.2008.4668665, November 2008,
> > > > >              <https://ieeexplore.ieee.org/document/4668665>.
> > > > > -->
> > > > >
> > > > > ZTR> I checked the IEEE802.1AX standard. The latest one is
> 802.1AX-2020.  I would like to update the reference information as follows:
> > > > > IEEE, "IEEE Standard for Local and Metropolitan Area Networks -
> Link Aggregation", IEEE Std 802.1AX-2020, DOI 10.1109/IEEESTD.2020.9105034,
> May 2020, <https://ieeexplore.ieee.org/document/9105034>.
> > > > >
> > > > > 10) <!--[rfced] Please note that we have removed the reference
> entry for
> > > > >     RFC 9256 as we see no corresponding citation in the document.
> > > > >     Please review and let us know any objections.-->
> > > > >
> > > > > ZTR> Agreed.
> > > > >
> > > > > 11) <!-- [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.
> > > > >
> > > > > Note that our script did not flag any words in particular, but
> this should still be reviewed as a best practice.
> > > > >
> > > > > -->
> > > > >
> > > > > ZTR> I don't find any updates.
> > > > >
> > > > > 12) <!-- [rfced] We had the following questions about terminology
> as it
> > > > >     appeared throughout the document:
> > > > >
> > > > > Please let us know if the following instance should be made "test"
> (lowercase) or "OWAMP-Test".
> > > > >
> > > > > Original:
> > > > > If there is no such a session, the Test packet MUST be discarded.
> > > > >
> > > > > Perhaps A:
> > > > > If there is no such a session, the test packet MUST be discarded.
> > > > >
> > > > > Perhaps B:
> > > > > If there is no such a session, the OWAMP-Test packet MUST be
> discarded.
> > > > > -->
> > > > >
> > > > > ZTR> A is preferred.
> > > > >
> > > > > Thank you.
> > > > >
> > > > > RFC Editor/mf
> > > > >
> > > > > *****IMPORTANT*****
> > > > >
> > > > > Updated 2024/01/23
> > > > >
> > > > > 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/rfc9533.xml
> > > > >   https://www.rfc-editor.org/authors/rfc9533.html
> > > > >   https://www.rfc-editor.org/authors/rfc9533.pdf
> > > > >   https://www.rfc-editor.org/authors/rfc9533.txt
> > > > >
> > > > > Diff file of the text:
> > > > >   https://www.rfc-editor.org/authors/rfc9533-diff.html
> > > > >   https://www.rfc-editor.org/authors/rfc9533-rfcdiff.html (side
> by side)
> > > > >
> > > > > Diff of the XML:
> > > > >   https://www.rfc-editor.org/authors/rfc9533-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/rfc9533.original.v2v3.xml
> > > > >
> > > > > XMLv3 file that is a best effort to capture v3-related format
> updates
> > > > > only:
> > > > >   https://www.rfc-editor.org/authors/rfc9533.form.xml
> > > > >
> > > > >
> > > > > Tracking progress
> > > > > -----------------
> > > > >
> > > > > The details of the AUTH48 status of your document are here:
> > > > >   https://www.rfc-editor.org/auth48/rfc9533
> > > > >
> > > > > Please let us know if you have any questions.
> > > > >
> > > > > Thank you for your cooperation,
> > > > >
> > > > > RFC Editor
> > > > >
> > > > > --------------------------------------
> > > > > RFC9533 (draft-ietf-ippm-otwamp-on-lag-08)
> > > > >
> > > > > Title            : One-way/Two-way Active Measurement Protocol
> Extensions for Performance Measurement on LAG
> > > > > Author(s)        : Z. Li, T. Zhou, J. Guo, G. Mirsky, R. Gandhi
> > > > > WG Chair(s)      : Marcus Ihlar, Tommy Pauly
> > > > > Area Director(s) : Martin Duke, Zaheduzzaman Sarker
> > > >
> > >
>
>