Subject: Re: [Enum] Re: URI Portability

From: [email-masked]
Date: Wed, 8 Feb 2006 12:05:51 -0500

Richard,

I must be missing something.  As far as I know, individually-owned 
or company-owned domain names ARE portable.  I can have any service 
provider run a web server for my domain.  I can have a separate 
provider handle my email.  I can have lots of providers handle lots 
of different services for me, and I can switch any particular 
service from any provider to any other at any time. 

What kind of portability isn't already implemented?  What portability 
functions are you looking for that aren't available today?

Jim

==========================
Richard Stastny wrote:

IMHO "portability" of domains held by individuals or companies
must be implemented, but not portability within domains held
by an ISP or VoIP SP such as yahoo.com or verizon.net

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

---

From: Otmar Lendl <[email-masked]>
Date: Wed, 8 Feb 2006 18:48:11 +0100

> functions are you looking for that aren't available today?

Have you ever asked one of the new SIP based VoIP outfits (Vonage,
SIPhone, Gizmo, VoIPbuster, SIPgate, ...) whether their system
copes with customers wanting to use their own domain for the
SIP URIs these services use?

I haven't seen that yet. 

The protocol support ist there, no question. But in term of
implementation we're at the level of email anno 1992 where
most people had to use user@provider as their email address.

To make things even more interesting: have a look at the the IMS and all
the other NGN efforts. From what I have heard, these people don't want
to rely on the public DNS for any of their call routing decisions. They
can easily build their own private DNS on their GRX (or whatever)
network and store the domains of the carriers in there.

I can't see how such a private DNS infrastructure can ever cope
with people wanting to user their own domains in an IMS or NGN
setting. Either you duplicate the public DNS in your walled
garden or you abandon your "never depend on the public Internet
principle".

So: There is a real chance that for the near future people will 
have no choice but use sip:user@provider as their SIP address.

I thus consider it not _that_ unlikely that regulators will
step in and force portability for such addresses.

Summary: Right now, E.164 numbers are still the primary addressing
mechanism for most SIP/VoIP services. Once that starts to change
and people start to put SIP addresses on their business cards,
then all providers MUST offer the option of using a customer-owned
domain.

Failing to support that early can spell trouble down the road.

/ol
-- 
< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >

---

From: Tony Rutkowski <[email-masked]>
Date: Thu, 16 Feb 2006 15:16:44 +0100

Dear Otmar,

Your very useful token contribution can be
usefully implemented within what seems the
universal global architecture and process
requirement for public ENUM.

Whoever is running the ENUM EPP bluebox
will generally require four tokens.

best,
tony

---

From: Otmar Lendl <[email-masked]>
Date: Tue, 21 Feb 2006 15:29:53 +0100

Hi Tony,

> will generally require four tokens.

Thank you for sharing your Authentication Architecture diagram.
Some comments/questions:

* Is this for User-ENUM?

* As I read the diagram, you plan to hold NAPTR records in your
  Tier1(b) registry. You don't plan to do "normal" delegations
  based on NS records?

* You're planning to use the data from the ENUM validation to
  feed the E.115 DBs? 

  Here in .at we had long discussions about that as well, and we
  decided against it. In our model, a new ENUM delegations contains

  o The ENUM Token which documents the ownership of the number

  and optionally

  o a domain/number owner contact object which can be set by the registrar.

  If we were to feed our data into a directory assistance DB, we'd
  use the contact object and not the info from the Token.

  For private persons that distinction may be unnecessary. For companies
  this can be an essential feature. E.g. if the numbers of all
  branch offices are managed from the headquarter: Validation is
  done through them, but you still want the local address in the
  phonebook. Or consider a holding with various brands.

* I have some difficulties understanding the roles on the left side
  of your diagram. Could you elaborate a bit on them?

* Concerning the Token from the "E.164 Service Subscriber": Is that
  one digitally signed? If yes, you need some sort of PKI. Who will
  act as the CA in that system?

* About the "referenced service provider": Are you sure you need a
  proactive agreement from that role? 

  Nobody is doing that in the email space. I can point my MX records
  to whomever I want to. I can install email forwards without
  permission from the destination. I can do SIP redirects without
  a token from the destination.

  How much will this also introduce restriction on the SIP service
  hosters? Can a Texan use a SIP provider based in Australia which
  doesn't know a thing about your system?

My plan was to get the token draft into WGLC as soon as possible
as all changes in the last 6 months were mostly cosmentic. 

I'd really like to accomodate any changes you might need. 

So: what are your requirements for the Token specs?

/ol

---

From: Tony Rutkowski <[email-masked]>
Date: Tue, 21 Feb 2006 10:37:38 -0500

Hi Otmar,

>Thank you for sharing your Authentication Architecture diagram.

The relationships are applicable wherever an E.164 number
is used in providing services to the public.  Thus it
would apply to most of the various ENUM categories.

>   Tier1(b) registry. You don't plan to do "normal" delegations

My apologies for the confusion.  The architecture
was intended to apply at all registry tiers, although
for the upper tiers, some token functions would be
null.  There was no intent in the diagram to constrain
the hierarchical structures.

I should also underscore that this is just a "thought
piece" based on an array of current developments in
different industry, security, justice, and regulatory
forums worldwide.

>* You're planning to use the data from the ENUM validation to

Yes.  This would be necessary, for example, where E.164
number blocks are allocated directly to ISPs.  It also
gets a little tricky with number portability.  You need
some kind of authoritative E.164 directory and arguably
the protocol of choice is E.115v2 because of its nice
feature set and span of legacy and IP/NGN platforms.

>   use the contact object and not the info from the Token.

I think you could do it either way, as long as the necessary
contractual agreements were put in place, and it was acceptable
by national authorities (regulatory, justice, security), including
telecom operators. :-)

>   of your diagram. Could you elaborate a bit on them?

You raise good questions, and I owe more narrative
on the diagram.  Again, it was largely to sort out
options for your very attractive token approach.

>   a token from the destination.

The new European Union Data Retention Directive will likely
alter the practices.

>   doesn't know a thing about your system?

I raised this issue in my presentation on the Directive
at ETSI three weeks ago.

>So: what are your requirements for the Token specs?

Forthcoming...

--tony