Subject: RE: [Enum] E.164 communication assumptions/requirements

From: "FOUQUART Philippe RD-CORE-ISS" <[email-masked]>
Date: Tue, 19 Jul 2005 10:38:05 -0400

Ray, Penn,

I'm not sure you're in total disagreement :-) Even for conversational services, there may be perfectly valid reasons for not making E.164 numbers reachable (customer request, barred portions of international CCs for all kinds of reasons...) so I'm not sure that in principle an E.164 number is automatically tied with reachability. 
However, most national/international numbering plans are under some pressure to accommodate all sorts of new services in a space that's already assigned for the main part (and demand may exceed supply). So there has to be criteria for making sure that public resources are assigned where they're most needed, a primary requirement being that these can be reached from PSTN/PLMN. Reachability may therefore not be a prerequisite for E.164 number assignment per se, but it is often part of a sensible numbering plan management, let alone national regulatory constraints as alluded to by Penn. 

For the ownership of an international numbering resource, I don't believe a user or anyone can claim to be the owner of a number, but I guess that's just a point of terminology. For a short 'explanation' you may have a look at principle n°5 of E.190, which along with E.164.1 sort of governs E.164 numbering ("Assignment confers use of the resource but does not imply ownership by the assignee".) For a moooore substantial discussion you may want to try http://www.ero.dk/documentation/docs/docfiles.asp?docid=1902&frames=0. It's not new but still applies to a large extent, and I would assume this absence of ownership is pretty much a constant of the numbering regulatory regimes within the EU.
Now whether we refer the "owner" or the "assignee" of the E.164 number, I don't think that impacts infrastructure/ carrier Enum.   

Hope this helps,

Philippe Fouquart 
R&D/CORE/NAS 
+33 (0) 1 45 29 58 13 

________________________________

From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of Ray Anderson
Sent: Monday, July 18, 2005 10:22 PM
To: Pfautz, Penn L, NEO; enum at ietf.org
Subject: RE: [Enum] E.164 communication assumptions/requirements

At 13:45 18/07/2005, Pfautz, Penn L, NEO wrote:

	Ray:
	We could argue about whether these are ENUM requirements.  And use of numbers within assigned E.164 country codes is largely a national matter. But at least within the United States the reachability assumption is likely to hold and use of NANP numbers for purposes such as you describe (pure DNS indexes) are likely to be discouraged by regulators. 
	 
	Penn Pfautz

I believe that some regulators will allow "free issue" of large blocks of ENUM "space" for non voice purposes

I also think that the ability to "change" your ENUM DNS records is a good clue that you "own" that number, so
it is possible to use ENUM as a way of cost effectively verifying who "owns" an E.164 number

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

---

From: "Stastny Richard" <[email-masked]>
Date: Tue, 19 Jul 2005 11:45:41 -0400

Philippe,
 
thanks for pointing out again that nobody "owns" a E.164 number
(I gave up already ;-)
the correct term is Right-of-Use (RoU), which is always used in
our national ENUM documents.
 
>Now whether we refer the "owner" or the "assignee" of the E.164 number, 
>I don't think that impacts infrastructure/ carrier Enum.  
 
Yes and no ;-)
 
Both User ENUM and Infrastructure/Carrier ENUM use the DNS and
use domain names related to E.164 numbers, and because of this these domains
are a bit different to "normal" domains, there are more like "sponsored" domains.
 
In User ENUM the domain name holder can only be the end-user having the RoU;
and only during the time he has the RoU. Note: Number Portability is NA in User
ENUM because the RoU does not change. 
The End-user is directly responsible for the contents of the domainn
 
In Carrier ENUM the domain name holder can only be the Carrier-of-Record
(see a previous posting that for the time beeing this definition is a national matter)
Note: Therefore Number Portability IS an issue in Carrier ENUM, because the
Carrier-of-Record and therefore the domain Name Holder changes.
In Carrier ENUM the end-user is only indirectly via the current Carrier-of-record
responsible for the content of the domain

-richard

Von: enum-bounces at ietf.org im Auftrag von FOUQUART Philippe RD-CORE-ISS
Gesendet: Di 19.07.2005 16:34
An: Ray Anderson; Pfautz, Penn L, NEO
Cc: enum at ietf.org
Betreff: RE: [Enum] E.164 communication assumptions/requirements

Ray, Penn,

Hope this helps,

Philippe Fouquart
R&D/CORE/NAS
+33 (0) 1 45 29 58 13

        Ray:
        
        Penn Pfautz

---

