Hi, Dhruv. Please note that my email address has changed to <lbartholo...@staff.rfc-editor.org>.
We have further updated this document per your note below. 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 (side by side) https://www.rfc-editor.org/authors/rfc9707-auth48diff.html https://www.rfc-editor.org/authors/rfc9707-auth48rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9707-lastdiff.html https://www.rfc-editor.org/authors/rfc9707-lastrfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9707-xmldiff1.html https://www.rfc-editor.org/authors/rfc9707-xmldiff2.html We have noted your approval on the AUTH48 status page: https://www.rfc-editor.org/auth48/rfc9707 Thank you! RFC Editor/lb > On Jan 21, 2025, at 10:49 PM, Dhruv Dhody <d...@dhruvdhody.com> wrote: > > Hi, > > Last suggestion. I have discussed this with Mirja as well.... > > OLD: > The analysis presented in [RAMESH-1] 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. > NEW: > The analysis presented in [RAMESH-1] highlights various issues that lead to > data leaks—such as the leakage of IPv6 traffic, non-browser traffic, or > failures in tunneling—resulting in a failure to meet user expectations, > particularly in scenarios involving censorship circumvention or private > communication in authoritarian regimes. > END > > Please mark my AUTH48 approval after this change. > > Thanks! > Dhruv > > > On Tue, Jan 7, 2025 at 11:15 PM Lynne Bartholomew <lbartholo...@amsl.com> > wrote: > Hi, Mirja, Wes, and Mallory. > > Mirja, please see our [rfced] notes inline below. > > 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-lastdiff.html > https://www.rfc-editor.org/authors/rfc9707-lastrfcdiff.html > > https://www.rfc-editor.org/authors/rfc9707-xmldiff1.html > https://www.rfc-editor.org/authors/rfc9707-xmldiff2.html > > Please review our latest updates carefully, and let us know if anything is > incorrect. > > Thank you! > > RFC Editor/lb > > > > On Dec 20, 2024, at 11:28 AM, Mallory Knodel > > <malloryk@socialweb.foundation> wrote: > > > > That makes good sense to me, Mirja. And I’m sorry we are using the wrong > > email for me in this chain— I’m fine with cdt as affiliation at the time > > (probably worth noting in the text bc it’s otherwise confusing) but I need > > the author details to change with NYU as affiliation and my NYU email as > > contact. > > > > Thank you! > > > > Executive Director, Social Web Foundation > > > > > On Dec 20, 2024, at 10:24 AM, Mirja Kuehlewind (IETF) <i...@kuehlewind.net> > > wrote: > > > > I think the question about authorship is different and I think needs to be > > decided by the person based on an own assessment on a case by case basis. > > However, for IAB docs we usually don’t have author affiliations as we just > > say IAB. If Mallory wants to add her current affiliation to the authors > > info that would be totally fine for me as she is not on the IAB anymore > > either. > > > > However, for the PC and workshop participation, which are separate sections > > in the appendix, I really think we should give the affiliation, if at all, > > of the time of when the workshop happened. Because this might provide > > actual information about the kind of input that was provided to the > > workshop. > > > > Mirja > > > > > On Dec 20, 2024, at 9:50 AM, Wes Hardaker <harda...@isi.edu> wrote: > > > > > > > >> No I actually think this should reflect the affiliation at the time of the > >> workshop, > > > > I think this is a problem much bigger than workshops. RFCs come into the > > same question at times when a draft gets to AUTH48 sometimes authors > > change their affiliation at the last second. > > > > As everyone knows, the IETF is an odd place where "we work as individuals > > but yet somehow the company name still really really matters". I cloud see > > CDT being annoyed at losing publicity (as would potentially cisco, or USC, > > or Mozilla, or ...). > > > >> or we could just remove affiliation in that section completely for all. In > >> other reports I found both cases, with or without affiliation. Maybe we > >> could also established a common practice for future reports…? > > > > It does seem the last few we've published removes affiliation, which makes > > sense. Though it does remove transparency to easily detect if one company > > flooded the workshop or something. > > > > -- > > Wes Hardaker > > USC/ISI > > > > > On Dec 20, 2024, at 8:41 AM, Mirja Kuehlewind (IETF) <i...@kuehlewind.net> > > wrote: > > > > 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> 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. > > [rfced] Reverted to running text. > > > > > > >> > >> 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. > > [rfced] Reverted to running text. > > > > >> > >> > >> 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. > > [rfced] Updated; please review. > > > > >> > >> 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 Please check! > > > > > > Mirja: Please revert and propose other changes if needed. > > [rfced] Reverted. > > > > >> > >> 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. > > [rfced] Reverted. > > > > >> > >> 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. > > [rfced] Agreed that the section isn't necessary in this case, but for the > time being, we need to follow our current process, which includes asking the > Document Shepherd for approval. > > That being said, would you like us to set precedent here by removing the > Security Considerations and asking the Document Shepherd for approval of the > new form? > > > > >> > >> > >> 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. > > [rfced] Reverted, with the exception of "threads". > > > > >> > >> > >> 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”. > > [rfced] Changed back to "topics". > > > > >> > >> 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 > > > > > > 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>. > >> 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 > >> > > > > On Dec 20, 2024, at 7:40 AM, Mirja Kuehlewind (IETF) <i...@kuehlewind.net> > > wrote: > > > > Hi all, > > > > No I actually think this should reflect the affiliation at the time of the > > workshop, or we could just remove affiliation in that section completely > > for all. In other reports I found both cases, with or without affiliation. > > Maybe we could also established a common practice for future reports…? > > > > Also for the participants list, I looked at 2-3 reports and it looks like > > we usually don’t have people listed with affiliation. However, for the new > > AI-CONTROL report we will do that. I think that part is actually the more > > important piece of information and I think we should by default list all > > participants with affiliation for future workshops. Thoughts? > > > > Mirja > > > > > > > > > > > >> On 18. Dec 2024, at 21:02, Mallory Knodel <malloryk@socialweb.foundation> > >> wrote: > >> > >> Hi, > >> > >> Please change my affiliation to NYU. Email should be > >> mallory.kno...@nyu.edu Thanks! > >> > >> Executive Director, Social Web Foundation > >> > >> > >> On Wed, Dec 18, 2024 at 14:50 Lynne Bartholomew <lbartholo...@amsl.com> > >> wrote: > >> Hi, Mallory. > >> > >> Is "Mallory Knodel (IAB, Center for Democracy and Technology)" in Appendix > >> C of RFC-to-be 9707 still correct (because it was your affiliation at the > >> time), or should we update your affiliation? If you'd like to update, > >> please provide the correct affiliation information. > >> > >> Thank you! > >> > >> RFC Editor/lb > >> > >> > On Dec 18, 2024, at 11:42 AM, Mallory Knodel <mkno...@cdt.org> wrote: > >> > > >> > Thank you for your message! I am no longer at CDT and I can instead be > >> > reached at malloryk@socialweb.foundation or 917-796-6884. > >> > > >> > -- > >> > Mallory Knodel > >> > CTO, Center for Democracy and Technology > >> > gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780 > >> > > >> > > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
