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

["Dr. Joseph Lorenzo Hall" <[e-mail]>]

Hi responses inline:

>From: [e-mail] <[e-mail]>
>Sent: Friday, October 27, 2023 20:34
>To: Dr. Joseph Lorenzo Hall <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
>Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
>Subject: Re: AUTH48: RFC-to-be 9505 <draft-irtf-pearg-censorship-10> for your review 
> 
>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.
>-->

OLD:
<keyword>example</keyword>

NEW:
<keyword>network censorship</keyword>
<keyword>network blocking</keyword>
<keyword>network throttling</keyword>
<keyword>traffic impairment</keyword>
<keyword>censorship circumvention</keyword>

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

Please feel free to remove that; it's better to match the cited text.

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

That looks great, thank you.

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

"For example" is great; no need to use a fixed-width font, thank you.

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

No, this is not necessary, but thank you for the suggestion.

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

This sounds great.

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

Yes, this is good, thank you.

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

That is fine... another option might be to use the adverb "operationally" here, but the suggested edit does the trick without using new terms.

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

Option A seems perfect.

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

The change seems great, thank you.

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

Yes, good catch.

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

It = "DNS interference" (the heading title for this section). so:

NEW:

DNS interference can be circumvented by using alternative DNS resolvers...

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

You may remove them, thank you.

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

I think we need to remove ", but only Iran has acted by blocking all Israeli (.il) domains" as it is not in that cited work and more recent analysis from OONI shows pervasive .il TLD blocking but not a blanket block of all .il domains: https://ooni.org/post/iran-internet-censorship/

>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]).
>-->

That does look much easier to read, thank you.

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

That works, thank you.

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

Yes.

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

I would suggest just deleting that sentence ("The latter is really the only uniquely beneficial feature for 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. 
>-->

That's fine, thanks.

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

Thank you.

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

Thank you:

This document is a survey of existing literature on network censorship techniques.  As such, it does not introduce any new security considerations to be taken into account beyond what is already discussed in each paper surveyed.

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

Please remove them, thank you.

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

New URL works.

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

This no longer seems to be available.

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

New URL works, thank you.

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

This one also appears to no longer be online.

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

This no longer appears online, although the Verified Voting Foundation's Voting News has an archive of the article here: https://thevotingnews.com/zimbabwe-election-hit-by-hacking-and-ddos-attacks-the-inquirer/

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

Thank you

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

Yes, thank you.

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

Yes, this no longer exists, sadly.

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

Please use: https://vuls.cert.org/confluence/display/historical/CERT+Advisory+CA-1996-21+TCP+SYN+Flooding+and+IP+Spoofing+Attacks

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

Let's just delete this as unused.

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

The text here is essentially the same between the two so we can update to 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/>.
>-->

Thank you.

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

Let's go with the second to match provided URL.

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

Let's use the 2023 revision, thank you.

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

Yes, thank you, good catch.

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

Yes, thank you.

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

That page appears to be here now: https://support.sophos.com/support/s/article/KB-000036518?language=en_US , so if this could be updated to match, that would be great.

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

This is the intended page, thank you.

>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 

Yes, please update, thank you.

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

Yes, thank you.

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

I don't see this in the XML or HTML but do not see any issues with abbreviations.

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

We have, the IRTF chair is a stickler here. ::)

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

sourcecode is fine (it's technically a command-line entry in a terminal but essentially the same).

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

Please update to "machine-" for both. Thank you.

>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