Subject: RE: [Enum] RE: ENUM Part of Call Setup (Was: Implementer's dilemm a)

From: "Stastny, Richard" <[email-masked]>
Date: Thu, 21 Feb 2002 15:59:34 +0100

Did someone actually make the case that ENUM is "call setup"? 
> I'd appreciate
> a pointer to the item in the archive. Did someone discuss how 
> they plan to
> implement LI in ENUM? Ditto.

If you look at the presentation from Robert Khello, Ericsson at the ENUM
Workshop held in Copenhagen by ERO/ETO www.eto.dk , you will see on page 6
and 7 that the ENUM query is done by the MMS Application Server in the
network. Although the exaples are for messaging, the same applies also for
Voice calls, as he confirmed. If the network is doing the ENUM query and not
the user client, it is done IMHO during the call setup from the user pont of
view.

Two statements from the contribution of China 011-Q1 to the January SG2
meeting on: DISCUSSION ON ESTABLISHING A TLD SPECIAL FOR ENUM
IMPLEMENTATION:

Quote1: In practice, ENUM is a framework making use of Internet DNS for
providing SCP-like function used in circuit-switching network. End Quote1

Quote2: With the development of ENUM, the amount of domain name resolution
will be very large.  However, voice communication requires high real time
performance.  The speed of resolution will be a key aspect for ENUM
development.  Speeding up the resolution will be propitious to the
development of ENUM. End Quote2.

During the discussion, China argued that they consider to use ENUM within
their telephony network during call setup, and that it is therefore very
important to reduce the call setup delay by having the ENUM Root in a TLD
and not in a SLD. (No, I do not want to comment this, but it was nice to
watch Patrik's and Jim's faces when China explained to them how the root
server network works).

Regarding LI: of course I know, that you cannot LI an DNS query, but I have
seen the term on so-called Issues with ENUM List. I also got the question
from a regulator, if it is possuble to block the access to ENUM, or to parts
of ENUM.

You should be aware, that currently a lot of people out there, who are
discussing very seriously about ENUM, have no idea how the Internet, SIP or
DNS works (not to talk about the DDDS drafts, they gave me an headache ;-)

PS: Eric, I send you the above mentioned documents with separate e-mail.

Richard STASTNY
OeFEG
Arsenal Objekt 24
P.O. Box 147
A-1103 Vienna, Austria

Tel: +43 664 420 4100
Fax: +43 1 79780 13
[email-masked]
[email-masked]

> -----Original Message-----
> From: Eric Brunner-Williams in Portland Maine
> [mailto:[email-masked]]
> Sent: Thursday, February 21, 2002 3:24 PM
> To: Stastny, Richard
> Cc: 'Christian Huitema'; [email-masked]; [email-masked]
> Subject: Re: [Enum] RE: ENUM Part of Call Setup (Was: Implementer's
> dilemma) 
> 
> 
> My head hurts.
> 
> > This is VERY important in legal context and also related to 
> the technical
> > requirements. Regarding the legal context, if ENUM is NOT 
> PART of the call
> > setup, it is not part of eventually regulated voice calls, 
> there is no
> > requiremnt of LI, etc. Technically it is not part of the telephony
> > infrastructure and therefore ITU-T E.105 is not relevant.
> 
> Somewhere there is an instance of bind, responding to 
> queries. The data the
> instance of bind uses has a temporal property (TTL value). 
> While valid, two
> temporally distinct identical queries yeild identical 
> responses. During the
> intervening temporal period the network fabric between the 
> resolver and the
> mapped address could have partitioned.
> 
> Resolution may be successfully accomplished, even if there is 
> no route to
> host.
> 
> One of the aspects of one of the "keyword" or "alternate 
> root" offerings
> made elsewhere (not on this list) that interested me was the 
> similarity
> between interposition (on the dns) and legal intercept.
> 
> In the vendor case I became familiar with, a UA formed a 
> string (with infix
> dots), heuristics concerning the string (terminating 
> dot-bounded substring
> value) caused the UA to (eventually) serially query 
> responders located at
> the vendor-partners facilities in three North American sites, 
> not the M root
> server, which is more proximal.
> 
> The "intercept" occurred at the UA/resolver interface, in the 
> form of query
> modification with redirection, rather than query replication 
> with redirection. 
> The interested can read rfc2804 for the technical critique of 
> interposition
> and related complexity and access model issues. It also 
> occurred at the set
> of query responders
> 
> I fail to see how resolution (ENUM) is part of transport (call setup).
> 
> I fail to see how legal intercept (query replication and/or 
> redirection)
> can be implemented outside of the resolver or nameserver, if 
> the lookup
> function (dns queries) are within the scope for intercept.
> 
> Did someone actually make the case that ENUM is "call setup"? 
> I'd appreciate
> a pointer to the item in the archive. Did someone discuss how 
> they plan to
> implement LI in ENUM? Ditto.
> 
> Eric
> 

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

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Thu, 21 Feb 2002 10:50:01 -0500

Richard,

> watch Patrik's and Jim's faces when China explained to them how the root

The example I mentioned was motivated by some observations I didn't include:
a bug in a UA's handling of a particular encoding, and the cost of "overseas
bandwidth". Common to each is the phenomena that every reference to the dns 
for name labels or name-label-like strings which used a generating set larger
than the well-known set of 63 distinct values would (exit the dns, but that
isn't this issue, except when card(.) != 1), and incure trans-pacific tarrif
and latency properties (this issue).

The first quote (ENUM-is-SCP) fails to appreciate generality, e.g., mailto
or avian carrier.
Its author doesn't actually say the-application-is-the-transport, only that
it is used.

The second quote could be read as bandwith/latency sensitive, not simply
as ENUM-is-setup, and adequately addressed by the deployment of secondary
servers, independent of the namespace.

The Jim is our own Jim Reid, neh? Who was the "China" explaining to he and
Patrik?

Urk. A power-point and a MSWord doc. Thanks. First time I've seen exmh say
"Very Large Message", then again, 5.88 MB means "I've got MAIL".

Thanks,
Eric

---

From: Lawrence Conroy <[email-masked]>
Date: Thu, 21 Feb 2002 16:50:12 +0000

>servers, independent of the namespace.

To which I add:
    actually, 3GPP include an allusion to ENUM in the IMS documents (TS23.228 -
a word doc, I'm afraid, so I'll let you retrieve it from ftp.3gpp.org).

This is also in the call setup procedures and is not done by the Mobile.

Thus I tend to agree with Chip; whether or not ENUM is initiated within
the call setup sequence is an applicability issue, not one for 2916.

BTW (mindful that this is an IETF list, so apologies for the 
inappropriate content):
(i) it's IP traffic so it's covered by CALEA (or RIPA over here), right?
(ii) do you really expect and answer to "how do you do it if it's 
decentralised" ?

all the best,
   Lawrence
-- 
[email-masked]: +44 1794 833666::<my opinions>:

---

From: Tony Rutkowski <[email-masked]>
Date: Thu, 21 Feb 2002 12:44:49 -0500

>(i) it's IP traffic so it's covered by CALEA (or RIPA over here), right?

Definitely by RIPA, as well as the Council resolution.

As to LI, it's definitely covered under Title 18
as modified by the Patriot Act.  As to CALEA,
probably - although Chip argues for some kind
of creative escape. :-)

--tony

---

From: Richard Shockey <[email-masked]>
Date: Thu, 21 Feb 2002 13:16:02 -0500

>This is also in the call setup procedures and is not done by the Mobile.

I've been scratching my head over this thread..... so can some one define 
what is "call setup procedures" ??? Is there some common definition here?

I've always looked at ENUM as a globally authoritive database that can 
convert a name (E.164 number) into a list of possible services. ENUM could 
be part of a set of databases or tables ( local or otherwise)  that can 
assist a network element in making a decision on how to potentially 
terminate (route or switch) a particular media stream.

How and when a look up occurs could be nearly anywhere depending on the 
network configuration and the pathway by which the media stream originates.

>BTW (mindful that this is an IETF list, so apologies for the inappropriate 
>content):

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
45980 Center Oak Plaza   Bldg 8     Sterling, VA  20166
1120 Vermont Ave NW Suite 400 Washington DC 20005
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: +1 815.333.1237
<mailto: [email-masked]> or
<mailto: [email-masked]>
<http://www.neustar.biz>
<http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: Chip Sharp <[email-masked]>
Date: Thu, 21 Feb 2002 17:08:37 -0500

http://www.wordfocus.com/word-act-blindmen.html
ENUM=elephant

I've always felt ENUM was the set of procedures and algorithms defined in RFC2916 that can be used for a multitude of applications & services.  
:-)