From: "FOUQUART Philippe RD-CORE-ISS" <[email-masked]>
Date: Wed, 20 Jul 2005 09:10:13 -0400

> From: Stastny Richard
> Yes and no ;-
[...]

Richard,

Thanks for the clarification, I agree, I think :-) 
What I meant was that I'm not sure the notion of owner or that of
assignee would be the appropriate one to determine what you refer to as
the Carrier-of-record. There are countries (one that I know of at
least...) where strictly speaking NP does not affect E.164 numbering
assignment whereas as you point out it should impact your
'Carrier-of-record'. 

Having said that, since NP comes in a number of different flavours, as a
work-method requirement if you like, the solution that the WG can come
up with should be kept as generic as possible in this department.
Anything that would venture into NP national specifics would be better
dealt with 'locally' IMO. And I'm not sure we want to get into some Enum
administration model thing again :-) 

Regards,

Philippe Fouquart
R&D/CORE/NAS
+33 (0) 1 45 29 58 13

-----Original Message-----
From: Stastny Richard [mailto:Richard.Stastny at oefeg.at] 
Sent: Tuesday, July 19, 2005 5:49 PM
To: FOUQUART Philippe RD-CORE-ISS
Cc: enum at ietf.org
Subject: Re: [Enum] E.164 communication assumptions/requirements

Philippe,

 
Yes and no ;-)
 
Both User ENUM and Infrastructure/Carrier ENUM use the DNS and
use domain names related to E.164 numbers, and because of this these
domains
are a bit different to "normal" domains, there are more like "sponsored"
domains.
 
In User ENUM the domain name holder can only be the end-user having the
RoU;
and only during the time he has the RoU. Note: Number Portability is NA
in User
ENUM because the RoU does not change. 
The End-user is directly responsible for the contents of the domainn
 
In Carrier ENUM the domain name holder can only be the Carrier-of-Record
(see a previous posting that for the time beeing this definition is a
national matter)
Note: Therefore Number Portability IS an issue in Carrier ENUM, because
the
Carrier-of-Record and therefore the domain Name Holder changes.
In Carrier ENUM the end-user is only indirectly via the current
Carrier-of-record
responsible for the content of the domain

-richard

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 20 Jul 2005 12:09:48 -0400

>> Valdiation in User ENUM has been discussed and solved
>> years ago,

>Validation is solved in User ENUM? I'd say at most part of it...

Agreed, most if the problems are solved, at least one can subscribe to ENUM.

I have to admit we are still not able to subscribe whales and also global
warming is not not completely solved yet ;-)

-richard

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Fri, 22 Jul 2005 16:37:22 -0400

Richard,

A conclusion from your statements below is that if the number was assigned by the national numbering authority to the carrier, and not directly to the end-user, then that number can not be in User ENUM, only in Carrier ENUM.  Was that really the intent?

Since there seems to be no mechanisms to synchronize what is going on in User ENUM from Carrier ENUM, then I would also conclude that no E.164 number can appear in both User ENUM and Carrier ENUM at the same time.  Otherwise, we get from queries to both that E.164 number belongs to both parties X and Y at the same time, i.e. calls based on each terminate to different places.  Is that correct?

I think I am missing something here.

Mike

