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

[Greg Mirsky <[e-mail]>]

Dear RFC Editor,
thank you for your thoughtful help in improving the document. I agree with
Tianran's answers and support changes he proposed. One minor note to
keywords Tianran proposed could be s/Micro Session/Micro-session/.

Regards,
Greg

On Wed, Jan 24, 2024 at 12:03 AM Tianran Zhou <[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
>
>
>