Subject: [Enum] Summary and Minutes of ENUM in Washington

From: Scott Petrack <[email-masked]>
Date: Thu, 2 Dec 1999 14:53:17 -0500 (EST)

The following summary and minutes of the ENUM working group are long
overdue. Thanks to Jonathan Rosenberg and Willi Wimmreuter for providing
their notes to me. Please review and correct if I under- or
mis-represented you.

Scott (Petrack)

Short Summary of ENUM WG meeting -- Washington DC Nov 1999

The ENUM working group had its first meeting in Washington Nov 1999. 
The meeting reviewed the basic charter and scope, which is to map
from telephone numbers into a set of URLs (or the information contained in 
set of URLs). ENUM will concentrate on using DNS for mapping queries and
responses: the "back-end" services, such as administrative questions of how
the data gets into the DNS, is outside the scope of ENUM.

Patrik Falsrom presented his I-D draft-faltstrom-e164-03.txt, and the group
discussed the suitability of this draft as a basis for ENUM's work. It 
seems that there was rough consensus that the approach taken in the draft
is reasonable enough, and a new draft, incorporating comments from the WG
meeting, will be prepared. The draft should at the very least be reworked
to present a more generic mapping service, rather than a set of examples
narrowly focusssed on implementing number portability.

Detailed minutes follow.

Scott Petrack

Minutes for the ENUM WG (Telephone Number Mapping) meeting

Place: Omni Shoreham Hotel Washington DC,
Date: Nov. 8. 1999, from 15:00 - 17:30
Reported By: Wilhelm Wimmreuter
Prepared By: Scott Petrack

The ENUM working group session was held on Monday afternoon with about 120
people attending. The working group was chaired by Scott Petrack.

DESCRIPTION:

This working group will define an architecture and protocols for mapping a
telephone number to a set of URLs which can be used to contact a resource
associated with that number.

AGENDA:

1. Agenda bashing                                   5 minutes
2. presentation of proposed charter                15 minutes
3. Requirements     by Anne Brown          (new)
4. presentation of I-D by Pattrick Falstrom       15 minutes
   draft-faltstrom-e164-03.txt
5. discussion of suitability of this 
   draft as basis                                  25 minutes

1.	AGENDA BASHING:

	In addition to the original agenda, Anne Brown was assigned to
present and discuss a list of requirement for ENUM.

2.	CHARTER and SCOPE

Scott Petrack presented various examples that fit in the scope of ENUM:
  - "sending Email to a telephone" (smtp used to send text to pagers)
     need to map telephone number to mailto: URL

  - translation to SIP URL, Mailto, fax, ....

In general ENUM is to translate phone numbers as names to IP addresses 
and other auxillary information. Therefore, the use of DNS based solution 
is reasonable. Other approaches are possible, but this working group is
chartered to produce a DNS-based solution. Our goal is to specify the best
DNS-based solution we can find, and document its capabilities and weaknesses.

The definition of new RR's (extension of DNS) is a lower priority. 

The working group is NOT chartered to discuss how the data is inserted 
into the DNS, only how to access the data. 

Finally, the chair presented some open issues:
  - performance
  - Capability Announcements

The following questions where raised by the audience.

*	Christian Huitema raised a concern that it must be possible to
retrieve the data from multiple sources. 

*	Wilhelm Wimmreuters stated, that Reverse lookup is required and
therefore some kind of PTR records shall be used to accomplish this function

*	Melinda Shore raised the concern that operational procedures are
absolutely critical. For example, it may be necessary to ensure that NS 
records can be inserted by one provider for another.

	Scott Bradner replied that indeed operations is indeed critical,
but not for this group. Scott Petrack replied that it is within scope to
decide (for example) that an NS record pointing to a new name server shall
be used to enable "porting the phone number" from one information provider 
to another. What is not within scope is just how the owners of the databases
are incented to do that.

*	Bjorn Marshal from Ericsson mentioned, that billing for lookups will
be an issue in future and ENUM might be the place to discuss that.

	Scott Bradner replied that accounting within the database is outside
the scope of ENUM (anything internal to a database is outside ENUM scope).
However, security based access controls is certainly within scope.

	The question was raised if this could be a placeholder for
later discussion on accounting for phone calls.

	Lawrence Conroy mentioned that an E164 number is not a billable
entity in any case.

	Scott Bradner repeated that it is entirely irrelevant to ENUM if
lookups or anything else costs money.

	Scott Petrack repeated that it is within scope to provide the
security neccessary to authorize requests, and perhaps to enable
non-repudiation that the request occured.

