Accountability Mechanisms - ICANN

Accountability Mechanisms - 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
Accountability Mechanisms
This page is available in:
English
العربية
Español
Français
Pусский
中文
ICANN has a proven commitment to accountability and transparency in all of its practices. ICANN considers these principles to be fundamental safeguards in ensuring that its bottom-up, multi-stakeholder model remains effective. The mechanisms through which ICANN achieves accountability and transparency are built into every level of its organization and mandate – beginning with its
Bylaws
, detailed in its
Accountability and Transparency Frameworks and Principles
(adopted by ICANN's Board in 2008) and annually reinforced in its
Strategic and Operational Plan
. In order to reinforce its transparency and accountability, ICANN has established accountability mechanisms for review of ICANN actions. While the full texts of the accountability mechanisms are set forth in Articles IV and V of the ICANN Bylaws, the following is summary and illustrative overview of these mechanisms.
Reconsideration Process
Reconsideration is a mechanism provided by
Article IV, Section 2 of the Bylaws
by which any person or entity materially affected by an action (or inaction) of ICANN may request review or reconsideration of that action by the Board.
Any person or entity may submit a request for reconsideration or review of an ICANN action or inaction ("Reconsideration Request") to the extent that the person or entity has been adversely affected by:
one or more staff actions or inactions that contradict established ICANN policy(ies); or
one or more actions or inactions of the ICANN Board that have been taken or refused to be taken without consideration of material information, except where the party submitting the request could have submitted, but did not submit, the information for the Board's consideration at the time of action or refusal to act; or
one or more actions or inactions of the ICANN Board that are taken as a result of the Board's reliance on false or inaccurate material information.
Absent a showing of these standards, the reconsideration process is not a mechanism for reconsideration of an action (or inaction) simply because the person or entity does not agree with the action (or inaction).
All Reconsideration Requests must be submitted within fifteen days after:
for requests challenging Board actions, the date on which information about the challenged Board action is first published in a resolution, unless the posting of the resolution is not accompanied by a rationale. In that instance, the request must be submitted within 15 days from the initial posting of the rationale; or
for requests challenging staff actions, the date on which the party submitting the request became aware of, or reasonably should have become aware of, the challenged staff action; or
for requests challenging either Board or staff inaction, the date on which the affected person reasonably concluded, or reasonably should have concluded, that action would not be taken in a timely manner.
Reconsideration Requests are reviewed and considered by the Board Governance Committee ("BGC"). For all Reconsideration Requests brought regarding staff action or inaction, the BGC shall be delegated the authority by the Board of Directors to make a final determination and recommendation on the matter. Board consideration of the recommendation is not required. As the BGC deems necessary, it may make recommendation to the Board for consideration and action.
The BGC shall make a final determination, or a recommendation to the Board within thirty days following its receipt of the Reconsideration Request, unless impractical. In the event that a recommendation is made to the Board by the BGC, the Board shall issue its decision on the recommendation of the BGC within sixty days of receipt of the Reconsideration Request or as soon thereafter as feasible.
ICANN has determined that the reconsideration process can properly be invoked for challenges to expert determinations rendered by panels formed by third party dispute resolution service providers in the New gTLD Program, if the claim is that the Panel failed to follow established policies or processes in reaching the expert determination, or that staff failed to follow its policies or processes in accepting that determination.
For more information about ICANN's Reconsideration Process, please visit Article IV of the Bylaws at
http://www.icann.org/en/about/governance/bylaws#IV
, or the
Reconsideration page
.
Independent Review Process ("IRP")
In addition to the Reconsideration Process, ICANN has also established a separate process for independent third-party review of Board actions (or inactions) alleged by an affected party to be inconsistent with ICANN's Articles of Incorporation or Bylaws.
See
Article IV, Section 3 of the ICANN Bylaws
.
Any person materially affected by a decision or action by the Board that he or she asserts is inconsistent with the Articles of Incorporation or Bylaws may submit a request for independent review of that decision or action. In order to be materially affected, the person must suffer injury or harm that is directly and causally connected to the Board's alleged violation of the Bylaws or the Articles of Incorporation, and not as a result of third parties acting in line with the Board's action.
An IRP request must be filed within thirty days of the posting of the minutes of the Board meeting (and the accompanying Board Briefing Materials, if available) that the requesting party contends demonstrates that ICANN violated its Bylaws or Articles of Incorporation. For IRP requests relating to a BGC determination on a Reconsideration Request, such requests must be filed within thirty days of the posting of the minutes of the BGC meeting in which the determination at issue was made.
Prior to initiating a request for independent review, the complainant is urged to enter into a period of cooperative engagement with ICANN for the purpose of resolving or narrowing the issues that are contemplated to be brought to the IRP.
See
http://www.icann.org/en/news/irp/cep-11apr13-en.pdf
.
For more information about ICANN's Independent Review Process, please visit Article IV, Section 3 of the Bylaws at
http://www.icann.org/en/about/governance/bylaws#IV
, or the
Independent Review Process page
.
Ombudsman
The ICANN Ombudsman is an independent and impartial neutral whose function is to provide an independent internal evaluation of complaints by members of the ICANN community who believe that the ICANN staff, Board or an ICANN constituent body has treated them unfairly for matters which have not otherwise become the subject of the Reconsideration Process or the Independent Review Process. The Ombudsman shall serve as an objective advocate for fairness, and shall seek to evaluate and where possible resolve complaints about unfair or inappropriate treatment by ICANN staff, the Board, or ICANN constituent bodies, clarifying the issues and using conflict resolution tools such as negotiation, facilitation, and "shuttle diplomacy" to achieve these results.
See
Article V of the ICANN Bylaws
.
The Ombudsman does not have the power to make, change or set aside a policy, administrative or Board decision, act, or omission. The Ombudsman does have the power to investigate these events, and to use Alternative Dispute Resolution technique to resolve them. The Ombudsman is authorized to make such reports to the Board as he or she deems appropriate with respect to any particular matter and its resolution or the inability to resolve it.
For more information about ICANN's Ombudsman, please visit Article V of the Bylaws at
http://www.icann.org/en/about/governance/bylaws#V
or the
Ombuds Page
.
What is the Empowered Community?
The Empowered Community is the mechanism through which ICANN's Supporting Organizations (SOs) and Advisory Committees (ACs) can organize under California law to legally enforce community powers. The community powers and rules that govern the Empowered Community are defined in the
ICANN
Articles of Incorporation
and
Bylaws
.
Who can participate in the Empowered Community?
All of ICANN's SOs, as well as the At-Large and Governmental ACs, can participate in the Empowered Community including:
Address Supporting Organization (ASO)
Country Code Name Supporting Organization (ccNSO)
Generic Name Supporting Organization (GNSO)
At-Large Advisory Committee (ALAC)
Governmental Advisory Committee (GAC)
How does the Empowered Community use their powers?
The Empowered Community has a process to raise concerns with an action or inaction made by the ICANN Board or organization. This escalation process gives SOs and ACs opportunities to discuss solutions with the ICANN Board.
For more information, click
here
for the Empowered Community webpage.
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


Key Areas of Action

Key Areas of Action
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
Key Areas of Action
Rollup Image
You are here
ITU
>
Homepage
>
ITUs Areas of Action
Share
Accessibility
Broadband
Cybersecurity
Digital Divide
Digital financial inclusion and digital currency
Emergency Telecommunications
Environment and climate change
Entrepreneurship & SMEs
Gender equality
Internet
Submarine Cable Resilience
Youth and Academia
Accessibility
Accessibility to ICTs: Achieving Equitable Communications for Everyone
15 per cent of the world’s population lives with a disability. This represents about 1 billion people globally. Information and Communication Technologies (ICTs), such as mobile phones, satellites or the Internet, are a unique infrastructure that expand access to key public services, promoting digital inclusion. Throughout the world, persons living with disabilities are already benefitting from the advantages of ICT-enabled applications.
Learn more

Artificial Intelligence
AI is expected to play a particularly important role in accelerating progress towards each one of the 17 UN Sustainable Development Goals. Within its mandate, ITU provides a neutral platform for all stakeholders to build a common understanding of the capabilities of AI technologies, facilitating trusted, safe and inclusive development of AI technologies, and equitable access to their benefits.
Learn more

Broadband
Affordable, Safe and Resilient Broadband Networks
While much progress has been made globally over the past ten years in expanding access to, and adoption of, broadband infrastructure and services, significant challenges remain in tackling digital inequalities, addressing the current widespread impacts of the COVID-19 pandemic, and in accelerating efforts towards achieving the Sustainable Development Goals (SDGs) by 2030.
Learn more
Environment and climate change
Greening the digital transition
ITU is at the forefront of enabling environmentally sustainable digital transformation, recognizing the pivotal role of digital technologies in climate action and sustainable development. Working with over 1000 public and private sector members ITU is committed to greening the digital transition while minimizing its environmental impact.
Learn more
Cybersecurity
ITU Cybersecurity Activities
A fundamental role of ITU, following the World Summit on the Information Society (WSIS) and the 2010 ITU Plenipotentiary Conference, is to build confidence and security in the use of Information and Communication Technologies (ICTs). At WSIS, Heads of States and world leaders entrusted ITU to be the Facilitator of Action Line C5, "Building confidence and security in the use of ICTs
Learn more
Digital Divide
Connect the World
Connect the World aims to mobilize human, financial and technical resources for the implementation of the connectivity targets of the World Summit on the Information Society (WSIS) and the Regional Initiatives adopted by Member States at the ITU World Telecommunication Development Conference. ITU and partners are organizing a series of regional Summits to mobilize resources and forge partnerships.
Learn more
Digital financial inclusion and digital currency
Some 1.4 billion people remain without access to financial services. Digital financial inclusion is a critical enabler for poverty reduction and inclusive growth. ITU offers platforms to study cybersecurity challenges for digital finance, the quality of service provided by mobile networks for digital finance, and innovations and regulatory challenges brought about by fintech, digital currencies, blockchain, and artificial intelligence.
Learn more
Emergency Telecommunications
Telecommunications Saves Lives
Disasters disrupt national economies, severely weaken the poor and vulnerable and are recognized as major impediments to sustainable development and reduction of poverty especially in poor countries. The impact is even worse for those living in remote and isolated areas with no access to basic information and communication facilities that are essential to providing vital alerting information.
Learn more
Entrepreneurship & SMEs
Entrepreneurship, Innovation and SME development
Small and medium enterprises (SMEs) have a key role in ensuring economic growth in a sustainable and inclusive manner. They are often the source of innovative ICT-enabled solutions that make a long-lasting impact in global, regional and national economies, and are an important source of new jobs especially for youth. SMEs make up more than 95% of all businesses worldwide, and represent a path out of poverty for many developing countries.”
Learn more
Gateways to Public Digital Learning
Building the digital foundations for public digital learning platforms
Connecting a school to the internet is only the first step. Countries also need secure, interoperable digital foundations to turn that connectivity into lasting educational value. The Gateways to Public Digital Learning Initiative, a joint effort of UNESCO, UNICEF and ITU, helps governments design and scale public digital learning platforms that are safe, open and built to last.
Learn more
Gender equality
Gender equality
and the empowerment of women and girls through ICTs
The information and communication technologies (ICTs) are tools through which gender equality and women's empowerment can be advanced, and are integral to the creation of societies in which both women and men can substantively contribute and participate.
Learn more
Internet
Internet Policy and Governance
ITU's Internet-related activities result from its role as mandated in various resolutions with regard to international public policy issues pertaining to the Internet and the management of critical Internet resources.
Learn more
Youth and Academia
Youth, Innovation and Academia
ITU's Youth Programme aims to support children and young people from developing countries and those in transition to improve their access, use and knowledge of information and communication technologies (ICTs).
Learn more

Page Content 9
Page Content 10
Page Content 6
Page Content 7
Page Content 2
Page Content 3
Page Content 4
Page Content 5
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


RFC 2826: IAB Technical Comment on the Unique DNS Root | RFC Editor
Skip to content
Primary navigation
The RFC Series
For Authors
About Us
Home
RFC 2826
Info
RFC
2826
:
IAB Technical Comment on the Unique DNS Root
Internet Architecture Board
Informational
Network Working Group Internet Architecture Board
Request for Comments: 2826 May 2000
Category: Informational
IAB Technical Comment on the Unique DNS Root
Status of this Memo

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

Copyright Notice

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

Summary

To remain a global network, the Internet requires the existence of a
globally unique public name space. The DNS name space is a
hierarchical name space derived from a single, globally unique root.
This is a technical constraint inherent in the design of the DNS.
Therefore it is not technically feasible for there to be more than
one root in the public DNS. That one root must be supported by a set
of coordinated root servers administered by a unique naming
authority.

Put simply, deploying multiple public DNS roots would raise a very
strong possibility that users of different ISPs who click on the same
link on a web page could end up at different destinations, against
the will of the web page designers.

This does not preclude private networks from operating their own
private name spaces, but if they wish to make use of names uniquely
defined for the global Internet, they have to fetch that information
from the global DNS naming hierarchy, and in particular from the
coordinated root servers of the global DNS naming hierarchy.
1
. Detailed Explanation
There are several distinct reasons why the DNS requires a single root
in order to operate properly.
1.1
. Maintenance of a Common Symbol Set
Effective communications between two parties requires two essential
preconditions:
IAB Informational [Page 1]
RFC 2826
IAB Technical Comment on the Unique DNS Root May 2000
- The existence of a common symbol set, and

- The existence of a common semantic interpretation of these
symbols.

Failure to meet the first condition implies a failure to communicate
at all, while failure to meet the second implies that the meaning of
the communication is lost.

In the case of a public communications system this condition of a
common symbol set with a common semantic interpretation must be
further strengthened to that of a unique symbol set with a unique
semantic interpretation. This condition of uniqueness allows any
party to initiate a communication that can be received and understood
by any other party. Such a condition rules out the ability to define
a symbol within some bounded context. In such a case, once the
communication moves out of the context of interpretation in which it
was defined, the meaning of the symbol becomes lost.

Within public digital communications networks such as the Internet
this requirement for a uniquely defined symbol set with a uniquely
defined meaning exists at many levels, commencing with the binary
encoding scheme, extending to packet headers and payload formats and
the protocol that an application uses to interact. In each case a
variation of the symbol set or a difference of interpretation of the
symbols being used within the interaction causes a protocol failure,
and the communication fails. The property of uniqueness allows a
symbol to be used unambiguously in any context, allowing the symbol
to be passed on, referred to, and reused, while still preserving the
meaning of the original use.

The DNS fulfills an essential role within the Internet protocol
environment, allowing network locations to be referred to using a
label other than a protocol address. As with any other such symbol
set, DNS names are designed to be globally unique, that is, for any
one DNS name at any one time there must be a single set of DNS
records uniquely describing protocol addresses, network resources and
services associated with that DNS name. All of the applications
deployed on the Internet which use the DNS assume this, and Internet
users expect such behavior from DNS names. Names are then constant
symbols, whose interpretation does not specifically require knowledge
of the context of any individual party. A DNS name can be passed
from one party to another without altering the semantic intent of the
name.

Since the DNS is hierarchically structured into domains, the
uniqueness requirement for DNS names in their entirety implies that
each of the names (sub-domains) defined within a domain has a unique
IAB Informational [Page 2]
RFC 2826
IAB Technical Comment on the Unique DNS Root May 2000
meaning (i.e., set of DNS records) within that domain. This is as
true for the root domain as for any other DNS domain. The
requirement for uniqueness within a domain further implies that there
be some mechanism to prevent name conflicts within a domain. In DNS
this is accomplished by assigning a single owner or maintainer to
every domain, including the root domain, who is responsible for
ensuring that each sub-domain of that domain has the proper records
associated with it. This is a technical requirement, not a policy
choice.
1.2
. Coordination of Updates
Both the design and implementations of the DNS protocol are heavily
based on the assumption that there is a single owner or maintainer
for every domain, and that any set of resources records associated
with a domain is modified in a single-copy serializable fashion.
That is, even assuming that a single domain could somehow be "shared"
by uncooperating parties, there is no means within the DNS protocol
by which a user or client could discover, and choose between,
conflicting definitions of a DNS name made by different parties. The
client will simply return the first set of resource records that it
finds that matches the requested domain, and assume that these are
valid. This protocol is embedded in the operating software of
hundreds of millions of computer systems, and is not easily updated
to support a shared domain scenario.

Moreover, even supposing that some other means of resolving
conflicting definitions could be provided in the future, it would
have to be based on objective rules established in advance. For
example, zone A.B could declare that naming authority Y had been
delegated all subdomains of A.B with an odd number of characters, and
that naming authority Z had been delegated authority to define
subdomains of A.B with an even number of characters. Thus, a single
set of rules would have to be agreed to prevent Y and Z from making
conflicting assignments, and with this train of actions a single
unique space has been created in any case. Even this would not allow
multiple non-cooperating authorities to assign arbitrary sub-domains
within a single domain.

It seems that a degree of cooperation and agreed technical rules are
required in order to guarantee the uniqueness of names. In the DNS,
these rules are established independently for each part of the naming
hierarchy, and the root domain is no exception. Thus, there must be
a generally agreed single set of rules for the root.
IAB Informational [Page 3]
RFC 2826
IAB Technical Comment on the Unique DNS Root May 2000
1.3
. Difficulty of Relocating the Root Zone
There is one specific technical respect in which the root zone
differs from all other DNS zones: the addresses of the name servers
for the root zone come primarily from out-of-band information. This
out-of-band information is often poorly maintained and, unlike all
other data in the DNS, the out-of-band information has no automatic
timeout mechanism. It is not uncommon for this information to be
years out of date at many sites.

Like any other zone, the root zone contains a set of "name server"
resource records listing its servers, but a resolver with no valid
addresses for the current set of root servers will never be able to
obtain these records. More insidiously, a resolver that has a mixed
set of partially valid and partially stale out-of-band configuration
information will not be able to tell which are the "real" root
servers if it gets back conflicting answers; thus, it is very
difficult to revoke the status of a malicious root server, or even to
route around a buggy root server.

In effect, every full-service resolver in the world "delegates" the
root of the public tree to the public root server(s) of its choice.

As a direct consequence, any change to the list of IP addresses that
specify the public root zone is significantly more difficult than
changing any other aspect of the DNS delegation chain. Thus,
stability of the system calls for extremely conservative and cautious
management of the public root zone: the frequency of updates to the
root zone must be kept low, and the servers for the root zone must be
closely coordinated.

These problems can be ameliorated to some extent by the DNS Security
Extensions [
DNSSEC
], but a similar out-of-band configuration problem
exists for the cryptographic signature key to the root zone, so the
root zone still requires tight coupling and coordinated management
even in the presence of DNSSEC.
2
. Conclusion
The DNS type of unique naming and name-mapping system may not be
ideal for a number of purposes for which it was never designed, such
a locating information when the user doesn't precisely know the
correct names. As the Internet continues to expand, we would expect
directory systems to evolve which can assist the user in dealing with
vague or ambiguous references. To preserve the many important
features of the DNS and its multiple record types -- including the
Internet's equivalent of telephone number portability -- we would
expect the result of directory lookups and identification of the
IAB Informational [Page 4]
RFC 2826
IAB Technical Comment on the Unique DNS Root May 2000
correct names for a particular purpose to be unique DNS names that
are then resolved normally, rather than having directory systems
"replace" the DNS.

There is no getting away from the unique root of the public DNS.
3
. Security Considerations
This memo does not introduce any new security issues, but it does
attempt to identify some of the problems inherent in a family of
recurring technically naive proposals.
4
. IANA Considerations
This memo is not intended to create any new issues for IANA.
5
. References
[
DNS-CONCEPTS
] Mockapetris, P., "Domain Names - Concepts and
Facilities", STD 13,
RFC 1034
, November 1987.

[
DNS-IMPLEMENTATION
] Mockapetris, P., "Domain Names - Implementation
and Specification", STD 13,
RFC 1035
, November
1987.

[
DNSSEC
] Eastlake, D., "Domain Name System Security
Extensions",
RFC 2535
, March 1999.
6
. Author's Address
Internet Architecture Board

EMail: iab@iab.org
IAB Informational [Page 5]
RFC 2826
IAB Technical Comment on the Unique DNS Root May 2000
7
. Full Copyright Statement
Copyright (C) The Internet Society (2000). 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.

IAB Informational [Page 6]
RFC
2826
: IAB Technical Comment on the Unique DNS Root
Informational
Contents
About this RFC
Errata
1
In this section
1. Detailed Explanation
1.1. Maintenance of a Common Symbol Set
1.2. Coordination of Updates
1.3. Difficulty of Relocating the Root Zone
2. Conclusion
3. Security Considerations
4. IANA Considerations
5. References
6. Author's Address
7. Full Copyright Statement
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

Request for Comments: 2826 May 2000

RFC publication date from document header


Library | Shaping Europe’s digital future
Skip to main content
en
Select your language
Close
bg
български
es
español
cs
čeština
da
dansk
de
Deutsch
et
eesti
el
ελληνικά
en
English
fr
français
ga
Gaeilge
hr
hrvatski
it
italiano
lv
latviešu
lt
lietuvių
hu
magyar
mt
Malti
nl
Nederlands
pl
polski
pt
português
ro
română
sk
slovenčina
sl
slovenščina
fi
suomi
sv
svenska
Search
Search
Shaping Europe’s digital future
Menu
Close
Menu
Back
Previous items
Next items
Home
Policies
Activities
News
Library
Funding
Calendar
Consultations
AI Office
Home
Library
Library
Search Options
Library
Factsheet / infographic
Policy and legislation
Report / Study
Speech
Video
Brochure
Event report
Success story
Call document
Consultation results
Toggle dropdown
From
To
Topic
Search
Search Results (3854)
Highlight
Factsheet / infographic
31 July 2026
EU support for the news media sector
Policy and legislation
20 July 2026
Guidelines on transparency obligations for providers and deployers of AI systems
Report / Study
13 July 2026
Special panel report: Child safety online protecting and empowering minors in a digital world
Factsheet / infographic
31 July 2026
Factsheet - EU support for the news media sector
The European Commission works to address structural challenges in media sectors and to promote a free, diverse and pluralistic media environment.
Report / Study
31 July 2026
Commission publishes study supporting the Review of the Digital Decade Policy Programme
The study on the review of the Digital Decade assessed the Digital Decade’s priorities, targets, indicators and governance framework, providing a basis for the Commission’s forthcoming review.
Call document
31 July 2026
Presentation materials for the call for proposals “Youth-Driven Social Media Design”
On 30 July, the Commission organised an information session for the call for proposals “Youth-Driven Social Media Design”.
Report / Study
27 July 2026
Gigabit Infrastructure Act (GIA) Key Performance Indicators agreed by Communications Committee (COCOM)
Member States’ input on these indicators will serve as an important basis for the foreseen Commission report on the GIA, planned for May 2028.
Report / Study
27 July 2026
Annual country reports on Open Internet from national regulatory authorities (2025-2026)
The Commission has published the annual country reports, from National Regulatory Authorities for telecommunications, on the implementation of the provisions on open internet.
Policy and legislation
27 July 2026
Commission publishes new guidance to support timely Cyber Resilience Act implementation
In a clear demonstration of its commitment to simplification and timely implementation, the Commission today published practical guidance to help manufacturers, developers, and businesses of all sizes meet their obligations under the Cyber Resilience Act.
Report / Study
24 July 2026
Assessment of future connectivity needs for precision farming adoption
This study explores how connectivity is shaping the adoption of precision farming technologies across Europe. It identifies the challenges and infrastructure needed to support the sector's digital transformation.
Report / Study
24 July 2026
Report on strategies to boost open source reuse
The report sets out practical strategies to overcome the barriers that still limit the sharing and reuse of open source software across the public sector.
Report / Study
23 July 2026
New report finds diverse spectrum needs of Member States and growing demand for the sub-700 MHz frequency band from other sectors
The European Commission adopted today a report on the developments in the use of the 470–694 MHz (sub-700 MHz) frequency band, in accordance with Article 7 of the Ultra High Frequency (UHF) Decision.
Success story
22 July 2026
From EU-funded robotics research to industrial innovation: the Generative Bionics success story
EU-funded robotics research is helping turn scientific excellence into industrial innovation, with Generative Bionics building on the legacy of RobotCub, CoDyCo, and An.Dy projects.
1
Page 1
2
3
...
386
Next
Shaping Europe’s digital future
This site is managed by:
Directorate-General for Communications Networks, Content and Technology
Digital EU on Mastadon
Digital EU on LinkedIn
Digital EU on Facebook
Digital EU on Youtube
Digital EU on Instagram
Digital EU on X
About us
Privacy statement
Copyright notice
About Directorate-General CONNECT
Language Policy
Accessibility statement
Follow the European Commission
Mastodon
LinkedIn
Bluesky
Facebook
Youtube
Other
Contact us
Report an IT vulnerability
Languages on our websites
Cookies
Privacy policy
Legal notice
Accessibility

31 July 2026

Month Year date pattern in document text


RFC 1207: FYI on Questions and Answers: Answers to Commonly asked 'Experienced Internet User' Questions

RFC 1207: FYI on Questions and Answers: Answers to commonly asked "experienced Internet user" questions | RFC Editor
Skip to content
Info
RFC
1207
:
FYI
7
:
FYI on Questions and Answers: Answers to commonly asked "experienced Internet user" questions
G.S. Malkin
,
A.N. Marine
,
J.K. Reynolds
Informational
Network Working Group                                          G. Malkin
Request for Comments: 1207                            FTP Software, Inc.
FYI: 7                                                         A. Marine
                                                                     SRI
                                                             J. Reynolds
                                                                     ISI
                                                           February 1991
FYI on Questions and Answers
Answers to Commonly asked "Experienced Internet User" Questions
Status of this Memo

   This FYI RFC is one of two FYI's called, "Questions and Answers"
   (Q/A), produced by the User Services Working Group of the Internet
   Engineering Task Force (IETF).  The goal is to document the most
   commonly asked questions and answers in the Internet.

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

Table of Contents
1
. Introduction..................................................
1
2
. Acknowledgements..............................................
3
3
. Questions about the Internet..................................
3
4
. Questions About Other Networks and Internets..................
3
5
. Questions About Internet Documentation........................
4
6
. Questions About the Domain Name System (DNS)..................
4
7
. Questions About Network Management............................
7
8. Questions about Serial Line Internet Protocol (SLIP) and
      Point-to-Point Protocol (PPP) Implementations.................
9
9
. Questions About Routing.......................................
11
10
. Other Protocol and Standards Implementation Questions........
11
11
. Suggested Reading............................................
12
12
. References...................................................
13
13
. Security Considerations......................................
14
14
. Authors' Addresses...........................................
15
1
. Introduction
During the last few months, several people have monitored various
   major mailing lists and have extracted questions that are important
   or commonly asked.  This FYI RFC is one of two in a series of FYI's
   which present the questions and their answers.  The first FYI, FYI 4,
   presented questions new Internet users commonly ask and their
   answers.
User Services Working Group                                     [Page 1]
RFC 1207
FYI Q/A - for Experienced Internet Users   February 1991
The goal of this FYI is to codify the Internet lore so that network
   operations staff, especially for networks just joining the Internet,
   will have an accurate and up to date set of references from which to
   work.  Also, redundancies are moved away from the electronic mailing
   lists so that the lists' subscribers do not have to read the same
   queries and answers over and over again.

   Although the questions and their responses are taken from various
   mailing lists, they are presented here loosely grouped by related
   topic for ease of reading.  First the question is presented, then the
   answer (or answers) as it appeared on the mailing list.

   Sometimes the answers are abridged for better use of space.  If a
   question was not answered on the mailing list, the editors provide an
   answer.  These answers are not distinguished from the answers found
   on the lists.  Sometimes, in order to be as complete as possible, the
   editors provide additional information that was not present in the
   original answer.  If so, that information falls under the heading
   "Additional Information".

   The answers are as correct as the reviewers can make them.  However,
   much of this information changes with time.  As the FYI is updated,
   temporal errors will be corrected.

   Many of the questions are in first person, and the answers were
   directed to the originator of the question.  These phrasings have not
   been changed except where necessary for clarity.  References to the
   correspondents' names have been removed.

   The Q/A mailing lists are maintained by Gary Malkin at FTP.COM.  They
   are used by a subgroup of the User Services Working Group to discuss
   the Q/A FYIs.  They include:

   quail@ftp.com           This is a discussion mailing list.  Its
                           primary use is for pre-release review of
                           the Q/A FYIs.

   quail-request@ftp.com   This is how you join the quail mailing list.

   quail-box@ftp.com       This is where the questions and answers
                           will be forwarded-and-stored.  It is
                           not necessary to be on the quail mailing
                           list to forward to the quail-box.
User Services Working Group                                     [Page 2]
RFC 1207
FYI Q/A - for Experienced Internet Users   February 1991
2
. Acknowledgments
The following people deserve thanks for their help and contributions
   to this FYI Q/A: Jim Conklin (EDUCOM), John C. Klensin (MIT),
   Professor Kynikos (Special Consultant), Jon Postel (ISI),
   Marshall Rose (PSI, Inc.), David Sitman (Tel Aviv University),
   Patricia Smith (Merit), Gene Spafford (Purdue), and
   James Van Bokkelen (FTP Software, Inc.).
3
. Questions about the Internet
3.1. How do I get statistics regarding the traffic on NSFNET?

      Merit/NSFNET Information Services maintains a variety of
      statistical data at 'nis.nsf.net' (35.1.1.48) in the 'stats'
      directory.  Information includes packet counts by NSS and byte
      counts for type of use (ftp, smtp, telnet, etc.).  Filenames are
      of the form 'NSFyy-mm.type'.

      Files are available for anonymous ftp; use 'guest' as the
      password.

      The data in these files represent only traffic which traverses the
      highest level of the NSFNET, not traffic within a campus or
      regional network.  Send questions/comments to nsfnet-
      info@merit.edu.
4
. Questions About Other Networks and Internets
4.1. We have a user who would like to access a machine on
        "EARN/BITNET".  I can't find anything on this in the domain
        name tables.  Please, what is this, and how do I connect to it?

      There are several machines on the Internet that act as gateways
      between the Internet and BITNET.  Two examples are UICVM.UIC.EDU
      and CUNYVM.CUNY.EDU.  You can address a mail message to
      user%nodename.bitnet@uicvm.uic.edu where the message will be
      passed from the Internet to BITNET.

      Additional Information:

         These same gateways, known as INTERBIT on the BITNET/EARN side,
         transfer mail from computers on that network which support SMTP
         mail headers, onto the Internet.  (Many BITNET/EARN computers
         still do not support SMTP, which is not a part of the IBM
         protocol used, and it is not possible to send mail from those
         computers across the gateways into the Internet, in general.)
User Services Working Group                                     [Page 3]
RFC 1207
FYI Q/A - for Experienced Internet Users   February 1991
BITNET and EARN are the two largest of several cooperating
         networks which use the IBM RSCS/NJE protocol suite, but are not
         limited to IBM systems.  These independently administered,
         interconnected networks function as a single, worldwide network
         directly connecting more than 3,300 computers in about 1,400,
         mostly higher-education, organizations worldwide.  This
         worldwide network supports electronic mail, including mailing
         lists, sender-initiated file transfer, and short "interactive"
         messages.

         BITNET, frequently used (outside of Europe) to refer to the
         whole worldwide network, technically refers to that portion in
         the United States, plus sites in other countries which are
         connected through the United States and do not have their own
         separately administered cooperating networks.  More than 550
         organizations in the U.S.  participate in BITNET.

         EARN is the European Academic Research Network.  EARN links
         more than 500 institutions in Europe and several surrounding
         countries.

         BITNET and CSNET merged organizationally on October 1, 1990, to
         form CREN, the Corporation for Research and Educational
         Networking.  The two networks remain separate at the
         operational level level, however.  (EARN and the other
         Cooperating Networks were not involved in this merger.)
5
. Questions About Internet Documentation
5.1. Where do I get information regarding ordering documents
        related to GOSIP?

      The complete information as issued by NIST is available online on
      the NIC.DDN.MIL host as PROTOCOLS:GOSIP-ORDER-INFO.TXT.  The file
      contains pointers to contact people, ordering addresses, prices,
      and, in some cases, online pathnames, for various GOSIP related
      documents.  In addition, the information as of August 1990 was
      published as an appendix to
RFC 1169
, "Explaining the Role of
      GOSIP" [
1
].
6
. Questions About Domain Name System (DNS)
6.1. Is there a DNS Query server?

      Actually, what you are looking for is the service that host
      128.218.1.109 provides on port 5555 - you simply connect to that
      host at that port, type in a fully qualified domain name and it
      responds with an internet address and closes the connection.  I