> From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On 
> Behalf Of Stastny Richard
> Sent: Tuesday, July 19, 2005 11:49 AM
> thanks for pointing out again that nobody "owns" a E.164 
> number (I gave up already ;-) the correct term is 
> Right-of-Use (RoU), which is always used in our national ENUM 
> documents.
>  
> Both User ENUM and Infrastructure/Carrier ENUM use the DNS 
> and use domain names related to E.164 numbers, and because of 
> this these domains are a bit different to "normal" domains, 
> there are more like "sponsored" domains.
>  
> In User ENUM the domain name holder can only be the end-user 
> having the RoU; and only during the time he has the RoU. 
> Note: Number Portability is NA in User ENUM because the RoU 
> does not change. 
> In Carrier ENUM the domain name holder can only be the 
> Carrier-of-Record (see a previous posting that for the time 
> beeing this definition is a national matter)
> Note: Therefore Number Portability IS an issue in Carrier 
> ENUM, because the Carrier-of-Record and therefore the domain 
> Name Holder changes.
> In Carrier ENUM the end-user is only indirectly via the 
> current Carrier-of-record responsible for the content of the domain
> 
> -richard
>  
>  
> 
> I'm not sure you're in total disagreement :-) Even for 
> conversational services, there may be perfectly valid reasons 
> for not making E.164 numbers reachable (customer request, 
> barred portions of international CCs for all kinds of 
> reasons...) so I'm not sure that in principle an E.164 number 
> is automatically tied with reachability.
> However, most national/international numbering plans are 
> under some pressure to accommodate all sorts of new services 
> in a space that's already assigned for the main part (and 
> demand may exceed supply). So there has to be criteria for 
> making sure that public resources are assigned where they're 
> most needed, a primary requirement being that these can be 
> reached from PSTN/PLMN. Reachability may therefore not be a 
> prerequisite for E.164 number assignment per se, but it is 
> often part of a sensible numbering plan management, let alone 
> national regulatory constraints as alluded to by Penn.
> 
> For the ownership of an international numbering resource, I 
> don't believe a user or anyone can claim to be the owner of a 
> number, but I guess that's just a point of terminology. For a 
> short 'explanation' you may have a look at principle n°5 of 
> E.190, which along with E.164.1 sort of governs E.164 
> numbering ("Assignment confers use of the resource but does 
> not imply ownership by the assignee".) For a moooore 
> substantial discussion you may want to try 
> http://www.ero.dk/documentation/docs/docfiles.asp?docid=1902&f
> rames=0. It's not new but still applies to a large extent, 
> and I would assume this absence of ownership is pretty much a 
> constant of the numbering regulatory regimes within the EU.
> Now whether we refer the "owner" or the "assignee" of the 
> E.164 number, I don't think that impacts infrastructure/ 
> carrier Enum.  
> 
> Hope this helps,
> 
> Philippe Fouquart
> R&D/CORE/NAS
> +33 (0) 1 45 29 58 13
> 
> 
> 
>         We could argue about whether these are ENUM 
> requirements.  And use of numbers within assigned E.164 
> country codes is largely a national matter. But at least 
> within the United States the reachability assumption is 
> likely to hold and use of NANP numbers for purposes such as 
> you describe (pure DNS indexes) are likely to be discouraged 
> by regulators.
>         
>         Penn Pfautz
> 
> 
> I believe that some regulators will allow "free issue" of 
> large blocks of ENUM "space" for non voice purposes
> 
> I also think that the ability to "change" your ENUM DNS 
> records is a good clue that you "own" that number, so it is 
> possible to use ENUM as a way of cost effectively verifying 
> who "owns" an E.164 number
> 
>

---

From: "Stastny Richard" <[email-masked]>
Date: Mon, 25 Jul 2005 06:02:15 -0400

Michael,
 
>A conclusion from your statements below is that if the number was assigned by the national numbering authority to the >carrier, and not directly to the end-user, then that number can not be in User ENUM, only in Carrier ENUM.  Was that >really the intent?
 
I think you have a serious misunderstanding on (User) ENUM: In User ENUM an end-user may
enter all numbers he has the right-to-use (and also provided the number range is open for
ENUM with the national nubering scheme. In Austria end-users may enter all national
numbers except value-added numbers (0900) and non-E164 numbers (logically), if
he proves that he has the right-to-use this number.
 
>Since there seems to be no mechanisms to synchronize what is going on in User ENUM from Carrier ENUM, then I would >also conclude that no E.164 number can appear in both User ENUM and Carrier ENUM at the same time.  Otherwise, we >get from queries to both that E.164 number belongs to both parties X and Y at the same time, i.e. calls based on each >terminate to different places.  Is that correct?
 
No. As Rich Shockey and I pointed out many times, User ENUM and Carrier ENUM are completely
independant (orthogonal) from each other. User ENUM is for End-users (both originating
AND terminating) and Carrier ENUM is for Carriers. So the same number may (and will) show up in 
both User and Carrier ENUM. The end-user queries User ENUM, the Carrier queries Carrier ENUM.

A Carrier MAY query User ENUM on behalf of the user in addition, if the user wants
so (opt-in) and the carrier is providing this service.
 
It is correct that in this case the call may terminatate in different places if the user chooses
so. This is always the case for normal geographic numbers in user ENUM without Carrier ENUM
 
-richard

Von: Michael Hammer (mhammer) [mailto:mhammer at cisco.com]
Gesendet: Fr 22.07.2005 22:36
An: Stastny Richard; FOUQUART Philippe RD-CORE-ISS
Cc: enum at ietf.org
Betreff: RE: [Enum] E.164 communication assumptions/requirements

Richard,

Mike

> E.164 number,
> Behalf Of Ray Anderson

---

From: Ray Anderson <[email-masked]>
Date: Mon, 25 Jul 2005 09:10:13 -0400

And two more examples where piggy-backing is used extensively:
(1) You send a text message, containing a pass-code to a user, and 
piggyback on the fact that a Mobile Operator only shows it only to that 
subscriber

(2) Mobile network operators do a 1p transaction on a credit card and use 
it to validate that an over 18 year old person has therefore authorised 
that phone to be used to see "adult only" content.

In a nutshell, we want to only issue a Bango Number (a number from our 
proprietary database) to somebody who "owns" the equivalent phone 
number.  We can't use text or voice messages, because the number might not 
support either.  So, we plan to piggy-back on ENUM - relying on teh fact 
that if somebody can "fiddle" with teh ENUM DNS records, they have a lot of 
power over that number, so we give them teh Bango Number.

At 18:30 23/07/2005, Peter Williams wrote:
It will be intresting to see if this "third party reliance" (aka 
piggybacking) security practice is ever authorized, in reality. The last 3 
INTERNET infrastructures I worked in all denied this obvious practice. 
Once the infastructure player operates a branded (audited) process, the 
company will generally want any other companies who benefit from it to be 
paying for those reliance benefits....and come under the terms and 
conditions rules, etc.

If we look at other examples of switched online identity databases wth 
federated trust models and multi-provider interconnect practices:

(a) VISA will NOT let you use its accurate numbering, subscriber 
identification, privilege assignment, and switched trust system (VisaNet) 
as a way of verifying personal identity. That is, you cannot take a 1c 
visa purchase from a cardholder peter williams, and then claim you 
verified me as peter williams, with a 100k credit worthiness.

(b) VeriSign will NOT let you rely on a SSL merchant cert, and then issue 
you own cert to that website operator - claiming "well VeriSign issued a 
cert, having done due dligence concerning the right-to-use rules (ENUM 
query on a E.164 registry, DNS registration, usb.org registration, 
IANA/DARPA MIB schema organizations...), and therefore "i have verified 
that "peter.com is clearly peter.com" when listing said "verified" name in 
my own _reissued_ (i.e. non-VeriSign) cert.

(c) On the other hand, a variety of the practice is EXACTLY what many 
value added PSP providers do (in unauthorized fashion, generally) 
-  relying on the  email, paging company, or ISP provider's account 
management controls to boot up their own, independent trust model. We all 
respond to a email ping, and authenticate thereby to a new web site 
account. That is the website app relies on a third parties account 
accuracy representations when verifyng a new consumer's identity (i.e. 
those of the email service provider) when superimposing its own account 
susbcription/provisioning/publication processes.

So, if I claim to own +441223472778 I might be asked to change the email 
address in the
ENUM record to banana at bango.com   If I can do that, it is assumed I am 
"all powerful"
with respect to that number.  The whole ENUM project should be causing 
E.164 owners
to put into place varying levels of verification systems that we can 
piggyback on top of.

Ray Anderson   T:+44 7768 454545    F:+44 20 7692 5558
ray at bango.com

---

From: "James McEachern" <[email-masked]>
Date: Mon, 25 Jul 2005 23:45:18 -0400

Stastny Richard wrote:

>The end-user queries User ENUM, the Carrier queries Carrier ENUM.
>
>A Carrier MAY query User ENUM on behalf of the user in addition, if the >user wants so (opt-in) and the carrier is providing this service.
 
If the Carrier queries Carrier ENUM (and retrieves the POI for that number), and then also queries User ENUM (and receives the URI for the users mobile phone), what should the Carrier do (and why)?

If the User ENUM query returns a phone number in another country, what should the carrier do?

And finally, if the User ENUM query returns a link to a web page, what should the Carrier do?

Jim

---

From: "Stastny Richard" <[email-masked]>
Date: Tue, 26 Jul 2005 12:56:17 -0400

James,
 
let me first start with a practical example:
Assume I have an Intertex IX67 at home (or a Snom phone) 
which is capable of querying User ENUM on his own. 
 
I enter now a E.164 number and I want to make a voice call.
The IX67 find a sip URI in ENUM and the call is set up. Done

If the IX67 does not find an entry; it forward the call to a Carrier
I have a contract with and this carrier is now querying Carrier ENUM
If it find an entry. done. if not the call is routed to the PSTN
In both cases I may or may not be charged by the carrier.
 
Now assume I do not have a IX67, I just have a Sipura TA and 
a normal phone. In this case the call is directly handled by the
carrier. The cariier is only quierying Carrier ENUM by default.
 
I may now have a contract with the carrier that the carrier is querying
User ENUM FIRST on my behalf. He may charge me $5 a month for
this service, but he does not charge me for the call. The rest is as above.
 
rest inline:

>>A Carrier MAY query User ENUM on behalf of the user in addition, if the 
>>user wants so (opt-in) and the carrier is providing this service.

>If the Carrier queries Carrier ENUM (and retrieves the POI for that number), 
>and then also queries User ENUM (and receives the URI for the users mobile phone), 
>what should the Carrier do (and why)?
 
The feasable agreement would be as described above that always User ENUM is queried
first, In this case the Carrier ENUM entry would never be seen

>If the User ENUM query returns a phone number in another country, what should the carrier do?
 
This is a good point and it is not completely solved in User ENUM. Since User ENUM is also
calling user opt-in, it is basically the decision of the calling user if a PSTN number is accessed at all
 
Remember: if you dial a E.164 number and the number is not contained in ENUM, you need
to have a carrier avaiable to provide you a GW to the PSTN to complete the call and you will
be charged anyway. The problem is as you point out: you may dial a national number
and the User ENUM query returns an international number: Do you forward this number
now also to the carrier or not. The basic question here is the (undefined) user interface:
do you get a warning that the call may be more expensive?
 
In the above case you mention IMHO there has to be a prior agreement between user
and carrier how the procedure should be in such cases.
 
BTW: we had this problem in implementing the generic gateways for calls to ENUM-only
numbers from the PSTN. Since the call on the PSTN is only charged to the gateway, there
is no way to recover the additional charges from the calling party if an ENUM entry
contains a tel URI to a PSTN number. The solution was that this calls are not completed
with announcement: service not provided. It is strongle recommended to users of
ENUM-only numbers to provide a sip URI in any case.

>And finally, if the User ENUM query returns a link to a web page, what should the Carrier do?
 
Nothing. the user requested a voice call, so he may either look up carrier ENUM or if this also
does not work: "Service not available.", same if you see an ifax:mailto
Have you ever had a meaningful conversation with a fax machine on the PSTN? ;-)

