Re: [auth48] AUTH48: RFC-to-be 9490 <draft-iab-m-ten-workshop-02> for your review

[Tommy Pauly <[e-mail]>]

Hi RFC Editor,

Thanks for you work on this! Responses are inline.

Best,
Tommy

> On Oct 5, 2023, at 1:21 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 review the guidance found at 
> <https://www.rfc-editor.org/materials/iab-format.txt> and let us know 
> if any changes are needed.
> -->
> 
> 
> 2) <!--[rfced] This document had the consensus attribute set to true, but also
> says the following. Shall the consensus attribute be set to false?
> 
> Original:
>   The views and positions documented in this report are
>   those of the expressed during the workshop by participants and do not
>   necessarily reflect IAB views and positions.
> and
>   Thus, the content of this
>   report follows the flow and dialog of the workshop but does not
>   attempt to capture a consensus.
> -->

I believe consensus should be left set to “true”. This document has consensus of the IAB as a report of what occurred at the workshop.

> 
> 3) <!--[rfced] Section 2.2.1. Please let us know how we can clarify the following
> sentence. Is the collaboration between the intermediary services or the
> support they provide?
> 
> Original:
>   Instead of encrypted communication between only two ends and passive
>   observation by all on-path elements, intermediate relays could be
>   trusted parties with limited information for the purposes of
>   collaboration between in-network intermediary services' support.
> -->

I suggest saying the following (the other authors should check):

Instead of encrypting communication between only two ends with passive observation by all on-path elements, intermediate relays could be introduced as trusted parties that get to see limited information for the purpose of collaboration between in-network intermediary services.
> 
> 
> 4) <!--[rfced] Section 2.2.3. The following sentence appears to be missing one 
> or more words between "local transmission" and "end-to-end transmission". 
> Please let us know how to update this:
> 
> Original:
>   E.g. side car information can contain additional
>   acknowledgements to enable in-network local retransmission faster
>   end-to-end retransmission by reducing the signaling round trip time.
> -->
> 

I suggest this should be “or”:

"to enable in-network local retransmission or faster end-to-end retransmission"
> 
> 
> 5) <!--[rfced] Section 2.3.1. Please help us make the following sentence
> clearer. Does "categorized into an envelope" mean "comprises"?
> 
> Original:
>   The proposed contract solution is to define a collection of
>   acceptable behaviors categorized into an envelope of different states
>   that might include IP addresses, domain names, and indicators of
>   compromise.  
> 
> Perhaps:
>   The proposed contract solution is to define a collection of
>   acceptable behaviors that comprises different states
>   that might include IP addresses, domain names, and indicators of
>   compromise. 
> -->

That seems correct to me.

> 
> 
> 6) <!--[rfced] Section 2.3.3. Is there a phrase missing in this sentence? Is the
> compromise between the "tension" and something else? Or is the compromise
> between services that offer privacy and services that offer protection?
> 
> Original:
>   These collaborative solutions may be
>   the best compromise between the tension of privacy vs protection
>   based services [PAULY]. 
> 
> Perhaps:
>   These collaborative solutions may be the
>   best compromise on services that balance privacy and protection [PAULY].
> -->

How about:

  These collaborative solutions may be
  the best compromise to resolve the the tension between privacy and
  protection-based services [PAULY]. 
> 
> 
> 7) <!--[rfced] Section 3. In the following sentence, it is not clear what kind 
> of technologies the operators are being asked to allow into their
> environments. In addition, is the phrase "environment requirements"
> correct? Please let us know how to clarify this sentence.
> 
> Original:
>   *  There is an unanswered question of whether or not network
>      operators be willing to participate and allow technologies into
>      their environment requirements in exchange for technologies that
>      prove their clients are being good net-citizens.
> -->

I’ll ask Wes to help answer this one, as I believed he had written that section.
> 
> 
> 8) <!--[rfced] We found alternate sources for both the [GRUBBS] and [KUEHLEWIND]
> references. Would you like to update these references?
> 
> [GRUBBS] https://www.usenix.org/conference/usenixsecurity22/presentation/grubbs
> [KUEHLEWIND] https://www.ericsson.com/en/blog/2022/6/relays-and-online-user-privacy
> 
> Original:
>   [GRUBBS]   Grubbs, P., Arun, A., Zhang, Y., Bonneau, J., and M.
>              Walfish, "Zero-Knowledge Middleboxes", August 2022,
>              <https://github.com/intarchboard/workshop-m-
>              ten/blob/main/papers/Grubbs-Zero-
>              Knowledge%20Middleboxes.pdf>.
> 
>   [KUEHLEWIND]
>              Kühlewind, M., Westerlund, M., Sarker, Z., and M. Ihlar,
>              "Relying on Relays", August 2022,
>              <https://github.com/intarchboard/workshop-m-
>              ten/blob/main/papers/Kuehlewind-Relying-on-Relays.pdf>.
> -->