User Services Working Group                                     [Page 4]
RFC 1207
FYI Q/A - for Experienced Internet Users   February 1991
used it when I had a host that still only had /etc/hosts and it
      did just what I needed - which was basically a manual nslookup.

      However, the vast majority of users will find it simpler to just
      use a DNS query tool and ask the DNS directly.  This doesn't
      require much sophistication, and does allow the user to see how
      short names are expanded at the user's site rather than at
      128.218.1.109 (wherever that is).  For example, suppose a user
      wants to find out the address of a fully-qualified domain name
      "X.MISKATONIC.EDU", and also see what host and address are used
      when "Z" is typed as a host name.

      Assuming the user is on a UNIX host and has a copy of the dig
      program, type:

         dig x.miskatonic.edu
      and
         dig z

         and the answers will appear.  You are now on your way to
         becoming a DNS expert.  There are other UNIX alternatives,
         e.g., nslookup, and similar programs for non-UNIX systems.
         Your local DNS guru certainly has one or more of these tools,
         and although they are often kept from the public, they are
         really quite easy to use for simple cases.

   6.2. We have been having a frequent BIND failure on both our VAX
        and Solbourne that is traced to TCP domain queries from an
        IBM NSMAIN nameserver running in cache mode (UDP queries do
        not cause this problem, though it is usually a UDP
        resolution that is active upon the crash -- this resolution
        is an innocent victim).

        I have discovered that something is trashing the hash areas
        (sometimes even as it is being recursively used in a
        resolution).  Also, occasionally the socket/file descriptor
        for the TCP connection is changed to invalid entries causing
        a reply write fail (though this is not necessarily fatal,
        and the rest of the structure is not apparently altered).

        Has any one else had frequent BIND failures (especially
        major domain sites that have heavy TCP domain loads)?

      In both the case of BIND and the IBM implementation, often called
      FAL, there are multiple versions, with older versions being truly
      bad.  Upgrade to recent version before exploring further.

      BIND has always had a problem with polluting its own database.
