MINUTES of E164-to-IP BOF at 42nd IETF (Chicago, August 1998)
Chair: Scott Petrack <petrack@vocaltec.com>
1. Scott Petrack <petrack@vocaltec.com>
- gave an overview of the "E.164 number to IP address mapping (ENUM)
problem". The slides can be found at
http://www.vocaltec.com/~petrack/IETF/E164/BOF1/Petrack.ppt
It included a set of questions that needed to be resolved in order to write a charter,
such as:
1. Do we really want to resolve true E.164 numbers, or "any old telephone
number" (e.g. 911 or *123 may be well known local telephone numbers, but
they are not E.164 numbers).
2. Each E.164 number is "owned" by someone -- there is an authoritative
hierarchy of who controls the information about them. Do we really want to
copy this hierarchy into our solution?
3. What will the exact input and output to such a query be?
4. Do we need two protocols -- one for the query/responses and a different one
to maintain the information?
2. Christian Huitema <huitema@bellcore.com>
- spoke on what made ENUM Problem different from other simple lookup
questions, and presented some elements of an architecture to fulfil the special
requirements. His slides are available at
http://www.vocaltec.com/~petrack/IETF/E164/BOF1/Huitema.ppt
The main problem according to Christian is to determine "who owns a number or
prefix"? According to him, it is useful to enable competing "claims" that they can
resolve the query. For example, if a Telco has been allocated a particular E.164
number, then if the NUM is "owned" by the Telco which owns the number, that
Telco may have a conflict of interest --it might be unwilling to allow a competing
IP telephony provider to insert information about how the competitor might resolve
the information. So a system is needed that allows competing claims to be able to
resolve a query. It is a bit like in Web searches, where a single string may turn up
many different URLS which "compete" to resolve the information for you.
Christian's solution is to think of the E.164 number as just being an "identifier of the
called party." Then the protocol must be able to express things like "Bellcore claims
to be able to resolve that identifier", and this claim is accompanied by a FQDN (fully
qualified domain name) and a signature of the claimant. The FQDN is used to
further resolve the information. It is necessary to allow parallel, conflicting, and
competing claims. DNS can be used to provide both security (the signatures needed)
and also forward and reverse mappings (i.e. between "identifiers" and "FQDNs
of claimants".
Christian views queries as happening in two steps which are quite separate: The first
step is E.164 to FQDN, and the second step is FQDN to URL (such as a "phone
URL" or a sip URL or H323 URL). He envisions that the main competition will be
in the third, next step, of gateway selection, and as such will be an IPTEL problem
more than an ENUM problem.
3. Jonathan Rosenberg <jdrosen@bell-labs.com>
- spoke on what distinguishes ENUM from the problems that are being worked on
in IPTEL. His slides are available at
http://www.cs.columbia.edu/~jdrosen/papers/ietf_e164_aug98.ppt
Jonathan emphasized that the ENUM problem is distinguished from the problem of
"gateway selection", in that the ENUM problem is a problem in "endpoint selection" --
that is, to find a server which can be used to further resolve information about a
particular E.164 number. For example, given an E.164 number, the query should be
to find all service providers who can service that number. It may be that the "service"
given to a particular E.164 number might not be "phone service." For example, the
callee decided to "call forward from his phone to his Email", then it might be that
given an E.164 number, the ENUM query will result in a mailto: URL, so no gateway
selection or location is involved at all. IPTel is working on the "pure" gateway
location part, where it is known that a PSTN gateway is to required to complete a
call to some number. In contrast, the "gateway location/selection" problem is one of
"path selection" -- that is, it has already been decided that the communication is to
take place to some terminal on the PSTN with a given E.164 number, and now the
correct path to that terminal via a particular gateway must be chosen.
4. Chinmei Lee <chinmeilee@lucent.com>
- spoke on the similarities between the problem of resolving E.164 numbers to IP
address and the problem of resolving GSM phone numbers to a routable number
which can be used by telephone networks to route a call to the callee's current
location. She suggested that the solution used in GSM could be profitably
translated to solve the ENUM problem. Chinmei's slides are at:
http://www.vocaltec.com/~petrack/IETF/E164/BOF1/Lee.ppt
The solution that results has the similarity with the others that there is a "two-tier"
resolution. First, the number is used to determine the "home server" that can provide
information about the number. Then, that server is queried in order to return the
information needed (namely, the IP address (dynamic or static) of the destination
subscriber, entered when the IP subscriber registered to the IP network).
5. Anne Brown <anne.brown.arbrown@nt.com>
- spoke on the requirements for a deployable and practical global E.164 to IP
address infrastructure. She emphasized the great need for deploying the service
quickly. Her slides are at:
http://www.vocaltec.com/~petrack/IETF/E164/BOF1/Brown.txt
Anne Brown envisions a global system of "Internet Telephony Directory Service
Providers (ITDSP)," made up of three separate functional entities: ITDSP
"consumers" -- clients who make queries about E.164 numbers; ITDSP "servers" --
which are responsible for delivering that information to the clients; ITDSP
"suppliers" -- who upload the information to the servers.
These may be separate from the entities that actually allocate the E.164 numbers
themselves. Access to ITDSP information should be free and unauthenticated, unless
a number is requested to be unlisted. Anne emphasized that it is important to get
agreement as quickly as possible on the query/response access protocol to be used by
clients, and on the "information provision" protocol to be used to inject information
into the global databases. She suggested that the client protocol could be based on
either or both DNS and LDAP, perhaps using the tpc.int solution as a basis. It was
important that the space be totally flat, because she did not want clients to have to
know how to parse an E.164 number in order to make a query.
Her slides contain a suggested way to use both DNS and LDAP.
6. Patrik F?ltstr?m <paf@swip.net>
- spoke on the requirements for solving the ENUM problem, and gave a solution
based on NAPTR and SVR record lookups within the DNS.
Patrik's solution was: The input to the query would be an E.164 number and the
preferred protocol of communication. The result would be an endnode address, and
the protocol to be used to contact that endnode. The information is retrieved in two
steps:
a.) The client does an NAPTR query using the E.164 number as input. The
response contains a list of the pairs (service, Domain Name of service
provider) which are available to that number.
b) The client chooses which (service,service provider) pair it wants to use and
does an SRV lookup in DNS to the DN of the service provider chosen). The
response contains the info needed to contact the endnode.
Because this uses DNS "as is", there is certainly a single authority behind the answers
to each query, so this does not quite provide the "total free market" solution that
Christian would like. But Patrik's suggestion is that the actual human "owner-user" of
the E.164 number can be given the power to maintain the DNS records, so at least
s/he has total control over who provides which services to the number. In this sense,
it is a complete solution for "number portability."
7. Louise Spergel <louise@mvjok.mv.lucent.com>
- gave a presentation on the work being done within ETSI TIPHON WG4 on
"Naming and Addressing". Her slides are at: http://www.vocaltec.com/~petrack/IETF/E164/BOF1/Spergel.ppt
This work includes coordinating an applicaiton to the ITU to receive a new global
service code within the E.164 number space for IP based terminals (a.k.a. "a country
code for IP based terminals") . She described why this is a good idea, how it might be
used, and what still needed to be done before the ITU might agree to allocate the
service code. A more complete "service description" needs to be written, so that the
request for a new "country code" can be accepted. Louise welcomed those present
at the BOF to contribute to the information in TIPHON WG 4 that would be required
to obtain approval of the cc.
After these presentation, there followed a short discussion, during which the
following points were made:
a) Rather than concentrating on just E.164 numbers, there are many schemes of
"hierarchically assigned authoritative numbering schemes." Other examples are
ISBN book numbers, credit card numbers, etc. (even email addresses). It might
be useful to come up with a single solution for resolving all these "hierarchical
numbering schemes". (Don Eastlake). An internet draft on the subject was
indicated. (PAF, can you get Don to please help me here...)
This was considered extremely interesting and useful input. But these schemes may
not allow the sort of "competing claims" that Christian wants (i.e. Can we have two
different compete claims to resolve an ISBN or credit card number?)
b) Careful attention must be paid not to wake up the regulators who might seize on
the fact that E.164 are scarce, expensive resources, in order to start regulating
various aspects of the protocol we might define. (Henry Sinnreich)
There was general agreement that it is important to avoid doing anything that might
involve regulation later.
c) A comment was made that it would be very unfortunate to break the "geographic
link" between telephone numbers and places, which all the proposed schemes
could do. In answer, the chair pointed out that roaming and number portability
already was breaking this link, and that although indeed geographical information
might be an inportant input into the query, we could not count on phone numbers
to carry geographical information anymore.
d) There was some discussion about what to call the actual problem, BOF, and/or
WG. For the time being I have taken Jonathan Rosenberg's suggestion of ENUM,
although it may be that we decide to avoid referencing E.164 numbers directly,
and rather just speak of "Number to IP mappings" (NIMs?)
As a final summary, it was agreed to carry on discussion on the list to see if we could
resolve enough of the questions raised during the chair's presentation to write a
charter. Keith Moore (or Patrik??) asked for a show of hands as to how many people
wanted a working group on the subject, and there was a very large number, and also
how many people could actually contribute real time to completing such an effort,
and there was a much smaller but still quite respectable number of hands.
None received