.tel and ICANN

Status Report on the sTLD Application Process

TEL (PULVER)

The applicant and registry operator for this TEL sTLD application is NetNumber, Inc, a
company doing business in Massachusetts (“Netnumber”). The Sponsoring Organization
(SO) is Pulver.com, a company doing business in New York (“Pulver”). For purposes of
this report, both entities shall be referred to as “Pulver.”

Each of the three evaluation teams described above reviewed this TEL application, and
none recommended approval. The technical evaluation team expressed concern that an
effort to “create a public ENUM-like service that is only open for registration by ‘VoIP
providers’” would “cause major problems for global ENUM deployment.” It was “also
concerned that this proposal is focused entirely on North America.” The team also noted
that “this is a new operator of an EPP registry that has not demonstrated an ability to
operate it, even though the description in the application suggests that it has the chance of
being a success. Nonetheless, there is a high risk of technical problems when the registry
starts up, even though the registry is also (the only) registrar.”

The business/financial team found that the “methodology is not clear. The key players
are experienced, well resourced financially and qualified, and NetNumber’s existing
operation appears to be solid, but there are few details actually provided in the
application to substantiate this. Nor is there a detailed methodology that describes how
that experience and current operational success will be used to ensure the success of this
TLD.”

The sponsorship/community value team found a “lack of representative reach of the
Sponsoring Organization, poor coordination with ENUM developments in the larger
Internet community, and questions about whether the application defined a community
which can add value to the Internet name space.”

On 31 July 2004, ICANN notified Pulver of the evaluators’ recommendations (see
Appendices D and E). Pulver did not respond to ICANN’s invitation to remedy, or
attempt to remedy, deficiencies in its applications.

On 30 November 2004, ICANN informed Pulver that those applicants seeking to remedy
identified deficiencies have done so, and the sTLD application process would therefore
draw to a close.

TEL (TELNIC)

The applicant and registry operator for this TEL sTLD application is Telnic Limited, a
company in the United Kingdom (“Telnic”). The Sponsoring Organization (SO) it plans
to form is Telname Limited. The registry operator selected CORE Internet Council of
Registrars (CORE) to provide registry services.

Each of the three evaluation teams described above reviewed the TEL application, and
none recommended approval. The technical evaluation team did not recommend the TEL
application for approval because (1) “the description of how the domain operates
describes functionality which is not coherent” with the rest of the application, and could
contribute to “an increase in operational instability when the registry starts up;” (2) it is
unclear “if there will be a connection between what names are used in this domain, versus
other TLDs. I.e. should the holder of example.com get example.tel, or examplecom.tel?;”
and (3) TEL’s proposal to allow any registration but “only register non
delegation records for each name . . . may cause problems for registrars as they need to
make major changes to their systems . . . .” In addition, Telnic’s decision initially not to
identify the provider of registry services led to team to decide that there was “no way to
judge their suitability or capabilities.”

The business/financial team did not recommend approval because it found that (1) neither
“the business plan nor the responses to supplementary questions provides satisfactory
evidence of the applicant’s ability to reach the projected number of domain registrations.
Projections are based on an unconvincing argument that the number of dot-tel domains
registered will be proportional to number of users of mobile terminal devices;” (2) the
“marketing plan suggests that the applicants will spend a significant amount of money
quickly without any real focus to their efforts.” It does “not indicate where the market
focus is, for example which conferences are the most potentially beneficial and why. This
lack of focus, lack of meaningful specificity and lack of relevant partners on board to date
do not generate confidence in the applicant’s ability to execute successfully;” and (3) the
“lack of evidence of initial discussions/agreements with an RO does not establish
confidence in the applicant’s ability to garner the necessary technical resources in a
timely fashion and within the planned budget.”

The sponsorship/community value team found did not recommend approval. Its concerns
included that (1) the “application defines an enormously broad community of users,”
namely “anyone who has a phone or seeks to disseminate telecommunications routing
information about how to reach them;” and (2) despite “laudably transparent operating
procedures, the policy making and operational authority is exclusively vested in the
original financial investors of this venture with no mechanisms to grow toward broader
community support,” with “no obligation to include representation from any portion of
the community to be served by the sTLD.”

On 31 July 2004, ICANN notified Telnic that it had not been recommended by any of the
evaluation teams (see Appendices D and E).

On 25 August 2004, Telnic responded to the evaluation reports. It indicated that (1) the
proposed TLD was “configured as a standard ‘delegation only’ system (i.e., Registry
holds only NS records)”; (2) it would issue an RFP for back-end services but had not in
an effort to promote a competitive process; (3) it had presented a sound business and
financial plan; (4) there was sufficient market demand; and (5) providing domains that
are “tied exclusively tied to a person’s or company’s name and used to hold contact data
for Registrant, not their machines” is appropriately an sTLD.

On 20 September 2004, Telnic notified ICANN that it had signed a Letter of Intent with
CORE to provide registry services.

On 28 October 2004, the technical team issued a statement on “Consideration of
Supplemental Information,” which took into account selection of CORE. The technical
team noted that, with respect to the nature of the delegation system, Telnic’s affirmative
answer that the proposed sTLD was to be “delegation only” was not consistent with other
information it had provided. For example, Telnic’s June 21, 2004, response to questions
from the Technical Team states both that (i) “SRV records and MX records will be
acceptable. However, the target for these records will have to be in a zone in another
TLD,” and (ii) that the sTLD will be “delegation only.” With respect to registration
restrictions, the team noted that the SO “should have a technical plan for enforcing
restrictions that ensures, for example, the registry will operate reliably” and suggested the
applicant provide “a more detailed technical description of the proposed enforcement
mechanism.” With respect to the identification of CORE, the team noted that “CORE has
demonstrated sound technical abilities to operate registries of sizes that are smaller than
Telnic proposes for .tel,” which Telnic estimates would be 5 million by the end of year 5.