For consistency, it might be best to have all of the references be to GitHub?
> 
> 
> 9) <!--[rfced] The [KNODEL] reference is an introduction to the pearg
> Internet-Draft [I-D.irtf-pearg-safe-internet-measurement].
> 
> Original:
>   [I-D.irtf-pearg-safe-internet-measurement]
>              Learmonth, I. R., Grover, G., and M. Knodel, "Guidelines
>              for Performing Safe Measurement on the Internet", Work in
>              Progress, Internet-Draft, draft-irtf-pearg-safe-internet-
>              measurement-08, 10 July 2023,
>              <https://datatracker.ietf.org/doc/html/draft-irtf-pearg-
>              safe-internet-measurement-08>.
> 
>   [KNODEL]   Knodel, M., "Guidelines for Performing Safe Measurement on
>              the Internet", August 2022,
>              <https://github.com/intarchboard/workshop-m-
>              ten/blob/main/papers/Knodel-Guidelines-for-Performing-
>              Safe-Measurement-on-the-Internet.pdf>.
> 
> Appendix A lists the following:
> 
>   Iain R.  Learmonth, Gurshabad Grover, Mallory Knodel. “Guidelines for
>   Performing Safe Measurement on the Internet.” (Additional rationale)
>   [KNODEL]
> 
> Perhaps [KNODEL] should be listed in the Informative References as the following:
> 
>   [KNODEL]   Knodel, M., "Additional rationale for 'Guidelines for 
>              Performing Safe Measurement on the Internet'", August 2022,
>              <https://github.com/intarchboard/workshop-m-
>              ten/blob/main/papers/Knodel-Guidelines-for-Performing-
>              Safe-Measurement-on-the-Internet.pdf>.
> 
> And Appendix A be updated to show the following:
> 
>   Iain R. Learmonth, Gurshabad Grover, Mallory Knodel. “Guidelines for
>   Performing Safe Measurement on the Internet.” [LEARMONTH]
> 
>   Mallory Knodel. "Additional rationale for 'Guidelines for 
>   Performing Safe Measurement on the Internet'" [KNODEL]
> -->

Yes, these updates seem generally good. I don’t know if it should say “(Additional rationale)”; perhaps “(Introduction)” or “(Summary)”?
> 
> 
> 10) <!--[rfced] On the [KUEHLEWIND] paper
> (https://github.com/intarchboard/workshop-m-ten/blob/main/papers/Kuehlewind-Relying-on-Relays.pdf),
> it is unclear to us whether "ANM" is part of Zaheduzzaman Sarker's name
> or is an honorific. This may impact the initial used in the Informative
> References section (currently Z.) and the name provided in Appendix A.3
> (Currently Zaheduzzaman Sarker).
> -->

This is probably best a question for Zahed, added to the thread.
> 
> 
> 11) <!--[rfced] The original URL provided for [DITTO] does not work:
> 
>   [DITTO]    Meier, R., Lenders, V., and L. Vanbever, "Ditto - WAN
>              Traffic Obfuscation at Line Rate", April 2022,
>              <https://nsg.ee.ethz.ch/fileadmin/user_upload/
>              publications/ditto_final_ndss22.pdf>.
> 
> We have found the following: 
> A landing page for the paper: https://www.ndss-symposium.org/ndss-paper/auto-draft-195/
> And also a DOI URL, which displays the PDF directly: https://doi.org/10.14722/ndss.2022.24056
> 
> Perhaps:
>   [DITTO]    Meier, R., Lenders, V., and L. Vanbever, "Ditto: WAN
>              Traffic Obfuscation at Line Rate", Network and Distributed
>              Systems Security (NDSS) Symposium, April 2022,
>              <https://doi.org/10.14722/ndss.2022.24056>.
> -->

This seems good to me.
> 
> 
> 12) <!--[rfced] Appendix A.2. The following paper does not have a reference. 
> Would you like to add one?
> 
>   Wes Hardaker. "Network Flow Management by Probability." 
> -->

Wes?
> 
> 
> 13) <!--[rfced] Appendix B. 
> a) The list of participants includes a duplication: "Michael Ackermann" and
> "Mike Ackermann". Which should be used?
> b) While we understand that some participants may wish to provide only partial
> names, is "Qiufang" actually "Qiufang Ma"?
> 
> Please review the participant list and let us know if any updates are needed.
> -->

Since Mike Ackermann lists himself as “Mike” on the paper, we can probably use that.
And yes, Qiufang is Qiufang Ma.
> 
> 
> 14) <!--[rfced] FYI, we have removed the Acknowledgments section because it was
> empty. Please let us know if any further updates are necessary.
> -->

Thank you, that should be fine.
> 
> 
> 15) <!--[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.
> 
> Please consider whether "tradition" should be updated for clarity.  While the NIST website
> <https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1>
> indicates that this term is potentially biased, it is also ambiguous.
> "Tradition" is a subjective term, as it is not the same for everyone.
> -->

Since this refers to a “tradition” in network management, I personally think this use is appropriate.
> 
> 
> Thank you.
> 
> RFC Editor/jm/ar
> 
> 
> On Oct 5, 2023, [e-mail] wrote:
> 
> *****IMPORTANT*****
> 
> Updated 2023/10/05
> 
> 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/rfc9490.xml
>  https://www.rfc-editor.org/authors/rfc9490.html
>  https://www.rfc-editor.org/authors/rfc9490.pdf
>  https://www.rfc-editor.org/authors/rfc9490.txt
> 
> Diff file of the text:
>  https://www.rfc-editor.org/authors/rfc9490-diff.html
>  https://www.rfc-editor.org/authors/rfc9490-rfcdiff.html (side by side)
> 
> 
> Tracking progress
> -----------------
> 
> The details of the AUTH48 status of your document are here:
>  https://www.rfc-editor.org/auth48/rfc9490
> 
> Please let us know if you have any questions.  
> 
> Thank you for your cooperation,
> 
> RFC Editor
> 
> --------------------------------------
> RFC9490 (draft-iab-m-ten-workshop-02)
> 
> Title            : Report from the IAB Workshop on Management Techniques in Encrypted Networks (M-TEN)
> Author(s)        : M. Knodel, W. Hardaker, T. Pauly