ICANN Grant Program - ICANN

ICANN Grant Program - 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 Grant Program
About
|
Key Documents
|
Grant Cycle Timeline
|
Reporting Summaries
|
FAQs
We are happy to announce that the ICANN Board has
officially approved
the final slate of applications to proceed to contract negotiations in the first cycle of the ICANN Grant Program. Congratulations to our future grantees and thank you to everyone who participated by applying.
The funded projects are listed below.
This marks an exciting milestone, and we look forward to seeing the impact these grants will have!
First Cycle of Funded Projects
Project Title
Organization
Country
Region
Project Duration (months)
Grant Amount
Deployment of IPv6 In African Countries
African Telecommunications Union
Kenya
AF
24
$398,040.50
Passive DNSSEC Data Collection Platform (GUPPY)
Ajman University
United Arab Emirates
AP
16
$410,300.00
Enhancing Digital Inclusivity and Universal Acceptance through Educational Outreach
Asociación A Favor De Lo Mejor, A.C.
Mexico
LAC
24
$500,000.00
African Internet Observatory for Assessing Resilience of Critical Cyber Infrastructure
Carnegie Mellon University
United States
NA
24
$450,389.00
Closing the DNSSEC Maturity Gap Through Automation
deSEC e.V.
Germany
EUR
24
$399,912.00
Empowering Māori in Internet Governance and DNS Management: A Culturally Tailored Educational Programme for Enhancing Equitable & Indigenous Participation in Aotearoa New Zealand's Digital Landscape
Digital Natives Academy Charitable Trust
New Zealand
AP
17
$350,000.00
Assessing GeoTLD's Performance for Enhanced Internet Accessibility: An Open Source Methodological Approach
Fundació privada puntCAT
Spain
EUR
23
$346,655.27
Shaping the WSIS+20 Review for a Unified Internet Through Multistakeholderism (SWUIM)
Global Network Initiative, Inc.
United States
NA
12
$500,000.00
Consumer-Focused Transformation of the Official Publication Site for the RFC Series
IETF Administration, LLC
United States
NA
13
$455,487.00
Improving DNS Security with a Focus on PKI
Internet Security Research Group
United States
NA
24
$375,000.00
Strengthening Open Source Tools for Managing IP Address Assignments via DHCP
Internet Systems Consortium, Inc
United States
NA
20
$495,000.00
Strengthening Kenya's Cybersecurity Posture: Inclusive Capacity Building across Five Regions
Kenya Education Network Registered Trustees
Kenya
AF
24
$500,000.00
Capacity Building And Community Engagement in ccTLDs and gTLDs Management Across Africa
Kenya Network Information Centre
Kenya
AF
17
$500,000.00
Investigating the Impact of DNS Centralization and Regional Discrepancies on the Security, Stability, Performance, and Resilience of DNS-dependent Applications
Ruhr-Universität Bochum
Germany
EUR
24
$499,912.38
Safeguarding Cyberspace Stability: Understanding and Mitigating the Impacts of Internet Fragmentation in the Black Sea Region
Scientific Cyber Security Association
Georgia
AP
24
$138,860.00
Universal Acceptance to the IDNs - Bottom-up Approach - Push 2.0
Seva Sahayog Foundation
India
AP
24
$387,487.50
Carbon.txt: Use DNS to Discover Sustainability and Energy Data and Reduce the Internet’s Emissions
Stichting The Green Web Foundation
Netherlands
EUR
16
$495,000.00
Secure Time for a Safe Internet
Stichting Trifecta Tech Foundation
Netherlands
EUR
24
$437,121.00
Assistance for Domain Name Holders in ICANN's Uniform Dispute Resolution Policy Procedures
Universidad Católica del Norte
Chile
LAC
24
$500,000.00
Addressing DNS Abuse in Southern Africa
University of Cape Town (Cybersecurity Capacity Centre for Southern Africa - C3SA)
South Africa
AF
24
$499,237.68
Deployability of ILNP at Global Scale
University of St Andrews
United Kingdom
EUR
24
$496,318.06
The DNS Atlas: Assessing Internet Dependency at Scale
Universiteit Twente
Netherlands
EUR
24
$500,000.00
Digital Sovereigns and the Non-Sovereign Internet: A Cautionary Tale (DSNS-ACT)
Vrije Universiteit Brussel
Belgium
EUR
24
$333,653.00
TOTAL
$9,968,373.39
Below is a selection of publications produced by some of the grantees on their funded projects:
Digital Natives Academy Charitable Trust
:
https://digitalnatives.academy/global-initiative-boosts-opportunities-for-tech-leadership/
IETF Administration LLC
:
https://www.ietf.org/blog/rfc-editor-website-reimagined/
African Telecommunications Union (ATU)
:
https://developingtelecoms.com/telecom-business/telecom-regulation/18614-atu-gets-icann-grant-to-accelerate-africa-s-transition-to-ipv6.html
Global Network Initiative, Inc.
:
https://globalnetworkinitiative.org/gni-and-gpd-launch-new-summary-infographic-on-wsis20-country-positions/
University of St Andrews
:
https://www.youtube.com/watch?v=ShjlUAN6FjI&t=1657s
Scientific Cyber Security Association
:
https://www.mdpi.com/1999-5903/18/1/19
About the ICANN Grant Program
The ICANN Grant Program is an exciting opportunity for eligible organizations across the globe to apply for funding for projects that are consistent with ICANN's mission and aligned with the objectives of the ICANN Grant Program.
This program will make a difference in the Internet ecosystem, while also positively impacting people all over the world by investing in creative and innovative solutions that further ICANN's vision of a single, open, and globally interoperable Internet.
The types of initiatives that the ICANN Grant Program will fund include those that support ICANN's mission by:
Benefitting the development, distribution, and evolution of the services and systems that support the Internet's unique identifier systems.
Providing capacity development.
Advancing developments, innovation, and open standards for the benefit of the Internet community.
Contributing to diversity, participation, and inclusion across stakeholder communities and geographic regions.
Key Documents
Applicant Guide
The ICANN Grant Program Applicant Guide provides instructions on how eligible organizations can apply to the program.
Access Version 3.0 of the Applicant Guide below:
English
|
العربية
|
Español
|
Français
|
Pусский
|
中文
(15 March 2024)
Archive
Version 2.0 of the Applicant Guide:
English
(26 February 2024)
Version 1.0 of the Applicant Guide:
English
|
العربية
|
Español
|
Français
|
Pусский
|
中文
(8 January 2024)
Additional Documents
Privacy Policy List of Third Party Providers
Grant Program Data Retention Policy
Grant Program Application Terms and Conditions
Grant Cycle Tentative Timeline
Grant platform opens for application submission
25 March 2024 at 15:00 UTC
Grant platform closes for application submission
24 May 2024 at 20:00 UTC
Admissibility and eligibility checks
June-July 2024
Independent Application Assessment Panel review
August-October 2024
Expected ICANN Board decision on final slate of successful applications
January 2025
Grant agreement negotiations
February 2025
For questions, please email
[email protected]
.
Reporting Summaries
June 2026 |
ICANN Grant Program First Interim Reporting Period Summary
FAQs
What is the ICANN Grant Program?
It is a global grant-making program funded by the proceeds received from last-resort auctions in the 2012 New gTLD Program. The ICANN community convened a working group that developed a
Final Report
with recommendations on how these proceeds should be allocated. On 12 June 2022 the ICANN Board
adopted
the recommendations. As a result, ICANN org developed a Grant Program.
How much funding is available?
The total net auction proceeds fund amounts to $217 million as of 30 June 2023 and are segregated from ICANN's general Operations. This may not be the final amount of proceeds available for distribution, as a portion of the auction proceeds funds under management are still subject to disputes. Additionally, costs to run the program will be covered by the auction proceeds fund.
The Grant Program will operate in a series of cycles. During each cycle, a portion of the total fund will be available for distribution for successful applications.
How much funding is available for the first cycle?
The total amount available for grants in this first cycle is $10 million.
What are the minimum and maximum grant amounts?
Applications can be submitted for grant awards between $50,000 and $500,000. These award thresholds are for the first cycle only and will be reassessed for future cycles.
What is the maximum project duration?
The maximum project duration is 24 months.
What types of projects and activities will be eligible?
Applications must be for projects consistent with ICANN's mission to help ensure the stable and secure operation of the Internet's unique identifier systems and align with the objectives of the Grant Program.
The types of initiatives that the program will fund include those that support the ICANN mission by:
Benefitting the development, distribution, and evolution of the services and systems that support the Internet's unique identifier systems.
Providing capacity development.
Advancing developments, innovation, and open standards for the benefit of the Internet community.
Contributing to diversity, participation, and inclusion across stakeholder communities and geographic regions.
All proposed activities also must not duplicate existing activities currently or previously funded by ICANN.
Please reference
Sections 2(iii)-2(v) and Sections 4(v) in the Grant Program Applicant Guide
for more information on what type of projects and funding themes are eligible.
What types of projects are not eligible?
Ineligible activities include:
Any political or lobbying activity, including activities to influence legislation and/or the outcome of any specific public election, or to carry on, directly or indirectly, any voter registration drive.
Any activity that may lead to private financial benefit of individuals beyond incidental items such as payment of reasonable employment salaries.
Any unlawful activity according to the country where the applicant is based and/or where the project is developed.
Who will evaluate the applications?
ICANN staff will initially review applications to confirm consistency with ICANN's mission and the Grant Program's funding themes. Applications that are deemed admissible and meet preliminary eligibility criteria will be referred to the Independent Application Assessment Panel (the Panel).
A third-party vendor will manage the Panel including the recruitment and selection of Panel members as well as manage their assessments of applications. This third-party vendor will be used to maximize independence from the ICANN Board, organization, or community.
The Panel composition is expected to include a diverse collective of subject matter experts aligned to the themes and work areas of the Program. The Panel will use assessment criteria outlined in the
Grant Program Applicant Guide Section 5(ii)
to deliver a rank order list. ICANN staff will conduct final eligibility screening before a final slate is prepared.
Grant Program Applicant Guide Section 5(iii)
provides more information on how final decisions will be made.
How will the funds be disbursed to the grantees?
Disbursement of the grants will occur in installments. The first installment will be disbursed to the grantee in a timely manner after the signing of the grant agreement. Following installments will be disbursed after the submission and approval of regular reports that the grantee is expected to produce and submit.
What will be required from the grantees?
Grantees will be expected to complete interim reports throughout the duration of the grant to document the progress of the project and the use of the funds. A final report will also be due at the conclusion of the project and should detail achievement of goals and objectives and final expenditures for the project.
Projects may be subject to additional monitoring activities, such as site visits to verify and document project activities as reported. On the occasion of any such activity, ICANN will contact the grantee directly to make arrangements for the visit at no cost to the grantee.
Grantees may also be subject to periodic reviews and evaluations. This may include surveys, participation in virtual or in-person meetings and interviews with ICANN staff, or other activities that require data collection related to implementation of the project and use of grant funds.
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."


