IETF  | RFCs

IETF | RFCs
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
Process
About RFCs
RFCs are the core output of the IETF.
Introduction
Structure of the series
Availability and use
Publication formats
Statuses
Publication streams
Obsoleting and updating
Corrections and errata
Reporting vulnerabilities in RFCs
Introduction
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 IETF RFC.
Structure of the series
RFCs are sequentially numbered, starting with RFC 1 published in 1969. (The RFC series predates the IETF.) Today, there are more than 9000 documents in the series.
The RFC series has two subseries, STDs and BCPs, with each numbered STD and BCP comprising one or more RFCs. STDs are 'Internet Standard' RFCs, and BCPs are RFCs that describe 'Best Current Practices' for the Internet, some of which are administrative processes for the IETF.
Availability and use
RFCs are freely available to download, copy, publish, display and distribute, in a variety of formats, under a license granted by the
IETF Trust
. This license, the
Trust Legal Provisions
has some important restrictions, including a prohibition on modification of IETF RFCs outside of the IETF Standards Process.
RFCs are not guaranteed to be patent-free and anyone interested in the Intellectual Property Rights (IPR) constraints on a specific document should consult the IETF's
IPR disclosure database
, though this is not guaranteed to be a complete record of applicable patents.
Publication formats
RFCs are published in the following formats:
HTML
. This is the most flexible format for reading an RFC: the page layout adapts to the window size; if SVG diagrams are supplied, they are displayed; and the text is accompanied by a header showing important metadata, including the details of any RFCs that this RFC updates or obsoletes, and vice versa, as well as indicating the existence of errata and linking to those. For RFCs before RFC 8650, the HTMLised (see below) format is used in place of the HTML.
Plain Text
. RFCs were originally produced on typewriters, and a plain text format that looks very similar to those original RFCs is still available. The main limitations of the plain text format are that the metadata cannot change, only ASCII diagrams can be displayed, links in the text are shown as annotations, the line width is fixed so may be difficult to read on a mobile device, and there is no indication of the existence of errata.
HTMLised
. This format displays the Plain Text format as an HTML page with working links and the same metadata as the HTML version; however, it shares the rest of the limitations as the plain text format. This format is available for RFCs before RFC 8650.
PDF
. This is a PDF of an HTML rendering of the RFC, so it can display any SVG diagrams and it provides working links. However, the metadata is limited. PDFs are the only paginated RFC format.
RFCXML
. This is the raw source of RFCs, not a publication format. RFCXML is an XML language fully documented on the
I-D Authors Resource Site
and has been used as the source format since RFC 8650.
Statuses
Most RFCs and all new RFCs have one of the following statuses. Statuses may change over time.
Informational
.
An "Informational" specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation.
RFC 2026, Section 4.2.2
Experimental
.
The "Experimental" designation typically denotes a specification that is part of some research or development effort. Such a specification is published for the general information of the Internet technical community and as an archival record of the work
RFC 2026, Section 4.2.1
Standards have one of the following statuses:
Proposed Standard (PS)
. The first official stage. Many standards never progress beyond this level.
Draft Standard
. An intermediate stage that is no longer used for new standards.
Internet Standard
. The final stage, when the standard is shown to be interoperable and widely deployed.
Best Current Practice (BCP)
. BCPs have a dual role. One is to document IETF processes as agreed by the IETF community, and the other is explained in
RFC 2026, Section 5
as:
since the Internet itself is composed of networks operated by a great variety of organizations, with diverse goals and rules, good user service requires that the operators and administrators of the Internet follow some common guidelines for policies and operations.
Historic
.
A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the "Historic" level.
RFC 2026, Section 4.2.4
RFCs that were published before statuses were introduced (before RFC 1128) are mostly considered to have an
Unknown
status, with a handful having had statuses retroactively applied.
Publication streams
There are five streams that can publish an RFC.
The
IETF Stream
is the only stream that can publish standards and by far the largest. All RFCs published in the IETF Stream must have community rough consensus, whatever their status.
The
IAB Stream
and
IRTF Stream
can also publish technical and process RFCs related to their role.
The
Editorial Stream
, as described by
RFC 9920
publishes policies governing the RFC Series as a whole.
The
Independent Submissions Stream
publishes RFCs that are outside the official processes of the IETF, IAB, and IRTF but are relevant to the Internet community and achieve reasonable levels of technical and editorial quality.
Obsoleting and updating
An RFC can be entirely obsoleted by a new RFC or have parts of it updated by other RFCs. A new RFC can update parts of multiple RFCs, and can obsolete multiple RFCs.
Most of the publication formats note if an RFC has been obsoleted or updated and lists the RFCs responsible.
Corrections and errata
With one exception, once an RFC is published, it is never changed, which is why the RFC series is often described as "archival" in nature. The one exception to this rule is if an RFC is rendered incorrectly, such as some text cut off, in which case the specific publication format with the problem may be replaced.
If a technical or editorial error in an RFC is reported, an erratum may be created that documents the error and optionally provides a correction. Newly Reported errata are checked and either Verified, Rejected or Held for Document Update. For Technical errata, this decision is made by the appropriate stream-specific party, and for Editorial errata, by the RFC Editor.
The RFC Editor site has more details on these
statuses
and a
searchable errata database
.
Verified errata are linked to the RFC, but the RFC is not republished with the errata incorporated. There is ongoing work to provide a good way of displaying an RFC with the errata incorporated.
Reporting vulnerabilities in RFCs
The IETF recognizes that security vulnerabilities will be discovered in IETF protocols and welcomes their critical evaluation by researchers. If you believe that you have discovered a vulnerability in an IETF protocol then please follow our guidance on
how to report vulnerabilities
.
you might be interested in
RFC Editor website
How to Read an RFC
RFC 8700: Fifty Years of RFCs
Key moments in RFC History (from RFC 8700)
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)
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


IETF  | Process

IETF | Process
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
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.
Improving existing standards and creating, implementing, and deploying new standards is an ongoing effort. The
IETF's mission
is to produce high quality, relevant technical documents that describe these voluntary standards.
IETF working groups
are the primary mechanism for development of IETF specifications and guidelines.
Guide to the IETF standards process
The IETF follows open and well-documented processes for its work, including setting Internet standards. This guide synthesizes various sources to describe the IETF standards process at a high level.
Informal guide to IETF process documents
This informal guide to documents about the Internet Engineering Task Force (IETF) standards process aims to assist IETF participants by providing an introduction to the variety of documents that describe it, as well as related groups and processes.
Bringing new work to the IETF
A guide for people who have a new idea or some proposed work they wish to bring to the IETF.
Intellectual property rights (IPR)
A basic guide to the complex subject of Intellectual Property Rights (IPR) and the IETF
Guide to IETF Working Groups
Working Groups (WGs) are the primary mechanism for development of IETF specifications and guidelines, many of which are intended to be standards or recommendations.
Birds of a Feather (BOF)
Birds of a Feather sessions (BOFs) are initial discussions about a particular topic of interest to the IETF community. BOFs are usually held at IETF meetings, and requests to hold a BOF must be made significantly in advance of the meeting.
Protocol registries (IANA)
The global coordination of the DNS Root, IP addressing, and other Internet protocol resources is performed as the Internet Assigned Numbers Authority (IANA) functions.
About RFCs
RFC documents contain technical specifications and organizational notes for the Internet and are the core output of the IETF.
Publishing and accessing RFCs
Internet-Drafts that have successfully completed the IETF review process are submitted to the RFC Editor for publication.
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


Global Digital Compact | Office for Digital and Emerging Technologies
Skip to main content
Welcome to the United Nations
Toggle navigation
Language:
عربي
中文
English
Français
Русский
Español
Office for Digital and Emerging Technologies
Search form
A-Z Site Index
Search
Toggle navigation
Home
Global Digital Compact
Endorse the Global Digital Compact
UN Digital Cooperation Portal
AI Governance
Independent International Scientific Panel on AI
Global Dialogue on AI Governance
AI Governance for Humanity Lab
HLAB on Artificial Intelligence (2023–2024)
Digital Public Infrastructure
Events
Past Events
India AI Impact Summit (February 2026)
Building the Commons (December 2025)
UN Digital Cooperation Day (September 2025)
STI Forum Action Day (May 2025)
UN Open Source Week 2026 (June 2026)
UN Digital Cooperation Day (September 2026)
About
Contact
News and Resources
Home
Global Digital Compact
Global Digital Compact
Your browser does not support the video tag.
Get Involved with the Global Digital Compact
Join the Global Digital Compact
Access the UN Digital Cooperation Portal
Background on Intergovernmental Processes
Global Digital Compact Intergovernmental Process (2023–2024)
AI Panel & Dialogue Intergovernmental Process (2025)
Contact Us
Global Digital Compact:
digitalcompact@un.org
General Inquiries:
odet@un.org
Donate
facebook
twitter
youtube
flickr
instagram
Footer
A-Z Site Index
Contact
Copyright
FAQ
Fraud Alert
Privacy Notice
Terms of Use


ITU Constitution and Convention (1992)

Constitution and Convention Collection
Connecting the world and beyond
عربي
中文
Español
Français
Русский
Advanced Search
ITU
About ITU
Media Centre
Events
Publications
Statistics
Action areas
Regional Presence
Careers
General Secretariat
Radiocommunication
Standardization
Development
News
Members' Zone
Join ITU
Constitution and Convention Collection

Search this Collection

ImageUrl
You are here
ITU
>
Homepage
>
History of ITU Portal
Share
History of ITU Portal
Site Map
Explore the Digital Collections
Discover ITU's History
Focus on Areas of Work
Overview of ITU's History article
ITU Library and Archives
Send feedback

Page Content 20
Persistent Identifier for this page
Page Content 20 Title Hyperlink
http://handle.itu.int/11.1004/020.1000/5
Page Content 2
The International Telegraph (later Telecommunication) Convention, today the Constitution and Convention of ITU, is the basic treaty that establishes the legal basis for the Union and defines its purpose and structure.
The first International Telegraph Convention signed in 1865 established the basic principles for international telegraphy. In order to keep up with advances in telegraphy, the Member States met regularly to revise the Convention and the annexed International Service Regulations (also known as the Telegraph Regulations).
Useful links
Page Content 3
Signature and ratification status of ITU's treaties (Position of Member States)
Glossary of terms relating to Treaty actions (UN Treaty Collection)
Page Content
For a brief period from 1906 to 1932, the regulation of radiotelegraph (“wireless”) communications was managed by a separate, but related, treaty – the International Radiotelegraph Convention.
In 1932, the International Telegraph Convention and the International Radiotelegraph Convention were merged into a single new convention, the International Telecommunication Convention. This new Convention covered the three fields of telegraphy, telephony and radio.
The International Telecommunication Convention was revised regularly until 1989, when the Plenipotentiary Conference in Nice agreed to establish a stable Constitution and Convention. The 1989 Constitution and Convention of the International Telecommunication Union never received the required number of ratifications, however, and so it never came into effect. It is not included in the list below for this reason.
A thoroughly revised Constitution and Convention of the International Telecommunication Union was adopted at the 1992 Additional Plenipotentiary Conference held in Geneva. Subsequent plenipotentiary conferences have adopted only amending instruments to the 1992 documents. The Constitution and Convention currently in force are the Consti
tution and Convention of the International Telecommunication Union (Geneva, 1992) as amended by subsequent plenipotentiary conferences.

