You are here: Home > Participate > Join a Discussion > Mailman Archives
<<< Chronological >>> Author Index    Subject Index <<< Threads >>>

AW: RE : New number ranges for E.164

  • To: < >
    < >
    < >
    < >
    < >
    < >
    < >
  • From: "Stastny Richard" < >
  • Date: Sat, 28 Feb 2004 14:10:03 +0100

Yes and no, Olivier
 
1. It is true that in the old days phone numbers have been properties of the phone
service providers, but since the introduction of number portability this has changed.
 
The block assignement still used in many countries is there mainly for technical reasons,
eg onward-routing. In principle one could assign all phone numbers first to the end-users and
then let the customer choose a provider, in the same way it is done for service numbers.
 
2. It is also true that SIM cards are always tied to a single service provider, but this
is because the IMSI is linked by definition (MCC MNC) to the provider. The SIM
card is the replacement for userID/PW, which is always linked to a provider like a RADIUS realm
 
The E.164 number is linked to the IMSI later. So again, if you port your E.164 mobile
number to another operator, you keep the number, but you have to change the IMSI (Sim Card)
 
This is like transferring a domain from one hosting service to another: you keep the domain,
because you hold it, but you change the UserID/PW to access the hosting service.
 
IP Communications are implemented the same way: if you change your SIP SP, you change
the userId/PW (and in most cases your SIP URI ,-), but not the E.164 number.
 
BTW thats one of the advantages of E.164: SIP and mailto URIs are normally not portable,
(except e.g stastny.com;-), E.164 numbers are.
 
