RE: [Enum] Re: URI Portability

Tim Ruiz <tim@godaddy.com> Wed, 08 February 2006 18:06 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6tiQ-0005GY-JS; Wed, 08 Feb 2006 13:06:54 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6tiN-0005FA-GA for enum@megatron.ietf.org; Wed, 08 Feb 2006 13:06:53 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17104 for <enum@ietf.org>; Wed, 8 Feb 2006 13:05:00 -0500 (EST)
Received: from smtpout06-01.prod.mesa1.secureserver.net ([64.202.165.224] helo=smtpout06-03.prod.mesa1.secureserver.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F6tuq-0007A7-OF for enum@ietf.org; Wed, 08 Feb 2006 13:19:45 -0500
Received: (qmail 24046 invoked from network); 8 Feb 2006 18:06:29 -0000
Received: from unknown (HELO gem-wbe06.prod.mesa1.secureserver.net) (64.202.189.38) by smtpout06-03.prod.mesa1.secureserver.net with SMTP; 8 Feb 2006 18:06:29 -0000
Received: (qmail 25510 invoked by uid 99); 8 Feb 2006 18:06:29 -0000
Date: Wed, 08 Feb 2006 11:06:29 -0700
From: Tim Ruiz <tim@godaddy.com>
Subject: RE: [Enum] Re: URI Portability
To: Stastny Richard <Richard.Stastny@oefeg.at>
Message-ID: <20060208110629.4a871ae7d05d2c98d9abb595d392cd69.5c51fef7ac.wbe@email.email.secureserver.net>
MIME-Version: 1.0
Content-Type: TEXT/plain; CHARSET="US-ASCII"
X-Originating-IP: 12.215.195.100
X-Spam-Score: 3.1 (+++)
X-Scan-Signature: b5299d0955d21ceeb18e25a232290fec
Cc: james.f.baskin@verizon.com, enum@ietf.org, "Michael Hammer (mhammer)" <mhammer@cisco.com>
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Tim Ruiz <tim@godaddy.com>
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>, <mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>, <mailto:enum-request@ietf.org?subject=subscribe>
Sender: enum-bounces@ietf.org
Errors-To: enum-bounces@ietf.org

Richard, 

So you are saying sip:richard@stastny.com must be portable, but not
sip:richard@acme-sip.com? If so, then you're done becaue the first
example is really already portable isn't it? 

  
Tim 

 
-------- Original Message --------
Subject: Re: [Enum] Re: URI Portability
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
Date: Wed, February 08, 2006 9:28 am
To: "Michael Hammer (mhammer)" <mhammer@cisco.com>,
<james.f.baskin@verizon.com>, <matthew.stafford@cingular.com>,
<enum@ietf.org>

Mike,

I agree with you. Maybe I was not perfectly clear: I do not propose
this to be implemented, I just said it could be implemented if
it is required. NP was also not invented by operators, it was
invented by regulators.

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

Richard

________________________________

Von: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]
Gesendet: Mi 08.02.2006 16:22
An: Stastny Richard; james.f.baskin@verizon.com;
matthew.stafford@cingular.com; enum@ietf.org
Betreff: RE: [Enum] Re: URI Portability



Richard,