Chip

At 01:16 PM 2/21/2002, Richard Shockey wrote:

>I've been scratching my head over this thread..... so can some one define what is "call setup procedures" ??? Is there some common definition here?
>
>I've always looked at ENUM as a globally authoritive database that can convert a name (E.164 number) into a list of possible services. ENUM could be part of a set of databases or tables ( local or otherwise)  that can assist a network element in making a decision on how to potentially terminate (route or switch) a particular media stream.
>
>How and when a look up occurs could be nearly anywhere depending on the network configuration and the pathway by which the media stream originates.
>
>>BTW (mindful that this is an IETF list, so apologies for the inappropriate content):
>>(ii) do you really expect and answer to "how do you do it if it's decentralised" ?
>>
>>all the best,
>>  Lawrence
>>--

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 22 Feb 2002 09:25:35 +0100

> The Jim is our own Jim Reid, neh? Who was the "China" explaining to he and

I guess it is Jim Reid.

The issues China has with e164.arpa has nothing to do with ENUM, but other
more political things.

I spent quite some time with them in Geneva, and the text passed _can_ (and
I think is) blown to proportions which is not of the same scale as the
actual discussions.

China supported the use of e164.arpa and the instructions to TSB, but,
wanted an examination of locations of the root and arpa nameservers (which
is an RSAC issue). I.e. they wanted more data and experiments on impact on
doing ENUM during call setup, and I think that is fair.

"China" included people which sent in the request to RIPE NCC for
delegation of their E.164 CC, so there is support. Much more than what
readers of this list might think.

Can we go back to discuss 2916bis and relevant documents please?

    paf

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Fri, 22 Feb 2002 06:44:08 -0500

> The issues China has with e164.arpa has nothing to do with ENUM, but other

Yup. I saw their text.

> I think is) blown to proportions which is not of the same scale as the

I had that impression after reading the original, bandwidth, latency, scale,
all reasonable concerns, and not identical with foo-is-call-setup as someone
suggested.

> doing ENUM during call setup, and I think that is fair.

Yup on the RSAC issue. Data and experiments are always good, or at least
better than the alternative.

> readers of this list might think.

I started working towards feasibility and proof-of-concept in September,
with actual trials in November. The E.164 CC delegation wasn't available
so we improvised _without_ signifigance where delegations were available.

> Can we go back to discuss 2916bis and relevant documents please?

Yup. EOT.

Eric

---

From: Randy Bush <[email-masked]>
Date: Fri, 22 Feb 2002 06:35:27 -0800

> is an RSAC issue).

<pedantry> 
the location of arpa servers is _not_ an rsac, or any part of icann, issue.
</pedantry>

> delegation of their E.164 CC, so there is support.

exactly.  many countries are voting with their feet while politicians
electioneer with their keyboards.  it's amusing when one sees the larger
picture.

randy