Home | Generic Names Supporting Organization
Skip to main content
Search
Search
Acronym helper
If you're reading an ICANN document and cannot understand an acronym, type it here. Acronym Helper knows more than 400 acronyms, and will instantly show what the initials stand for. You'll find this Helper on every page of GNSO.ICANN.org.
If you are a member of the community and want to suggest an acronym for the helper please email your suggestion to start@icann.org
Main Menu
☰ Menu
Home
About
GNSO Council
Stakeholder Groups and Constituencies
Board Appointees
NomCom Appointees
Policy Staff
How To Participate
Other ICANN Structures
GNSO Structure Archive
Council Activities
Consensus Policies
Correspondence
Drafts and Working Documents
Elections
Presentations
Procedures
Program Management Tools Suite
Resolutions
Group Activities
Calendar
Active Projects
Mailing Lists
Program Management Tools Suite
Completed Projects
Quick Info
News
Announcements
GNSO Policy Briefing: ICANN Meeting Editions
Public Comments
Videos / Photos
Community Digest
Basics
What Does ICANN Do?
GNSO 101
GNSO Policy Development Introduction
DNS Infrastructure Basics
Learning on ICANN.ORG
ICANN Glossary
Quick Info
PDP Workspaces
Briefings & Documents
Education
GNSO Council
GNSO Calendar
Library
Quick info for: GNSO Council members
Quick info for: Working Group members
Quick info for: Newcomers
Working Group Workspaces
Translate
Announcements
Expression of Interest - GNSO Latin Script Diacritics Policy Development Process Working Group and Working Group Chair
03 January 2025
Expression of Interest – GNSO Nominated Member of the Fellowship Selection Committee
18 December 2024
Expression of Interest – GNSO Nominated Mentor for the ICANN Fellowship Program
18 December 2024
Updated: Expression of Interest - GNSO Nominated Mentor for the ICANN Fellowship Program
03 January 2024
SEE ALL
ICANN86, Seville Policy Outlook Report
The Policy Outlook Report is produced by ICANN's Policy staff including the staff supporting the GNSO. The GNSO section is drafted specifically in preparation for ICANN meetings to provide the Community with concise background information on all relevant GNSO policy efforts.
Follow the DNS Abuse Mitigation Policy Development Process
The ICANN community is currently engaged in a GNSO Council initiated Policy Development Process (PDP) on DNS Abuse Mitigation. The first PDP in addressing the complex topic of DNS Abuse Mitigation is narrowly scoped and focuses on Associated Domain Checks. Please be sure to follow the progress of the PDP Working through the ICANN community wiki page.
Enroll for Free in GNSO Online Course
As part of the ICANN Learn platform, you can Get to Know the GNSO by taking the online course.. The course is aimed mostly at newcomers but also serves veterans to refresh their knowledge. Topics covered include: 'The GNSO Stakeholder Groups and Constituencies', the GNSO's Policy Development Process, and 'How to keep up-to-date with the GNSO'.
0
1
2
GNSO Council Teleconference Minutes
Proposed
agenda and documents
Read more
about GNSO Council Teleconference Minutes
ALAC Conference Call Minutes - ALAC Conference Call Minutes
Participants: Izumi Aizu, Vittorio Bertola, Pierre Dandjinou, Roberto Gaetano, Xue Hong, Jacqueline Morris, Annette Muehlberg, Jean Armour Polly, Sebastián Ricciardi, Siavash Shahshahani, Wendy Seltzer, Bruce Beckwith
Absent: Clement Dzidonu, Bret Fausett, John Levine, Alice Wanjira-Munyua
Absent with reported conflict: Erick Iriarte Ahon
Liaison reports follow.
Whois Task Force Liaison (Wendy Seltzer)
Read more
about ALAC Conference Call Minutes - ALAC Conference Call Minutes
ALAC Requests an Issues Report on Post-Expiration Domain Recovery
Introductory Note
By the ICANN Staff
The At-Large Advisory Committee resolved in its meeting of 14 th October 2008:
Read more
about ALAC Requests an Issues Report on Post-Expiration Domain Recovery
ALAC Requests an Issues Report of the GNSO Staff Related to Domain Tasting
On 8 May 2007, the ALAC Liaison to the GNSO formally notified the Staff of ICANN that ALAC had resolved to request an Issues Report on the practice known as "Domain Tasting".
The ability to request an Issues Report is enshrined in the Bylaws of ICANN, in Annex B [insert hyperlink on phrase "Annex B" to
http://www.icann.org/en/general/bylaws.htm#AnnexB
]. This request marks the first occasion that an Issues Report has been requested by any Advisory Committee in ICANN.
Read more
about ALAC Requests an Issues Report of the GNSO Staff Related to Domain Tasting
ALAC Requests Comments on Draft Advisory to Board on GNSO Restructuring
Working Group on GNSO Restructuring Concludes Work - ALAC Working on Related Advisory for ICANN Board  - Comments by Community Sought
On 26 June 2008 the ICANN Board of Directors endorsed the recommendations of the Board Governance Committee's (BGC) GNSO Review Working Group, with the exception of the BGC's recommendation regarding GNSO Council restructuring.
Read more
about ALAC Requests Comments on Draft Advisory to Board on GNSO Restructuring
ALAC Response to the Proposed sTLD RFP and Suggested Principles for New TLD Processes
The
At Large Advisory Committee
welcomes the opportunity to provide comments on ICANN's proposed "
Establishment of new sTLDs: Request for Proposals
."
Read more
about ALAC Response to the Proposed sTLD RFP and Suggested Principles for New TLD Processes
Subscribe to
GNSO Calendar
Full Calendar View
Quick links to:
GNSO Policy Briefing Archives
Active Projects / Groups / Teams
Council Activities
ICANN Community WIKI
Footer Menu
Home
About
GNSO Council
Stakeholder Groups and Constituencies
Board Appointees
NomCom Appointees
Policy Staff
How To Participate
Other ICANN Structures
GNSO Structure Archive
Council Activities
Consensus Policies
Correspondence
Drafts and Working Documents
Elections
Presentations
Procedures
Program Management Tools Suite
Resolutions
Group Activities
Calendar
Active Projects
Mailing Lists
Program Management Tools Suite
Completed Projects
Quick Info
News
Announcements
GNSO Policy Briefing: ICANN Meeting Editions
Public Comments
Videos / Photos
Community Digest
Basics
What Does ICANN Do?
GNSO 101
GNSO Policy Development Introduction
DNS Infrastructure Basics
Learning on ICANN.ORG
ICANN Glossary
© 2026 The Internet Corporation for Assigned Names and Numbers. All rights reserved
Privacy Policy
Terms of Service
Cookies Policy
A note about our privacy policies and terms of service:
We have updated our privacy policies and certain website terms of service to provide greater transparency, promote simplification, and align with recent changes in privacy laws applicable to us.
Learn more.
This site uses cookies to deliver an efficient user experience and to help us see how the site is used.
Learn more.
OK


