Re: [auth48] AUTH48: RFC-to-be 9505 <draft-irtf-pearg-censorship-10> for your review

[[e-mail]]

Authors,

While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.

1) <!-- [rfced] Please insert any keywords (beyond those that appear in the
title) for use on https://www.rfc-editor.org/search.
-->


2) <!--[rfced] Was it your intention for the text to exactly match the 
reference [WP-Def-2020]? That page does not include "politically incorrect"; 
would you like it to remain in this document? 

Current:
   Censorship is where an entity in a position of power - such as a
   government, organization, or individual - suppresses communication
   that it considers objectionable, harmful, sensitive, politically
   incorrect, or inconvenient [WP-Def-2020].
-->


3) <!-- [rfced] To clarify "and specific to" and to make the list items 
parallel, may we update as follows or otherwise? (The preceding sentence
is included for context.)

   Countries that are more interested in retaining specific political
   control typically have ministries or organizations that maintain
   blocklists. 

Original:
   Examples include the Ministry of Industry and
   Information Technology in China, Ministry of Culture and Islamic
   Guidance in Iran, and specific to copyright in France [HADOPI-2020]
   and across the EU for consumer protection law [Reda-2017].

Perhaps:
   Examples include the Ministry of Industry and
   Information Technology in China, the Ministry of Culture and Islamic
   Guidance in Iran, and the organizations specific to copyright law 
   in France [HADOPI] and consumer protection law across the EU
   [Reda-2017].
-->


4) <!--[rfced] Would you like to make it clear that "GET /page"
is an example? Using fixed-width font, which would appear in the HTML
and PDF outputs, is also an option (via the <tt> element).

Original:
   As such, "method" and "host" are
   the two fields used most often for ubiquitous censorship.  A censor
   can sniff traffic and identify a specific domain name (host) and
   usually a page name (GET /page) as well. 

Perhaps:
   As such, "method" and "host" are
   the two fields used most often for ubiquitous censorship.  A censor
   can sniff traffic and identify a specific domain name (host) and
   usually a page name (for example, GET /page) as well. 
-->


5) <!-- [rfced] To make the trade-offs and empirical examples stand out more
clearly in the text, would you like them to be indented or bulleted? 
Note that this update would apply to several subsections of Section 4.2.
For example (from Section 4.2.1):

Original:
   Tradeoffs: Request Identification is a technically straight-forward
   identification method that can be easily implemented at ...

   Empirical Examples: Studies exploring censorship mechanisms have 
   found evidence of HTTP header/ URL filtering in many countries ...

Option A (with a line break and indentation):
   Trade-offs:
      Request Identification is a technically straightforward
      identification method that can be easily implemented at the ...

   Empirical Examples:
      Studies exploring censorship mechanisms have found evidence of
      HTTP header/ URL filtering in many countries, including ...


Option B (bulleted):
   *  Trade-offs: Request Identification is a technically 
      straightforward identification method that can be 
      easily implemented at ...

   *  Empirical Examples: Studies exploring censorship mechanisms 
      have found evidence of HTTP header/ URL filtering in many 
      countries, including ...
-->


6) <!-- [rfced] For clarity, may we update "HTTP header/ URL filtering" to 
"HTTP header and/or URL filtering"?

Original:
   Empirical Examples: Studies exploring censorship mechanisms have
   found evidence of HTTP header/ URL filtering in many countries,
   ...

Perhaps:
   Empirical Examples: Studies exploring censorship mechanisms have
   found evidence of HTTP header and/or URL filtering in many countries,
   ...
-->


7) <!-- [rfced] To match other instances in the document, should
Host: header be changed to "host" header?

Original:
   To avoid identification by censors,
   applications using domain fronting put a different domain name in the
   SNI extension than in the Host: header, which is protected by HTTPS.

Perhaps:
   To avoid identification by censors,
   applications using domain fronting put a different domain name in the
   SNI extension than in the "host" header, which is protected by HTTPS.
-->


8) <!--[rfced] As "infrastructurally" is not actually a word, please let us 
know how this may be rephrased.

Original:
   In addition, this technique
   requires deep packet inspection (DPI) techniques that can be
   computationally and infrastructurally expensive, especially when
   applied to QUIC where DPI requires ...

