Please see my comments also inline. > On 17. Dec 2024, at 08:14, Dhruv Dhody <d...@dhruvdhody.com> wrote: > > Hi, > > On Tue, Dec 17, 2024 at 4:54 AM <rfc-edi...@rfc-editor.org > <mailto: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
Mirja: yes, please. I think that is what we usually/in most cases use and we should try to unified this also in future. > > >> >> 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 Mirja: yes this is the correct name or the workshop. > > >> >> 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 Mirja: yes > > >> >> 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 Mirja: I don’t think the second oder bullet list is helpful here at all. Further I would actually not change this at all as this is directly taken from the workshop call for papers. > > >> 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 Mirja: Yes. Thanks! > > >> 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. Mirja: Maybe we can be even more specific here like this: OLD: Further, there was a discussion on geopolitical tensions because of these allocations. NEW Further, there was a discussion on the geopolitical tensions regarding the use of unlicensed spectrum and commercial interest in new spectrum usage. > > >> 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 Mirja: Yes, that’s good. > > >> 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 Mirja: I would go for something like “The three aspected presented and discussed were:”. Further I actually preference not to have a list here, as this sentence mailing covers an overview of the sections following afterwards. So, it more a summary of the section rather than an exhaustive list. > > >> >> 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 Mirja: yes > > >> 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. Mirja: I think Dhruv’s version is most clear. Thanks! > > >> 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 Mirja: No this is a list of three things: OONI measurements, heuristics, or user experience. > > >> 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. Mirja: yes 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 Mirja. This change is not correct. 4379 is the number from the slides Dhruv points to above on slide 16 and not from the Singh paper. The Singh paper reference is only used for the Pakistan numbers. > > >> 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 <mailto:i...@kuehlewind.net> Please check! Mirja: Please revert and propose other changes if needed. > > >> 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 Mirja: No this is not correct. “User expectation” is not a separate item. This is meant to say because certain traffic is leaked (e.g. ipv6, non-browser traffic or when there is a tunnel failure), this does not upload with user expectations. > > >> 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. Mirja: I don’t think security considerations are useful for workshop reports. All workshop reports that I’ve been involved with did not have security considerations but I did see that some other reports do. However, I assume they have mostly been added during AUTH48 based on this kind of request. Particularly just adding the sentence above is not useful and I wouldn’t want to do that just for the sake for process. If we want security consideration we should come up with real ones but as I said I don’t think we should just add anything to report in that respect. I think we should conclude with the IAB to not have security consideration for workshop reports in general in future. > > >> >> 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 Mirja: Yes please > > >> 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. Mirja: Yes 12 is correct for submitted and accepted papers. 19 were submitted but 7 were not accepted and respectively not published, i.e. those papers are not publicly available. Plus we had 2 invited papers. The rest of the material in the datatracker are slides only. > > >> >> 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. Mirja: I’m not sure here. The IAB has set the scope and the PC made a decision that the papers are out-of-scope. I think the rewording wrongly suggests that the PC had to set the scope. > > >> >> 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 Mirja: I’m not sure about the use of the term “scenario” here. That’s is not more clear to me than “topics”. In the previous sentence we use “problems”. > > >> 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 <mailto:supp...@ietf.org>. >> --> >> >> > > Dhruv: Ack Mirja: Yes, please. > > >> 20) <!-- [rfced] Appendix A: We found this URL for this additional >> Ramesh paper: <https://www.usenix.org/conference/usenixsecurity23/ >> presentation/ramesh-vpn >> <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 Mirja: Yes > > >> 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/ Mirja: yes, thanks! > > >> 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 Mirja: I actually would prefer lower case for all terms but Internet. > > >> 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 Mirja: Yes circumvention is fine. Thanks! > > Thanks! > Dhruv > > >> >> Thank you. >> >> RFC Editor/lb/ar >> >> On Dec 16, 2024, rfc-edi...@rfc-editor.org >> <mailto: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 <mailto: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 <mailto: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 <mailto: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