regards
Richard

	-----Ursprüngliche Nachricht----- 
	Von: Olivier.Girard@localhost [
] Gesendet: Sa 28.02.2004 13:48 An: ag@localhost Stastny Richard Cc: enum-trials@localhost jseng@localhost enum-l@localhost jim@localhost enum-trial@localhost Olivier.Girard@localhost Betreff: RE : New number ranges for E.164 Adrian, Sorry, I don't agree with you at all, except on your first paragraph: >> The end goal as far as I can see it is the convergence of PSTN and >> INTERNET into Next Generation Networks. Regardless of how we will call >> the end-result of this integration, it means that all sides must adjust >> to the changes. Changes are reflected in addressing schemes, billing >> mechanisms, regulatory and many other issues. Today, E.164 numbers are the quasi property of telephony service providers who allocated them to their own customer. As far as I can remember, ENUM has been presented as the opportunity to offer a unique identifier (the E.164 number) for multiple services. In my opinion, once a customer have been allocated an E.164 number, he should have the right (and the means) to register this number for any kind of services he wants to (services requiring such a number of course, like fix or mobile telephony, ENUM, Web based SMS/MMS, Web based fax, etc...). The use of SIM Card is a very good example. However, SIM cards are (again, like E.164 numbers) always tied on a single service provider. This prevent the enduser to use them for accessing other providers' services... All this require some radical changes in traditional telephony service providers' minds (and especially incumbents'...) and regulators' policy. Best, Olivier -----Message d'origine----- De : Adrian Georgescu [
] Envoyé : samedi, 28. février 2004 12:09 À : Stastny Richard Cc : enum-trials@localhost jseng@localhost enum-l@localhost jim@localhost enum-trial@localhost Olivier.Girard@localhost Objet : New number ranges for E.164 The end goal as far as I can see it is the convergence of PSTN and INTERNET into Next Generation Networks. Regardless of how we will call the end-result of this integration, it means that all sides must adjust to the changes. Changes are reflected in addressing schemes, billing mechanisms, regulatory and many other issues. Speaking about ENUM, it is obvious from the results presented at ETSI ENUM workshop that ENUM acts already today like glue between different technologies. Examples about how carriers now use ENUM to route messages between different technologies like GSM/CDMA in the US are a clear proof of the usefulness of ENUM in the convergence. Looking at the user side however, we hit more obstacles non-technically related, which are hard to overcome by technology itself. If in some countries ENUM is approached from a legal perspective and in others from a technical perspective we understand why the time to market in these two scenarios will never meet at the right time on a global scale. One of the ideas presented at the Workshop was the use of a dedicated number range for Voice over IP. One might object to this by saying that the current numbering plans do not allow creation of so many new numbers. But again the main purpose of ENUM is to help the convergence. The telephone numbers as we know them today will disappear on the long term and will be replaced by friendly names (email addresses, buddy names, aliases easy to remember and such). It could very well be that there is no need to plan a scheme where everyone will use an ENUM number. ENUM is a moving train and it should carry with it only what is necessary to the next station. If ENUM will stay because it brings more advantages than initially thought, it will survive and expand accordingly to the market forces. Should regulators in each country consider assigning a dedicated number range (see Japan example), there will be no need to authenticate/validate new requests. ENUM numbers will be assigned on the basis of first asked/first served the same way like Internet Domain Names. Using established procedures existing already in each country for the Domain Names could do the transfers or canceling of numbers. We aim for maintaining the E164 space consistent as Richard mentioned and other achievable goals that will appear in our sight. This would not solve all issues but is clearly a non-blocking start for everyone to jump in the ENUM train. regards Adrian On 28 Feb 2004, at 11:20, Stastny Richard wrote: > I fully agree with Olivier: > > We have here two complete separate problems: > > 1. Identification required to get an E.164 number. > This is a problem that has nothing to do with ENUM and should be kept > completely separate. That prepaid cards are given out in some (most) > countries without proper id is NOT an ENUM problem. > > If some legal entity wants to get the identification of a person or > entity assigned > an E.164 number, it should use the existing infrastructure. This is > also holds if they > want to know the identity holding an e164.arpa domain related to this > number if > no contact information is available. > > ENUM is not here to solve OPPs (Other People Problems) > > 2. The only thing that ENUM needs to provide is consistency in the > E.164 name space, that is: a e614.arpa domain shall only be delegated > if and only for the period of time the associated E.164 number is > assigned to > a person or entity and it shall be delegated to the SAME person or > entity. > > As Olivier shows this does not necessarily require to reveal the > entity of the person, > especially not on mobile phone if you use the access to the > identification token > (e.g a SIM-card), but there ara also possibilities for fixed lines. > > For regulators, they should only state the requirement and not the > procedure > how to do this, because you can do this in many different ways. They > will of course > have the right to check a given procedure if it complies to the > requirement given. > > 3. In case of ENUM-only numbers the validation problem is not > existent, because > the domain in e164.arpa IS the E.164 number, so there is consistency > in the > name space per default. The identification problem remains, > but has to be solved at least nationally equivalent to other number > ranges, especially mobiles. > If it is allowed to have anonymous number usage there, it must also be > allowed to have > it here. So this is a national problem. Because it cannot be quod > licet Jovi, not licet bovi ;-) > > Last note: this does not hinder anybody wanting to give his identity > to either an > ENUM contact info or a phone directory. In case of ENUM-only numbers > the > normal procedure like with all other numebrs could apply (e.g entry in > phone book > and possibility to opt-out) > > regards > Richard > > -----Ursprüngliche Nachricht----- > Von: Olivier.Girard@localhost > [
] > Gesendet: Sa 28.02.2004 10:24 > An: jim@localhost Olivier.Girard@localhost > Cc: ag@localhost jseng@localhost enum-l@localhost > enum-trials@localhost enum-trial@localhost > Betreff: RE : RE : data point - anonymous E.164 number usage > > > > >> As you say, it's proving that this entity has the right to use a > given > E.164 number > >> is what matters. Unfortunately that usually means identifying this > entity... :-) > > Not sure Jim... > > If the allocation of an E.164 number to XYZ is accompanied with a > validation > piece (password, certificate, digsig key or whatever it is...) which > becomes > invalid as soon as XYZ is not anymore owner of the number and that > this > piece is checked every time XYZ want to use her/his number in > relation to a > service (not only ENUM but every service which require the use of an > E.164 > number), then you do not need to identify the person. In that case > you have > only to check if the validation piece is valid. > > This, of course, needs a review of the E.164 number allocation policy > which > is national matter... > > In my opinion, we should focus on a generic solution (not only > related to > ENUM). > > Today, I can use my mobile number to register for a web based SMS > service > which offers me to send SMS from the web keeping my mobile number (it > works > also with anonymous prepaid!). The registration check is made via SMS > (you > get a "validation" password via SMS). The problem is: when I cease the > contract with my mobile operator I can continue to send SMS using my > old > mobile number. Of course I can not get any reply to the SMS I have > sent > because the number is not allocated anymore (unless the associated > ENUM > Domain & NAPTR remain active after the E.164 number has been > deactivated... > ;o) ) > > In my opinion, there are two critical things: > 1 - the point where an E.164 number is registered for a service (it > can be > ENUM, SMS, etc... but also telephony) > 2 - the point where an E.164 number is not used anymore by the user > and > given back to the "allocator" (at this time, all registrations made > with > this number must be cancelled. For this, it is necessary that all > service > providers who have a relationship with the number be informed > accordingly or > that all those service providers make a periodic check of the > validation > piece. > > Is it a way to work on ? > > > -----Message d'origine----- > De : Jim Reid [
] > Envoyé : vendredi, 27. février 2004 23:43 > À : Olivier.Girard@localhost > Cc : ag@localhost jseng@localhost enum-l@localhost > enum-trials@localhost enum-trial@localhost > Objet : Re: RE : data point - anonymous E.164 number usage > > > >>>>> "Olivier" == Olivier Girard <Olivier.Girard@localhost > >>>>> writes: > > Olivier> Dear All, I think we should make a difference here. In my > Olivier> opinion, the interest of validation in ENUM is not to > Olivier> know WHO is owner of an E.164 number or WHO has the right > Olivier> to use an ENUM domain name. The role of ENUM validation > Olivier> is primarily the ensure that only the one who has the > Olivier> right to use an E.164 number can use the associated ENUM > Olivier> domain name. Nothing more. > > Absolutely! There is a very subtle but important difference here and > you're > right to underline it. > > I think we're all guilty of being too loose with our terminology and > confusing identity with authentication and/or validation. The > identity of > whatever it is that registers an E.164 number shouldn't matter. As > you say, > it's proving that this entity has the right to use a given E.164 > number is > what matters. Unfortunately that usually means identifying this > entity... > :-) > > > >

  • Post To The List:
<<< Chronological >>> Author    Subject <<< Threads >>>