Subject: [Enum] Why not re-use interim procedures for infrastructure ENUM?

From: Bernie Hoeneisen <[email-masked]>
Date: Fri, 3 Feb 2006 17:33:25 +0100 (CET)

Hi!

I'd like to start a discussion about an alternative proposal to address 
the problem, on how tree infrastructure ENUM should look like
(more details at the bottom of this email):

Why can't we apply the same (interim) procedures for infrastructure ENUM
( http://www.itu.int/ITU-T/inr/enum/ ) as they exist for User ENUM?
Those (interim) procedures have been set up with User ENUM in mind, but 
IMHO those procedure are _not_ restricted to User ENUM only.

Therefore I believe, we could introduce a new infrastructure ENUM zone 
rather smoothly, without any need for changes at ITU or NRA level.
Of course, discussions with RIPE are needed, but I do not expect
any major disagreements or delay with RIPE.

The zone for infrastructure ENUM could e.g. look like:
   - infra.e164.arpa. or
   - e164i.arpa.
for all country codes, and there would be no branching between the 
numbers, as described in  draft-haberler-carrier-enum-01.

So why not to take this path forward and re-use, what is already out 
there, instead of introducing a new technical solution, which lacks 
backward compatibility? Or did I miss something?

cheers,
  Bernie

PS:

Background of my proposal for discussion:
-----------------------------------------

There are discussions ongoing, on how an infrastructure ENUM tree should 
look like. One solution is described in

   http://www.ietf.org/internet-drafts/draft-haberler-carrier-enum-01.txt

That I/D dicusses two options on how a infractructure ENUM tree could 
look like, i.e.

   1) Having a new subdomain of e164.arpa. (e.g. infra.e164.arpa.)

   2) Making branches between country code and the rest of a E.164
      number (e.g. 1.2.3.4.5.6.7.8.9.infra.1.4.e164.arpa.)

   Note, that I adjusted the terminology in the examples to reflect the
   recent decision about the naming convention (carrier -> infrastructure).

Option 2) is further discussed and a solution is proposed.
However, from technical point of view, option 2) is a bad choice,
e.g. it is not backward compatibel.

Option 1) is clean and easy from the technical point of view, but the 
authors of that I/D are affraid, that the process of introducing such a 
subdomain will delay the introduction of infrastructure ENUM:

   "In the first case, heavy involvement of ITU-T, RIPE as well as the
    applicable NRAs (National Regulatory Authorities) is needed during
    the setup phase.  Also, reopening the discussion of the interim
    procedures already agreed is a tedious process, as is the adaptation
    of the current delegation mechanism."

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Lind, Steven D, ALABS" <[email-masked]>
Date: Fri, 3 Feb 2006 10:56:44 -0600

Bernie,

I think you've oversimplified the problem. You certainly could introduce
a new tree or branch of the current tree above the country code, but the
ITU would definitely have to change its procedures to recognize both
trees. A country could opt-in to either of the two trees, both of them,
or neither of them. The current interim procedures assume there is only
one tree. 

The national sovereignty issue still exists, so if you introduce
something above the country code, the ITU must address it somehow. My
fear is that it will reignite the same debate that has taken place in
Study Group 2 over the last 4+ years. While some service providers,
particularly in Europe, are concerned over the current delegation
placement, the only way to avoid the ITU debate would be to make the
provider ENUM tree branch below the country code, thus making such
decisions national matters.

Thanks for raising this issue again, it is a very important one.

Steve

--------------------------------------------------------
Steven D. Lind, AT&T            Tel: 973-236-6787
180 Park Avenue, Rm. A201       Fax: 360-343-2875
Florham Park, NJ 07932          e-mail: [email-masked]
--------------------------------------------------------

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Bernie Hoeneisen
> Sent: Friday, February 03, 2006 11:33 AM
> To: [email-masked]
> Subject: [Enum] Why not re-use interim procedures for 
> infrastructure ENUM?
> 
> Hi!
>

---

From: "Stastny Richard" <[email-masked]>
Date: Sat, 4 Feb 2006 01:08:55 +0100

Bernie, Steven,
 
In principle Bernie is correct, but only in principle, because also Steven
has a point in stating that this is an oversimplification. and it
would IMHO unwise politically not to involve the ITU at all.
 
Michael and I have been discussing the issue off-list with some key players
to find potential ways forward.
 
We have studied the interim procedures 
http://www.itu.int/ITU-T/inr/enum/procedures.html
and came to the conclusion that the interim procedures COULD also
be used for delegations within an Infrastructure ENUM tree such as
proposed e.g. i.e164.arpa or e164i.arpa
 
The reasons for this are:
1. The interim procedures do NOT state ANY apex for ENUM at all, not
even in e164.arpa, so the apex is not mentioned and therefor not defined.
 
"These interim procedures are consistent with the agreed SG2 statement that Member States will have the right to choose whether to participate in the common designated ENUM domain, or not to participate in it, at their discretion, and with the procedures currently under development as specified in the future Recommendation(s). "
 