*	Scott Petrack made the comment that there was enough common interest
just in the problem of "looking up phone numbers", and enough people wanted
to see a DNS solution, that it is worth first deciding how to do this basic
task.

	There was some discussion on the suitability of other protocols 
like LDAP for this purpose.

	Scott Bradner concluded this discussion with the statement that the
IESG will give consideration to other working groups based on other 
technologies. But work on non-DNS solutions will not happen in ENUM.

*	Scott Petrack made the comment that it is important that we document
the applications for which DNS is clearly NOT appropriate. For example, it
is probable (may be?) that DNS is not good for highly dynamic data, since
propogation of data is not very fast. 

3. Requirements by Anne Brown

Anne Presented a list of requirements and invided the audience for further
discussion.

a. Basic endpoint address lookup: have phone number, want endpoint address.

	There seemed to be agreement that the output should be essentially
a URL. (The actual response may or may not contain an actual URL, but it
should be possible to construct (possibly multiple) URL(s) from the response.

b. Retrieval and negotiation of additional info.

	Richard Shockey said that retrieval should be in scope, while
negotiation should be out of scope. Dave Oran said that rescap is doing
this work, and so probably it should be out of scope for ENUM. Scott Bradner
said that certainly ENUM should look at that work and see if it is appropriate,
although ENUM could decide that it's not. Anne agreed that capability 
announcement was in scope.

	Jonathan Rosenberg asked if the size of the responses would be a problem
for DNS, because it runs over UDP. He also asked if there one could just
return an LDAP URL within the response to get further info such as 
capabilities. Patrik answered that this is entirely possible. In any case,
ENUM would never define a new URL. If ENUM decides that one is needed,
it would go to the appropriate working group to have them make one.

	Jonathan Lennox asked if there is a difference between saying 
"Give me the SIP server for this number" and "give me the directory
server for this number". Scott Petrack replied that the difference is that
you speak SIP to a SIP server and LDAP to an LDAP server. The two servers
have different URLs. It must be possible to get back both in a response
(if they both exist of course).

c. Qualification of a request (this means having the server apply some
filter to a response. There may be many URLs in the repsonse, and the
requestor is only interested in some subset).

	Scott Petrack said that they are out of scope, unless there is 
some problem with network bandwidth and they are required to make the
responses fit within a UDP packet.

f. Provisioning of the Listing Information

	Scott Bradner said that this is generally out of scope for ENUM, 
and will go into some other group. Patrik Falstrom said that his presentation
covers some aspect of this.

g. Security

	Anne said that we should point to DNS-sec, except that any E164
specific stuff would be within scope. Scott Bradner pointed out that the
IESG requires WG to think about security.

h. Response time and timeouts

	Anne said that clearly performance requirements are in. Christian
Huitema said that since we have committed to DNS, we have no choice but to
live with its performance. Anne replied that we will certainly need to 
document performance. Someone (?) noted that DNS "experts" differ wildly
on what performance DNS technology can achieve. Scott Petrack said that
it is not assumed a priori that the ENUM solution will run on the 
public DNS infrastructure.

i. Number portability

	Anne Brown said that there may be more than one provider who
wants to provide a given number. This can't be done by a telephone
number tree. Someone (?) said that who "owns" the telephone number is 
out of scope. Dave Oran noted that if you stay within the IP world, 
portability comes for free. He asked if the requirement is that the ENUM
solution should replace the existing system for global number portability?
Melinda Shore said that there will be a conflict between number portability
and performance requirements. Someone (?) that to be useful the ENUM 
solution must fit within the time budget for Call setup times.

j. Miscellaneous comments

	Milo Orsic said tha mobility should be out of scope. There was
general agreement that the dynamic nature of information needed to support
mobility made it difficult to use DNS for everything, although the ENUM
solution might fit in with a more general mobile service.

	Jonathan Rosenberg wanted an explicit non-requirement that ENUM
would not be used for gateway selection.

	 David Gurle asked to review the reasons for the assumption
of a DNS-based solution. Scott P said that there was agreement that DNS
was one reasonable approach, and this group was chartered to see if it would
really work. Scott Bradner made the comment that the IESG felt that there
would never be real agreement between the various base approaches, so that 
it was most appropriate to develop each one separately. 

Someone (?) stated that such a server must serve different networks and 
therefore the service might use different protocols Scott Petrack answers, 
that we shall not do everything, and look only for things that can be done 
with DNS.

4. Patrik Falstrom's Presentation: draft-faltstrom-e164-03.txt 

Patrik Falstrom presented his draft. He mentioned that it is flavored by
portability, which was its original purpose. It is based on the standard
set of indirections used throughout the Internet: 
URL->domain name->IP address->routing

DNS is a database, good at lookups and distributed delegation. DNS is not
good for searches. Ericssn has already replaced done work replacing an IN
database by DNS lookups for number portability. It was further stated, that 
DNS Naming schemes are already defined for E-Mail to FAX translations.

Patrik's solution uses the specific resource records:

	NAPTR: domain name to a list of services.
	SRV: service to list of domain names.

Patrik proposes a listing service, that makes use of DNS. 

There followed some "animated discussion"  on the subject of how one 
can tell if a given number is part of the E164 domain or if it belongs
to some other domain:

	Dave Oran asked how the client could know if a given number belongs
to e164.int or something else.

	Scott Petrack said that this is within the scope of ENUM. 

	Scott Bradner said that we don't want to spend time on what goes
on the "right hand side of the @ sign". Let's say that it's in some magic
configuration file.

	Christian said that there have been advances in DNS. We might be 
able to discover the correct zone in some way.

	Patrik pointed out that his draft can be used to map from
one zone to another.
	
	David Gurle pointed out that there is a distinction between 
E164 numbers and private number. Scott Petrack replied that one
could put something else besides e164.int, but that the WG would 
have to either pretend that the base domain is already a given, or
specify some way to determine the base domain. Anne Brown asked if 
"I have two service providers, who lists my information." Scott Petrack
replied that Patrik's draft distributes the information among multiple places
in any case. Christian Huitema said that this was not enough -- the root of 
the information itself must not be unique. Scott Petrack asked that this
discussion get carried to the list. In any case, we must provide a solution
for the case where the base domain is decided.

	There was a question about why one put a dot in between each digit. 
Why couldn't it be instead a unique email address? The answer is that this
group has been chartered to look at phone numbers. 

	Christian Huitema mentioned that the CNAME could be used to point
you somewhere else.

	Willi Wimmreuter pointed out that numbering subdomains don't 
always match administrative boundaries. 

	Milo asked about using 800 numbers. Scott Petrack claimed that
all these problems are similar to just having numbers from different
numbering spaces. 800 numbers are not international E164 numbers.

	Mo Zonoun asked about retrieving carrier access codes. Scott
Petrack said that they are out of scope. These are merely numbers that
are dialed for access to certain providers.

	Dave Oran said that given that this is a listing service, we 
don't need number portability, if someone defines his own zone.

	Patrik replied that in order to port, the ported-from domain
simply places an NS record pointing to the new name server, in whose
zone there is the listing service for the number. There can be complete
separation between the location of the NS information, the NAPTR information,
the SRV information, and the DNS resolution information.

	Scott Petrack strongly suggested that everyone read the complete
definition of the 4 resource records used in Patrik's draft, in order to
determine if they were appropriate or not.

	Anne Brown asked if it is possible to stop someone from listing a 
number for her phone number if she so desired. Patrick replied that this
is normally handled either by contractual arrangements or one-way pointers.
DNS spoofing is a "well known" problem. Scott Petrack mentioned that certain
RRs ma need to be signed. Scott Bradner said that any problem concerning
how data is provisioned into the system is out of scope.

	Scott Petrack mentioned that in the worst case where everyone 
ports a number, every number would require an NS record in the DNS. 
Dean Willis reminded us that there is both a forward and reverse look-up,
and every dialing/numbering plan has its own root.

Scott Petrack

_______________________________________________
enum mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/enum

---

From: "Albert Manfredi" <[email-masked]>
Date: Thu, 2 Dec 1999 17:10:25 -0500

> on the "right hand side of the @ sign".

One point that wasn't mentioned in the minutes. This discussion took
place at the close of the session.

As I understand it, the DNS today has a peer field to the IP address
which is an ATM End System Address (AESA). Is this so?

If this is so, then why not use that field for E.164, which is after
all already an accepted format, encapsulated by the 20-byte AESA
frame?

Now you don't have to worry about the incredibly long series of
numbers and dots to the left of an @ symbol. You simply have a third
field to search on. So a name can be mapped to an IP address and an
AESA (which incorporates E.164).

Christian Huitema brought up the question, "How do you know you have
an E.164 number?" My first answer _was_ that it is preceded by a +
symbol. But in fact, a much better answer is that the 20-byte AESA
field has an AFI (Authority and Format Identifier) byte as its first
byte, and that is used to identify E.164. There are also two other
possible formulations of the 20-byte AESA already standardized,
which could be used here as well. And potentially many more,
including possible multicast or even portable telephone numbers.
(Okay, this is outside the enum scope.)

What's wrong with this approach, given that DNS already is set up
for the AESA?

Bert
[email-masked]