On the same day, CORE, on behalf of Telnic, provided an initial response to the technical
team’s questions that described CORE’s capacity and ability to scale up or down.

On 29 October 2004, Telnic, the technical team and ICANN held a teleconference to
discuss technical issues. With respect to delegation, the team sought clarification of a
system that was not described consistently. Telnic clarified that it would “use a standard
delegation only system.” On enforcement, Telnic described how robots would
“randomly and selectively query registered domains for evidence of usage violations,”
and agreed to describe in more detail the process. Telnic also confirmed that CORE
could scale up to the estimated size of the .tel registry. After the teleconference, the
Evaluators conferred, as agreed, and posed follow-up questions about treatment of the
address records, the proximity of data centers and what domain name strings would be
prohibited.

On 2 November 2004, the applicant provided answers to the technical team’s follow-up
questions.

On November 10, 2004, the business/financial team completed its review of Telnic’s
response to the evaluation, and posed 22 supplemental questions to the applicant. The
questions were organized into five broad issues and included: (1) facilitating the sale of
.tel registrations, including eligibility and market research; (2) determining the
importance of value-added features; and (3) clarifying the relationship between an
increase in consumers’ purchase and use of dual-function (both Internet and Telephony
capable) devices and the financial success of .tel.

On 15 November 2004, Telnic responded to the technical team’s supplemental questions
(which updated an earlier response on 2 November). Telnic described the TEL registry
delegation model, and confirmed that it would act as a “delegation only” TLD. It also
described its acceptable usage, policing and enforcement model in detail. It clarified that
solely numeric domain labels will be excluded from TEL.

On 27 November 2004, the Technical Team provided its final comments and found that
the application was now “complete and sufficient from a technical standpoint,” and did
meet the technical criteria of the RFP. It indicated that (1) “information provided by
CORE showed evidence that their operation can scale to a size larger than .TEL expects
to reach in 3-5 years;” and (2) greater geographical distance between the data sites would
be optimal.

On 4 December 2004, the applicant provided responses to the business/financial team’s
question, including market surveys and analyses.

On 12 January 2005, the business/financial team concluded that its concerns had been
addressed, and that from a business/financial perspective Telnic’s application now meets
the selection criteria set forth in the RFP. It noted that Telnic’s new “information
presents a high level of specificity, and has provided the answers, details and
clarifications we were looking for. It has moved this plan for a .tel TLD from the early
stage work that characterized the original application to a more fully considered
endeavour with a comprehensive business plan. Telnic’s ability to implement its
business plan is now evident and the methodology appears to be sound. The additional
details that have been provided regarding operational capacity, marketing, fee structure
and registrar arrangements reinforce our evaluation that Telnic is likely to be able to
implement its plan.”

On 17 March 2005, the applicant provided ICANN with additional thoughts on why it
believed it met the sponsorship/community value criteria, for the Board’s consideration.
Telnic indicated that the sTLD allows people to find people, and that TEL will restrict the
“use” of the domain; “members of this community will use the DNS to organize, store
and publish their personal contact information.” It also stated that the needs of this
specific community are unique in terms of technical issues, infrastructure, restrictions,
educational needs, enforcement and privacy. It pledged that the SO would enable broad,
direct community involvement.