The History of ITU Portal uses Persistent Identifiers for its digitized
documents. To copy a Persistent ID, hover the cursor over the document link and then right-click on it.

Year
Title
English
Français
Español
عربي
中文
Русский
1865
International Telegraph Convention (Paris, 1865)
FR
1868
International Telegraph Convention (Vienna, 1868)
FR
1872
International Telegraph Convention (Rome, 1872)
EN
FR
1875
International Telegraph Convention (St. Petersburg, 1875)
FR
1906
International Radiotelegraph Convention (Berlin, 1906)
FR
1912
International Radiotelegraph Convention (London, 1912)
EN
FR
1927
International Radiotelegraph Convention (Washington, 1927)
EN
FR
1932
International Telecommunication Convention (Madrid, 1932)
EN
FR
1947
International Telecommunication Convention (Atlantic City, 1947)
EN
FR
ES
ZH
1952
International Telecommunication Convention (Buenos Aires, 1952)
EN
FR
ES
ZH
1959
International Telecommunication Convention (Geneva, 1959)
EN
FR
ES
1965
International Telecommunication Convention (Montreux, 1965)
EN
FR
ES
ZH
1973
International Telecommunication Convention (Málaga-Torremolinos, 1973)
EN
FR
ES
1982
International Telecommunication Convention (Nairobi, 1982)
EN
FR
ES
AR
ZH
RU
1992
Constitution and Convention of the International Telecommunication Union (published in Final Acts of the Additional Plenipotentiary Conference (Geneva, 1992))
EN
FR
ES
AR
ZH
RU
1994
Constitution and Convention of the International Telecommunication Union as amended by the 1994 Plenipotentiary Conference (published in Final Acts of the Plenipotentiary Conference (Kyoto, 1994))
EN
FR
ES
AR
ZH
RU
1998
Constitution and Convention of the International Telecommunication Union as amended by the 1998 Plenipotentiary Conference (published in Basic Texts, 1999)
EN
FR
ES
AR
ZH
RU
2002
Constitution and Convention of the International Telecommunication Union as amended by the 2002 Plenipotentiary Conference (published in Basic Texts, 2003)
EN
FR
ES
AR
ZH
RU
2006
Constitution and Convention of the International Telecommunication Union as amended by the 2006 Plenipotentiary Conference (published in Basic Texts, 2007)
EN
FR
ES
AR
ZH
RU
2010
Constitution and Convention of the International Telecommunication Union as amended by the 2010 Plenipotentiary Conference (published in Basic Texts, 2011) - English version includes index
EN
FR
ES
AR
ZH
RU
2014
Constitution and Convention of the International Telecommunication Union adopted by the 2014 Plenipotentiary Conference (published in Basic Texts, 2015)
EN
FR
ES
AR
ZH
RU
2018
Constitution and Convention of the International Telecommunication Union adopted by the 2018 Plenipotentiary Conference (published in Basic Texts, 2019)
EN
FR
ES
AR
ZH
RU
2022
Constitution and Convention of the International Telecommunication Union adopted by the 2022 Plenipotentiary Conference (published in Basic Texts, 2023)
EN
FR
ES
AR
ZH
RU
Follow us
Twitter
Facebook
YouTube
Flickr
Linkedin
Instagram
Soundcloud
Podcasts
Spotify
Spreaker
TikTok
© ITU
All Rights Reserved
Contact us
Terms of Use
Privacy notice
Accessibility
Report misconduct
Back to top


Information for Domain Name Registrants - 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
Information for Domain Name Registrants
This page is available in:
English
العربية
Español
Français
Pусский
中文
What is a Registrant?
A
domain name registrant
is an individual or entity who registers a
domain name
. Upon registration of a
domain name
, a
registrant
enters into a contract with a
registrar
. The contract describes the terms under which the
registrar
agrees to register and maintain the requested name. After registration,
registrants
manage their
domain name
settings through their
registrar
.
As a domain name registrant, you have certain
rights and responsibilities
. Your rights include access to information from your registrar regarding processes for registering, managing, transferring, renewing, and restoring your domain name registration.
Take Action
Click here
to use ICANN's Lookup Tool to find your registrar.
If you have suggestions, or would like to submit an inquiry, please contact ICANN's
Global Support Center
.
Contractual Compliance complaints can be submitted
here
.
Registrant Resources
The ICANN Registrant Program team has developed a number of informational series that aim to help educate registrants about their rights and responsibilities, the domain name ecosystem, how to navigate it, and the ICANN policies that impact them.
ICANN Learn
Sign up for the free ICANN Learn course:
Registrant Basics: Essentials for Domain Name Holders
What You Need to Know
Thinking About Registering a Domain Name?
Need Help With Your Domain Name?
Blog series
: Includes info on keeping your contact information up-to-date, transfer and renewal policies, and how to protect your domain name.
5 Things Every Domain Name Registrant Should Know
Frequently Asked Questions (FAQs)
Domain Name Renewals and Expiration
Registrant Contact Information and the WDRP
Transferring your domain name
About ICANN
Various FAQs
General Questions and Registering a Domain Name
Registration and Management of Domain Names
Registering domain names
Transferring domain names
Renewing domain names
Protecting domain names
Domain Name Registration Data Policies and Related Requirements
Provides information on the existing requirements and ongoing work related to domain name registration data by the ICANN community (SO/ACs).
Infographics
Thinking About Registering a Domain Name?
Need Help With Your Domain Name?
Important Tips to Help Keep Your Domain Name Secure
Arabic
Chinese
English
French
Russian
Spanish
Get Involved
ICANN Public Meetings
ICANN Policy Development
Public Comment Opportunities
Get Involved in the ICANN 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."

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


