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

IS A NUMBER-BASED REGISTRY FOR COMMUNICATIONS CONTACTS APPROPRIATE IN THE LONG TERM?
-----------------------------------------------------------------------------------

In the short to medium term, it is easier to dial numbers than names using the majority of fixed telephones. However, the rapid increase in use of cell phones (and the applications these phones include) makes this limitation less important than it was. In the future, dialing names will be both possible and have some significant benefits:

- A telephone number is assigned for use with communications service provision. This means that the number may no longer be valid (and control over the number may change). If the domain registration is tied to control over the number, then the Registration may be transitory. De-coupling of a domain name from the transport service provided is one of the original reasons for the introduction of the DNS, and remains true today. By hiding the network addresses behind a name, changes in those addresses could be reflected quickly and easily in a distributed manner. Tying a domain to the telephone number by which a communications service is provided is limiting unless full number portability is supported for that telephone number.

- A textual name tends to be more memorable, so that the risk of misdialling is reduced. Particularly for Personal (or brand) name-based domains, the text has mnemonic properties that telephone numbers don't have.

Given that the limitations on textual-based dialling will disappear in the medium term, and that associating domain contact storage to a number that is tied to communications service may lead to enforced changes of registration, an text-based naming scheme independent of communications service provision is more appropriate for the future.

THE E.164 NUMBER-BASED REGISTRY EXISTS; THIS PROPOSAL DILUTES THAT REGISTRY
-------------------------------------------------------------------------------------------

A single public Registry for domains associated with E.164 numbers has been agreed between the IAB (as controllers of .arpa.) and the ITU (as controllers of the E.164 number space); it is: e164.arpa. This domain space is organized into country or region-based partitions, aligned with the E.164 country code delegation scheme and so allowing the Nation States to control their own number spaces and the domains associated with those spaces.

The NetNumber/Pulver proposal is in direct competition with this e164.arpa. Registry, taking control of the global number space into one (U.S.-based) company.

One of the goals of e164.arpa. is to have a single authoritative Registry for domains associated with E.164 numbers, rather than a set of incomplete Registries that act more like competing Business Directories. By introducing this competition, the proposal attempts to destroy this single authoritative Registry approach.

From a Registrant's perspective, this raises the question: where do I register?, and similarly from a querying client's perspective, where do I look for contact information? As such, the proposal is destructive and has a major impact on efficiency.

Clients will have to issue more than one query before they are sure that there is no contact information stored associated with an E.164 number. If this is done immediately prior to placing a call, then this will increase the time before a communications client will be able to determine a call strategy.

As it is in direct competition with another Registry as a repository for contact information associated with E.164 numbers, the benefits of a defined TLD aren't important; it acts as just another business directory, and could use any domain name as its apex.

The community defined for the NetNumber/Pulver proposal is the IP Communications Service Providers (IPCSPs). The proposed name space is intended to allow them to store communications contact information.

E.164 numbers are assigned by the National Regulatory Authority (NRA) to a Communications Service Provider for use in providing the service. In effect, the number is assigned to the end customer for the duration of communications service provided via that number.

The NetNumber/Pulver proposal seems unclear whether the end customer has any rights over a Registration for a domain associated with their number. It mentions day-to-day control over an E.164 number, which would imply the end customer, if service is provided to that subscriber via that number. However, these end customers are not within the community served by the proposal. The proposal explicitly states that the name space is intended for IPCSP use.

However, it then states (under Registration Validation Policy, in the Proposed Extent of Policy-Making Authority section) that they will enforce a: Policy that limits registrants to IP Communications Service Providers (IPCSPs) who are registering names on behalf of individual subscribers who have been assigned control over the E.164 numbers being registered as names under the .tel sTLD.

Furthermore, (under section B. Protecting the rights of others, point 5), the Conflict Resolution policy is open to individuals and enterprises (i.e. the subscribers) as well as to service providers.

This raises a question that needs clarification: an IPCSP is intended to be Registrant for a domain associated with an E.164 number, but who has a right to populate data in the DNS zones so delegated; the individual subscriber, the IPCSP, both, or some third party?

It is perfectly possible to store many contacts (for example, an e-mail address, a web site, a cell phone number, and a SIP URI) under a domain. If a subscriber to one of these services (for example, to a SIP service) wants to store their email address in the zone data, can they? What if the customer has more than one service provider; can they publish contact data for all of them?

- If an IPCSP registers domains associated with a number or range of numbers via which it provides service, and uses these domains to store contact information, then data privacy is an issue.