User Services Working Group                                     [Page 5]
RFC 1207
FYI Q/A - for Experienced Internet Users   February 1991
These problems have been related to TCP connections, NS RRs with
      small TTLs, and several other causes.  Experience suggests that
      the style of bug fixing has often been that of reducing the
      problem by 90% rather than eliminating it.

      IBM's support for the DNS (outside of UNIX systems) is interesting
      in its techniques, encouraging in its improvement, but still
      somewhat depressing when compared to most other DNS software.  IBM
      also uses terminology that varies somewhat from the usual DNS
      usage and preserves some archaic syntax, e.g., "..".

      The combination of an old BIND and an old IBM server is just plain
      unpleasant.

   6.3. Is the model used by the domain name system for host names
        that the owner of a name gets to choose its case?

      The model used by the DNS is that you get to control at a specific
      point in the name space, and are hence free to select case as you
      choose, until points where you in turn give away control.  As a
      practical matter, there are several implementations that don't do
      the right thing.  IBM implementations often map everything into a
      single case.

   6.4. According to
RFC 1034
[
2
], section 4.2.1, one should not have
        to code glue RR's for name server's names unless they are below
        the cut.  When I don't put glue RR's in, and do a query for
        NS records, the "additional" field is left blank.  As far as I
        can tell, all other zones I query for NS records have this
        filled with the IP addresses of the NS hosts.  Is this required
        or should I not be concerned that the additional field is empty?

      The protocol says that an empty additional field is not a problem
      when the name server's name is not "below" the cut.

      In practice, putting in the glue where it is not required can
      cause problems if the servers named in the glue are used for
      several zones.  This is broken behavior in BIND.  Not putting in
      glue can cause other problems in BIND, usually when the server
      name is difficult to resolve.  So, the bottom line is to put glue
      in only when required, and don't use aliases or anything else
      tricky when it comes to identifying name servers.