Contractual Compliance - ICANN

Contractual Compliance - 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
Contractual Compliance
Updated 15 September 2025 to improve navigation and make it easier to access information.
Latest News from Contractual Compliance
June 2026 Contractual Compliance Monthly Report
January 2026 Contractual Compliance gTLD Registry Audit Report
Notice of Bankruptcy, Convictions and Security Breaches
updated SEP 2025
January 2026 Contractual Compliance Monthly Metrics
Enforcement of DNS Abuse Obligations
Formal Enforcement Notices
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
ICANN Contractual Compliance – Functional Activities Overview
What we do:
Enforce ICANN org's agreements with Registry Operators, ICANN-Accredited Registrars and the community-developed policies incorporated into those agreements.
Enforcement activities include addressing external complaints, proactive monitoring to ensure contracted parties comply with the agreements, and conducting regularly scheduled audits.
Support ICANN's policy development processes and working groups efforts by providing input on clarity and enforceability of proposed recommendations and sharing relevant historical Compliance data and reporting.
Participate in training and outreach sessions to increase awareness and understanding of the role of ICANN Compliance in enforcing ICANN's agreements with Registry Operators and ICANN-accredited Registrars.
Produce, publish, and maintain detailed monthly metrics and reports on the enforcement activities of ICANN Contractual Compliance.
Learn More About ICANN Contractual Compliance
Information about how to submit a complaint to ICANN Contractual Compliance
.
Information about the process ICANN Contractual Compliance follows to address complaints and to enforce contractual obligations
.
Contractual Compliance Vision, Mission, Approach, and Team
Archived ICANN Contractual Compliance Reports
Archive
2024 Achive Page
2012 Archive Page
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."


Page not found | Internet Governance Forum (IGF)
Skip to main content
Welcome to the United Nations
|
Department of Economic and Social Affairs
العربية
简体中文
English
Français
Русский
Español
العربية
简体中文
English
Français
Русский
Español
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
Page not found
The requested page could not be found.
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


Government and Intergovernmental Organization Engagement
العربية
中文
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
Government and IGO Engagement
Stay up-to-date on the latest government and intergovernmental organization engagement information by subscribing to ICANN News.
Subscribe
GE Home
GE Publications
Third Party Contributions
Reports to the GAC
GAC
Internet Governance Network
Government and Intergovernmental Organization Engagement
One of ICANN’s strategic objectives is to address geopolitical issues with the potential to impact its mission to ensure a single, stable, and globally interoperable Internet through the secure operation of the Internet’s unique identifier systems. To support this objective, ICANN organization (org) monitors activity and builds alliances in the Internet ecosystem and beyond to raise awareness of our important mission and technical work.
ICANN has a dedicated Government and Intergovernmental Organization Engagement (GE) team responsible for the development and implementation of a global strategy to engage with governments and Intergovernmental Organizations (IGOs). ICANN seeks to ensure that all decision-makers understand how the Internet’s technical foundation works. This is to ensure that any actions, regulations, or laws do not disrupt the Internet’s functioning or unintentionally disadvantage users.
Governments are critical to ICANN’s multistakeholder model. ICANN works with governments within ICANN’s Governmental Advisory Committee (GAC), which is one of ICANN’s Advisory Committees. ICANN also works with governments directly and with relevant IGOs, whose roles have the potential to touch upon ICANN’s mission.
Internet Governance Network
The Internet Governance Network brings together members of the global Internet community to share information, resources, and perspectives on developments related to ICANN's remit. Learn more on our page.
Learn more on our page
.
Publications and Reports
The GE team, comprised of subject-matter experts, monitors and analyzes government and IGO activities to ensure that ICANN has the necessary information and tools to address geopolitical issues. As part of this work, the GE team publishes analytical papers, which explore relevant legislative, regulatory, and governmental structures, policies, and processes. We also make submissions to Internet ecosystem processes when appropriate, and we publish bi-monthly reports to the GAC on government and IGO engagement activities.
Access these publications, reports, and submissions below.
Government Engagement Publications
Community Contribution Opportunities
ICANN org Submissions to External Bodies
Government Engagement Public Reporting
Government Engagement Publications
Community Contribution Opportunities
ICANN org Submissions to External Bodies
Government Engagement Public Reporting
Interested in ICANN's Government Engagement Publications?
Sign up for email alerts to get notified when new reports are published.
Subscribe
GE Announcements
ICANN Seeks Input on IGO and INGO Curative Rights Implementation
ICANN Announces US$ 1 Million Contribution to Support the Internet Governance Forum
ICANN Leads Critical Discussions at 2024 Internet Governance Forum
See more announcements
GE Blogs
ICANN at WSIS Forum 2026: Advancing Global Internet Cooperation
A Permanent Internet Governance Forum: The Work Ahead
Building on Long-Standing Cooperation to Strengthen Digital Capacity in Africa
See more blogs
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


