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

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

Yup, pretty much. Though a hit would presumably tell the client how  
to terminate some sort of service for that number via SIP or the PSTN.

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

Nope. All that can be inferred from an NXDOMAIN for a number in this  
scheme is it's not in the DNS. A number could have been ported to  
another provider and the end user for that number hasn't done  
anything about entering it into the public DNS. The number could  
still be in use even if it's not in the DNS. Or it might be in the  
twilight world between "not allocated to a customer" and "ready for  
re-use". IIRC Lawrence and Richard made a compelling case for the  
void: service type NAPTR to be used to indicate whenever a number was  
not in use. I see no justification for disagreeing with that point of  
view.

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

The idea is that if a number is ported, it drops out of the CRUE  
block. The end user for that number could still register it using the  
standard User ENUM registration process and have its ENUM zone  
delegated to them. End user registrations will always supersede a  
CRUE entry. This was the detail I alluded to earlier. And now wish to  
postpone further discussion about until the new web site is up with  
all of the UK ENUM documents.

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

Well we have (mainly VoIP) providers queuing up to try this. They  
don't appear to share your doubts. :-)

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

Michael, you're looking for complexity and scenarios that simply  
don't exist. The client just does a lookup in the public  
4.4.e164.arpa tree. If that returns a sip: URI, the client may (or  
may not) -- it's the client's choice -- try to speak SIP to the named  
SIP server. It neither knows or cares about how that SIP URI was  
entered or who put it there. And it doesn't matter whether that  
client is an end-user or an "operator" is irrelevant. They're just  
clients on the public internet doing regular DNS lookups.

> What if I have a IP Interconnect agreement with BT / what if not? I  
> would assume BT might have an opinion here.. Tony?

You seem to be confused Michael. CRUE has NOTHING WHATSOEVER to do  
with Infastructure or Carrier ENUM. Or interconnect agreements  
between carriers. That subject has never even cropped up while the  
CRUE proposal was being worked on.

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

Michael, I'm trying not to get angry with you. :-) There is only one  
public tree: e164.arpa.
Anything else is not ENUM and not worthy of consideration here. CRUE  
only uses the UK public ENUM tree. The only difference between CRUE  
and the classical User ENUM model is that a provider gets the ability  
to register say 1 million numbers in one operation instead of
numbers being registered and delegated one at a time by the  
individuals owning each number.
If anything, CRUE provides a means of eliminating some of the  
existing alternate trees. [None of the UK providers who are about to  
use CRUE use alternate trees AFAICT.] Instead of each (UK based) VoIP  
provider running their own ENUM-like name space uknown to anyone else  
and being unable to talk to each other, they could in principle enter  
their Ofcom-assigned blocks into CRUE and all share a common,  
consistent tree.