Subject: Re: [Enum] Agenda items for IETF Paris

From: "Stastny Richard" <[email-masked]>
Date: Thu, 07 Jul 2005 17:41:00 -0400

Hi all,
 
>For example, I know Stasny have said several times "this is not ENUM" 
>and personally, I do agree with him. But, to be able to have that 
>discussion, we first need the meta-discussion... 
 
I agree that there seems to be a discussion necessary
 
to clarify this, as I tried to state in the definitions I posted:
 
The purpose of User ENUM is for mapping end-user URIs to E.164 numbers.
basically a service for end-users. The basic requirement for end-users
is to find other end.users. The second requirement is that orig end-user
must be able to reach the destination user, because the Internet is
end-to-end. User ENUM is conformant to the Internet principles
 
The purpose of Carrier ENUM is to help carriers finding peering partners
using E.164 numbers to map to URIs, basically find the destination networks
from an origination network. The basic requirement for carriers is to find other 
carriers. Here it is NOT required that every carrier must be able to reach any
other carrier, this is depandant on peering agreements.
 
These two implementations are orthogonal and independant.
 
If there is an efficient way to use the same nfrastructure for these
differnt purposes, fine.
 
IMHO the VoIP peering requirements necessary to do so are out of scope 
of ENUM WG. I leave it to the discussion if they are within the scope of the IETF.
On the other hand, many IETF protocols are used on IP-based networks separated
from the Internet (e.g. SIP within 3GPP).

-richard

________________________________

Von: enum-bounces at ietf.org im Auftrag von Patrik Fältström
Gesendet: Do 07.07.2005 22:53
An: Livingood, Jason
Cc: enum at ietf.org; Richard Shockey
Betreff: Re: [Enum] Agenda items for IETF Paris

What I hope we can do is to first discuss what requirements we have 
on "user" and "carrier" ENUM, what is in-scope and out of scope. This 
discussion will give a list of requirements that I hope we can use to 
measure the proposals against.

For example, I know Stasny have said several times "this is not ENUM" 
and personally, I do agree with him. But, to be able to have that 
discussion, we first need the meta-discussion... So we know what we 
agree on and not.

    paf

On Jul 7, 2005, at 20:41, Livingood, Jason wrote:

>
>
>> 5 Discussion of Pfautz etal drafts on Carrier ENUM - Requirements ?
>>
>
> (Agenda addition)
>
> There is a new, alternate Carrier ENUM proposal making its way to the
> WG, draft-haberler-carrier-enum-00.  Perhaps this I-D can be discussed
> immediately after the Pfautz et al. draft?  Discussion of both drafts
> could follow, which I expect to be lively.
>
> Regards
> Jason Livingood
>
> _______________________________________________
> enum mailing list
> enum at ietf.org
> https://www1.ietf.org/mailman/listinfo/enum
>

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

---

From: Richard Shockey <[email-masked]>
Date: Thu, 07 Jul 2005 21:25:03 -0400

At
I agree that there seems to be a discussion necessary
to clarify this, as I tried to state in the definitions I posted:
The purpose of User ENUM is for mapping end-user URIs to E.164 numbers.
basically a service for end-users. The basic requirement for end-users
is to find other end.users. The second requirement is that orig end-user
must be able to reach the destination user, because the Internet is
end-to-end. User ENUM is conformant to the Internet principles
The purpose of Carrier ENUM is to help carriers finding peering partners
using E.164 numbers to map to URIs, basically find the destination networks
from an origination network. The basic requirement for carriers is to find 
other
carriers. Here it is NOT required that every carrier must be able to reach any
other carrier, this is depandant on peering agreements.
This is well stated simply because you can find a point of interconnection 
does not mean you have to peer.

These two implementations are orthogonal and independant.
If there is an efficient way to use the same nfrastructure for these
differnt purposes, fine.
IMHO the VoIP peering requirements necessary to do so are out of scope
of ENUM WG. I leave it to the discussion if they are within the scope of 
the IETF.
On the other hand, many IETF protocols are used on IP-based networks separated
from the Internet (e.g. SIP within 3GPP).
I'd state this a little directly, whereas the IETF has never attempted to 
define transit-peering requirements among Internet service providers it 
certainly has provided useful technologies to facilitate such agreements. 
In the same sprit I agree that VoIP peering requirements should be out of 
scope for the IETF there are still technologies that we can provide that 
can facilitate those transactions. TN to URI mapping is certainly one of them.

I will further postulate ..and I co-authoring a draft on this that TN to 
URI mappings can also help facilitate PSTN to PSTN connections where the 
core transport and proxy network is IP based. <NO TCAP>

Classic PSTN service providers have always exchanged various forms of data 
to facilitate interconnection.It is perfectly reasonable to assume that 
they also need technologies to facilitate interconnection or peering  in an 
all IP environment as well.

-richard

Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141 at fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683,  Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or <mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum