RFC 1261: Transition of NIC Services

RFC 1261: Transition of Nic Services | RFC Editor
Skip to content
Info
RFC
1261
:
Transition of Nic Services
S. Williamson
,
L. Nobile
Informational
Network Working Group                                      S. Williamson
Request for Comments: 1261                                     L. Nobile
                                                       Network Solutions
                                                          September 1991
TRANSITION OF NIC SERVICES
Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

Discussion

   The transition of the Network Information Center from SRI
   International in Menlo Park, CA, to Government Systems Inc. in
   Chantilly, VA, is officially scheduled for 1 October 1991.  This
   includes the transition of services currently offered to DDN and
   Internet users by SRI.  These services include network/user
   registration (i.e., network number and top level domain name
   assignment), on-line information services, and Help Desk operations.
   GSI will also continue RFC and Internet-Draft archive and
   distribution services.

   SRI will continue to provide all NIC services and respond to all user
   calls and requests until 30 September 1991.

   Defense Information System Agency (DISA) and GSI will make every
   effort to ensure a smooth and timely transition of NIC services from
   SRI.  Network users should be minimally impacted.  With a few minor
   exceptions, all on-line services currently offered by SRI will appear
   the same to the user when a connection is established to the new
   (GSI) NIC host.  These exceptions are due to the change from the
   TOPS20 operating system to the SunOS operating system.  The new NIC
   host is a Sun 470 SPARCserver running SunOS 4.1.  All users on the
   DDN and the Internet should carefully note the following changes:

   U.S. Postal Address:      Government Systems, Inc.
                             Attn: Network Information Center
                             14200 Park Meadow Drive
                             Suite 200
                             Chantilly, VA  22021
Williamson & Nobile                                             [Page 1]
RFC 1261
Transition of NIC Services          September 1991
Help Desk Telephone Numbers:

                             1-800-365-3642 (1-800-365-DNIC)
                             1-703-802-4535

   Help Desk Hours of Operation:

                             7:00 am to 7:00 pm Eastern Time

   Fax Number:               1-703-802-8376

   Network Address:          192.112.36.5 (NIC.DDN.MIL)

   Root Domain Server:       192.112.36.4 (NS.NIC.DDN.MIL)

   During the period of 26 to 30 September 1991 the ID (WHOIS) database
   will not be changed.  All registration actions for this five day
   period will be suspended.  This action is necessary in order to
   transfer the master database to GSI.  Starting 26 September 1991, all
   U.S. mail and fax requests should be directed to the GSI address and
   fax number shown above.  All electronic mail requests should continue
   to be directed to the "HOSTMASTER" and "REGISTRAR" mailboxes at
   NIC.DDN.MIL.  As appropriate, SRI will redirect electronic mail to
   GSI.  On 1 October 1991 all registration activities will resume.

   We hope that the transition and its accompanying changes will not
   greatly inconvenience network users, and we thank you in advance for
   your patience and understanding.  For general questions regarding the
   transition, users may call the new NIC Help Desk after September 1,
   1991 at 1-800-365-3642/703-802-4535 or send an e-mail message to
   nic@diis.ddn.mil.

Security Considerations

   Security issues are not discussed in this memo.
Williamson & Nobile                                             [Page 2]
RFC 1261
Transition of NIC Services          September 1991
Authors' Addresses

   Scott Williamson
   Network Solutions, Inc.
   505 Huntmar Park Drive
   Herndon, VA 22070

   Phone: (703) 802-8405

   EMail: scottw@DIIS.DDN.MIL

   Leslie Nobile
   Network Solutions, Inc.
   505 Huntmar Park Drive
   Herndon, VA 22070

   Phone: (703) 802-8456

   leslie@DIIS.DDN.MIL

Williamson & Nobile                                             [Page 3]
RFC
1261
: Transition of Nic Services
Informational


Engagement Calendar

Engagement Calendar
العربية
中文
English
Français
Pусский
Español
Logo
en
Search
Search
Search
Filtered Search
Log In
Sign Up
Are you sure you want to sign out from
https://www.icann.org
?
Yes
Cancel
If you want to sign out from both
https://www.icann.org
and ICANN Account,
click here
.
ICANN
Get Started
News and Media
Policy
Public Comment
Resources
Community
Quicklinks
Get Started
News and Media
Policy
Public Comment
Resources
Community
Quicklinks
Engagement Calendar
View the Engagement Calendar to find upcoming ICANN org, community, Board, and internet ecosystem-related events.
Subscribe
Engagement Calendar Home
Announcements
Blogs
Follow Us on Social
Media Resources
Engagement Calendar
Advanced Search
Select filters and click Apply to narrow your search results or click More Search Options to search for keywords within the Engagement Calendar.
To view past events published before November 2023,
click here
.
Start Date
End Date
Activity or Event Type
ICANN Engagement
Internet Ecosystem Event
Training
Location
Africa
Asia/Australia/Pacific
Europe
Latin America/Caribbean
North America
Event Format
In Person
Virtual Only
Apply
Clear
More Search Options
1-20 of 50 results
CANTO41 Annual Conference and Trade Exhibition
The CANTO Annual Conference is the Caribbean’s premier telecommunications and digital technology gathering - a powerhouse platform where leaders, innovators, and change-makers unite to shape the region’s digital future. This flagship event brings together policy makers, global tech champions, operators, solution providers, and strategic partners ...
Date:
Sunday 9 August 2026
- Wednesday 12 August 2026
Location:
Latin America/Caribbean,
Punta Cana, Dominican Republic, In Person
Access:
Open Event
Priorities for Youth in the Digital World: Young Digital Talent for Emerging Technologies
Organized by the International Telecommunication Union (ITU) in collaboration with the National Directorate of Telecommunications and Audiovisual Communication Services (DINATEL) of the Ministry of Industry, Energy and Mining of Uruguay, this regional seminar will be held in Montevideo from 12-13 August 2026 to promote the development of young ...
Date:
Wednesday 12 August 2026
- Thursday 13 August 2026
Location:
Latin America/Caribbean,
Montevideo, Uruguay, In Person
Access:
Open Event
.za Domain Name Authority (ZADNA) National Stakeholder Engagement Meeting
The engagement presents an opportunity to strengthen collaboration between national and international stakeholders responsible for the security, stability and resilience of the global Domain Name System.
Date:
Monday 24 August 2026
Location:
Both Virtual and In Person
Access:
Open Event
22nd Caribbean Internet Governance Forum
The Caribbean Internet Governance Forum (CIGF) is a regional, non-hierarchical, multi-stakeholder forum initiated by the Caribbean Telecommunications Union (CTU) and the Caribbean Community (CARICOM) Secretariat in 2005 to coordinate a regional approach to Internet Governance (IG), initially focussed on the ...
Date:
Monday 24 August 2026
- Wednesday 26 August 2026
Location:
Latin America/Caribbean,
Both Virtual and In Person
Access:
Open Event
5th Caribbean Youth Internet Governance Forum
The Caribbean Youth Internet Governance Forum (CYIGF) is a regional, multi-stakeholder forum, initiated by the Caribbean Telecommunications Union, to coordinate regional views, interests and challenges of youth within the Caribbean.
The first CYIGF took place in 2022, and was planned and facilitated by Caribbean youth that attended the ...
Date:
Monday 24 August 2026
Location:
Latin America/Caribbean,
Both Virtual and In Person
Access:
Open Event
ICANN Near You - Dominican Republic
ICANN Near You is a regional engagement initiative designed to bring ICANN closer to local stakeholders through in-country activities that combine technical capacity building, policy awareness, and stakeholder outreach.
The Dominican Republic edition will bring together key actors from across the Internet ecosystem, including Internet ...
Date:
Tuesday 25 August 2026
- Thursday 27 August 2026
Location:
Latin America/Caribbean,
Santo Domingo and Santiago de los Caballeros, Dominican Republic, In Person
Access:
Open Event
EMEA Webinar Series - KSK Rollover 2026
The ICANN DNS root zone Key Signing Key (KSK) rollover is scheduled for October 11, 2026. On this date, the new cryptographic trust anchor (KSK-2024) will be used to sign the root zone for the first time. This event is vital to the security of DNSSEC-validating resolvers worldwide.
Date:
Wednesday 26 August 2026
Location:
Asia/Australia/Pacific,
Virtual Only
Access:
Open Event
Networking event - ICANN Near you Dominican Republic
The ICANN Near You Networking Event is designed to bring together participants from different sectors in the Dominican Republic in an informal setting. The event provides an opportunity to strengthen relationships among participants and foster new connections across stakeholder groups, creating opportunities for continued collaboration beyond ...
Date:
Wednesday 26 August 2026
Location:
Latin America/Caribbean,
Santo Domingo, Dominican Republic, In Person
Access:
Open Event
7th National Conference on Information Technology
The National Conference on IT (NCIT) 2026 is a technology conference in Fiji organized by the Fiji National University. This platform will build on dialogue and collaboration amongst innovators, industry leaders, policymakers, educators, entrepreneurs, and emerging technology professionals from across Fiji and the Pacific.
Date:
Wednesday 26 August 2026
- Friday 28 August 2026
Location:
Asia/Australia/Pacific,
Sigatoka, Fiji, In Person
Access:
Open Event
DNS Abuse workshop - ICANN Near you Dominican Republic
The primary objective of the workshop is to strengthen participants' understanding of DNS Abuse, its impact on the security and stability of the Internet, and the roles and responsibilities of the different stakeholders involved in its mitigation. Organized in collaboration with the Dominican Institute of Telecommunications (INDOTEL) and the ...
Date:
Thursday 27 August 2026
Location:
Latin America/Caribbean,
Santo Domingo, Dominican Republic, In Person
Access:
Open Event
DNS Operations and DNSSEC Workshop Tunisia 2026
This workshop on DNS Operations and DNSSEC is for the mobile network operators and ISPs operating in Tunisia.
Date:
Monday 31 August 2026
- Friday 4 September 2026
Location:
Africa,
Tunis City, Tunisia, In Person
Access:
Closed Event
Hawai'i School of Interenet Governance
The Hawaiʻi School on Internet Governance is a regional School of Internet Governance and part of the Dynamic Coalition on Schools of Internet Governance. Our purpose is to raise awareness and build capacity about digital technologies within the Hawaiʻi and Pacific ...
Date:
Friday 4 September 2026
Location:
North America,
Both Virtual and In Person
Access:
Open Event
CTU 2026 4th International ICT forecast and Preparatory Meeting
The meeting will apprise stakeholders of the upcoming series of regional and international meetings taking place in the next quarter of 2026. The Secretariat has invited partner organisations to present a brief on each meeting to demonstrate the importance of Caribbean representation at all major decision-making ...
Date:
Friday 4 September 2026
Location:
Virtual Only
Access:
Open Event
49 MEETING OF PERMANENT CONSULTATIVE COMMITTEE I: TELECOMMUNICATIONS/ICTS (PCC.I) & FINAL PREPARATORY MEETING OF CITEL FOR PP-26.
Within the framework of PCC.I, the
Final Preparatory Meeting of CITEL for the ITU Plenipotentiary Conference (PP-26)
will be held from
September 7 to 11, 2026
. As this will be the
FINAL MEETING
of the Working Group on the Plenipotentiary Conference (WGPP), and in accordance with the established ...
Date:
Monday 7 September 2026
- Friday 11 September 2026
Location:
Latin America/Caribbean,
Both Virtual and In Person
Access:
Open Event
Middle East and Adjoining Countries School on Internet Governance 2026
-
Revised Dates
The annual regional school on Internet Governance takes place in Beirut, Lebanon. The purpose is to attract a cohort of participants who can move in to become active in IG related processes.
Date:
Tuesday 8 September 2026
- Friday 11 September 2026
Location:
Africa,
Hamammat, Tunisia, In Person
Access:
Closed Event
SiNOG
Slovenian Network Operators Group meeting
Date:
Tuesday 8 September 2026
Location:
Europe,
Ljubiljana, Slovenia, In Person
Access:
Open Event
IGFUSA 2026
The Internet Governance Forum 2026 will happen for the first time in Philadelphia bringing stakeholders together to discuss the future of the internet.
Date:
Wednesday 9 September 2026
Location:
North America,
Both Virtual and In Person
Access:
Open Event
Uganda DNS Forum
The Uganda DNS Forum is a multi-stakeholder platform dedicated to strengthening Uganda’s Domain Name System (DNS) ecosystem through policy dialogue, technical capacity building, research, and community engagement.
Date:
Thursday 10 September 2026
Location:
Africa,
Both Virtual and In Person
Access:
Open Event
NOG.HR
Croatian Network Operators Group
Date:
Thursday 10 September 2026
Location:
Europe,
Zagreb, Croatia, In Person
Access:
Open Event
2026 Puerto Rico Capacity Development Sessions
The capacity-development event in Puerto Rico is part of ICANN’s strategic objective to provide hands-on training to foster knowledge sharing, skills development, and technical engagement. This marks the third consecutive year that ICANN has delivered these sessions to students, ...
Date:
Thursday 10 September 2026
- Monday 14 September 2026
Location:
North America,
San Juan, Puerto Rico, In Person
Access:
Closed Event
Previous
1
2
3
Next
Previous
1
2
3
Next
Connect with us
X
Instagram
Facebook
Youtube
LinkedIn
Flickr
Soundcloud
Explore Our Social Media Hub and Follow Us on ICANN's Official Accounts
Who We Are
ICANN For Beginners
ICANN Learn
Participate
Groups
Board Members
CEO Corner
Staff
Careers
Public Responsibility
Contact Us
Locations
Report Security Issues
Certificate Authority
Registry Liaison
Ombuds
Complaints Office
Media Resources
Accountability and Transparency
Accountability Mechanisms
Document Disclosure
Independent Review Process
Requests for Reconsideration
Empowered Community
Employee Anonymous Hotline Policy and Procedures
Governance
Governance Documents
Agreements
Organizational Reviews
Specific Reviews
Annual Report
Financials
Planning
RFPs
Litigation
Correspondence
Help
I Need Help
Dispute Resolution
Domain Name Dispute Resolution
Name Collision
ICANN Lookup
Registration Data Request Service (RDRS)
Data Protection
Data Privacy Practices
Privacy Policy
Terms of Service
Cookies Policy
© Internet Corporation for Assigned Names and Numbers
Privacy Policy
Terms of Service
Cookies Policy
Privacy Policy
Terms of Service
Cookies Policy


IETF  | Introduction

IETF | Introduction
Skip to main content
Search
About
About
Introduction to the IETF
Introduction to the IETF
Introduction to the IETF
Participants
Mission
Principles
The work
Structure of the IETF
Internet Engineering Steering Group
Internet Architecture Board
Internet Research Task Force
Liaison relationships
Nominating Committee
IETF Trust
RFC Editor
Independent Submissions Editor
Legal requests
Legal request procedures
Legal requests
Administration
IETF Administration LLC
Administrative announcements
Administrative reports
IETF Administration LLC Board
IETF Administration LLC Staff
Financial statements
RFPs and contracts
Administrative policies and procedures
IETF LLC transparency report
Technologies
The IETF works on a broad range of networking technologies that provide the foundation for the Internet's growth and evolution.
Technologies
Automated network management
The Internet of Things
New transport technology
Security & privacy
IETF technologies in action
Domain Name System
IETF technology groups
IETF Areas
Working Group keywords
Recent posts about IETF technologies
Agentic AI communications: Identifying the standards we need
Enabling Publishers to Express Preferences for AI Crawlers: An Update on the AIPREF Working Group
Preventing Internet Route Hijack with SIDRops Technology
End-to-end encryption based on the IETF-developed Messaging Layer Security set be used on 100s of millions of mobile devices
The new GREEN working group gets ready for an energy efficient Internet
Meetings
While most IETF work takes place online, meetings and other events such as Hackathons provide in-person opportunities to advance work within the IETF.
Meetings
IETF 126 Vienna
IETF 127 San Francisco
IETF 128 Kuala Lumpur
IETF 129 Berlin
Upcoming meetings
Past meetings
Interim meetings
IETF Hackathons
Code Sprint
Participation information
Preparing for an IETF Meeting
Guide to IETF Meetings
IETF meeting terms and conditions
New Participants
IETF Guides program
Meeting network and technology
Meetecho guide for participants
Visas and Letters of Invitation
Meeting Registration Fee Waivers
Onsite Childcare
Organizing meetings
Meeting planning
Meeting sponsorship
Side meetings and private meetings
Process
The IETF is the premier Internet standards organization. It follows open and well-documented processes for setting these standards. Once published, those standards are made freely available.
Process
Guide to the IETF standards process
Informal guide to IETF process documents
Bringing new work to the IETF
Intellectual property rights (IPR)
Guide to IETF Working Groups
Birds of a Feather (BOF)
Protocol registries (IANA)
RFCs
About RFCs
RFC Editor
Availability and use
Publication formats
Statuses
Publication streams
Corrections and errata
Reporting protocol vulnerabilities to the IETF
Participate
The global IETF community works together in many different ways to produce high quality, relevant technical documents that influence the way people design, use, and manage the Internet.
Participate
Getting started in the IETF
Internet-Drafts
IETF Systers
Tools and services
Datatracker
Mailing lists
Tools and services
Open records
Chairs resources
I-D authors resources
DraftForge
Participation guides
Guide to IETF Meetings
Guide to IETF Working Groups
Roles in the IETF
Key policies
Note Well - A reminder of IETF policies
Anti-harassment policy
Internet Standards process (BCP 9)
Working Group processes (BCP 25)
Guidelines for conduct (BCP 54)
Copyright (BCP 78)
Patents, Participation (BCP 79)
IETF/IRTF/IAB Privacy Statement
Support us
By supporting the IETF today, you are ensuring a free and open Internet exists tomorrow.
Support us
Why we need your support
IETF financial supporters
Donate to the IETF
Ways to give
IETF Endowment
Meeting sponsorship
Other ways to give
Technical foundations for business
Supporting values
Running Code
Sustainability
Diversity and Inclusion
Open Internet
News & blog
Search
Go
About
Introduction to the IETF
A brief introduction to the Mission, Participants, Principles, Work and Meetings of the IETF
About the IETF
Mission
Participants
Principles
RFCs
The Work
IETF Meetings
About the IETF
The Internet Engineering Task Force (IETF), founded in 1986, is the premier standards development organization (SDO) for the Internet. The IETF makes voluntary standards that are often adopted by Internet users, network operators, and equipment vendors, and it thus helps shape the trajectory of the development of the Internet. But in no way does the IETF control, or even patrol, the Internet.
Mission
Quoting from
RFC 3935: A Mission Statement for the IETF
:
"the overall goal of the IETF is to make the Internet work better."
"Its mission is to produce high quality, relevant technical and engineering documents that influence the way people design, use, and manage the Internet in such a way as to make the Internet work better. These documents include protocol standards, best current practices, and informational documents of various kinds."
The Mission Statement further states that the Internet isn't value-neutral, and neither is the IETF. The IETF wants the Internet to be useful for communities that share our commitment to openness and fairness. The IETF embraces technical concepts such as decentralized control, edge-user empowerment and sharing of resources, because those concepts resonate with the core values of the IETF community. These concepts have little to do with the technology that's possible, and much to do with the technology that the IETF chooses to create.
Participants
There is no membership in the IETF. Anyone can participate by signing up to a working group mailing list (more on that below), or registering for an IETF meeting. All IETF participants are considered volunteers and expected to participate as individuals, including those paid to participate.
The IETF welcomes all interested individuals and participants come from all over the world and from many different parts of the Internet industry. In any one year, over 7000 people actively participate in the IETF either by authoring a document, engaging in a mailing list discussion, or attending a meeting.
The only fee the IETF charges is for registering for an IETF meeting, with options in place to prevent that fee from becoming a barrier to participation.
IETF participants are regularly shown the
Note Well
, a reminder of the policies and processes they are expected to comply with. To ensure an environment in which people of many different backgrounds are treated with dignity, decency, and respect, these policies include a
code of conduct
, an
anti-harassment policy
, and the IETF has an
Ombudsteam
who are the point of escalation for any problems with conduct.
The IETF conducts its work solely in English.
Principles
The IETF pursues its mission in adherence to the following cardinal principles:
Open process
Any interested person can participate in the work, 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 documents, our Working Group mailing lists, our attendance lists, and our meeting minutes publicly available on the Internet.
Technical competence
The issues on which the IETF produces its documents are issues where the IETF has the competence needed to speak to them, and that the IETF is willing to listen to technically competent input from any source. Technical competence also means that we expect IETF output to be designed to sound network engineering principles - this is also often referred to as "engineering quality".
Volunteer Core
Our participants and our leadership are people who come to the IETF because they want to do work that furthers the IETF's mission of "making the Internet work better."
Rough consensus and running code
We make standards based on the combined engineering judgement of our participants and our real-world experience in implementing and deploying our specifications.
Protocol ownership
When the IETF takes ownership of a protocol or function, it accepts the responsibility for all aspects of the protocol, even though some aspects may rarely or never be seen on the Internet. Conversely, when the IETF is not responsible for a protocol or function, it does not attempt to exert control over it, even though it may at times touch or affect the Internet.
RFCs
The IETF publishes its technical documentation as RFCs, an acronym for their historical title
Requests for Comments
. They describe the Internet's technical foundations, such as addressing, routing, and transport technologies. RFCs also specify protocols like TLS 1.3, QUIC, and WebRTC that are used to deliver services used by billions of people every day, such as real-time collaboration, email, and the domain name system.
Software developers, hardware manufacturers, and network operators around the world voluntarily implement and adopt the technical specifications and best practices described by RFCs.
The
RFC Editor
website is the authoritative site for RFCs. The
IETF Datatracker
provides transparency on the process that resulted in the publication of each RFC.
For more information see
About RFCs
.
The Work
The work of the IETF is to produce technical documents (RFCs) that define how Internet technology works in detail, and can be operated and managed at scale.
New work in the IETF begins with one or more participants producing a discussion document called an Internet-Draft (I-D) and then working to get that I-D adopted for further work. Anyone can write an Internet-Draft on any topic they believe is relevant to the IETF. There are different routes that an I-D can follow to be adopted, worked on and eventually become an RFC.
The IETF has
policies
about Intellectual Property Rights (IPR) that are designed to ensure that IETF participants have as much information as possible about any IPR constraints on a technical proposal as early as possible in the development process.
The majority of the IETF's work is done in
Working Groups
. A Working Group (WG) has its own mailing list with most of its interaction, and all of it official work, conducted on this list. The day to day work of WGs revolves around Internet-Drafts and over time the WG shapes them into RFCs. Decisions within WGs, as with the broader IETF, are taken by 'rough consensus' and not by voting. When a WG has finished with an I-D it goes through a process to ensure that it has approval from the appointed technical leadership and the consensus support of the IETF as a whole.
When an I-D has cleared all the hurdles to become an RFC it goes through a professional editorial process and is then assigned a number and published in a range of formats.
IETF Meetings
The IETF holds three week-long meetings a year. Onsite participation averages between 1000 and 1500 participants. Every effort is made to integrate the 600+ remote participants into the overall meeting experience.
IETF meetings are very different from standard industry conferences as they are working meetings with the primary goal of helping Working Groups (WGs) get their tasks done, and the secondary goal of promoting mixing among the WGs. For that reason, most of the agenda is comprised of multiple simultaneous sessions for Working Groups. There is no exposition hall and only a small section of the agenda is set aside for tutorials, industry presentations, panel sessions, and opportunities for the whole community to come together.
For more information see
Guide to IETF Meetings
.
About
Introduction to the IETF
About
Introduction to the IETF
Internet Engineering Steering Group
Administration
Privacy and policies
Contact us
System status
Technologies
Automated network management
The Internet of Things
New transport technology
Security & privacy
IETF Areas
Meetings
Upcoming meetings
Past meetings
IETF Hackathons
Preparing for an IETF Meeting
Guide to IETF Meetings
Process
Guide to the IETF standards process
About RFCs
Bringing new work to the IETF
Participate
Getting started in the IETF
Guide to IETF Meetings
Guide to IETF Working Groups
Mailing lists
Support us
Why we need your support
Meeting sponsorship
Other ways to give
IETF financial supporters
IETF LLC
RFC Editor
IANA
IAB
IRTF
IETF Trust