User Services Working Group                                     [Page 6]
RFC 1207
FYI Q/A - for Experienced Internet Users   February 1991
7
. Questions About Network Management Implementations
7.1. In reading the SNMP RFCs [
3
,
4
,
5
,
6
] I find mention of
        authentication of PDUs.  Are there any standards for
        authentication mechanisms?

      There is a working group of the IETF that is working on this
      problem.  They are close to a solution, but nothing has yet
      reached RFC publication yet.  Expect something solid and
      implementable by October of 1991.

   7.2. Can vendors make their enterprise-specific variables available
        to users through a standard distribution mechanism?

      Yes.  But before someone submits a MIB, they should check it out
      themselves.

      On uu.psi.com in pilot/snmp-wg/, there are two files

              mosy-sparc-4.0.3.c

              mosy-sun3-3.5

      The first will run on a Sun-Sparc, the second will run on a Sun-3.
      After retrieving one of these files in BINARY mode via anonymous FTP,
      the submittor can run their MIB through it, e.g.,

              % mosy mymib.my

      Once your MIB passes, send it to:

              mib-checker@isi.edu

      If everything is OK, the mib-checker will arrange to have it
      installed in the /share/ftp/mib directory on venera.isi.edu.

      Note: This processing does not offer an official endorsement.  The
      documents submitted must not be marked proprietary, confidential,
      or the like.

   7.3. I have a question regarding those pesky octet strings again.
        I use the variable-type field of the Response pdu to determine
        how the result should be displayed to the user.  For example,
        I convert NetworkAddresses to their dotted decimal format
        ("132.243.50.4").  I convert Object Identifiers into strings
        ("1.3.6.1.2....").

        I would LIKE to just print Octet Strings as strings.  But,