Perhaps:
   In addition, this technique
   requires deep packet inspection (DPI) techniques that can be
   expensive in terms of computational complexity and infrastructure, 
   especially when applied to QUIC where DPI requires ...
-->


9) <!-- [rfced] This sentence seems contradictory ("trivial to implement",
then "difficult to implement"). Would the following rewording convey the 
intended meaning?

Original:
   Header identification is trivial to implement, but is difficult to
   implement in backbone or ISP routers at scale, and is therefore
   typically implemented with DPI.

Option A:
   Header identification is trivial to implement in some routers, 
   but is difficult to implement in backbone or ISP routers at scale, 
   and is therefore typically implemented with DPI.

Option B (removing mention of trivial):
   Because header identification is difficult to implement in backbone 
   or ISP routers at scale, it is typically implemented with DPI.
-->


10) <!--[rfced] For clarity, may the lists be written out as follows?

Original:
        There are three common options available to an adversary:                     
        2-tuple (client IP, server IP), 3-tuple (client IP, server IP+port),
        or 4-tuple (client IP+port, server IP+port).

Perhaps:
        There are three common options available to an adversary:                     
        2-tuple (client IP, server IP), 3-tuple (client IP, server IP, 
        server port), or 4-tuple (client IP, client port, server IP, 
        server port).
-->


11) <!-- [rfced] Should "and" be "or" (i.e., any one of these can be used
to respond to a DNS query with an incorrect address)?

Original:
   Responding to a DNS query with an incorrect address can be achieved
   with on-path interception, off-path cache poisoning, and lying by the
   nameserver.

Perhaps:
   Responding to a DNS query with an incorrect address can be achieved
   with on-path interception, off-path cache poisoning, or lying by the
   name server.
-->


12) <!-- [rfced] Please clarify; what is "It" referring to in "It can be 
circumvented"? 

Original:
   Trade offs: These forms of DNS interference require the censor to
   force a user to traverse a controlled DNS hierarchy (or intervening
   network on which the censor serves as an Active Pervasive Attacker
   [RFC7624] to rewrite DNS responses) for the mechanism to be
   effective.  It can be circumvented by using alternative DNS resolvers
   (such as any of the public DNS resolvers) that may fall outside of
   the jurisdictional control of the censor, or Virtual Private Network
   (VPN) technology. 
-->


13) <!-- [rfced] What are the quotation marks indicating in "censorship
disasters"? May they be removed?

Original:
   DNS interference, when incorrectly
   implemented, has resulted in some of the largest "censorship
   disasters".
-->


14) <!-- [rfced] While we found "China", "Turkey", and "United States" in the
reference [Albert-2011], we did not find "Iran" mentioned.
Please verify that this is the correct reference for this sentence. Or,
should a second reference be added to this sentence, such as
[Aryan-2013], [Bock-2020], [Knight-2005], or otherwise?

Original:
   Countries such as
   China, Iran, Turkey, and the United States have discussed blocking
   entire TLDs as well, but only Iran has acted by blocking all Israeli
   (.il) domains [Albert-2011]. 
-->


15) <!--[rfced] For readability, would you like this list to be formatted
as follows?

Original:
   DNS-blocking is commonly deployed in
   European countries to deal with undesirable content, such as child
   abuse content (Norway, United Kingdom, Belgium, Denmark, Finland,
   France, Germany, Ireland, Italy, Malta, the Netherlands, Poland,
   Spain and Sweden [Wright-2013] [Eneman-2010]), online gambling
   (Belgium, Bulgaria, Czech Republic, Cyprus, Denmark, Estonia, France,
   Greece, Hungary, Italy, Latvia, Lithuania, Poland, Portugal, Romania,
   Slovakia, Slovenia, Spain (see Section 6.3.2 of: [EC-gambling-2012],
   [EC-gambling-2019])), copyright infringement (all European Economic
   Area countries), hate-speech and extremism (France [Hertel-2015]) and
   terrorism content (France [Hertel-2015]).

