Subject: RE: [Enum] Carrier ENUM mini-BoF Agenda

From: "Stastny Richard" <[email-masked]>
Date: Thu, 24 Jun 2004 12:42:47 -0400

I still do not know what should be on the agenda
of the Carrier ENUM mini-BoF.

Sofar two issues have been raised:

1. Privacy, but this is a non-issue for Carrier ENUM
(it may be discussed in the User ENUM part)

2. Usage of Carrier ENUM for transit routing

I said related to this issue
"ENUM as it is now is not providing these functions, one
should use TRIP or OSP for this. 
 
The mini-BoF may discuss this issue and may come
to a conclusion. (reject the issue or extend ENUM)"

I have seen NO comment on this on the list.

BTW, I have seen besides the privacy issue
NO comment related to Carrier ENUM on this list sofar
so there seem to be either no interest or nobody
already implementing Carrier ENUM is coming forward.

Either way, we may skip the topic.

Richard

> Richard Stastny
ÃFEG
Ãsterreichische Fernmeldetechnische Entwicklungs- und FÃrderungsgesellschaft mbH
BÃroadresse: Arsenal Objekt 24, 7. Stock, Bauteil Ost, A-1030 Wien
Postadresse: Postfach 147, A-1103 Wien
Telefon: +43 664 420 4100
Telefax: +43 1 79780 13
E-Mail: <mailto:richard.stastny at oefeg.at> 
Web: <http://www.oefeg.at>

Die in dieser Mitteilung und AnhÃngen enthaltenen Informationen sind ausschlieÃlich fÃr den Adressaten bestimmt und kÃnnen geheime, vertrauliche oder vor Weitergabe geschÃtzte Informationen enthalten. Falls es sich beim Leser dieses Absatzes nicht um den beabsichtigten EmpfÃnger oder dessen Vertretung handelt, wird er hiermit in Kenntnis gesetzt, dass jegliche Weitergabe, Verteilung oder VervielfÃltigung dieser Mitteilung verboten ist. Sollte dieses Schreiben irrtÃmlich zugestellt worden sein, wird gebeten, den Absender zu benachrichtigen und die Mitteilung zu lÃschen, ohne Kopien einzubehalten. Danke.

-----Original Message-----
From: Stastny Richard 
Sent: Sunday, June 20, 2004 10:29 PM
To: Richard Shockey
Cc: enum at ietf.org
Subject: AW: [Enum] Carrier ENUM mini-BoF Agenda

So given Steven questions, my "User ENUM" definitions
and Richards "Carrier TN to URI translation mechanisms" aka "Carrier ENUM",
Â
I want to try to give an answer toÂquestion 1b first, before I address 1a
Â
a: within User ENUM there exist privacy issues.
ÂÂÂ set-up properly these issues do not exist in "Carrier ENUM",
ÂÂÂ because either the information is not accessible or not usable
ÂÂÂ by end-users.
ÂÂÂ Note: all privacy issues with ENUM should thereore be discussed 
ÂÂÂ in the first half of the meeting, not in the mini-BoF on "Carrier ENUM"
Â
b. "User ENUM" is end-to-end and therefore opt-in
Â-ÂÂService providers wanting to deploy a routing of calls
ÂÂÂ between their networks avoiding the PSTN as interconnect
ÂÂÂ need a tool on the Internet to achieve this goal. (This
ÂÂÂ tool is also necessary if no PSTN exists anymore ;-)

ÂÂ-ÂThey may choose to use the technology as defined
ÂÂÂ in RFC3761 at al.

Â -ÂTo achieve this they have to includeÂALL E.164 numbers assigend
ÂÂÂÂ to them andÂthey in turn assigned to the end-users they
ÂÂÂÂ are providing service for (anybody an idea of a better wording?)
ÂÂÂÂ so opt-in is not possible.

-ÂÂ confederations of service providers may choose any domain in
ÂÂÂ the DNS as root for their tree, they may even chooseÂa "private DNS"
Â
Â - IfÂa service provider Âpopulates the tree only with E.164 numbers 
ÂÂÂÂ assigned to him, a later merging of trees is trivial, because no overlaps
ÂÂÂÂ exist.
Â - currently also nor additional requirements on the ENUM protocol
ÂÂÂ are known. If there are, please come forward now.
Â
Warning: the above definition is only valid if "carrier ENUM" is
only used for routing to destination service providers hosting the
numbers they hold in the tree.
Â
So
1a: What are the issues/problems that need to be addressed?
Recently some requirements have been discussed to use
ENUM and especially "carrier ENUM" for additional 
purposes,e.g. routing to transit providers if they also
provide gateways to the PSTN.
Â
Although this is in principle possible with ENUM, this
is not recommended because it may cause conflicts in
domain ownerships and make it impossible to merge
trees later.
Â
Since in most cases routing to the PSTN is involved,
this immediately raises the question of settlement and
alternative routes.

ENUM as it is now is not providing these functions, one
should use TRIP or OSP for this. 
Â
The mini-BoF may discuss this issue and may come
to a conclusion. (reject the issue or extend ENUM)

Richard

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

---

From: James Seng <[email-masked]>
Date: Thu, 24 Jun 2004 12:44:27 -0400