On 21 March 2005, the ICANN Board discussed the TEL application and directed “the
President to provide the Board with more information from the technical evaluators and
applicants regarding the technical aspects of the .TEL sTLD application” (see
http://www.icann.org/minutes/minutes-21mar05.htm ). The Board had questions about
the scaling potential of the TLD; the operation, name conflicts, and special applications;
and registrar-registry protocols and interactions.

On 3 June 2005, the technical team responded to the Board’s inquiries. The team stated
that (1) with respect to scaling, the “proposed TLD is no different than .COM . . .
[because] growth is typically linear . . . .”; (2) a “first-come, first-served approach to
registration does not seem appropriate to a TLD of this potential size,” but that issue was
within the purview of the sponsorship team; (3) there “is no known technical mechanism
whereby different users in different locations can get different responses from DNS;” (4)
it did not foresee a problem with the DNS’s caching environment, for DNS traffic is
relatively small; (5) “the TLD will ultimately succeed or fail based on the availability of
applications;” (6) it had already “expressed the view that a prefix would raise fewer
issues than a suffix,” but that “proposals for prefixes were not the ones presented to us for
evaluation;” (7) it had already noted that “there is a high risk of problems for registrars
if there is no preliminary detailed analysis of the registry-registrar relationship, including
consideration of the different technical abilities of different registrars;” and (8) despite
“initial confusion, Telnic clarified in fall 2004 that the .TEL sTLD would be ‘delegationonly,’”
which moots the question of patches in a post-SiteFinder environment.

On 28 June 2005, the Board discussed the TEL application, specifically the issues of
compliance with the technical requirements of the sTLD RFP. The Board voted to
authorize the President and General Counsel to enter into negotiations relating to
proposed commercial and technical terms for the TEL sTLD (see
http://www.icann.org/minutes/minutes-28jun05.htm ).

Annex 1: Telefonica Response

The comments from Telefonica are very surprising for a leading Internet Access and
Telephony Services Provider.
• They are based on a fundamental misunderstanding of the way in which DNS
operates.
• They constitute a serious misreading of the .tel-Telnic proposal; the comments might
be applicable to other proposals (notably .mobi and .tel-Pulver), and so the inclusion
of quotes from the Telnic proposal seem out of place.
• The latter sections of the Telefonica comments seem to attack all ICANN issued
gTLDs (and, potentially all ccTLDs) rather than being applicable only to the .telTelnic
proposal. It is unclear why these comments were made to this proposal only.
• The comments also reflect a basic confusion between storage and publication of
communications contact information and provision of communications service to
those individuals.
• Finally, it would appear that there is a lack of understanding of the addressing
mechanisms in Voice over IP systems as opposed to the operation of the PSTN.

Here below is a point by point response to the Telefonica comments. Please refer to the
original Telefonica 0000.PDF document for the individual comments. In the following,
references to .tel mean the sTLD proposed by Telnic, unless specifically mentioned
otherwise.

1.
1.1.
This section contains the ICANN Definition of Community to which we have no
comments.

1.2.
This section contains examples of communities served in ‘last round’ sTLDs.
It should be noted that registration in these sTLDs is not mandatory. For example, most
museums don’t have a registered .museum domain.

1.3/1.4.
For the .tel-Telnic proposal, the community served is those people and companies who
wish to store communications contact details in one place. The community is defined by
their use of this sTLD; the role of the sTLD is to act as the ‘well known place’ to store
and publish contact information.
1.5.
In presentations to the GSMA and the UMTS Forum, Telnic has stated that a single sTLD
to store all communications contact details is, by definition, suitable to store mobile-
specific contact details, and so fulfils one of the requirements of a mTLD originally
proposed to the UMTS Forum and GSMA.

2.
2.1.
This section contains three quotes from the .tel-Telnic proposal - to summarize:
• .tel is a text based naming structure
• .tel is a catalyst and enabler for new communications services
• New communication service and application growth is in the Internet
By implication, these new services and applications use the Internet & DNS for naming,
not just the PSTN and E.164 telephone numbers.
We have no disagreement with these points.

2.2.
This section contains an ICANN Charter extract to which we have no comments.

2.3.
Telefonica states: ‘.tel is a complete system, of which TLD is only a part’. This is only as
true as stating that Internet connected nodes run applications and exchange protocols
other than just DNS.

There are many potential applications that could use a single repository for storage and
publication of communications contact details. The .tel proposal intends to provide the
registry that supports communications contact storage and publication.

It is a strange misreading of the proposal to assume that only Telnic-supplied applications
would operate using this sTLD.

As the goal is to provide a domain space under which can be stored standard DNS
Resource Records (such as NAPTRs), any application can query and collect this data and
can process it. The sTLD acts as a single name space to enable these applications; it isn’t
these applications.

Telefonica further states that the .tel-Telnic sTLD proposal is: “...a proposal that appears
more like a search for a fraudulent alternative means of becoming a provider of
telecommunications services...”

To expect that any TLD Registry is capable of providing Telecommunications Service
when it provides only DNS support is incorrect.

If any proposal expects to get a Telecommunications License from ICANN, then it would
indeed be woefully misguided?

None of the sTLD proposals have made this basic mistake; however, Telefonica confuses
DNS with Telecommunications Service.

2.4.
Given the basic mistake of confusing a structure to allow users to publish their contact
data with the process of providing a telecommunications service for users, the seriousness
of ICANN exceeding its authority in approving a sTLD is equally mistaken.

3.
Telefonica states in its first two paragraphs of section 3:

‘The nature of the proposal and the extent of its subject-matter and of the intended
services affect, if not encroach upon, aspects which are the responsibility of established
international organizations, primarily the ITU, and of both national telecommunications
services regulators (States) and supranational regulators. Successfully implementing the
proposal would also require the consensus of the international community (regulators,
service providers, consumers ...) on key aspects of the proposal, which has categorically
not been obtained.

We are speaking about matters such as: network security and integrity, universal service
(directory of directories), operator selection, tariff rebalancing and pricing mechanisms,
policies for routing and Internet use incentivization, commercial agreements between
operators, server location and application legislation, call identification services,
emergency services, and in particular about issues relating to numbering, interconnection
and voice services over IP.’

One of the key aspects of the .tel-Telnic proposal is that any individual can register a
domain and can publish whatever contact details they choose under this domain. Given
that this contact data is chosen by the end user (rather than some third party, such as a
Service Provider), Telefonica’s comment is misplaced. One might as easily say that the
ITU controls printing of business cards or the publication of telephone contact details
shown on a web page.

It seems that again this reflects a basic misunderstanding of the difference between
publication of contact data by individuals and provision of telecommunications services
to those individuals.

3.1.
In this section, Telefonica discusses ENUM.

ENUM has involved ITU SG2 and IAB cooperation, and is designed to reflect allocation
of E.164 numbers by the Nation States. The E.164 number space is the remit exclusively
of the ITU and the Nation States that are members. We agree that is imperative that any
domain space that reflects or is mapped to the E.164 number space should involve such
co-operation.

However, as is explicitly stated in the proposal, the .tel domain does not reflect the E.164
number space. Registration of domains that are (or may be confused with) E.164 numbers
is barred.

Domains within .tel can use NAPTRs, as can any other domain within the DNS. These
NAPTRs hold communications contact information in the form of URLs, and these URLs
may include telephone numbers.

Telnic disagrees that such specific use is either barred or controlled by individual Nation
States, over and above the choice of some Countries to block access to the Internet to
their citizens.

We are unaware of any action taken against individuals publishing ‘their’ telephone
numbers on their Web pages, thus this assertion from Telefonica is unfounded.

3.2.
It appears that this section of Telefonica’s comments is addressed for other proposals, not
.tel-Telnic.

Barring registration of any domain that might be confused with an E.164 number is one
of the clarifications in this proposal added since the initial round in 2000; .tel (in the
Telnic proposal) is designed purely to complement the number based domain space
agreed for .e164.arpa.

Given this explicit statement, we do not understand the assertion that there is any conflict
with ENUM reflected in the .tel-Telnic proposal; Telefonica appears to have confused
Telnic’s proposal with another proposal.

3.3.
The relevance of the comments in this section is unclear.

Telnic has been careful to exclude the possibility of conflicting with E.164 number based
domain registrations. The .tel proposal has been designed to allow Registrants to store
contact data under a domain registration that reflects their name. It does not and cannot
reflect the E.164 number by which they are provided Telecommunications Service.

To suggest that “the ability to dial via .tel conflicts with the provisions of the National
Numbering Plans...” is to widely misunderstand existing Voice over IP systems.

It is perfectly possible for two individuals to communicate via SIP (or even H.323)
without using E.164 numbers to address the caller or callee. Indeed, it is possible for
them to communicate without the use of any third party application entity; all that is
needed is a means of transferring data between their SIP UAS. Given that Telefonica is a
provider of just such Internet access services, it is surprising that this misunderstanding
has been made.

If a registrant decides to place a SIP URI within a NAPTR stored in their .tel domain,
then this is not an E.164 number; it’s a SIP URI.

Even if the registrant decides to place a NAPTR containing a tel: URI into their domain,
this is discrete from a provision of a telecommunications service using the value of the
URL as an address.

3.4.
These comments relate only to provision of telecommunications service. As Telnic has
no intention of providing such services, and the proposal is unrelated to such provision,
these comments are irrelevant.

3.5.
Insofar as Telnic would operate a sTLD Registry, they would, of course, ensure that their
operations meet the appropriate legislation. See also next section.

3.6.
Telnic has no intention of dispensing with regulations and will comply with the rules laid
down by competent authority; in this case, ICANN (and, where appropriate, Data Privacy
legislation and WIPO rules on Trademarks, together with Financial accounting
regulations).

However, nowhere does this proposal suggest that Telnic will be providing
telecommunications service to their customers.

We believe that Communications Service Provision regulation does not cover operation
of a sTLD (i.e. the provision of DNS delegations). This is a general rather than a specific
comment on this sTLD; we do not believe that such regulation applies to any gTLD (or
ccTLD).

4.
4.1.
Given that Telnic intends to operate a sTLD, and so will perforce support standard
protocols, it is unclear exactly what this section means. We assume that communications
contact data will be stored by registrants using NAPTRs (as specified in RFC3401-
RFC3404, the successors to RFC2915).

It is not at all clear what proprietary, non-standard features Telefonica believes are being
suggested in the proposal; as such we cannot respond. We can only restate that the .tel
will be an open system to all.

4.2.
After considerable searching, Telnic is unaware of any enforceable patents on DNS
operation or NAPTR Resource Records. We are aware of the use of the terms Universal
Identifier, Communications Identifier, Personal Communications Space, and other
variants from many EU and other projects that preceded the ETSI work. We are unaware
of any trademark on these terms.

If the assertion on patents and trademarks is in earnest, we would appreciate a list of
these allegedly applicable patents and trademarks; there is considerable ‘prior art’ in the
public domain so we are surprised at this assertion.

4.3.
Telnic will, of course, comply with ICANN and other guidelines on protection of
Trademarks.
A)Telefonica is aware that their statement is a gross simplification, and that clarification
is required - see Telefonica comment 4.4, and the first sentence of the closing
paragraph of this section.
B) ICANN has a policy on labels that must not be registered such as two character
country codes. Telnic will enforce this ICANN policy fully and Telefonica’s
interpretation of the Telnic proposal is in correct in this regard.
C) Famous Names is a difficult topic; this has an impact on other TLDs, but is one to
which Telnic is sensitive; hence, the comments in the .tel-Telnic proposal address this
topic clearly.

