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

[Greg Mirsky <[e-mail]>]

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
> >
>
>