Perhaps:
   DNS blocking is commonly deployed in European countries to deal with
   undesirable content, such as

   *  child abuse content (Norway, United Kingdom, Belgium, Denmark,
      Finland, France, Germany, Ireland, Italy, Malta, the Netherlands,
      Poland, Spain, and Sweden [Wright-2013] [Eneman-2010]),

   *  online gambling (Belgium, Bulgaria, Czech Republic, Cyprus,
      Denmark, Estonia, France, Greece, Hungary, Italy, Latvia,
      Lithuania, Poland, Portugal, Romania, Slovakia, Slovenia, and
      Spain (see Section 6.3.2 of [EC-gambling-2012],
      [EC-gambling-2019])),

   *  copyright infringement (all European Economic Area countries),

   *  hate-speech and extremism (France [Hertel-2015]), and

   *  terrorism content (France [Hertel-2015]).
-->


16) <!-- [rfced] Since RFC 793 does not use the words "good enough", the
quotation marks may be misleading. May it be updated as follows or otherwise?

Original:
   Sequence number is the hardest to get correct, as
   [RFC0793] specifies an RST Packet should be in-sequence to be
   accepted, although the RFC also recommends allowing in-window packets
   as "good enough". 

Perhaps:
   The sequence number is the hardest to get correct, as
   [RFC0793] specifies that a RST packet should be in sequence to be
   accepted, although that RFC also recommends allowing in-window packets.
-->


17) <!--[rfced] Please clarify; may "it" be changed to "Google" here?

Original:
   In 2018 nearly all Google services and Google cloud customers, like
   Spotify, all lost more than one hour of service after it lost control
   of several million of its IP addresses. 
-->


18) <!--[rfced] Please clarify; what is "The latter" referring to here? 

Also, we suggest rephrasing the preceding sentence if the "instead"
phrase should not include "for a limited period of time".

Original:
   Trade offs: DDoS is an appealing mechanism when a censor would like
   to prevent all access to undesirable content, instead of only
   preventing access in their region for a limited period of time.  The
   latter is really the only uniquely beneficial feature for DDoS as a
   technique employed for censorship. 

Perhaps (where text needs to be provided):
   Trade-offs: DDoS is an appealing mechanism when a censor would like
   to prevent all access (not just regional access) to undesirable content
   for a limited period of time.  ___ is a unique feature
   of DDoS as a technique employed for censorship. 
-->


19) <!--[rfced] FYI, we updated "Censors maturity" to "Censor maturity" 
here; please review and let us know if a different term was intended.

Current:
   Censor maturity
   refers to the technical maturity required of the censor to perform
   the specific censorship technique. 
-->


20) <!--[rfced] FYI, an IANA Considerations section has been
added as typical for RFCs that do not contain any actions for IANA.
-->


21) <!--[rfced] A Security Considerations section (per RFC 3552) is required
in an RFC. Please provide the content.

Here's an example from a survey document from the IRTF in 2010:
https://www.rfc-editor.org/rfc/rfc6029.html#section-5
-->


22) <!-- [rfced] The following references are not cited in the text. Please let
us know where they should be cited or if these references should be
deleted from the References section.

   [AP-2012] 
   [Bentham-1791] 
   [Bristow-2008] 
   [Calamur-2013] 
   [Ellul-1973] 
   [Fareed-2008] 
   [Gao-2014] 
   [Guardian-2014] 
   [Hopkins-2011] 
   [Kopel-2013] 
   [RSF-2005]
-->


23) <!-- [rfced] Please review the URLs in the following references as they return the
following errors and let us know how we may update.

a) Please provide a replacement URL. This one is 404 Not Found.

Original:
   [Wagstaff-2013]
              Wagstaff, J., "In Malaysia, online election battles take a
              nasty turn", 2013,
              <http://www.reuters.com/article/2013/05/04/uk-malaysia-
              election-online-idUKBRE94309G20130504>.

Perhaps:
   [Wagstaff-2013]
              Wagstaff, J., "In Malaysia, online election battles take a
              nasty turn", May 2013, <https://www.nbcnews.com/tech/tech-news/
	      malaysia-online-election-battles-take-nasty-turn-
	      flna6c9783842>.


b) Please provide a replacement URL. This one is 404 Not Found.

