Internet Engineering Task Force J. Daley
Internet-Draft IETF Administration LLC
Intended status: Informational 28 April 2025
Expires: 30 October 2025
IETF Network Requirements
draft-daley-meeting-network-requirements-00
Abstract
This document aims to initiate a conversation to clarify the way
forward to address disagreements within the community about the
requirements for the IETF meeting network, how it is delivered and
whether or not the current cost and effort of providing the network
is reasonable.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 30 October 2025.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Daley Expires 30 October 2025 [Page 1]
Internet-Draft IETF Network Requirements April 2025
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Requirements that the IETF Network currently aims to meet . . 4
4.1. The meeting networks and their purposes . . . . . . . . . 4
4.1.1. Conference network . . . . . . . . . . . . . . . . . 5
4.1.2. Hotel network . . . . . . . . . . . . . . . . . . . . 5
4.1.3. Experimental network . . . . . . . . . . . . . . . . 5
4.2. Expectations of how these networks should be operated . . 6
4.2.1. High performance and robust . . . . . . . . . . . . . 7
4.2.2. Low friction . . . . . . . . . . . . . . . . . . . . 7
4.2.3. Good access to network data, without compromising
privacy . . . . . . . . . . . . . . . . . . . . . . . 7
4.2.4. Every participant needs to be able to participate
fully . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2.5. Early adopter of relevant, production-ready IETF
standards . . . . . . . . . . . . . . . . . . . . . . 7
4.2.6. Open, transparent and community-led development . . . 8
5. How the IETF Network is currently delivered . . . . . . . . . 8
5.1. IETF NOC . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Conference network . . . . . . . . . . . . . . . . . . . 8
5.2.1. Approach . . . . . . . . . . . . . . . . . . . . . . 8
5.2.2. Equipment and services . . . . . . . . . . . . . . . 9
5.2.3. Set up and management . . . . . . . . . . . . . . . . 10
5.2.4. Multiple SSIDs . . . . . . . . . . . . . . . . . . . 10
5.3. Experimental network . . . . . . . . . . . . . . . . . . 11
5.3.1. Test SSIDs . . . . . . . . . . . . . . . . . . . . . 11
5.3.2. Hackathon network . . . . . . . . . . . . . . . . . . 11
5.3.3. Local experimental networks . . . . . . . . . . . . . 12
5.4. Hotel network . . . . . . . . . . . . . . . . . . . . . . 12
5.5. Remote participation services . . . . . . . . . . . . . . 12
5.6. Support . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.7. Network data . . . . . . . . . . . . . . . . . . . . . . 13
5.8. Cost . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Meeting networks at other meetings . . . . . . . . . . . . . 14
6.1. NANOG . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. W3C . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Areas of disagreement . . . . . . . . . . . . . . . . . . . . 15
8. Next steps . . . . . . . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Informative References . . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
Daley Expires 30 October 2025 [Page 2]
Internet-Draft IETF Network Requirements April 2025
1. Introduction
The network that IETF participants use at an IETF Meeting has been a
high-profile feature of IETF Meetings for some time and is now a
major part of the behind-the-scenes work and cost of running an IETF
Meeting. This network replaces any venue network using equipment
donated by suppliers, installed and managed by a mixed team of
volunteers and contractors.
There are disagreements within the community about the requirements
for this network, how it is delivered and whether or not the current
cost and effort of providing the network is reasonable.
The IETF Administration LLC (IETF LLC) has overall responsibility for
delivering IETF Meetings to meet community-set requirements including
managing the meeting costs and service provision. However, the IETF
LLC is unclear on what the path is to resolve these disagreements.
This is important because they get to the heart of the requirements
for the IETF Network and the resulting provision of that network.
The main area of uncertainty is whether this is a community matter
that requires a community-led process to determine an outcome such as
an RFC, or this is for the IETF LLC to lead on and make decisions
through its normal consultative processes.
This document aims to initiate a conversation to clarify the way
forward. To do this, it provides a full primer on the facts needed
to understand the current situation and the areas of disagreement.
This includes It sets out the current high-level requirements for the
IETF Network, an overview of how the IETF Network is delivered, how
this relates back to the requirements and where the areas of
disagreement are.
2. Terms
IETF Network: Used generically to mean the network used by IETF
participants at an IETF meeting, however it is provided.
Remote Participation Services (RPS): The service and all the parts
that go with it that allows remote people to participate in an
IETF Meeting.
Meeting Tool: The tool participants must use during the meeting in
order to participate.
3. Background
[BCP226] gives the following relevant mandatory criterion for venue
selection:
Daley Expires 30 October 2025 [Page 3]
Internet-Draft IETF Network Requirements April 2025
| It MUST be possible to provision Internet Access to the Facility
| and IETF Hotels that allows those attending in person to utilize
| the Internet for all their IETF, business, and day-to-day needs;
| in addition, there must be sufficient bandwidth and access for
| remote attendees. Provisions include, but are not limited to,
| native and unmodified IPv4 and IPv6 connectivity, and global
| reachability; there may be no additional limitation that would
| materially impact their Internet use. To ensure availability, it
| MUST be possible to provision redundant paths to the Internet.
It further goes on to give the following important, but not
mandatory, relevant criteria:
| * The Facility's support technologies and services -- network,
| audio-video, etc. -- are sufficient for the anticipated
| activities at the meeting, or the Facility is willing to add
| such infrastructure, or these support technologies and services
| might be provided by a third party, all at no -- or at an
| acceptable -- cost to the IETF.
|
| * The IETF Hotels directly provide, or else permit and
| facilitate, the delivery of a high performance, robust,
| unfiltered, and unmodified Internet service for the public
| areas and guest rooms; this service is to be included in the
| cost of the room.
In summary, this sets out requirements for a meeting network,
conceptually split into two networks:
* Conference network
* Hotel network
It also sets the the following required attributes for those
networks:
* Unfiltered and unmodified.
* High performance and robust.
4. Requirements that the IETF Network currently aims to meet
4.1. The meeting networks and their purposes
Daley Expires 30 October 2025 [Page 4]
Internet-Draft IETF Network Requirements April 2025
4.1.1. Conference network
The mandatory criterion in [BCP226] is clear that the core purpose of
the IETF Network is a conference network, which includes "all their
IETF, business, and day-to-day needs".
In addition it requires that "there must be sufficient bandwidth and
access for remote attendees". However, in practice this requirement
has expanded in scope and importance as it is no longer possible to
run an IETF Meeting without full support for the RPS and Meeting
Tool:
* Over time, and boosted by the period during the COVID-pandemic
when IETF Meetings went fully online, the level of active remote
participation has grown considerably, and IETF Meetings have
become dependent on the RPS to support this.
* Several meeting practices now rely on the Meeting Tool, including
the use of the queuing feature for all speakers at the microphone,
recording meeting participation and the use of the poll feature to
replace humming.
4.1.2. Hotel network
The requirement for a hotel network (irrespective of how it is
delivered) is set in [BCP226] as documented above, but this does not
explain why this is a requirement.
One possible reason is that IETF participants have a higher
dependency on the reliability of the hotel network than other hotel
guests due to the nature of IETF participation, explained as follows.
As evidenced by annual community surveys, participation in the IETF
is a part-time activity for a very high percentage of participants.
During the week of an IETF meeting, participants spend a much higher
proportion of their working week on IETF activities than otherwise,
which pushes many to work on their day job work and other personal
commitments out of hours, from their hotel rooms, thereby increasing
their dependency on the hotel network.
4.1.3. Experimental network
In addition to a conference network and a hotel network, the IETF
Network also fulfills the purpose of an experimental network.
Running code is a key part of the IETF process. As documented in
[BCP205] "there are benefits to the IETF standardization process of
producing implementations of protocol specifications before
Daley Expires 30 October 2025 [Page 5]
Internet-Draft IETF Network Requirements April 2025
publication as RFCs". Producing protocol implementations is, by
definition, experimental on a network and so brings with it specific
requirements that would not ordinarily be supported, such as:
* Running networking equipment with experimental features on them.
* Providing an SSID which implements an experimental feature.
* Sending packets that are built in ways that production equipment
cannot recognise.
Such experimentation can have an adverse impact on a production
network and therefore needs to be clearly managed to prevent that.
4.2. Expectations of how these networks should be operated
Only the first of the following expectations is documented in a BCP.
The rest have been understood by the IETF NOC, over many years of
running the IETF Network, to be the expectations of the IETF
community. These latter expectations do not have community consensus
and have not been sufficiently reviewed to understand if they are
mandatory or just desirable.
These expectations do not equally apply to the conference, hotel and
experimental networks. The following table shows where they apply:
+==============================+============+=======+==============+
| | Conference | Hotel | Experimental |
+==============================+============+=======+==============+
| High performance and robust | x | x | - |
+------------------------------+------------+-------+--------------+
| Low friction | x | x | - |
+------------------------------+------------+-------+--------------+
| Good access to network data, | x | x | x |
| without compromising privacy | | | |
+------------------------------+------------+-------+--------------+
| Every participant needs to | x | - | - |
| be able to participate fully | | | |
+------------------------------+------------+-------+--------------+
| Early adopter of relevant, | x | - | - |
| production-ready IETF | | | |
| standards | | | |
+------------------------------+------------+-------+--------------+
| Open, transparent and | x | x | x |
| community-led development | | | |
+------------------------------+------------+-------+--------------+
Table 1
Daley Expires 30 October 2025 [Page 6]
Internet-Draft IETF Network Requirements April 2025
4.2.1. High performance and robust
This expectation is set in [BCP226] and is taken to mean ample
bandwidth, WiFi coverage everywhere, and 100% uptime experienced by
all participants. In other words, "it just works".
4.2.2. Low friction
The assumed expectation here is that using the network should involve
as little friction as possible. This is generally taken as
minimising the need for participants to take a manual action to use
the network for ordinary purposes.
4.2.3. Good access to network data, without compromising privacy
While not a documented expectation, there have been enough individual
requests from IETF participants for good access to data on the IETF
Network that this is considered a general expectation. The reasons
for these requests vary from general interest to assisting people in
assessing if any changes are needed to either the network
requirements or how it is delivered.
The general privacy expectations of the IETF community are well
documented and it is therefore assumed that access to network data
must not compromise privacy.
4.2.4. Every participant needs to be able to participate fully
The expectation is that every participant is fully able to
participate, as a requirement of the standards process. In practice,
this means that old (legacy) equipment is supported beyond what might
be commonly supported.
4.2.5. Early adopter of relevant, production-ready IETF standards
The expectation here is that when a relevant IETF standard reaches
the point where it is considered production-ready, work begins to
implement it on the IETF Network. "Production ready" means that a
number of conditions are met:
* It is fully supported across all of the equipment that is part of
the provision.
* The IETF NOC has sufficient knowledge and experience to support
its use.
* All vendor support is identified by that vendor as production-
ready not experimental support.
Daley Expires 30 October 2025 [Page 7]
Internet-Draft IETF Network Requirements April 2025
4.2.6. Open, transparent and community-led development
It is a general expectation of the IETF community that all of the
custom-developed tools and services that it relies on (not off-the-
shelf tools and services), are developed in an open and transparent
fashion that provides ample opportunity for IETF participants to
share their views on how they should be developed, and that this
development takes those views into consideration.
5. How the IETF Network is currently delivered
5.1. IETF NOC
The IETF Network is delivered by the IETF NOC, which consists of four
parts:
* A paid NOC lead.
* A team of volunteers, drawn primarily from long-term IETF
participants.
* A team provided by a professional conference networking company.
* A team provided by a professional remote participation services
company.
5.2. Conference network
5.2.1. Approach
The IETF NOC provides its own conference network separate from that
provided by a venue, by installing equipment and services at the
venue.
The reasoning for this approach is based on the experiences of many
IETF NOC members (including those who work professionally on
conference networks) regarding venue networks:
* Venue networks are rarely capable of delivering the requirements
for the IETF Network, specifically:
- Rarely able to deliver IPv6
- Rarely able to cope with the number and variety of different
devices (designed for coverage, not density)
- Rarely provide an onsite helpdesk
Daley Expires 30 October 2025 [Page 8]
Internet-Draft IETF Network Requirements April 2025
- Rarely support recent wireless standards and features
- Rarely provide significant privacy protection
- Rarely able to support HackNet (see below)
- Rarely provides visibility into network usage
- Sometimes do not have sufficient bandwidth
- Sometimes have filtering or other traffic modification
* It is not possible to test the performance and reliability of
venue networks well enough in advance to trust them (too many
problems appear with scale and variety of clients)
5.2.2. Equipment and services
The equipment itself is stored between IETF Meetings by the
professional conference networking company and shipped to each venue.
The volume of this equipment is substantial, taking up a full rack
and multiple other boxes.
* *1Gb/s or 10Gb/s Internet connection**, almost always donated by a
local provider. For some venues the provider installs a new fibre
into the venue to deliver this connection.
* *Router(s)**.
* *Access points*, controllers* and switches** to provide WiFi
coverage over the entire venue.
* *Servers** that provide core services such as DHCP and DNS, and
onsite monitoring and management.
* *Raspberry Pis* for network monitoring.
* *Cameras, tripods, and A/V control equipment* for providing the
remote participation services.
* *Dedicated IPv4 and IPv6 address blocks* that are ‘owned’ by the
IETF.
Items marked with * are donated by IETF sponsors - major equipment
providers that are significantly engaged in the IETF.
Most of this equipment is enterprise-grade and there are multiple
devices of each class in order to provide a high level of redundancy.
Daley Expires 30 October 2025 [Page 9]
Internet-Draft IETF Network Requirements April 2025
The in-room WiFi equipment is primarily installed by the professional
conference networking company and the A/V equipment by the remote
participation services provider.
5.2.3. Set up and management
The set up generally takes three to four days or work before the
Saturday when the IETF Meeting starts.
During the meeting week, the delivery of the IETF Network is as
follows:
* The NOC Lead has overall operational responsibility, which
includes daily meetings, coordinating between the different teams
and liaising with the Secretariat, LLC, venue and IETF leadership.
* The volunteer team manages the network, including all
connectivity, WiFi access, and core services such as DHCP and DNS.
* The professional conference networking company manages the
physical side of the equipment - power, location, cabling, etc.
They also provide all first line support, including staffing the
helpdesk. Throughout the week, room configurations change.
* The professional remote participation services company delivers
the remote participation services.
5.2.4. Multiple SSIDs
The conference network is entirely wireless and delivered as a set of
SSIDs, each with different characteristics to support different
users:
*ietf*. The main SSID. Currently this delivers IPv4 and IPv6 with
public addresses assigned to each client. It is expected to move
to any IPv6-mostly network in due course. This primarily aims to
meet the "High performance and robust" expectation, while slowly
evolving to meet the "Early adopter of production-ready IETF
standards" expectation.
*eduroam*. For existing eduroam users. Eduroam is an international
roaming service for users in research, higher education and
further education. It provides researchers, teachers, and
students network access when visiting an institution other than
their own. Users are authenticated with credentials from their
home institution, regardless of the location of the eduroam access
point. This is implemented to support the "Low friction"
expectation above.
Daley Expires 30 October 2025 [Page 10]
Internet-Draft IETF Network Requirements April 2025
*ietf-legacy*. A hidden SSID for those with old devices that cannot
connect to the main *ietf* SSID. This is generally used by a very
small number of very old participant devices (less than 10). This
is implemented to support the "Every participant needs to be able
to participate fully" expectation above.
There are also SSIDs used as part of the experimental network,
described below.
5.3. Experimental network
The experimental network comprises multiple physical networks.
5.3.1. Test SSIDs
Test SSIDs available across all access points, are generally used for
users to test new features before they are implemented on the
production *ietf* SSID. A recent example is *ietf-ipv6-mostly*,
which provides an "IPv6-only preferred" network [RFC 8925]. This
supports the "Early adopter of relevant, production-ready IETF
standards" expectation above.
Test SSIDs are also used to test new features that might become new
production SSIDs, separate from the main production SSID. For
example, while not implemented, there was discussion on offering a
permanent SSID with OpenRoaming, that would have first been a test
SSID.
5.3.2. Hackathon network
The hackathon network is primarily intended to support projects that
are part of the IETF Hackathon.
For onsite participants, each of the tables in the hackathon room has
a wired switch installed and specific networks are created on a per
table/project basis as needed. This averages 2-3 networks per
meeting. After the IETF Hackathon finishes, those switches with
custom networks are moved to the Shared Workspace so that work on
those projects can continue.
For remote participants, the IETF NOC maintains a custom router image
that can be used, together with a Datatracker account, to build a
cheap router that tunnels to the IETF Hackathon network. This
service is called HackNet.
Daley Expires 30 October 2025 [Page 11]
Internet-Draft IETF Network Requirements April 2025
5.3.3. Local experimental networks
Very occasionally, a local network is created, either wired and
wireless, to support experimentation that has to be kept entirely
separate from the IETF Network.
5.4. Hotel network
The IETF NOC works with the hotel IT provider so that a new SSID is
added to the existing hotel network (*ietf-hotel*) and traffic on
that is sent to a small IETF NOC router that then backhauls the
traffic to the conference network.
Where this backhaul requires a dedicated circuit (as opposed to just
running a cable) this is always donated by the local provider of
Internet connectivity, and sometimes includes the installation of new
fibre just for this purpose.
Working with the hotel network in this way, often shows up issues
with installation and configuration of the hotel networking equipment
that the IETF NOC assists the hotel in addressing.
The reasoning for this approach is based on the experiences of many
NOC members (including those who work professionally on conference
networks) regarding hotel networks:
* Captive portals, as regularly used in hotel networks, are a major
source of problems when a large number of devices go through them.
* The IETF NOC regularly discovers issues with hotel networks that
they fix as part of working with the hotel IT provider. Examples
include, all APs set to the same channel, APs on the roof of
elevators, APs that are not cabled to a controller, etc.
5.5. Remote participation services
The remote participation services provider has an onsite team who
operate and monitor the services throughout the meeting. The onsite
equipment needed is partly supplied by the services provider and
partly by the venue audio/visual services provider. Generally the
latter provides the microphones, speakers and sound desk, with
everything else provided and managed by the remote participation
services provider.
The remote participation service itself is hosted in the cloud.
Daley Expires 30 October 2025 [Page 12]
Internet-Draft IETF Network Requirements April 2025
5.6. Support
The professional conference networking company runs a staffed
helpdesk during the IETF meeting (not all day) and they monitor and
respond to tickets submitted by email. These tickets may require
escalation to a different part of the IETF NOC, such as the
volunteers or remote participation provider.
The reasoning for this approach is:
* This is a working meeting, not a conference where people go to
watch presentations, and so a participant unable to work has an
impact on the IETF as they cannot participate in the standards
process.
* An onsite helpdesk is able to fix things there and then.
* The combination of our own network, volunteers in the NOC with
very high levels of skills, a very technical group that needs
support and a local helpdesk, enables an exceptional level of
diagnostic support. For example, problems diagnosed by the IETF
NOC have led directly to changes in the codebase of the iPhone.
5.7. Network data
In order to meet the expectation of "Good access to network data,
without compromising privacy" some network and session participation
data is collected during the meeting but network flows are not
monitored and recorded. At the end of the meeting aggregate data is
extracted and the source data is deleted.
This data is then made available to the IETF community in a number of
ways, though these are not widely known about:
* Session participation data with geolocation is shown on a public
dashboard (https://dashboard.meeting.ietf.org/dashboard).
* Grafana dashboards on wireless users, overall traffic and packet
breakdowns, have recently been introduced.
The IETF NOC used to present at each plenary session on the use of
the network but this was dropped from the agenda in 2019 or so.
Daley Expires 30 October 2025 [Page 13]
Internet-Draft IETF Network Requirements April 2025
5.8. Cost
The total cost of providing the IETF Network for the three IETF
Meetings in 2024 was just over $1,000,000, a significant proportion
of the total cost of over $4,500,000. This can be broken down into
the following buckets, which are intentionally coarse-grained in
order to protect contractual confidentiality:
* The cost of the two contractors - the remote participation
services provider and the professional conference networking
company, and associated expenses. The fees charged by these
companies are confidential.
* The cost of the volunteers and overall NOC management, including
accommodation, expenses, onsite meals and site visits, totalled
approximately $250,000 in 2024.
* The cost of shipping the equipment. Approximately $70,000 over
the year.
The equipment and circuits are almost all donated by sponsors and so
these costs are excluded from the above costs.
6. Meeting networks at other meetings
The following two examples of meeting networks at other meetings,
NANOG and W3C, have been chosen to show two different models for
meeting networks from the IETF model. The W3C model is quite
different from the IETF and the NANOG model is somewhere in the
middle. The information presented has been checked with relevant
organisation.
Neither are exact matches to the IETF. For example, while NANOG
meets three times a year those meetings are solely in North America
and while W3C meets globally, it only has a plenary meeting once a
year. While both are hybrid meetings, both have a more limited set
of remote participation services than the IETF.
6.1. NANOG
The network at NANOG meetings is provided in a similar way to the
IETF network with a new network (APs, controllers, switches) fitted
by a professional conference networking company, bypassing the venue
network. However, the equipment shipped is much smaller and much
cheaper to ship as less of it is enterprise-grade.
Daley Expires 30 October 2025 [Page 14]
Internet-Draft IETF Network Requirements April 2025
The Hotel Network however, is the existing hotel network with no
modification or enhancement. NANOG does not rely on the hotel's
existing network at all. NANOG looks for available spare fiber into
the communications room and if the hotel doesn't have any, then NANOG
coordinates with a local ISP to have it installed as a Network
Sponsor. In some cases, the hotel has fibre they can use (if they
don't have any) and the provider might even add a commercial client.
The professional conference networking company operates the whole
network, there is no equivalent of the IETF NOC volunteers.
6.2. W3C
The W3C uses the venue network for the meeting network, but works
with the venue for some months before the meeting, testing it and
helping them fix any issues that would affect its performance. They
often contract for additional bandwidth above what their Internet
provider normally serves to the venue. The quality of the existing
network and the willingness of the venue to work with them are
important factors in venue selection.
Venue staff manage the network, for a fee, and no W3C staff or
professional conference networking company are employed to do so.
A/V hardware is provided and managed by W3C staff.
The network has received among the highest scores within the
logistics ratings in the feedback surveys for recent annual W3C
Conferences (TPAC meetings):
* In 2024 a score of 4.48 out of 5
* In 2023 a score of 4.54 out of 5
* In 2022 a score of 4.51 out of 5
7. Areas of disagreement
There are a number of areas of disagreement within the community
about the required purposes and attributes of the IETF Network and
how it is delivered. Specific disagreements include:
1. If the networks installed in meeting venues can meet the
requirements for a conference network, including the required
attributes.
2. If all the requirements for the hotel network necessary.
Daley Expires 30 October 2025 [Page 15]
Internet-Draft IETF Network Requirements April 2025
a. If so, then if the networks installed in meeting hotels meet
those requirements, including the required attributes.
3. If the IETF Network should support an experimental network.
a. If so, then if it should support the same three physical
networks described above.
4. If the IETF Network should be an early adopter of relevant,
production-ready IETF standards.
5. If the IETF Network should support old (legacy) equipment beyond
what might be commonly supported.
a. If so, then what should be the minimum threshold of supported
equipment.
6. If the current provision of network data provides good access to
network data, without compromising privacy.
8. Next steps
As noted above, the IETF LLC is unclear on what the path is to
resolve these disagreements. This is important because they get to
the heart of the requirements for the IETF Network and the resulting
provision of that network. The main area of uncertainty is whether
this is a community matter that requires a community-led process to
determine an outcome such as an RFC, or this is for the IETF LLC to
lead on and make decisions through its normal consultative processes.
9. IANA Considerations
This memo includes no request to IANA.
10. Security Considerations
This document should not affect the security of the Internet.
11. References
11.1. Informative References
[BCP205] Best Current Practice 205,
<https://www.rfc-editor.org/info/bcp205>.
At the time of writing, this BCP comprises the following:
Daley Expires 30 October 2025 [Page 16]
Internet-Draft IETF Network Requirements April 2025
Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[BCP226] Best Current Practice 226,
<https://www.rfc-editor.org/info/bcp226>.
At the time of writing, this BCP comprises the following:
Lear, E., Ed., "IETF Plenary Meeting Venue Selection
Process", BCP 226, RFC 8718, DOI 10.17487/RFC8718,
February 2020, <https://www.rfc-editor.org/info/rfc8718>.
Krishnan, S., "High-Level Guidance for the Meeting Policy
of the IETF", BCP 226, RFC 8719, DOI 10.17487/RFC8719,
February 2020, <https://www.rfc-editor.org/info/rfc8719>.
Duke, M., "Considerations for Cancellation of IETF
Meetings", BCP 226, RFC 9137, DOI 10.17487/RFC9137,
October 2021, <https://www.rfc-editor.org/info/rfc9137>.
Daley, J. and S. Turner, "IETF Meeting Venue Requirements
Review", BCP 226, RFC 9712, DOI 10.17487/RFC9712, January
2025, <https://www.rfc-editor.org/info/rfc9712>.
Acknowledgements
Thanks to multiple members of the IETF NOC for their help in ensuring
the accuracy of this document, particularly Joe Clarke, Sean Croghan,
Colin Doyle, Con Reilly, Simon Pietro Romano. Thanks also to Roman
Danyliw and Victor Kuarsingh for their reviews.
Author's Address
Jay Daley
IETF Administration LLC
1000 N. West St, Ste 1200
Wilmington, DE 19801
United States of America
Email: jay@staff.ietf.org
Daley Expires 30 October 2025 [Page 17]