Hi Lynne, On Thu, Dec 19, 2024 at 1:12 AM Lynne Bartholomew <lbartholo...@amsl.com> wrote:
> 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? > > Dhruv: Mallory has responded to this and asked for a different email address to be used. > 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 > > Dhruv: Sorry, I forgot to remove this. You can disregard this comment! > > >> 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. > > Dhruv:Sorry for the confusion. I am happy with your proposed text. > = = = = = > > 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. > > Dhruv: please use the -01 > = = = = = > > 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") > >> Dhruv: Internet > >> 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.) > >> Dhruv: Internet access > > >> satellite / Satellite (e.g., "satellite constellations", > >> "via Satellite-dependent community networks") > > Dhruv: Satellite Thanks! Dhruv > > > > > 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
