Subject: RE: [Enum] Re: URI Portability

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 8 Feb 2006 10:22:55 -0500

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: [email-masked] 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: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Stastny Richard
> Sent: Wednesday, February 08, 2006 10:01 AM
> To: [email-masked]; 
> [email-masked]; [email-masked]
> 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:[email-masked] 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:[email-masked]), 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 
> >[email-masked] or [email-masked].
> 
> I agree in principal, but we have to distinguish between to 
> cases here:
> 
> 
> 1. sip:[email-masked] 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:[email-masked]
> 
> 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:[email-masked] ===> 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:[email-masked] 
> <mailto:[email-masked]> ]
> Sent: Tuesday, February 07, 2006 12:50 PM
> To: Stafford, Matthew
> Cc: [email-masked]; [email-masked]
> 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:[email-masked] to 
> >sip:[email-masked]. 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:[email-masked] 
> 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: [email-masked] im Auftrag von Stafford, Matthew
> Gesendet: Di 07.02.2006 19:20
> An: Tony Rutkowski
> Cc: [email-masked]; [email-masked]
> 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:[email-masked] to sip:[email-masked]. 
> 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:[email-masked] 
> <mailto:[email-masked]> ]
> Sent: Sunday, February 05, 2006 10:42 AM
> To: lconroy; Stafford, Matthew; Otmar Lendl
> Cc: [email-masked]; [email-masked]
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/enum
> 
> 
> _______________________________________________
> 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: "Stastny Richard" <[email-masked]>
Date: Wed, 8 Feb 2006 16:28:18 +0100

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:[email-masked]]
Gesendet: Mi 08.02.2006 16:22
An: Stastny Richard; [email-masked]; [email-masked]; [email-masked]
Betreff: RE: [Enum] Re: URI Portability

Richard,

Mike

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 8 Feb 2006 10:32:34 -0500

Never tell regulators something is possible, it will just become a new
career opportunity. :)

Mike

> From: Stastny Richard [mailto:[email-masked]] 
> Sent: Wednesday, February 08, 2006 10:28 AM
> To: Michael Hammer (mhammer); [email-masked]; 
> Subject: Re: [Enum] Re: URI Portability
> 
> 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
> 
> An: Stastny Richard; [email-masked]; 
> 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: 
> [email-masked] 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.
> 
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of Stastny Richard
> > 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:
> >
> > I agree in principal, but we have to distinguish between to cases 
> > here:
> >
> >
> > 1. sip:[email-masked] 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
> > a clear distinction between what a public telephone service is and 
> > what is private (corporate)
> >
> yahoo.com and 
> > aol.com is.
> to foster 
> > competition and require URI portability vor public SIP URIs.
> >
> impossible, 
> > expensive, whatever, but we had this also on the PSTN.
> >
> > implemented in the PSTN, with onward routing and/or 
> redirect, with the 
> > same drawback: the donor is always involved
> >
> > of course there are a lot of problems, such as a certified from 
> > information, but this can be solved.
> >
> established 
> > 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
> >
> > ===> What I want to have is SIP URI portability too, or in other 
> > words: I ===> want to have my sip URI sip:[email-masked] ===> 
> > No disagreement there. I guess I view these portability options as 
> > complementary (i.e., both useful depending on individual 
> preferences).
> > Subject: Re: [Enum] a suggestion re: using flags to distinguish 
> > post-ENUM signaling f lows
> >
> hosted by one 
> > provider and the possibility to port this to another.
> >
> Networks (NGCN) 
> > involving Public Next Generation Networks
> > (NGN) (December 2005)
> > Corporate Telecommunication Networks - Mobility for Enterprise 
> > Communications (December 2005) 
> 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
> > Betreff: RE: [Enum] a suggestion re: using flags to distinguish 
> > post-ENUM signaling f lows
> >
> 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 
> > As long as my phone number stays the same, it can be used 
> to obtain my 
> > current SIP URI.
> >
> > Best,
> > Matt
> >
> > Subject: Re: [Enum] a suggestion re: using flags to distinguish 
> > post-ENUM signaling f lows
> >
> > Hi Lawrence,
> >
> > 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.
> >
> 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
> >

---

From: Tim Ruiz <[email-masked]>
Date: Wed, 08 Feb 2006 11:06:29 -0700

Richard, 

So you are saying sip:[email-masked] must be portable, but not
sip:[email-masked]? 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" <[email-masked]>
Date: Wed, February 08, 2006 9:28 am
To: "Michael Hammer (mhammer)" <[email-masked]>,
<[email-masked]>, <[email-masked]>,
<[email-masked]>

Mike,

Richard

Richard,

Mike

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 8 Feb 2006 14:38:25 -0500

Maybe, but that doesn't scale globally.  
Heck, I couldn't even get my own name within Comcast domain.

My solution is to just not use letter head or print too many business
cards. :)

Mike

> From: Richard Shockey [mailto:[email-masked]] 
> Sent: Wednesday, February 08, 2006 2:32 PM
> To: Michael Hammer (mhammer)
> Cc: Otmar Lendl; [email-masked]
> Michael Hammer (mhammer) wrote:
> > Otmar,
> > 
> > What do you think are the chances of my getting the 
> [email-masked], 
> > hammer.net, hammer.org, ... domain name?
> > 
> > The problem is only shifted.
> 
> 
> well actually mikehammer.us is available  :-)
> 
> > 
> > Mike
> >  
> > 
> 
> -- 
> 
> 
>  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> Richard Shockey, Director - Member of Technical Staff NeuStar Inc.
> 46000 Center Oak Plaza  -   Sterling, VA  20166
> sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
> ENUM +87810-13313-31331
> PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
> Fax: +1 815.333.1237
> <mailto:richard(at)shockey.us> or
> <mailto:richard.shockey(at)neustar.biz>
> <http://www.neustar.biz> ; <http://www.enum.org> 
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>