Re: [enum-wg] Follow up on Jim Reid's presentation - CRUE and relation to IETF work
Hi Jim,
BTW I don't share your optimism that standardisation of Carrier ENUM can be completed this year. But let's not jump down that rat-hole.
For terminolgy: Carrier ENUM needs not to be standardized, it is Infrastructure ENUM. I agree that the long-term soltution cannot be standardized this year, because the earliest (optimistic) possible date is January 2007 JWhat Michael wanted to say is that the temporary solution defined in the Dallas treaty can be nationally implemented soon (as you will see) and could be ready for publication request this fall, so it could be used also internationally in a standadized way. Another question for clarification about CRUE: You mention that for each number a tel and an sip URI is entered. this requires each operator to provide a ingress element to their network How can this be done? Richard ________________________________ Von: enum-wg-admin@ripe.net im Auftrag von Jim Reid Gesendet: Fr 28.04.2006 10:26 An: Michael Haberler Cc: enum-wg@ripe.net Betreff: Re: [enum-wg] Follow up on Jim Reid's presentation - CRUE and relation to IETF work On Apr 28, 2006, at 07:58, Michael Haberler wrote:
I'm a bit puzzled though about your slides where you mention "CRUE" (Carrier Registration in User ENUM) and its potential international interoperability aspects.
currently the IETF work on Infrastructure ENUM is progressing nicely - I expect the long-run solution to be a separate apex (like ie164.arpa for instance) and http://www.enum.at/ietf/draft-haberler- carrier-enum-02.html will be the backwards-compatible interim solution until ITU and friends have their act together. Looks like all this is done this year. This will provide a easy manageable home for carrier-related information.
Michael, CRUE has no bearing whatsoever on Infrastructure ENUM. This will be apparent when the CRUE document is published on the new UK ENUM web site. [I'll make an announcement about that when it goes on- line.] The object of CRUE is to get lots of meaningful data into the UK ENUM tree so that ENUM-aware applications can be encouraged because there's a better chance of getting a successful ENUM lookup. The scheme is simple. Communications Service Providers register a block of numbers. This gets verified against the regulator's public database of block allocations to CSPs. The registry enters 2 NAPTRs for these numbers: a tel: URI and a sip: URI. The only "control" the CSP has here is the name of the SIP server: ie how non-PSTN calls can be terminated on their network. Now there's a lot of detail about ported numbers, allocation to end users and so forth. But that still doesn't make CRUE a replacement for "Infrastructure ENUM" whatever that happens to mean today. BTW I don't share your optimism that standardisation of Carrier ENUM can be completed this year. But let's not jump down that rat-hole.
I'm a bit concernced about diverging developments - maybe you can enlighten us where you're heading and how this will interoperate with the rest of us.
CRUE is not a "standard". Or a protocol. It's just a means to get lots of NAPTRs populating the 4.4.e164.arpa name space. So there are no interoperability issues.
On Apr 28, 2006, at 09:51, Stastny Richard wrote:
BTW I don't share your optimism that standardisation of Carrier ENUM can be completed this year. But let's not jump down that rat-hole.
For terminolgy: Carrier ENUM needs not to be standardized, it is Infrastructure ENUM.
For some definition of these terms. Maybe. :-) No matter what is meant by Carrier ENUM or Infrastructure ENUM, these two things presumably must agree on a name space. Though not necessarily with each other. That choice of name space or zone apex surely must entail standardisation somewhere. Or have I missed something?
JWhat Michael wanted to say is that the temporary solution defined in the Dallas treaty can be nationally implemented soon (as you will see) and could be ready for publication request this fall, so it could be used also internationally in a standadized way.
If you're referring to draft-haberler-carrier-enum-02.txt, I think you are being far, far too optimistic. This draft is badly flawed in too many ways to elaborate here. A discussion on that belongs in another thread and I'll be happy to initiate this debate.
Another question for clarification about CRUE:
You mention that for each number a tel and an sip URI is entered. this requires each operator to provide a ingress element to their network
How can this be done?
I imagine the hostname lurking in the sip: URI would do that. No?
On Apr 28, 2006, at 09:51, Stastny Richard wrote: ...
JWhat Michael wanted to say is that the temporary solution defined in ...
If you're referring to draft-haberler-carrier-enum-02.txt, I think you are being far, far too optimistic. This draft is badly flawed in too many ways to elaborate here. A discussion on that belongs in another
Jim - we're all very very eager to hear and discuss your most helpful contributions. Help make the world a better place and stamp out such badly flawed drafts. To do so, please: a) detail your concerns on the IETF ENUM WG list (that's where this stuff is being discussed) b) in time (that is, like half a year ago, but late adopters welcome) c) including facts, so you actually convince people d) [optional] make a better proposal (those which yield a really loud hum). I'll support you on your superior superior proposal. -Michael
we're all very very eager to hear and discuss your most helpful contributions.
Help make the world a better place and stamp out such badly flawed drafts.
To do so, please:
a) detail your concerns on the IETF ENUM WG list (that's where this stuff is being discussed) b) in time (that is, like half a year ago, but late adopters welcome) c) including facts, so you actually convince people d) [optional] make a better proposal (those which yield a really loud hum).
I have done a, b, and c already on the IETF mailing list and will be happy to do so again.
I'll support you on your superior superior proposal.
You'll have a very long wait because it's not clear to me what the actual problem is or what its requirements are. And yes, I know you have a list of requirements in the draft. But they don't define what problem space(s) fit them. That said, it is clear that your draft can't be the answer because it combines two mutually exclusive concepts -- User ENUM and Infrastructure ENUM -- on the same infrastructure.
participants (3)
-
Jim Reid -
mah＠inode.at -
Stastny Richard