Please update Mallory's email to malloryk@socialweb.foundation On Tue, Dec 17, 2024 at 12:44 PM Dhruv Dhody <d...@dhruvdhody.com> wrote:
> Hi, > > On Tue, Dec 17, 2024 at 4:54 AM <rfc-edi...@rfc-editor.org> wrote: > >> Authors and Suresh (as Document Shepherd), >> >> * Suresh, please reply to #14. >> >> While reviewing this document during AUTH48, please resolve (as >> necessary) the following questions, which are also in the XML file. >> >> 1) <!-- [rfced] We see that post-8073 IAB RFCs that discuss workshops >> use a different title format - along the lines of either "Report from >> the IAB Workshop on ..." (fairly common) or "IAB Workshop Report: >> Measuring Network Quality for End-Users" (RFC 9318 only). May we >> update the document title as follows? >> >> Original: >> IAB Barriers to Internet Access of Services (BIAS) Workshop Report >> >> Suggested: >> Report from the IAB Workshop on Barriers to Internet Access of >> Services (BIAS) >> --> >> >> > Dhruv: Ok > > > >> >> 2) <!-- [rfced] Abstract: We changed "Barriers for" to "Barriers to" >> per the document title and >> <https://datatracker.ietf.org/group/biasws/about/>. Please let us >> know any concerns. >> >> Original: >> The "Barriers for Internet Access of Services (BIAS)" workshop was >> convened by the Internet Architecture Board (IAB) from January 15-17, >> 2024 as a three-day online meeting. >> >> Currently: >> The "Barriers to Internet Access of Services (BIAS)" workshop was >> convened by the Internet Architecture Board (IAB) from January 15-17, >> 2024 as a three-day online meeting. --> >> >> > Dhruv: Ack > > > >> >> 3) <!-- [rfced] Please review the guidance for IAB documents >> (https://www.rfc-editor.org/materials/iab-format.txt) >> and let us know if any changes are needed. Specifically, >> would you like to add this paragraph to the introduction? >> >> "The following boilerplate paragraph SHOULD appear in the introduction: >> >> The Internet Architecture Board (IAB) holds occasional workshops >> designed to consider long-term issues and strategies for the >> Internet, and to suggest future directions for the Internet >> architecture. This long-term planning function of the IAB is >> complementary to the ongoing engineering efforts performed by >> working >> groups of the Internet Engineering Task Force (IETF)." >> --> >> >> > Dhruv: Please add > > > >> >> 4) <!-- [rfced] Section 1: We had trouble parsing this sentence. To >> what does "based on" refer? Also, please clarify "as well as due to". >> >> Original: >> This IAB workshop has aimed >> >> * to collect reports about barriers to accessing content and >> services on the Internet, e.g. based on filtering, and blocking as >> well as due to general inequality of technological capabilities, >> like device or protocol limitations. >> >> Possibly (we changed "has aimed" to "aimed", as the workshop took >> place about a year ago): >> This IAB workshop aimed to collect reports about barriers to >> accessing content and services on the Internet. For example, >> >> * based on filtering >> >> * based on blocking >> >> * due to general inequality of technological capabilities, e.g., >> device or protocol limitations. --> >> >> >> > Dhruv: I am fine with the rewording and converting it into a sub-list for > readability > > > >> 5) <!-- [rfced] Section 2.1.2: For ease of the reader, we expanded >> "LEO" as "low-Earth orbit" here, per [HU]. Please let us know >> any concerns. >> >> Original: >> [HU] highlighted that Satellite Internet provided by advanced LEO >> satellite constellations can play a pivotal role in closing the >> connectivity gap in the urban-rural digital divide via Satellite- >> dependent community networks. >> >> Currently: >> [HU] highlighted that Satellite Internet provided by advanced low- >> Earth orbit (LEO) satellite constellations can play a pivotal role in >> closing the connectivity gap in the urban-rural digital divide via >> Satellite-dependent Community Networks. --> >> >> >> > Dhruv: Ack > > > >> 6) <!-- [rfced] Section 2.1.2: To what does "it" refer in this >> sentence? >> >> Original (the previous sentence is included for context): >> Spectrum allocations directly impact industries and market >> access with ramifications for community networks. Further, there was >> a discussion on the geopolitical tension because of it. --> >> >> >> > Dhruv: it refers to spectrum allocations. > > > >> 7) <!-- [rfced] Section 2.2: This sentence is a bit unwieldy and >> difficult to follow. May we update as suggested? >> >> Original: >> Critical internet infrastructure affects many aspects of our society >> significantly, although differently, the inequitable aspects of which >> are typically referred to as "digital inclusion" signifying that in >> efforts to digitalise society, there are those left out due to what >> is typically called the "digital divide", a related term specific to >> access to the Internet. >> >> Suggested: >> Critical Internet infrastructure affects many aspects of our society >> significantly, although it impacts different parts of society >> differently. The inequitable aspects are typically referred to as >> "digital inclusion"; these aspects signify that in efforts to >> digitalize society, there are those left out due to what is >> typically called the "digital divide", a related term specific to >> access to the Internet. --> >> >> >> > Dhruv: Ack > > > >> 8) <!-- [rfced] Section 2.2: We found "at least three" and "Those were" >> a bit confusing, as only three aspects are listed. Also, as written, >> the third sentence indicates that sizes are downloaded. May we >> update as suggested? If not, please clarify the text. >> >> Original: >> Presentations of reports interrogated at >> least three key aspects of the digital divide, though there is >> recognition that there may be more technical aspects of the digital >> divide that were not present. Those were: differences between >> population demographics in the provision of online resources by >> governments, inequality in the use of multilingualized domains and >> email addresses, and increased costs for end-user downloads of >> contemporary websites' sizes. >> >> Suggested: >> Presentations of reports interrogated at >> least three key aspects of the digital divide, though it is >> recognized that there may be more technical aspects of the digital >> divide that were not addressed. Three of those aspects were: >> >> * differences between population demographics in the provision >> of online resources by governments. >> >> * inequality in the use of multilingualized domains and email >> addresses. >> >> * increased costs for end-user downloads of websites of >> contemporary sizes. >> --> >> >> > Dhruv: Ack > > > >> >> 9) <!-- [rfced] Section 2.2.2: This sentence as written indicated that >> the barriers, as opposed to equal rollout, were hindered. We updated >> to indicate that the equal rollout is hindered. Please review, and >> let us know if anything is incorrect. >> >> Original: >> Today there are around 150 internationalised domain names (IDNs) but >> the barriers to equal rollout of these scripts at the domain level >> are hindered primarily by software and applications that do not yet >> recognise these new scripts. >> >> Currently: >> Today, there are around 150 internationalized domain names (IDNs), >> but equal rollout of these scripts at the domain level is hindered >> primarily by software and applications that do not yet recognize >> these new scripts. --> >> >> >> > Dhruv: Ack > > > >> 10) <!-- [rfced] Section 2.3: We cannot determine what "specifically" >> and "example" refer to in this sentence. If the suggested text is >> not correct, please clarify the use of "specifically" and "example". >> >> Original: >> The censorship reports, with a focus on Asia, and specifically India, >> as well as Russia, as an example where censorship has changed >> significantly recently, discussed the legal frameworks and court acts >> that put legal obligations on regional network providers to block >> traffic. >> >> Suggested (assuming that "specifically" refers to India only and >> that "example" refers to Russia only): >> The censorship reports - with a focus on Asia and (specifically) >> India, as well as Russia (which provides an example of where >> censorship has changed significantly recently) - discussed the legal >> frameworks and court actions that put legal obligations on regional >> network providers to block traffic. --> >> >> >> > Dhruv: How about we change the order like - > > The censorship reports highlighted legal frameworks and > > court acts that put legal obligations on regional network > > providers to block traffic. The discussion focused on > > Asia, specifically India, and included Russia as an > > example where censorship practices have recently undergone > > significant changes. > > > >> 11) <!-- [rfced] Section 2.3.1: >> >> a) It is not clear what "either" refers to in this sentence. Also, >> we defined "OONI" as "Open Observatory of Network Interference" per >> <https://ooni.org/>. >> >> If the suggested text regarding "either" and the definition of "OONI" >> are not correct, please clarify the text. >> >> Original: >> The blocking was either confirmed by OONI >> measurements for existing blocking fingerprints, heuristics, i.e. for >> new blocking fingerprints as well as news reports of blocking orders, >> or user experiences. >> >> Suggested: >> The blocking was confirmed by either (1) Open >> Observatory of Network Interference (OONI) measurements for existing >> blocking fingerprints or heuristics (i.e., for new blocking >> fingerprints as well as news reports of blocking orders) or (2) user >> experiences. >> >> > Dhruv: Ack > > > >> b) Per Internet searches, a bogon address could be any one of a >> number of inappropriate addresses and is not necessarily 127.0.0.1. >> However, is 127.0.0.1 the only possible bogon address when discussing >> DNS? If not, should "(127.0.0.1)" be "(e.g., 127.0.0.1)"? >> >> Original: >> For DNS, either a decided >> IP address, a bogon IP address (127.0.0.1), or an empty domain >> (nxdomain) is used. --> >> >> >> > Dhruv: add e.g. > > > >> 12) <!-- [rfced] Section 2.3.1: We had trouble following these >> sentences, in part because the text related to the citation for >> [Singh2020]* has some issues. >> >> * We consulted <https://arxiv.org/pdf/1912.08590>, which provides the >> full [Singh2020] paper, and found that "27.64%" in the current text >> seems to be out of "4379", which is not correct. (The full paper >> mentions "only 1115 websites out of the 4033 (just 27.64%)"). >> >> (We have an item later in our list of questions for you, where we ask >> if we can update the URL for the reference listing so that readers >> can access the full Singh paper at no cost.) >> >> May we update the text as suggested? If not, please >> >> * clarify what "tested on" refers to >> >> * provide the correct definitions of "SNI", "IPSs" (noting that for >> now we changed "IPSs" to "ISPs"), and "IXP" >> >> * review the numbers provided in [Singh2020] and correct the >> numbers as needed. For example, because 1115 is 27.64% of 4033, we >> added "4033" to the suggested text below, per >> <https://arxiv.org/pdf/1912.08590>. >> >> > Dhruv: The current numbers might be based on what was there in the slides > presented - > https://datatracker.ietf.org/meeting/interim-2024-biasws-03/materials/slides-interim-2024-biasws-03-sessa-online-censorship-in-india-pakistan-and-indonesia-00, > in that case should we site the slide instead in this case? I will let > > > >> Original: >> [GROVER] further focused the discussion on online censorship in >> India, Pakistan, and Indonesia. In India, where providers are >> responsible for implementing the blocking but no method is mandated, >> the six major ISPs (covering 98.82% of all subscribers) were tested >> on 4379 blocked websites (based on court orders, user reports, and >> publicly available or leaked government orders) on DNS poisoning/ >> injection or HTTP/SNI-based censorship. Used censorship techniques >> and websites blocked were different across ISPs. Multiple ISPs used >> two different techniques (depending on the website), and all but one >> provided censorship notices. Providers blocked between 1892 to 3721 >> (of 4379) pages with only 1115 (27.64%) of pages blocked by all ISPs. >> [Singh2020] In contrast, in Pakistan, the government can also order >> the IPSs to perform blocking and blocking has even been observed in >> the past on the IXP level. >> >> Suggested (also assuming that "tested on" refers to DNS >> poisoning/injection or on censorship using HTTP or SNI): >> [GROVER] further focused the discussion on online censorship in >> India, Pakistan, and Indonesia. >> >> As discussed in [Singh2020], in India, where providers are >> responsible for implementing the blocking but no method is >> mandated, the six major ISPs (covering 98.82% of all subscribers) >> were tested on a total of 4379 blocked websites (based on court >> orders, user reports, and publicly available or leaked government >> orders) by using DNS poisoning/injection or using censorship based >> on HTTP or the Server Name Indication (SNI). The censorship >> techniques used and websites blocked were different across ISPs. >> Multiple ISPs used two different techniques (depending on the >> website), and all but one provided censorship notices. A list of >> 4379 potentially blocked websites was tested; 4033 of those websites >> appeared in at least one ISP's blocklist. Providers blocked between >> 1892 and 3721 of the 4033 websites, with only 1115 websites (27.64%) >> blocked by all six ISPs. >> >> In contrast, in Pakistan, the government can also order the ISPs to >> perform blocking, and blocking has even been observed in the past at >> the Internet Exchange Point (IXP) level. --> >> >> >> > Dhruv: LGTM! @Mirja Kuehlewind <i...@kuehlewind.net> Please check! > > > >> 13) <!-- [rfced] Section 2.3.2: In this sentence as written, it is not >> clear what "not upholding user expectations" refers to. It appears >> that in [RAMESH], "user expectations" is treated as a separate >> concept. May we update this sentence as suggested? >> >> Original: >> The analysis presented in [RAMESH] has shown various problems that >> lead to data leaks such as leakage of IPv6 traffic, non-browser >> traffic, or tunnel failure, not upholding user expectations, >> especially when used in authoritarian regimes for censorship >> circumvention or private communication. >> >> Suggested: >> The analysis presented in [RAMESH] has shown various problems that >> lead to data leaks, such as (1) leakage of IPv6 traffic, >> (2) non-browser traffic, or (3) tunnel failure, in addition to >> failing to uphold user expectations, especially when used in >> authoritarian regimes for censorship circumvention or private >> communication. --> >> >> >> > Dhruv: Ack > > > >> 14) <!-- [rfced] [Document Shepherd] We see that this document does not >> contain a Security Considerations section. Please see Section 4.8.5 >> of RFC 7322 (https://www.rfc-editor.org/info/rfc7322). Also, please >> provide appropriate text for this document. For example, should >> "security shortcomings" in Section 2.3.2 be mentioned/addressed? >> >> If you verify that security considerations do not apply to this >> document, we could add something like the following (as done in >> IAB RFCs 8700 ("Fifty Years of RFCs") and 9419 ("Considerations on >> Application - Network Collaboration Using Path Signals")): >> >> 4. Security Considerations >> >> This document has no security considerations. >> >> Please review and advise. --> >> >> > Dhruv: WFIW, I prefer the above. > > > >> >> 15) <!-- [rfced] References: The provided URL for [Singh2020] only >> provides the Abstract. May we update this listing as follows, so >> that readers may access the full article at no cost? >> >> Original: >> [Singh2020] >> Singh, K., Grover, G., and V. Bansal, "How India Censors >> the Web", July 2020, >> <https://dl.acm.org/doi/abs/10.1145/3394231.3397891>. >> >> Suggested: >> [Singh2020] >> Singh, K., Grover, G., and V. Bansal, "How India Censors >> the Web", WebSci '20: Proceedings of the 12th ACM >> Conference on Web Science, DOI 10.1145/3394231.3397891, >> July 2020, >> <https://arxiv.org/pdf/1912.08590>. --> >> >> >> > Dhruv: Ack > > > >> 16) <!-- [rfced] Appendix A: We see a list of twelve published papers >> under "This is the list of all published papers", but this sentence >> indicates eleven. Should we update to "twelve"? If not, should the >> M-Lab paper be placed in a separate category even though it's >> included in the list of accepted papers? >> >> Looking at <https://datatracker.ietf.org/group/biasws/materials/>, >> we see 26 (twenty-six) papers listed with "interim-2024-biasws-<##>", >> so "19 position papers" in the current text is also unclear to us. >> >> Please review, and let us know if any updates are needed. >> >> Original: >> 19 position papers were submitted to the workshop call for papers. 11 >> were selected for publication. --> >> >> > Dhruv: 12 is the correct number for accepted papers. > > > >> >> 17) <!-- [rfced] Appendix A: We had trouble following this sentence >> and updated it as noted below. Please review, and let us know if >> anything is incorrect. >> >> Also, please note that we changed "threads" to "threats" here. Please >> let us know if this is incorrect. >> >> In addition, please confirm that "prelimited"* is the correct word >> here and that "scope as dedicated for the workshop discussion" will >> be clear to readers; we do not understand the meaning of "dedicated >> for ..." >> >> * Please see <https://www.merriam-webster.com/dictionary/prelimited>. >> >> Original: >> Papers that were not published either >> (1) only provided a very prelimited analysis of an idea that was felt >> to be incomprehensive for discussion at the workshop, or (2) >> addressed problems that were beyond the scope as dedicated for the >> workshop discussion e.g. discussing cyber security threads as a >> barrier for participation or implication of technology in regulation >> that imposes blocking. >> >> Currently: >> Papers that were not >> published either (1) only provided a very prelimited analysis of an >> idea that was felt to be incomprehensive for discussion at the >> workshop or (2) addressed problems that were considered "beyond >> scope" as dedicated for the workshop discussion, e.g., discussing >> cybersecurity threats as a barrier to participation or implication >> of technology in a regulation that imposes blocking. >> >> Possibly: >> Papers that were not >> published either (1) only provided a very prelimited analysis of an >> idea that was felt to be incomprehensive for discussion at the >> workshop or (2) addressed problems that were considered beyond the >> scope of the workshop discussions, e.g., discussing cybersecurity >> threats as a barrier to participation or implication of technology >> in a regulation that imposes blocking. --> >> >> > Dhruv: I like this minimal rewording. > > > >> >> 18) <!-- [rfced] Appendix A: "risks might provide a high risk" reads >> oddly. May we update as suggested (assuming that "these risks" >> means "these scenarios")? >> >> Original: >> Both of these topics pose a potentially >> severe risk on the open Internet, however, these risks might provide >> a high risk for all Internet users but do not necessarily imply an >> unbalance. >> >> Suggested: >> Both of these >> scenarios pose a potentially severe risk for the open Internet; >> however, they might pose a high risk for all Internet users but do >> not necessarily imply an unbalance. --> >> >> >> > Dhruv: Ack > > > >> 19) <!-- [rfced] Appendix A: Would you like to add references for these >> two papers? We note other papers in this section have corresponding >> references. >> >> Current: >> * Ott, J., Bartolomeo, G., Bese, M.M., Bose, R., Bosk, M., Guzman, >> D., Kärkkäinen, L., Kosek, M., and N. Mohan: The Internet: Only >> for the Fast (and Furious)? >> >> * Ohlsen, L.Y.: BIAS workshop - M-Lab Position Paper submission >> >> Perhaps: >> * Ott, J., Bartolomeo, G., Bese, M.M., Bose, R., Bosk, M., Guzman, >> D., Kärkkäinen, L., Kosek, M., and N. Mohan: The Internet: Only >> for the Fast (and Furious)? [OTT] >> >> * Ohlsen, L.Y.: BIAS workshop - M-Lab Position Paper submission >> [OHLSEN] >> >> where in the References section: >> >> [OTT] Ott, J., Bartolomeo, G., Bese, M.M., Bose, R., Bosk, M., Guzman, >> D., Kärkkäinen, L., Kosek, M., and N. Mohan, "The Internet: Only >> for the Fast (and Furious)?", January 2024, >> < >> https://www.ietf.org/slides/slides-biasws-the-internet-only-for-the-fast-00.pdf >> >. >> >> [OHLSEN] Ohlsen, L.Y., "BIAS workshop - M-Lab Position Paper submission", >> [Date], < >> https://www.ietf.org/slides/slides-biasws-m-lab-position-paper-00.pdf>. >> NOTE: The PDF at that URL is errored and needs to be replaced. This has >> been reported >> to supp...@ietf.org. >> --> >> >> >> > Dhruv: Ack > > > >> 20) <!-- [rfced] Appendix A: We found this URL for this additional >> Ramesh paper: <https://www.usenix.org/conference/usenixsecurity23/ >> presentation/ramesh-vpn >> <https://www.usenix.org/conference/usenixsecurity23/presentation/ramesh-vpn> >> >. >> We suggest that it be cited here and included in the References >> section. >> >> Would it be acceptable to change [RAMESH] to [RAMESH-1] and use >> [RAMESH-2] for this paper? >> >> Original: >> * R. Ramesh, A. Vyas, R. Ensafi: "All of them claim to be the >> best": A multi-perspective study of VPN users and VPN providers >> >> Suggested: >> * Ramesh, R., Vyas, A., and R. Ensafi: "All of them claim to be the >> best: Multi-perspective study of VPN users and VPN providers" >> [RAMESH-2] >> >> In the References section: >> [RAMESH-2] Ramesh, R., Vyas, A., and R. Ensafi, "'All of them >> claim to be the best': Multi-perspective study of VPN >> users and VPN providers", 32nd USENIX Security >> Symposium (USENIX Security '23), 2023, >> <https://www.usenix.org/conference/usenixsecurity23/ >> presentation/ramesh-vpn>. --> >> >> >> > Dhruv: Ack > > > >> 21) <!-- [rfced] IAB Members at the Time of Approval: Please provide the >> list of IAB members at the time this document was approved for >> publication. >> >> Original: >> Internet Architecture Board members at the time this document was >> approved for publication were: TODO --> >> >> >> > Dhruv: The document was approved in July 2024. So you can safely use the > current IAB member list https://www.iab.org/about/members/ > > > >> 22) <!-- [rfced] Although this document discusses inclusiveness >> extensively, as part of our process we still need to ask you to >> review the "Inclusive Language" portion of the online Style Guide at >> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> >> and let us know if any changes are needed. Updates of this nature >> typically result in more precise language, which is helpful for >> readers. >> >> Note that our script did not flag any words in particular, but this >> should still be reviewed as a best practice. --> >> >> >> 23) <!-- [rfced] Please let us know if any changes are needed for the >> following: >> >> a) The following terms were used inconsistently in this document. >> We chose to use the latter forms. Please let us know any objections. >> >> block list / blocklist (Section 2.3.1) >> >> community network(s) (12 instances in text) / >> Community Network(s) (14 instances in text) (per RFC 7962) >> >> (Non-)Terrestrial / (non-)terrestrial >> >> b) The following terms appear to be used inconsistently in this >> document. Please let us know which form is preferred. >> >> internet / Internet (used generally, e.g., "the Internet community", >> "the internet community") >> >> internet access (1 instance) / Internet Access (2 instances) / >> Internet access (2 instances) (in text; used generally) >> (We also see "in Internet Access of Services" in the Abstract.) >> >> satellite / Satellite (e.g., "satellite constellations", >> "via Satellite-dependent community networks") >> >> > Dhruv: Ack > > > >> c) Please let us know how/if the following should be made consistent >> (asking because "circumvents" is normally a verb; please see >> <https://www.merriam-webster.com/dictionary/circumvents>): >> >> circumvents (noun) / circumvention (noun) --> >> >> > Dhruv: perhaps - > > OLD: > 2.3.2. Use of VPNs for Censorship Circumvents and User Expectations > NEW: > 2.3.2. Use of VPNs for Censorship Circumventions and User Expectations > > OLD: > 2.3.3. Discussion > > After all, there is a cat-and-mouse game between censors and > circumvents; however, continued work on protocol enhancements that > protect user privacy is essential. > NEW > 2.3.3. Discussion > > After all, there is a cat-and-mouse game between censorship and > circumvention; however, continued work on protocol enhancements that > protect user privacy is essential. > END > > Thanks! > Dhruv > > > >> Thank you. >> >> RFC Editor/lb/ar >> >> On Dec 16, 2024, rfc-edi...@rfc-editor.org wrote: >> >> *****IMPORTANT***** >> >> Updated 2024/12/16 >> >> RFC Author(s): >> -------------- >> >> Instructions for Completing AUTH48 >> >> Your document has now entered AUTH48. Once it has been reviewed and >> approved by you and all coauthors, it will be published as an RFC. >> If an author is no longer available, there are several remedies >> available as listed in the FAQ (https://www.rfc-editor.org/faq/). >> >> You and you coauthors are responsible for engaging other parties >> (e.g., Contributors or Working Group) as necessary before providing >> your approval. >> >> Planning your review >> --------------------- >> >> Please review the following aspects of your document: >> >> * RFC Editor questions >> >> Please review and resolve any questions raised by the RFC Editor >> that have been included in the XML file as comments marked as >> follows: >> >> <!-- [rfced] ... --> >> >> These questions will also be sent in a subsequent email. >> >> * Changes submitted by coauthors >> >> Please ensure that you review any changes submitted by your >> coauthors. We assume that if you do not speak up that you >> agree to changes submitted by your coauthors. >> >> * Content >> >> Please review the full content of the document, as this cannot >> change once the RFC is published. Please pay particular attention to: >> - IANA considerations updates (if applicable) >> - contact information >> - references >> >> * Copyright notices and legends >> >> Please review the copyright notice and legends as defined in >> RFC 5378 and the Trust Legal Provisions >> (TLP – https://trustee.ietf.org/license-info). >> >> * Semantic markup >> >> Please review the markup in the XML file to ensure that elements of >> content are correctly tagged. For example, ensure that <sourcecode> >> and <artwork> are set correctly. See details at >> <https://authors.ietf.org/rfcxml-vocabulary>. >> >> * Formatted output >> >> Please review the PDF, HTML, and TXT files to ensure that the >> formatted output, as generated from the markup in the XML file, is >> reasonable. Please note that the TXT will have formatting >> limitations compared to the PDF and HTML. >> >> >> Submitting changes >> ------------------ >> >> To submit changes, please reply to this email using ‘REPLY ALL’ as all >> the parties CCed on this message need to see your changes. The parties >> include: >> >> * your coauthors >> >> * rfc-edi...@rfc-editor.org (the RPC team) >> >> * other document participants, depending on the stream (e.g., >> IETF Stream participants are your working group chairs, the >> responsible ADs, and the document shepherd). >> >> * auth48archive@rfc-editor.org, which is a new archival mailing list >> to preserve AUTH48 conversations; it is not an active discussion >> list: >> >> * More info: >> >> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc >> >> * The archive itself: >> https://mailarchive.ietf.org/arch/browse/auth48archive/ >> >> * Note: If only absolutely necessary, you may temporarily opt out >> of the archiving of messages (e.g., to discuss a sensitive matter). >> If needed, please add a note at the top of the message that you >> have dropped the address. When the discussion is concluded, >> auth48archive@rfc-editor.org will be re-added to the CC list and >> its addition will be noted at the top of the message. >> >> You may submit your changes in one of two ways: >> >> An update to the provided XML file >> — OR — >> An explicit list of changes in this format >> >> Section # (or indicate Global) >> >> OLD: >> old text >> >> NEW: >> new text >> >> You do not need to reply with both an updated XML file and an explicit >> list of changes, as either form is sufficient. >> >> We will ask a stream manager to review and approve any changes that seem >> beyond editorial in nature, e.g., addition of new text, deletion of text, >> and technical changes. Information about stream managers can be found in >> the FAQ. Editorial changes do not require approval from a stream manager. >> >> >> Approving for publication >> -------------------------- >> >> To approve your RFC for publication, please reply to this email stating >> that you approve this RFC for publication. Please use ‘REPLY ALL’, >> as all the parties CCed on this message need to see your approval. >> >> >> Files >> ----- >> >> The files are available here: >> https://www.rfc-editor.org/authors/rfc9707.xml >> https://www.rfc-editor.org/authors/rfc9707.html >> https://www.rfc-editor.org/authors/rfc9707.pdf >> https://www.rfc-editor.org/authors/rfc9707.txt >> >> Diff file of the text: >> https://www.rfc-editor.org/authors/rfc9707-diff.html >> https://www.rfc-editor.org/authors/rfc9707-rfcdiff.html (side by side) >> >> Diff of the XML: >> https://www.rfc-editor.org/authors/rfc9707-xmldiff1.html >> >> >> Tracking progress >> ----------------- >> >> The details of the AUTH48 status of your document are here: >> https://www.rfc-editor.org/auth48/rfc9707 >> >> Please let us know if you have any questions. >> >> Thank you for your cooperation, >> >> RFC Editor >> >> -------------------------------------- >> RFC9707 (draft-iab-bias-workshop-report-02) >> >> Title : IAB Barriers to Internet Access of Services (BIAS) >> Workshop Report >> Author(s) : M. Kühlewind, D. Dhody, M. Knodel >> >>
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
