Subject: RE: [Enum] Please start thinking about agenda items for IETF SanDiego etc

From: "Lind, Steven D, ALABS" <[email-masked]>
Date: Fri, 11 Jun 2004 11:54:02 -0400

Richard S.,

As to your proposed agenda item 1, I believe that the direct should be:

1a: What are the issues/problems that need to be addressed?
1b: What are the reasons that "Public" ENUM can't solve them?

I've never gotten any answers on those questions from my European colleagues that seem to be more involved in the "Carrier" ENUM activities on that side of the pond.

Steve

--------------------------------------------------------------------------------
Steven D. Lind                                Tel: 973-236-6787
180 Park Avenue                             Fax: 360-343-2875
Room A201                                    sdlind at att.com
Florham Park, NJ 07932
--------------------------------------------------------------------------------

> -----Original Message-----
> From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org]On Behalf Of
> Stastny Richard
> Sent: Thursday, June 10, 2004 1:16 PM
> To: Richard Shockey; enum at ietf.org
> Cc: paf at cisco.com
> Subject: Re: [Enum] Please start thinking about agenda items for IETF
> SanDiego etc
> 
> 
> >If we did a BoF on carrier ENUM , what would the proposed agenda be?
> 
> Concerning IETF two agenda items could be:
> 
> 1. What are the principal differences between user and 
> carrier ENUM, if any?
> 2. Is there any additional requirement in protocol, eg 
> different enumservices
> carrier ENUM would need? If yes, speak now.
> 
> Now to non IETF, but ENUM issues:
> 
> >That said its manifestly self evident that everyone and their
> >brother-in-law is either becoming a VoIP service provider and or
> >infrastructure ENUM registry.
> 
> >>Here at VON Europe a group of UK ITSPs (ITSPA) is 
> considering such a thing on
> >>an European scale, linking all European virtual VoIP 
> providers together
> >>with iENUM.
> 
> >humm and as you know a group of Asia-Pac CCTLD operators are putting
> >together thieir own ENUM Engineering group
> 
> >http://www.apenum.org <http://www.apenum.org> 
> 
> of course I now about APEET ;-) (hi James)
> 
> I consider the sideways operation born out of disparation with their
> regulators or ENUM Forums of the mentioned groups
> still in principle as user ENUM, and not operator ENUM,
> because this groups accept the end-to-end principle Dr. Sinnreich
> and the IETF is talking aboit.
> 
> Since most of the usual suspects know each other, we may still
> be able to capture the movement before it is completely out of
> the box and at least agree on a common tree. 
> 
> I also suggest to host the tier 0 of this tree also with RIPE,
> and delegate the CC via the national or regional groups
> forming. These group should decide who is operating the
> tier 1s for a country or group of countries. Since this then
> stays near RIPE, this would be in most cases also the potential
> tier 1s for e164.arpa, so a later transition back to e164.arpa
> would be easier.
> 
> BTW, in SER and asterisk (and also in the IX66 beta) the query of
> different trees for different number ranges or first querying 
> e164.arpa
> and then another tree is already implemented (see freenum.org),
> so the two systems could smoothly co-operate and run in paralell
> 
> And finally it would create some pressure to get e164.arpa on
> track asap.
> 
> Richard
> 
> 
> 	-----UrsprÃngliche Nachricht----- 
> 	Von: Richard Shockey [mailto:richard at shockey.us] 
> 	Gesendet: Do 10.06.2004 18:08 
> 	An: Stastny Richard; enum at ietf.org 
> 	Cc: paf at cisco.com 
> 	Betreff: Re: AW: [Enum] Please start thinking about 
> agenda items for IETF San Diego etc
> 	
> 	
> 
> 	At 03:56 AM 6/10/200
> 	
> 	>Hi Rich,
> 	>
> 	>I am currently writing on a draft for registration of 
> enum-service "void",
> 	>I hope I will have it ready before the deadline
> 	
> 	OK
> 	
> 	>
> 	>Another item I could offer is about the Austrian 
> number ordinance
> 	>(in force) and the ENUM-driven numbers.
> 	
> 	Well we have so far
> 	
> 	1. The ENUM operations document that needs very careful review.
> 	
> 	2. Andrzej Bartosiewicz 
> "draft-bartosiewicz-enterprise-enum-00.txt"
> 	
> 	3. Scott Hollenbeck on EPP-e164 and whether this is 
> fully baked enough to
> 	advance . I'm  disappointed to see that there has been 
> little or no
> 	discussion of this important work on the list.
> 	
> 	>
> 	>A hot issue currently is infrastructure ENUM. I do not 
> know if we should
> 	>discuss
> 	>this in ENUM WG or in a separate BoF as you proposed.
> 	
> 	I still don't know.  I vacillate on this issue 
> depending on cicada insects
> 	I have to deal with in the morning.
> 	
> 	I'm curious to hear what the list thinks about this.  
> I'm reluctant to use
> 	WG time since the discussion of infrastructure/carrier 
> ENUM ( aka non
> 	e164.arpa) could spin off in any number of useless 
> directions and there is
> 	more fundamental question on whether their is even an 
> appropriate role for
> 	the IETF in this area at all.
> 	
> 	That said its manifestly self evident that everyone and their
> 	brother-in-law is either becoming a VoIP service provider and or
> 	infrastructure ENUM registry.
> 	
> 	If we did a BoF on carrier ENUM , what would the 
> proposed agenda be?
> 	
> 	>
> 	>Infrastructure ENUM is getting currently more speed in 
> take-up then
> 	>ENUM in e164.arpa. The reason is (as you know very well) that
> 	>there is an increasing need for VoIP operators to interconnect
> 	>their islands on VoIP.
> 	
> 	ENUM and VoIP have been joined at the hip since its 
> inception. We've always
> 	known this. As VoIP takes off like a rocket the need to 
> interconnect the
> 	islands increases exponentially.
> 	
> 	>
> 	>There a really two groups: one is trying to hide the 
> end-user information
> 	>by not disclosing the URIs to the public (I call them 
> the NGN walled gardens)
> 	>and the others which want to disclose the URIs (the 
> zero termination cost
> 	>club),
> 	>and they would like to go into e164.arpa, but do not 
> get delegations in
> 	>their country.
> 	>These guys look for a (temporary, unregulated=quick) 
> solution beside
> 	>e164.arpa, but
> 	>will be at least not lost forever for e164.arpa (at 
> least for some time).
> 	>
> 	>Here at VON Europe a group of UK ITSPs (ITSPA) is 
> considering such a thing on
> 	>an European scale, linking all European virtual VoIP 
> providers together
> 	>with iENUM.
> 	
> 	humm and as you know a group of Asia-Pac CCTLD 
> operators are putting
> 	together thieir own ENUM Engineering group
> 	
> 	http://www.apenum.org
> 	
> 	>
> 	>BTW, Henry said clearly at the the VON Europe that he 
> consideres
> 	>implementations
> 	>not giving out URIs to the end-user not as VoIP.
> 	
> 	Dr. Sinnreich, as usual, is absolutely correct.
> 	
> 	>
> 	>So IMHO there is currently a critical time period for 
> e164.arpa. If e164.arpa
> 	>is not implemented very soon in a wide range of 
> countries, it will be dead.
> 	>One year trial in +1 is definetely too long, and this 
> is also important
> 	>for Europe
> 	>since it seems that many countries, even if the have 
> delegations already,
> 	>are still
> 	>waiting for the US.
> 	
> 	<sigh> well you remember that +1 is a unique problem in 
> herding 19 nation
> 	states together but the progress in recent months has 
> been substantial. The
> 	Canadian ENUM forum is moving forward very quickly the 
> NANP regulators are
> 	in ongoing discussions...etc etc.
> 	
> 	  If North Americans would like the process to move 
> faster they can always
> 	write their MP's, Senators and Congressmen ..the FCC, 
> The CRTC, the DoC etc
> 	etc. I'm told they enjoy letters from constituents.
> 	
> 	>
> 	>Or as James Seng said at the ENUM Workshop in Brunei:
> 	>"The biggest problem in ENUM currently is:
> 	>-Those who want to do trials do not get delegations.
> 	>-Those who get delegations do not know what to do with it."
> 	>
> 	>And I can even add to this: time for trials is over, 
> or it is game over
> 	>(TILT).
> 	
> 	Right ..It works.
> 	
> 	
> 	
> 	 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> 	Richard Shockey, Senior Manager, Strategic Technology 
> Initiatives
> 	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

---

From: Richard Shockey <[email-masked]>
Date: Fri, 11 Jun 2004 12:11:18 -0400

At 11:27 AM 6/11/2004, Lind, Steven D, ALABS wrote:
Richard S.,
As to your proposed agenda item 1, I believe that the direct should be:
1a: What are the issues/problems that need to be addressed?
1b: What are the reasons that "Public" ENUM can't solve them?
Excellent description...

Richard Shockey, Senior Manager, Strategic Technology Initiatives
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