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

From: "Anne Brown" <[email-masked]>
Date: Fri, 3 Dec 1999 10:30:42 -0500

Alfred,

In response to Christian's question "How do you know you have an E.164
number?",  a person today is expected to know the difference between a local
and an E.164 number in order to make a phone call.  In the future we, or an
application on our behalf, will be able to lookup a telephone number, given
some input information.  I would hope that an E.164 number is returned, if
the request was to a global service (i.e., not a request to a local service
or directory).  I would also hope that the user would never see the number,
but only verify the intended recipient before commencing with the session.

Regards,
Anne

-----Original Message-----
From:	Albert Manfredi [mailto:[email-masked]]
<mailto:[mailto:[email-masked]]> 
Sent:	December 02, 1999 5:10 PM
To:	Scott Petrack; enum
Subject:	RE: [Enum] Summary and Minutes of ENUM in Washington

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

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] <mailto:[email-masked]> 

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

---

From: "Albert Manfredi" <[email-masked]>
Date: Fri, 3 Dec 1999 12:01:16 -0500

Anne,

I'm not sure your response addresses Christian's concern. Maybe it
does, but I took it differently.

To me, the question is "how does a host send a DNS request, with an
E.164 telephone number in it, in such a way that the DNS knows that
the number is in fact E.164?" To understand the question, it was one
reaction to my suggestion of making the E.164 number a field that is
_peer_ to the IP address. Not part of an IP name, as has been
proposed here.

Since I believe that the 20-byte AESA field already exists in the
DNS database format, I also believe that the answer to Christian's
concern should be quite elegant. When you request a resolution of an
E.164 number, the field used in the request is the AESA field. The
number is encoded as an encapsulated E.164 address, the AFI byte up
front is set to 0x45, and there is no ambiguity. And this is
expandable in the future.

In other words, this is a different scheme from the one discussed in
DC. Telephone numbers get their own field, using the field allocated
now to AESAs.

Bert
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Anne Brown
Sent: Friday, December 03, 1999 10:31 AM
To: 'ENUM'
Subject: FW: [Enum] Summary and Minutes of ENUM in Washington

Alfred,
In response to Christian's question "How do you know you have an
E.164 number?",  a person today is expected to know the difference
between a local and an E.164 number in order to make a phone call.
In the future we, or an application on our behalf, will be able to
lookup a telephone number, given some input information.  I would
hope that an E.164 number is returned, if the request was to a
global service (i.e., not a request to a local service or
directory).  I would also hope that the user would never see the
number, but only verify the intended recipient before commencing
with the session.
Regards,
Anne
-----Original Message-----
From:   Albert Manfredi [mailto:[email-masked]]
Sent:   December 02, 1999 5:10 PM
To:     Scott Petrack; enum
Subject:        RE: [Enum] Summary and Minutes of ENUM in Washington
> 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]

[email-masked]

[email-masked]

---

From: Christian Huitema <[email-masked]>
Date: Fri, 03 Dec 1999 16:35:50 -0500

Alfred,

I am afraid that you are mixing several elements of the DNS systems. I was not
really aware of the 20 byte AESA field, and I don't know whether there is more
than minimal experimental use of it.  In any case, AESA provides an encoding
for records, not for names, much like the A record encodes the IP addresses.
The names themselves are encoded as sequences of tokens, usually represented in
txt forms such as "a.b.c.com". 

My remark was that most users don't know that they are using E.164. They never
heard of that standard. They are most likely to use the locally defined dialing
plan to which they are used. If I designed a mapping system, I would make damn
sure that it could be parameterized with a local dial plan. For example, if I
have to map "#699 4267" (a valid number in our own plan), I woul probably map
it to something like "7.6.2.4.9.9.6.#.local-dial-plan.telcordia.com" and I
would then use "Non-Terminal DNS Name Redirection" (RFC 2672) to redirect
branches of that subtree towards other subtrees, some of which could be
definitions of "plain e.164."

In fact, an "e.164" tree does not need to contain much more than a list of
country codes pointing to various national subtrees. This allows for easy
management, delegation, etc. And it does not mandate that we have a single
root!
-- Christian Huitema

---

From: Richard Shockey <[email-masked]>
Date: Fri, 03 Dec 1999 16:17:44 -0600

>management, delegation, etc. And it does not mandate that we have a single

And that can be easily cashed locally.

Christian .. I did notice on the main IETF list you've pointed out some 
interesting statistics on DNS performance based on some monitoring of your 
local workstation.

I hate to ask ..but do you have any thoughts on possible DNS performance 
expectations with ENUM in the picture above and beyond the 20% re 
transmission rates you experienced ?

Richard Shockey
Shockey Consulting LLC
8045 Big Bend Blvd. Suite 110
St. Louis, MO 63119
Voice 314.918.9020
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : [email-masked]
GSTN Fax 314.918.9015
MediaGate iPost VoiceMail and Fax 800.260.4464
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: Christian Huitema <[email-masked]>
Date: Mon, 06 Dec 1999 10:12:45 -0500

>transmission rates you experienced ?

Basically, good design + improved quality of the DNS service. Good design
means a structure that maximises the value of caching -- i.e. rather
hierarchical than flat. It also means a structure that facilitates
management, i.e. a structure in which local information is kept and updated
locally.