Jim

---

From: "James McEachern" <[email-masked]>
Date: Tue, 26 Jul 2005 21:27:51 -0400

Richard,
Thanks for the clarification - it clears up a couple of questions that have been confusing me for a while now.  

So if I understand correctly, a carrier should never query User ENUM unless the originating user has explicitly asked the carrier to do the query on his behalf, and has also provided guidance on what to do in various situations (for example if the query returns a phone number in another country, or a "900" number).

Jim

 > Sent: Tuesday, July 26, 2005 1:00 PM
 > To: McEachern, James [CAR:5N00:EXCH]
 > Cc: enum at ietf.org

---

From: "Pfautz, Penn L, NEO" <[email-masked]>
Date: Wed, 27 Jul 2005 08:09:37 -0400

I would disagree that a carrier can't query user ENUM without explicit
consent of the originating caller. But if a carrier uses the results and
the results are funky in the ways suggested than I would expect the
carrier to eat any added cost *unless* they have some specific terms of
agreement with the originator.
Realistically, carriers are not stupid (well not entirely :-)) and would
distinguish between a SIP URL that would allow them to terminate a call
bypassing the circuit switched network and a redirecting tel URL that
would be a scam.

-----Original Message-----
From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of
James McEachern
Sent: Tuesday, July 26, 2005 9:27 PM
To: Stastny Richard
Cc: enum at ietf.org
Subject: RE: [Enum] E.164 communication assumptions/requirements