This talk of URI portability being like number portability seems
dangerous.  The problems with number ownership in the PSTN and domain
name ownership wrt ICANN always seems a sore point.  The logical
conclusion is you go that route would seem to be to assign a national
identity, perhaps like: john-doe456@town.state.country at birth which
then begs the question can people be portable too.  Should we stamp this
on our passports too?  Then we can create yet another DNS directory UNUM
to do translations from our birth URI to our current SP URI.  :(

Please, don't go there.  It seems to have little value.  If you want to
keep a business domain name, buy a long-term lease of the name and run
your own DNS server.

I am not an ENUM guru.  Am I missing something here?

Mike


> -----Original Message-----
> From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On
> Behalf Of Stastny Richard
> Sent: Wednesday, February 08, 2006 10:01 AM
> To: james.f.baskin@verizon.com;
> matthew.stafford@cingular.com; enum@ietf.org
> Subject: [Enum] Re: URI Portability
>
> Jim Baskin sent a private comment on URI Portability to Matt
> and me, but had no objections to comment this on the list,
> which I do, because I consider this relevant:
>
> >Number portability and SIP URI portability may sound like similar
> >concepts, but there is at least one big difference.
> >Moving sip:richard@stastny.com from one provider to another may be
> >really simple, assuming that you own stastny.com and you
> have control
> >over its nameserver.
>
> Agreed
> 
> >However, if you are
> >a SIP customer of acme-sip.com (e.g., sip:richard@acme-sip.com), it
> >isn't a strictly technical issue.  It is not likely that the
> owners of
> >acme-sip.com would want their company name or its domain used by
> >someone who has a different SIP service provider.  The same issue is
> >why I don't ever expect to see email address portability for
> >somebody@aol.com or somebody-else@yahoo.com.
>
> I agree in principal, but we have to distinguish between to
> cases here:
>
>
> 1. sip:richard@acme-sip.com can be compared your company
> extension with DDI I have eg +43 1 79780 32 as office number,
> where 32 is my extension.
> It is obvious that if I change company I cannot take (port)
> this number with me, because +43 1 79780 belongs to OeFEG.
> Same with acme-sip.com
> +43 1 79780 is public, the rest is private. In the PSTN there exists
> a clear distinction between what a public telephone service
> is and what is private (corporate)
>
> 2. On the Internet this distincion is not existing, but of
> course one could be found:
>
> acme-sip.com is not providing a service for the public
> yahoo.com and aol.com is.
>
> A bored regulator could come to the conclusion at some time
> to foster competition and require URI portability vor public SIP URIs.
>
> First every SIP service provider would rant that this is
> impossible, expensive, whatever, but we had this also on the PSTN.
>
> Of course this can be implemented in the same way as it was
> implemented in the PSTN, with onward routing and/or redirect,
> with the same drawback: the donor is always involved
>
> Next step would be to standardise a DNS lookup for sip:fred@yahoo.com
>
> in something like fred.at.yahoo.com to find the current URI.
> of course there are a lot of problems, such as a certified
> from information, but this can be solved.
>
> >E.164 telephone numbers, on the other hand, don't have
> service provider
> >trademark issues.  In addition, number portability, if done with a
> >database and originating or n-1 carrier dips, takes the ported-from
> >service provider completely out of call processing for the ported
> >number.  Of course, number portability isn't "perfect" yet. 
> There are
> >still regulatory limits on what numbers can be ported where.
> 
> SIP URI portability of course must work global, an this
> will delay or prevent the idea for some time ;-)  
>
> >Oh yes, regarding Tony's statement, "The use of E.164 identifiers,
> >internationally and domestically, is subject to more statutory,
> >regulatory, national security, and industry practice
> requirements than
> >any identifier space in existence - not to mention well established
> >institutional jurisdiction."
> >That may be exactly why E.164 telephone numbers have been used so
> >successfully as a nearly seamless identifier standard providing
> >worldwide telecommunications for longer than many IETF
> participants can
> >remember.
>
> True, at least as long as we do not have global reachability
> provided by a Public User Identity in the form of a SIP AoR.
> 
> Richard
>
> >Jim Baskin
>
> =======================================
> Original messages:
>
> Richard-
> ===> What I want to have is SIP URI portability too, or in
> other words: I ===> want to have my sip URI
> sip:richard@stastny.com ===> hosted by one provider and the
> possibility to port this to another.
> No disagreement there. I guess I view these portability
> options as complementary (i.e., both useful depending on
> individual preferences).
> Thanks for the document pointers.
> Matt
> -----Original Message-----
> From: Stastny Richard [mailto:Richard.Stastny@oefeg.at
> <mailto:Richard.Stastny@oefeg.at> ]
> Sent: Tuesday, February 07, 2006 12:50 PM
> To: Stafford, Matthew
> Cc: enum@ietf.org; speermint@ietf.org
> Subject: Re: [Enum] a suggestion re: using flags to
> distinguish post-ENUM signaling f lows
>
> >The second one is (essentially) number portability. My SIP
> URI can change from sip:mstafford@provider-A.net to
> >sip:mstafford@provider-B.biz. As long as my phone number
> stays the same, it can be used to obtain my current SIP URI.
>
> What I want to have is SIP URI portability too, or in other
> words: I want to have my sip URI sip:richard@stastny.com
> hosted by one provider and the possibility to port this to another.
>
> Especially if I am a company.
> 
> For more information see the ECMA christmas wish-list
> presented today at ETSI TISPAN:
> Technical Report TR/91
> Enterprise Communication in Next Generation Corporate
> Networks (NGCN) involving Public Next Generation Networks
> (NGN) (December 2005)
> http://www.ecma-international.org/publications/files/ECMA-TR/T
> R-091.pdf
> <http://www.ecma-international.org/publications/files/ECMA-TR/
> TR-091.pdf> 
> 
> and also
> Technical Report TR/92
> Corporate Telecommunication Networks - Mobility for
> Enterprise Communications (December 2005)
> http://www.ecma-international.org/publications/files/ECMA-TR/T
> R-092.pdf
> <http://www.ecma-international.org/publications/files/ECMA-TR/
> TR-092.pdf> 
>  
> The scenarios and requirements described in these two
> documents will not be really easy to implement with NGNs ;-)
> Of course they want to have best of both sides: peering with
> each other in all variants AND in addition to be connected to
> an NGN, just to be on the safe side.
> One could also say: the overflow traffic is for the telcos
> (say max 20%)
> 
> Richard
> _______________________________
>
> Von: enum-bounces@ietf.org im Auftrag von Stafford, Matthew
> Gesendet: Di 07.02.2006 19:20
> An: Tony Rutkowski
> Cc: enum@ietf.org; speermint@ietf.org
> Betreff: RE: [Enum] a suggestion re: using flags to
> distinguish post-ENUM signaling f lows
>
> Tony- The E.164 space is a many-encumbered thing. No argument there.
>
> All the same, I see two benefits of E.164 numbers: although
> *some* mobile devices have QWERTY keyboards, many of them
> still don't. IMO a telephone number is far and away the
> easiest thing to punch into a cellphone keypad. That's the
> first one. The second one is (essentially) number
> portability. My SIP URI can change from
> sip:mstafford@provider-A.net to sip:mstafford@provider-B.biz.
> As long as my phone number stays the same, it can be used to
> obtain my current SIP URI.
>
> Best,
> Matt
>
> -----Original Message-----
> From: Tony Rutkowski [mailto:trutkowski@verisign.com
> <mailto:trutkowski@verisign.com> ]
> Sent: Sunday, February 05, 2006 10:42 AM
> To: lconroy; Stafford, Matthew; Otmar Lendl
> Cc: enum@ietf.org; speermint@ietf.org
> Subject: Re: [Enum] a suggestion re: using flags to
> distinguish post-ENUM signaling f lows
>
> Hi Lawrence,
>
> >The first is the process issue - what group (if any) coordinates
> >between the different DDDS applications and their uses; this topic
> ...
> >3761bis. It seems that your proposal is purely for Carrier/
> >Infrastructure/ Private ENUM; in this case, changing 3761 has
> >unintended consequences for Public/User ENUM applications.
>
> These are great understatements.  The use of
> E.164 identifiers, internationally and
> domestically, is subject to more statutory, regulatory,
> national security, and industry practice requirements than
> any identifier space in existence - not to mention well
> established institutional jurisdiction.
>
> The following list is a current tabulation of E.164
> resolver-directory capability requirements, parsed into three
> categories, currently in play in various industry NGN forums.
>  The recently enacted EC Data Retention Directive, and the
> U.S. Prevent Cyberstalking law, add further complexity to the
> mix. ;-)
>
> best,
> --tony
>
> >basic resolver capability
> >
> >supplementary capability
> >         Number Portability
> >         Priority Access
> >         Roaming
> >         Quality of Service
> >         Directory Assistance
> >         CallerID
> >         Disability Assistance
> >         Language preference
> >         Personal emergency (E112/911)
> >         Public emergency alerts
> >         Law enforcement assistance
> >         DoNotCall
> >         Payment Methods
> >         Intercarrier Compensation
> >         Profile Management
> >         Presence
> >         Availability
> >         Location
> >         Push Management
> >         Digital Rights Management
> >         Device Management
> >         Authentication Credentials
> >         Information verification level
> >
> >protocol feature
> >         Authentication
> >         Auditing
> >         Multiple Syntax Support
> >         Mutiple Language Support
> >         Extensibility and Localisation Mechanisms
> enum mailing list
> enum@ietf.org
> https://www1.ietf.org/mailman/listinfo/enum
>
>
> _______________________________________________
> enum mailing list
> enum@ietf.org
> https://www1.ietf.org/mailman/listinfo/enum
>



_______________________________________________
enum mailing list
enum@ietf.org
https://www1.ietf.org/mailman/listinfo/enum 


_______________________________________________
enum mailing list
enum@ietf.org
https://www1.ietf.org/mailman/listinfo/enum