Subject: RE: [Enum] NITS review of draft-ietf-enum-infrastructure-03

From: "Antoin Verschuren" <[email-masked]>
Date: Fri, 5 Jan 2007 16:02:26 +0100

Richard Shockey wrote:
> The simple truth is you don't need to put I-ENUM in the public DNS
> and I still can't understand why anyone would.

I can.
I can imagine a service where the authorisation to interconnect is
embeded in a device or software, not the network.
Supose I buy that service from Provider A who is a member of federation
A.
Now I want to use this device while I'm connected to the network of
provider B (and paying for it) who is not part of federation A or any
federation.
This means I need to query the tree and find out which interconnection
point of federation A is closest/fastest/most efficient for me to use. I
do not want to first go to provider A's network to find that out, when
my interconnection point might be my neighbour. I also don't want
povider B to selectively block this service for me.
If provider A and provider B both share this concept, than why should it
be forbidden ?
It's all a question of whether you want to have these end-to-end
devices, or that you want the network you're connected to to decide
which services you can use and how.
Some incumbants might want to keep I-ENUM closed, and then we need a 3th
ENUM tree for the providers that don't :-(
This closed version is called private ENUM.
The public DNS version is called Infrastructure ENUM, by definition.

> Carrier Interconnection is a function of trusted Registry
> Infrastructures and the Policies associated with those Registries not
> the access method to the data.

The interconnection might be in a trusted enviroment between certain
peers, but not the discovery of where the peer is to try to
interconnect, as this query might come from an unknown network.
This model will allow providers to open or close their network for
interconnection at their own insight, not forcing it.

> This IMHO this news out of the UK actually good news, hopefully it
> will bring some folks to their senses especially about that bizarre
> CREW idea floating around over there.

IMHO, the privacy considerations we should discuss in infrastructure
ENUM is that a provider is only allowed to publish NAPTR data that is
nessecary to service the service he sold the customer in relation to his
phonenumber.
Or to put it in simple words, I don't want my provider to publish my
email address, website or business card if I only bought a voice service
from him. So we should somehow define that in infrastructure ENUM, only
those records are allowed to be published that are nessecary to route
the service I bought. Perhaps only SIP ? Don't know, but I do know
that's what the discussion should be about, and how to phrase that.

Antoin Verschuren

Technical Advisor
Policy & Business Development
SIDN
Utrechtseweg 310
PO Box 5022
6802 EA Arnhem
The Netherlands

T +31 26 3525510
F +31 26 3525505
M +31 6 23368970
E [email-masked]
W http://www.sidn.nl/

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

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 5 Jan 2007 11:02:11 -0500

But the very definition of I-ENUM is service provider to service provider
interface not a User to Network interface.

If it SP to SP then the set of users is sufficiently small to permit various
forms of private data exchanges outside the scope of the DNS.

Everything else is better dealt with in User ENUM.

Simply because delegations in e164.arpa have not taken off as expected does
not mean that everyone has to try and fit every square peg into the round
hole of e164.arpa to economically justify its existence.

> -----Original Message-----
> From: Antoin Verschuren [mailto:[email-masked]]
> Sent: Friday, January 05, 2007 10:02 AM
> To: [email-masked]
> Subject: RE: [Enum] NITS review of draft-ietf-enum-infrastructure-03
> 
> Richard Shockey wrote: