Hi, Dhruv. Thank you for your prompt replies!
Thanks also for the updated email address for Mallory. Is "Center for Democracy and Technology" in Appendix C still correct? We have a few more follow-up items for you: = = = = = Regarding this question and your reply: >> 12) <!-- [rfced] Section 2.3.1: We had trouble following these >> sentences, in part because the text related to the citation for >> [Singh2020]* has some issues. >> >> * We consulted <https://arxiv.org/pdf/1912.08590>, which provides the >> full [Singh2020] paper, and found that "27.64%" in the current text >> seems to be out of "4379", which is not correct. (The full paper >> mentions "only 1115 websites out of the 4033 (just 27.64%)"). >> >> (We have an item later in our list of questions for you, where we ask >> if we can update the URL for the reference listing so that readers >> can access the full Singh paper at no cost.) >> >> May we update the text as suggested? If not, please >> >> * clarify what "tested on" refers to >> >> * provide the correct definitions of "SNI", "IPSs" (noting that for >> now we changed "IPSs" to "ISPs"), and "IXP" >> >> * review the numbers provided in [Singh2020] and correct the >> numbers as needed. For example, because 1115 is 27.64% of 4033, we >> added "4033" to the suggested text below, per >> <https://arxiv.org/pdf/1912.08590>. >> > > Dhruv: The current numbers might be based on what was there in the slides > presented - > https://datatracker.ietf.org/meeting/interim-2024-biasws-03/materials/slides-interim-2024-biasws-03-sessa-online-censorship-in-india-pakistan-and-indonesia-00, > in that case should we site the slide instead in this case? I will let > >> Original: >> [GROVER] further focused the discussion on online censorship in >> India, Pakistan, and Indonesia. In India, where providers are >> responsible for implementing the blocking but no method is mandated, >> the six major ISPs (covering 98.82% of all subscribers) were tested >> on 4379 blocked websites (based on court orders, user reports, and >> publicly available or leaked government orders) on DNS poisoning/ >> injection or HTTP/SNI-based censorship. Used censorship techniques >> and websites blocked were different across ISPs. Multiple ISPs used >> two different techniques (depending on the website), and all but one >> provided censorship notices. Providers blocked between 1892 to 3721 >> (of 4379) pages with only 1115 (27.64%) of pages blocked by all ISPs. >> [Singh2020] In contrast, in Pakistan, the government can also order >> the IPSs to perform blocking and blocking has even been observed in >> the past on the IXP level. >> >> Suggested (also assuming that "tested on" refers to DNS >> poisoning/injection or on censorship using HTTP or SNI): >> [GROVER] further focused the discussion on online censorship in >> India, Pakistan, and Indonesia. >> >> As discussed in [Singh2020], in India, where providers are >> responsible for implementing the blocking but no method is >> mandated, the six major ISPs (covering 98.82% of all subscribers) >> were tested on a total of 4379 blocked websites (based on court >> orders, user reports, and publicly available or leaked government >> orders) by using DNS poisoning/injection or using censorship based >> on HTTP or the Server Name Indication (SNI). The censorship >> techniques used and websites blocked were different across ISPs. >> Multiple ISPs used two different techniques (depending on the >> website), and all but one provided censorship notices. A list of >> 4379 potentially blocked websites was tested; 4033 of those websites >> appeared in at least one ISP's blocklist. Providers blocked between >> 1892 and 3721 of the 4033 websites, with only 1115 websites (27.64%) >> blocked by all six ISPs. >> >> In contrast, in Pakistan, the government can also order the ISPs to >> perform blocking, and blocking has even been observed in the past at >> the Internet Exchange Point (IXP) level. --> > > > > Dhruv: LGTM! @Mirja Kuehlewind Please check! Apologies; we are not sure how best to update the text. [GROVER] is already cited, and we see "just 27.64% -- 1115 of 4033 websites" on Page 51 of [GROVER]; this seems to be the same as the information in the full [Singh2020] paper, so we're not sure why we should cite [GROVER] instead. We also saw the "Ack" reply for our question 15) re. possibly updating the provided URL for [Singh2020] so that readers can review the entire document; we went ahead and updated the URL. Please review, and let us know how best to update the text here. = = = = = Regarding this part of our question 19): ... >> [OHLSEN] Ohlsen, L.Y., "BIAS workshop - M-Lab Position Paper submission", >> [Date], >> <https://www.ietf.org/slides/slides-biasws-m-lab-position-paper-00.pdf>. >> NOTE: The PDF at that URL is errored and needs to be replaced. This has been >> reported >> to supp...@ietf.org. We found that when going to the PDF copy of the M-Lab paper via <https://datatracker.ietf.org/group/biasws/materials/>, we would sometimes get the "-00" paper (bad format) and sometimes get the "-01" paper (which looks fine). We changed the "00" to "01" in the URL. Please take a look at the "-01" paper, and let us know if that paper is correct and acceptable. = = = = = Regarding our question 23)b) and your reply: >> b) The following terms appear to be used inconsistently in this >> document. Please let us know which form is preferred. >> >> internet / Internet (used generally, e.g., "the Internet community", >> "the internet community") >> >> internet access (1 instance) / Internet Access (2 instances) / >> Internet access (2 instances) (in text; used generally) >> (We also see "in Internet Access of Services" in the Abstract.) >> >> satellite / Satellite (e.g., "satellite constellations", >> "via Satellite-dependent community networks") > > > Dhruv: Ack Please let us know which form is preferred for the three terms listed above. = = = = = The latest files are posted here. Please refresh your browser: https://www.rfc-editor.org/authors/rfc9707.txt https://www.rfc-editor.org/authors/rfc9707.pdf https://www.rfc-editor.org/authors/rfc9707.html https://www.rfc-editor.org/authors/rfc9707.xml https://www.rfc-editor.org/authors/rfc9707-diff.html https://www.rfc-editor.org/authors/rfc9707-rfcdiff.html https://www.rfc-editor.org/authors/rfc9707-auth48diff.html https://www.rfc-editor.org/authors/rfc9707-xmldiff1.html https://www.rfc-editor.org/authors/rfc9707-xmldiff2.html Thanks again! RFC Editor/lb > On Dec 16, 2024, at 11:33 PM, Dhruv Dhody <d...@dhruvdhody.com> wrote: > > Please update Mallory's email to malloryk@socialweb.foundation > On Dec 16, 2024, at 11:14 PM, Dhruv Dhody <d...@dhruvdhody.com> wrote: > > Hi, > > On Tue, Dec 17, 2024 at 4:54 AM <rfc-edi...@rfc-editor.org> wrote: > Authors and Suresh (as Document Shepherd), > > * Suresh, please reply to #14. > > While reviewing this document during AUTH48, please resolve (as necessary) > the following questions, which are also in the XML file. > > 1) <!-- [rfced] We see that post-8073 IAB RFCs that discuss workshops > use a different title format - along the lines of either "Report from > the IAB Workshop on ..." (fairly common) or "IAB Workshop Report: > Measuring Network Quality for End-Users" (RFC 9318 only). May we > update the document title as follows? > > Original: > IAB Barriers to Internet Access of Services (BIAS) Workshop Report > > Suggested: > Report from the IAB Workshop on Barriers to Internet Access of > Services (BIAS) > --> > > > Dhruv: Ok > > > 2) <!-- [rfced] Abstract: We changed "Barriers for" to "Barriers to" > per the document title and > <https://datatracker.ietf.org/group/biasws/about/>. Please let us > know any concerns. > > Original: > The "Barriers for Internet Access of Services (BIAS)" workshop was > convened by the Internet Architecture Board (IAB) from January 15-17, > 2024 as a three-day online meeting. > > Currently: > The "Barriers to Internet Access of Services (BIAS)" workshop was > convened by the Internet Architecture Board (IAB) from January 15-17, > 2024 as a three-day online meeting. --> > > > Dhruv: Ack > > > 3) <!-- [rfced] Please review the guidance for IAB documents > (https://www.rfc-editor.org/materials/iab-format.txt) > and let us know if any changes are needed. Specifically, > would you like to add this paragraph to the introduction? > > "The following boilerplate paragraph SHOULD appear in the introduction: > > The Internet Architecture Board (IAB) holds occasional workshops > designed to consider long-term issues and strategies for the > Internet, and to suggest future directions for the Internet > architecture. This long-term planning function of the IAB is > complementary to the ongoing engineering efforts performed by working > groups of the Internet Engineering Task Force (IETF)." > --> > > > Dhruv: Please add > > > 4) <!-- [rfced] Section 1: We had trouble parsing this sentence. To > what does "based on" refer? Also, please clarify "as well as due to". > > Original: > This IAB workshop has aimed > > * to collect reports about barriers to accessing content and > services on the Internet, e.g. based on filtering, and blocking as > well as due to general inequality of technological capabilities, > like device or protocol limitations. > > Possibly (we changed "has aimed" to "aimed", as the workshop took > place about a year ago): > This IAB workshop aimed to collect reports about barriers to > accessing content and services on the Internet. For example, > > * based on filtering > > * based on blocking > > * due to general inequality of technological capabilities, e.g., > device or protocol limitations. --> > > > > Dhruv: I am fine with the rewording and converting it into a sub-list for > readability > > 5) <!-- [rfced] Section 2.1.2: For ease of the reader, we expanded > "LEO" as "low-Earth orbit" here, per [HU]. Please let us know > any concerns. > > Original: > [HU] highlighted that Satellite Internet provided by advanced LEO > satellite constellations can play a pivotal role in closing the > connectivity gap in the urban-rural digital divide via Satellite- > dependent community networks. > > Currently: > [HU] highlighted that Satellite Internet provided by advanced low- > Earth orbit (LEO) satellite constellations can play a pivotal role in > closing the connectivity gap in the urban-rural digital divide via > Satellite-dependent Community Networks. --> > > > > Dhruv: Ack > > 6) <!-- [rfced] Section 2.1.2: To what does "it" refer in this > sentence? > > Original (the previous sentence is included for context): > Spectrum allocations directly impact industries and market > access with ramifications for community networks. Further, there was > a discussion on the geopolitical tension because of it. --> > > > > Dhruv: it refers to spectrum allocations. > > 7) <!-- [rfced] Section 2.2: This sentence is a bit unwieldy and > difficult to follow. May we update as suggested? > > Original: > Critical internet infrastructure affects many aspects of our society > significantly, although differently, the inequitable aspects of which > are typically referred to as "digital inclusion" signifying that in > efforts to digitalise society, there are those left out due to what > is typically called the "digital divide", a related term specific to > access to the Internet. > > Suggested: > Critical Internet infrastructure affects many aspects of our society > significantly, although it impacts different parts of society > differently. The inequitable aspects are typically referred to as > "digital inclusion"; these aspects signify that in efforts to > digitalize society, there are those left out due to what is > typically called the "digital divide", a related term specific to > access to the Internet. --> > > > > Dhruv: Ack > > 8) <!-- [rfced] Section 2.2: We found "at least three" and "Those were" > a bit confusing, as only three aspects are listed. Also, as written, > the third sentence indicates that sizes are downloaded. May we > update as suggested? If not, please clarify the text. > > Original: > Presentations of reports interrogated at > least three key aspects of the digital divide, though there is > recognition that there may be more technical aspects of the digital > divide that were not present. Those were: differences between > population demographics in the provision of online resources by > governments, inequality in the use of multilingualized domains and > email addresses, and increased costs for end-user downloads of > contemporary websites' sizes. > > Suggested: > Presentations of reports interrogated at > least three key aspects of the digital divide, though it is > recognized that there may be more technical aspects of the digital > divide that were not addressed. Three of those aspects were: > > * differences between population demographics in the provision > of online resources by governments. > > * inequality in the use of multilingualized domains and email > addresses. > > * increased costs for end-user downloads of websites of > contemporary sizes. > --> > > > Dhruv: Ack > > > 9) <!-- [rfced] Section 2.2.2: This sentence as written indicated that > the barriers, as opposed to equal rollout, were hindered. We updated > to indicate that the equal rollout is hindered. Please review, and > let us know if anything is incorrect. > > Original: > Today there are around 150 internationalised domain names (IDNs) but > the barriers to equal rollout of these scripts at the domain level > are hindered primarily by software and applications that do not yet > recognise these new scripts. > > Currently: > Today, there are around 150 internationalized domain names (IDNs), > but equal rollout of these scripts at the domain level is hindered > primarily by software and applications that do not yet recognize > these new scripts. --> > > > > Dhruv: Ack > > 10) <!-- [rfced] Section 2.3: We cannot determine what "specifically" > and "example" refer to in this sentence. If the suggested text is > not correct, please clarify the use of "specifically" and "example". > > Original: > The censorship reports, with a focus on Asia, and specifically India, > as well as Russia, as an example where censorship has changed > significantly recently, discussed the legal frameworks and court acts > that put legal obligations on regional network providers to block > traffic. > > Suggested (assuming that "specifically" refers to India only and > that "example" refers to Russia only): > The censorship reports - with a focus on Asia and (specifically) > India, as well as Russia (which provides an example of where > censorship has changed significantly recently) - discussed the legal > frameworks and court actions that put legal obligations on regional > network providers to block traffic. --> > > > > Dhruv: How about we change the order like - > > The censorship reports highlighted legal frameworks and > court acts that put legal obligations on regional network > providers to block traffic. The discussion focused on > Asia, specifically India, and included Russia as an > example where censorship practices have recently undergone > significant changes. > > 11) <!-- [rfced] Section 2.3.1: > > a) It is not clear what "either" refers to in this sentence. Also, > we defined "OONI" as "Open Observatory of Network Interference" per > <https://ooni.org/>. > > If the suggested text regarding "either" and the definition of "OONI" > are not correct, please clarify the text. > > Original: > The blocking was either confirmed by OONI > measurements for existing blocking fingerprints, heuristics, i.e. for > new blocking fingerprints as well as news reports of blocking orders, > or user experiences. > > Suggested: > The blocking was confirmed by either (1) Open > Observatory of Network Interference (OONI) measurements for existing > blocking fingerprints or heuristics (i.e., for new blocking > fingerprints as well as news reports of blocking orders) or (2) user > experiences. > > > Dhruv: Ack > > b) Per Internet searches, a bogon address could be any one of a > number of inappropriate addresses and is not necessarily 127.0.0.1. > However, is 127.0.0.1 the only possible bogon address when discussing > DNS? If not, should "(127.0.0.1)" be "(e.g., 127.0.0.1)"? > > Original: > For DNS, either a decided > IP address, a bogon IP address (127.0.0.1), or an empty domain > (nxdomain) is used. --> > > > > Dhruv: add e.g. > > 12) <!-- [rfced] Section 2.3.1: We had trouble following these > sentences, in part because the text related to the citation for > [Singh2020]* has some issues. > > * We consulted <https://arxiv.org/pdf/1912.08590>, which provides the > full [Singh2020] paper, and found that "27.64%" in the current text > seems to be out of "4379", which is not correct. (The full paper > mentions "only 1115 websites out of the 4033 (just 27.64%)"). > > (We have an item later in our list of questions for you, where we ask > if we can update the URL for the reference listing so that readers > can access the full Singh paper at no cost.) > > May we update the text as suggested? If not, please > > * clarify what "tested on" refers to > > * provide the correct definitions of "SNI", "IPSs" (noting that for > now we changed "IPSs" to "ISPs"), and "IXP" > > * review the numbers provided in [Singh2020] and correct the > numbers as needed. For example, because 1115 is 27.64% of 4033, we > added "4033" to the suggested text below, per > <https://arxiv.org/pdf/1912.08590>. > > > Dhruv: The current numbers might be based on what was there in the slides > presented - > https://datatracker.ietf.org/meeting/interim-2024-biasws-03/materials/slides-interim-2024-biasws-03-sessa-online-censorship-in-india-pakistan-and-indonesia-00, > in that case should we site the slide instead in this case? I will let > > Original: > [GROVER] further focused the discussion on online censorship in > India, Pakistan, and Indonesia. In India, where providers are > responsible for implementing the blocking but no method is mandated, > the six major ISPs (covering 98.82% of all subscribers) were tested > on 4379 blocked websites (based on court orders, user reports, and > publicly available or leaked government orders) on DNS poisoning/ > injection or HTTP/SNI-based censorship. Used censorship techniques > and websites blocked were different across ISPs. Multiple ISPs used > two different techniques (depending on the website), and all but one > provided censorship notices. Providers blocked between 1892 to 3721 > (of 4379) pages with only 1115 (27.64%) of pages blocked by all ISPs. > [Singh2020] In contrast, in Pakistan, the government can also order > the IPSs to perform blocking and blocking has even been observed in > the past on the IXP level. > > Suggested (also assuming that "tested on" refers to DNS > poisoning/injection or on censorship using HTTP or SNI): > [GROVER] further focused the discussion on online censorship in > India, Pakistan, and Indonesia. > > As discussed in [Singh2020], in India, where providers are > responsible for implementing the blocking but no method is > mandated, the six major ISPs (covering 98.82% of all subscribers) > were tested on a total of 4379 blocked websites (based on court > orders, user reports, and publicly available or leaked government > orders) by using DNS poisoning/injection or using censorship based > on HTTP or the Server Name Indication (SNI). The censorship > techniques used and websites blocked were different across ISPs. > Multiple ISPs used two different techniques (depending on the > website), and all but one provided censorship notices. A list of > 4379 potentially blocked websites was tested; 4033 of those websites > appeared in at least one ISP's blocklist. Providers blocked between > 1892 and 3721 of the 4033 websites, with only 1115 websites (27.64%) > blocked by all six ISPs. > > In contrast, in Pakistan, the government can also order the ISPs to > perform blocking, and blocking has even been observed in the past at > the Internet Exchange Point (IXP) level. --> > > > > Dhruv: LGTM! @Mirja Kuehlewind Please check! > > 13) <!-- [rfced] Section 2.3.2: In this sentence as written, it is not > clear what "not upholding user expectations" refers to. It appears > that in [RAMESH], "user expectations" is treated as a separate > concept. May we update this sentence as suggested? > > Original: > The analysis presented in [RAMESH] has shown various problems that > lead to data leaks such as leakage of IPv6 traffic, non-browser > traffic, or tunnel failure, not upholding user expectations, > especially when used in authoritarian regimes for censorship > circumvention or private communication. > > Suggested: > The analysis presented in [RAMESH] has shown various problems that > lead to data leaks, such as (1) leakage of IPv6 traffic, > (2) non-browser traffic, or (3) tunnel failure, in addition to > failing to uphold user expectations, especially when used in > authoritarian regimes for censorship circumvention or private > communication. --> > > > > Dhruv: Ack > > 14) <!-- [rfced] [Document Shepherd] We see that this document does not > contain a Security Considerations section. Please see Section 4.8.5 > of RFC 7322 (https://www.rfc-editor.org/info/rfc7322). Also, please > provide appropriate text for this document. For example, should > "security shortcomings" in Section 2.3.2 be mentioned/addressed? > > If you verify that security considerations do not apply to this > document, we could add something like the following (as done in > IAB RFCs 8700 ("Fifty Years of RFCs") and 9419 ("Considerations on > Application - Network Collaboration Using Path Signals")): > > 4. Security Considerations > > This document has no security considerations. > > Please review and advise. --> > > > Dhruv: WFIW, I prefer the above. > > > 15) <!-- [rfced] References: The provided URL for [Singh2020] only > provides the Abstract. May we update this listing as follows, so > that readers may access the full article at no cost? > > Original: > [Singh2020] > Singh, K., Grover, G., and V. Bansal, "How India Censors > the Web", July 2020, > <https://dl.acm.org/doi/abs/10.1145/3394231.3397891>. > > Suggested: > [Singh2020] > Singh, K., Grover, G., and V. Bansal, "How India Censors > the Web", WebSci '20: Proceedings of the 12th ACM > Conference on Web Science, DOI 10.1145/3394231.3397891, > July 2020, > <https://arxiv.org/pdf/1912.08590>. --> > > > > Dhruv: Ack > > 16) <!-- [rfced] Appendix A: We see a list of twelve published papers > under "This is the list of all published papers", but this sentence > indicates eleven. Should we update to "twelve"? If not, should the > M-Lab paper be placed in a separate category even though it's > included in the list of accepted papers? > > Looking at <https://datatracker.ietf.org/group/biasws/materials/>, > we see 26 (twenty-six) papers listed with "interim-2024-biasws-<##>", > so "19 position papers" in the current text is also unclear to us. > > Please review, and let us know if any updates are needed. > > Original: > 19 position papers were submitted to the workshop call for papers. 11 > were selected for publication. --> > > > Dhruv: 12 is the correct number for accepted papers. > > > 17) <!-- [rfced] Appendix A: We had trouble following this sentence > and updated it as noted below. Please review, and let us know if > anything is incorrect. > > Also, please note that we changed "threads" to "threats" here. Please > let us know if this is incorrect. > > In addition, please confirm that "prelimited"* is the correct word > here and that "scope as dedicated for the workshop discussion" will > be clear to readers; we do not understand the meaning of "dedicated > for ..." > > * Please see <https://www.merriam-webster.com/dictionary/prelimited>. > > Original: > Papers that were not published either > (1) only provided a very prelimited analysis of an idea that was felt > to be incomprehensive for discussion at the workshop, or (2) > addressed problems that were beyond the scope as dedicated for the > workshop discussion e.g. discussing cyber security threads as a > barrier for participation or implication of technology in regulation > that imposes blocking. > > Currently: > Papers that were not > published either (1) only provided a very prelimited analysis of an > idea that was felt to be incomprehensive for discussion at the > workshop or (2) addressed problems that were considered "beyond > scope" as dedicated for the workshop discussion, e.g., discussing > cybersecurity threats as a barrier to participation or implication > of technology in a regulation that imposes blocking. > > Possibly: > Papers that were not > published either (1) only provided a very prelimited analysis of an > idea that was felt to be incomprehensive for discussion at the > workshop or (2) addressed problems that were considered beyond the > scope of the workshop discussions, e.g., discussing cybersecurity > threats as a barrier to participation or implication of technology > in a regulation that imposes blocking. --> > > > Dhruv: I like this minimal rewording. > > > 18) <!-- [rfced] Appendix A: "risks might provide a high risk" reads > oddly. May we update as suggested (assuming that "these risks" > means "these scenarios")? > > Original: > Both of these topics pose a potentially > severe risk on the open Internet, however, these risks might provide > a high risk for all Internet users but do not necessarily imply an > unbalance. > > Suggested: > Both of these > scenarios pose a potentially severe risk for the open Internet; > however, they might pose a high risk for all Internet users but do > not necessarily imply an unbalance. --> > > > > Dhruv: Ack > > 19) <!-- [rfced] Appendix A: Would you like to add references for these > two papers? We note other papers in this section have corresponding > references. > > Current: > * Ott, J., Bartolomeo, G., Bese, M.M., Bose, R., Bosk, M., Guzman, > D., Kärkkäinen, L., Kosek, M., and N. Mohan: The Internet: Only > for the Fast (and Furious)? > > * Ohlsen, L.Y.: BIAS workshop - M-Lab Position Paper submission > > Perhaps: > * Ott, J., Bartolomeo, G., Bese, M.M., Bose, R., Bosk, M., Guzman, > D., Kärkkäinen, L., Kosek, M., and N. Mohan: The Internet: Only > for the Fast (and Furious)? [OTT] > > * Ohlsen, L.Y.: BIAS workshop - M-Lab Position Paper submission > [OHLSEN] > > where in the References section: > > [OTT] Ott, J., Bartolomeo, G., Bese, M.M., Bose, R., Bosk, M., Guzman, > D., Kärkkäinen, L., Kosek, M., and N. Mohan, "The Internet: Only > for the Fast (and Furious)?", January 2024, > > <https://www.ietf.org/slides/slides-biasws-the-internet-only-for-the-fast-00.pdf>. > > [OHLSEN] Ohlsen, L.Y., "BIAS workshop - M-Lab Position Paper submission", > [Date], > <https://www.ietf.org/slides/slides-biasws-m-lab-position-paper-00.pdf>. > NOTE: The PDF at that URL is errored and needs to be replaced. This has been > reported > to supp...@ietf.org. > --> > > > > Dhruv: Ack > > 20) <!-- [rfced] Appendix A: We found this URL for this additional > Ramesh paper: <https://www.usenix.org/conference/usenixsecurity23/ > presentation/ramesh-vpn>. > We suggest that it be cited here and included in the References > section. > > Would it be acceptable to change [RAMESH] to [RAMESH-1] and use > [RAMESH-2] for this paper? > > Original: > * R. Ramesh, A. Vyas, R. Ensafi: "All of them claim to be the > best": A multi-perspective study of VPN users and VPN providers > > Suggested: > * Ramesh, R., Vyas, A., and R. Ensafi: "All of them claim to be the > best: Multi-perspective study of VPN users and VPN providers" > [RAMESH-2] > > In the References section: > [RAMESH-2] Ramesh, R., Vyas, A., and R. Ensafi, "'All of them > claim to be the best': Multi-perspective study of VPN > users and VPN providers", 32nd USENIX Security > Symposium (USENIX Security '23), 2023, > <https://www.usenix.org/conference/usenixsecurity23/ > presentation/ramesh-vpn>. --> > > > > Dhruv: Ack > > 21) <!-- [rfced] IAB Members at the Time of Approval: Please provide the > list of IAB members at the time this document was approved for > publication. > > Original: > Internet Architecture Board members at the time this document was > approved for publication were: TODO --> > > > > Dhruv: The document was approved in July 2024. So you can safely use the > current IAB member list https://www.iab.org/about/members/ > > 22) <!-- [rfced] Although this document discusses inclusiveness > extensively, as part of our process we still need to ask you to > review the "Inclusive Language" portion of the online Style Guide at > <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> > and let us know if any changes are needed. Updates of this nature > typically result in more precise language, which is helpful for > readers. > > Note that our script did not flag any words in particular, but this > should still be reviewed as a best practice. --> > > > 23) <!-- [rfced] Please let us know if any changes are needed for the > following: > > a) The following terms were used inconsistently in this document. > We chose to use the latter forms. Please let us know any objections. > > block list / blocklist (Section 2.3.1) > > community network(s) (12 instances in text) / > Community Network(s) (14 instances in text) (per RFC 7962) > > (Non-)Terrestrial / (non-)terrestrial > > b) The following terms appear to be used inconsistently in this > document. Please let us know which form is preferred. > > internet / Internet (used generally, e.g., "the Internet community", > "the internet community") > > internet access (1 instance) / Internet Access (2 instances) / > Internet access (2 instances) (in text; used generally) > (We also see "in Internet Access of Services" in the Abstract.) > > satellite / Satellite (e.g., "satellite constellations", > "via Satellite-dependent community networks") > > > Dhruv: Ack > > c) Please let us know how/if the following should be made consistent > (asking because "circumvents" is normally a verb; please see > <https://www.merriam-webster.com/dictionary/circumvents>): > > circumvents (noun) / circumvention (noun) --> > > > Dhruv: perhaps - > > OLD: > 2.3.2. Use of VPNs for Censorship Circumvents and User Expectations > NEW: > 2.3.2. Use of VPNs for Censorship Circumventions and User Expectations > > OLD: > 2.3.3. Discussion > > After all, there is a cat-and-mouse game between censors and > circumvents; however, continued work on protocol enhancements that > protect user privacy is essential. > NEW > 2.3.3. Discussion > > After all, there is a cat-and-mouse game between censorship and > circumvention; however, continued work on protocol enhancements that > protect user privacy is essential. > END > > Thanks! > Dhruv > > > > Thank you. > > RFC Editor/lb/ar > > On Dec 16, 2024, rfc-edi...@rfc-editor.org wrote: > > *****IMPORTANT***** > > Updated 2024/12/16 > > 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-edi...@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/rfc9707.xml > https://www.rfc-editor.org/authors/rfc9707.html > https://www.rfc-editor.org/authors/rfc9707.pdf > https://www.rfc-editor.org/authors/rfc9707.txt > > Diff file of the text: > https://www.rfc-editor.org/authors/rfc9707-diff.html > https://www.rfc-editor.org/authors/rfc9707-rfcdiff.html (side by side) > > Diff of the XML: > https://www.rfc-editor.org/authors/rfc9707-xmldiff1.html > > > Tracking progress > ----------------- > > The details of the AUTH48 status of your document are here: > https://www.rfc-editor.org/auth48/rfc9707 > > Please let us know if you have any questions. > > Thank you for your cooperation, > > RFC Editor > > -------------------------------------- > RFC9707 (draft-iab-bias-workshop-report-02) > > Title : IAB Barriers to Internet Access of Services (BIAS) > Workshop Report > Author(s) : M. Kühlewind, D. Dhody, M. Knodel > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