RFC 1462: FYI on 'What is the Internet?'

RFC 1462: FYI on "What is the Internet?" | RFC Editor
Skip to content
Info
RFC
1462
:
FYI
20
:
FYI on "What is the Internet?"
E. Krol
,
E. Hoffman
Informational
Network Working Group                                          E. Krol
Request for Comments: 1462                      University of Illinois
FYI: 20                                                     E. Hoffman
                                                   Merit Network, Inc.
                                                              May 1993
FYI on "What is the Internet?"
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.

Abstract

   This FYI RFC answers the question, "What is the Internet?" and is
   produced by the User Services Working Group of the Internet
   Engineering Task Force (IETF). Containing a modified chapter from Ed
   Krol's 1992 book, "The Whole Internet User's Guide and Catalog," the
   paper covers the Internet's definition, history, administration,
   protocols, financing, and current issues such as growth,
   commercialization, and privatization.

Introduction

   A commonly asked question is "What is the Internet?" The reason such
   a question gets asked so often is because there's no agreed upon
   answer that neatly sums up the Internet. The Internet can be thought
   about in relation to its common protocols, as a physical collection
   of routers and circuits, as a set of shared resources, or even as an
   attitude about interconnecting and intercommunication. Some common
   definitions given in the past include:

      * a network of networks based on the TCP/IP protocols,
      * a community of people who use and develop those networks,
      * a collection of resources that can be reached from those
        networks.

   Today's Internet is a global resource connecting millions of users
   that began as an experiment over 20 years ago by the U.S.  Department
   of Defense. While the networks that make up the Internet are based on
   a standard set of protocols (a mutually agreed upon method of
   communication between parties), the Internet also has gateways to
   networks and services that are based on other protocols.