The .tel sTLD is name-based, and we are aware that the right to register, for example, the
domain ‘Enrique.Iglesias.tel’ is not straightforward. As highlighted, regimes are being
developed in WIPO and within ICANN working groups, and the goal is for the PAG to
reflect these policies as they are developed. The PAG will develop specific policies for
the .tel sTLD, but these are intended to reflect global policies developed by competent
authorities. Intentionally to do otherwise would be absurd.

4.4.
This is a general issue for all gTLDs.

The UDRP is, of course, not a panacea, but it does exist and has been agreed upon and
used to resolve disputes. As policies are developed and agreed upon by the competent
authorities, Telnic, (in common with all other gTLD operators,) will apply these.

The suggestion that the Telnic proposal is ‘even less sufficient’ is unclear. It is difficult to
see how communications contacts chosen by a Registrant to populate Resource Records
in their domain relate to Trademarks on the domain name; this is the only difference
between this and any other gTLD.

4.5.
Scarcity is not an issue here; however, control of E.164 number spaces allocated to
National or Regional Regulatory Authorities by a United Nations organization (ITU-T)
is, undoubtedly, a national or regional issue. One could well argue that domain names
that reflect E.164 numbers are thus related to these national or regional concerns.

The .tel-Telnic proposal specifically rejects such domain names, and so is unaffected by
such concerns. It is instead a name-based sTLD.

It is difficult to imagine how names can be subject to national or international regulation,
except in relation to trademarks. As the UDRP is specifically concerned with trademark
dispute resolution, it seems eminently appropriate for this sTLD.

5.
We believe that the concerns stated in this section apply equally to all gTLD Registries,
and that the concerns expressed as specific to Telnic’s proposal arise from a
misunderstanding of the way in which the DNS system operates.

5.1.
This section appears to reflect a misunderstanding of the roles of different providers in
the DNS system.

To clarify, Telnic intends to oversee the sTLD Registry; they do not intend to operate the
Authoritative DNS servers for the domains they delegate.

The Registrants are assumed to have control over the Resource Records populated in
their domains, and so are assumed to have redress against their DNS Service Providers
for incorrect publication.

Thus the data they hold will not be Resource Records holding the contact details chosen
by registrants. Instead, the .tel Registry will hold the identities of the Registrants and the
Registrars who act for them, along with the technical information needed on the domain
names and IP addresses of the DNS servers authoritative for that domain. In short, the
kind of information held will be identical to that held by other gTLDs.

Telnic is based in the EU, and so is sensitive to the data privacy concerns of its
Registrants. As it will operate a sTLD, the kind of data it holds is the same as the data
used by any other registry, and so is subject to ICANN guidelines.