World Summit on the Information Society

World Summit on the Information Society
home
|
français
|
español
search
|
site map
|
contact
|
text only
WSIS IMPLEMENTATION BY
ACTION LINE
The
Tunis Agenda for the Information Society
states that the
WSIS
implementation mechanism at the international level
should
be organised taking into account the themes and action lines in
the Geneva Plan of Action, and moderated or facilitated by UN
agencies when appropriate. It also states that
ITU, UNESCO and UNDP
should play a leading facilitating role in the implementation of
the Geneva Plan of Action.
Meetings of
Action Line Moderators/Facilitators
Action Line
Facilitators and Focal Points
WSIS Action Lines
С1.
The role of public governance authorities and
all stakeholders in the promotion of ICTs for development
С2.
Information and communication infrastructure
C3.
Access to information and knowledge
C4.
Capacity building
C5.
Building confidence and security in the use
of ICTs
C6.
Enabling environment
C7.
ICT Applications:
E-government
E-business
E-learning
E-health
E-employment
E-environment
E-agriculture
E-science
C8.
Cultural diversity and identity, linguistic
diversity and local content
C9.
Media
C10.
Ethical dimensions of the Information
Society
C11.
International
and regional cooperation
WSIS
Stocktaking
WSIS
Golden Book
b
a
sic information
|
first
phase: Geneva
|
second phase: Tunis
|
stocktaking
|
newsroom
|
links
Top
-
Copyright © WSIS 2024
All Rights
Reserved -
Logo Policy
Privacy Notic
es
Updated : 2015-01-22


RFC 3172: Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa") | RFC Editor
Skip to content
Primary navigation
The RFC Series
For Authors
About Us
Home
RFC 3172
Info
RFC
3172
:
BCP
52
:
Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa")
G. Huston
,
Ed.
Best Current Practice
This RFC was updated
, see
RFC
9120
.
Network Working Group G. Huston, Editor
Request for Comments: 3172 IAB
BCP: 52 September 2001
Category: Best Current Practice
Management Guidelines & Operational Requirements for
the Address and Routing Parameter Area Domain ("arpa")
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 (2001). All Rights Reserved.

Abstract

This memo describes the management and operational requirements for
the address and routing parameter area ("arpa") domain. The "arpa"
domain is used to support a class of infrastructural identifier
spaces, providing a distributed database that translates elements of
a structured name space derived from a protocol family to service
names. The efficient and reliable operation of this DNS space is
essential to the integrity of operation of various services within
the Internet. The Internet Architecture Board (IAB) has the
responsibility, in cooperation with the Internet Corporation for
Assigned Names and Numbers (ICANN), to manage the "arpa" domain.
This document describes the principles used by the IAB in undertaking
this role.
1
. Introduction
The Domain Name System (DNS) [
1
] [
2
] is predominately used to
translate a structured textual identifier into a protocol-specific
value. It uses the structure embedded within a hierarchical
identifier space to create a distributed database, where every node
within the database corresponds to a node within the name structure.
The most prevalent role of the DNS is to store a set of name to
address translations, allowing a domain name to be translated to an
IP address. The DNS is also used to store a number of other
translations from hierarchically structured identifier spaces into
target values of various types.
Huston Best Current Practice [Page 1]
RFC 3172
arpa Guidelines September 2001
The DNS is also capable of supporting a translation in the opposite
direction, from protocol values to the names of service entities.
One approach in using the DNS in this fashion has been to transform
protocol values into a hierarchically structured identifier space,
and then use these transformed protocol value names as a DNS lookup
key into the appropriate DNS name hierarchy. A common use of this
mechanism has been the reverse of the name to address lookup,
allowing for an IPv4 address to be used to look up a matching domain
name. For example, the IP address 128.9.160.55 can be associated
with the domain name "www.iab.org." by creating the DNS entry
55.160.9.128.in-addr.arpa." and mapping this entry, via a DNS PTR
record, to the value "www.iab.org.".

The resolution of protocol objects into service names is used by a
number of applications to associate services with a particular
protocol object. The correct and efficient operation of these
applications is dependent on the correct and efficient operation of
the associated "arpa" domain name servers.
2
. The "arpa" domain
The "arpa" domain was originally established as part of the initial
deployment of the DNS, to provide a transition mechanism from the
Host Tables that were common in the ARPANET, as well as a home for
the IPv4 reverse mapping domain. During 2000, the abbreviation was
redesignated to "Address and Routing Parameter Area" in the hope of
reducing confusion with the earlier network name.

