[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Enum] A proposal for Carrier ENUM



Stastny Richard wrote:
Dear all,

I do not want to define the requirements or rules for the entities
defined
in voipeer allowing them to peer and if there are different classes.

I only want to make a strong recommendation here: entities called
"carriers" allowed to make entries in Public Carrier ENUM MUST be
a subset of the above set. One requirement of the subset is that all
Members of the subset are able to peer with all other members.

Otherwise the whole construct does not make sense.
  

Well this whole discussion is interesting but realistically wont it be the NRA's that will define what is the relevant entity(s) authorized to make entries in Public Carrier ENUM?

This is still the e164.apra tree.

Having heard the arguments here, I come to the following conclusion
(and I changed my mind ;-)

An entity hosting the E.164 number in question as a destination
network for the PSTN termination is also allowed to enter the
E.164 number in question into Carrier ENUM. Carrier ENUM is
the opt-in place for the entities SERVING E.164 numbers 
On the PSTN (see below)

Rationale:

For my case A this is trivial, for case B and C even if the
number is assigned directly to the End-User, they need a
carrier to terminate or translate (in case of an IN-number)
the E.164 number in question.

The argument I brought forward during the discussion that we
should not rely on the PSTN within the Internet is not valid, because
E.164 numbers are PSTN names.

The argument brought forward by Antion is also not correct in this case:

  
The real (third party) Telco that controls the server should make the
peering decisions for that server, but that does not make him the owner
    
of >the delegation.

If we follow this argument for number portability, we would end up
finally
with this:

NP gives the end-user the right to keep the number, but as long as
he ports the number form one carrier to the other. In all countries
the number is still connected via a long rubber band to the original
donor
and zoomes back if given up. If the above statement from Antoin holds
true
here, the number should be kept by the subscriber.

One could also argue that if the entity that has the right to use of
a number is always the owner of the delegation, we have exactly what
we have now in User ENUM. So it is the decision of the end-user what
he is doing with the number = opt-in in ENUM. Again, this is USER ENUM.

We all have seen that we have a problem here and that's why we want to 
create Carrier ENUM:

Carrier ENUM is the opt-in of the entities SERVING the E.164 numbers
in question and it is assumed that such an entity will opt-in
with all his numbers.

This implies that an entity running their own servers will still
need to use a "carrier" for entries in Carrier ENUM. They may agree with
the "carrier" to enter their servers directly in this case (if they are
also member of the peering subset - if not, they will need a "carrier" 
anyways)

Richard


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

  


-- 


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
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