User Services Working Group                                     [Page 7]
RFC 1207
FYI Q/A - for Experienced Internet Users   February 1991
this causes a problem in such cases as atPhysAddress in
        which the Octet string contains the 6 byte address instead
        of a printable ASCII string.  In this case, I would want to
        display the 6 bytes instead of just trying to print the
        string.

        MY QUESTION IS: Does anyone have a suggestion as to how I
        can determine whether I can just print the string or whether
        I should display the octet bytes.  * Remember: I want to
        support enterprise specific variables too.

      In general, there is no way that you can tell what is inside an
      OCTET STRING without knowing something about the object that the
      OCTET STRING comes from.  In MIB-II [
6
], some objects are marked
      as DisplayString which has the syntax of OCTET STRING but is
      restricted to characters from the NVT ASCII character set (see the
      TELNET Specification,
RFC 854
[
7
], for further information).
      These objects are:

         sysDescr
         sysContact
         sysName
         sysLocation
         ifDescr

      If you want to be able to arbitrarily decide how to display the
      strings, without knowing anything about the object, then you can
      scan the octets, looking for any octet which is not printable
      ASCII.  If you find at least one, you can print the entire string,
      octet by octet, in "%02x:" notation.  If all of the octets are
      printable ASCII, then you can just printf the string.

   7.4. If archived MIBs must be 1155-compatible [
3
], it would be nice
        if those who submit them check them first.  Where are these
        MIB tools available for public FTP?  Ideally, a simple
        syntax checker (that didn't actually generate code) would be
        nice.

      In the ISODE 6.0 release there is a tool called MOSY which
      recognizes the 1155 syntax and produces a flat ASCII file.  If you
      can run it through MOSY without problems then you are OK.

   7.5. Suppose I want to create a private MIB object for causing
        some action to happen, say, do a reset.  Should the syntax
        or this object specify a value such as:
User Services Working Group                                     [Page 8]
RFC 1207
FYI Q/A - for Experienced Internet Users   February 1991
Syntax:
            INTEGER {
               perform reset (1),
            }

        even though there is only a single value?  Or, is it ok to
        just allow a Set on this object with any value to perform
        the desired action?  If the later, how is this specified?

      For our SNMP manageable gizmos and doohickies with similar
      "action" type MIB variables, I've defined two values

            Syntax:
               INTEGER {
                  reset(1)
                  not-reset(2)
               }

      And defined behavior so that the only valid value that the
      variable may be set to is "reset" (which is returned in the get
      response PDU) and at all other times a get/getnext will respond
      with "not-reset".
8
. Questions about Serial Line Internet Protocol (SLIP) and
Point-to-Point Protocol (PPP) Implementations
8.1. I seem to recall hearing that SLIP [
8
] will only run on
        synchronous serial lines.  Is this true?  ... is there
        something about SLIP which precludes it's being implemented
        over async lines?

      Other way around:  SLIP is designed for async lines and is not a
      good fit on sync lines.  PPP [
9
,
10
] works on either, and is what
      you should be implementing if you're implementing something.

   8.2. Since we are very interested in standards in this area,
        could someone tell me were I can find more information on PPP?

        Also, can this protocol be used in other fields than for the
        Internet (i.e., telecontrol, telemetering) where we see a
        profusion of proprietary incompatible and hard to maintain
        Point-to-Point Protocols?

      PPP was designed to be useful for many protocols besides just IP.
      Whether it would be useful for your particular application should
      probably be discussed with the IETF's Point-to-Point Protocol
      Working Group discussion list.  For general discussion: ietf-
      ppp@ucdavis.edu.  To subscribe: ietf-ppp-request@ucdavis.edu
User Services Working Group                                     [Page 9]
RFC 1207
FYI Q/A - for Experienced Internet Users   February 1991
The PPP specification is available as
RFC 1171
[
9
], and a PPP
      options specification is available as
RFC 1172
[
10
].

      In UnixWorld of April 1990 (Vol. VII, No. 4, Pg. 85), Howard
      Baldwin writes:

         "Point-to-Point Protocol (PPP) has just been submitted to the
         CCITT from the Internet Engineering Task Force.  It specifies a
         standard for encapsulating Internet Protocol data and other
         network layer (level three on ISO's OSI Model) protocol
         information over point-to-point links; it also provides ways to
         test and configure lines and the upper level protocols on the
         OSI Model.  The only requirement is a provision of a duplex
         circuit either dedicated or switched, that can operate in
         either an asynchronous or synchronous mode, transparent to the
         data-linklayer frame.

         "According to Michael Ballard, director of network systems for
         Telebit, PPP is a direct improvement upon Serial Line Internet
         Protocol (SLIP), which had neither error correction nor a way
         to exchange network address."

   8.3. Does anyone know if there is a way to run a SLIP program on
        a IBM computer running SCO Xenix/Unix, with a multi-port
        serial board?

      SCO TCP/IP for Xenix supports SLIP.  It works.  However, be
      warned: SCO SLIP works *only* with SCO serial drivers, so it will
      *not* work with intelligent boards that come with their own
      drivers.  If you want lots of SLIP ports, you'll need lots of dumb
      ports, perhaps with a multi-dumb-port board.

      Here's the setup -- SunOS 3.5, with the 4.3BSD TCP, IP & SLIP
      distributions installed.  Slip is running between the "ttya" ports
      of two Sun 3/60's.  "ping", "rlogin", etc., works fine, but a NFS
      mount results in "server not responding: RPC Timed Out".

      SunOS 3.5 turns the UDP checksum off, which is legal and works
      okay over interfaces such as ethernet which has link- level
      checksumming.  On the other hand, SLIP doesn't perform checksums
      thus running NFS over SLIP requires you to turn the UDP checksum
      on.  Otherwise, you'll experience erratic behavior such as the one
      described above.
User Services Working Group                                    [Page 10]
RFC 1207
FYI Q/A - for Experienced Internet Users   February 1991
Save the older kernel and try,

            % adb -k -w /vmunix /dev/kmem udpcksum?w 1

         to patch up the kernel.
9
. Questions About Routing
9.1. Some postings mentioned "maximum entropy routing".  Could
        someone please provide a pointer to on-line or off-line
        references to this topic?

      Try NYU CSD Technical Report 371: "Some Comments on Highly Dynamic
      Network Routing," by Herbert J. Bernstein, May 1988.
10
. Other Protocol and Standards Implementation Questions
10.1. Does anyone recognize ethernet type "80F3"?  I don't see it
         in
RFC 1010
, but I am seeing it on our net.

      Ethernet type 0x80F3 is used by AppleTalk for address resolution.
      You must have Macs on your network which are directly connected to
      Ethernet.  These packets are used by the Mac (generally at
      startup) to determine a valid AppleTalk node number.

      Additional Information:
RFC 1010
is obsolete.  Please consult
RFC 1060
[
11
], the current
      "Assigned Numbers" (issued March 1990), which does list "80F3":

      Ethernet          Exp. Ethernet    Description          References
      -------------     -------------   -----------           ----------
      decimal  Hex      decimal  octal
      33011   80F3        -      -     AppleTalk AARP (Kinetics)[XEROX]

   10.2. Does anyone know the significance of a high value for
         "Bad proto" in the output from netstat on Unix machines using
         ethernet?  We're seeing values in the tens of thousands out of
         a few hundred thousand packets sent/received in all.  Some
         "Bad proto" values are negative, too.  (Off the scale?)  Any
         help would be appreciated.

      This probably indicates that you are getting tens of thousands of
      broadcast packets from some host or hosts on your network.  You
      might want to buy or rent a LAN monitor, or install one of the
      public-domain packages to see what private protocol is guilty.
      "FYI on a Network Management Tool Catalog: Tools for Monitoring
      and Debugging TCP/IP Internets and Interconnected Devices" (RFC
User Services Working Group                                    [Page 11]
RFC 1207
FYI Q/A - for Experienced Internet Users   February 1991
1147, FYI 2), [
12
] contains pointers to tools that may help you
      zero in on the problem.

   10.3. Which RFC would explain the proper way to configure broadcast
         addresses when using subnets?

      Consult
RFC 1122
, "Requirements for Internet Hosts --
      Communication Layer" [
13
].

   10.4. Can anyone tell me what .TAR files exactly are?  Is it like
         ZIP or LZH for the IBM PC's?  IF so, how do I go about getting
         a compressor/decompressor for .TAR files and what computer
         does this run on?

      TAR stands for "Tape ARchive".  It is a Unix utility which takes
      files, and directories of files, and creates a single large file.
      Originally intended to back up directory trees onto tape (hence
      the name), TAR is also used to combine files for easier electronic
      file transfer.
11
. Suggested Reading
For further information about the Internet and its protocols in
   general, you may choose to obtain copies of the following works:

      Bowers, K., T. LaQuey, J. Reynolds, K. Roubicek, M. Stahl, and A.
      Yuan, "Where to Start - A Bibliography of General Internetworking
      Information",
RFC 1175
, FYI 3, CNRI, U Texas, ISI, BBN, SRI,
      Mitre, August 1990.

      Braden, R., Editor, "Requirements for Internet Hosts --
      Communication Layer",
RFC 1122
, Internet Engineering Task Force,
      October 1989.

      Braden, R., Editor, "Requirements for Internet Hosts --
      Application and Support",
RFC 1123
, Internet Engineering Task
      Force, October 1989.

      Comer, D., "Internetworking with TCP/IP: Principles, Protocols,
      and Architecture", Prentice Hall, New Jersey, 1989.

      Frey, D. and R. Adams, "!%@:: A Directory of Electronic Mail
      Addressing and Networks", O'Reilly and Associates, Newton, MA,
      August 1989.

      Krol, E., "The Hitchhikers Guide to the Internet",
RFC 1118
,
      University of Illinois Urbana, September 1989.
User Services Working Group                                    [Page 12]
RFC 1207
FYI Q/A - for Experienced Internet Users   February 1991
LaQuey, T, Editor, "Users' Directory of Computer Networks",
      Digital Press, Bedford, MA, 1990.

      Malkin, G., and A. Marine, "FYI on Questions and Answers - Answers
      to Commonly asked "New Internet User" Questions",
RFC 1206
, FYI 4,
      FTP Software, Inc., SRI, February 1991.

      Postel, J., Editor, "IAB Official Protocol Standards",
RFC 1140
,
      Internet Activities Board, May 1990.

      Quarterman, J., "Matrix: Computer Networks and Conferencing
      Systems Worldwide", Digital Press, Bedford, MA, 1989.

      Reynolds, J., and J. Postel, "Assigned Numbers",
RFC 1060
,
      USC/Information Sciences Institute, March 1990.

      Socolofsky, T., and C. Kale, "A TCP/IP Tutorial",
RFC 1180
, Spider
      Systems Limited, January 1991.

      Stevens, W., "UNIX Network Programming", ISBN 0-13-949876-1,
      Prentice Hall, Englewood Cliffs, NJ, 1990.

      Stine, R., Editor, "FYI on a Network Management Tool Catalog:
      Tools for Monitoring and Debugging TCP/IP Internets and
      Interconnected Devices"
RFC 1147
, FYI 2, Sparta, Inc., April 1990.
12
.  References
[
1
] Cerf, V., and K. Mills, "Explaining the Role of GOSIP",
RFC 1169
,
       IAB, NIST, August 1990.

   [
2
] Mockapetris, P., "Domain Names - Concepts and Facilities",
RFC
1034
, USC/Information Sciences Institute, November 1987.

   [
3
] Rose, M., and K. McCloghrie, "Structure and Identification of
       Management Information for TCP/IP-based Internets",
RFC 1155
,
       Performance Systems International, Hughes LAN Systems, May 1990.

   [
4
] McCloghrie, K., and M. Rose, "Management Information Base for
       Network Management of TCP/IP-based internets",
RFC 1156
, Hughes
       LAN Systems, Performance Systems International, May 1990.

   [
5
] Case, J., M. Fedor, M. Schoffstall, and J. Davin, "A Simple
       Network Management Protocol (SNMP)",
RFC 1157
, SNMP Research,
       Performance Systems International, Performance Systems
       International, MIT Laboratory for Computer Science, May 1990.

   [
6
] Rose, M., Editor, "Management Information Base for Network
User Services Working Group                                    [Page 13]
RFC 1207
FYI Q/A - for Experienced Internet Users   February 1991
Management of TCP/IP-based internets: MIB-II",
RFC 1158
,
       Performance Systems International, May 1990.

   [
7
] Postel, J., and J. Reynolds, "TELNET Protocol Specification",
RFC
854
, USC/Information Sciences Institute, May 1983.

   [
8
] Romkey, J., "A Nonstandard for Transmission of IP Datagrams over
       Serial Lines: SLIP",
RFC 1055
, June 1988.

   [
9
] Perkins, D., "The Point-to-Point Protocol: A Proposal for Multi-
       Protocol Transmission of Datagrams Over Point-to-Point Links",
RFC 1171
, CMU, July 1990.

  [
10
] Perkins, D., and R. Hobby, "The Point-to-Point Protocol (PPP)
       Initial Configuration Options", CMU, UC Davis, July 1990.

  [
11
] Reynolds, J., and J. Postel, "Assigned Numbers",
RFC 1060
,
       USC/Information Sciences Institute, March 1990.

  [
12
] Stine, R., Editor, "FYI on a Network Management Tool Catalog:
       Tools for Monitoring and Debugging TCP/IP Internets and
       Interconnected Devices"
RFC 1147
, FYI 2, Sparta, Inc., April
       1990.

  [
13
] Braden, R., Editor, "Requirements for Internet Hosts --
       Communication Layer",
RFC 1122
, Internet Engineering Task Force,
       October 1989.
13
. Security Considerations
Security issues are not discussed in this memo.
User Services Working Group                                    [Page 14]
RFC 1207
FYI Q/A - for Experienced Internet Users   February 1991
14
. Authors' Addresses
Gary Scott Malkin
   FTP Software, Inc.
   26 Princess Street
   Wakefield, MA 01880

   Phone:  (617) 246-0900
   EMail:  gmalkin@ftp.com

   April N. Marine
   SRI International
   Network Information Systems Center
   333 Ravenswood Avenue, EJ294
   Menlo Park, CA 94025

   Phone:  (415) 859-5318
   EMail:  APRIL@nic.ddn.mil

   Joyce K. Reynolds
   USC/Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA  90292-6695

   Phone:  (213) 822-1511
   EMail:  jkrey@isi.edu

User Services Working Group                                    [Page 15]
RFC
1207
: FYI on Questions and Answers: Answers to commonly asked "experienced Internet user" questions
Informational


Public Comment Closed Proceedings

Public Comment Closed Proceedings
العربية
中文
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
Public Comment
Public Comment is a vital part of our multistakeholder model. It provides a mechanism for stakeholders to have their opinions and recommendations formally and publicly documented. It is an opportunity for the ICANN community to effect change and improve policies and operations.
Subscribe to Public Comment Alerts
Public Comment Home
Upcoming Proceedings
Open Proceedings
Closed Proceedings
Other Public Consultations
Public Comment Closed Proceedings
Search for Closed Public Comment proceedings and submissions by category, date, or keyword(s).
Advanced Search
Select filters and click Apply to narrow your search results or click More Search Options to search for keywords within closed Public Comment proceedings.
To view closed Public Comment proceedings published before September 2021,
click here
.
Category
Governance
Operations
Policy
Reviews
Technical
Other
Start date
End date
Apply
Clear
Closed Public Comment Proceedings
If you are searching for a closed Public Comment proceeding that was published before September 2021,
click here
.
More Search Options
Download results to .csv file
1-20 of 125 results
Proceedings
Report
Submissions
Close Date
Draft Evaluation Guide for Community Priority Evaluation (CPE)
Show description
Report
(pdf, 146.14 KB)
12
13 May 2026
Draft Guidelines for Advancing UA Adoption
Show description
Report
(pdf, 236.82 KB)
37
12 May 2026
Proposed Root KSK Algorithm Rollover
Show description
Report
(pdf, 157.3 KB)
11
4 May 2026
Standard Bylaws Amendment – Transition Article on Specific Reviews
Show description
Report
(pdf, 83.08 KB)
13
20 Apr 2026
Fundamental Bylaws Amendments on IANA-Related Reviews and CSC Charter Update
Show description
Report
(pdf, 137.71 KB)
9
13 Apr 2026
Name Collision Procedure Documentation
Show description
Report
(pdf, 191.61 KB)
4
9 Apr 2026
ICANN FY27–31 Operating & Financial Plan, ICANN/IANA FY27 Op Plans & Budgets
Show description
Report
(pdf, 803.83 KB)
8
2 Apr 2026
Draft PTI FY27 Operating Plan and Budget
Show description
Report
(pdf, 189.02 KB)
3
2 Apr 2026
Name Collision IPv6 Research Study
Show description
Report
(pdf, 147.3 KB)
12
16 Mar 2026
Latin Script Diacritics PDP Initial Report
Show description
Report
(pdf, 287.87 KB)
15
9 Mar 2026
ICANN Office of Ombuds Framework and Process
Show description
Report
(pdf, 156.88 KB)
11
24 Feb 2026
Proposed Updates to the Trademark Clearinghouse Requirements
Show description
Report
(pdf, 349.26 KB)
4
17 Feb 2026
Proposed Next Round Base gTLD Registry Agreement - Spec 14 (Variant TLDs)
Show description
Report
(pdf, 132.61 KB)
5
12 Feb 2026
Proposed GNSO Process for ICANN Board to Reverse Adoption of GNSO Policy Recs
Show description
Report
(pdf, 151.35 KB)
11
11 Feb 2026
String Similarity Evaluation Guidelines for New gTLD Program: 2026 Round
Show description
Report
(pdf, 200.87 KB)
6
5 Feb 2026
Registration Data Request Service (RDRS) Policy Alignment Analysis
Show description
Report
(pdf, 244.34 KB)
13
20 Jan 2026
Timeline for Urgent Requests for Lawful Disclosure of Nonpublic Registration Data
Show description
Report
(pdf, 114.37 KB)
12
14 Jan 2026
ICANN Public Meeting Proposed Dates for 2029–2033
Show description
Report
(pdf, 52.61 KB)
8
22 Dec 2025
Proposed Next Round Base gTLD Registry Agreement - Public Comment 2 of 2
Show description
Report
(pdf, 240.97 KB)
18
22 Dec 2025
Updated GNSO Stakeholder Group and Constituency Charter Amendment Process
Show description
Report
(pdf, 50 KB)
4
19 Dec 2025
Previous
1
2
3
4
5
6
7
Next
Previous
1
2
3
...
7
Next
Connect with us
X
Instagram
Facebook
Youtube
LinkedIn
Flickr
Soundcloud
Explore Our Social Media Hub and Follow Us on ICANN's Official Accounts
Who We Are
ICANN For Beginners
ICANN Learn
Participate
Groups
Board Members
CEO Corner
Staff
Careers
Public Responsibility
Contact Us
Locations
Report Security Issues
Certificate Authority
Registry Liaison
Ombuds
Complaints Office
Media Resources
Accountability and Transparency
Accountability Mechanisms
Document Disclosure
Independent Review Process
Requests for Reconsideration
Empowered Community
Employee Anonymous Hotline Policy and Procedures
Governance
Governance Documents
Agreements
Organizational Reviews
Specific Reviews
Annual Report
Financials
Planning
RFPs
Litigation
Correspondence
Help
I Need Help
Dispute Resolution
Domain Name Dispute Resolution
Name Collision
ICANN Lookup
Registration Data Request Service (RDRS)
Data Protection
Data Privacy Practices
Privacy Policy
Terms of Service
Cookies Policy
© Internet Corporation for Assigned Names and Numbers
Privacy Policy
Terms of Service
Cookies Policy
Privacy Policy
Terms of Service
Cookies Policy


CEO Corner

CEO Corner
العربية
中文
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
CEO Corner
Gain insight into the work ICANN does and stay up to date on the organization’s latest achievements with this collection of reports, blogs, and Organizational Objectives.
Subscribe
CEO Corner Home
CEO Reports to the Board
CEO’s Latest Blogs
Board Activities and Meetings
CEO Corner
Kurt Erik “Kurtis” Lindqvist is the ICANN President and Chief Executive Officer (CEO), and he regularly communicates the organization’s milestones, activities, and progress toward established goals and objectives. In this collection of reports, blogs, and Organizational Objectives, readers can learn more about ICANN and stay up to date on its latest initiatives from the perspective of the organization’s leader.
Get a high-level and comprehensive look at how the organization works by viewing the Organizational Objectives and the CEO’s regular Reports to the Board and blogs. Check back often to stay informed about the latest from ICANN.
Organizational Objectives and CEO Reports to the Board
One of the most important aspects of any organization’s operations is setting goals. By clearly defining what it hopes to achieve, an organization can stay focused and on track.
Each year, the ICANN CEO works with the ICANN Board and the org’s Executive team to set goals for the organization. These goals are developed with the needs of the organization and the challenges the ICANN ecosystem faces in mind, and they help guide the org as it continues its work. Once the goals are set, the CEO regularly reports back to the Board on the org’s progress, allowing for course corrections when necessary and the celebrating of successes along the way.
Learn more about how ICANN org is working to meet its mission by reviewing the Organizational Objectives and CEO Reports to the Board.
Organizational Objectives
View the newest objectives for a comprehensive overview of current activities and initiatives.
READ MORE
Latest CEO Report to the Board
View the latest report for insight into the challenges and opportunities facing ICANN as well as the progress made.
READ MORE
All CEO Reports to the Board
Browse the library of past reports to understand how the organization has adapted over time to meet changing needs.
READ MORE
Organizational Objectives
View the newest objectives for a comprehensive overview of current activities and initiatives.
READ MORE
Latest CEO Report to the Board
View the latest report for insight into the challenges and opportunities facing ICANN as well as the progress made.
READ MORE
All CEO Reports to the Board
Browse the library of past reports to understand how the organization has adapted over time to meet changing needs.
READ MORE
CEO’s Latest Blogs
gTLD Integrations with Alternative Naming Systems Technical Study Group Underway
By
Kurtis Lindqvist
9 June 2026
ICANN FY27 Organizational Objectives Align Efforts on Priority Issues
By
Kurtis Lindqvist
3 June 2026
A Look Back at ICANN85
By
Kurtis Lindqvist
26 March 2026
More Blogs from the CEO
Kurtis Lindqvist
President and Chief Executive Officer
Read biography
Kurtis Lindqvist
President and Chief Executive Officer
Kurt Erik “Kurtis” Lindqvist is a seasoned technology executive and business leader who became President and Chief Executive Officer (CEO) of the Internet Corporation for Assigned Names and Numbers (ICANN) on 9 December 2024. With more than 30 years of experience in engineering and business development of Internet service providers, Internet Exchange Points, and global network carriers, Lindqvist has dedicated his career to advancing the stability, security, and accessibility of the Internet.
Prior to joining ICANN, Lindqvist served as CEO of the London Internet Exchange (LINX), a leading operator of worldwide interconnection services, from 2019 to 2024. Prior to this, he was CEO of Netnod from 2002 to 2015. Lindqvist also chaired the European Internet Exchange Association (Euro-IX) from 2003 to 2020, which underscores his long-standing leadership in Internet infrastructure organizations.
Lindqvist has been a leading voice in Internet governance (IG) and technical development. He served on the Internet Architecture Board (IAB) and led working groups within the Internet Engineering Task Force (IETF) and RIPE, where his efforts helped shape critical Internet standards and policies. Additionally, he has advised the Swedish government on IG, broadband policy, and other key areas, fostering collaboration between public and private sectors.
Lindqvist studied Computer Science at Uppsala University, Sweden, and holds an Executive MBA from the International Institute for Management Development (IMD) in Lausanne, Switzerland.
Kurtis Lindqvist
President and Chief Executive Officer
Read biography
Kurtis Lindqvist
President and Chief Executive Officer
Kurt Erik “Kurtis” Lindqvist is a seasoned technology executive and business leader who became President and Chief Executive Officer (CEO) of the Internet Corporation for Assigned Names and Numbers (ICANN) on 9 December 2024. With more than 30 years of experience in engineering and business development of Internet service providers, Internet Exchange Points, and global network carriers, Lindqvist has dedicated his career to advancing the stability, security, and accessibility of the Internet.
Prior to joining ICANN, Lindqvist served as CEO of the London Internet Exchange (LINX), a leading operator of worldwide interconnection services, from 2019 to 2024. Prior to this, he was CEO of Netnod from 2002 to 2015. Lindqvist also chaired the European Internet Exchange Association (Euro-IX) from 2003 to 2020, which underscores his long-standing leadership in Internet infrastructure organizations.
Lindqvist has been a leading voice in Internet governance (IG) and technical development. He served on the Internet Architecture Board (IAB) and led working groups within the Internet Engineering Task Force (IETF) and RIPE, where his efforts helped shape critical Internet standards and policies. Additionally, he has advised the Swedish government on IG, broadband policy, and other key areas, fostering collaboration between public and private sectors.
Lindqvist studied Computer Science at Uppsala University, Sweden, and holds an Executive MBA from the International Institute for Management Development (IMD) in Lausanne, Switzerland.
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