However, we understand that provision of a WHOIS (or CRISP) service is, of course,
subject to data privacy concerns. Furthermore, we are sensitive to concerns on a ‘Thin
Registry’ model, where personal information may be made available by a Registrar
operating in one legislative jurisdiction on behalf of a customer who lives in another (and
may expect different levels of control over accessibility to their personal information).
We expect to work within ICANN guidelines, and will protect Registrant’s personal
information where possible.

5.2.
It is unclear how this differs from any other gTLD.
A)Regarding .tel Registry DNS Operation centers, it is expected that, as with all other
gTLDs, the servers and databases will be placed in at least three different continents,
for performance, robustness and security reasons.
B) Telnic Limited is a UK-based company, as mentioned in the proposal. We are fully
aware of the differences in Data Privacy regulations between the EU and other
jurisdictions.
In terms of the specific case of court-ordered access or interception of
telecommunications, this would be an issue if Telnic were intending to provide
Telecommunications service; as it does not, this is irrelevant.
C) This comment seems to reflect Telefonica’s misunderstanding of DNS.
Telnic oversee the sTLD Registry Operator, and so will not operate the Authoritative
DNS servers that publish the Registrants’ Resource Records. Thus personally chosen
communications contact data would not be published by Telnic.

The only exception would be the publication of Registrant contact data inside any
required Whois or CRISP service, as would any other gTLD operator.

6.
6.1.
The goal is to have a sTLD that can be used as a ‘well known place’ to register domains
under which communications contact information can be published.

It will not hold and publish a database with the contact information for the Registrants
(other than in the limited sense of Whois/CRISP publication, in common with all
gTLDs).

Publication of the Registrants’ choice of communication contact data is done by
Authoritative DNS Service Providers selected individually by those Registrants. As such,
there is no single database holding all such contacts.

6.2.
To hold and publish a complete databases of all customer’s contact details would indeed
be a major asset. However, as this is not how DNS operates, it is not relevant.

6.3.
As already stated, Telnic has no intention of providing telecommunications service for
any of its customers. Thus it will not, directly or indirectly, manage telecommunications
traffic. Telecommunications Service is completely discrete from provision of a gTLD
Registry (i.e. providing DNS delegation service). Whilst any protocol might be misused
to carry voice packet data, using DNS for this purpose seems unimaginably perverse.

To provide a telecommunications service as well as arrange domain Registrations ‘under
which’ communications contact details were published might cause such confusion.
However, for such confusion one should look to other proposals that do involve such
Service Providers, not the .tel-Telnic one.

6.4.
Whilst Telnic has requested an sTLD with the intent that the delegated domains will be
used to publish NAPTR Resource Records holding communications contacts, it does not
have any control or influence over the supply of contacts populated in those Resource
Records.

Even for the specific case of the ENUM system, this is akin to storing a SIP URI
provided by a US-based VoIP provider inside an ENUM domain that is registered in the
UK portion of the ENUM domain space (4.4.e164.arpa.). In the case of ENUM, the
domain name is dependent on the UK ENUM regulations. However, the content of the
resource records published for that domain name are quite separate.

Thus, the suggestion that control of the supply of domain names somehow controls the
contacts that are published in those domains misapprehends the operation of DNS and the
.tel sTLD.

In conclusion, we would ask Telefonica to reconsider their comments in the light of these
clarifications.

We sincerely believe that these comments arose due to a misunderstanding of certain
aspects of the .tel-Telnic proposal, and trust that with these clarifications Telefonica now
understands the benefits of this proposal for end users and will no longer oppose it.

Telnic Management

Annex 2: Boston Response

Thank you for your questions. These are subtle points, so are addressed in turn.

1) Restricted use for Telname sTLD?

Yes - Telnic believes that there is a business case for a Telname (name-based)
mechanism to store contacts in DNS. We believe that in this case the behaviour of the
Telname system will be different from that of a ‘normal’ gTLD.

The performance requirements for resolving personal contacts can be different from
‘finding’ a machine IP address, and an individual may not have a machine ‘visible’ on the
Internet and still have personal contacts to store in their Telname.

In many ways, resolving personal contacts in Telnames is similar to the ENUM scheme.
Both allow contacts to be stored and queried using ‘standard’ DNS messages, and both
are restricted in some way.

However, there are several differences:
(i) We believe that there should be a separation between storage of personal contacts and
machine addresses - one holds information on me, the other holds information on my
machine(s).
(ii) Performance issues are different from a ‘normal’ gTLD and similar to ENUM;
personal lookups are likely to follow Telephone network patterns, but machine address
resolution is going to follow normal Internet patterns. Current ENUM schemes do not
have this restriction - we believe that mixing the two is a mistake.
(iii) Phone numbers are useful NOW as an identifier, but we expect that there will be a
move towards using personal names as identifiers - most times, people want to talk to
a person, not whoever happens to be addressed by a particular phone number. For a
company, this isn’t a real issue, but for an individual, in most places you only are
allowed to register a domain in ENUM while you have a telephone service from a
service provider - that is a problem if you move and cannot take your phone number
with you.

2) No address records allowed?

We would expect that ‘standard’ Address records used to map to IP addresses would be
stored elsewhere from their contacts - these are fundamentally different uses. As stated,
we believe that the traffic patterns used for DNS queries on .tel will be different in the
short to medium term from those used to lookup the IP address for a machine.

In the short term, most people will be called by telephone numbers. We expect queries on
a registrant’s Telname for NAPTR, and for most, this would result in a phone call being
placed (e.g. over the existing wireline or cellular service). A Telname lookup is a
‘hybrid’, with a short Internet query, followed by a normal voice call.

