rfc9501.original | rfc9501.txt | |||
---|---|---|---|---|
Network Working Group M. Kühlewind | Internet Engineering Task Force (IETF) M. Kühlewind | |||
Internet-Draft Ericsson | Request for Comments: 9501 Ericsson | |||
Intended status: Best Current Practice J. Reed | BCP: 239 J. Reed | |||
Expires: 29 February 2024 R. Salz | Category: Best Current Practice R. Salz | |||
Akamai Technologies | ISSN: 2070-1721 Akamai Technologies | |||
28 August 2023 | December 2023 | |||
Open Participation Principle regarding Remote Registration Fee | Open Participation Principle regarding Remote Registration Fee | |||
draft-ietf-shmoo-remote-fee-09 | ||||
Abstract | Abstract | |||
This document outlines a principle for open participation that | This document outlines a principle for open participation that | |||
extends the open process principle defined in RFC3935 by stating that | extends the open process principle defined in RFC 3935 by stating | |||
there must be a free option for online participation to IETF meetings | that there must be a free option for online participation to IETF | |||
and, if possible, related IETF-hosted events over the Internet. | meetings and, if possible, related IETF-hosted events. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This memo documents an Internet Best Current Practice. | |||
provisions of BCP 78 and BCP 79. | ||||
Internet-Drafts are working documents of the Internet Engineering | ||||
Task Force (IETF). Note that other groups may also distribute | ||||
working documents as Internet-Drafts. The list of current Internet- | ||||
Drafts is at https://datatracker.ietf.org/drafts/current/. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | This document is a product of the Internet Engineering Task Force | |||
and may be updated, replaced, or obsoleted by other documents at any | (IETF). It represents the consensus of the IETF community. It has | |||
time. It is inappropriate to use Internet-Drafts as reference | received public review and has been approved for publication by the | |||
material or to cite them other than as "work in progress." | Internet Engineering Steering Group (IESG). Further information on | |||
BCPs is available in Section 2 of RFC 7841. | ||||
This Internet-Draft will expire on 29 February 2024. | Information about the current status of this document, any errata, | |||
and how to provide feedback on it may be obtained at | ||||
https://www.rfc-editor.org/info/rfc9501. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2023 IETF Trust and the persons identified as the | Copyright (c) 2023 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents | |||
license-info) in effect on the date of publication of this document. | (https://trustee.ietf.org/license-info) in effect on the date of | |||
Please review these documents carefully, as they describe your rights | publication of this document. Please review these documents | |||
and restrictions with respect to this document. Code Components | carefully, as they describe your rights and restrictions with respect | |||
extracted from this document must include Revised BSD License text as | to this document. Code Components extracted from this document must | |||
described in Section 4.e of the Trust Legal Provisions and are | include Revised BSD License text as described in Section 4.e of the | |||
provided without warranty as described in the Revised BSD License. | Trust Legal Provisions and are provided without warranty as described | |||
in the Revised BSD License. | ||||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction | |||
2. Principle of Open Participation . . . . . . . . . . . . . . . 3 | 2. Principle of Open Participation | |||
3. Financial Impact . . . . . . . . . . . . . . . . . . . . . . 4 | 3. Financial Impact | |||
4. Considerations on Use and Misuse of a Free Participation | 4. Considerations on Use and Misuse of a Free Participation Option | |||
Option . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 5. Security Considerations | |||
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 | 6. IANA Considerations | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 | 7. References | |||
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 | 7.1. Normative References | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 7.2. Informative References | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . 7 | Acknowledgments | |||
8.2. Informative References . . . . . . . . . . . . . . . . . 7 | Authors' Addresses | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 | ||||
1. Introduction | 1. Introduction | |||
Remote participation for IETF in-person meetings has evolved over | Remote participation for IETF in-person meetings has evolved over | |||
time from email-only to live chat and audio streaming, and, | time from email-only to live chat and audio streaming, and, from | |||
subsequently, to a full online meeting system that is tightly | there, to a fully online meeting system that is tightly integrated | |||
integrated with the in-room session and enables interactive | with the in-room session and enables interactive audio and video | |||
participation by audio and video. Remote participation has | participation. Remote participation has historically been free for | |||
historically been free for remote attendees. | remote attendees. | |||
Given this more full-blown participation option, the IETF has started | Given this more full-blown participation option, the IETF has started | |||
seeing an increasing number of remote participants. This increase | to see an increase in the number of remote participants. This | |||
can be explained by the ease with which new participants can join a | increase can be explained by the ease with which new participants can | |||
meeting or only attend selected parts of the meeting agenda, and also | join a meeting or only attend selected parts of the meeting agenda, | |||
by a less strongly perceived need to attend every meeting in person. | and also by a decrease in the perceived need to attend every meeting | |||
Financial considerations may also be a factor. In order to better | in person. Financial considerations may also be a factor. In order | |||
understand these trends, the IETF started requiring registration for | to better understand these trends, the IETF started to require | |||
remote participation, still without any registration fee applied. | registration for remote participation, still without any registration | |||
fee applied. | ||||
With the move to fully online meetings in 2020 and 2021, however, | With the move to fully online meetings in 2020 and 2021, however, | |||
there was no longer a distinction between remote and on-site | there was no distinction between remote and on-site participants for | |||
participants for those meetings. Since IETF meeting costs and other | those meetings. Because IETF meeting costs and other costs still | |||
costs still had to be covered, a meeting fee was charged for remote | needed to be covered, a meeting fee was charged for remote | |||
participants, replacing the free participation that was previously | participants, replacing the free participation that was previously | |||
available for all remote attendees. | available for all remote attendees. | |||
The introduction of a fee for remote participation raised concerns | The introduction of a fee for remote participation raised concerns | |||
about the potential impact on both, those who regularly remotely | about the potential impact on both those who regularly attend IETF | |||
attend IETF meetings and those people considering attending an IETF | meetings remotely and those who are considering attending an IETF | |||
meeting for the first time. In both cases, even a small registration | meeting for the first time. In both cases, even a small registration | |||
fee can be a barrier to participation. | fee can be a barrier to participation. | |||
2. Principle of Open Participation | 2. Principle of Open Participation | |||
This document outlines the principle of open participation that the | This document outlines the principle of open participation that the | |||
IETF Administration LLC (IETF LLC) is expected to incorporate into | IETF Administration LLC (IETF LLC) is expected to incorporate into | |||
decisions about the registration fee structure for remote | decisions about the registration fee structure for remote | |||
participation. | participation. | |||
The principle this document states is simple: there must be an option | The principle is simple: there must be an option for free remote | |||
for free remote participation in any IETF meeting, regardless of | participation in any IETF meeting, regardless of whether the meeting | |||
whether the meeting has a physical presence. Related events | has a physical presence. Related events collocated with an IETF | |||
collocated with an IETF meeting are part of the IETF's open process | meeting are part of the IETF's open process [RFC3935] and are | |||
[RFC3935] and are encouraged to follow this principle as well, if | encouraged to follow this principle as well, if they offer remote | |||
they offer remote participation at all. | participation at all. | |||
This principle aims to support the openness principle of the IETF as | This principle aims to support the openness principle of the IETF as | |||
defined in [RFC3935]: | defined in [RFC3935]: | |||
"Open process - any interested person can participate in the work, | | Open process - any interested person can participate in the work, | |||
know what is being decided, and make his or her voice heard on the | | know what is being decided, and make his or her voice heard on the | |||
issue. Part of this principle is our commitment to making our | | issue. Part of this principle is our commitment to making our | |||
documents, our WG mailing lists, our attendance lists, and our | | documents, our WG mailing lists, our attendance lists, and our | |||
meeting minutes publicly available on the Internet." | | meeting minutes publicly available on the Internet. | |||
While RFC3935 explicitly notes that this principle includes a | While [RFC3935] explicitly notes that this principle requires our | |||
requirement to open basically all our documents and material and to | documents and materials to be open and accessible over the Internet, | |||
make them accessible over the Internet, it was written with mainly | it was primarily written with email interactions in mind when talking | |||
having email interactions in mind when talking about participation. | about participation. This document extends this principle to | |||
This document extends this principle to explicitly cover remote | explicitly cover remote participation at meetings. Particularly in | |||
participation at meetings. Particularly in this context, openness | this context, openness should be seen as open and free. | |||
should be seen as open and free. | ||||
This document does not stipulate that all IETF meetings or related | This document does not stipulate that all IETF meetings or related | |||
IETF events must have a remote participation option, because there | IETF events must have a remote participation option, because there | |||
could be technical or other reasons why that might not always be | could be technical or other reasons why that might not be possible. | |||
possible. This document rather states that if remote participation | However, if remote participation is provided, there should always be | |||
is provided, there should always be a free option to make the process | a free option to make the process as open as possible. At a minimum, | |||
as open as possible. This document does not specify the | working group sessions, BoFs, and the administrative plenary are | |||
implementation details of the free option and leaves this to the LLC. | expected to provide a remote participation option. | |||
At the time of publication an approach to request a fee waiver was | ||||
implemented. Further, it is of course strongly anticipated that at | Note that this document does not specify the implementation details | |||
least all working group sessions as well as BoFs and the | of the free option and leaves this to the LLC. At the time of | |||
administrative plenary of an IETF meeting provide an option for | publication, an approach to request a fee waiver was implemented. | |||
remote participation. | ||||
Moreover, in order to fully remove barriers to participation, any | Moreover, in order to fully remove barriers to participation, any | |||
free registration option must offer the same degree of interactivity | free registration option must offer the same degree of interactivity | |||
and functionality available to paid remote participants. | and functionality available to paid remote participants. | |||
Specifically, it must not be possible to identify participants that | Specifically, it must not be possible to identify participants that | |||
used the free option. However, of course this does not mean that all | used the free option. However, of course this does not mean that all | |||
services must be provided for free to participants using the free | services must be provided for free to participants using the free | |||
registration option, but only those services that are provided as | registration option, but only those services that are provided as | |||
part of the regular registration. Offering additional services to a | part of the regular registration. Offering additional services to a | |||
subset or all participants at an additional charge is still possible, | subset or all participants at an additional charge is still possible, | |||
e.g. if special needs are required. However, to promote inclusivity, | e.g., if special needs are required. However, to promote | |||
it should also be considered if those services can also be offered | inclusivity, whether those services can also be offered without | |||
without charge for those in need and who cannot afford the fee. | charge for those who are in need and cannot afford the fee should be | |||
considered. | ||||
Further, the free option must be clearly and prominently listed on | The free option must be clearly and prominently listed on the meeting | |||
the meeting website and registration page. If the free option | website and registration page. If the free option requires | |||
requires additional registration steps, such as applying for a fee | additional registration steps, such as applying for a fee waiver, | |||
waiver, those requirements should be clearly documented. | those requirements should be clearly documented. In particular, to | |||
Particularly, to avoid any potential negative implications on | avoid any potential negative implications on inclusivity, any | |||
inclusivity, any personal information that is collected with respect | personal information that is collected with respect to the use of the | |||
to the use of the free remote participation option must be kept | free remote participation option must be kept confidential. | |||
confidential. | ||||
3. Financial Impact | 3. Financial Impact | |||
Fully online meetings as well as remote participation incur expenses, | Fully online meetings as well as remote participation incur expenses, | |||
as do other services that the IETF provides. This includes items | as do other services that the IETF provides. This includes items | |||
such as mailing lists, document access via the datatracker or other | such as mailing lists, document access via the datatracker or other | |||
online platforms, as well as support for videoconferencing, like use | online platforms, as well as support for videoconferencing (e.g., | |||
of Meetecho and others. Meeting fees are a way to distribute these | Meetecho). Meeting fees are a way to distribute these and other | |||
and other operating costs of the IETF among participants, even though | operating costs of the IETF among participants, even though they do | |||
they do not fully offset the costs of either holding the meeting or | not fully offset the costs of either holding the meeting or operating | |||
operating the IETF. As such, the intention of this document and the | the IETF. As such, the intention of this document and the principle | |||
principle stated herein is not to make remote participation free for | stated herein is not to make remote participation free for everyone, | |||
everyone, but to always offer a free remote option that enables | but to always offer a free remote option that enables remote | |||
remote participation without any barriers other than the application | participation without any barriers other than the application for | |||
for the free registration itself when the registration fee is a | free registration when the registration fee is a barrier to | |||
barrier to participation. This principle applies to remote | participation. This principle applies to remote participation only, | |||
participation only, providing thereby one free option for | thereby providing one free option for participation. In-person | |||
participation. In-person participation is not in scope for this | participation is not in scope for this document as the cost | |||
document as the cost considerations are broader than just the | considerations are broader than just the registration fee. | |||
registration fee. | ||||
It is not in scope for this document to make suggestions for changing | Changes to the IETF's fee structure or overall funding model are not | |||
the IETF's fee structure or overall funding model. As defined in | in scope for this document. As defined in [RFC8711], it is the IETF | |||
RFC8711, it is the IETF LLC's responsibility to manage the IETF's | LLC's responsibility to manage the IETF's finances and budget and as | |||
finances and budget and as such "[t]he IETF LLC is expected to act | such "[t]he IETF LLC is expected to act responsibly so as to minimize | |||
responsibly so as to minimize risks to IETF participants and to the | risks to IETF participants and to the future of the IETF as a whole, | |||
future of the IETF as a whole, such as financial risks." Further, it | such as financial risks." Further, it is the responsibility of the | |||
is the responsibility of the IETF LLC Board "to act consistently with | IETF LLC Board "to act consistently with the documented consensus of | |||
the documented consensus of the IETF community" [RFC8711], taking | the IETF community" [RFC8711], taking into account agreed principles | |||
agreed principles like the one proposed in this document into | like the one described in this document. | |||
account. | ||||
If unlimited free remote participation is determined to adversely | If unlimited free remote participation is determined to adversely | |||
affect financial sustainability of the IETF, e.g. if the number of | affect financial sustainability of the IETF, e.g., if the number of | |||
paying participants or the cost of free participation emerges to be a | paying participants or the cost of free participation emerges as a | |||
significant factor, the LLC is expected to implement additional | significant factor, the LLC is expected to implement additional | |||
measures to manage these costs. This document does not and cannot | measures to manage these costs. This document does not and cannot | |||
restrict the LLC in its financial responsibility and therefore does | restrict the LLC in its financial responsibility and therefore does | |||
not impose any limitation on the use of appropriate measures. If the | not impose any limitation on the use of appropriate measures. If the | |||
LLC decides to do this, they should make their decision and rationale | LLC decides to implement additional measures, they should share their | |||
known to the community and consider community consultation as | decision and rationale with the community and consider whether | |||
specified in Section 4.4 of RFC8711 in order "to obtain consensus- | community consultation as specified in Section 4.4 of [RFC8711] is | |||
based community input on key issues". Further, they should describe | needed "to obtain consensus-based community input on key issues". | |||
the implemented process in sufficient detail for participants to make | Further, they should describe the implemented process in sufficient | |||
an informed decision about the use of the free option. | detail for participants to make an informed decision about use of the | |||
free option. | ||||
As discussed in the next section, assessment of eligibility is | As discussed in the next section, assessment of eligibility is | |||
difficult. Consequently, any limit on the number of available free | difficult. Consequently, any limit on the number of available free | |||
registrations, which likely requires an assessment of eligibility, | registrations, which likely requires an assessment of eligibility, | |||
can cause unfairness and negatively impact openness which should be | can cause unfairness and negatively impact openness, which should be | |||
considered seriously in any LLC decision. As such, this document | considered seriously in any LLC decision. As such, this document | |||
defines the principle of free participation but leaves room for | defines the principle of free participation but leaves implementation | |||
choices in the implementation by the LLC. Specifically, it cannot | details to the LLC. Specifically, it does not provide guidance on | |||
provide guidance on appropriate measures against misuse as any | appropriate measures against misuse, as any measures need to be | |||
measures need to be adapted to the specific problem in a specific | adapted to the specific problem in a specific situation in order to | |||
situation in order to minimise both the financial risk as well as its | minimize both the financial risk and its impact on openness and | |||
impact on openness and inclusivity. | inclusivity. | |||
4. Considerations on Use and Misuse of a Free Participation Option | 4. Considerations on Use and Misuse of a Free Participation Option | |||
This document does not provide specific requirements on when it is | This document does not provide specific requirements on when it is | |||
appropriate for an IETF community member to use or not use the free | appropriate for an IETF community member to use or not use the free | |||
option to remotely attend a meeting. The purpose of the free option | option to remotely attend a meeting. The purpose of the free option | |||
is to enable everybody who is interested in participation to join | is to enable everybody who is interested in participation to join | |||
meetings without the meeting fee imposing a financial barrier. These | meetings without the meeting fee imposing a financial barrier. These | |||
cases cannot be limited to a certain group, like students or "self- | cases cannot be limited to a certain group, like students or "self- | |||
funded" participants, nor to any specific other restrictions like the | funded" participants, nor to any other specific restrictions like the | |||
number of meetings previously attended or previous level of | number of meetings previously attended or previous level of | |||
involvement. The purpose is simply to maximise participation without | involvement. The purpose is simply to maximize participation without | |||
barriers in order to make the standards process as open as possible. | barriers in order to make the standards process as open as possible. | |||
It is expected that participants who have financial support to use | It is expected that participants who have financial support to use | |||
the paid regular registration option will do so. Paying a | the paid regular registration option will do so. Paying a | |||
registration fee is a way for their sponsor to support the | registration fee is a way for their sponsor to support the | |||
sustainability of the IETF. For example, a higher late payment | sustainability of the IETF. For example, a higher late payment | |||
charge can be used to maximise this financial support. However, this | charge can be used to maximize this financial support. However, this | |||
document does not comment on the actual payment structure of the IETF | document does not comment on the actual payment structure of the IETF | |||
meeting fee other than the requirement for a free option. The fee | meeting fee other than requiring a free remote option. The fee | |||
payment structure is set by the IETF LLC such that the viability of | payment structure is set by the IETF LLC such that the viability of | |||
the IETF and the ability of IETF participants to work productively | the IETF and the ability of IETF participants to work productively | |||
within the IETF can be ensured. | within the IETF can be ensured. | |||
The LLC is responsible to ensure the financial stability of the IETF | The LLC is responsible for ensuring the financial stability of the | |||
and therefore should monitor trends in the use of the free | IETF; therefore, they should monitor trends in the use of the free | |||
participation option that could endanger the viability of the IETF | participation option that could endanger the viability of the IETF | |||
and, if necessary, manage the associated costs. Aggregated data on | and, if necessary, manage the associated costs. Aggregated data on | |||
the number and percentage of free registrations used should be | the number and percentage of free registrations used should be | |||
published, as this will permit analysis of the use and change in use | published, as this will permit analysis of the use and change in use | |||
over time of the free registration option without revealing personal | over time of the free registration option without revealing personal | |||
information. | information. | |||
As the principle defined in this document aims to promote openness | As the principle defined in this document aims to promote openness | |||
and thereby enhance participation, an increase in use of free | and thereby enhance participation, an increase in use of free | |||
registrations is a success, likely a sign of increased interest, not | registrations is a success, because it is likely a sign of increased | |||
necessarily a sign of misuse, and should not be linked to the number | interest and not necessarily a sign of misuse. The increase should | |||
of paid registrations. In particular, the number of paid | not be linked to the number of paid registrations. In particular, | |||
registrations may decrease due to various reasons other than misuse, | the number of paid registrations may decrease for various reasons | |||
such as restrictions on travel to physical meetings due to cost | other than misuse, such as restrictions on travel to physical | |||
savings or environmental reasons, general cost savings and lesser | meetings due to cost savings or environmental reasons, general cost | |||
focus on standardization work, or simply loss of business interest. | savings and lesser focus on standardization work, or simply loss of | |||
Such trends can impact the sustainability of the IETF due to its | business interest. Such trends can impact the sustainability of the | |||
dependency on meetings fees to cross-finance other costs, independent | IETF due to its dependency on meeting fees to cross-finance other | |||
of use of the free registrations. | costs, independent of use of the free registrations. | |||
5. Security Considerations | 5. Security Considerations | |||
This document introduces no new concerns for the security of Internet | This document introduces no new concerns for the security of Internet | |||
protocols. | protocols. | |||
6. IANA Considerations | 6. IANA Considerations | |||
This document has no IANA actions. | This document has no IANA actions. | |||
7. Acknowledgments | 7. References | |||
Thanks to everybody involved in the shmoo working group discussion, | ||||
especially Brian Carpenter, Jason Livingood, Lars Eggert, and Charles | ||||
Eckel for proposing concrete improvements and their in-depth reviews. | ||||
8. References | ||||
8.1. Normative References | 7.1. Normative References | |||
[RFC3935] Alvestrand, H., "A Mission Statement for the IETF", | [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", | |||
BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004, | BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004, | |||
<https://www.rfc-editor.org/rfc/rfc3935>. | <https://www.rfc-editor.org/info/rfc3935>. | |||
8.2. Informative References | 7.2. Informative References | |||
[RFC8711] Haberman, B., Hall, J., and J. Livingood, "Structure of | [RFC8711] Haberman, B., Hall, J., and J. Livingood, "Structure of | |||
the IETF Administrative Support Activity, Version 2.0", | the IETF Administrative Support Activity, Version 2.0", | |||
BCP 101, RFC 8711, DOI 10.17487/RFC8711, February 2020, | BCP 101, RFC 8711, DOI 10.17487/RFC8711, February 2020, | |||
<https://www.rfc-editor.org/rfc/rfc8711>. | <https://www.rfc-editor.org/info/rfc8711>. | |||
Acknowledgments | ||||
Thanks to everybody involved in the SHMOO Working Group discussion, | ||||
especially Brian Carpenter, Jason Livingood, Lars Eggert, and Charles | ||||
Eckel for proposing concrete improvements and their in-depth reviews. | ||||
Authors' Addresses | Authors' Addresses | |||
Mirja Kühlewind | Mirja Kühlewind | |||
Ericsson | Ericsson | |||
Email: mirja.kuehlewind@ericsson.com | Email: mirja.kuehlewind@ericsson.com | |||
Jon Reed | Jon Reed | |||
Akamai Technologies | Akamai Technologies | |||
Email: jreed@akamai.com | Email: jreed@akamai.com | |||
End of changes. 35 change blocks. | ||||
163 lines changed or deleted | 157 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |