Re: [auth48] [IAB] AUTH48: RFC-to-be 9490 <draft-iab-m-ten-workshop-02> for your review
Tommy Pauly <tpauly@apple.com> Mon, 09 October 2023 21:37 UTC
Return-Path: <tpauly@apple.com>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D459C152573 for <auth48archive@ietfa.amsl.com>; Mon, 9 Oct 2023 14:37:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Todz8d3ByA8r for <auth48archive@ietfa.amsl.com>; Mon, 9 Oct 2023 14:37:24 -0700 (PDT)
Received: from ma-mailsvcp-mx-lapp02.apple.com (ma-mailsvcp-mx-lapp02.apple.com [17.32.222.23]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C84D8C09BB4F for <auth48archive@rfc-editor.org>; Mon, 9 Oct 2023 14:37:24 -0700 (PDT)
Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by ma-mailsvcp-mx-lapp02.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPS id <0S2A009CG6PVO400@ma-mailsvcp-mx-lapp02.apple.com> for auth48archive@rfc-editor.org; Mon, 09 Oct 2023 14:37:24 -0700 (PDT)
X-Proofpoint-GUID: FRS8WDbTKyfWCUCYoFnR4SeX82PghiWV
X-Proofpoint-ORIG-GUID: FRS8WDbTKyfWCUCYoFnR4SeX82PghiWV
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.619, 18.0.980 definitions=2023-10-09_20:2023-10-09, 2023-10-09 signatures=0
X-Proofpoint-Spam-Details: rule=interactive_user_notspam policy=interactive_user score=0 malwarescore=0 adultscore=0 bulkscore=0 mlxscore=0 spamscore=0 suspectscore=0 mlxlogscore=999 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2309180000 definitions=main-2310090171
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=w/Y50A0BB2g4YYQoIBeyYGHAV+HAjg7lvriIE58KO0U=; b=Yx5hVD4iTQ3WcAgSYo06i4iRufl6DmqEV3yPqs43PFlyjjaOWakN10QEiob3h9QpMqFL KTCzXXCyTr2fG9KSPfJ8r1GmbGurHB1BTeQsdOE7gP3+VfL6Ckao0bPH0h1gvDIiKEm5 4lW+z/swGYYD0K59NbwTCLc5mYWK0ScI/XoC51Oat3fsuQ5FPJHP+scSUpJl0Wa1n4hf 8pFFl+dII7UrQpL0A6qhCRKCi9Ocbo1fWi/uNV8V5qqs8cmu+VhP5GxhE5CglL+MxZZL opC4aDk4FvqxCE7khHh6uzcJxSrmNXeflxyREtClXlzFOpKEDgrU62j8qKkbbl7qvFsd 9w==
Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPS id <0S2A00JE16Q8OGR0@rn-mailsvcp-mta-lapp01.rno.apple.com>; Mon, 09 Oct 2023 14:37:21 -0700 (PDT)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) id <0S2A00R0066VEZ00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Mon, 09 Oct 2023 14:37:20 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 8b143e8dcd3302345cbb1e94d7a0d4e3
X-Va-E-CD: 95249f1e3f2147a2f3c4f5023137d641
X-Va-R-CD: dc3d8d69e446be7bffeefdef72156622
X-Va-ID: 93ab31ec-51f3-4966-bee8-146040e3ef85
X-Va-CD: 0
X-V-A:
X-V-T-CD: 8b143e8dcd3302345cbb1e94d7a0d4e3
X-V-E-CD: 95249f1e3f2147a2f3c4f5023137d641
X-V-R-CD: dc3d8d69e446be7bffeefdef72156622
X-V-ID: aa29e2a2-6b88-42bc-b84c-4509da80d4d0
X-V-CD: 0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.619, 18.0.980 definitions=2023-10-09_20:2023-10-09, 2023-10-09 signatures=0
Received: from smtpclient.apple ([17.230.175.198]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPSA id <0S2A00AJA6Q3GP00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Mon, 09 Oct 2023 14:37:16 -0700 (PDT)
Content-type: text/plain; charset="utf-8"
MIME-version: 1.0 (Mac OS X Mail 16.0 \(3774.100.2.1.4\))
From: Tommy Pauly <tpauly@apple.com>
In-reply-to: <5a2af4f9-96af-4958-ad93-3cab6fd04b61@amsl.com>
Date: Mon, 09 Oct 2023 14:37:05 -0700
Cc: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>, RFC Errata System <rfc-editor@rfc-editor.org>, Zaheduzzaman Sarker <zahed.sarker.ietf@gmail.com>, ietf@hardakers.net, auth48archive <auth48archive@rfc-editor.org>, iab@ietf.org
Content-transfer-encoding: quoted-printable
Message-id: <ADCDB7C6-CC41-4B82-AA09-E70D35ADFC16@apple.com>
References: <20231005202118.75CAAE629D@rfcpa.amsl.com> <059D62CB-0EFC-4B06-996B-E5890B5B627F@apple.com> <5a2af4f9-96af-4958-ad93-3cab6fd04b61@amsl.com>
To: Jean Mahoney <jmahoney@amsl.com>
X-Mailer: Apple Mail (2.3774.100.2.1.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/ug47m2gq7E3F_Cez2T28-O8W-FE>
Subject: Re: [auth48] [IAB] AUTH48: RFC-to-be 9490 <draft-iab-m-ten-workshop-02> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Oct 2023 21:37:29 -0000
> On Oct 9, 2023, at 2:31 PM, Jean Mahoney <jmahoney@amsl.com> wrote: > > 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, rfc-editor@rfc-editor.org 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] That construction looks good to me, for both places. > > > We will await further word from you and your coauthor(s) regarding other AUTH48 changes and/or approval. Great! I’ll let the others reply before giving my approval here. Thanks, Tommy > > 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, rfc-editor@rfc-editor.org 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 >>> >>> * rfc-editor@rfc-editor.org (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). >>> >>> * auth48archive@rfc-editor.org, 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, >>> auth48archive@rfc-editor.org 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 >
- [auth48] AUTH48: RFC-to-be 9490 <draft-iab-m-ten-… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9490 <draft-iab-m-… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9490 <draft-iab-m-… Tommy Pauly
- Re: [auth48] AUTH48: RFC-to-be 9490 <draft-iab-m-… Jean Mahoney
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9490 <draft-… Tommy Pauly
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9490 <draft-… Wes Hardaker
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9490 <draft-… Wes Hardaker
- [auth48] [IAB Chair] Re: [IAB] AUTH48: RFC-to-be … Jean Mahoney
- Re: [auth48] [IAB Chair] Re: [IAB] AUTH48: RFC-to… Wes Hardaker
- Re: [auth48] [IAB Chair] Re: [IAB] AUTH48: RFC-to… Jean Mahoney
- Re: [auth48] [IAB] [IAB Chair] Re: AUTH48: RFC-to… Tommy Pauly
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9490 <draft-… Wes Hardaker
- Re: [auth48] [IAB] [IAB Chair] Re: AUTH48: RFC-to… Wes Hardaker
- Re: [auth48] [IAB] [IAB Chair] Re: AUTH48: RFC-to… Jean Mahoney
- Re: [auth48] [IAB] [IAB Chair] Re: AUTH48: RFC-to… Jean Mahoney
- Re: [auth48] [IAB] [IAB Chair] Re: AUTH48: RFC-to… Mallory Knodel
- Re: [auth48] [IAB] [IAB Chair] Re: AUTH48: RFC-to… Jean Mahoney
- Re: [auth48] [IAB] [IAB Chair] Re: AUTH48: RFC-to… Mirja Kuehlewind (IETF)
- Re: [auth48] [IAB] [IAB Chair] Re: AUTH48: RFC-to… Jean Mahoney
- Re: [auth48] [IAB] [IAB Chair] Re: AUTH48: RFC-to… Wes Hardaker
- [auth48] Paper references to GitHub? [was: Re: [I… Mirja Kuehlewind (IETF)
- Re: [auth48] Paper references to GitHub? [was: Re… Jean Mahoney
- Re: [auth48] Paper references to GitHub? [was: Re… Mirja Kuehlewind (IETF)
- [auth48] datatracker support of IAB workshops (wa… Jean Mahoney
- Re: [auth48] datatracker support of IAB workshops… Robert Sparks
- Re: [auth48] datatracker support of IAB workshops… Mirja Kuehlewind (IETF)
- Re: [auth48] Paper references to GitHub? [was: Re… Wes Hardaker
- Re: [auth48] [IAB] [IAB Chair] Re: AUTH48: RFC-to… Qin Wu
- Re: [auth48] Paper references to GitHub? [was: Re… Mirja Kuehlewind (IETF)
- Re: [auth48] Paper references to GitHub? [was: Re… Wes Hardaker
- Re: [auth48] Paper references to GitHub? [was: Re… Jean Mahoney
- Re: [auth48] Paper references to GitHub? [was: Re… Jean Mahoney
- Re: [auth48] Paper references to GitHub? [was: Re… Wes Hardaker
- Re: [auth48] Paper references to GitHub? [was: Re… Jean Mahoney
- Re: [auth48] Paper references to GitHub? [was: Re… Mirja Kuehlewind (IETF)
- Re: [auth48] Paper references to GitHub? [was: Re… Jean Mahoney
- Re: [auth48] [IAB] Paper references to GitHub? [w… Cindy Morgan
- Re: [auth48] [IAB] Paper references to GitHub? [w… Jean Mahoney
- Re: [auth48] [IAB] Paper references to GitHub? [w… Cindy Morgan
- Re: [auth48] [IAB] Paper references to GitHub? [w… Mirja Kuehlewind (IETF)
- Re: [auth48] [IAB] Paper references to GitHub? [w… Jean Mahoney
- Re: [auth48] [IAB] Paper references to GitHub? [w… Mirja Kuehlewind (IETF)
- Re: [auth48] [IAB] Paper references to GitHub? [w… Jean Mahoney
- Re: [auth48] [IAB Chair] Re: AUTH48: RFC-to-be 94… Jean Mahoney
- Re: [auth48] [IAB] [IAB Chair] Re: AUTH48: RFC-to… Wes Hardaker
- Re: [auth48] [IAB] [IAB Chair] Re: AUTH48: RFC-to… Jean Mahoney
- Re: [auth48] [IAB] [IAB Chair] Re: AUTH48: RFC-to… Wes Hardaker
- Re: [auth48] [IAB] [IAB Chair] Re: AUTH48: RFC-to… Jean Mahoney
- Re: [auth48] [IAB] [IAB Chair] Re: AUTH48: RFC-to… Wes Hardaker
- Re: [auth48] Paper references to GitHub? [was: Re… Mirja Kuehlewind (IETF)