Original:
   [Sandvine-2014]
              Sandvine, "Technology Showcase on Traffic Classification:
              Why Measurements and Freeform Policy Matter", 2014,
              <https://www.sandvine.com/downloads/general/technology/
              sandvine-technology-showcases/sandvine-technology-
              showcase-traffic-classification.pdf>.


c)  Please provide a replacement URL. This one is 404 Not Found.

Original:
   [BBC-2013b]
              BBC, "China employs two million microblog monitors state
              media say", 2013,
              <http://www.bbc.com/news/world-asia-china-2439695>.

Perhaps:
   [BBC-2013b]
              BBC, "China employs two million microblog monitors state
              media say", October 2013,
              <https://www.bbc.com/news/world-asia-china-24396957>.


d) Please provide a replacement URL; this one is "server not found".
(Also, this reference is not cited.)

Original:
   [RSF-2005] Reporters Sans Frontieres, "Technical ways to get around
              censorship", 2005, <http://archives.rsf.org/print-
              blogs.php3?id_article=15013>.


e) Please review the URL as it returns a "Connection timed out Error code
522".

Original:
   [Orion-2013]
              Orion, E., "Zimbabwe election hit by hacking and DDoS
              attacks", 2013,
              <http://www.theinquirer.net/inquirer/news/2287433/
              zimbabwe-election-hit-by-hacking-and-ddos-attacks>.
-->


24) <!-- [rfced] Please review the URLs in the following references as they appear
to redirect to pages with different names from what was provided in the
original. Let us know how/if we may update.

a) Please review the URL as it redirects to a page titled "Hitta
material". Would you like to update to the English version below or update the
current version to match the title of the original URL?

Original:
   [Eneman-2010]
              Eneman, M., "ISPs filtering of child abusive material: A
              critical reflection of its effectiveness", 2010,
              <https://www.gu.se/forskning/
              publikation/?publicationId=96592>.

Perhaps:
   [Eneman-2010]
              Eneman, M., "Internet service provider (ISP) filtering of 
	      child-abusive material: A critical reflection of its          
	      effectiveness", June 2010, DOI 10.1080/13552601003760014,
	      <https://www.tandfonline.com/doi/abs/10.1080/
	      13552601003760014>.


b) Please review the URL as it redirects to
https://profsforrest.github.io/homepage/, which is an individual's
home page. Would the following update be accurate? 

Original:
   [Leyba-2019]
              Leyba, K., Edwards, B., Freeman, C., Crandall, J., and S.
              Forrest, "Borders and Gateways: Measuring and Analyzing
              National AS Chokepoints", 2019,
              <https://forrest.biodesign.asu.edu/data/publications/2019-
              compass-chokepoints.pdf>.

Perhaps:
   [Leyba-2019]
              Leyba, K., Edwards, B., Freeman, C., Crandall, J., and S.
              Forrest, "Borders and gateways: measuring and analyzing
              national as chokepoints", July 2019, COMPASS '19: 
	      Proceedings of the 2nd ACM SIGCAS Conference on Computing 
	      and Sustainable Societies, pages 184–194, DOI 10.1145/
	      3314344.3332502, <https://doi.org/10.1145/3314344.3332502>.


c) Please review the URL as it redirects to https://blogs.oracle.com/, and we
were unable to find a blog post with the title below.

Original:
   [Zmijewski-2014]
              Zmijewski, E., "Turkish Internet Censorship Takes a New
              Turn", 2014,
              <https://blogs.oracle.com/internetintelligence/turkish-
              internet-censorship-takes-a-new-turn>.


d) Please review the URL as it redirects to a page titled "1996 CERT
Advisories".

Original:
   [CERT-2000]
              CERT, "TCP SYN Flooding and IP Spoofing Attacks", 2000,
              <http://www.cert.org/historical/advisories/CA-
              1996-21.cfm>.


e) Please review the URL as it redirects to a page titled "'A MAJOR FAILURE'
WHAT WENT WRONG?". (Also, this reference is not cited.)

Original:
   [AP-2012]  Associated Press, "Sattar Beheshit, Iranian Blogger, Was
              Beaten In Prison According To Prosecutor", 2012,
              <http://www.huffingtonpost.com/2012/12/03/sattar-beheshit-
              iran_n_2233125.html>.