Richard,
Thanks for the clarification - it clears up a couple of questions that
have been confusing me for a while now.  

So if I understand correctly, a carrier should never query User ENUM
unless the originating user has explicitly asked the carrier to do the
query on his behalf, and has also provided guidance on what to do in
various situations (for example if the query returns a phone number in
another country, or a "900" number).

Jim

 > The feasable agreement would be as described above that always User
ENUM
 > is queried
 > >If the User ENUM query returns a phone number in another country,
what
 > should the carrier do?
 > 
 > This is a good point and it is not completely solved in User ENUM.
Since
 > User ENUM is also
 > calling user opt-in, it is basically the decision of the calling user
if
 > a PSTN number is accessed at all
 > 
 > Remember: if you dial a E.164 number and the number is not contained
in
 > ENUM, you need
 > to have a carrier avaiable to provide you a GW to the PSTN to
complete
 > the call and you will
 > and the User ENUM query returns an international number: Do you
forward
 > this number
 > now also to the carrier or not. The basic question here is the
(undefined)
 > user interface:
 > BTW: we had this problem in implementing the generic gateways for
calls
 > to ENUM-only
 > numbers from the PSTN. Since the call on the PSTN is only charged to
the
 > gateway, there
 > is no way to recover the additional charges from the calling party if
