Re: [auth48] [Doc Shepherd] Re: AUTH48: RFC-to-be 9505 <draft-irtf-pearg-censorship-10> for your review
Shivan Kaul Sahib <shivankaulsahib@gmail.com> Mon, 30 October 2023 21:18 UTC
Return-Path: <shivankaul.1993@gmail.com>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8387C15107E; Mon, 30 Oct 2023 14:18:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.158
X-Spam-Level:
X-Spam-Status: No, score=0.158 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, URI_DOTEDU=1, URI_WP_DIRINDEX=1] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozjM_0MAffGB; Mon, 30 Oct 2023 14:18:17 -0700 (PDT)
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24737C14F748; Mon, 30 Oct 2023 14:18:17 -0700 (PDT)
Received: by mail-wr1-x42d.google.com with SMTP id ffacd0b85a97d-32d834ec222so3145478f8f.0; Mon, 30 Oct 2023 14:18:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698700695; x=1699305495; darn=rfc-editor.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=On9s4yQ6GW8PlMhRmSYNdyX40T+jqcvInDRocQl4a38=; b=RF7t6ddDnyQLRQKfrEtUqcUO14pmbHSPEGOxaPxVwLFVv2piweiTD5i+EOrhFnsuE9 DOi0+CcYAMF1CfQAolKoQrotBE1ESFL8t6JIkTva54KAk72GrScV+PK4w5dECzZ2dKl+ mFerQ1/Rp28MY323je4jDKDtGpqcxoF7FrkY4s8YHWEEe8do84B5Q2yjazAA4HrmmHYs vsm8Uj0+j8UYqxSIdQ5aigJac8UmSwMPXlSYiOY6CfLILyAs+BQH8XXExUn4Qnc48zIE TZ9khesKBMVBfyTyq7r+T577FwKS5+uiICZ74fEVIEUn3uzxOMJifkz8/r96gHkP91XT 0efQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698700695; x=1699305495; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=On9s4yQ6GW8PlMhRmSYNdyX40T+jqcvInDRocQl4a38=; b=KHyQ+M8ZDPPfKGhGmgKjcSA7ML6PW5OdUfREnqV4IY4tcr64YB3YcOCVkSRC81tzKB MN80dJt5NXqhdgktbvSGdDNdufL5ezOQcVFPtEApQ/jQmfEx/Hki3gidzRJ4hkniLFYA 1EbqsS2jFQTosZgnzOoD6zgQvpumThY/XnE71rD08EwhXAUoOndL1Q9Xhgyxxg427JWx UjNnuT0GWAYX/2ko5akopfa35Ze0mKY7P/x29YRQ+4A0iu3jxHLPObN4wNFSGiwKQqGS Ta1pIlSinoPjGa5f+dSOHE5i82ZqEjsg4at6qHAZFah0cTi5OMcpNNewluThh6h0vP0z M+/g==
X-Gm-Message-State: AOJu0YygMb5ktlrnWq/aZljve3ooEbRU+O+VjONM7oNdcOk3+rryA1FH qSnnOFYOIf+TDfOKlMWRv8CwebaN2Z7JnKhE3UY=
X-Google-Smtp-Source: AGHT+IFOxwpWdgxlfGONjtLMiR+utlMuUY7adkffm4vJk6fw7lQrGcGOhHtyLp4dGg3ln03UX1PlJd8VIZS5eHb4zs8=
X-Received: by 2002:a05:6000:1a87:b0:32f:88d1:218c with SMTP id f7-20020a0560001a8700b0032f88d1218cmr3169844wry.35.1698700694693; Mon, 30 Oct 2023 14:18:14 -0700 (PDT)
MIME-Version: 1.0
References: <20231028003417.30010B33A7@rfcpa.amsl.com> <MN2PR06MB63029F6D5C825F68E0183205B1A1A@MN2PR06MB6302.namprd06.prod.outlook.com> <C0A01F6E-D038-425B-BFFE-7E9D1B556C08@amsl.com>
In-Reply-To: <C0A01F6E-D038-425B-BFFE-7E9D1B556C08@amsl.com>
From: Shivan Kaul Sahib <shivankaulsahib@gmail.com>
Date: Mon, 30 Oct 2023 17:17:38 -0400
Message-ID: <CAG3f7Mg+mVG6OtCf8kJpNFmf0_26pZjvWeyvuji4qQat8NTRpg@mail.gmail.com>
To: Alice Russo <arusso@amsl.com>
Cc: hall@isoc.org, "mknodel@cdt.org" <mknodel@cdt.org>, "michael.drew.aaron@gmail.com" <michael.drew.aaron@gmail.com>, "amelia.ietf@andersdotter.cc" <amelia.ietf@andersdotter.cc>, "ben.jones.irtf@gmail.com" <ben.jones.irtf@gmail.com>, "feamster@uchicago.edu" <feamster@uchicago.edu>, "irsg@irtf.org" <irsg@irtf.org>, "rfc-editor@rfc-editor.org" <rfc-editor@rfc-editor.org>, "auth48archive@rfc-editor.org" <auth48archive@rfc-editor.org>
Content-Type: multipart/alternative; boundary="0000000000007caa550608f59382"
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/v_k7v3eoumV7pki3iDyssyVvsfI>
Subject: Re: [auth48] [Doc Shepherd] Re: AUTH48: RFC-to-be 9505 <draft-irtf-pearg-censorship-10> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Oct 2023 21:18:23 -0000
Hi, On Mon, 30 Oct 2023 at 16:59, Alice Russo <arusso@amsl.com> 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]. Yeah, to be thorough, I don't think we should include Iran there if the reference doesn't talk about it. I found an Iranian news website link mentioning that Iran blocks certain TLDs like .online and .gallery (it's in Farsi though): https://www.khabaronline.ir/news/1665942/%D9%81%DB%8C%D9%84%D8%AA%D8%B1%DB%8C%D9%86%DA%AF-%D8%AC%D8%AF%DB%8C%D8%AF-%D9%88-%D8%B9%D8%AC%DB%8C%D8%A8-%D8%A7%DB%8C%D8%B1%D8%A7%D9%86%D8%B3%D9%84-%D9%88-%D9%87%D9%85%D8%B1%D8%A7%D9%87-%D8%A7%D9%88%D9%84 . > > > 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= > 40isoc.org@dmarc.ietf.org> wrote: > > > > Hi responses inline: > > > >> From: rfc-editor@rfc-editor.org <rfc-editor@rfc-editor.org> > >> Sent: Friday, October 27, 2023 20:34 > >> To: Dr. Joseph Lorenzo Hall <hall@isoc.org>; > michael.drew.aaron@gmail.com <michael.drew.aaron@gmail.com>; > amelia.ietf@andersdotter.cc <amelia.ietf@andersdotter.cc>; > ben.jones.irtf@gmail.com <ben.jones.irtf@gmail.com>; feamster@uchicago.edu > <feamster@uchicago.edu>; mknodel@cdt.org <mknodel@cdt.org> > >> Cc: rfc-editor@rfc-editor.org <rfc-editor@rfc-editor.org>; > irsg@irtf.org <irsg@irtf.org>; shivankaulsahib@gmail.com < > shivankaulsahib@gmail.com>; auth48archive@rfc-editor.org < > auth48archive@rfc-editor.org> > >> 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, rfc-editor@rfc-editor.org 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 > >> > >> * rfc-editor@rfc-editor.org (the RPC team) > >> > >> * other document participants, depending on the stream (e.g., > >> IETF Stream participants are your working group chairs, the > >> responsible ADs, and the document shepherd). > >> > >> * auth48archive@rfc-editor.org, which is a new archival mailing > list > >> to preserve AUTH48 conversations; it is not an active discussion > >> list: > >> > >> * More info: > >> > https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > >> > >> * The archive itself: > >> https://mailarchive.ietf.org/arch/browse/auth48archive/ > >> > >> * Note: If only absolutely necessary, you may temporarily opt out > >> of the archiving of messages (e.g., to discuss a sensitive > matter). > >> If needed, please add a note at the top of the message that you > >> have dropped the address. When the discussion is concluded, > >> auth48archive@rfc-editor.org will be re-added to the CC list > and > >> its addition will be noted at the top of the message. > >> > >> You may submit your changes in one of two ways: > >> > >> An update to the provided XML file > >> — OR — > >> An explicit list of changes in this format > >> > >> Section # (or indicate Global) > >> > >> OLD: > >> old text > >> > >> NEW: > >> new text > >> > >> You do not need to reply with both an updated XML file and an explicit > >> list of changes, as either form is sufficient. > >> > >> We will ask a stream manager to review and approve any changes that seem > >> beyond editorial in nature, e.g., addition of new text, deletion of > text, > >> and technical changes. Information about stream managers can be found > in > >> the FAQ. Editorial changes do not require approval from a stream > manager. > >> > >> > >> Approving for publication > >> -------------------------- > >> > >> To approve your RFC for publication, please reply to this email stating > >> that you approve this RFC for publication. Please use ‘REPLY ALL’, > >> as all the parties CCed on this message need to see your approval. > >> > >> > >> Files > >> ----- > >> > >> The files are available here: > >> https://www.rfc-editor.org/authors/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 > > > > > >
- [auth48] AUTH48: RFC-to-be 9505 <draft-irtf-pearg… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9505 <draft-irtf-p… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9505 <draft-irtf-p… Dr. Joseph Lorenzo Hall
- Re: [auth48] AUTH48: RFC-to-be 9505 <draft-irtf-p… Mallory Knodel
- Re: [auth48] AUTH48: RFC-to-be 9505 <draft-irtf-p… Dr. Joseph Lorenzo Hall
- [auth48] [Doc Shepherd] Re: AUTH48: RFC-to-be 950… Alice Russo
- Re: [auth48] [Doc Shepherd] Re: AUTH48: RFC-to-be… Shivan Kaul Sahib
- Re: [auth48] [Doc Shepherd] Re: AUTH48: RFC-to-be… Mallory Knodel
- Re: [auth48] [Doc Shepherd] AUTH48: RFC-to-be 950… Alice Russo
- Re: [auth48] [Doc Shepherd] Re: AUTH48: RFC-to-be… Dr. Joseph Lorenzo Hall
- Re: [auth48] AUTH48: RFC-to-be 9505 <draft-irtf-p… Alice Russo
- [auth48] Amelia, Ben, Nick (Re: AUTH48: RFC-to-be… Mallory Knodel
- Re: [auth48] Amelia, Ben, Nick (Re: AUTH48: RFC-t… Michael A
- Re: [auth48] Amelia, Ben, Nick (Re: AUTH48: RFC-t… Amelia Andersdotter
- Re: [auth48] AUTH48: RFC-to-be 9505 <draft-irtf-p… Dr. Joseph Lorenzo Hall
- Re: [auth48] AUTH48: RFC-to-be 9505 <draft-irtf-p… Dr. Joseph Lorenzo Hall
- Re: [auth48] AUTH48: RFC-to-be 9505 <draft-irtf-p… Nick Feamster
- Re: [auth48] AUTH48: RFC-to-be 9505 <draft-irtf-p… Dr. Joseph Lorenzo Hall
- Re: [auth48] Nick - Re: AUTH48: RFC-to-be 9505 <d… Nick Feamster
- Re: [auth48] AUTH48: RFC-to-be 9505 <draft-irtf-p… Ben Jones
- Re: [auth48] AUTH48: RFC-to-be 9505 <draft-irtf-p… Dr. Joseph Lorenzo Hall
- Re: [auth48] AUTH48: RFC-to-be 9505 <draft-irtf-p… Mallory Knodel
- Re: [auth48] AUTH48: RFC-to-be 9505 <draft-irtf-p… Alice Russo
- Re: [auth48] AUTH48: RFC-to-be 9505 <draft-irtf-p… Dr. Joseph Lorenzo Hall
- [auth48] Nick - Re: AUTH48: RFC-to-be 9505 <draft… Alice Russo
- Re: [auth48] Nick - Re: AUTH48: RFC-to-be 9505 <d… Dr. Joseph Lorenzo Hall
- Re: [auth48] AUTH48: RFC-to-be 9505 <draft-irtf-p… Alice Russo
- Re: [auth48] AUTH48: RFC-to-be 9505 <draft-irtf-p… Dr. Joseph Lorenzo Hall