RE: [Enum] Re: URI Portability

["Michael Hammer \(mhammer\)" <[e-mail]>]

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

Mike


> -----Original Message-----
> From: Stastny Richard [mailto:[e-mail]] 
> Sent: Wednesday, February 08, 2006 10:28 AM
> To: Michael Hammer (mhammer); [e-mail]; 
> [e-mail]; [e-mail]
> 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
> 
> ________________________________
> 
> Von: Michael Hammer (mhammer) [mailto:[e-mail]]
> Gesendet: Mi 08.02.2006 16:22
> An: Stastny Richard; [e-mail]; 
> [e-mail]; [e-mail]
> 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: 
> [e-mail] 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: [e-mail] [mailto:[e-mail]] 
> On Behalf 
> > Of Stastny Richard
> > Sent: Wednesday, February 08, 2006 10:01 AM
> > To: [e-mail];
> > [e-mail]; [e-mail]
> > 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:[e-mail] 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:[e-mail]), 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 
> > >[e-mail] or [e-mail].
> >
> > I agree in principal, but we have to distinguish between to cases 
> > here:
> >
> >
> > 1. sip:[e-mail] can be compared your company extension 
> > with DDI I have eg [phone] 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 [phone] belongs to OeFEG.
> > Same with acme-sip.com
> > [phone] 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:[e-mail]
> >
> > 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:[e-mail] ===> 
> > 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:[e-mail] 
> > <mailto:[e-mail]> ]
> > Sent: Tuesday, February 07, 2006 12:50 PM
> > To: Stafford, Matthew
> > Cc: [e-mail]; [e-mail]
> > 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:[e-mail] to
> > >sip:[e-mail]. 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:[e-mail] 
> 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: [e-mail] im Auftrag von Stafford, Matthew
> > Gesendet: Di 07.02.2006 19:20
> > An: Tony Rutkowski
> > Cc: [e-mail]; [e-mail]
> > 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:[e-mail] to sip:[e-mail].
> > 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:[e-mail] 
> > <mailto:[e-mail]> ]
> > Sent: Sunday, February 05, 2006 10:42 AM
> > To: lconroy; Stafford, Matthew; Otmar Lendl
> > Cc: [e-mail]; [e-mail]
> > 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
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/enum
> >
> >
> > _______________________________________________
> > enum mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/enum
> >
> 

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