an
 > ENUM entry
 > contains a tel URI to a PSTN number. The solution was that this calls
are
 > not completed
 > with announcement: service not provided. It is strongle recommended
to
 > users of
 > >And finally, if the User ENUM query returns a link to a web page,
what
 > should the Carrier do?

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 27 Jul 2005 15:37:24 -0400

Chenhui wrote:

>I have some items need to be confirmed:
>1. Users can decide by themselves to register the ENUM information into User ENUM or Carrier ENUM
Yes for User ENUM, No for Carrier ENUM - here the Carreir decides

>2. User ENUM is separated with Carrier ENUM.
Yes

>3. There may be same ENUM numbers recorded in User ENUM and Carrier ENUM, but the NAPTR records are different, for example, I have "SIP" record in >User ENUM and "tel" record in Carrier ENUM.
Yes
 
-richard

>Thanks.
>Chenhui

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 27 Jul 2005 16:16:21 -0400

Penn, James,

Yes
 
Penn, please re-read the historic "Final Report on ENUM" of the US ITAC-T
SGA Ad-Hoc, Juli 2001, which was the basis of the US ENUM Forum

It clearly states (I think in section 3.4) that User ENUM is opt-in
BOTH for the CALLING and the called user. So the opt-in
(consent) of the subscriber is necessary to query User ENUM
 
Now there IS an interesting issue related to ENUM-only numbers
 
ENUM-only numbers cannot be in carrier ENUM per se because
there is no hosting carrier. A carrier could pretend to be stupid and
route all calls to the PSTN and charge for them.
 
Now with these numbers there is no obligation for an originating
network on the PSTN to a specific gateway, so the originating
network may directly route the call to his own gateway. This
is the whole idea of such numbers.
 
Therefore a carreir on IP  also could be "clever", pretend to be a
gateway, query User ENUM, and route the call directly
(charging for it or not)
This does not require opt-in by the calling user !!!

The originating carrier may have a list of all such numbers;
or, for convenience, carrier ENUM may contain a hint!
This is the proposed "enum:tel" Enumservice.

-richard

Von: Pfautz, Penn L, NEO [mailto:ppfautz at att.com]
Gesendet: Mi 27.07.2005 14:09
An: James McEachern; Stastny Richard
Cc: enum at ietf.org
Betreff: RE: [Enum] E.164 communication assumptions/requirements

-----Original Message-----

Richard,

Jim

ENUM
what
Since
if
in
complete
forward
(undefined)
calls
the
an
are
to
what

---

From: "Pfautz, Penn L, NEO" <[email-masked]>
Date: Wed, 27 Jul 2005 16:26:30 -0400

Richard:
The ITAC report was not as you interpret it. Opt-in for the calling
entity means there is no duty to query or to use the result if the query
is made. The originator in this clause was NOT restricted to be the end
user but could be the calling user's carrier.
-----Original Message-----
From: Stastny Richard [mailto:Richard.Stastny at oefeg.at] 
Sent: Wednesday, July 27, 2005 4:20 PM
To: Pfautz, Penn L, NEO; James McEachern
Cc: enum at ietf.org
Subject: Re: [Enum] E.164 communication assumptions/requirements

Penn, James,

Yes
 
Penn, please re-read the historic "Final Report on ENUM" of the US
ITAC-T
SGA Ad-Hoc, Juli 2001, which was the basis of the US ENUM Forum

 

-richard

-----Original Message-----

Richard,

Jim

ENUM
what
Since
if
in
complete
forward
(undefined)
calls
the
an
are
to
what

---

From: "Pfautz, Penn L, NEO" <[email-masked]>
Date: Wed, 27 Jul 2005 17:36:10 -0400

Richard,
I think the carrier can make that decision in the absence of some other
restriction. 

-----Original Message-----
From: Stastny Richard [mailto:Richard.Stastny at oefeg.at] 
Sent: Wednesday, July 27, 2005 4:57 PM
To: Pfautz, Penn L, NEO; James McEachern
Cc: enum at ietf.org
Subject: Re: [Enum] E.164 communication assumptions/requirements

Penn,
 
if you say so.
 
Nevertheless, do not forget that with ENUM calls
may terminate on the PSTN and also on IP (via ENUM)
Do you think the carrier may decide without the user
consent where to terminate the call?
 
-richard
 
------------------------------------------------------------------------

