Hi, Mallory. We have noted your approval: https://www.rfc-editor.org/auth48/rfc9707
Thank you! RFC Editor/lb > On Jan 30, 2025, at 9:17 AM, Mallory Knodel <malloryk@socialweb.foundation> > wrote: > > Approve from me > > Executive Director, Social Web Foundation > > > On Wed, Jan 22, 2025 at 11:47 Lynne Bartholomew > <lbartholo...@staff.rfc-editor.org> wrote: > 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