Queries for A records will be done, as needed, in other TLDs - we expect cacheing to
behave differently for these lookups, particularly with ‘vanity’ domains for a personal
web server or for a mail server address. Similarly, as they are introduced, SIP ‘addresses
of record’ would be in a NAPTR stored in a Telname, but the ‘contact address’ for the
SIP phone would not, nor would the IP address of that SIP phone. There are good reasons
for suggesting that such ‘dynamic’ information should not be published in DNS at all; it
is certainly excluded from the Telname model.

3) SRV/MX records allowed?

From the above, we expect that MX and SRV records may be placed in Telnames, as
long as the target for these records is in another TLD.

4) Policing .tel domains?

We do not intend to scan all domains under .tel, but will react to a complaint from an
individual that a .tel domain is used incorrectly. As just mentioned, we do this for
performance concerns as well as general principle. In the case of Telnames, the check can
be done by anyone automatically, and will be simple (and so will be quick and with low
cost); it just involves a check on the kind of resource records returned in a normal DNS
query. Note that we do not restrict the kind of content that can be provided by a server
that is referenced in a Telname - any such restriction is related to the TLD in which the A
records are stored.

We hope we have answered your questions.

Telnic Management

Annex 3: Why Telnic’s .tel is an sTLD

A common pair of questions seems to have been raised regarding the .tel-Telnic proposal;
“what is the served community and what is the Sponsoring Organization”? An implied
question is “what is the goal of .tel”?

To answer this, it is useful first to consider what the goal of an STLD is, and how it fits
with the gTLD system. This has to reflect the history – how did we get here?

After this, we consider the detailed roles expected of the Sponsoring Organizations at the
heart of all proposals.

We consider how a community can be defined, in terms of the personal role or
characteristics of the registrant, and in terms of the usage to which the domain
registration is put.

We then describe the way in which we envisage how a personal name space can be used
to store personal (or corporate) communications contacts.

Finally, we describe how the Sponsoring Organization for .tel will have to remain
neutral, balancing the different interests of the community served, and not fall under the
sway of any single sectional interest.

1. History

Initially, the gTLDs were partitioned into name spaces that supported different groups.
Thus .mil served the community that was connected to MILNET and so was associated
with Department of Defense use. Similarly, .edu served the Academic community. With
network expansion away from ARPANET, there was a demand for domain names from
organizations that didn’t fit within these communities; thus the .com (and .org and .net)
gTLDs served the general pool of registrants that were not tied to Academic or Military
institutions. The introduction of .int was intended to cover those potential registrants who
had operations in more than one country, and initially was used to deal with global
infrastructure developments. This proved a major role, so that .arpa was introduced to
deal with “infrastructure” issues.

In parallel, a similar process was developing in other countries, with the creation of
country-code specific TLDs. In the UK, for example, the original domain name
registrations were dealt with via the Joint Academic Network (JANET); as commercial
companies inter-connected with this network, a defined partitioning into the .ac and .co
second-levels was made, allowing registrations for academic and commercial
communities to be made separately. As networks were interconnected between the
various countries, so the existing domain name system evolved.

Over time, the gTLD system and its role relative to the ccTLDs was refined; for example,
no longer did potential registrants for .com,.net, or .org need to be U.S-based
organizations. Their operational rules were limited to ensuring that the DNS continued to
operate; what the delegations were used for was unimportant. They had become true
general as well as global TLDs.

With the introduction of ICANN, one of the roles it took on was ensuring that the DNS
provided support for all Internet users. It became apparent (from the many issues raised)
that there were potential users who had a discrete identity that was not reflected in the
global nature of the general gTLDs, and yet didn’t fit into the strictly country-based
communities either. Thus the sTLD process was developed to deal with this perceived
“gap”.

2. Role of Sponsoring Organizations

The goal was to have identified groups served by proposed sTLDs with a strong
Sponsoring Organization to control those aspects of the sTLD that are specialised and so
don’t fall under general ICANN guidelines.

Specifying the identity of the group served is a crucial task of the Sponsoring
Organization at the heart of each of the sTLD proposals. The sTLD communities are not
mutually exclusive (i.e. a person can register a domain in .cat, and potentially in .travel).

Similarly, there are a number of “interested parties” for each potential identified
community, and balancing the interests of these different parties to ensure common
agreement on the operation of the sTLD is also a key task. Looking after the interests of
all of those affected by the proposed sTLD is a responsibility delegated by ICANN to the
Sponsoring Organization and its specialists.

ICANN is also responsible for ensuring the integrity and continued stable operation of
the DNS. Thus, another requirement in this process is to ensure that the Registries
operating the proposed sTLDs continue to operate. In practice, this means there is a
Sponsoring Organization that ensures the Registry serving a community does not cease
operations. It is important that the sTLD operation is commercially viable, and if not then
there is a group who can be called on to provide the needed financial support.

It also follows from this that, in most cases, an overly restrictive community means that
there is little revenue for the Registry operation using “normal” registration charges, and
so funding must come from somewhere; the Sponsoring Organization must ensure that
the Registry “business proposition” is viable, in conjunction with the community. In this
way, a balance is struck between the commercial drives of a Registry and that of the
community served by this “franchise”.

In the past, the sTLD operations have been restricted to non-profit organizations; this is
not the case for this set of proposals, so that some are operated on a non-profit whilst
other proposals have for-profit organizations.

Whilst the profit basis of the organization should not matter (in that the same
requirements from stable and continued operation are applied) it may affect the
Governance, structure and internal balance of the Sponsoring Organization that is, in
effect, responsible for the sTLD.

In a for-profit proposal, it is important that the policy setting function of the Sponsoring
Organization is autonomous from the Investors. In practice, there will be influences in
both directions as no policy can be set regardless of financial consequences. However,
care must be taken to ensure that these distinctions are not blurred.