Richard:
-----Original Message-----
From: Stastny Richard [mailto:Richard.Stastny at oefeg.at
<mailto:Richard.Stastny at oefeg.at> ]
Sent: Wednesday, July 27, 2005 4:20 PM
To: Pfautz, Penn L, NEO; James McEachern
Cc: enum at ietf.org
Subject: Re: [Enum] E.164 communication assumptions/requirements

Penn, James,

Yes

-richard

Von: Pfautz, Penn L, NEO [mailto:ppfautz at att.com
<mailto:ppfautz at att.com> ]
Gesendet: Mi 27.07.2005 14:09
An: James McEachern; Stastny Richard
Cc: enum at ietf.org
Betreff: RE: [Enum] E.164 communication assumptions/requirements

-----Original Message-----
From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org
<mailto:enum-bounces at ietf.org> ] On Behalf Of
James McEachern
Sent: Tuesday, July 26, 2005 9:27 PM
To: Stastny Richard
Cc: enum at ietf.org
Subject: RE: [Enum] E.164 communication assumptions/requirements

Richard,

Jim

 > From: Stastny Richard [mailto:Richard.Stastny at oefeg.at
<mailto:Richard.Stastny at oefeg.at> ]
ENUM
what
Since
if
in
complete
forward
(undefined)
calls
the
an
are
to
what

_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum
<https://www1.ietf.org/mailman/listinfo/enum>

---

From: "James McEachern" <[email-masked]>
Date: Wed, 27 Jul 2005 18:25:00 -0400

Richard,

 > route all calls to the PSTN and charge for them.
 
I'm not sure I understand what it would mean to route an ENUM-only number to the PSTN.

Jim

---

From: "James McEachern" <[email-masked]>
Date: Wed, 27 Jul 2005 18:36:05 -0400

Penn, 
Does this extend to the Carrier being able to decide what to use when the User ENUM query returns several records?

Jim

 > From: Pfautz, Penn L, NEO [mailto:ppfautz at att.com]
 > 
 > Richard,

---

From: "Pfautz, Penn L, NEO" <[email-masked]>
Date: Wed, 27 Jul 2005 20:00:47 -0400

I'd expect so although there might some argument about records with the
same service but different preference levels. 

-----Original Message-----
From: James McEachern [mailto:jmce at nortel.com] 
Sent: Wednesday, July 27, 2005 6:35 PM
To: Pfautz, Penn L, NEO; Stastny Richard
Cc: enum at ietf.org
Subject: RE: [Enum] E.164 communication assumptions/requirements

Penn, 
Does this extend to the Carrier being able to decide what to use when
the User ENUM query returns several records?

Jim

---

From: "Fullbrook Kim \(UK\)" <[email-masked]>
Date: Thu, 28 Jul 2005 08:48:06 -0400

>> [Remember: in Europe it's sender pays all for calls to mobiles. There
>> are no charges incurring on the receiving side.]