Here is what I think:
First, I think we need to do some problem statement trashing. What is 
Carrier ENUM and what's the problem we trying to solve?

Then we can have someone present a solution (or more) as a strawman to 
start the discussion.

Anyone wants to give a first shot at these two?
-James Seng
Stastny Richard wrote:

Richard Stastny
ÃFEG

-----Original Message-----
From: Stastny Richard 
Sent: Sunday, June 20, 2004 10:29 PM
To: Richard Shockey
Cc: enum at ietf.org
Subject: AW: [Enum] Carrier ENUM mini-BoF Agenda

I want to try to give an answer to question 1b first, before I address 1a
 
a: within User ENUM there exist privacy issues.
    set-up properly these issues do not exist in "Carrier ENUM",
    because either the information is not accessible or not usable
    by end-users.
    Note: all privacy issues with ENUM should thereore be discussed 
    in the first half of the meeting, not in the mini-BoF on "Carrier ENUM"
 
b. "User ENUM" is end-to-end and therefore opt-in
 -  Service providers wanting to deploy a routing of calls
    between their networks avoiding the PSTN as interconnect
    need a tool on the Internet to achieve this goal. (This
    tool is also necessary if no PSTN exists anymore ;-)

  - They may choose to use the technology as defined
    in RFC3761 at al.
  - To achieve this they have to include ALL E.164 numbers assigend
     to them and they in turn assigned to the end-users they
     are providing service for (anybody an idea of a better wording?)
     so opt-in is not possible.
-   confederations of service providers may choose any domain in
    the DNS as root for their tree, they may even choose a "private DNS"
 
  - If a service provider  populates the tree only with E.164 numbers 
     assigned to him, a later merging of trees is trivial, because no overlaps
     exist.
  - currently also nor additional requirements on the ENUM protocol
    are known. If there are, please come forward now.

So

 

Richard

---

From: Jaap Akkerhuis <[email-masked]>
Date: Thu, 24 Jun 2004 19:39:24 -0400

Can you please send your email in non encoded form? There is no reason
to encode plain ascii (since that is what you seem to be sending).

	jaap

---

From: Jeff Williams <[email-masked]>
Date: Fri, 25 Jun 2004 02:33:00 -0400

Richard and all,

  Why would the subject of privacy and security in user ENUM
be skipped?

  As I stated earlier on another thread, even in carrier ENUM for
routes, some small amount of exposure to privacy intrusion exists..
Hence it would seem appropriate that this also needs some
addressing unless the anti-privacy bigots wish to dismiss such
out of hand?

Stastny Richard wrote:

> �?FEG
> �?sterreichische Fernmeldetechnische Entwicklungs- und Förderungsgesellschaft mbH
> Büroadresse: Arsenal Objekt 24, 7. Stock, Bauteil Ost, A-1030 Wien
> Die in dieser Mitteilung und Anhängen enthaltenen Informationen sind ausschlie�?lich für den Adressaten bestimmt und können geheime, vertrauliche oder vor Weitergabe geschützte Informationen enthalten. Falls es sich beim Leser dieses Absatzes nicht um den beabsichtigten Empfänger oder dessen Vertretung handelt, wird er hiermit in Kenntnis gesetzt, dass jegliche Weitergabe, Verteilung oder Vervielfältigung dieser Mitteilung verboten ist. Sollte dieses Schreiben irrtümlich zugestellt worden sein, wird gebeten, den Absender zu benachrichtigen und die Mitteilung zu löschen, ohne Kopien einzubehalten. Danke.
>
> �
> I want to try to give an answer to� question 1b first, before I address 1a
> �
> � � �  set-up properly these issues do not exist in "Carrier ENUM",
> � � �  because either the information is not accessible or not usable
> � � �  by end-users.
> � � �  Note: all privacy issues with ENUM should thereore be discussed
> � � �  in the first half of the meeting, not in the mini-BoF on "Carrier ENUM"
> �
> � -� � Service providers wanting to deploy a routing of calls
> � � �  between their networks avoiding the PSTN as interconnect
> � � �  need a tool on the Internet to achieve this goal. (This
> � � �  tool is also necessary if no PSTN exists anymore ;-)
>
> � � -� They may choose to use the technology as defined
> � � �  in RFC3761 at al.
>
> �  -� To achieve this they have to include� ALL E.164 numbers assigend
> � � � �  to them and� they in turn assigned to the end-users they
> � � � �  are providing service for (anybody an idea of a better wording?)
> � � � �  so opt-in is not possible.
>
> -� �  confederations of service providers may choose any domain in
> � � �  the DNS as root for their tree, they may even choose� a "private DNS"
> �
> �  - If� a service provider � populates the tree only with E.164 numbers
> � � � �  assigned to him, a later merging of trees is trivial, because no overlaps
> � � � �  exist.
> �  - currently also nor additional requirements on the ENUM protocol
> � � �  are known. If there are, please come forward now.
> �
> �
> �
> �
> �
>   ------------------------------------------------------------------------
>
>    Part 1.2       Type: Plain Text (text/plain)
>               Encoding: 7bit

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail jwkckid1 at ix.netcom.com
 Registered Email addr with the USPS
Contact Number: 214-244-4827