2. So basically it is at the discretion of the member states to participate in the common designated
ENUM domain.
 
3. The taslk of the ITU TSB according to the interim procedures is only (somewhat simplfied):
 
a. When the TSB receives a request from RIPE NCC, it will first verify that the country code (CC) mentioned in the request meets the formal conditions for delegation for ENUM, namely: that the code is a currently-assigned country code, ...
 
b If the (above) condition is met, and if the concerned Member State has notified the TSB of its position regarding delegation for ENUM of its CC, then the TSB will immediately make that position known to RIPE NCC. ...
 
Period.
 
What has to be changed in any case is the RIPE procedures
http://www.ripe.net/enum/instructions.html
because these procedures given by IAB are clearly for e164.arpa
1. Instructions to the RIPE NCC regarding operations of the doamin e164.arpa
 
	So here the IAB MUST update the instructions to RIPE for the (to be defined)
infrastructure domain AND RIPE must be willing to host in addition also the apex of this domain, e.g. 

1 Instructions to the RIPE NCC regarding operations of the doamin e164.arpa AND i.e164.arpa

A concerned Member state may now send in independently TWO requests to RIPE and
notify ITU TSB independantly for each request.
 
Michael Haberler and I are currently working on an up-issue for 
 http://www.ietf.org/internet-drafts/draft-haberler-carrier-enum-01.txt <http://www.ietf.org/internet-drafts/draft-haberler-carrier-enum-01.txt> 
 
proposing this way forward.
 
Since it is unclear if this works out in IAB, RIPE and ITU-T, and if,
how long this takes, we still will include the second option, branching
off the tree below, because this allows member states to
IMMEDIATELY start trials or implementations of Infrastructure
ENUM in a co-ordinated and compatible way.
 
Note: member states could do this anyway on their own discretion at any time now
in any part below their cc-code or in a completely different tree, but
our proposal simply allows to put a pointer in e164.arpa to allow internatioal
interworking

If finally the issues are worked out, the data could fe folded back
into the common infrastructure tree at any time also at the discretion
of the country.
 
The currently envisaged way forward is

- discuss the proposal at the IETF meeting in Dallas
The IETF (and the IAB) should come to a conclusion
before RIPE and especially the ITU is involved.
(note: if this is agreed, a simple addition of one or two lines
to RFC3761 is sufficient)
 
- the next ITU SG2 meeting takes place first half of May 2005
so enough time to prepare a D contribution to explain
the issue. (requires IAB and RIPE to principally agree)
 
- if ITU SG2 accepts that the interim procedures are
also sufficient for valid requests of member states, it
may instruct the ITU TSB by stating this in the meeting
report to approve also requests to RIPE for infrastructure
ENUM delegations in the same way as it is done now for
User ENUM requests. This would be the optimum
 
- if ITU SG2 is not stating this in the meeting report
(this could be for various reasons, eg no decision is
made, the interim procedures need change, etc.)
the next ITU SG2 meeting is in January 2006, (because
of the ITU Plenipot Meeting in Fall in Turkey)
 
- in this case we could still proceed with option 2.

best regards
Richard Stastny

________________________________

Von: [email-masked] im Auftrag von Lind, Steven D, ALABS
Gesendet: Fr 03.02.2006 17:56
An: Bernie Hoeneisen; [email-masked]
Betreff: RE: [Enum] Why not re-use interim procedures for infrastructure ENUM?

Bernie,

Steve

---

From: "Rosbotham, Paul" <[email-masked]>
Date: Mon, 6 Feb 2006 10:28:55 -0000

Thanks Richard,

I like your way forward.  I continue to have severe reservations of the Plan B approach, ie i.c.c.e164.arpa, leaving things to national matters.  

I think that approach is fine where the ENUM delegation hasn't been made, or where it's been made for limited trial purposes.  In these scenarios, the choice of Tier One for commercial service could then be made according to the needs of both user and infrastructure ENUM.

However, where delegation has already made for commercial service, this delegation was very much made under the criteria of the Tier One being selected for *USER* ENUM.  These criteria may or may not be applicable for infrastructure ENUM.  For example, it is a reasonable expectation that the telcos in the country concerned may  require some degree of joint control over the infrastructure ENUM Tier One, given its actions/performance would be critical in the routeing of calls to their customers.  The choice of Tier One for User ENUM certainly wouldn't have factored this in, or at least if it has it would be by co-incidence of similar stakeholder communities.

Having the discussion at ITU may be painful....but it will be far less painful than half of the world's numbers not being in infrastructure ENUM because the telco assignees aren't willing to participate in something that they have no influence over....

Paul Rosbotham

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Stastny Richard
Sent: Saturday, February 04, 2006 12:09 AM
To: Lind, Steven D, ALABS; Bernie Hoeneisen; [email-masked]
Subject: Re: [Enum] Why not re-use interim procedures for infrastructure
ENUM?

Bernie, Steven,

 

 

best regards
Richard Stastny

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.