ICANN Email Archives: [stld-rfp-tel-telnic]

The comments from Telefonica are very surprising for a leading Internet Access and Telephony Services Provider.

o 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.

o 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 .tel-Telnic proposal. It is unclear why these comments were made to this proposal only.

o The comments also reflect a basic confusion between storage and publication of communications contact information and provision of communications service to those individuals.

o 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.

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.

By implication, these new services and applications use the Internet & DNS for naming, not just the PSTN and E.164 telephone numbers.

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.

'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.

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.

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.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.

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.

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.

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.

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.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.

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.

[stld-rfp-tel-telnic]

Telnic's Reply to Telefonica