The Internet Architecture Board (IAB), in cooperation with the
Internet Corporation for Assigned Names and Numbers (ICANN), is
currently responsible for managing the Top Level Domain (TLD) name
"arpa". This arrangement is documented in
Appendix A
. This domain
name provides the root of the name hierarchy of the reverse mapping
of IP addresses to domain names. More generally, this domain name
undertakes a role as a limited use domain for Internet
infrastructure applications, by providing a name root for the mapping
of particular protocol values to names of service entities. This
domain name provides a name root for the mapping of protocol values
into lookup keys to retrieve operationally critical protocol
infrastructure data records or objects for the Internet.

The IAB may add other infrastructure uses to the "arpa" domain in the
future. Any such additions or changes will be in accordance with the
procedures documented in
Section 2.1
and
Section 3
of this document.
Huston Best Current Practice [Page 2]
RFC 3172
arpa Guidelines September 2001
This domain is termed an "infrastructure domain", as its role is to
support the operating infrastructure of the Internet. In particular,
the "arpa" domain is not to be used in the same manner (e.g., for
naming hosts) as other generic Top Level Domains are commonly used.

The operational administration of this domain, in accordance with the
provisions described in this document, shall be performed by the IANA
under the terms of the MoU between the IAB and ICANN concerning the
IANA [
3
].
2.1
Criteria for "arpa" Sub-domains
The "arpa" sub-domains are used for those protocol object sets
defined as part of the Internet Standards Process [
4
], and are
recommended to be managed as infrastructure protocol objects.
Normally, the recommendation is to be made in the "IANA
Considerations" section of the Internet Standard protocol
specification. The recommendation should include the manner in which
protocol objects are to be mapped into lookup keys, and
recommendations to IANA concerning the operation of the "arpa" sub-
domain in conjunction with the recommendations concerning the
operation of the protocol object registry itself.

The IESG consideration of a document which proposes the use of an
"arpa" sub-domain shall include consideration of the "IANA
Considerations" section. If the document is approved, the IESG will
ask the IAB to request the IANA to add the corresponding protocol
object sub-domain domain to the "arpa" domain, in accordance with
RFC
2860
[
3
], with administration of the sub-domain undertaken in
accordance with the provisions described in this document.
2.2
"arpa" Name Server Requirements
As this domain is part of the operationally critical infrastructure
of the Internet, the stability, integrity and efficiency of the
operation of this domain is a matter of importance for all Internet
users.

The "arpa" domain is positioned as a top level domain in order to
avoid potential operational instabilities caused by multiple DNS
lookups spanning several operational domains that would be required
to locate the servers of each of the parent names of a more deeply
nested infrastructure name. The maximal lookup set for "arpa" is a
lookup of the name servers for the "arpa" domain from a root server,
and the query agent is then provided with a list of authoritative
"arpa" name servers.
Huston Best Current Practice [Page 3]
RFC 3172
arpa Guidelines September 2001
The efficient and correct operation of the "arpa" domain is
considered to be sufficiently critical that the operational
requirements for the root servers apply to the operational
requirements of the "arpa" servers. All operational requirements
noted in
RFC 2870
[
5
] as they apply to the operational requirements
of the root servers shall apply to the operation of the "arpa"
servers. Any revision to
RFC 2870
in relation to the operation of
the root servers shall also apply to the operation of the "arpa"
servers.

Many of the servers that are authoritative for the root zone (or the
"." zone) also currently serve as authoritative for the "arpa" zone.
As noted in
RFC 2870
[
5
], this arrangement is likely to change in the
future.
3
. Delegation of "arpa" Sub-Domains
While the decision as to which protocol elements are loaded into the
"arpa" domain, and the hierarchical structure of such protocol
elements, remains within the role of the IAB, the role of managing
the sub-domain may be delegated by the IAB to an appropriate protocol
management entity.

The IAB shall only recommend the creation of "arpa" sub-domains
corresponding to protocol entities where:

- the delegation, and the hierarchical name structure, is described
by an IETF Standards Track document [
4
], and

- the use of the "arpa" domain is explicitly recommended in the
"IANA Considerations" section of that document.

The "IANA Considerations" section should include the name of the
subdomain, the rules for how the subdomain is to be administered, and
the criteria for entries within the subdomain.
4
. Current Status of "arpa"
The "arpa" domain is used for the sub-domains "in-addr.arpa" [
1
],
"ip6.arpa" [
7
] and "e164.arpa" [
8
].

Currently, the "arpa" zone is located on a subset of the root
servers, and the zone is managed in accordance with these
specifications. The IAB is working with ICANN, IANA, and the
regional registries to move "arpa" and "in-addr.arpa" records from
the root servers in accord with the
RFC 2870
recommendation for
exclusive use of those servers [
5
].
Huston Best Current Practice [Page 4]
RFC 3172
arpa Guidelines September 2001
The IPv4 reverse address domain, "in-addr.arpa" is delegated to the
IANA. The "in-addr.arpa" zone is currently located on the same same
subset of the root servers as "arpa". Sub-delegations within this
hierarchy are undertaken in accordance with the IANA's address
allocation practices.

The "ip6.arpa" IPv6 reverse address domain uses a method of
delegation that is the same as is used for "in-addr.arpa", where the
"ip6.arpa" domain is delegated to the IANA, and names within this
zone further delegated to the regional IP registries in accordance
with the delegation of IPv6 address space to those registries [
6
]
[
7
].

