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

From: "Stastny Richard" <[email-masked]>
Date: Fri, 08 Jul 2005 01:33:40 -0400

Hi,
 
I think Richard and Michael have already answered most of your questions, 
I just want to add an important point you may have missed:
 
>A key requirement MUST be that a dialed E.164 number enables a call to go through. 
 >If ENUM becomes the stumbling block preventing call completion, 
> that will invite unnecessary regulation
 
MUST?
Please look at RFC3764 (SIP Enumservice from our esteemed AD).
It states clearly in the Security Section:
 
"Unlike a traditional telephone number, the resource identified by a
   SIP URI may require that callers provide cryptographic credentials
   for authentication and authorization before a user is alerted.  In
   this respect, ENUM in concert with SIP can actually provide far
   greater protection from unwanted callers than the existing PSTN,
   despite the public availability of ENUM records."
 
On the other hand, if a carrier is not able to access the PoI
given in Carrier ENUM, that does not mean that the call
cannot go through, it may still be delivered via other
means of peering, e.g. the PSTN.
 
-richard

________________________________

Von: Michael Hammer (mhammer) [mailto:mhammer at cisco.com]
Gesendet: Fr 08.07.2005 00:11
An: Stastny Richard; Patrik Faltstrom (pfaltstr); Livingood, Jason
Cc: enum at ietf.org; Richard Shockey
Betreff: RE: [Enum] Agenda items for IETF Paris

Richard,

So in User ENUM you provide an end-user URI and get an E.164 number back?  I don't think so.

First, don't both types of ENUM start with an E.164 and return a URI?

Second, in which RFC does it say that the URI returned MUST be an end-user URI?
(I'll confess I haven't read them all.)

Third, in both cases, isn't the intent to be able to route a call (initiate communication) toward the owner of the E.164 number?  The concept of peering partners is beside the point.  I find the idea of disconnected islands of closed clubs to be counter-productive.  A key requirement MUST be that a dialed E.164 number enables a call to go through.  If ENUM becomes the stumbling block preventing call completion, that will invite unnecessary regulation.

Fourth, isn't one of the principles of the Internet to provide generally useful mechanisms?  Bifurcating this into User versus Carrier "orthogonal and independent" implementations is a recipe for non-interoperability and "Walled ENUM".

I hope I have totally misunderstood your words below.

Mike

> -----Original Message-----
> From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On
> Behalf Of Stastny Richard
> Sent: Thursday, July 07, 2005 5:44 PM
> To: Patrik Faltstrom (pfaltstr); Livingood, Jason
> Cc: enum at ietf.org; Richard Shockey
> Subject: Re: [Enum] Agenda items for IETF Paris
>
> 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
>

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

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Fri, 08 Jul 2005 11:31:19 -0400

Richard,

Regulatory authorities need to learn that the OPT-IN part should apply only to the FQDN AoR of the end-user not a FQDN URI of a Point of Interconnect.  Once that distinction is learned, I think a viable single-tree ENUM would be possible.

My comments below are all orthogonal to service and policy issues.  The ability to route to an end-user or to a border controller does not mean that one has a peering (SLA) agreement, security credentials, or termination services configured to allow the call through.  Those are not routing issues, but additional service issues that need to be worked out.  In the case of the end-user, it is up to them to decide to accept calls.

Mike

> From: Richard Shockey [mailto:richard at shockey.us] 
> Sent: Thursday, July 07, 2005 9:05 PM
> To: Michael Hammer (mhammer); Stastny Richard; Patrik 
> Faltstrom (pfaltstr); Livingood, Jason
> Cc: enum at ietf.org
> Subject: RE: [Enum] Agenda items for IETF Paris
> 
> At 06:11 PM 7/7/2005, Michael Hammer \(mhammer\) wrote:
> 
> >Richard,
> >
> yes ..but end user ENUM as it has been interpreted by most 
> regulatory authorities is OPT-IN which requires the proactive 
> consent of the end point user to register a FQDN in e164.arpa 
> and that in most cases the URI is a SIP AOR
> 
> Carrier enum presumes that the URI returned is NOT a AOR but 
> a  border element in a service providers network that 
> provides admission control and interconnection between 
> service providers. Carrier ENUM presumes that registrations 
> are for all TN under the service providers control and 
> therefore there is no need to OPT IN since the endpoints are 
> never actually exposed.
> 
> 
> none of them.
> >Third, in both cases, isn't the intent to be able to route a call 
> >(initiate communication) toward the owner of the E.164 number?
> 
> not necessiarily .. initiate communication towards the owner 
> may not be the end point but a point of interconnection.
> 
> >The concept of peering partners is beside the point.  I find 
> the idea 
> >of disconnected islands of closed clubs to be counter-productive.
> 
> tell that to the wireless industry.
> 
> >  A key requirement MUST be that a dialed E.164 number 
> enables a call 
> > to go through.
> 
> not necessarily ..in carrier enum that means you find the 
> point of interconnection and it is the up to that point of 
> egress to apply policy as to whether to permit admission or not.
> 
> >  If ENUM becomes the stumbling block preventing call 
> completion, that 
> > will invite unnecessary regulation.
> >
> >Fourth, isn't one of the principles of the Internet to provide 
> >generally useful mechanisms?  Bifurcating this into User 
> versus Carrier 
> >"orthogonal and independent" implementations is a recipe for 
> >non-interoperability and "Walled ENUM".
> 
> Most of us dont agree since one of the objectives of Carrier 
> ENUM is to assist service providers in their well known and 
> highly publicized statement of directions for collapsing 
> their internal networks on to IP. 
> Carriers cannot collapse their networks on to IP unless they 
> can also collapse the underlying signalling networks that 
> enable carrier interconnection.
> 
> 
> > > From: enum-bounces at ietf.org 
> [mailto:enum-bounces at ietf.org] On Behalf 
> > > Of Stastny Richard
> > > 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.
> > >
> > > 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
> > >
> > > 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.
> > >
> > > discussion, we first need the meta-discussion... So we 
> know what we 
> > > agree on and not.
> > >
> > >     paf
> > >
> 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> 
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>

