Re: [auth48] [ISE] Re: AUTH48: RFC-to-be 9446 <draft-farrell-tenyearsafter-05> for your review

["Independent Submissions Editor (Eliot Lear)" <[e-mail]>]

Hi RFC Editor

> 3) <!-- [rfced] Abstract. Elliot, given the following in the Acknowledgments section: "that of course doesn't mean that they necessarily agree with the text", should the Abstract or the Introduction have a disclaimer such as "The views expressed in this memo are those of the authors"?
> -->
> 

I am ordering this from a policy perspective.  It is a matter of whether others, especially those who don’t read many RFCs might be led to believe that the authors are speaking for others.  I don’t think that’s likely in this case, but I will consult others to confirm. 


> 
> 4) <!-- [rfced] Introduction. Does clarifying what caused the sea change in the suggested text below improve the readability of the following sentence?
> 
> Original:
>   The breathtaking scope of the operations
>   shocked the Internet technical community that was reflected in a sea
>   change within the IETF, IAB, and other standards organizations.
> 
> Perhaps:
>   The breathtaking scope of the operations
>   shocked the Internet technical community, and this shock caused a sea
>   change within the IETF, IAB, and other standards organizations.
> -->

I think it’s a bit verbose, but that sentence could stand some improvement. So how about this:

>   The breathtaking scope of the operations
>   shocked the Internet technical community and resulted in a sea
>   change within the IETF, IAB, and other standards organizations.

Thanks and regards,

Eliot