The "e164.arpa" domain is used to map E.164 style phone numbers into
URIs. This mechanism is defined in
RFC 2916
[
9
].
RFC 2916
notes
that the provision that names within this DNS zone are to be
delegated to parties according to ITU recommendation E.164 [
10
].
RFC
3026
[
8
] describes the overall liaison arrangements between the IETF
and ITU-T about the use of this domain.
5
. Infrastructure domains elsewhere in the DNS tree
Any infrastructure domains that are located elsewhere in the DNS tree
than as sub-domains of "arpa", for historical or other reasons,
should adhere to all of the requirements established in this document
for sub-domains of "arpa", and consideration should be given to
migrating them into "arpa" as and when appropriate.
6
. Security Considerations
The security considerations as documented in
RFC 2870
[
5
], and any
successors to that document, apply to the operation of the "arpa"
servers.

The security considerations specific to the E.164 subdomain are
documented in
Section 5 of RFC 2916
[
9
].

Any new subdomain delegation must adequately document any security
considerations specific to the information stored therein.
7
. IANA Considerations
As noted in
section 3
of this document, the IAB may request the IANA
to delegate the sub-domains of "arpa" in accordance with the "IANA
Considerations" section of an IETF Standards Track document. This
request falls under the scope of
section 4
of the MoU between the
IETF and ICANN concerning the IANA [
3
].
Huston Best Current Practice [Page 5]
RFC 3172
arpa Guidelines September 2001
Acknowledgements

This document is a document of the IAB, and the editor acknowledges
the contributions of the members of the IAB in the preparation of the
document. In addition, suggestions have been incorporated from Scott
Bradner.

References

[
1
] Mockapetris, P., "Domain names - concepts and facilities", STD
13,
RFC 1034
, November 1987.

[
2
] Mockapetris, P., "Domain names - implementation and
specification", STD 13,
RFC 1035
, November 1987.

[
3
] Carpenter, B., Baker, F. and M. Roberts, "Memorandum of
Understanding Concerning the Technical Work of the Internet
Assigned Numbers Authority",
RFC 2860
, June 2000.

[
4
] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP
9
,
RFC2026
, October 1996.

[
5
] Bush, R., Karrenberg, D., Kosters, M. and R. Plzak, "Root Name
Server Operational Requirements",
BCP 40
,
RFC 2870
, June 2000.

[
6
] Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6
Address Aggregation and Renumbering",
RFC 2874
, July 2000.

[
7
] Bush, R., "Delegation of IP6.arpa",
BCP 49
,
RFC 3152
, August
2001.

[
8
] Blane, P., "Liaison to IETF/ISOC on ENUM",
RFC 3026
, January
2001.

[
9
] Falstrom, P., "E.164 number and DNS",
RFC 2916
, September 2000.

[
10
] ITU-T Recommendation E.164/I.331 (05/97): The International
Public Telecommunication Numbering Plan. 1997.

Author's Address

Internet Architecture Board
Geoff Huston, Editor

iab@iab.org
Huston Best Current Practice [Page 6]
RFC 3172
arpa Guidelines September 2001
Appendix A

April 28, 2000

Mr. Louis Touton
Vice-President, Secretary, and General Counsel
Internet Corporation for Assigned Names and Numbers
4676 Admiralty Way, Suite 330
Marina del Rey, CA 90292

Re: Purchase Order No. 40SBNT067020:
Administration of the arpa Top Level Domain

Dear Mr. Touton:

As noted in your organization's quotation of February 2, 2000, the
arpa Top Level Domain (TLD) exists in the root zone of the domain
name system as a limited use domain currently consisting of one
record, in-addr.arpa. On April 14, 2000, the Defense Advanced
Research Projects Agency (DARPA), formerly known as the Advanced
Research Projects Agency (ARPA), officially signaled its
disassociation with the arpa domain and its understanding the domain
would be used by the Internet Corporation for Assigned Names (ICANN)
and Numbers and the Internet Architecture Board (IAB) for additional
Internet infrastructure uses.

In keeping with the DARPA understanding, we believe that the arpa
domain should be made available for this specific, limited purpose.
The Department of Commerce considers this an Internet Assigned
Numbers Authority (IANA) function and has requested that the WHOIS
entry for the arpa domain reflect IANA as the registrant.

Purchase Order No. 40SBNT067020 provides that "[ICANN] will perform
other IANA functions as needed upon request of DOC." As such, the
Department of Commerce requests that, as part of the IANA functions,
ICANN undertake administration of the arpa TLD in cooperation with
the Internet technical community under the guidance of the IAB, as a
limited use domain for Internet infrastructure applications,
including the migration of Internet infrastructure applications that
currently reside in the .int TLD. Further, as indicated by DARPA,
the arpa TLD string should be given a different expansion such as
"Address and Routing Parameter Area" to avoid any implication that
DARPA has operational responsibility for the domain.

If you have any questions, please do not hesitate to contact me.

Sincerely, Karen Rose
Purchase Order Technical Representative
Huston Best Current Practice [Page 7]
RFC 3172
arpa Guidelines September 2001
Full Copyright Statement

Copyright (C) The Internet Society (2001). 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 assigns.

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.

Huston Best Current Practice [Page 8]
RFC
3172
: Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa")
Best Current Practice
Contents
About this RFC
Errata
In this section
1. Introduction
2. The "arpa" domain
2.1 Criteria for "arpa" Sub-domains
2.2 "arpa" Name Server Requirements
3. Delegation of "arpa" Sub-Domains
4. Current Status of "arpa"
5. Infrastructure domains elsewhere in the DNS tree
6. Security Considerations
7. IANA Considerations
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