Krol & Hoffman                                                  [Page 1]
RFC 1462
What is the Internet?                  May 1993
To help answer the question more completely, the rest of this paper
   contains an updated second chapter from "The Whole Internet User's
   Guide and Catalog" by Ed Krol (1992) that gives a more thorough
   explanation. (The excerpt is published through the gracious
   permission of the publisher, O'Reilly & Associates, Inc.)

The Internet (excerpt from "The Whole Internet User's Guide and
Catalog")

   The Internet was born about 20 years ago, trying to connect together
   a U.S. Defense Department network called the ARPAnet and various
   other radio and satellite networks. The ARPAnet was an experimental
   network designed to support military research--in particular,
   research about how to build networks that could withstand partial
   outages (like bomb attacks) and still function.  (Think about this
   when I describe how the network works; it may give you some insight
   into the design of the Internet.) In the ARPAnet model, communication
   always occurs between a source and a destination computer. The
   network itself is assumed to be unreliable; any portion of the
   network could disappear at any moment (pick your favorite
   catastrophe--these days backhoes cutting cables are more of a threat
   than bombs). It was designed to require the minimum of information
   from the computer clients. To send a message on the network, a
   computer only had to put its data in an envelope, called an Internet
   Protocol (IP) packet, and "address" the packets correctly. The
   communicating computers--not the network itself--were also given the
   responsibility to ensure that the communication was accomplished. The
   philosophy was that every computer on the network could talk, as a
   peer, with any other computer.

   These decisions may sound odd, like the assumption of an "unreliable"
   network, but history has proven that most of them were reasonably
   correct. Although the Organization for International Standardization
   (ISO) was spending years designing the ultimate standard for computer
   networking, people could not wait. Internet developers in the US, UK
   and Scandinavia, responding to market pressures, began to put their
   IP software on every conceivable type of computer. It became the only
   practical method for computers from different manufacturers to
   communicate. This was attractive to the government and universities,
   which didn't have policies saying that all computers must be bought
   from the same vendor. Everyone bought whichever computer they liked,
   and expected the computers to work together over the network.

   At about the same time as the Internet was coming into being,
   Ethernet local area networks ("LANs") were developed. This technology
   matured quietly, until desktop workstations became available around
   1983. Most of these workstations came with Berkeley UNIX, which
   included IP networking software. This created a new demand: rather
Krol & Hoffman                                                  [Page 2]
RFC 1462
What is the Internet?                  May 1993
than connecting to a single large timesharing computer per site,
   organizations wanted to connect the ARPAnet to their entire local
   network. This would allow all the computers on that LAN to access
   ARPAnet facilities. About the same time, other organizations started
   building their own networks using the same communications protocols
   as the ARPAnet: namely, IP and its relatives. It became obvious that
   if these networks could talk together, users on one network could
   communicate with those on another; everyone would benefit.

   One of the most important of these newer networks was the NSFNET,
   commissioned by the National Science Foundation (NSF), an agency of
   the U.S. government. In the late 80's the NSF created five
   supercomputer centers. Up to this point, the world's fastest
   computers had only been available to weapons developers and a few
   researchers from very large corporations. By creating supercomputer
   centers, the NSF was making these resources available for any
   scholarly research. Only five centers were created because they were
   so expensive--so they had to be shared. This created a communications
   problem: they needed a way to connect their centers together and to
   allow the clients of these centers to access them.  At first, the NSF
   tried to use the ARPAnet for communications, but this strategy failed
   because of bureaucracy and staffing problems.

   In response, NSF decided to build its own network, based on the
   ARPAnet's IP technology. It connected the centers with 56,000 bit per
   second (56k bps) telephone lines.  (This is roughly the ability to
   transfer two full typewritten pages per second.  That's slow by
   modern standards, but was reasonably fast in the mid 80's.)  It was
   obvious, however, that if they tried to connect every university
   directly to a supercomputing center, they would go broke. You pay for
   these telephone lines by the mile. One line per campus with a
   supercomputing center at the hub, like spokes on a bike wheel, adds
   up to lots of miles of phone lines. Therefore, they decided to create
   regional networks. In each area of the country, schools would be
   connected to their nearest neighbor. Each chain was connected to a
   supercomputer center at one point and the centers were connected
   together. With this configuration, any computer could eventually
   communicate with any other by forwarding the conversation through its
   neighbors.

   This solution was successful--and, like any successful solution, a
   time came when it no longer worked. Sharing supercomputers also
   allowed the connected sites to share a lot of other things not
   related to the centers. Suddenly these schools had a world of data
   and collaborators at their fingertips. The network's traffic
   increased until, eventually, the computers controlling the network
   and the telephone lines connecting them were overloaded. In 1987, a
   contract to manage and upgrade the network was awarded to Merit
Krol & Hoffman                                                  [Page 3]
RFC 1462
What is the Internet?                  May 1993
Network Inc., which ran Michigan's educational network, in
   partnership with IBM and MCI. The old network was replaced with
   faster telephone lines (by a factor of 20), with faster computers to
   control it.

   The process of running out of horsepower and getting bigger engines
   and better roads continues to this day. Unlike changes to the highway
   system, however, most of these changes aren't noticed by the people
   trying to use the Internet to do real work. You won't go to your
   office, log in to your computer, and find a message saying that the
   Internet will be inaccessible for the next six months because of
   improvements. Perhaps even more important: the process of running out
   of capacity and improving the network has created a technology that's
   extremely mature and practical. The ideas have been tested; problems
   have appeared, and problems have been solved.

   For our purposes, the most important aspect of the NSF's networking
   effort is that it allowed everyone to access the network. Up to that
   point, Internet access had been available only to researchers in
   computer science, government employees, and government contractors.
   The NSF promoted universal educational access by funding campus
   connections only if the campus had a plan to spread the access
   around. So everyone attending a four year college could become an
   Internet user.

   The demand keeps growing. Now that most four-year colleges are
   connected, people are trying to get secondary and primary schools
   connected. People who have graduated from college know what the
   Internet is good for, and talk their employers into connecting
   corporations. All this activity points to continued growth,
   networking problems to solve, evolving technologies, and job security
   for networkers.

What Makes Up the Internet?

   What comprises the Internet is a difficult question; the answer
   changes over time. Five years ago the answer would have been easy:
   "All the networks, using the IP protocol, which cooperate to form a
   seamless network for their collective users." This would include
   various federal networks, a set of regional networks, campus
   networks, and some foreign networks.

   More recently, some non-IP-based networks saw that the Internet was
   good. They wanted to provide its services to their clientele. So they
   developed methods of connecting these "strange" networks (e.g.,
   Bitnet, DECnets, etc.) to the Internet. At first these connections,
   called "gateways", merely served to transfer electronic mail between
   the two networks. Some, however, have grown to translate other
Krol & Hoffman                                                  [Page 4]
RFC 1462
What is the Internet?                  May 1993
services between the networks as well. Are they part of the Internet?
   Maybe yes and maybe no. It depends on whether, in their hearts, they
   want to be. If this sounds strange, read on--it gets stranger.

Who Governs the Internet?

   In many ways the Internet is like a church: it has its council of
   elders, every member has an opinion about how things should work, and
   you can either take part or not. It's your choice. The Internet has
   no president, chief operating officer, or Pope. The constituent
   networks may have presidents and CEO's, but that's a different issue;
   there's no single authority figure for the Internet as a whole.

   The ultimate authority for where the Internet is going rests with the
   Internet Society, or ISOC. ISOC is a voluntary membership
   organization whose purpose is to promote global information exchange
   through Internet technology.  (If you'd like more information, or if
   you would like to join, contact information is provided in the "For
   More Information" section, near the end of this document.)  It
   appoints a council of elders, which has responsibility for the
   technical management and direction of the Internet.

   The council of elders is a group of invited volunteers called the
   Internet Architecture Board, or the IAB. The IAB meets regularly to
   "bless" standards and allocate resources, like addresses. The
   Internet works because there are standard ways for computers and
   software applications to talk to each other. This allows computers
   from different vendors to communicate without problems. It's not an
   IBM-only or Sun-only or Macintosh-only network. The IAB is
   responsible for these standards; it decides when a standard is
   necessary, and what the standard should be. When a standard is
   required, it considers the problem, adopts a standard, and announces
   it via the network. (You were expecting stone tablets?) The IAB also
   keeps track of various numbers (and other things) that must remain
   unique. For example, each computer on the Internet has a unique 32-
   bit address; no other computer has the same address.  How does this
   address get assigned? The IAB worries about these kinds of problems.
   It doesn't actually assign the addresses, but it makes the rules
   about how to assign addresses.

   As in a church, everyone has opinions about how things ought to run.
   Internet users express their opinions through meetings of the
   Internet Engineering Task Force (IETF). The IETF is another volunteer
   organization; it meets regularly to discuss operational and near-term
   technical problems of the Internet. When it considers a problem
   important enough to merit concern, the IETF sets up a "working group"
   for further investigation. (In practice, "important enough" usually
   means that there are enough people to volunteer for the working
Krol & Hoffman                                                  [Page 5]
RFC 1462
What is the Internet?                  May 1993
group.) Anyone can attend IETF meetings and be on working groups; the
   important thing is that they work. Working groups have many different
   functions, ranging from producing documentation, to deciding how
   networks should cooperate when problems occur, to changing the
   meaning of the bits in some kind of packet. A working group usually
   produces a report. Depending on the kind of recommendation, it could
   just be documentation and made available to anyone wanting it, it
   could be accepted voluntarily as a good idea which people follow, or
   it could be sent to the IAB to be declared a standard.

   If you go to a church and accept its teachings and philosophy, you
   are accepted by it, and receive the benefits. If you don't like it,
   you can leave. The church is still there, and you get none of the
   benefits. Such is the Internet. If a network accepts the teachings of
   the Internet, is connected to it, and considers itself part of it,
   then it is part of the Internet. It will find things it doesn't like
   and can address those concerns through the IETF. Some concerns may be
   considered valid and the Internet may change accordingly.  Some of
   the changes may run counter to the religion, and be rejected. If the
   network does something that causes damage to the Internet, it could
   be excommunicated until it mends its evil ways.

Who Pays for It?

   The old rule for when things are confusing is "follow the money."
   Well, this won't help you to understand the Internet. No one pays for
   "it"; there is no Internet, Inc. that collects fees from all Internet
   networks or users. Instead, everyone pays for their part.  The NSF
   pays for NSFNET. NASA pays for the NASA Science Internet.  Networks
   get together and decide how to connect themselves together and fund
   these interconnections. A college or corporation pays for their
   connection to some regional network, which in turn pays a national
   provider for its access.

What Does This Mean for Me?

   The concept that the Internet is not a network, but a collection of
   networks, means little to the end user. You want to do something
   useful: run a program, or access some unique data. You shouldn't have
   to worry about how it's all stuck together. Consider the telephone
   system--it's an internet, too. Pacific Bell, AT&T, MCI, British
   Telephony, Telefonos de Mexico, and so on, are all separate
   corporations that run pieces of the telephone system. They worry
   about how to make it all work together; all you have to do is dial.

   If you ignore cost and commercials, you shouldn't care if you are
   dealing with MCI, AT&T, or Sprint. Dial the number and it works.
Krol & Hoffman                                                  [Page 6]
RFC 1462
What is the Internet?                  May 1993
You only care who carries your calls when a problem occurs. If
   something goes out of service, only one of those companies can fix
   it. They talk to each other about problems, but each phone carrier is
   responsible for fixing problems on its own part of the system.  The
   same is true on the Internet. Each network has its own network
   operations center (NOC). The operation centers talk to each other and
   know how to resolve problems. Your site has a contract with one of
   the Internet's constituent networks, and its job is to keep your site
   happy. So if something goes wrong, they are the ones to gripe at. If
   it's not their problem, they'll pass it along.

What Does the Future Hold?

   Finally, a question I can answer. It's not that I have a crystal ball
   (if I did I'd spend my time on Wall Street instead of writing a
   book). Rather, these are the things that the IAB and the IETF discuss
   at their meetings. Most people don't care about the long discussions;
   they only want to know how they'll be affected. So, here are
   highlights of the networking future.

New Standard Protocols

   When I was talking about how the Internet started, I mentioned the
   International Standards Organization (ISO) and their set of protocol
   standards. Well, they finally finished designing it. Now it is an
   international standard, typically referred to as the ISO/OSI (Open
   Systems Interconnect) protocol suite. Many of the Internet's
   component networks allow use of OSI today. There isn't much demand,
   yet. The U.S. government has taken a position that government
   computers should be able to speak these protocols. Many have the
   software, but few are using it now.

   It's really unclear how much demand there will be for OSI,
   notwithstanding the government backing. Many people feel that the
   current approach isn't broke, so why fix it? They are just becoming
   comfortable with what they have, why should they have to learn a new
   set of commands and terminology just because it is the standard?

   Currently there are no real advantages to moving to OSI. It is more
   complex and less mature than IP, and hence doesn't work as
   efficiently. OSI does offer hope of some additional features, but it
   also suffers from some of the same problems which will plague IP as
   the network gets much bigger and faster. It's clear that some sites
   will convert to the OSI protocols over the next few years.  The
   question is: how many?
Krol & Hoffman                                                  [Page 7]
RFC 1462
What is the Internet?                  May 1993
International Connections

   The Internet has been an international network for a long time, but
   it only extended to the United States' allies and overseas military
   bases. Now, with the less paranoid world environment, the Internet is
   spreading everywhere. It's currently in over 50 countries, and the
   number is rapidly increasing. Eastern European countries longing for
   western scientific ties have wanted to participate for a long time,
   but were excluded by government regulation. This ban has been
   relaxed. Third world countries that formerly didn't have the means to
   participate now view the Internet as a way to raise their education
   and technology levels.

   In Europe, the development of the Internet used to be hampered by
   national policies mandating OSI protocols, regarding IP as a cultural
   threat akin to EuroDisney.  These policies prevented development of
   large scale Internet infrastructures except for the Scandinavian
   countries which embraced the Internet protocols long ago and are
   already well-connected.  In 1989, RIPE (Reseaux IP Europeens) began
   coordinating the operation of the Internet in Europe and presently
   about 25% of all hosts connected to the Internet are located in
   Europe.

   At present, the Internet's international expansion is hampered by the
   lack of a good supporting infrastructure, namely a decent telephone
   system. In both Eastern Europe and the third world, a state-of-the-
   art phone system is nonexistent. Even in major cities, connections
   are limited to the speeds available to the average home anywhere in
   the U.S., 9600 bits/second. Typically, even if one of these countries
   is "on the Internet," only a few sites are accessible. Usually, this
   is the major technical university for that country. However, as phone
   systems improve, you can expect this to change too; more and more,
   you'll see smaller sites (even individual home systems) connecting to
   the Internet.

Commercialization

   Many big corporations have been on the Internet for years. For the
   most part, their participation has been limited to their research and
   engineering departments. The same corporations used some other
   network (usually a private network) for their business
   communications. After all, this IP stuff was only an academic toy.
   The IBM mainframes that handled their commercial data processing did
   the "real" networking using a protocol suite called System Network
   Architecture (SNA).

   Businesses are now discovering that running multiple networks is
   expensive. Some are beginning to look to the Internet for "one-stop"
Krol & Hoffman                                                  [Page 8]
RFC 1462
What is the Internet?                  May 1993
network shopping. They were scared away in the past by policies which
   excluded or restricted commercial use. Many of these policies are
   under review and will change. As these restrictions drop, commercial
   use of the Internet will become progressively more common.

   This should be especially good for small businesses. Motorola or
   Standard Oil can afford to run nationwide networks connecting their
   sites, but Ace Custom Software couldn't. If Ace has a San Jose office
   and a Washington office, all it needs is an Internet connection on
   each end. For all practical purposes, they have a nationwide
   corporate network, just like the big boys.

Privatization

   Right behind commercialization comes privatization. For years, the
   networking community has wanted the telephone companies and other
   for-profit ventures to provide "off the shelf" IP connections.  That
   is, just like you can place an order for a telephone jack in your
   house for your telephone, you could do this for an Internet
   connection. You order, the telephone installer leaves, and you plug
   your computer into the Internet. Except for Bolt, Beranek and Newman,
   the company that ran the ARPAnet, there weren't any takers.  The
   telephone companies have historically said, "We'll sell you phone
   lines, and you can do whatever you like with them." By default, the
   Federal government stayed in the networking business.

   Now that large corporations have become interested in the Internet,
   the phone companies have started to change their attitude. Now they
   and other profit-oriented network purveyors complain that the
   government ought to get out of the network business. After all, who
   best can provide network services but the "phone companies"?  They've
   got the ear of a lot of political people, to whom it appears to be a
   reasonable thing. If you talk to phone company personnel, many of
   them still don't really understand what the Internet is about. They
   ain't got religion, but they are studying the Bible furiously.
   (Apologies to those telephone company employees who saw the light
   years ago and have been trying to drag their employers into church.)

   Although most people in the networking community think that
   privatization is a good idea, there are some obstacles in the way.
   Most revolve around the funding for the connections that are already
   in place. Many schools are connected because the government pays part
   of the bill. If they had to pay their own way, some schools would
   probably decide to spend their money elsewhere. Major research
   institutions would certainly stay on the net; but some smaller
   colleges might not, and the costs would probably be prohibitive for
   most secondary schools (let alone grade schools).  What if the school
   could afford either an Internet connection or a science lab? It's
Krol & Hoffman                                                  [Page 9]
RFC 1462
What is the Internet?                  May 1993
unclear which one would get funded. The Internet has not yet become a
   "necessity" in many people's minds. When it does, expect
   privatization to come quickly.

   Well, enough questions about the history of the information highway
   system. It's time to walk to the edge of the road, try and hitch a
   ride, and be on your way.

Acknowledgments

   We would like to thank O'Reilly & Associates for permission to
   reprint the chapter from their book by Ed Krol (1992), "The Whole
   Internet User's Guide and Catalog."

For More Information

   Hoffman, E. and L. Jackson. (1993) "FYI on Introducing the Internet
   --A Short Bibliography of Introductory Internetworking Readings for
   the Network Novice," 4 p.  (FYI 19,
RFC 1463
).

      To find out how to obtain this document and other on-line
      introductory readings, send an e-mail message to:
      nis-info@nis.merit.edu, with the following text:
      send access.guide.

   Krol, Ed. (1992) The Whole Internet User's Guide and Catalog,
   O'Reilly & Associates, Sebastopol, CA. ISBN 1-56592-025-2.

   Quarterman, J. (1993) "Recent Internet Books," 15 p. (
RFC 1432
).

   The Internet Society
   Phone: (703) 620-8990
   Fax: (703) 620-0913
   E-mail: isoc@cnri.reston.va.us
Krol & Hoffman                                                 [Page 10]
RFC 1462
What is the Internet?                  May 1993
Security Considerations

   Security issues are not discussed in this memo.

Authors' Addresses

   Ed Krol
   Computing and Communications Service Office
   Univ. of Illinois Urbana Champaign (UIUC)
   1304 W Springfield
   Urbana, IL 61801

   Phone: (217)333-7886
   EMail: e-krol@uiuc.edu

   Ellen Hoffman
   Merit Network, Inc.
   2901 Hubbard, Pod-G
   Ann Arbor, MI 48105

   Phone: (313) 936-3000
   EMail: ellen@merit.edu

Krol & Hoffman                                                 [Page 11]
RFC
1462
: FYI on "What is the Internet?"
Informational


RFC 3677: IETF ISOC Board of Trustee Appointment Procedures | RFC Editor
Skip to content
Primary navigation
The RFC Series
For Authors
About Us
Home
RFC 3677
Info
RFC
3677
:
BCP
77
:
IETF ISOC Board of Trustee Appointment Procedures
L. Daigle
,
Ed.
,
Internet Architecture Board
Best Current Practice
Network Working Group L. Daigle, Ed.
Request for Comments: 3677 Internet Architecture Board
BCP: 77 IAB
Category: Standards Track December 2003
IETF ISOC Board of Trustee Appointment Procedures
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 (2003). All Rights Reserved.

Abstract

This memo outlines the process by which the IETF makes a selection of
an Internet Society (ISOC) Board of Trustees appointment.
1
. Introduction
The Internet Society (ISOC) provides organizational and financial
support for the IETF. As stipulated in ISOC's by-laws the IETF is
called upon to name 3 Trustees to its Board (BoT), with staggered 3
year terms. This requires that the IETF name one Trustee each year.

This memo outlines the process by which the IETF makes that
selection. This process will also be used in the event of mid-term
vacancies that may arise with IETF nominated Board positions.
1.1
. Overview of Selection Process
In brief, this document describes the timeframe and procedures for
the IAB to solicit public input and make a selection for the open
position each year.
1.2
. Rationale
An alternative approach to making a selection for these positions
would be to use the IETF's NomCom (
RFC 2727
[
1
] and its revisions).
However, that NomCom is chartered and defined specifically to the
task of making selections for IETF organization tasks, and the ISOC
BoT appointment process does not fit that in 2 ways:
Daigle & IAB Best Current Practice [Page 1]
RFC 3677
ISOC Trustee Appointment Procedures December 2003
1. the timeframe of the appointment does not mesh with the IETF
appointment cycle

2. the nature of the deliberations and the type of information
solicited would be significantly different for an external
appointment, such as this appointment to the ISOC BoT

The first issue (timing) could be resolved fairly easily for this
specific appointment. The second issue is more general, and not
reasonably reconciled with the IETF NomCom task as currently
specified.

The process described in
RFC 2727
is oriented toward soliciting
feedback from the IETF community with respect to individuals and
technical positions with which they have personal experience. To
make a good decision on external appointments, in general, the NomCom
would have to understand the requirements for those positions, and
attempt to evaluate candidates for a very different set of skills
than is required of IAB/IESG members. It might also require
soliciting feedback from outside the IETF community. There is no
question that the individuals that constitute the IETF NomCom each
year have the competence to carry out such a search; the issue is
that it is a very different task, would require additional time and
resources, and therefore is a side effort that could very well
undermine the effectiveness of the NomCom in carrying out its primary
task for the IETF.

By contrast, the IAB is chartered to be responsible for IETF external
liaisons, is a standing body that works with ISOC (and the ISOC
Board), and therefore has a working knowledge of the requirements of
the specific position discussed here.

At some future point, if there is a more general need to make
external appointments, the IETF may consider broadening the scope of
the IETF NomCom role, or create a separate nominating committee for
such external non-liaison appointments. This document proposes that
is not necessary or desirable for the purposes of this one annual
appointment.
2
. Desirable Qualifications and Selection Criteria for an
IETF-Nominated ISOC Trustee
Candidates for an ISOC Trustee should have a demonstrable involvement
in the IETF with a particular focus on active participation in IETF
Working Groups.
Daigle & IAB Best Current Practice [Page 2]
RFC 3677
ISOC Trustee Appointment Procedures December 2003
The candidate is expected to possess clearly demonstrated technical
competence in Internet technology, and be able to articulate
technology issues such that the ISOC Board can be provided with sound
technical perspectives. The candidate is also expected to be able to
understand the respective roles and responsibilities of the IETF and
ISOC and be able to articulate these roles within both organizational
communities.

The candidate will also be expected to exercise all the duties of an
ISOC Board member, including fiduciary responsibility, setting of
policies, oversight of the operation of the Society, representing
the interests of the members and stakeholders of the Society and
participation in all Board meetings and Board activity programs.

The candidate is not a representative or a delegate of the IETF and
is not chartered to represent the IETF or the IETF Standards Process
within the ISOC Board or the broader ISOC community. However it is
expected that the candidate would be able to call on experts in the
IETF community as required, to ensure that the ISOC Board receives
the highest quality technical advice available.
3
. IETF ISOC Board of Trustees Selection Process
3.1
. Nominations and eligibility
Each year, the IAB will make a public call for nominations on the
ietf-announce@ietf.org mailing list. The public call will specify
the manner by which nominations will be accepted and the means by
which the list of nominees will be published.

Self-nominations are permitted. Along with the name and contact
information for each candidate, details about the candidate's
background and qualifications for the position should be attached to
the nomination. All IETF participants, including working group
chairs, IETF NomCom members, IAB and IESG members are eligible for
nomination.

IAB and IESG members who accept nomination will recuse themselves
from selection and confirmation discussions respectively.
3.2
. Selection
The IAB will publish the list of nominated persons, review the
nomination material, and make a selection.
Daigle & IAB Best Current Practice [Page 3]
RFC 3677
ISOC Trustee Appointment Procedures December 2003
The selection criteria will include additional consideration of any
nominated candidates who are concurrently members of the IAB or IESG
members such that at the time of selection no more than two of the
three IETF-appointed ISOC Trustees are IAB and IESG members.
3.3
. Confirmation
The IESG will act as the confirming body for the selection. In the
event that the IESG determines not to confirm the nominated
candidate, the IESG will provide the IAB with the basis for this
determination and the IAB will nominate another candidate.
3.4
. Timeframe
ISOC expects to seat new Board members at its annual general meeting
in June of each year. Basic timeframe requirements for the IETF
process are as follows:

o 4-6 weeks for solicitation of nominations

o 4-6 weeks for review of nominees, deliberation and selection

o 4-6 weeks for confirmation (and re-selection as necessary) and
delivery to ISOC

In January of each year, the IAB will announce the specific dates for
the IETF ISOC Trustee selection process for that year (taking into
account the particular dates of the first IETF meeting of the year,
etc), following the guidelines above.
3.5
. Mid-term Vacancies
This document describes the process for the general, annual
appointment of ISOC Trustees to fill the seats of Trustees whose
terms are ending. However, if an IETF-appointed Trustee is unable to
serve his or her full term, the IAB may, at its discretion,
immediately select a replacement to serve the remainder of the term
using the interim process defined in
Section 3.5.1
. If the IAB does
not invoke the interim process, the next annual selection process
will fill the vacancy (if the vacant term does not end at that point)
as well as the regular appointment for that selection cycle.
3.5.1
. Interim Appointment Process
If the IAB elects to fill the mid-term vacancy before the next annual
selection, a separate timeline will be announced and the rest of the
process described in this document will be followed.
Daigle & IAB Best Current Practice [Page 4]
RFC 3677
ISOC Trustee Appointment Procedures December 2003
4
. Security Considerations
This document does not describe any technical protocols and has no
implications for network security.
5
. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in
BCP-11
. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
6
. References
[
1
] Galvin, J., "IAB and IESG Selection, Confirmation, and Recall
Process: Operation of the Nominating and Recall Committees",
BCP
10
,
RFC 2727
, February 2000.
Daigle & IAB Best Current Practice [Page 5]
RFC 3677
ISOC Trustee Appointment Procedures December 2003
Appendix A
. IAB Members at the time of this writing
Bernard Aboba

Harald Alvestrand

Rob Austein

Leslie Daigle

Patrik Faltstrom

Sally Floyd

Mark Handley

Geoff Huston

Jun-ichiro (Itojun) Hagino

Charlie Kaufman

James Kempf

Eric Rescorla

Mike St.Johns

Authors' Addresses

Leslie Daigle
Editor

Internet Architecture Board
IAB

EMail: iab@iab.org
Daigle & IAB Best Current Practice [Page 6]
RFC 3677
ISOC Trustee Appointment Procedures December 2003
Full Copyright Statement

Copyright (C) The Internet Society (2003). All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.

Acknowledgement

Funding for the RFC Editor function is currently provided by the
Internet Society.

Daigle & IAB Best Current Practice [Page 7]
RFC
3677
: IETF ISOC Board of Trustee Appointment Procedures
Best Current Practice
Contents
About this RFC
Errata
2
In this section
1. Introduction
1.1. Overview of Selection Process
1.2. Rationale
2. Desirable Qualifications and Selection Criteria for an
IETF-Nominated ISOC Trustee
3. IETF ISOC Board of Trustees Selection Process
3.1. Nominations and eligibility
3.2. Selection
3.3. Confirmation
3.4. Timeframe
3.5. Mid-term Vacancies
3.5.1. Interim Appointment Process
4. Security Considerations
5. Intellectual Property Statement
6. References
Appendix A. IAB Members at the time of this writing
Footer
rfc-editor.org is maintained by the
Internet Engineering Task Force
System Status
·
Report a Bug
·
Version 1.76.1
Useful links
IETF.org
IRTF.org
IAB.org
Datatracker
Author Resources
Contact Us
RFC Editor
rfc-dist Info Page
rfc-interest Info Page
Expand sidebar


Root Server System Advisory Committee (RSSAC)
العربية
中文
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
Root Server System Advisory Committee (RSSAC)
The RSSAC is a group of root server operators and specialists that provides insights and advice to the ICANN Board and community about the management of the Internet’s Root Server System.
Subscribe
RSSAC Home
RSSAC Caucus
RSSAC Publications
Technology @ ICANN
Community Home
Root Server System Advisory Committee (RSSAC)
About the RSSAC
The RSSAC advises the ICANN community and the Board on matters relating to the operation, administration, security, and integrity of the Root Server System. The RSSAC consists of representatives from the root server operator organizations and liaisons from the partner organizations involved in the technical and operational management of the root zone.
The
RSSAC Caucus
is composed of Domain Name System experts who have an interest in the RSS and who broaden the base of diverse technical expertise available for RSSAC work. The primary role of the RSSAC Caucus is to perform research and produce publications on topics relevant to the mission of the RSSAC.
How to Become Involved
Interested parties can apply for membership in the RSSAC Caucus by submitting a
statement of interest
to the RSSAC Caucus Membership Committee. In this statement of interest, RSSAC Caucus applicants should indicate their preferred work areas and relevant expertise. The Membership Committee considers the following points when reviewing applicants: knowledge of the Domain Name System (DNS), experience within the DNS community, and a commitment to participate.
Members of the RSSAC Caucus can serve as leaders who produce or contribute to documents. RSSAC Caucus members may also submit personal opinions about a document at any point in the process, and specifically once the document has been submitted to the RSSAC.
Current Members
Learn more about the RSSAC’s members and leaders who represent root server operator organizations and other partner organizations in related fields.
READ MORE
FAQ
Get answers to common questions about RSSAC, the Root Server System, and more at our Frequently Asked Questions page.
READ MORE
Meetings
Find out what is happening with the RSSAC by viewing minutes from its past meetings.
READ MORE
Publications
Browse a list of RSSAC advisories, reports, and statements on a range of topics including the technical aspects of the Root Server System and root zone operations.
READ MORE
RSSAC Caucus
Get information about the RSSAC Caucus and the experts who research and write RSSAC advisories, comments, statements, procedures, and reports.
READ MORE
Work Plan
Get an overview of the activities undertaken by the RSSAC, the RSSAC Caucus, and the ICANN organization by month.
READ MORE
Current Members
Learn more about the RSSAC’s members and leaders who represent root server operator organizations and other partner organizations in related fields.
READ MORE
FAQ
Get answers to common questions about RSSAC, the Root Server System, and more at our Frequently Asked Questions page.
READ MORE
Meetings
Find out what is happening with the RSSAC by viewing minutes from its past meetings.
READ MORE
Publications
Browse a list of RSSAC advisories, reports, and statements on a range of topics including the technical aspects of the Root Server System and root zone operations.
READ MORE
RSSAC Caucus
Get information about the RSSAC Caucus and the experts who research and write RSSAC advisories, comments, statements, procedures, and reports.
READ MORE
Work Plan
Get an overview of the activities undertaken by the RSSAC, the RSSAC Caucus, and the ICANN organization by month.
READ MORE
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


Media Resources - ICANN

Media Resources - 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
Media Resources
ICANN News
|
About ICANN
|
Subscribe and Follow
|
Contacts
ICANN News
Read
the latest ICANN press releases.
Read
the latest ICANN announcements.
Read
the latest ICANN blogs.
About ICANN
ICANN's mission is to help ensure a stable, secure, and unified global Internet. To reach another person on the Internet, you need to type an address – a name or a number – into your computer or other device. That address must be unique so computers know where to find each other. ICANN helps coordinate and support these unique identifiers across the world. ICANN was formed in 1998 as a nonprofit public benefit corporation with a community of participants from all over the world.
ICANN's vision is to be a champion of the single, open, and globally interoperable Internet, by being the independent, trusted, multistakeholder steward of the Internet's unique identifiers, and by providing an open and collaborative environment where diverse stakeholders come together in the global public interest.
ICANN is a California-based nonprofit, public-benefit organization accountable to a global community of stakeholders. Its enduring mission is to ensure a stable, secure, and unified Internet. ICANN follows a multistakeholder model in which individuals, businesses, civil society, governments, and technologists play important roles in its community-based, consensus-driven, policymaking approach. Additional information and media assets are available at the resources below.
Fact Sheet
English
|
العربية
|
Español
|
Français
|
Pусский
|
中文
ICANN ON – Supporting a More Multilingual Internet
ICANN ON – Internationalized Domain Names in Action Globally
ICANN Board Members
ICANN Executives
Download
ICANN logos, images, and infographics.
Subscribe and Follow
Sign up for email alerts
to receive the latest ICANN blogs, announcements, Public Comment proceedings, and other updates directly to your email inbox. When new content is added or updated on our website, ICANN will send you a daily or weekly email with links to that content.
Subscribe to ICANN Regional Newsletters
to stay up to date on the latest ICANN global and regional stories.
Follow the latest ICANN activities on
social media
Contacts
General Media Inquiries:
[email protected]
Region-specific Inquiries:
Asia Pacific
: Liana Teo, Singapore,
[email protected]
, +65 9113 2001
Europe, Middle East, and Africa
: Luna Madi, Istanbul, Turkey,
[email protected]
, +90 533 0313505
The Americas
: Alexandra Dans, Montevideo, Uruguay,
[email protected]
, +598 95 831 442
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."