---

From: "Stastny Richard" <[email-masked]>
Date: Fri, 08 Jul 2005 12:10:52 -0400

Hi Mike,

thanks for compressing the whole issue in
three sentences.
 
-richard stastny

Von: Michael Hammer (mhammer) [mailto:mhammer at cisco.com]
Gesendet: Fr 08.07.2005 17:30
An: Richard Shockey; Stastny Richard; Patrik Faltstrom (pfaltstr); Livingood, Jason
Cc: enum at ietf.org
Betreff: RE: [Enum] Agenda items for IETF Paris

Richard,

Mike

---

From: "Stastny Richard" <[email-masked]>
Date: Sat, 09 Jul 2005 04:36:59 -0400

Otmar made a very important point here:
>As such, telephone numbers in an open numbering plan behave much more
>like domain names: If I own example.com, then I can put a webserver
>at example.com. I'm free to use foo.example.com, bar.foo.example.com
>and whatnot as well, as long as I stay within the lenght limits imposed by
>the DNS standard.

and thats why DNS and E.164 fits so well together, as long
as one sticks to the rules and does not invent or implement 
unnatural things (DNS-wise) e.g. cohabitation of zones.
 
-richard

Von: enum-bounces at ietf.org im Auftrag von Otmar Lendl
Gesendet: Sa 09.07.2005 10:25
An: enum at ietf.org
Betreff: Re: [Enum] Agenda items for IETF Paris

On 2005/07/09 00:07, "Michael Hammer (mhammer)" <mhammer at cisco.com> wrote:
> Michael,
>
> Could you elaborate more fully.  Between the setup of IP PBX and the
> assertion that my proposal makes something impossible, I didn't see any
> explanation.  It would help if you use a hypothetical E.164 number and
> perhaps explain if this was provided through a carrier or not.  Also, is
> this extension being assigned an E.164 number also?  Or is this grafting
> a non-E.164 number onto an E.164 number?  Would this require all
> DNS-resolvers to continue searching beyond the E.164 tree?

The misunderstanding here seems to be in open numbering plans nad
how they relate to E.164 numbers.

Michael gave some examples, I'd like to add a simple one. Our office in
Vienna uses a simple ISDN BRI in point-to-point mode. The number is
+43 1 5056416 which is a valid E.164 number that is dial- and
reachable from the worldwide PSTN. But so is +43 1 5056416 33,
+43 1 5056416 933, or +43 1 5056416 6, too.

We, as the owner of the head number are free to design our own, variable
length numbering plan behind that number as long as we stay within the
length limit of E.164. Our telco will route calls to +43 1 5056416 [0-9]*
to us and indicate in the call-setup what exactly the caller
dialled. (I will not go into the territory of overlap dialing here,
there is plenty of fun in the details.)

All those locally defined extensions are valid E.164 numbers. There
is no need to "continue searching beyond the E.164 tree", because
we *are* still in the E.164 tree.

As such, telephone numbers in an open numbering plan behave much more
like domain names: If I own example.com, then I can put a webserver
at example.com. I'm free to use foo.example.com, bar.foo.example.com
and whatnot as well, as long as I stay within the lenght limits imposed by
the DNS standard.