ICANN Complaints Office - ICANN

ICANN Complaints Office - 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 Complaints Office
Click Here to Submit a Complaint
Overview and Scope – ICANN Complaints Office
The Complaints Office is a function within the ICANN organization (org) that:
Provides a centralized location to submit complaints regarding ICANN org.
Receives and investigates complaints, collects facts, and reviews, analyzes, and resolves issues as openly as possible.
Helps ICANN org build on its effectiveness, and increase its transparency.
Aggregates the data from complaints to identify and solve for operational trends that should be improved.
The Complaints Office handles complaints about ICANN org that don't fall into an existing complaints mechanism, such as
Contractual Compliance
,
Request for Reconsideration
and the
Ombuds
(see
Existing Complaints Mechanisms Guidance
below). This may include complaints about how ICANN org previously handled a request, structured a process, solved an issue, or failed to account for something that may indicate a systemic issue, among other things. To learn more about the kinds of complaints the Complaints Office handles, please visit the
Complaints Office Report page
.
The Complaints Office reviews verifiable information to ensure recommendations and resolutions are based in fact. It strives to be open and transparent to all stakeholders; to be responsive and accountable to all parties; and to be constructive and actionable in its final recommendations so as to fulfill its core purpose. Above all else, the Complaints Office acts with the utmost integrity in service of ICANN's mission.
Existing Complaints Mechanisms Guidance
For complaints that fall into other existing complaints mechanisms, please visit the
Contractual Compliance
,
Request for Reconsideration
, and the
Ombuds
webpages. To submit a complaint for the most common Contractual Compliance complaint types, please refer to the following pages:
Domain Name Abuse Complaint
Domain Name Renewal/Redemption Complaint
Domain Name Transfer Complaint
Domain Name Registration Data Complaint
For other common complaint areas, please refer to
Information for Domain Name Registrants
, the
Uniform Domain-Name Dispute-Resolution Policy
, and
About ccTLD Compliance
.
Submitting a Complaint to the ICANN Complaints Office
Anyone wishing to submit a complaint related to the ICANN org may do so by completing this
web-form
. When submitting a complaint, please be sure to include all relevant information. Once a complaint is received, it will be reviewed to ensure it falls within the scope of the office, and you will be notified of next steps via email. Out of scope submissions are forwarded and responded to by ICANN's Global Support Center team whose expertise in navigating the entire ICANN org and will get the submitter the submitter with the information and/or assistance they need.
Submissions that fall within the scope of the Complaints Office will be handled in the following stages:
1. Receive, Acknowledge, and Publish
Acknowledge receipt of the complaint.
Remind submitter that the process is transparent, that the complaint will be published on the
Complaints Office Report page
with personal information redacted (as appropriate), and that the next update will arrive as per a specific, stipulated time frame.
2. Evaluate and Consider
The Complaints Officer interviews ICANN org employees with subject-matter expertise, collects, reviews and analyzes facts, researches appropriate data, and works with management to determine if improvements are warranted and if so—what can be done.
The Complaints Officer is independent and will make recommendations based on research and facts.
If there is disagreement regarding improvements between the Complaints Officer and relevant department executives, the issue is escalated to the Complaints Officer's supervisor and the ICANNCEO.
3. Response Drafting
Once a complaint is fully researched, a path forward is identified.
A path forward can be many things, for example: improvements to a process, an educational opportunity, no improvements can be implemented, among others.
The path forward is agreed upon and the Complaints Officer drafts a response to the submitter.
4. Response Issued and Published
The Complaints Officer provides the complainant with the response and the response is published on the
Complaints Office Report Page
.
Resources about the Complaints Office
Complaints Report
Complaints Office Semi-Annual Report for 1 January – 30 June 2018
Complaints Office Semi-Annual Report for 15 March 2017 – 31 December 2017
Frequently Asked Questions
[PDF, 296 KB] (18 May 2017)
العربية
[PDF, 368 KB]
Español
[PDF, 41 KB]
Français
[PDF, 42 KB]
Português
[PDF, 43 KB]
Pусский
[PDF, 196 KB]
中文
[PDF, 135 KB]
Announcements, Blogs, and More
[Announcement] ICANN Publishes First Complaints Office Semi-Annual Report
(7 March 2018)
[ICANN60 Session] A Conversation with the ICANN Complaints Officer
(30 October 2017)
[Webinar - APAC] A Conversation With The ICANN Complaints Officer
(22 August 2017)
[Blog] Publishing Submissions to the Complaints Office
(24 June 2017)
[Blog] Clarifying the Roles of the ICANN Complaints Office and Ombudsman
(18 May 2017)
[Blog] Complaints Office Update: Objectives & Next Steps
(27 April 2017)
[Announcement] Krista Papac Named as ICANN Complaints Officer
(10 Mar 2017)
Terms and Conditions for Submission to the Complaints Office
Submitted complaints will be handled in accordance with the
ICANN Bylaws
and the
ICANN Privacy Policy
. By submitting this
web-form
you acknowledge that the complaints process shall operate to the maximum extent feasible in an open and transparent manner, and shall be consistent with procedures designed to ensure fairness. Except as noted above, information you submit is subject to being published on the
ICANN website
.
By submitting my personal data, I agree that my personal data will be processed in accordance with the ICANN Privacy Policy, and agree to abide by the website Terms of Service.
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."