There is no question however that the performance issue is important.  I
have no proof that my measurements are representative of the current state
of the Internet, albeit a couple of private replies pointed to very similar
performance data acquired at other locations. If that is the case, then we
can expect today a failure rate of 3 to 6% for any "request-response"
Internet-wide transaction. Note that this failure rate would not be
specific to the DNS. There would be similar failures for any transaction
based protocol, such as for example LDAP over UDP. And don't say that we
should just use TCP -- the initial SYN exchange of TCP would experience the
same loss rate as UDP, and, if the TCP connection actually carries isolated
transactions, these transactions would also be repeated, at the TCP level,
with performances that would not be very different from UDP.

The transaction failure rate implies that we should minimize the number of
transactions that are required in order to resolve a phone number, and that
we should prefer local transactions with a local server over Internet-wide
transactions. If we use the DNS, that means that the structure should be
amenable to easy replication and efficient caching.
-- Christian Huitema

---

From: [email-masked]
Date: Wed, 8 Dec 1999 10:04:32 +0200

Hello Christian.

Maybe I didn't understood everything what you are discussing, but anyway
why we don't use the same numbering system as in GSM network has been
widely used, so:

If the first mark, what you got from subscriber is + then follows E.164
number, otherwise it is national form. Both of format always are
available, then not necessary to know how E.164 number will be cat for
national use.

Originally this "plus" was indication about international access code
and it still on, but nowadays it could be used for this purpose too.

Question is how generate "plus" with old-fashioned telephone, but
perhaps instead of it could be used # as you maybe mentioned ? 

Kimmo Rantanen
Ericsson Finland
+358 9 2992957

---

From: "Albert Manfredi" <[email-masked]>
Date: Wed, 8 Dec 1999 10:59:42 -0500

I won't answer for Christian, but I'll offer an answer. I think that
there are too many different national numbering plans to be able to
say that anything without a "+" prefix is just a national plan. Now
you're still left with the problem of identifying which national
plan. So the + solution is only a partial solution anyway.

Also, the scheme which puts the telephone number in front of a
domain name makes the + prefix unnecessary, and greatly increases
overall flexibility. However, it also could potentially make the DNS
database considerably bigger. Which is in part why I thought
something a little more "integrated" would be nice.

Bert

> From: [email-masked]
>
> Hello Christian.
>
> > I am afraid that you are mixing several elements of the
> DNS systems. I
> was not
> > really aware of the 20 byte AESA field, and I don't
> know whether there
> is more
> > than minimal experimental use of it.  In any case, AESA
> provides an
> encoding
> > for records, not for names, much like the A record
> encodes the IP
> addresses.
> > My remark was that most users don't know that they are
> using E.164.
> They never
> > plan to which they are used. If I designed a mapping
> system, I would
> make damn
> > it to something like
> "7.6.2.4.9.9.6.#.local-dial-plan.telcordia.com"
> and I
> > branches of that subtree towards other subtrees, some
> of which could
> be
> > In fact, an "e.164" tree does not need to contain much
> more than a
> list of
> > country codes pointing to various national subtrees.
> This allows for
> easy
> > management, delegation, etc. And it does not mandate
> that we have a
> single
> > root!
> > -- Christian Huitema
> >

---

From: Christian Huitema <[email-masked]>
Date: Wed, 08 Dec 1999 17:29:12 -0500

>available, then not necessary to know how E.164 number will be cat for

There are all kinds of possible conventions, "+" being just one of them. I
would rather use conventions where they belong, i.e. in the design of the
user interface.
-- Christian Huitema

---

From: [email-masked]
Date: Mon, 13 Dec 1999 08:20:45 +0200

Hello.

Yes, I see your point, but I am just thinking how GSM works over the
world.
International number is very good e.g. in case when someone doesn't know
national/local numbering plans then one can use international plan. 

It makes easier to do some kind of mobility e.g. "fixed roaming" etc.

Anyway, I thing that everybody needs own international number or
otherwise interworking with PSTN is difficult to organize without new
"NAS" solution. Am I right ?

/Kimmo

---

From: "Albert Manfredi" <[email-masked]>
Date: Mon, 13 Dec 1999 10:20:10 -0500

I guess this is a topic for the enum WG. Specifically:

1. Should enum support direct entry of telephone numbers in national
numbering plan format within its database (e.g. within DNS), in
addition to the E.164 format, or

2. Should enum limit itself to listing numbers in E.164 format
within the DNS, and let hosts do whatever manipulation necessary to
accept local plan dialing from a user?

In my opinion, both 1 and 2 can be supported without too much
trouble, if we are willing to accommodate a potentially long list of
alternative formats for each E.164 number within the DNS (or
whatever database is ultimately selected for this). And it seems
that #1 is what the group is assuming will be the case.

Also, this decision can be made irrespective of whether the AESA
field of DNS is used, as I proposed. I think the decision is
orthogonal to this other topic.

Bert

Kimmo Rantanen wrote:

> > > > The names themselves are encoded as sequences of
> tokens, usually
> > > represented in
> > > > heard of that standard. They are most likely to use
> the locally
> > > defined dialing
> > > > sure that it could be parameterized with a local
> dial plan. For
> > > example, if I
> > > > have to map "#699 4267" (a valid number in our own
> plan), I woul
> > > probably map
> > > > it to something like
> > > > would then use "Non-Terminal DNS Name Redirection"
> (RFC 2672) to
> > > redirect