To continue with the +43 1 5056416 example: The ISDN BRI is connected
to a small cisco router on our side which translates all incoming calls
to SIP. The numbering plan (the information which extensions exist and
where they are routed) is stored in a small database which also drives
the 6.1.4.6.5.0.5.1.3.4.e164.arpa zone.

I can thus create new, valid E.164 numbers by a simple insert into that
table. ENUM NAPTRs are instantly visible as well. There is real value
in the fact that we have complete control over our ENUM zone.

All this does not mix with carrier enum. Our carrier doesn't even know
what numbers are in use behind our number. All he needs to know
is "route everything matching /^4315056416.*/ in our direction".
And basically that's the information our carrier has to put into
any carrier ENUM tree. In ENUM terms, that will probably be something
like

$ORIGIN 6.1.4.6.5.0.5.1.carrier.3.4.e164.arpa
@       100 10 "u" "E2U+sip" "!(^.*)$!sip:\\1 at sbc.my-carrier.at!" .
*       100 10 "u" "E2U+sip" "!(^.*)$!sip:\\1 at sbc.my-carrier.at!" .

As for zone-sharing, I think the problem is obvious.

/ol
--
< Otmar Lendl (lendl at nic.at) | nic.at Systems Engineer >

---

From: "Stastny Richard" <[email-masked]>
Date: Sun, 10 Jul 2005 13:15:40 -0400

>...but in the second variant it presupposes that the choices already made at a national level for user-ENUM are suitable/acceptable for carrier->ENUM. 
 
No, it does not
 
The entity responsible for the domain c.c.e164.arpa (e.g. the NRA, or Jim) is in charge of the domain, so this entity
may decide to that the entity (e.f the Tier 1 registry) running c.c.e164.arpa must delegate carrier.c.c.e164.arpa 
to another entity (e.g. the carrier Tier 1 registry). Of course it may also decide to use the same entity.
This is a national matter.
 
-richard

Von: Rosbotham, Paul [mailto:Paul.Rosbotham at cwmsg.cwplc.com]
Gesendet: So 10.07.2005 18:36
An: Stastny Richard; Michael Haberler; Michael Hammer (mhammer)
Cc: enum at ietf.org
Betreff: RE: [Enum] Agenda items for IETF Paris

...but in the second variant it presupposes that the choices already made at a national level for user-ENUM are suitable/acceptable for carrier-ENUM.  There are many locations where .e164.arpa delegations have proceeded upon a set of assumptions, and the system being used for wholesale PSTN replacement wasn't one of them (and, for the record, I'm not referring to the UK here, as the current delegation is only for trial purposes).

Personally, I think the proposal is a good idea, but only in the c.c.carrier.e164.arpa guise : I don't regard carrier.c.c.e614.arpa as being workable.  And yes, I know that means another N years of debate at ITU...

Regards

Paul

-----Original Message-----
From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org]On Behalf Of
Stastny Richard
Sent: Saturday, July 09, 2005 9:33 AM
To: Michael Haberler; Michael Hammer (mhammer)
Cc: enum at ietf.org
Subject: Re: [Enum] Agenda items for IETF Paris

>I don't think it a good idea to regulate where in the tree (e.g. after 3
>or 6 digits) to place carrier information.

First, there is no regulation, it is only a recommendation to
put it after the cc, as Michael already pointed out

And for the avoidance of doubt:

the proposals c.c.carrier.e164.arpa and
carrier.c.c.e614.arpa are technically (or DNS wise)
completely equivalent

It is also obvious that the first variant is more straightforward.
The preference for the latter variant is simply because
of practical administrative and political reasons.

In the second variant everything stays a national matter,
in the first variant the debate on the  international level would
start over again (2-3 years?), and then you have again the debate on the
national level.

With the second variant we jump over the international
debate and can start immediately with the national debate.
This is enough anyway.

-richard

Von: enum-bounces at ietf.org im Auftrag von Michael Haberler
Gesendet: Sa 09.07.2005 01:58
An: Michael Hammer (mhammer)
Cc: enum at ietf.org
Betreff: RE: [Enum] Agenda items for IETF Paris

Michael,

At 18:29 08.07.2005, Michael Hammer \(mhammer\) wrote:

>I read your draft, but fail to see the need to define a new "carrier"
>domain at any point in the tree.  Putting such a domain under the
>country code only branches at a different point down the hierarchy.
>You've only moved the problem next door.
>
>Two facts bound this problem as far as I can tell:
>1:  A number is dialed and presented to the DNS client that then must
>resolve it by traversing the tree from root on down to the last digit.
>2:  Until you reach a given point in the tree (depending on national
>authority assignments, e.g. 10K v 1K blocks) it is ambiguous whether the
>number belongs to one carrier or another.
>
>I don't think it a good idea to regulate where in the tree (e.g. after 3
>or 6 digits) to place carrier information.

