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

[Mallory Knodel <[e-mail]>]

Hi,

Sorry for the top post. I was browsing this Sandvine research doc that is
not the 2014 citation (this is from 2015) but presumably it contains what
was originally cited?

https://www.researchgate.net/profile/Nirmala-Svsg/post/Anybody-working-on-Internet-traffic-classification/attachment/59d63a5779197b807799782d/AS%3A405810988503040%401473764287142/download/traffic-classification-identifying-and-measuring-internet-traffic.pdf

Joe I think it was from and early version of the draft so you could tell us
if this document could replace the original.

-M

On Mon, 30 Oct 2023 at 16:59, Alice Russo <[e-mail]> wrote:

> Joseph, Mallory, Shivan*,
>
> Thank you for your replies. We have updated the document accordingly; see
> the follow-ups below. Please review the document and let us know if any
> further changes are needed. The files are here:
>
>    https://www.rfc-editor.org/authors/rfc9505.txt
>    https://www.rfc-editor.org/authors/rfc9505.pdf
>    https://www.rfc-editor.org/authors/rfc9505.html
>    https://www.rfc-editor.org/authors/rfc9505.xml
>
> This diff shows only the most recent changes:
>    https://www.rfc-editor.org/authors/rfc9505-auth48diff.html
>    https://www.rfc-editor.org/authors/rfc9505-auth48rfcdiff.html (side by
> side)
>
> This diff shows all changes from the Internet-Draft:
>   https://www.rfc-editor.org/authors/rfc9505-diff.html
>   https://www.rfc-editor.org/authors/rfc9505-rfcdiff.html (side by side)
>
>
> *Shivan (as Doc Shepherd),
>
> Re: Section 5.1.1, please review this change and let us know if you
> approve it. The change is per the author's reply to #14.  To reiterate,
> [Albert-2011] does not seem to mention Iran; should an additional reference
> be cited?
>
> 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].
>
> Current:
>    Countries such as
>    China, Iran, Turkey, and the United States have discussed blocking
>    entire Top-Level Domains (TLDs) as well [Albert-2011].
>
> Joseph wrote:
> > 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/
>
> ----
>
> Re: #18 (Section 5.4.1), updated as Mallory suggested. (Also changed
> 'feature for DDoS' to 'feature of DDoS'.) Please review.
>
> 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.
>
> Current:
>    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.  Temporal impermanence is
>    really the only uniquely beneficial feature of DDoS as a technique
>    employed for censorship.
>
>
> Re: the URL for [Orion-2013]
>
> >> 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/
>
> That page contains 4 of 6 paragraphs from the original article. So, the
> Internet Archive page is more complete; updated the reference accordingly (
> https://web.archive.org/web/20130825010947/http://www.theinquirer.net/inquirer/news/2287433/zimbabwe-election-hit-by-hacking-and-ddos-attacks
> ).
>
>
> Mallory wrote:
> > There are several links that no longer work, but I'm only commenting
> here-- would it be possible to try to find them on the Internet Archive?
>
> Yes, we can add URLs to Internet Archive to replace the URLs that no
> longer function. We have done so for [Zmijewski-2014] and [Orion-2013];
> please review. However, in some cases, it is not straightforward, and the
> authors' help is needed. For example:
>
> 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>.
>
> It seems that none of the pages archived in 2014 [1] or 2015 [2] or one in
> 2019 [3] -- nor any archived in 2023 -- are the PDF that was referenced. If
> you have a URL where it is archived, please send it along.
>
> [1]
> https://web.archive.org/web/20140719185454/https://www.sandvine.com/downloads/genera[…]cases/sandvine-technology-showcase-traffic-classification.pdf
> -> "301 response at crawl time", so they archived a different page.
>
> [2]
> https://web.archive.org/web/20151003172944/https://www.sandvine.com/downloads/genera[…]cases/sandvine-technology-showcase-traffic-classification.pdf
> -> archived 404
>
> [3]
> https://web.archive.org/web/20190314014034/https://www.sandvine.com/downloads/general/technology/sandvine-technology-showcases/sandvine-technology-showcase-traffic-classification.pdf
> -> archived 404
>
>
> We will wait to hear from you again and from your coauthors
> before continuing the publication process. This page shows
> the AUTH48 status of your document:
>   https://www.rfc-editor.org/auth48/rfc9505
>
> Thank you.
> RFC Editor/ar
>
>
>
> > On Oct 30, 2023, at 6:49 AM, Dr. Joseph Lorenzo Hall <hall=
> [e-mail]> wrote:
> >
> > 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
> >
>
>
>
>