Hi, Last suggestion. I have discussed this with Mirja as well....
OLD: The analysis presented in [RAMESH-1 <https://www.rfc-editor.org/authors/rfc9707.html#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 <https://www.rfc-editor.org/authors/rfc9707.html#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