-->


25) <!-- [rfced] Informative reference RFC 793 has been obsoleted by RFC 9293.
We recommend replacing RFC 793 with RFC 9293.  However, if RFC 793 must
be referenced, we suggest mentioning RFC 9293 (e.g., RFC 793 has been
obsoleted by RFC 9293). 
-->


26) <!--[rfced] Regarding [HADOPI-2020], we have updated the URL to 
to the main page and removed the year. If you intended to refer to
specific content within the site, please let us know.

Original:
   [HADOPI-2020]
              Haute Autorité pour la Diffusion des oeuvres et la
              Protection des Droits sur Internet, "Présentation", 2020,
              <https://www.hadopi.fr/en/node/3668>.

Current:
   [HADOPI]
              Hadopi, "Hadopi | Haute Autorité pour la diffusion des
              oeuvres et la protection des droits sur internet",
              <https://www.hadopi.fr/>.
-->


27) <!-- [rfced] We note that the title and the URL of reference
[EC-gambling-2012] do not match. Please review and let us know which
title and URL you would like to use.

Original:
   [EC-gambling-2012]
              European Commission, "Online gambling in the Internal
              Market", 2012, <https://eur-lex.europa.eu/legal-
              content/EN/TXT/?uri=CELEX:52012SC0345>. 

Perhaps:
a) (match provided title):
   [EC-gambling-2012]
              European Commission, "Online gambling in the Internal
              Market -  Frequently asked questions", October 2012, 
	      <https://ec.europa.eu/commission/presscorner/detail/
	      el/MEMO_12_798>.

b) (match provided URL):
   [EC-gambling-2012]
              Europa, "COMMISSION STAFF WORKING DOCUMENT Online 
	      gambling in the Internal Market Accompanying the 
	      document Communication from the Commission to the 
	      European Parliament, the Council, the Economic and 
	      Social Committee and the Committee of the Regions 
	      Towards a comprehensive framework for online 
	      gambling", 2012, <https://eur-lex.europa.eu/legal-
              content/EN/TXT/?uri=CELEX:52012SC0345>.
-->


28) <!-- [rfced] Please review the URL and date for reference [Hepting-2011].
The reference and the reference tag contain "2011", so
should the URL be for a 2011 revision or a 2023 revision of the 
Wikipedia page? If the latter, the reference tag will be updated as well.
Please provide the preferred URL.

Original:
   [Hepting-2011]
              Wikipedia, "Hepting vs. AT&T", 2011,
              <https://en.wikipedia.org/wiki/Hepting_v._AT%26T>.

Perhaps:
a) (an example of a 2011 revision)
   [Hepting-2011]
              Wikipedia, "Hepting vs. AT&T", October 2011,
              <https://en.wikipedia.org/w/index.php?
              title=Hepting_v._AT%26T&oldid=457488363>.

b) (2023 revision)
   [Hepting-2023]
              Wikipedia, "Hepting vs. AT&T", September 2023,
              <https://en.wikipedia.org/w/index.php?
              title=Hepting_v._AT%26T&oldid=1175143505>.
-->


29) <!-- [rfced] Regarding [Schone-2014], the page does not list any
authors, so may we replace the author names with "NBC News" and 
update the reference tag to "[NBC-News-2014]"?

Original:
   [Schone-2014]
              Schone, M., Esposito, R., Cole, M., and G. Greenwald,
              "Snowden Docs Show UK Spies Attacked Anonymous, Hackers",
              2014, <http://www.nbcnews.com/feature/edward-snowden-
              interview/exclusive-snowden-docs-show-uk-spies-attacked-
              anonymous-hackers-n21361>.

Perhaps:
   [NBC-News-2014]
              NBC News, "Exclusive: Snowden Docs Show UK Spies 
	      Attacked Anonymous, Hackers", February 2014, 
	      <http://www.nbcnews.com/feature/edward-snowden-
              interview/exclusive-snowden-docs-show-uk-spies-attacked-
              anonymous-hackers-n21361>.
-->


30) <!-- [rfced] Would you like to update to use the publisher's information for
reference [Murdoch-2011]?