Host Country Contributions to Supporting Global South | Internet Governance Forum (IGF)
Skip to main content
Welcome to the United Nations
|
Department of Economic and Social Affairs
English
English
Menu
Quick links
I am new to the IGF
Subscribe to our mailing list
Register for an IGF activity
Donate to the IGF
Find/Become a Resource Person
Search
Feed me
Log in
Header Menu
About
About
About IGF
FAQs – About IGF & IGF 2025
Get Started
Team
IGF Donors
Work With Us
IGF Mailing Lists
Contact Us
IGF Leadership Panel
Multi-stakeholder Advisory Group
Multi-stakeholder Advisory Group
MAG Terms of Reference
MAG Chair Terms of Reference
MAG Chair's Blog
MAG Members
MAG Members
Previous MAG Members
MAG Working Groups
MAG Meeting Records
MAG Activities
MAG Member Dashboard
IGF 2026 MAG Renewal
UN Global Advocate
IGF Expert Group Meeting (2026)
IGF Expert Group Meeting 2026
EGM Report
The IGF and UN Processes
Code of Conduct
Newsletter
Press
Support the IGF
Donate
IGF Trust Fund
Donors' Contributions to Main Trust Fund
Global South Contributions
Host the IGF
Share Your Experience - "Voices of the IGF"
IGF 2026
IGF 2026 Entry Page
IGF 2026 Call for Session Proposals
IGF 2026 Call for Village Booths
IGF 2026 Call for Remote Hubs
IGF 2026 First Open Consultations & MAG Meeting
IGF 2026 Timeline
IGF 2026 Intersessional Work Proposals
IGF 2026 Proposed Thematic Inputs
IGF 2025 Stocktaking & 2026 Improvements
IGF 2026 Call for MAG Nominations
IGF 2026 Call for NRI Grants
IGF 2026 Judiciary Engagement
IGF 2026 Parliamentary Track
IGF 2026 Youth Track
IGF 2026 Business Engagement
Intersessional Work
Thematic Intersessional Work
Dynamic Coalitions
Dynamic Coalitions
DC Coordination Activities
Terms of Reference
Best Practice Forums
Policy Networks
Policy Network on Artificial Intelligence
Policy Network on Cybersecurity
Policy Network on Open Digital Infrastructure
Policy Network on Digital Inclusion
Previous Work
Capacity Development
Intersessional News
National and Regional IGFs
Overview
NRIs FAQs
NRIs Toolkit: How to Start Your IGF Initiative?
Youth Initiatives
Regional IGF Initiatives
National IGF Initiatives
All National Initiatives
Africa
Asia Pacific
Eastern Europe
GRULAC
WEOG
NRI Dashboard
NRIs Library
NRIs Collaborative Work
IGF 2026 NRIs Preparatory Process
Brochures about NRIs
IGF NRIs Call for Grants
NRIs Meetings - overview
Publications and Reports
IGF Brochures and Select Publications
Publications and Reports
IGF Annual Meeting Proceedings
IGF Intersessional Work
CSTD Reports
UN GA Resolutions on ICT for SD
Calendar
Breadcrumb
Home
Host Country Contributions to Supporting Global South
As of 2019, host countries have made contributions to support Global South participation.
Donor
Total Contributions
Government of Germany
$1,650,000
Government of Japan
$550,000
Government of Saudi Arabia
$476,000
Government of Norway
$250,000
Government of Ethiopia
$80,000
Government of Poland
$20,000
UNITED NATIONS
Contact information
United Nations
Secretariat of the Internet Governance Forum (IGF)
Villa Le Bocage
Palais des Nations,
CH-1211 Geneva 10
Switzerland
igf [at] un [dot] org
+41 (0) 229 173 411
Additional Information
Donate to the IGF
Participant Funding
Vacancies
Multilingualism
Accessibility Statement
Resources
Publications
Press
Glossary
CONNECT WITH US
Donate
Footer menu
Copyright
Privacy Notice
Terms of Use
Accessibility menu
Contrast settings
Font size
Letter spacing
Line height
Images
Font
Reset the settings


WTO Telecommunications Services

WTO | Services: Telecommunications services
home
trade
          topics
services
sector-by-sector
telecommunications services
SERVICES:
SECTOR BY SECTOR
Telecommunication services
Telecommunication services are the core of the digital economy, enabling e-commerce in goods and services. Extensive trading is undertaken via commercial presence by a foreign company (mode 3 under the General Agreement on Trade in Services) and cross-border supply (mode 1 under the GATS). The sector accounts for over US$ 1.6 trillion in revenue, of which 65 per cent is from mobile services.  Proving resilient during the 2020-21 pandemic, telecommunications have also supported the uptake of many other services and their capacity to meet the dramatic increases in demand for online activity as a result of COVID-19.
Telecommunication services include all forms of voice telephony and data transmission as well as leasing of circuit capacity (considered “basic” telecommunications) and a host of messaging and online information and data retrieval and processing services (considered value-added telecommunications). Such services are covered by the sector regardless of the technology used to supply them. Having accommodated computer and related technologies in recent decades, the sector covers some services (especially value-added services) that today are nearly indistinguishable from certain activities included in the GATS classification for the computer and related services sector.
Help with understanding how GATS defines telecommunications, basic telecommunications, and other telecommunications services
Sectoral trade rules
The trade rules that apply to  telecommunications services include the framework articles of the
GATS
, which contain the principles for trade in all services. In addition, the GATS contains an Annex on telecommunications whose rules apply to all WTO members. The Annex provides guarantees for reasonable access to and  use of public telecommunications in a given market by suppliers of all services  benefiting from commitments scheduled by the member concerned.
Text of the Annex on Telecommunications
Annex explanation
Another key element of telecom disciplines — the
Reference Paper
— is a set of regulatory  principles that is legally binding only for those  WTO governments which have committed to it by appending the document, in whole  or in part, to their schedules of commitments. The Reference Paper provided a blueprint for telecommunications reform, at  a time when competition was being introduced, that largely reflected “best  practice” in sector regulation at the time, and in large part continues to do  so today.
Telecommunications  Reference Paper
Current market access commitments and most-favoured-nation (MFN) exemptions
Commitments in  telecommunications services were first made during the Uruguay Round (1986-94), mostly in  value-added services. In post-Uruguay Round negotiations (1994-97), WTO members  negotiated basic telecommunications services. Since then, commitments have been  made by new members upon accession to the WTO or unilaterally by  governments who have chosen to do so.
Currently, 126 WTO members have made market access and national  treatment commitments on trade in telecommunications services. This includes commitments  to allow the establishment of new telecoms companies, foreign direct investment  in existing companies and cross-border transmission of telecoms  services. In addition, 107 members have committed to the regulatory principles  spelled out in the Reference Paper.
List of all current telecommunications commitments and exemptions
For consolidated information on countries’ commitments and exemptions on
          telecommunications services go to the
