Subject: RE: [Enum] enum uri considered harmful?

From: "Stastny Richard" <[email-masked]>
Date: Mon, 2 Sep 2002 09:43:20 +0200

My dear Patrik,

I think your are on the wrong steamboat oops track ;-)

> I.e. default for E.164 processing is to do ENUM.

This is definetely NOT true for "User ENUM" in e164.arpa, although it will be true for "infrastructure ENUM" in another tree (see draft-stastny-enum-scenarios-00.txt). But there was not very much interest in the last IETF on this isssue :-(

This is for two reasons:

1. ENUM in e164.arpa is opt-in for end-users (for the called AND and also for the calling user)
2. Currently there is not a single user in ENUM, one can expect maybe 5-10% within the next 2 years.

Remark: The opt-in for the calling user implies, that it is up to the calling user if a query to "User ENUM" is made (either call-by-call or preselect similar to carrier selection). So it will NOT be possible to make an "User ENUM" query during the call-setup in any node as you assumed without the calling user knowing this. The only exception may be ENUM-only E.164 numbers, which has not been determined yet.

What you are proposing in a kind of ACQ for at least a part of the number ranges at the destination. This does only make sense if all or at least the majority of the numbers in question is in ENUM.

In "User ENUM" it will be never be possible to have all or even the majority of the numbers in ENUM for the above mentioned reason. This will only be possible in "Infrastructure ENUM" in an independant second golden tree, because there is no opt-in, so ALL numbers can be available for query on the service providers discretion.

The second tree is also required if a number is inserted by a service provider for infrastructure reason and from the end-user itself. Since the end-user is able to select his own Tier 2 Nameserver Provider in all current administrative models, you get a clash here.

Back to the enum URI:

It is obvious, that the majority of entries in the "infrastructure ENUM" tree will contain tel URIs as defined by the James Yu draft. (RN, CIC, etc). Other types of URI may come later.

The enum URI serves completely different purposes, it is IMHO mainly there for two reasons:

1. To allow the proud new ENUM customer to brag on his webpage and his e-mail signature to his friends and colleagues that he is really in the new cool service ENUM. This will also be a nice device to raise the awareness on ENUM. We will have to market and to sell ENUM and this will help.

2. to provide (again for the ENUM end-user) a simple tool to redirect one E.164 number completely with all entries to another E.164 number, without having to use constructs like CNAME.

Best regards
Richard

Richard STASTNY
OeFEG/Telekom Austria
Box 147, A-1103 Vienna, Austria
tel:+43 664 420 4100
fax:+43 1 797 80 13
mailto:[email-masked] 

> -----Original Message-----
> From: Patrik Fältström [mailto:[email-masked]] 
> Sent: Sunday, September 01, 2002 9:14 PM
> To: Lawrence Conroy; Rich
> Cc: [email-masked]
> Subject: Re: [Enum] enum uri considered harmful?
> 
> 
> --On 2002-09-01 19.44 +0100 Lawrence Conroy <[email-masked]> wrote:
> 
> > That's one big reason for my worry - we won't even try an 
> enum lookup 
> > with these existing clients, and there's no way to guess in advance 
> > what someone has sitting on their machine (unless there's 
> yet another 
> > security hole in a certain manufacturer's OS and Web Browser :).
> > 
> > Thus, I still think that we need an "enum:" URI. What am I missing?
> 
> That today ENUM lookup can be injected in the processing of 
> an E.164 number at whatever node in the network which have 
> that intelligence. I know of several implementations of IN 
> nodes which look at starting doing ENUM lookups, and several 
> SIP proxies and various gateways between PSTN and Internet 
> which also do ENUM lookups.
> 
> If a specific node which gets a destination in the form of 
> E.164 number doesn't do ENUM processing, it will forward the 
> call towards the destination according to whatever the E.164 
> routing says.
> 
> Finally, the number will reach the "destination" and a clever 
> holder of E.164 numbers (organisation which allocated the 
> number in the first place) route the call to some IN node 
> which _can_ do ENUM lookup.
> 
> I.e. default for E.164 processing is to do ENUM.
> 
> Saying in a tel URI that you do _not_ allow ENUM lookup is an 
> exception to the standard mechanism and a hint to the 
> processing. My view is that you still can not prohibit anyone 
> from doing ENUM processing (especially when you start 
> signalling using SS7 or whatever other protocol which can not 
> forward the "no" message, only the E.164 number.
> 
>    paf
> 
> _______________________________________________
> enum mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/enum
> 
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 02 Sep 2002 10:08:50 +0200

> I think your are on the wrong steamboat oops track ;-)

Possibly.

> This is definetely NOT true for "User ENUM" in e164.arpa, although it
> will be true for "infrastructure ENUM" in another tree (see
> draft-stastny-enum-scenarios-00.txt). But there was not very much
> interest in the last IETF on this isssue :-(

The discussion was about the processing of an E.164 number, not about the
registration process.

> 1. ENUM in e164.arpa is opt-in for end-users (for the called AND and also

No, not for the calling user. The calling user can not tell all involved
parties what kind of databases should be used during call setup. That is
already the case today, and will be also with ENUM. There is no way I can
tell the telcos whether they should use Informix or just MySQL databases in
their IN systems, whether number portability should be used, whether call
forwarding should be used or not.

That is a decision of the called party, and the calling party is only
requesting the call to go to the destination addressed by the E.164 number.

The opt-in which has been discussed around ENUM is only about the called
party. Whether a specific E.164 number should exists in DNS or not.

> 2. Currently there is not a single user in ENUM,
> one can expect maybe 5-10% within the next 2 years.

I don't understand what this has to do with this discussion.

> Remark: The opt-in for the calling user implies, that it is up to the
> calling user if a query to "User ENUM" is made (either call-by-call or
> preselect similar to carrier selection). So it will NOT be possible to
> make an "User ENUM" query during the call-setup in any node as you
> assumed without the calling user knowing this. The only exception may be
> ENUM-only E.164 numbers, which has not been determined yet.

See above. There is no opt-in for the calling user.

> What you are proposing in a kind of ACQ for at least a part of the number
> ranges at the destination. This does only make sense if all or at least
> the majority of the numbers in question is in ENUM.

I don't agree at all.

> In "User ENUM" it will be never be possible to have all or even the
> majority of the numbers in ENUM for the above mentioned reason. This will
> only be possible in "Infrastructure ENUM" in an independant second golden
> tree, because there is no opt-in, so ALL numbers can be available for
> query on the service providers discretion.

NXDOMAIN is a perfectly good response from DNS.

The only difference between "User ENUM" and "Infrastucture ENUM" I have
seen so far (except this mail) is whether a telco is allowed to store
_some_ information in DNS by default, and that only some (but the majority)
information (like email address, or other kind of URI schemes beside tel:),
falls under the opt-in rule.

A separate tree for people which agree on what that tree is have nothing to
do with that discussion. It is orthogonal.

> The second tree is also required if a number is inserted by a service
> provider for infrastructure reason and from the end-user itself. Since
> the end-user is able to select his own Tier 2 Nameserver Provider in all
> current administrative models, you get a clash here.

You mix up the selection of DNS provider for the NAPTR record and the telco
owning the E.164 number. Those are two different entities, and doesn't have
anything to do with each other.

> Back to the enum URI:
> 
> It is obvious, that the majority of entries in the "infrastructure ENUM"
> tree will contain tel URIs as defined by the James Yu draft. (RN, CIC,
> etc). Other types of URI may come later.
> 
> 1. To allow the proud new ENUM customer to brag on his webpage and his
> e-mail signature to his friends and colleagues that he is really in the
> new cool service ENUM. This will also be a nice device to raise the
> awareness on ENUM. We will have to market and to sell ENUM and this will
> help.

Sort of ok, BUT, I ask myself if you have ever intriduced a new URI scheme
before? It doesn't look like you have tried.

Introduction is extremely hard, if nothing else if you just look at the
software which parses URI's like all phones, web browsers and such. The
ability to add handles for URI schemes is not easy at all. So, an ENUM URI
will be completely useless before software implement the new scheme.

> 2. to provide (again for the ENUM end-user) a simple tool to redirect one
> E.164 number completely with all entries to another E.164 number, without
> having to use constructs like CNAME.

You mix up completely the ENUM database service with the database structure
(DNS) which implements the storage.

    paf