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

[Jean Mahoney <[e-mail]>]

Tommy,

Thank you for your response. We have updated the document accordingly:

    https://www.rfc-editor.org/authors/rfc9490.txt
    https://www.rfc-editor.org/authors/rfc9490.pdf
    https://www.rfc-editor.org/authors/rfc9490.html
    https://www.rfc-editor.org/authors/rfc9490.xml

    https://www.rfc-editor.org/authors/rfc9490-diff.html
       (comprehensive diff)
    https://www.rfc-editor.org/authors/rfc9490-rfcdiff.html
       (side-by-side comprehensive diff)
    https://www.rfc-editor.org/authors/rfc9490-auth48diff.html
       (diff of updates made during AUTH48)
    https://www.rfc-editor.org/authors/rfc9490-auth48rfcdiff.html
       (side-by-side diff of updates made during AUTH48)

We have a question on 9). Please see below.


On 10/6/23 6:51 PM, Tommy Pauly wrote:
> 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)”?

[JM] Do you prefer the following construction for the reference?

    [KNODEL]   Knodel, M., "(Introduction) '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?

    Mallory Knodel. "(Introduction) 'Guidelines for
    Performing Safe Measurement on the Internet'" [KNODEL]


We will await further word from you and your coauthor(s) regarding other 
AUTH48 changes and/or approval.

Best regards,
RFC Editor/jm


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