This is not true. In all the mobile networks I know, customers roaming
in foreign countries are charged for incoming calls. (There may be some
exceptions I'm not aware of). Also, customers of O2 Germany's "Genion"
service pay charges for incoming within-Germany calls in some
circumstances.
Although probably not relevant here there are also charges for receiving
certain types of premium SMS, 

Kim Fullbrook
O2 UK

=====================================================
This electronic message contains information from O2 which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately.
=====================================================

---

From: "Pfautz, Penn L, NEO" <[email-masked]>
Date: Thu, 28 Jul 2005 09:57:47 -0400

Well, you have to go after party B's various service providers, PSTN and
ISP, which is pretty much what you have to do today. If you want to know
who's communicating with B you then must work backward with the
(court-authorized, we hope) help of B's SPs.

Of course, the people in the other 20% who use the peer-to-peer with
encryption are the ones to really worry about...

-----Original Message-----
From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of
Peter Williams
Sent: Thursday, July 28, 2005 9:42 AM
To: lendl at nic.at; enum at ietf.org
Subject: Re: [Enum] E.164 communication assumptions/requirements

>As with ENUM, the destination of a call advertises the availability of
>an alternative way of completing the call. If it's financially
beneficial
>for an originating telco to take up this offer, why should it decline
to
>do so?
>
>The only open issue here is of regulatory nature. In the example from
>above: Does Vodafone have a right to receive the call to B even if B
>told T-Com that an alternative is fine with him?
>

ok. Lets sideline the direct issue of this personal/telco profit driver,
and 
focus on the indirect infrastructure requirements that flow from such 
incentives. A ENUM convergence strategy CANNOT diminish the
effectiveness of 
current regulatory practice in such areas as wiretap:

Court C orders trap and trace and a wiretap on B, for some legitimate 
reason. How do we discover all the parties (VAR, telcos, ISPs, and ENUM 
providers) who might query ENUM (for trap and trace) or actually
complete 
the call (for wiretap), so we can present the order?

Not interested now in dealing with the 20% of folks who might use
end-end IP 
encryption, or route-hiding based on walled-garden ENUMs, or those who
hide 
secret routes in their User ENUM URLs  in the e164.arpa. Lets just focus
on 
the 80% of folks who simply subscribe to PSTN-regulated or regulated
VOIP 
carriers.

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 28 Jul 2005 15:36:29 -0400

>I'm not sure I understand what it would mean to route an ENUM-only number to the PSTN.

All E.164 numbers needs to be (should be ;-) routed on the PSTN, so an ENUM-only
number is routed to the nearest GW capable of querying ENUM.

For each such number range at least one default GW exists.
This is especially necessary if say an operator in the US
does not now or does not care that +43780xxxx is
an ENUM only range, the call still can be completed
by simply routing the call to +43

-richard

Von: James McEachern [mailto:jmce at nortel.com]
Gesendet: Do 28.07.2005 00:24
An: Stastny Richard
Cc: enum at ietf.org
Betreff: RE: [Enum] E.164 communication assumptions/requirements

Richard,

Jim

---

From: "Stastny Richard" <[email-masked]>
Date: Fri, 29 Jul 2005 17:34:35 -0400

Mike, James

The ENUM-only numbers are real  E.164 - in case
of the +43780 out of the Austrian numbering plan
 
This implies that the rules are country specific
 
> So there is a kind of ^carrier-of-record^ even for ENUM-only
> numbers, at least in Austria.  
 
well observed, James ;-)
 
This is a kind of "chicken-and-egg" problem.
The rules in Austria require that a registrar needs
to have a contract with a "carrier-of-record" operating
the gateway, but there is an additional problem:
one side the gateway operator may route all numbers
within the range, on the other hand the registar  cannot
insist that calls to his numbers are routed via this gateway.
And in addition the registar does not need to provide a VOIP
service at all. This is very funny and very disturbing for bell-heads
 
More information only with a consulting contract ;-)
 
-richard

Von: enum-bounces at ietf.org im Auftrag von Michael Hammer (mhammer)
Gesendet: Fr 29.07.2005 22:36
An: james.f.baskin at verizon.com; enum at ietf.org
Betreff: RE: [Enum] E.164 communication assumptions/requirements

Quick check.  Is it correct to refer to these as ENUM only numbers, or
are they IP-domain numbers for which ENUM is just one method of routing
to them.  This might be country-specific.

Mike

> Behalf Of james.f.baskin at verizon.com
> Sent: Friday, July 29, 2005 3:34 PM
> To: enum at ietf.org
> Richard Stastny replied to James McEachern:
>
> >>I'm not sure I understand what it would mean to route an ENUM-only
> >>number
> to the PSTN.
> >
> >All E.164 numbers needs to be (should be ;-) routed on the
> PSTN, so an
> ENUM-only
> does not now
> >or does not care that +43780xxxx is an ENUM only range, the
> call still
> >can be completed by simply routing the call to +43
> >
> So there is a kind of ^carrier-of-record^ even for ENUM-only
> numbers, at least in Austria.  I would hope that other
> countries will require similar arrangements if they allow
> ENUM-only number assignments.
> By the way, if the governments of countries allowing
> assignment of ENUM-only numbers want to consider a completely
> level playing field for telecommunications users and
> providers (and require true portability), the number ranges
> for ENUM-only numbers won't stay purely ENUM when some users
> port those numbers to PSTN carriers.  This may be country- dependent.
>
> Jim
>
> >
> >-richard
>
>
>

---

From: "Stastny Richard" <[email-masked]>
Date: Sat, 30 Jul 2005 03:37:07 -0400

>How can the call be "completed" if there is no human or voice source at
>that ENUM  (i.e. its just a web page for example)

RC: service not available

-richard

Von: enum-bounces at ietf.org im Auftrag von Ray Anderson
Gesendet: Sa 30.07.2005 08:52
An: james.f.baskin at verizon.com; enum at ietf.org
Betreff: Re: [Enum] E.164 communication assumptions/requirements

> >by simply routing the call to +43

How can the call be "completed" if there is no human or voice source at
that ENUM  (i.e. its just a web page for example)