I think there is a major misunderstanding what our proposal suggests.

The 'carrier subdomain location' is about opening a complete new tree, at a
flexible but globally interworking location in the e164.arpa tree because
of the very cohabitation problems. It is a convention which needs to be
published for interoperability, not a regulation. A well-known table is
just one mechanism to do that, an appropriate RR in a standard place per
country code could get rid of the table altogether.

It is NOT the place where, for a given number, a particular "Carrier RR" is
stored. I propose to unroll all number ranges fully and store RR's at the
number level. I dont envisage delegations at some number block boundary -
this again gets in the way with zone ownership when a number is ported out
of a block - DNS semantics doesnt deal well with a "exception override"
over a delegation boundary. If each number is entered in itself - no
problem, because zone ownership for that number mirrors the changed
carrier-of-record status.

The rules are:
- a carrier-of-record for a given number may populate the carrier subtree
with this number, with RR's as she may see fit.
- a user may populate the user tree as per 3761 (section 2 requirement 2 in
our I-D) as he sees fit.
- they are ships in the night - no need to coordinate between the two.

The reason why the carrier subtree location needs to be flexible and cant
be assumed under the country code is that "Country Code does not equal
Numbering Plan Administration"  (that's by and large a fix for the
colonies, as far as we're concerned over here  ;))

Resolving a tree digit-by-digit is bound to increase lookups drastically,
violating our proposed "single DNS lookup to reach any NAPTR" requirement
(section 2 requirement one).

I guess I should give two examples. I assume the carrier subdomain location
for the Austrian CC is 2, that is, right below the CC.

Example 1:

1. I obtain a corporate network number from the national number
administrator, so I am the number holder. Lets assume the number is +43
59966 .  Now I can enter that in User ENUM - and I'll have
6.6.9.9.5.3.4.e164.arpa delegated to my own name server - in the zone I
have my SIP AOR for my PBX, and maybe lots of other stuff - we have an open
numbering plan here and I could have anywhere from 0 to 8 extra DDI digits
after +43 59966 for my users. I choose to manage all User ENUM entries in
my nameserver. I choose not to care about any carrier records my
carrier-of-record of the week might want to have.  I might not even be in
the position to manage such a record in case my gear happens to not support
that.

2. I turn around and ask Telekom Austria (TA) to route that number in the
PSTN, which is when they become the carrier of record for my number. They
happen to interconnect with other carriers with IP and choose to use the
carrier ENUM tree under +43 to do that, but I could care less.
Now they can enter that in the local carrier subtree:
6.6.9.9.5.carrier.3.4.e164.arpa points their SBC.

3. I decide Foo Telco is better for me, so I port my number to Foo, hence
Foo becomes the new carrier-of-record for my number and thus has the right
to change 6.6.9.9.5.carrier.3.4.e164.arpa to point to the Foo SBC.

Example 2:

I have number +1 571.123.4567, which is in a US NPA, which happens to use
the scheme I laid out. I assume that location for the +1 CC to be at 4,
after the NPA.

1.  I have a user ENUM domain: 7.6.5.4.3.2.1.1.7.5.1.e164.arpa - nothing
special here.
2.  My telco X chooses to interconnect on IP with others, among them TA and
Foo, using our scheme, so she would enter their SBC information in the
7.6.5.4.3.2.1.carrier.1.7.5.1.e164.arpa zone.

Since all this assumed to be well-known, a call to +1 571.123.4567
originating from some other TA or Foo POTS subscriber could be be passed to
X on IP, and vice versa. When X, Foo and TA eventually grow up, and decide
to dump interconnect completely, they can switch to just interpret User
ENUM records. Or both, as and when they see fit. Sun-Tsu says: "for the
fleeing enemy, build a silver bridge."

At no point there is any interference between the subtrees, and a single
lookup gets at any NAPTR. User-to-user between +43 59966.* and +1
571.123.4567 works as per rfc3761.

Michael

http://www.enum.at/ietf/draft-haberler-carrier-enum-00.html

ps: In practice, carrier records probably would point to carrier
nameservers, and RR's would be in the zone hosted there, but that makes no
difference.

This e-mail has been scanned for viruses by the Cable & Wireless e-mail security system - powered by MessageLabs. For more information on a proactive managed e-mail security service,  visit http://www.cw.com/uk/emailprotection/

The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies.

---

From: "Rosbotham, Paul" <[email-masked]>
Date: Sun, 10 Jul 2005 16:14:43 -0400

>>And yes, I know that means another N years of debate at ITU...

>Lets not prejudge our distinguished colleagues in Geneva.

Agree totally; as you're aware, for my sins I am one of said "distinguished colleagues", and understand well the concerns of my fellow Members and members, even if I don't always agree with them!