For example, for a Sponsoring Organization to manage the sTLD policies effectively, it
should be careful to consider both the requirement for a commercially viable Registry
and the neutrality of the organization. Its policy setting functions should not be
dominated by the interests of any sectional group, regardless of the financial power of
that group relative to the other community members. This is a challenge for any proposal,
but with one involving a for-profit organization, it must be seen that, beyond doubt, the
Sponsoring Organization is strictly neutral and represents all users in the community
equally.

One should not be confused between the constituency of the Sponsoring Organization
(i.e. entities that have board member representation) and the community served by the
sTLD. The constituency of the Sponsoring Organization has to reflect the whole
community, rather than only a portion of that community. Where there is board
representation reflecting equally the wide spread of interests in the community, then the
constituency of the Sponsoring Organization can be said to be democratic. Where that
constituency does not reflect the plurality of the served community, then it is hard to
convince people that that community is well served.

3. How Should a Community be Defined?

As already mentioned, the existing general gTLDs have no restrictions on the people they
serve (or the use to which domains are put), and so any identified group chosen by an
sTLD proposal reflects an aspect of life of the potential registrants.

For all of these proposals, the identity is defined by a role taken by a registrant in a
served aspect of their life. Thus, for example, a Catalan-speaking person could register a
domain under .cat; they could simultaneously register a domain under .edu (if they
fulfilled the “Educational Establishment” criteria). These registrations reflect different
aspects of their life and are not in any way contradictory.

Thus what appears to be a simple question – “how is this person in the served community
different from that person who isn’t” – is not quite so straightforward. The real
distinction may be between two aspects of the same person’s life.

Identification of a community based purely in terms of the personal characteristics of
registrants is only one distinguishing factor and does not always have any meaning when
applied to DNS. For example, it is hard to see how a community of registrants who are
“left-handed people” has any relation to the content of their “published” zones.

With several of the proposals, the community identity is defined by the use to which
domain registrations are put, as well as the personal characteristics or organization
membership of the registrants.

For example, the purpose served by a registration under .cat is considered important – it
should be to further the social and cultural aims of the Catalan community.

In this case, the community membership is not only defined by inclusion (i.e. what aspect
is part of this community) but also exclusion (i.e. what aspect is explicitly not allowed in
this community).

Definition of community in terms of the usage aspect is important, not only for culturebased
proposals like .cat but also for all of the communications-based proposals (.mobi,
.tel-Pulver, and .tel-Telnic). The set of people who could ask for or use registrations in
the communications-based proposed sTLDs is almost everyone. Their community is
defined by the communications aspects of the registrants’ lives.

This emphasises another related point; the size of the community alone does not
determine whether or not the proposal needs to be an sTLD or is more suited to a general
gTLD. This is solely determined by whether or not the community requires a Sponsoring
Organization to define, control and protect its specific activities.

In the case of .tel-Pulver, registrations are open only to service providers, but these are
expected to use their domains to publish information on the communications contacts of
their service customers.

In the case of .mobi, registrations are open both to Service Providers (and Content or
Application providers) and to individuals.

In the case of .tel-Telnic, registrations are open to individuals and companies that wish to
store personal or corporate communications contacts. It excludes use to identify machine
node addresses.

These communications-based sTLDs all require a strong Sponsoring Organization to
ensure the correct operation of the domain space and to balance the conflicting interests
of the parties involved in their chosen communities.

4. Telnic’s .tel: An sTLD for Personal and Corporate Contacts

4.1. People are not Machines

Curiously, the generality of Internet users (either individuals or corporations) are not
represented by current DNS name spaces. The machines they use are, the servers that
support their applications are, but we feel that the people aren’t.

At present, the information held in a registrant’s domain indicates node names and IP
addresses, as well as the application services that run on those nodes. Thus the identity of
a potential registrant does not reflect the use to which they put their domain registration.

4.2. People as Numbers: ENUM is half the solution

The introduction of ENUM changes that – for the first time, personal communications
contact data is to be “published” in DNS in a coherent and structured way. The E.164
telephone number acts as a top level identifier for that person, and with ENUM, this is
tied to a defined domain name space. Using this, we now have a DNS space that
represents a user rather than their machines. Within ENUM, the registrants can store and
“publish” the communication contacts that relate to them, rather than just the machines
they use.

However, there are several limitations and restrictions in the use of telephone numbers as
universal identifiers, and they interfere with the goal of ENUM.

The assignment process by which E.164 numbers are provided is closely controlled to
ensure that a given number is truly unique. The existing (and quite reasonable) process by
which this is done involves national control over those number spaces, and thus, in
ENUM, implies national control over the associated domain name space.

There is another risk to the use of E.164 numbers as personal or corporate identifiers;
these numbers are traditionally associated with Telephony Service, and in many
jurisdictions current plans assume that an ENUM domain registration will be valid only
while the registrant has Telephony Service provided via their E.164 number. If that
service ceases, then their entitlement to the E.164 assignment (and thus to the ENUM
domain) also ceases. Thus, unless the registrant is guaranteed exclusive and continued
assignment of an E.164 number, then the ENUM domain is not always a reliable place
either to store or to look up personal contacts.

Finally, the basic advantage of telephone numbers as identifiers is also one of their most
marked weaknesses. They are easy to dial into even the most basic communications
terminals, but they are hard to associate with a person – as most customers do not have a
free choice of the E.164 numbers they are assigned, they are not readily predictable, and
they are not very memorable.

4.3. People as Names: Telnic’s .tel is the solution

With the introduction of more capable terminals (for example, with mobile phones or
PCbased VoIP clients), many people have been enthusiastic in their use of in-built address
books and other aids that allow them to operate on the level of names rather than
numbers. This is neither surprising nor unexpected – nor is it a passing fashion. For this
reason, we believe that whilst ENUM is a major step forward in allowing a personal
name space for communications contacts, it is to some degree an interim technology that
is limited by the use of E.164 numbers as the “top level” personal identifier.

