[enum-wg] Follow up on Jim Reid's presentation - CRUE and relation to IETF work

At 10:26 28.04.2006, Jim Reid wrote:

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

Jim -

so it's really NRA block allocations which you're preloading in User 
ENUM - a hit in a block will really tell you that the block is 
allocated to some operator but nothing else, right? That would mean 
basically that a NXDOMAIN in UE can be used for "no such number" 
(SIT) signaling immediately (that is - before bouncing it to the PSTN 
to have that figure it out later), right?

Is it just blocks or can do you plan to add portability-corrected 
NAPTR's as well, like npd:tel URI's?

I agree that populating the tree helps resolution rates, and we're 
following a similar route publishing block allocation information, 
but in the Infrastructure ENUM tree where I think it belongs more 
naturally - plus it retains full operator control over the type of 
information they publish (which we've learned to be a key issue). If 
this is a first step to a DNS-based NPD directory, I'm unsure wether 
the UE tree is the right place to base that information.

I have some doubts that telcos will come forward and have the 
registry publish *for them* what is essentially a 
Point-of-Interconnect information in the User ENUM tree (right?).

But let's assume that happens - what is the semantics of such a SIP 
URI for a) an end user and b) an operator - can I bounce a call to 
sip:number at bt.com if I find  <number> in 4.4.e164.arpa and it returns 
such a registry-entered sip URI? Can I (do I need to?), as a 
end-user, distinguish who entered which record? What if I have a IP 
Interconnect agreement with BT / what if not? I would assume BT might 
have an opinion here.. Tony?

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

I think publishing blocks for real-time lookup is a potentially 
useful idea and it looks like it is more of a "best current practice" 
topic. BUT - the way you describe it: you're setting the rule on who 
enters what and if there is more than one way to publish this 
information I still think there is a interoperability issue because 
semantics of different public trees diverge.

Let me encourage you to bring this idea forward beyond the UK ENUM 
group and work on consensus on how to do this -

-Michael