RE: [Enum] Carrier ENUM mini-BoF Agenda

["Stastny Richard" <Richard.Stastny at oefeg.at>]

James,

I already offered to provide half of the first point:
I could present what carrier ENUM is (at least the ETSI
point of view) and why it needs to be different from
User ENUM

The problem we are trying to solve is IMHO opinion
an answer to the question if ENUM WG needs to do anything,
or in other words: 
a. are there any additional requirements
to RFC 3781 as it is now
b. are there additional enumservices need especially for
carrier ENUM.

Note: if I talk about existing ENUM services it mean
the ENUMservices defined in ETSI TS 102 172 v2
But these are needed also for User ENUM and should finally
be registered by IANA (or not).

My answer to these questions sofar is: no, there is
nothing additional needed if carrier ENUM is only
used to identify termination end points

If carrier ENUM is also user for transit, then
Something is needed, but I do not know what.

Richard

> -----Original Message-----
> From: James Seng [mailto:jseng at pobox.org.sg]
> Sent: Wednesday, June 23, 2004 3:44 PM
> To: Stastny Richard
> Cc: Richard Shockey; enum at ietf.org
> Subject: Re: [Enum] Carrier ENUM mini-BoF Agenda
> 
> 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:
> 
> > 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