- In publishing contact information relating to a customer, the IPCSP may well be breaking data privacy laws unless they gain the explicit agreement of that customer to the publication of each item of data.

- Note that, during the migration from PSTN/PLMN to IP communication, the contact addresses will not just be numbers; they will include SIP URIs such as sip:henry(at)sinnreich.org. This potentially exposes customer names, and so sensitive information.

- As such, it seems unlikely that an IPCSP would be advised to use a domain for the purposes specified in the proposal; the financial risk would be too great unless they confirm the data they are allowed to publish with their subscriber.

- An alternative might be for controlled publication of this data to be arranged between service providers that guarantee that the information will only be used internally and will not be made available publicly.

- However, even if this is acceptable in some jurisdictions, it opens an IPCSP to legal liability if another Service Provider that is privy to the data fails in this obligation. As such, such data must in practice be carried over an unconnected network. If this is the case, then there is no need for a public domain at all; machines on this private network would be operating with a private DNS tree.

- The proposal requires that all registrations will be made by an IPCSP for numbers via which they provide services to their subscribers. This implies that any customer who is provided services by an IPCSP who does not wish to participate in this scheme will be excluded from Registration. Their only option is to change to a provider who is willing (and able) to act on their behalf for Registration.

- Given that (in some jurisdictions) choice of CSP is regulated, this can lead to the subscribers not being able to select such a participating service provider, and so to have no possibility of registering a domain in the proposed name space.

- It appears that it is not possible for an individual to challenge an IPCSP's right to register a domain associated with the telephone number by which they are provided service by that IPCSP. Thus an unscrupulous IPCSP could register a domain associated with the telephone number without any possibility of challenge from the subscriber.

- The challenge procedure describes a mechanism by which an IPCSP can challenge the representation of a subscriber (or strictly, that they can assert that they provide a communications service via a telephone number assigned to the individual for this purpose).

- In some regions, subscribers have found their communications service has been fraudulently transferred to another service provider without their knowledge or informed consent. This process is called slamming. There are defined mechanisms in place to defend against this and to discourage those who engage in it.

Whilst there is a statement that the Conflict Resolution process will be online, it is not clear that this is possible other than placing an initial challenge.

Given that the zone data held for a domain will include contact information, an extended process is in many ways worse than the impact of traditional domain hijacking.

Number portability is required in many countries; this can make it difficult to demonstrate that a particular number is used by a given service provider.

In many countries, a significant proportion of the population is not included in a public directory, and in some jurisdictions there are strict controls over access to and use of the information included in public directories.

For number blocks allocated to an enterprise, it can be time-consuming to gain service provider proof that all of the numbers in the block are actually assigned to that enterprise.

For these (and other) reasons, it seems unlikely that the resolution process will be quick, and so an invalid domain transfer could have a devastating impact on communications service to a subscriber, quite out of proportion to the costs of the resolution process itself. Conversely, an invalid challenge may be insufficiently penalized, as the deposit is paid by the Registrant, not the challenger.

- Many of the issues raised above are caused by the requirement that a Registration is tied to Communications Service Provision, and by a confusion between the person who has day-to-day control over an E.164 number and the Registrant (and user) of the associated domain (i.e. who can publish zone data).

- The mechanisms used in number assignment differ throughout the world, and it is hard to see how a single rule set can be designed that can deal with these differences. The reason for a partitioning of the e164.arpa. domain space was to allow control to reflect these differences; with a gTLD, this reflection is missing.

- By focusing on the IPCSP, the proposal appears to simplify the process of Registration, in that only a Service Provider can register a number. However, this is an illusion, as it can exclude significant potential subscribers from the system unless every IPCSP agrees to be involved. Also, the penalties that can be applied to a rogue IPCSP are limited, particularly across jurisdictional boundaries. It is possible to attack the system using the Registration and Challenge processes, and this does not seem to have been considered in enough detail. The rules controlling communications service in the PSTN have taken considerable time to develop and are not all arbitrary.

Whilst competition is appropriate in many situations, replacing a single, authoritative Registry with a set of incomplete Business Directories is damaging to the interests of the Registrants and the Clients that have to query multiple domain spaces.

- The Definition of Community and the implications over rights to the domains registered (and to control over the data published within the domain zones) is unclear.

[stld-rfp-tel-pulver]

[stld-rfp-tel-pulver] Comprehensive Anaylsis of the Pulver Proposal