services  database
.
If you are seeking the commitments of a specific WTO member,  go to “Jump to a specific sector for a given Member”, select  telecommunications services from the sector dropdown list, select the member of interest and  click “go”. To see a table showing which members have made commitments in  telecommunications services, choose “See which Members have made commitments in a  specific sector”, select Telecommunications services and  click “go”.
Telecommunications in WTO negotiations
Following the extensive  negotiations in the 1990s, telecommunications, like other services, were  included in the Doha Round of
services  negotiations
.
Post-Uruguay Round negotiations on basic telecommunications (1994-1997)
In the Doha Round, which began  in January 2000, improved market opening and new  commitments to "bind" more recent reforms in telecommunications were under  negotiation. At least 39 members had offered  to improve their existing commitments or to commit for  the first time in the sector.
Improving telecommunications  commitments remains a priority and is likely to be pursued in any future  negotiations.
Help with understanding terms used in telecommunications: Informal glossary
Key events
Symposium on International Mobile Roaming — 22 March 2012
Basic Telecom Negotiations: 10th Anniversary Symposium —  20-21 February 2008
back to top
Additional information
Search Documents Online
These links open a new window: allow a moment for the results to appear.
Secretariat background
                notes
on telecom services
(Document code
                S/C/W/* and keyword “Telecommunication
                Services and Background Note”)
>
search
>
help
You can perform more sophisticated searches from the
Documents
              Online search facility
by defining multiple search criteria such as document symbol (i.e. code number), full text search or document date.
Useful links and other resources
International Telecommunication Union (ITU)
ITU Development Bureau:
Policy and Regulation
ITU
Global        Symposium for Regulators
and its
Best Practice        Guidelines
World  Bank:
Digital Development
UNCTAD:
Science, Technology &  Innovation and ICTs
UNCTAD:
Digital Economy Report Series
,  formerly
Information Economy Report
OECD:
Digital Economy Committee
IMF:  Sustainable Infrastructure -
Telecoms Media &  Technology
World Summit on the Information Society (WSIS)
WSIS Reports https://www.itu.int/pub/S-POL-WSIS
Internet Governance Forum  (IGF)
Internet Society (ISOC)
ISOC Publications


RFC 3935 - A Mission Statement for the IETF
Skip to main content
Datatracker
Groups
By area/parent
Apps & Realtime
General
Internet
Ops & Management
Routing
Security
Web and Internet Transport
IESG
IAB
IRTF
IETF LLC
RFC Editor
Other
Active AGs
Active Areas
Active Directorates
Active IAB Workshops
Active Programs
Active RAGs
Active Teams
New work
Chartering groups
BOFs
BOF Requests
Other groups
Concluded groups
Non-WG lists
Documents
Search
Recent I-Ds
Submit an Internet-Draft
RFC streams
IAB
IRTF
ISE
Editorial
Subseries
STD
BCP
FYI
Meetings
Agenda
Materials
Floor plan
Registration
Important dates
Request a session
Session requests
Upcoming meetings
Upcoming meetings
Past meetings
Past meetings
Meeting proceedings
Other
IPR disclosures
Liaison statements
IESG agenda
NomComs
Downref registry
Statistics
I-Ds/RFCs
Meetings
API Help
Release notes
System status
Report a bug
User
Sign in
Password reset
Preferences
New account
List subscriptions
IETF Lists
IRTF Lists
IAB Lists
RFC-Editor Lists
Report a bug
Sign in
A Mission Statement for the IETF
RFC 3935
also known as
BCP 95
Status
Email expansions
History
Document
Type
RFC

- Best Current Practice
(October 2004)
Errata
Was
draft-alvestrand-ietf-mission
(individual in gen area)
Author
H. Alvestrand
Last updated
2026-05-20
RFC stream
Internet Engineering Task Force (IETF)
Formats
txt
html
htmlized
bibtex
IESG
Responsible AD
David Kessens
Send notices to
(None)
Email authors
IPR
References
Referenced by
Search Lists
RFC 3935
Network Working Group H. Alvestrand
Request for Comments: 3935 Cisco Systems
BCP: 95 October 2004
Category: Best Current Practice

A Mission Statement for the IETF
Status of this Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This memo gives a mission statement for the IETF, tries to define the
terms used in the statement sufficiently to make the mission
statement understandable and useful, argues why the IETF needs a
mission statement, and tries to capture some of the debate that led
to this point.

1. Mission Statement

The goal of the IETF is to make the Internet work better.

The mission of the IETF is to produce high quality, relevant
technical and engineering documents that influence the way people
design, use, and manage the Internet in such a way as to make the
Internet work better. These documents include protocol standards,
best current practices, and informational documents of various kinds.

The IETF will pursue this mission in adherence to the following
cardinal principles:

Open process - any interested person can participate in the work,
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
documents, our WG mailing lists, our attendance lists, and our
meeting minutes publicly available on the Internet.

Technical competence - the issues on which the IETF produces its
documents are issues where the IETF has the competence needed to
speak to them, and that the IETF is willing to listen to
Alvestrand Best Current Practice [Page 1]
RFC 3935 IETF Mission Statement October 2004
technically competent input from any source. Technical competence
also means that we expect IETF output to be designed to sound
network engineering principles - this is also often referred to as
"engineering quality".

Volunteer Core - our participants and our leadership are people who
come to the IETF because they want to do work that furthers the
IETF's mission of "making the Internet work better".

Rough consensus and running code - We make standards based on the
combined engineering judgement of our participants and our real-
world experience in implementing and deploying our specifications.

Protocol ownership - when the IETF takes ownership of a protocol or
function, it accepts the responsibility for all aspects of the
protocol, even though some aspects may rarely or never be seen on
the Internet. Conversely, when the IETF is not responsible for a
protocol or function, it does not attempt to exert control over
it, even though it may at times touch or affect the Internet.

2. Definition of Terms

Mission: What an organization sets out to do. This is in contrast to
its goal (which is what it hopes to achieve by fulfilling its
mission), and to its activities (which is what specific actions it
takes to achieve its mission).

The Internet: A large, heterogeneous collection of interconnected
systems that can be used for communication of many different types
between any interested parties connected to it. The term includes
both the "core Internet" (ISP networks) and "edge Internet"
(corporate and private networks, often connected via firewalls,
NAT boxes, application layer gateways and similar devices). The
Internet is a truly global network, reaching into just about every
country in the world.
The IETF community wants the Internet to succeed because we
believe that the existence of the Internet, and its influence on
economics, communication, and education, will help us to build a
better human society.

Standard: As used here, the term describes a specification of a
protocol, system behaviour or procedure that has a unique
identifier, and where the IETF has agreed that "if you want to do
this thing, this is the description of how to do it". It does not
imply any attempt by the IETF to mandate its use, or any attempt
to police its usage - only that "if you say that you are doing
this according to this standard, do it this way". The benefit of
Alvestrand Best Current Practice [Page 2]
RFC 3935 IETF Mission Statement October 2004
a standard to the Internet is in interoperability - that multiple
products implementing a standard are able to work together in
order to deliver valuable functions to the Internet's users.

Participants: Individuals who participate in the process are the
fundamental unit of the IETF organization and the IETF's work.
The IETF has found that the process works best when focused around
people, rather than around organizations, companies, governments
or interest groups. That is not to say that these other entities
are uninteresting - but they are not what constitutes the IETF.

Quality: In this context, the ability to express ideas with enough
clarity that they can be understood in the same way by all people
building systems to conform to them, and the ability (and
willingness) to describe the properties of the system well enough
to understand important consequences of its design, and to ensure
that those consequences are beneficial to the Internet as a whole.
It also means that the specifications are designed with adherence
to sound network engineering principles, so that use for its
intended purpose is likely to be effective and not harmful to the
Internet as a whole.

Relevant: In this context, useful to some group of people who have to
make decisions that affect the Internet, including, but not
limited to, hardware and software implementors, network builders,
network operators, and users of the Internet. Note that it does
not mean "correct" or "positive" - a report of an experiment that
failed, or a specification that clearly says why you should not
use it in a given situation, can be highly relevant - for deciding
what NOT to do. A part of being relevant is being timely - very
often, documents delivered a year after core decisions have been
taken are far less useful than documents that are available to the
decision-makers at decision time.

3. The Need for a Mission Statement

The IETF has to make decisions. And in some cases, people acting on
behalf of the IETF have to make decisions without consulting the
entire IETF first.

There are many reasons for this, including the near-impossibility of
getting an informed consensus opinion on a complex subject out of a
community of several thousand people in a short time.

Having a defined mission is one of the steps we can take in order to
evaluate alternatives: Does this help or hinder the mission, or is it
orthogonal to it? If there are limited resources, are there things
that they could be invested in that help the mission better?
Alvestrand Best Current Practice [Page 3]
RFC 3935 IETF Mission Statement October 2004
(Another step is to choose leaders that we trust to exercise their
good judgement and do the right thing. But we're already trying to
do that.)

4. Issues with Scoping the IETF's Mission

4.1. The Scope of the Internet

A very difficult issue in discussing the IETF's mission has been the
scope of the term "for the Internet". The Internet is used for many
things, many of which the IETF community has neither interest nor
competence in making standards for.

The Internet isn't value-neutral, and neither is the IETF. We want
the Internet to be useful for communities that share our commitment
to openness and fairness. We embrace technical concepts such as
decentralized control, edge-user empowerment and sharing of
resources, because those concepts resonate with the core values of
the IETF community. These concepts have little to do with the
technology that's possible, and much to do with the technology that
we choose to create.

At the same time, it is clear that many of the IETF-defined
technologies are useful not only for the Internet, but also for
networks that have no direct relation to the Internet itself.

In attempting to resolve the question of the IETF's scope, perhaps
the fairest balance is struck by this formulation: "protocols and
practices for which secure and scalable implementations are expected
to have wide deployment and interoperation on the Internet, or to
form part of the infrastructure of the Internet."

In addition to this constraint, we are also constrained by the
principle of competence: Where we do not have, and cannot gather, the
competence needed to make technically sound standards, we should not
attempt to take the leadership.

4.2. The Balance Between Research, Invention and Adoption

The IETF has traditionally been a community for experimentation with
things that are not fully understood, standardization of protocols
for which some understanding has been reached, and publication of
(and refinement of) protocols originally specified outside the IETF
process.
Alvestrand Best Current Practice [Page 4]
RFC 3935 IETF Mission Statement October 2004
All of these activities have in common that they produce documents -
but the documents should be judged by very different criteria when
the time to publish comes around, and it's not uncommon to see people
confused about what documents are in which category.

In deciding whether or not these activities should be done within the
IETF, one should not chiefly look at the type of activity, but the
potential benefit to the Internet - an experiment that yields
information about the fact that an approach is not viable might be of
greater benefit to the Internet than publishing a standard that is
technically competent, but only useful in a few special cases.

For research of an essentially unbounded nature, with unknown
probability of success, it may be more relevant to charter a research
group than a standards group. For activities with a bounded scope -
such as specifying several alternative protocols to the point where
experiments can identify the better one for standardization - the
IETF's working group mechanism may be an appropriate tool.

4.3. The Balance Between Mission and Procedures

The mission is intended to state what the IETF is trying to achieve.
There are many methods that can be chosen to achieve these outcomes -
for instance, the appeals procedure is defined so that we can detect
cases where our fundamental principles of technical competence and
open process has been violated; it is not itself a fundamental value.

Similarly, the question of what body in the IETF declares that a
document is ready for publication is entirely outside the mission
statement; we can imagine changing that without in any way impacting
what the IETF mission is - even though it may significantly impact
the ability to achieve that mission.

4.4. The Reach of the Internet

The Internet is a global phenomenon. The people interested in its
evolution are from every culture under the sun and from all walks of
life. The IETF puts its emphasis on technical competence, rough
consensus and individual participation, and needs to be open to
competent input from any source. The IETF uses the English language
for its work is because of its utility for working in a global
context.
Alvestrand Best Current Practice [Page 5]
RFC 3935 IETF Mission Statement October 2004
4.5. Protocol Ownership

A problem akin to the problem of deciding on the area of the IETF's
competence arises when a protocol that is clearly in the IETF's scope
is used both on and off the Internet - the premier example is of
course the Internet Protocol itself.

Sometimes the IETF defines standards that ultimately see the most use
outside the global Internet. The IETF, having defined the standard,
will continue to provide the necessary administration of that
protocol.

Sometimes the IETF leverages standards that are defined and
maintained by other organizations; we continue to work with those
organizations on their standards and do not attempt to take them
over.

5. Security Considerations

Considering security is one of the core principles of sound network
engineering for the Internet. Apart from that, it's not relevant to
this memo.

6. Acknowledgements

This document is a result of many hours of debate, countless reviews,
and limitless emails. As such, any acknowledgements section is bound
to be incomplete.

Among the many who provided input were the current members of the
IESG (Alex Zinin, Allison Mankin, Bert Wijnen, Bill Fenner, David
Kessens, Jon Peterson, Margaret Wasserman, Russ Housley, Scott
Hollenbeck, Steve Bellovin, Ted Hardie, Thomas Narten) and recent
IESG members (Ned Freed, Randy Bush, Erik Nordmark), as well as
multiple IAB members, and many members from the community, including
James Polk, John Klensin, Pekka Savola, Paul Hoffman, Eliot Lear,
Jonne Soininen, Fred Baker, Dean Anderson, John Leslie, Susan Harris,
and many others. Special thanks go to Leslie Daigle, the IAB chair.
Author's Address
Harald Tveit Alvestrand
Cisco Systems
Weidemanns vei 27
Trondheim 7043
NO

EMail: harald@alvestrand.no
Alvestrand Best Current Practice [Page 6]
RFC 3935 IETF Mission Statement October 2004
Full Copyright Statement
Copyright (C) The Internet Society (2004).

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in IETF Documents can
be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Alvestrand Best Current Practice [Page 7]
IETF
IESG
IAB
IRTF
IETF LLC
IETF Trust
RFC Editor
IANA
Privacy Statement
About IETF Datatracker
Version 12.70.0
(release - 6fcc7d8)
System Status
Report a bug:
GitHub
Email

RFC publication date from document header


[2408.12345] Linearly Multiplexed Photon Number Resolving Single-photon Detectors Array
Skip to main content
Search
Submit
Donate
Log in
Search arXiv
Press Enter to search ·
Advanced search
Quantum Physics
arXiv:2408.12345
(quant-ph)
[Submitted on 22 Aug 2024 (
v1
), last revised 23 Oct 2024 (this version, v2)]
Title:
Linearly Multiplexed Photon Number Resolving Single-photon Detectors Array
Authors:
Leonardo Limongi
,
Francesco Martini
,
Thu Ha Dao
,
Alessandro Gaggero
,
Hamza Hasnaoui
,
Igor Lopez-Gonzalez
,
Fabio Chiarello
,
Fabio de Matteis
,
Alberto Quaranta
,
Andrea Salamon
,
Francesco Mattioli
,
Martino Bernard
,
Mirko Lobino
View a PDF of the paper titled Linearly Multiplexed Photon Number Resolving Single-photon Detectors Array, by Leonardo Limongi and 12 other authors
View PDF
HTML (experimental)
Abstract:
Photon Number Resolving Detectors (PNRDs) are devices capable of measuring the number of photons present in an incident optical beam, enabling light sources to be measured and characterized at the quantum level. In this paper, we explore the performance and design considerations of a linearly multiplexed photon number-resolving single-photon detector array, integrated on a single mode waveguide. Our investigation focus on defining and analyzing the fidelity of such an array under various conditions and proposing practical designs for its implementation. Through theoretical analysis and numerical simulations, we show how propagation losses and dark counts may have a strong impact on the performance of the system and highlight the importance of mitigating these effects in practical implementations.
Subjects:
Quantum Physics (quant-ph)
Cite as:
arXiv:2408.12345
[quant-ph]
(or
arXiv:2408.12345v2
[quant-ph]
for this version)
https://doi.org/10.48550/arXiv.2408.12345
Focus to learn more
arXiv-issued DOI via DataCite
Journal reference:
Optics Communications, Volume 575, 2025, 131244
Related DOI
:
https://doi.org/10.1016/j.optcom.2024.131244
Focus to learn more
DOI(s) linking to related resources
Submission history
From: Leonardo Limongi [
view email
]
[v1]
Thu, 22 Aug 2024 12:41:12 UTC (238 KB)
[v2]
Wed, 23 Oct 2024 15:01:32 UTC (259 KB)
Full-text links:
Access Paper:
View a PDF of the paper titled Linearly Multiplexed Photon Number Resolving Single-photon Detectors Array, by Leonardo Limongi and 12 other authors
View PDF
HTML (experimental)
TeX Source
view license
Current browse context:
quant-ph
< prev
|
next >
new
|
recent
|
2024-08
References & Citations
INSPIRE HEP
NASA ADS
Google Scholar
Semantic Scholar
export BibTeX citation
Loading...
BibTeX formatted citation
×
loading...
Data provided by:
Bookmark
Bibliographic Tools
Bibliographic and Citation Tools
Bibliographic Explorer Toggle
Bibliographic Explorer
(
What is the Explorer?
)
Connected Papers Toggle
Connected Papers
(
What is Connected Papers?
)
Litmaps Toggle
Litmaps
(
What is Litmaps?
)
scite.ai Toggle
scite Smart Citations
(
What are Smart Citations?
)
Code, Data, Media
Code, Data and Media Associated with this Article
alphaXiv Toggle
alphaXiv
(
What is alphaXiv?
)
Links to Code Toggle
CatalyzeX Code Finder for Papers
(
What is CatalyzeX?
)
DagsHub Toggle
DagsHub
(
What is DagsHub?
)
GotitPub Toggle
Gotit.pub
(
What is GotitPub?
)
Huggingface Toggle
Hugging Face
(
What is Huggingface?
)
ScienceCast Toggle
ScienceCast
(
What is ScienceCast?
)
Demos
Demos
Replicate Toggle
Replicate
(
What is Replicate?
)
Spaces Toggle
Hugging Face Spaces
(
What is Spaces?
)
Spaces Toggle
TXYZ.AI
(
What is TXYZ.AI?
)
Related Papers
Recommenders and Search Tools
Link to Influence Flower
Influence Flower
(
What are Influence Flowers?
)
Core recommender toggle
CORE Recommender
(
What is CORE?
)
Author
Venue
Institution
Topic
About arXivLabs
arXivLabs: experimental projects with community collaborators
arXivLabs is a framework that allows collaborators to develop and share new arXiv features directly on our website.
Both individuals and organizations that work with arXivLabs have embraced and accepted our values of openness, community, excellence, and user data privacy. arXiv is committed to these values and only works with partners that adhere to them.
Have an idea for a project that will add value for arXiv's community?
Learn more about arXivLabs
.
Which authors of this paper are endorsers?
|
Disable MathJax
(
What is MathJax?
)
We gratefully acknowledge support from
our
major funders
,
member institutions
,
,
and all contributors.
About
·
Help
·
Contact
·
Subscribe
·
Copyright
·
Privacy
·
Accessibility
·
Operational Status
(opens in new tab)
Major funding support from


ICANN Fellowship Selection Committee - ICANN
Skip to main content
Search ICANN.org
Log In
Sign Up
Get Started
About ICANN
ICANN for Beginners
Fellowship Program
NextGen@ICANN Program
History
News and Media
Announcements
Blog
Media Resources
Press Releases
Global Newsletters
ICANN News Subscriptions
Regional Reports
Policy
Develop Policy
Operational Design Phase (ODP)
Implement Policy
Community Participation Guidelines
Public Comment
Public Comment Home
Upcoming Proceedings
Open Proceedings
Closed Proceedings
About Public Comment
Other Public Consultations
Resources
Board Activities and Meetings
Accountability Mechanisms
Contracted Parties (Registry Operators and Accredited Registrars)
Domain Name Registrants
Contractual Compliance
Domain Name Security Threats
Privacy and Proxy Services
Government Engagement
Careers
Complaints Office
I Need Help
ICANN 25th Anniversary Photo Mosaic
Community
Engagement Calendar
Address Supporting Organization (ASO)
Country Code Names Supporting Organization (ccNSO)
Generic Names Supporting Organization (GNSO)
At-Large Advisory Committee (ALAC)
Governmental Advisory Committee (GAC)
Root Server System Advisory Committee (RSSAC)
Security and Stability Advisory Committee (SSAC)
Quicklinks
Board Activities and Meetings
Data Protection and Privacy
Domain Name Registrants
Engagement Calendar
IANA Services
ICANN Acronyms and Terms
ICANN Grant Program
New gTLD Program
Public Technical Identifiers (PTI)
Open Data
Question About A Domain Name?
Technology @ ICANN
WSIS+20 Outreach Network
Resources
About ICANN
Academic Engagement
Acronyms and Terms
Courses and Learning
ICANN for Beginners
Participate
What ICANN Does
Effect on the Internet
What's Going On Now
How to Participate
Fellowship Program
Committee
Terms & Conditions
NextGen@ICANN Program
President's Corner
ICANN Management Organization Chart
Staff
Careers
In Focus
ICANN Response Planning Framework
DNSSEC
Standards
IANA DNSSEC Root Information
TLD DNSSEC Report
Root Deployment
Deployment Graph
Tools
Training
Key Ceremony
News
Blog Posts
Presentations
Related Sites
GNSO Improvements
Travel Support
Media Resources
ICANN News
About ICANN
Subscribe and Follow
Contacts
Board Activities and Meetings
Accountability
Accountability Mechanisms
Reconsideration
Independent Review Process
Updating the IRP
Ombuds
About the Ombuds Office
Contact the Ombuds Office
Ombuds Office Services
Complaints About Unfairness
Complaints About Harassment
Collaborative Conflict Resolution
Request for Reconsideration
Resources for Community Members
Ombuds Office Accountability
Ombud's Blogs
Empowered Community
Empowered Community Administration
Empowered Community Administration Mailing List
Empowered Community Correspondence
Document Disclosure
Reviews
Organizational Reviews
ALAC
ASO
Board
ccNSO
GNSO
Nominating Committee
RSSAC
SSAC
Technical Liaison Group
Specific Reviews
Accountability & Transparency
Registration Directory Service
Security, Stability, and Resiliency
Competition, Consumer Trust & Consumer Choice
CCT Metrics
Expected Standards of Behavior
Employee Practices and Resources
Enhancing ICANN Accountability – Work Stream 2 Implementation
Governance
Governance Documents
Evolving ICANN’s Multistakeholder Model
Agreements
NTIA IANA Functions' Stewardship Transition
Call for Public Input: Draft Process to Develop the Proposal (8 April-8 May 2014
Process to Develop the Proposal and Next Steps
Registry
Archive
Affirmation of Commitments
AOC Tracking
ccTLD
Partnership Memorandums of Understanding
Registrar
Archive
Annual Reports
Financials
Financial Reports
Policies, Guidelines and Procedures
Annual Disclosure of Payments to Suppliers
Lobbying Disclosures & Contribution Reports
Planning
Strategic Plan
ICANN Strategic Plan for FY26-30
ICANN's Annual Strategy Review Program
ICANN Strategic Plan for FY21-25
Strategic Outlook Trends Program
ICANN Strategic Plan for FY16-20
Operating Plan
Presentations
RFPs
Litigation
Newsletter
Correspondence
2026
2025
2024
2023
2022
2021
2020
2019
2018
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008
2007
2006
2005
2004
2003
2002
2001
2000
1999
1998
Quarterly Reports
Groups
2023 ICANN CEO Search Committee
RSSAC
Charter
SSAC
GAC
At-Large
ASO
ccNSO
GNSO
Technical Liaison Group
Technical Experts Group (TEG)
NomCom
Past NomComs
Customer Standing Committee
Root Zone Evaluation Review Committee (RZERC)
Business
Civil Society
Complaints Office
Complaints Report
Domain Name System Abuse
Contractual Compliance
About
Enforcement of DNS Abuse Obligations
Formal Enforcement Notices
Archive
Contractual Compliance Metrics
Blogs
Contractual Compliance Audit Program
Notice of Bankruptcy, Convictions and Security Breaches
Contractual Compliance Reports
Audit Reports
Enforcement of DNS Abuse Mitigation Requirements: Periodic Reviews
Contractual Compliance Monthly Reports
gTLD Registry Compliance
Accredited Registrar Compliance
General Questions
Outreach
Contracted Parties (Registry Operators and Accredited Registrars)
Domain Name Registrants
About Domain Names
ICANN Policies
Registration Data Policies
WHOIS and Registration Data Directory Services
The Domain Name Registration Process
Using Domain Name Registration Data
Keeping Registration Data Accurate
Access and the Evolution of the WHOIS System
Domain Name Industry
Registering Domain Names
Managing Domain Names
Contact Information and WDRP
Securely Managing Your Domain Name
Transferring Domain Names
Renewing Domain Names
Rights and Responsibilities
Spam, Phishing, and Website Content
Trademark Infringement
GDS Metrics
Identifier Systems Security, Stability and Resiliency (OCTO-SSR)
ccTLDs
Background Materials
Agreements
Delegation
Root Zone Database
Model MOU
Workshops
ICANN and ISO
Internationalized Domain Names
Root Zone Label Generation Rules (LGR)
Generation Panel Update
Maximal Starting Repertoire
Proposals for Root Zone Label Generation Ruleset
IDN Variant TLD Implementation
LGR Toolset
IDN ccTLD Fast Track
IDN Implementation Guidelines
Second-Level LGR Reference
Resources
Announcements and Blogs Posts
New gTLD Program
Universal Acceptance Initiative
Make your systems UA-ready
UA Training
UA Day
UA Readiness Evaluations
UA Initiatives
Announcements and Blogs Posts
Policy
Policy Mission
Policy Staff Goals
Presentations
Global Addressing
IPv6 Allocation
ASN Allocation
Post Exhaustion IPv4 Allocation
New RIRs Criteria
Review Procedures
Policy Updates
Operational Design Phase (ODP)
Implementation
Public Comment
Open
Upcoming
Archive
Root Zone KSK Rollover
Technical Functions
Tech Day Archive
ICANN Locations
Report Security Issues
PGP Keys
Certificate Authority
Registry Liaison
Ombudsman
I Need Help
Dispute Resolution
Domain Name Dispute Resolution
Charter Eligibility Dispute Resolution Policy
Providers
Rules
Eligibility Requirements Dispute Resolution Policy
Providers
Rules
Intellectual Property Defensive Registration Challenge Policy
Providers
Rules
Qualification Challenge Policy
Providers
Rules
Restrictions Dispute Resolution Policy
Providers
Rules
Transfer Dispute Resolution Policy
Providers
Uniform Domain Name Dispute Resolution Policy
Policy Document
Providers
Provider Approval Process
Rules
Principal Documents
Proceedings
Historical Documents
Timeline
Name Collision
Registrar Problems
Whois Data Correction
Independent Review Process
Request for Reconsideration
Document
ICANN Fellowship Selection Committee
ICANN Fellowship Program
Membership Makeup
|
Responsibilities
|
Terms of Service
|
Application Assessment
|
Committee Members
Last Updated: 25 June 2025
Fellowship Selection Committee Membership Makeup
Each Supporting Organization/Advisory Committee (SO/AC) shall nominate one representative to serve on the ICANN Fellowship Selection Committee, for a total of up to seven individuals.
SOs/ACs are strongly encouraged to consider diversity criteria when selecting a Selection Committee member including, but not limited to, geographic and gender diversity.
Each Selection Committee member will serve a two-year term, as detailed in Terms of Service (below).
Selection Committee member expectations:
Represent the global Internet community, with a strong history of experience with specific sector(s) of the Internet ecosystem including, but not limited to, technical Internet issues; government, academia, commercial or non-commercial issues; I* entities; underserved and/or under-represented communities and/or Internet related development, or other fellowship programs
Be an active member of the appointing SO/AC for at least two years (Definitions of active membership may vary, but generally include penholders for ICANN policy/procedural comments contributing significant time to the SO/AC)
Have a good understanding of ICANN and work conducted by other SOs/ACs
Have attended ICANN meetings as an active contributor/panelist/chair to a policy session
Additional notes:
It is desirable for Selection Committee representatives to have contributed meaningfully to cross-community working groups and/or be an active member of I* organisations
Nominated Selection Committee members may be Fellowship Program alumni
Fellowship Selection Committee Responsibilities
The ICANN Fellowship Selection Committee is responsible for assessing all applications for the
ICANN Fellowship
received through the online application system. Selection Committee members will then determine which applicants have best met the posted
Applicant Selection Criteria
. A time commitment of approximately 30-40 hours over four to five weeks is required (for each application round).
Additional responsibilities:
Support outreach efforts of the Fellowship Program
Work closely with Fellowship Program staff to follow the implementation and evaluation process
Update criteria for Fellowship selection regularly (every two years)
*Relevant ICANN staff, such as Global Stakeholder Engagement (GSE), review applications from their respective regions and sectors and provide comments on candidates' engagement, future potential, and regional strategic priority.
Terms of Service
Members of the Selection Committee shall serve for a total of two years (6 application rounds)
Selection Committee members are expected to devote a significant amount of time to the Fellowship Program; if a member chooses to resign, the relevant SO/AC will nominate a replacement for the remainder of the tenure
When the Selection Committee changes (every two years), former Selection Committee members are encouraged to share their experiences and insights with the new Section Committee members
Selection Committee members will be supported by ICANN staff as needed, via conference calls and email
Selection Committee members may not serve as Fellowship Program mentors
Application Assessment and Decision-Making Process
Up to 45 Fellowships will be available per round, including Fellowship mentors
Each Selection Committee member assesses the application based on the following applicant criteria: (1) diversity, (2) experience, (3) ICANN knowledge and engagement, and (4) potential for future engagement. Selection Committee members will review and revise the criteria every two years, as appropriate.
Fellowship Program slots will be filled based on the scores and qualitative assessments drawn from the Selection Committee's reviews, while considering the need for regionally diverse candidates from a range of sectors, including those from underserved and/or under-represented communities, along with sectors that lack diverse representation within ICANN.
Fellowship Selection Committee Members
Current Members
As part of
The New Fellowship Program Approach
, the Selection Committee is composed of members nominated by their respective Supporting Organization/Advisory Committee. The following members begun their selection process starting with ICANN84 – ICANN89 inclusively:
Community Group
Selection Committee Nominee
ALAC
Seun Ojedeji
ASO
Not participating
ccNSO
Pablo Rodriguez
GAC
Zeina Bou Harb
GNSO
Maud Arjeley Ashong Elliot
RSSAC
Gaurav Kansal
SSAC
Not participating
Past Members
The following members were part of the Selection Committee for ICANN80 – ICANN83 inclusively
Community Group
Selection Committee Nominee
ALAC
Laura Margolis
ASO
Not participating
ccNSO
Pablo Rodriguez
GAC
Mistura Aruna
GNSO
Taiwo Peter Akinremi
RSSAC
Gaurav Kansal
SSAC
Not participating
The following members were part of the Selection Committee for ICANN78 – ICANN79 inclusively
Community Group
Selection Committee Nominee
ALAC
Laura Margolis
ASO
Not participating
ccNSO
Stephen Deerhake
GAC
Mistura Aruna
GNSO
Taiwo Peter Akinremi
RSSAC
Gaurav Kansal
SSAC
Not participating
The following members were part of the Selection Committee for ICANN75 – ICANN77 inclusively
Community Group
Selection Committee Nominee
ALAC
Abdulkarim Oloyede
ASO
Not participating
ccNSO
Margarita Valdés
GAC
Mistura Aruna
GNSO
Sebastien Ducos
RSSAC
Amir Qayyum
SSAC
Not participating
The following members were part of the Selection Committee at ICANN74
Community Group
Selection Committee Nominee
ALAC
Abdulkarim Oloyede
ASO
Not participating
ccNSO
Margarita Valdés
GAC
Mistura Aruna
GNSO
Tomslin
Samme-Nlar
RSSAC
Amir Qayyum
SSAC
Not participating
The following members were part of the Selection Committee at ICANN72 and ICANN73
Community Group
Selection Committee Nominee
ALAC
Abdulkarim Oloyede
ASO
Not participating
ccNSO
Margarita Valdés
GAC
Mistura Aruna
GNSO
Heather Forrest
RSSAC
Amir Qayyum
SSAC
Not participating
The following members were part of the Selection Committee from ICANN65 till ICANN71 inclusively:
Community Group
Selection Committee Nominee
ALAC
Alfredo Calderon
ASO
Not participating
ccNSO
Pablo Rodriguez
GAC
Karel Douglas
GNSO
Heather Forrest
RSSAC
Amir Qayyum
SSAC
Not participating
Nashwa Abel Baki – Asia-Pacific: 3 years / 9 rounds
Carolina Aguerre – Latin America and the Caribbean: 2 years / 5 rounds
Nadira Al-Araj – Asia-Pacific: 2 years / 4 rounds
Christine Arida – Asia-Pacific: 3 years / 7 rounds
Fahd Batayneh – Asia-Pacific: 3 rounds * now ICANN staff
Tatiana Chirev – Europe: 3 years / 10 rounds
Mouhamet Diop – Africa: 3 years / 10 rounds
Ayman El-Sherbiny – Asia-Pacific: 1 year / 3 rounds
Demi Getschko – Latin American and the Caribbean: 3 years / 10 rounds
Steven Huter – North America: 3 years / 9 rounds
Erick Iriarte Ahon – Latin America and the Caribbean: 3 years / 8 rounds
Gaongalelwe ("Gao") Mosweu – Africa: 3 years / 7 rounds
Pierre Ouédraogo – Africa: 1.5 years / 5 rounds
Alejandro Pisanty – Latin America and the Caribbean: 3 years /10 rounds
Dustin Phillips – North America: 2 years / 4 rounds
Vanda Scartezini – Latin America and the Caribbean: 3 years / 9 rounds
Aftab Siddiqui – Asia-Pacific: 4 years / 8 rounds
Nelly Stoyanova – Europe: 3 years / 10 rounds
Sorina Telenau – Europe: 3 years / 6 rounds
Gaurab Raj Upadhaya – Asia Pacific: 3 years / 10 rounds
Hong Xie – Asia Pacific: 3 years / 9 rounds
ICANN is not responsible for profile content or verification of user details.
YouTube
Twitter
LinkedIn
Flickr
Facebook
Newsletters
Community Wiki
ICANN Blog
Who We Are
ICANN For Beginners
ICANN Learn
Participate
Groups
Board Members
CEO Corner
Staff
Careers
Public Responsibility
Contact Us
Locations
Report Security Issues
Certificate Authority
Registry Liaison
Ombuds
Complaints Office
Media Resources
Accountability And Transparency
Accountability Mechanisms
Document Disclosure
Independent Review Process
Request for Reconsideration
Empowered Community
Employee Anonymous Hotline Policy and Procedures
Governance
Governance Documents
Agreements
Organizational Reviews
Specific Reviews
Annual Report
Financials
Planning
RFPs
Litigation
Correspondence
Help
I Need Help
Dispute Resolution
Domain Name Dispute Resolution
Name Collision
ICANN Lookup
Registration Data Request Service (RDRS)
Data Protection
Data Privacy Practices
Privacy Policy
Terms of Service
Cookies Policy
© Internet Corporation for Assigned Names and Numbers.
Privacy Policy
Terms of Service
Cookies Policy
Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."

Year pattern in URL — weak evidence, not a verified publication date


Learn How to Participate in Policy Development - ICANN
Skip to main content
Search ICANN.org
Log In
Sign Up
Get Started
About ICANN
ICANN for Beginners
Fellowship Program
NextGen@ICANN Program
History
News and Media
Announcements
Blog
Media Resources
Press Releases
Global Newsletters
ICANN News Subscriptions
Regional Reports
Policy
Develop Policy
Operational Design Phase (ODP)
Implement Policy
Community Participation Guidelines
Public Comment
Public Comment Home
Upcoming Proceedings
Open Proceedings
Closed Proceedings
About Public Comment
Other Public Consultations
Resources
Board Activities and Meetings
Accountability Mechanisms
Contracted Parties (Registry Operators and Accredited Registrars)
Domain Name Registrants
Contractual Compliance
Domain Name Security Threats
Privacy and Proxy Services
Government Engagement
Careers
Complaints Office
I Need Help
ICANN 25th Anniversary Photo Mosaic
Community
Engagement Calendar
Address Supporting Organization (ASO)
Country Code Names Supporting Organization (ccNSO)
Generic Names Supporting Organization (GNSO)
At-Large Advisory Committee (ALAC)
Governmental Advisory Committee (GAC)
Root Server System Advisory Committee (RSSAC)
Security and Stability Advisory Committee (SSAC)
Quicklinks
Board Activities and Meetings
Data Protection and Privacy
Domain Name Registrants
Engagement Calendar
IANA Services
ICANN Acronyms and Terms
ICANN Grant Program
New gTLD Program
Public Technical Identifiers (PTI)
Open Data
Question About A Domain Name?
Technology @ ICANN
WSIS+20 Outreach Network
Resources
About ICANN
Academic Engagement
Acronyms and Terms
Courses and Learning
ICANN for Beginners
Participate
What ICANN Does
Effect on the Internet
What's Going On Now
How to Participate
Fellowship Program
Committee
Terms & Conditions
NextGen@ICANN Program
President's Corner
ICANN Management Organization Chart
Staff
Careers
In Focus
ICANN Response Planning Framework
DNSSEC
Standards
IANA DNSSEC Root Information
TLD DNSSEC Report
Root Deployment
Deployment Graph
Tools
Training
Key Ceremony
News
Blog Posts
Presentations
Related Sites
GNSO Improvements
Travel Support
Media Resources
ICANN News
About ICANN
Subscribe and Follow
Contacts
Board Activities and Meetings
Accountability
Accountability Mechanisms
Reconsideration
Independent Review Process
Updating the IRP
Ombuds
About the Ombuds Office
Contact the Ombuds Office
Ombuds Office Services
Complaints About Unfairness
Complaints About Harassment
Collaborative Conflict Resolution
Request for Reconsideration
Resources for Community Members
Ombuds Office Accountability
Ombud's Blogs
Empowered Community
Empowered Community Administration
Empowered Community Administration Mailing List
Empowered Community Correspondence
Document Disclosure
Reviews
Organizational Reviews
ALAC
ASO
Board
ccNSO
GNSO
Nominating Committee
RSSAC
SSAC
Technical Liaison Group
Specific Reviews
Accountability & Transparency
Registration Directory Service
Security, Stability, and Resiliency
Competition, Consumer Trust & Consumer Choice
CCT Metrics
Expected Standards of Behavior
Employee Practices and Resources
Enhancing ICANN Accountability – Work Stream 2 Implementation
Governance
Governance Documents
Evolving ICANN’s Multistakeholder Model
Agreements
NTIA IANA Functions' Stewardship Transition
Call for Public Input: Draft Process to Develop the Proposal (8 April-8 May 2014
Process to Develop the Proposal and Next Steps
Registry
Archive
Affirmation of Commitments
AOC Tracking
ccTLD
Partnership Memorandums of Understanding
Registrar
Archive
Annual Reports
Financials
Financial Reports
Policies, Guidelines and Procedures
Annual Disclosure of Payments to Suppliers
Lobbying Disclosures & Contribution Reports
Planning
Strategic Plan
ICANN Strategic Plan for FY26-30
ICANN's Annual Strategy Review Program
ICANN Strategic Plan for FY21-25
Strategic Outlook Trends Program
ICANN Strategic Plan for FY16-20
Operating Plan
Presentations
RFPs
Litigation
Newsletter
Correspondence
2026
2025
2024
2023
2022
2021
2020
2019
2018
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008
2007
2006
2005
2004
2003
2002
2001
2000
1999
1998
Quarterly Reports
Groups
2023 ICANN CEO Search Committee
RSSAC
Charter
SSAC
GAC
At-Large
ASO
ccNSO
GNSO
Technical Liaison Group
Technical Experts Group (TEG)
NomCom
Past NomComs
Customer Standing Committee
Root Zone Evaluation Review Committee (RZERC)
Business
Civil Society
Complaints Office
Complaints Report
Domain Name System Abuse
Contractual Compliance
About
Enforcement of DNS Abuse Obligations
Formal Enforcement Notices
Archive
Contractual Compliance Metrics
Blogs
Contractual Compliance Audit Program
Notice of Bankruptcy, Convictions and Security Breaches
Contractual Compliance Reports
Audit Reports
Enforcement of DNS Abuse Mitigation Requirements: Periodic Reviews
Contractual Compliance Monthly Reports
gTLD Registry Compliance
Accredited Registrar Compliance
General Questions
Outreach
Contracted Parties (Registry Operators and Accredited Registrars)
Domain Name Registrants
About Domain Names
ICANN Policies
Registration Data Policies
WHOIS and Registration Data Directory Services
The Domain Name Registration Process
Using Domain Name Registration Data
Keeping Registration Data Accurate
Access and the Evolution of the WHOIS System
Domain Name Industry
Registering Domain Names
Managing Domain Names
Contact Information and WDRP
Securely Managing Your Domain Name
Transferring Domain Names
Renewing Domain Names
Rights and Responsibilities
Spam, Phishing, and Website Content
Trademark Infringement
GDS Metrics
Identifier Systems Security, Stability and Resiliency (OCTO-SSR)
ccTLDs
Background Materials
Agreements
Delegation
Root Zone Database
Model MOU
Workshops
ICANN and ISO
Internationalized Domain Names
Root Zone Label Generation Rules (LGR)
Generation Panel Update
Maximal Starting Repertoire
Proposals for Root Zone Label Generation Ruleset
IDN Variant TLD Implementation
LGR Toolset
IDN ccTLD Fast Track
IDN Implementation Guidelines
Second-Level LGR Reference
Resources
Announcements and Blogs Posts
New gTLD Program
Universal Acceptance Initiative
Make your systems UA-ready
UA Training
UA Day
UA Readiness Evaluations
UA Initiatives
Announcements and Blogs Posts
Policy
Policy Mission
Policy Staff Goals
Presentations
Global Addressing
IPv6 Allocation
ASN Allocation
Post Exhaustion IPv4 Allocation
New RIRs Criteria
Review Procedures
Policy Updates
Operational Design Phase (ODP)
Implementation
Public Comment
Open
Upcoming
Archive
Root Zone KSK Rollover
Technical Functions
Tech Day Archive
ICANN Locations
Report Security Issues
PGP Keys
Certificate Authority
Registry Liaison
Ombudsman
I Need Help
Dispute Resolution
Domain Name Dispute Resolution
Charter Eligibility Dispute Resolution Policy
Providers
Rules
Eligibility Requirements Dispute Resolution Policy
Providers
Rules
Intellectual Property Defensive Registration Challenge Policy
Providers
Rules
Qualification Challenge Policy
Providers
Rules
Restrictions Dispute Resolution Policy
Providers
Rules
Transfer Dispute Resolution Policy
Providers
Uniform Domain Name Dispute Resolution Policy
Policy Document
Providers
Provider Approval Process
Rules
Principal Documents
Proceedings
Historical Documents
Timeline
Name Collision
Registrar Problems
Whois Data Correction
Independent Review Process
Request for Reconsideration
Document
Learn How to Participate in Policy Development
ICANN achieves its mission through implementation of policies approved by its Board of Directors. These policies start out as recommendations formed and refined by the global ICANN community through its Supporting Organizations and influenced by Advisory Committees.
To foster a culture of trust, transparency, and mutual respect, all participants are expected to follow the policies and procedures that make up the ICANN Ethics Policy, including the
Community Participant Code of Conduct
,
Expected Standards of Behavior
, and
Community Anti-Harassment Policy
.
Click
here
to learn more about how to participate and what is expected of participants.
Supporting Organizations and Advisory Committees (SOs and ACs)
The SOs and ACs are comprised of volunteers from over 130 countries and territories. In a bottom-up, open and transparent process, members of any SO and AC as well as the ICANN Board may raise an issue they believe requires policy development. The relevant Supporting Organization considers decisions or recommendations by Working Groups (see below) before forwarding them to the ICANN Board of Directors. The Board has ultimate authority to approve or reject policy recommendations.
More information about individual SO or AC communities can be found at these links:
ASO
ALAC
ccNSO
GAC
GNSO
RSSAC
SSAC
A Working Group Model of Policy Development
Volunteer policy development Working Groups form around an issue and consider it from all angles, making decisions by consensus wherever possible. Many of these Working Groups are open to everyone in ICANN’s volunteer community. There are regular ‘newcomer sessions’ in the form of online webinars that provide an ideal starting point for first-time volunteers that would like to participate in policy development. Typically, Working Group discussions are recorded and transcribed so that the public has full access to discussions and debates. Once finalized, major documents and executive summaries are typically translated into the six United Nations languages.
Public Comments
Written public comments are sought at several stages in the policy development process. The opportunity to comment is intended to provide interested community members with a means to share their views on policy proposals, and to ensure that policy recommendations reflect the concerns and perspectives of the broader Internet community. Learn more about community public comment opportunities that are currently open for input at the ICANN
Public Comment Page
.
ICANN Public Meetings
Public Meetings
take place three times a year. These gatherings of the ICANN community provide an excellent opportunity to participate in policy development.
Prior to every ICANN meeting, ICANN staff host preview
webinars
about upcoming high interest topics and issues that the community will face at the next public meeting.
Throughout the public meeting there are sessions, workshops and forums where community members can voice opinions, ask questions and otherwise engage in discussions on topics that interest them. In addition to valuable in-person opportunities, ICANN offers extensive remote participation capabilities for community members who are not able to travel to the public meeting in-person.
Every ICANN Public Meeting features a nearly half-day open forum for community members to express their views on topics that concern them in front of the whole community.
More To Come
The ICANN Board and staff are constantly looking to identify new and improved forms of community interaction to make the organization’s core policy development functions operate fairly and efficiently - while ensuring that the ICANN organization and all its policy development efforts remain transparent and accountable to the entire community.
ICANN is not responsible for profile content or verification of user details.
YouTube
Twitter
LinkedIn
Flickr
Facebook
Newsletters
Community Wiki
ICANN Blog
Who We Are
ICANN For Beginners
ICANN Learn
Participate
Groups
Board Members
CEO Corner
Staff
Careers
Public Responsibility
Contact Us
Locations
Report Security Issues
Certificate Authority
Registry Liaison
Ombuds
Complaints Office
Media Resources
Accountability And Transparency
Accountability Mechanisms
Document Disclosure
Independent Review Process
Request for Reconsideration
Empowered Community
Employee Anonymous Hotline Policy and Procedures
Governance
Governance Documents
Agreements
Organizational Reviews
Specific Reviews
Annual Report
Financials
Planning
RFPs
Litigation
Correspondence
Help
I Need Help
Dispute Resolution
Domain Name Dispute Resolution
Name Collision
ICANN Lookup
Registration Data Request Service (RDRS)
Data Protection
Data Privacy Practices
Privacy Policy
Terms of Service
Cookies Policy
© Internet Corporation for Assigned Names and Numbers.
Privacy Policy
Terms of Service
Cookies Policy
Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."


Participate – APNIC

Participate – APNIC
Skip to content
MyAPNIC
Academy
Blog
Orbit
REx
DASH
Home
Whois and website search
Search
Advanced Whois
Make
a
payment
Close Search
Search APNIC.net OR enter Whois database
query
Get IP
Get IP
Make a payment
Membership
FAQs
Manage IP
MyAPNIC
Using Whois
IPv4 exhaustion
Go IPv6
Routing Registry
Make a payment
Training
About
Events
APNIC Academy
Community Trainers
Courses
Events
Conferences
Calendar
Sponsorship
Code of Conduct
Insights
APNIC Labs
DASH to secure your networks
REx
Raw Data
Community
Orbit
Community demographics
Policy Development
Fellowship
Addressing policies
Internet community
Code of Conduct
Technical Assistance
Root servers
Security at APNIC
ISIF Asia
APNIC Foundation
NRO Number Council (NC)
Blog
Help Centre
About
APNIC Region
APNIC Membership
Executive Council
Service updates
Team
Annual Reports
Transparency
APNIC Survey
Corporate Documents
Publications Archive
Careers
Glossary
Contact
Advanced Whois
Make a payment
Get IP
Get IP
Make a payment
Membership
FAQs
Manage IP
MyAPNIC
Using Whois
IPv4 exhaustion
Go IPv6
Routing Registry
Make a payment
Training
About
Events
APNIC Academy
Community Trainers
Courses
Events
Conferences
Calendar
Sponsorship
Code of Conduct
Insights
APNIC Labs
DASH to secure your networks
REx
Raw Data
Community
Orbit
Community demographics
Policy Development
Fellowship
Addressing policies
Internet community
Code of Conduct
Technical Assistance
Root servers
Security at APNIC
ISIF Asia
APNIC Foundation
NRO Number Council (NC)
Blog
Help Centre
About
APNIC Region
APNIC Membership
Executive Council
Service updates
Team
Annual Reports
Transparency
APNIC Survey
Corporate Documents
Publications Archive
Careers
Glossary
Contact
Participate
You are part of a community of thousands of Internet professionals across the region, and there are many ways you can network, contribute and share your experiences with your peers.
Orbit
A place for the APNIC community to connect, discuss and share information related to Internet addressing and networking. Orbit is an evolution of mailing lists, facilitated by APNIC on behalf of the community.
Visit Orbit
Take part in the Policy Development Process (PDP)
You can directly impact the way APNIC manages Internet number resources by
proposing
changes to existing policies or suggesting new policies.
The APNIC
Policy Development Process (PDP)
is open to anyone who wants to participate and is a great way to build your profile and contribute to the Internet! You can get involved by:
Subscribe to the
Policy SIG mailing list
Submit
a policy proposal
Discuss the policies face-to-face at
APNIC conferences
or participate remotely
Contribute to the User Feedback Group
Join the User Feedback Group to provide your input into improving APNIC’s products and services for the whole community.
The group has opportunities to provide feedback and contribute your ideas with all experience levels welcome.
Learn more and join up
Build your professional networks at APNIC conferences
Join the APNIC community at the twice-yearly
conferences
held in the region to learn from experts, share new Internet technology insights, and build your industry contacts.
Claim your FREE conference registration
If you’re an APNIC Member, you’re entitled to one free conference registration to the APNIC standalone conference (held in Sep).
Build capacity by participating in Network Operator Groups
Share experiences, make new industry contacts, and learn from other network operators in your local economy by participating in NOG events. There are more than
15 NOGs
in the APNIC region and new groups are being formed regularly!
Learn with the APNIC Academy
Visit the
APNIC Academy
to better understand networking best practices and manage Internet number resources and use appropriate Internet technologies more effectively.
24/7
Available & Free
17+
Online courses
10+
Virtual labs (all from your browser!)
Virtual labs Online courses Available & Free
Monthly webinars on current network and security topics
Multilingual
Find out more
about face-to-face training in your economy
Stay informed by subscribing to the APNIC Blog
Visit and subscribe to the
APNIC Blog
for the latest news and views from the community.
Stay connected
Connect, share and get involved in discussion with the APNIC community via
APNIC’s social media
and
mailing lists .
Please be mindful of the
code of conduct
that applies to mailing lists.
Community demographics
Community Consultations
Send us feedback
Resource Policies
Fellowship
APNIC in the Internet ecosystem
Participate
Special Interest Groups
Orbit
Elections
APNIC Survey
Community Technical Support
Security at APNIC
IPv6@APNIC
APNIC Foundation
APNIC IPv4 post-exhaustion
APNIC Home
Connect with us
Facebook
Twitter
YouTube
Flickr
Weibo
Slideshare
LinkedIn
RSS
©
2026
APNIC
ABN 42 081 528 010
Privacy
Contact
Help Centre
NRO News
Service Status
Careers
Feedback