> 
> 
> 5) <!--[rfced] Section 2. Please consider how the passage regarding Jacob Appelbaum could be improved by providing more details.  Was Appelbaum's work with Poitras the films, "Citizenfour" and "Risk"?  The clause "who had not yet been accused of sexual assault by multiple women" seems unnecessary here. Should it be dropped?
> 
> Is there a reference that can be added to support the claim that Appelbaum received the implant catalog from someone besides Snowden? If no supporting references can be added, could the passage instead focus on Appelbaum's reporting and the impact it had? Perhaps add a reference to <https://www.spiegel.de/international/world/the-nsa-uses-powerful-toolbox-in-effort-to-spy-on-global-networks-a-940969.html> or <https://www.spiegel.de/international/world/nsa-secret-toolbox-ant-unit-offers-spy-gadgets-for-every-need-a-941006.html>. Or perhaps the focus should be on the implant catalog and your analysis <https://www.schneier.com/tag/exploit-of-the-day/>?
> 
> Original:
> 
>   Jake Appelbaum, who
>   had not yet been accused of sexual assault by multiple women, was
>   working with Poitras.  He partnered with Spiegel to release an
>   implant catalog from the NSA’s Tailored Access Operations group.  To
>   this day, I am convinced that that document was not in the Snowden
>   archives: that Jake got it somehow, and it was released with the
>   implication that it was from Edward Snowden.
> --> 
> 
> 
> 6) <!-- [rfced] Section 2. Please provide expansions for the conference acronyms in the sentence below:
> 
> Current:
>   When I got back from Rio, I gave talks at a private conference in
>   Woods Hole, the Berkman Center at Harvard, something called the
>   Congress and Privacy and Surveillance in Geneva, events at both CATO
>   and New America in DC, an event at the University of Pennsylvania, an
>   event at EPIC, a "Stop Watching Us" rally in DC, the RISCS conference
>   in London, the ISF in Paris 
> -->
> 
> 
> 7) <!-- [rfced] Section 2. Would you like to provide a short list of examples here, or should the phrase "for example" be removed from the last sentence of the paragraph?
> 
> Original:
>   What struck me at the IETF was the indignation in the room, and the
>   calls to action.  And there was action, across many fronts.  We
>   technologists did a lot to help secure the Internet, for example.
> -->
> 
> 
> 8) <!-- [rfced] Section 3. Does rewording the following to focus on IETF participants improve the readability of the sentence?
> 
> Original:
>   As for the IETF's reaction, informal meetings during the July 2013
>   IETF meeting in Berlin indicated that IETF participants considered
>   that these revelations showed that we needed to do more to improve
>   the security and privacy properties of IETF protocols ...
> 
> Perhaps:
>   As for the IETF's reaction, IETF participants met informally during 
>   the July 2013 IETF meeting in Berlin to discuss these revelations,
>   which showed that we needed to do more to improve the security and 
>   privacy properties of IETF protocols ...
> -->
> 
> 
> 9) <!-- [rfced] Section 4. Does the following sentence say that policies and technical means have not been used to positively impact human rights and that the Snowden revelations didn't revolutionize the use of policies and technical means to do so? To whom does "our" refer to?   
> 
> Original:
>   Snowden revelations did not have a
>   revolutionary effect on our approach towards not using policies and
>   technical means that have an effect on human rights, such as freedom
>   of expression, freedom of association and assembly and privacy. 
> 
> Possibly:
>   The Snowden revelations did not revolutionize the use of policies
>   a technical means to support human rights such as freedom
>   of expression, freedom of association and assembly, and privacy. 
> -->
> 
> 
> 10) <!-- [rfced] Section 4. FYI, the first sentence below is a fragment. Please let us know how to update it.  
> 
> Original:
>   A range of European Union laws that aims to
>   address online safety or concentration of data.  There are many more
>   regulations that have an impact on the Internet.  
> 
> Perhaps:
>   A range of European Union laws aims to
>   address online safety or concentration of data. There are many more
>   regulations that have an impact on the Internet. 
> -->
> 
> 
> 11) <!-- [rfced] Section 4. Does the following suggestion improve the readability of the passage?
> 
> Original:
>   It might have also expedited and helped with
>   more easily convening the Human Rights Protocol Considerations
>   research group in the Internet Research Task Force (IRTF).  Co-
>   chaired by Niels ten Oever (who worked at Article 19 at the time) and
>   Internet governance activist Avri Doria, the Internet Research Task
>   Force in July 2015 chartered a Research Group on "Human Rights
>   Protocol Considerations" (the HRPC RG).  The charter of the HRPC RG
>   stated that the group was established: "to research whether standards
>   and protocols can enable, strengthen or threaten human rights, as
>   defined in the UDHR and the International Covenant on Civil and
>   Political Rights (ICCPR)."
> 
> Perhaps (removing some redundant text, clarifying that ten Oever and 
> Doria co-chaired the RG originally, and expanding UDHR):
>   It might have also expedited and helped with 
>   more easily convening the Human Rights Protocol Considerations 
>   Research Group (HRPC RG) in the Internet Research Task Force (IRTF) 
>   in July 2015. The HRPC RG was originally co-chaired by Niels ten 
>   Oever (who worked at Article 19 at the time) and Internet governance 
>   activist Avri Doria. The charter of the HRPC RG states that the group 
>   was established: "to research whether standards and protocols can 
>   enable, strengthen, or threaten human rights, as defined in the 
>   Universal Declaration of Human Rights (UDHR) and the International 
>   Covenant on Civil and Political Rights (ICCPR)." 
> -->
> 
> 
> 12) <!-- [rfced] Section 4. Please help us clarify the following sentence.  Does DoH contribute to the fight against censorship? 
> 
> Original:
>   For instance, we still have doubts about implementing DNS over HTTPS
>   without seriously considering its contributions to fight with
>   censorship and bring encryption to DNS queries. 
> -->
> 
> 
> 13) <!-- [rfced] Section 5.1. Regarding the following note to the RFC Editor:
> 
>   Also, the authors have requested that you provide specific guidance on 
>   the spelling of arabic names, specifically those in the following 
>   sentence:
> 
>   In the 9th century, Abu Yusuf Ya’qub ibn ‘Ishaq aṣ-Ṣabbah al-
>   Kindh developed and wrote about frequency analysis as a way to crack
>   ciphers [Borda2011],[Kahn1996].
> 
> Our research indicates that the following is the more typical spelling
> found in English, and we have updated the document accordingly:
> 
>   Abū Yūsuf Yaʻqūb ibn ʼIsḥāq aṣ-Ṣabbāḥ al-Kindī
> -->
> 
> 
> 14) <!-- [rfced] Section 5.2. Does the following update to reword "that that" improve the readability of the sentence?
> 
> Original:
>   NSA denied tampering with the design; a
>   Senate investigating committee found that that was correct...
> 
> Perhaps:
>   NSA denied tampering with the design; a
>   Senate investigating committee found that assertion to be 
>   correct... 
> -->
> 
> 
> 15) <!-- [rfced] Informative References. FYI, we have provided proceedings information for the following. Please let us know if any updates are necessary.
> 
> Original:
>   [LE]       Aas, J., Barnes, R., Case, B., Durumeric, Z., Eckersley,
>              P., Flores-López, A., Halderman, A., Hoffman-Andrews, J.,
>              Kasten, J., Rescorla, E., Schoen, S. D., and B. Warren,
>              "Let's Encrypt - an automated certificate authority to
>              encrypt the entire web", 2019,
>              <https://dl.acm.org/doi/pdf/10.1145/3319535.3363192>.
> 
> Current: 
>   [LE]       Aas, J., Barnes, R., Case, B., Durumeric, Z., Eckersley,
>              P., Flores-López, A., Halderman, A., Hoffman-Andrews, J.,
>              Kasten, J., Rescorla, E., Schoen, S. D., and B. Warren,
>              "Let's Encrypt: An Automated Certificate Authority to
>              Encrypt the Entire Web", CCS '19: Proceedings of the 2019 
>              ACM SIGSAC Conference on Computer and Communications 
>              Security, November 2019,
>              <https://dl.acm.org/doi/pdf/10.1145/3319535.3363192>.
> -->
> 
> 
> 16) <!-- [rfced] Informative References. We note that the URLs provided for ACM publications are inconsistent. Some point to acm.org; others point to personal websites. May be update the URLs to point to acm.org? The PDFs are freely available from that site.
> 
> Original:
>   [Adrian2015]
>              Adrian, D., Bhargavan, K., Durumeric, Z., Gaudry, P.,
>              Green, M., Halderman, J. A., and N. Heninger, "Imperfect
>              Forward Secrecy: How Diffie-Hellman Fails in Practice.",
>              Proceedings of the 22th ACM Conference on Computer and
>              Communications Security (CCS), 2015,
>              <https://weakdh.org/imperfect-forward-secrecy.pdf>.
> 
>   [Blaze1994]
>              Blaze, M., "Protocol Failures in the Escrowed Encryption
>              Standard", Proceedings of Second ACM Conference on
>              Computer and Communications Security, 1994,
>              <http://www.mattblaze.org/papers/eesproto.pdf>.
> 
>   [Checkoway2016]
>              Checkoway, S., Maskiewicz, J., Garman, C., Fried, J.,
>              Cohney, S., Green, M., Heninger, N., Weinmann, R. P.,
>              Rescorla, E., and Hovav Shacham, "A Systematic Analysis of
>              the Juniper Dual EC Incident", Proceedings of the 2016 ACM
>              SIGSAC Conference on Computer and Communications
>              Security 468-79, 2016,
>              <https://dl.acm.org/citation.cfm?id=2978395>.
> 
>   [LE]       Aas, J., Barnes, R., Case, B., Durumeric, Z., Eckersley,
>              P., Flores-López, A., Halderman, A., Hoffman-Andrews, J.,
>              Kasten, J., Rescorla, E., Schoen, S. D., and B. Warren,
>              "Let's Encrypt - an automated certificate authority to
>              encrypt the entire web", 2019,
>              <https://dl.acm.org/doi/pdf/10.1145/3319535.3363192>.
> -->
> 
> 
> 17) <!-- [rfced] Informative References. We note that the author's name for "Sanctions and the Internet" is given as Farzaneh Badiei. We have updated the author information to match the document, but have left the cite tag as [Badii2023].  Please let us know if any updates are necessary.
> 
> Original:
>   [Badii2023]
>              Badii, F., "Sanctions and the Internet", 2023,
>              <https://digitalmedusa.org/wp-content/uploads/2023/05/
>              SanctionsandtheInternet-DigitalMedusa.pdf>.
> 
> Current:
>   [Badii2023]
>              Badiei, F., "Sanctions and the Internet", Digital Medusa,
>              2023, <https://digitalmedusa.org/wp-
>              content/uploads/2023/05/SanctionsandtheInternet-
>              DigitalMedusa.pdf>.
> -->
> 
> 
> 18) <!-- [rfced] Normative References. FYI, RFC 7540 has been obsoleted by RFC 9113.  We have updated the reference. Please let us know if any changes are necessary.
> 
> Original:
>   [RFC7540]  Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
>              Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
>              DOI 10.17487/RFC7540, May 2015,
>              <https://www.rfc-editor.org/info/rfc7540>.
> 
> Current:
>   [RFC9113]  Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
>              DOI 10.17487/RFC9113, June 2022,
>              <https://www.rfc-editor.org/info/rfc9113>.
> -->
> 
> 
> 19) <!-- [rfced] Normative References. The I-D draft-farrelll-mpls-opportunistic-encrypt was replaced by draft-ietf-mpls-opportunistic-encrypt (also expired). Would you like to update the reference?
> 
> Original:
>   Of course, not all such initiatives bore fruit, for example attempts
>   to define a new MPLS encryption mechanism
>   [I-D.farrelll-mpls-opportunistic-encrypt] foundered due to a lack of
>   interest and the existence of the already deployed IEEE MACSEC
>   scheme.   
> 
>   [I-D.farrelll-mpls-opportunistic-encrypt]
>              Farrel, A. and S. Farrell, "Opportunistic Security in MPLS
>              Networks", Work in Progress, Internet-Draft, draft-
>              farrelll-mpls-opportunistic-encrypt-05, 17 June 2015,
>              <https://datatracker.ietf.org/doc/html/draft-farrelll-
>              mpls-opportunistic-encrypt-05>.
> -->
> 
> 
> 20) <!-- [rfced] Informative References. FYI, RFC 7484 has been obsoleted by RFC 9224.  We have updated the reference accordingly. Please let us know if any updates are necessary. 
> 
> Original:
>   [RFC7484]  Blanchet, M., "Finding the Authoritative Registration Data
>              (RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March
>              2015, <https://www.rfc-editor.org/info/rfc7484>.
> 
> Current:
> 
>   [RFC9224]  Blanchet, M., "Finding the Authoritative Registration Data
>              Access Protocol (RDAP) Service", STD 95, RFC 9224,
>              DOI 10.17487/RFC9224, March 2022,
>              <https://www.rfc-editor.org/info/rfc9224>.
> -->
> 
> 
> 21) <!-- [rfced] Terminology. 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.  For example, please consider whether the following should be updated: dummy, dumb, black bag, etc.
> -->
> 
> 
> Thank you.
> 
> RFC Editor/jm
> 
> 
> 
> On 7/11/23 5:55 PM, [e-mail] wrote:
> 
> *****IMPORTANT*****
> 
> Updated 2023/07/11
> 
> 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/rfc9446.xml
>   https://www.rfc-editor.org/authors/rfc9446.html
>   https://www.rfc-editor.org/authors/rfc9446.pdf
>   https://www.rfc-editor.org/authors/rfc9446.txt
> 
> Diff file of the text:
>   https://www.rfc-editor.org/authors/rfc9446-diff.html
>   https://www.rfc-editor.org/authors/rfc9446-rfcdiff.html (side by side)
> 
> Diff of the XML: 
>   https://www.rfc-editor.org/authors/rfc9446-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/rfc9446.original.v2v3.xml 
> 
> XMLv3 file that is a best effort to capture v3-related format updates 
> only: 
>   https://www.rfc-editor.org/authors/rfc9446.form.xml
> 
> 
> Tracking progress
> -----------------
> 
> The details of the AUTH48 status of your document are here:
>   https://www.rfc-editor.org/auth48/rfc9446
> 
> Please let us know if you have any questions.  
> 
> Thank you for your cooperation,
> 
> RFC Editor
> 
> --------------------------------------
> RFC9446 (draft-farrell-tenyearsafter-05)
> 
> Title            : Reflections on Ten Years Past The Snowden Revelations
> Author(s)        : S. Farrell, F. Badii, B. Schneier, S. Bellovin
> WG Chair(s)      : 
> Area Director(s) : 
> 
>