The .tel-Telnic proposal envisages a true Personal name space to store and publish
communications contacts for individual and corporate registrants.

This domain space uses the names that people find easier to use than E.164 numbers, but
employs similar DNS technology to the ENUM system. The zones for .tel domains will
hold NAPTRs that indicate the registrant’s communications contacts, and by querying
these clients (or their agents) can decide on the most appropriate form of communication,
without requiring dedicated support in any single Service Provider’s infrastructure.

This means that the domain fulfils the goal of a personal domain space, without the
limitations of number-based identities. It does not conflict with other TLDs as they will
continue to be used to identify machines.

In common with the other communications-based sTLD proposals, we believe that a
gTLD is inappropriate. This task requires a neutral Sponsoring Organization that can
build consensus amongst the different groups affected by .tel mediated communications;
it is too important to leave to any one sectional interest.

5. Telnic’s .tel Sponsoring Organization and Community

5.1. Telnic’s .tel needs a unique policy perspective

There are several key aspects to the .tel-Telnic proposal that, in combination, have a
unique influence on the policies and operations that justify an sTLD. Whilst it is the role
of the policy setting function (defined in our proposal as the Policy Advisory Group, or
PAG) to establish the issues and the policy choices to be made, we raise a few here.
• .tel is a Name based system. Our goal is to provide domains that are exclusively
tied to a person or company’s name, and are used to hold contact information
associated with the registrant rather than their machines. This is a specialised use of
the domain name system, and introduces new possibilities. For example, it is now
practical for a registrant to store “non-Internet” contacts in their zone (e.g.
telephone numbers) alongside links to their web sites. In this, it enables potential
services that have not been a part of previous TLDs. It shares underlying
technology with ENUM – the difference lies in name rather than number based
identification, and to avoid confusion, registrations of domain names of the form
used in ENUM are barred.
• .tel has different privacy concerns. In the case of this sTLD, we believe that our
focus on personal and corporate contacts will lead to a different balance in terms of
data protection and privacy. Whilst this may seem paradoxical, given that
registrants will use their domains to publicize their contacts, we expect that they
will wish to maintain control over any contacts available, including those from the
Registry and Registrars. Against that must be balanced the concerns of existing
Intellectual Property protection groups, as expressed by CCDN.
• .tel is an enabler for communications. We believe that, as it is used to hold contact
details, most queries will be done as the prelude to a communications session. Thus
there may be a reasonable expectation of DNS server performance on the part of
clients who query this data. This expectation will be different from that in
“traditional” TLDs, and is a direct consequence of a communication-focused sTLD.
• .tel is the holder for personal contact information for individuals and corporations,
and therefore must guarantee fair access, use, and publication to the industry,
regardless of network access technology.

5.2. Groups who need representation in the .tel served community

The groups that make up the .tel served community and their interactions are different
from other TLDs.

In addition to the usual group of interested parties (Registrants, Registrars, third parties
with an interest in protecting Intellectual Property), it adds new ones.

The use of .tel as a prelude to communications means that third party communications
service providers have legitimate interests in the performance provided by the DNS
servers, not only of the Registry itself but also those Authoritative servers that host a
registrant’s zone. Providers of such Authoritative DNS hosting service will need to be
represented so that reasonable recommendations can be agreed.

As a holder for contact information the Sponsoring Organization has a a responsibility to
guarantee fair access, use, and publication. Thus, the communications service providers
who use the data will need to be represented in the policy setting process. Equally,
developers of new applications that process the contacts for other services (for example
in a directory service web portal) will also be involved.

To initiate this process, Telnic has appointed an eminent “Interim PAG” Chairperson
with the mandate to select six influential and representative individuals with the exclusive
goal of establishing the PAG charter and the development of the PAG.

5.3. Model for Telnic’s .tel Sponsoring Organization

As the .tel-Telnic Sponsoring Organization is a commercial venture, special concern has
been taken to ensure a separation between the commercial needs of the Sponsoring
Organization and the policy setting role that defines the operation of the sTLD. To that
end, overall control of policy setting for the .tel sTLD has been delegated to an
autonomous Policy Advisory Group with strong Sponsoring Organisation board
representation, and a mandate to ensure diversified community inclusion.

The PAG will exert effective control over policy, and is not merely a source of proposals
without power. This will guide the sTLD and specify all policies to be carried out. Only
in the case where policies proposed by the PAG will directly damage the stable operation
of the sTLD, or are in direct conflict with ICANN agreements, can the Sponsoring
Organization refuse to implement the proposals. In effect, the PAG will control all policy
issues in the .tel sTLD.

As a closing point, there is another reason that drives us to conclude that a
communications-based TLD requires a broad based and independent policy-setting
constituency. The reason for using a Top Level Domain to hold name-based personal and
corporate contacts is that it forms the “one place to look”. There is a responsibility that
comes with this right, however.

Apart from the obvious need for the operations of the sTLD to remain commercially
viable, policy setting should reflect the people served by the sTLD, not the Investors in
the Sponsoring Organization. Blurring the roles and responsibilities of the two in a
commercial venture can only lead to conflicts of interest.

We think that this is the only reasonable approach to a “for profit” Sponsoring
Organization, and in particular for any sTLD that has its focus on communications. Only
through a wide constituency with real control can we avoid the risk that the sTLD will be
used by a sectional group to further their aims to the determent of others, and particularly
the registrants. No single group should be able to “take control” of this important role.
The Sponsoring Organization must not only be neutral, but be seen to be neutral.

We believe that there is a business case for a Registry to support a Name-based
communications contact name space, that it adds value to the Internet name space, and
supports a defined use and so community. This meets the definition of a Sponsored Top
Level Domain; it has an autonomous policy setting group with executive power, it has a
defined community, and a well-defined use.

https://archive.icann.org/en/tlds/stld-apps-19mar04/sTLD-EvaluationReport.pdf