Subject: [Enum] Please start thinking about agenda items for IETF San Diego etc

From: Richard Shockey <[email-masked]>
Date: Mon, 07 Jun 2004 17:18:00 -0400

Patrik and I will start to accept idea now.
If there are drafts we need to be aware of coming down the pipeline please 
let us know.

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: "Stastny Richard" <[email-masked]>
Date: Fri, 11 Jun 2004 07:45:09 -0400

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

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 11 Jun 2004 11:43:30 -0400

> >i would prefer EPP-e164 to be @ PROVREG instead. discussion 
> maybe, charter,
> >no.
> 
> PROVRED is already shut down.  Its seems appropriate to review the 
> application specifics here but to your point there has 
> unfortunately has 
> not been much discussion on Scott's excellent draft.

Plus, we had this discussion about "which WG?" two *years* ago.  It's a
"draft-enum" document because a discussion that took place during IETF-53
(March 2002) was confirmed on the WG mailing list.

-Scott-

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Sun, 13 Jun 2004 18:33:31 -0400

I can't speak to the service model to be implemented by VeriSign other than
noting that the protocol currently supports both delegation-only and NAPTR
provisioning modes.  The delegation stuff is in the protocol documents
developed by the provreg WG.  NAPTR provisioning is in the enum WG document.
A registry can support one or both modes as appropriate.

-Scott-

> -----Original Message-----
> From: Michael Haberler [mailto:mah at eunet.at] 
> Sent: Friday, June 11, 2004 4:40 PM
> To: Hollenbeck, Scott; 'enum at ietf.org'
> Cc: schisch at nic.at; axelm at nic.at; lendl at nic.at; mib at nic.at; 
> kurt Reichinger
> Subject: RE: AW: [Enum] Please start thinking about agenda 
> items for IETF San Diego etc
> 
> 
> Scott,
> reading your latest draft -
> do I understand this correctly that you plan to run service 
> which combines 
> delegation and NAPTR hosting (= Tier1 and Tier2)?
> I've been working on the "thin Tier1" (NS delegations only) 
> assumption so far.
> What has changed - do other people think collapsing these 
> roles should be 
> done as well?
> -Michael
> At 19:41 11.06.2004, Hollenbeck, Scott wrote:
> > > as a matter of curiousity, anyone interested to implement 
> epp-e164?
> > > please rise your hand if you are.
> >
> >It's a distinct possibility that my employer will be interested in
> >implementing and deploying the extension.
> >
> >-Scott-
> >