Original:
   [Murdoch-2011]
              Murdoch, S. J. and R. Anderson, "Access Denied: Tools and
              Technology of Internet Filtering", 2011,
              <http://access.opennet.net/wp-content/uploads/2011/12/
              accessdenied-chapter-3.pdf>.

Perhaps:
   [Murdoch-2008]
              Murdoch, S. J. and R. Anderson, "Tools and
              Technology of Internet Filtering" in "Access Denied:
              The Practice and Policy of Global Internet Filtering", 2008,
	      DOI 10.7551/mitpress/7617.003.0006,
              <https://doi.org/10.7551/mitpress/7617.003.0006>.
-->


31) <!-- [rfced] Please review the URL for reference [Sophos-2015] as it goes 
to a page titled "Sophos UTM: Web Filtering" and links to another page 
titled "Web Filtering".

Original:
   [Sophos-2015]
              Sophos, "Understanding Sophos Web Filtering", 2015,
              <https://www.sophos.com/en-us/support/
              knowledgebase/115865.aspx>.
-->


32) <!-- [rfced] Please review the URL for reference [Google-RTBF] as it returns a
form for "Personal Data Removal Request Form". Is this the intended
landing page? Please let us know how we may update.

Original:
   [Google-RTBF]
              Google, Inc., "Search removal request under data
              protection law in Europe", 2015,
              <https://support.google.com/legal/contact/
              lr_eudpa?product=websearch>.
-->


33) <!-- [rfced] Terminology

a) Throughout the text, the following terminology appears to be used
inconsistently. May we update to the third option in the list to make them
consistent?

i)
   HTTP Request Header Identification 
   Request Identification
   HTTP request header identification

ii)
   HTTP Response Header Identification 
   response identification 
   HTTP response header identification 


b) Throughout the text, the following terminology appears to be capitalized
inconsistently. May we update to the option on the right to make them
consistent?

   Client Hello message -> ClientHello message (as it appears in RFC 8446)
   HTTP Request Header -> HTTP request header
   Header Identification & Header identification -> header identification
   Response -> response
   Request -> request

c) To match "www.censored.example", would you like to add quotation marks
to the following?

   www.sex.example
   populardomain.example
   bad.foo.example
   good.foo.example
-->


34) <!-- [rfced] FYI, we have added expansions for abbreviations upon first 
use per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
-->


35) <!-- [rfced] Please ensure that the guidelines listed in Section 2.1 of RFC
5743 have been adhered to in this document.
-->


36) <!-- [rfced] Please review the artwork element in the XML file. Specifically,
should the artwork element be tagged as sourcecode or another element?
More information is here: https://authors.ietf.org/rfcxml-vocabulary#artwork
-->


37) <!-- [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.

For example, please consider whether the following should be updated: 
  man-in-the-middle
  man-on-the-side
-->


Thank you.

RFC Editor/st/ar



On Oct 27, 2023, at 5:33 PM, [e-mail] wrote:

*****IMPORTANT*****

Updated 2023/10/27

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/rfc9505.xml
  https://www.rfc-editor.org/authors/rfc9505.html
  https://www.rfc-editor.org/authors/rfc9505.pdf
  https://www.rfc-editor.org/authors/rfc9505.txt

Diff file of the text:
  https://www.rfc-editor.org/authors/rfc9505-diff.html
  https://www.rfc-editor.org/authors/rfc9505-rfcdiff.html (side by side)

This alternate diff file shows the changes in the moved text:
  https://www.rfc-editor.org/authors/rfc9505-alt-diff.html

Diff of the XML: 
  https://www.rfc-editor.org/authors/rfc9505-xmldiff1.html


Tracking progress
-----------------

The details of the AUTH48 status of your document are here:
  https://www.rfc-editor.org/auth48/rfc9505

Please let us know if you have any questions.  

Thank you for your cooperation,

RFC Editor

--------------------------------------
RFC9505 (draft-irtf-pearg-censorship-10)

Title            : A Survey of Worldwide Censorship Techniques
Author(s)        : J. Hall, M. Aaron, A. Andersdotter, B. Jones, N. Feamster, M. Knodel