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)
-->
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. -->
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)."
-->
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. -->
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. -->
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. -->
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. -->
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.
-->
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. -->
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. -->
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.
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. -->
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>.
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. -->
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. -->
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. -->
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>. -->
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. -->
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. -->
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. -->
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.
-->
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>. -->
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 -->
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")
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) -->
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
