Subject: [Enum] Send-n, rat holes and real issues

From: Jay Daley <[email-masked]>
Date: Wed, 2 Jul 2008 22:38:56 +0100

It appears to me that this discussion is actually getting somewhere 
sensible.  The following rat holes appear to have been exposed as bogus:

1.  This is not /just/ about a fully populated tree for a national number 
space.  If you take a different example, like a tree of only ported 
numbers, or a private tree shared by a group of carriers then it does not 
matter what the regulator knows. 

In those cases the shape of the tree is determined by the data that is put 
in it and _solely_ by the data put in it, so no outside data 
representation is of any use.  Protocols that describe the dial plan or 
numbering plan are orthogonal to this draft.

2.  The views of some people that overlapped dialling should not be used 
cannot be tackled by this draft.  It exists, it is used and that is that. 

3.  According to all the DNS experts the treatment of wildcards is not an 
issue.

So that leaves us with the following real issues that are actually worth 
discussing.  The first two are more about DNS:

a. Whether or not we need a more general mechanism to describe the shape 
of the tree rather than the something just for ENUM?  Also expressed as 
whether there should be meta-data in the tree about the tree (and whether 
NAPTR is a good way to do that)?

b. What is the trust/security implication from one label in the tree 
making a statement about later labels in the tree even though they might 
be under different administrative control?

and the second two are specifically about send-n:

c. Is the relative form of send-n worth the trouble?

d. Is the trade off between extra records vs reduced lookups worth it?

Any more real issues?

Jay
_______________________________________________
enum mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/enum

---

From: Eleanor McHugh <[email-masked]>
Date: Thu, 3 Jul 2008 00:17:51 +0100

> d. Is the trade off between extra records vs reduced lookups worth it?

e. This is probably covered by point (b) above, but I think it needs  
explicit consideration: if a NAPTR is being used (a la send-n), what  
are the implications of non-terminals and should they be restricted?

Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 2 Jul 2008 22:22:12 -0400

I claim this should be about determining the length of numbers, and not a
solution to overlapped dialing. The length of the number 99% of the time is
totally a function of a regulator.  The other 1% of the time, the regulator
allocates a prefix, and a carrier, or in some cases an enterprise,
determines the length of the suffix.  We need a solution for that 1%, but
it's 1% and the 1% probably ought to not be the tail wagging the dog.

While I understand that this draft proposes a way for someone to get a
number length out of an ENUM tree, I propose that we solve the general
problem, which I believe is an acceptable solution applicable to the
overlapped dialing problem.  I'm not fussy about what the solution look
like, although I want it to be useful to the entity creating an ENUM tree as
well as an entity using ENUM.

Brian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Jay Daley
> Sent: Wednesday, July 02, 2008 5:39 PM
> To: [email-masked]
> Subject: [Enum] Send-n, rat holes and real issues
>

---

From: [email-masked]
Date: Thu, 3 Jul 2008 08:47:57 +0100

> are the implications of non-terminals and should they be restricted?

Yes, if NAPTRs are used for Send-N then they should not be used in 
non-terminal NAPTRs.

That's currently implicit in the draft (as indeed it appears to be in 
Richard's CNAM draft) because the only valid form for a Send-N is as 
described in the regexp field.  I'll make it more explicit.

Ray

---

From: "Jay Daley" <[email-masked]>
Date: Thu, 3 Jul 2008 10:07:30 +0100

Brian

> solution to overlapped dialing. [rest snipped]

Apologies in advance if this comes across as rude, I don't mean it to.

You've presented this view several times now and on at least a couple of 
those occasions a reply has been given explaining why your view is about 
something quite different from send-n, except in one edge case. Yet it 
doesn't appear that you have addressed that response.  So I'm going to 
have one more go at explaining this and I would really appreciate you 
responding to this rather than restating your view.

1.  There are a number of different types of ENUM tree out there in use. 
They include:

a) National full number trees, fully populated (or almost) according to a 
national numbering plan
b) National user trees, scarcely populated with no algorithmic or other 
descriptive means of saying what numbers are in the tree.
c) National number portability trees, partially populated.  Again with no 
descriptive means of saying what numbers are in the tree.
d) Inter-carrier trees, be definition only partially populated and both 
with and without external descriptions of what numbers are in the tree.
e) Lots of other private trees.

2.  The only type of tree from the list above where the type of plan you 
are proposing would obviate the need for send-n is a).  In all the other 
cases, because the tree is not fully populated, only a description of what 
numbers are _actually_ in the tree is of any use.

3.  You could of course maintain a separate database for b) and c) with a 
list of all numbers in the tree, using something like the protocol you 
propose, but I am hoping you are not proposing that because the 
duplication of effort, processing overhead and overall complexity would be 
astonishing. 

4.  I agree totally that we need a the type of protocol that you are 
proposing.  In fact I think it would be very valuable, more so than 
send-n, and I am willing to commit resources to work on it with you if you 
wish.

However it is still completely orthogonal to send-n.

Jay

---

From: "Rosbotham, Paul" <[email-masked]>
Date: Thu, 3 Jul 2008 12:13:28 +0100

I can only speak from the perspective of having a variable length dialling plan nationally, and having to deal with complex number length tables internationally.  I'm no DNS expert so this is from a requirements perspective;

> c. Is the relative form of send-n worth the trouble?

The relative form arose partially from a standpoint of simplifying renumbering, but more for historic reasons.  Our UK variant of C7 has the concept of SND(n), which terminating switches send back to originating switches when the number length is insufficient, asking for n more digits.  The concept of SEND-N in DNS was devised to mimic that, albeit with a database (DNS) providing the info rather than the terminating node.  Since SND(n) gave the number of extra digits needed, SEND-N did the same, in order to keep the call handling engine the same.  If it causes issues, I wouldn't die in a ditch about it.

> d. Is the trade off between extra records vs reduced lookups worth it?

Given the hassle of maintaining the number length tables, I'd say an emphatic yes.  It's all very well saying ENUM is specified to be queried with a complete number, but that's precious little use if you've no idea whether the number you've got is complete or not.  Take a look at Section 3.3 of http://www.nicc.org.uk/nicc-public/Public/guidelines/nd1423_2007_06.pdf , which provides an overview of number lengths in some countries and it'll become clear how complex that is.  Regretably, regulators (more properly numbering plan administrators) aren't always the best at publishing correct information hence there's various international informal circles of databuild guys continually trying to update the pieces of the jigsaw (not to mention commercial organisations who'll help for a fee).  I know there's information at the ITU-T website...as it happens I initiated that about 7 or 8 years ago...but it's far from comprehensive.  So in a fully populated ENUM situation incorporating number length info seems a pragmatic way forward.

In a partially populated situation as you subsequently described, it seems to me even more so.  What matters is the length of the numbers in there, not the theoretical length of numbers that would plug the gaps.

> Jay

This e-mail has been scanned for viruses by the Cable & Wireless e-mail security system - powered by MessageLabs. For more information on a proactive managed e-mail security service, visit http://www.cw.com/uk/emailprotection/ 

The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies.
 
Cable and Wireless plc 
Registered in England and Wales.Company Number 238525 
Registered office: 3rd Floor, 26 Red Lion Square, London WC1R 4HQ
_______________________________________________
enum mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/enum

---

From: Duane <[email-masked]>
Date: Thu, 03 Jul 2008 21:22:48 +1000

Rosbotham, Paul wrote:

> The relative form arose partially from a standpoint of simplifying
> renumbering, but more for historic reasons.  Our UK variant of C7 has
> the concept of SND(n), which terminating switches send back to
> originating switches when the number length is insufficient, asking
> for n more digits.  The concept of SEND-N in DNS was devised to mimic
> that, albeit with a database (DNS) providing the info rather than the
> terminating node.  Since SND(n) gave the number of extra digits
> needed, SEND-N did the same, in order to keep the call handling
> engine the same.  If it causes issues, I wouldn't die in a ditch
> about it.

Just because that's what happened in the past is no reason to keep doing
the same thing if there is better ways to achieve the same result.

> Given the hassle of maintaining the number length tables, I'd say an
> emphatic yes.  It's all very well saying ENUM is specified to be
> queried with a complete number, but that's precious little use if
> you've no idea whether the number you've got is complete or not.
> Take a look at Section 3.3 of
> http://www.nicc.org.uk/nicc-public/Public/guidelines/nd1423_2007_06.pdf
> , which provides an overview of number lengths in some countries and
> it'll become clear how complex that is.  Regretably, regulators (more
> properly numbering plan administrators) aren't always the best at
> publishing correct information hence there's various international
> informal circles of databuild guys continually trying to update the
> pieces of the jigsaw (not to mention commercial organisations who'll
> help for a fee).  I know there's information at the ITU-T
> website...as it happens I initiated that about 7 or 8 years ago...but
> it's far from comprehensive.  So in a fully populated ENUM situation
> incorporating nu mber length info seems a pragmatic way forward.
> 
> In a partially populated situation as you subsequently described, it
> seems to me even more so.  What matters is the length of the numbers
> in there, not the theoretical length of numbers that would plug the
> gaps.

Again, where is the flaw in using a BGP like distributed routing table,
this would seem to be the most efficient to me, since nothing would need
to make any requests until the internal dial plan conditions were met.

The only data broad casted outwards would be incremental updates as
information changes, rather than keep banging away at DNS requests until
everything is satisfied that the full number is done.

Unlike TRIP this shouldn't be used to update route costs as well, a very
very simple protocol carrying just the numbering length.

-- 

Best regards,
 Duane

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 3 Jul 2008 11:32:16 -0400

> responding to this rather than restating your view.
Actually, my view is you guys are duplicating the PSTN for a subclass of a
general problem, and you won't look beyond the copy of the existing solution
in a whole new world.  Our experience in the IETF is that nearly every time
we emulate the PSTN, we come to regret it.  When we look at the PROBLEM and
then design a good Internet solution to that problem, we are better off. 

You have a problem: how do you know how long a number is.  I think it's a
real problem.  You have a solution, which is "emulate the PSTN".  I think
that's a poor solution to a real problem. 

> e) Lots of other private trees.
I agree there are lots of ENUM trees out there, some of which are not
complete.

> numbers are _actually_ in the tree is of any use.
This is incorrect. 

I claim there is never harm in having the information that comes from the
regulator, regardless of the completeness of the tree.  In the 1% case where
there is variability of number length, the variable data need not be
complete.

I will admit to being concerned about getting the variable data FROM THE
AUTHORITATIVE SOURCE.  Send-n is indirect; the variable data is obtained
from an authoritative source which is then provided to users by the ENUM
operator.  It's fine with me if the variable data comes from, say, the ENUM
operator if someone wants or needs to do that.  That may need the protocol
to accommodate such arrangements.

> duplication of effort, processing overhead and overall complexity would be
Nope.  The source of the variable data, where it exists, can supply data for
only a subset of a full tree.  

> send-n, and I am willing to commit resources to work on it with you if you
Great

> However it is still completely orthogonal to send-n.
Why?  If you had the data I propose to get, it solves the send-n problem,
right?  Why would we want two ways to get the same information?

This is the crux of the discussion we are having.  You think send-n is
solving a different problem, rather than a subset of a general problem.  I
think send-n solves a subset (overlapped dialing) of a general problem, and
I want a single solution to the whole problem.

---

From: Peter Koch <[email-masked]>
Date: Thu, 3 Jul 2008 18:03:25 +0200

Hi Jay,

thanks for the summary. Alas, there are some details I disagree with.

> cannot be tackled by this draft.  It exists, it is used and that is that. 

Well, yes, but the question remains whether this issue is to be solved within
I-ENUM or before I-ENUM-Queries are generated or whether this is an issue
at all.

> 3.  According to all the DNS experts the treatment of wildcards is not an 

I'd rephrase that to say that I'd see no protocol issues (... "breaks" ...),
but there might remain operational challenges.  However, this is closely
related to (c) below.

> NAPTR is a good way to do that)?

Likely out of scope for this WG.

> d. Is the trade off between extra records vs reduced lookups worth it?

Where this includes the question what that trade-off actually is.  Also,
this isn't just about "extra records", it is also about cluttering the tree.

-Peter

---

From: "Pete Cordell" <[email-masked]>
Date: Thu, 3 Jul 2008 17:20:34 +0100

- Original Message From: "Brian Rosen"
To: "'Jay Daley'"
> I want a single solution to the whole problem.

Can you give some more examples of what the "general problem" is?  I'm not 
really getting that from your messages.

Also, what do you mean by overlap dialling here?  There's obviously the 
Q.931/SS7 way of doing overlapped sending with INFORMATION messages etc.  Or 
do you use the term in a more abstract sense as in a process of dialling a 
number without having to press a 'Send' button at the end?

To me send-n is a way to iteratively determine the minimum length of an 
E.164 number.  That knowledge does allow you to do overlap dialling (in the 
sense of dialling without having to press a send button at the end), but it 
would also allow you answer pub quiz questions along the lines of "what are 
the minimum number of digits you would have to dial to get a connected call 
for a number that started +44336?" when no dialling is actually involved.

Thanks,

Pete Cordell
Codalogic

---

From: "Jay Daley" <[email-masked]>
Date: Thu, 3 Jul 2008 17:27:09 +0100

Peter

> I-ENUM or before I-ENUM-Queries are generated or whether this is an 
issue

You cannot legislate overlap dialling away by protocol design.  People 
have already said they will use it and the implications of that are clear. 
 If you want to say "I would rather we lived with the extra lookups than 
agree to send-n" then that is fine - it is basically an answer to d) 
below. 

BTW this is all ENUM not just I-ENUM.

> but there might remain operational challenges.  However, this is closely

Fine by me.

> Likely out of scope for this WG.

I agree entirely it would be if that is the way the answer went.  But we 
first need to agree whether to go this way or something more specific like 
send-n or whether to do nothing.

> this isn't just about "extra records", it is also about cluttering the 
tree.

I meant that as well in the phrase "extra records".  There are lots of 
reasons people might not want the extra records.

Jay

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 3 Jul 2008 14:07:31 -0400

Please read the thread.  The general problem is determining the length of a
number.  The subset is the problem of overlapped dialing where the endpoint
is sending digits blindly and the network doesn't know what the length of
the number is.

Other examples I have given include:
1. Validating the shape of an ENUM tree by the ENUM operator.
2. Intelligent end devices with SEND buttons and clever GUIs that react well
3. Proxy servers and other systems validating numbers before attempting to
route
4. Routing and rating systems diagnosing problems
The general problem of determining the length of a TN is a good problem.  I
think we should solve it.  Solving overlapped dialing by emulating how the
PSTN does it is, in my opinion, a poor choice of solution.

And, echoing Peter Koch, enum may not be the appropriate work group to solve
the problem.

Brian

> From: Pete Cordell [mailto:[email-masked]]
> Sent: Thursday, July 03, 2008 12:21 PM
> To: Brian Rosen; 'Jay Daley'
> Cc: [email-masked]
> Subject: Re: [Enum] Send-n, rat holes and real issues
>

---

From: "Pete Cordell" <[email-masked]>
Date: Thu, 3 Jul 2008 20:41:38 +0100

> Please read the thread.

I have been.  I might have missed stuff though.

> The general problem is determining the length of a

Doesn't a regular SIP UA have the same issue - knowing when it's got 
sufficient digits to get a final URI?  Send-n can work in that case also. 
Surely it's not all about carriers?

> 1. Validating the shape of an ENUM tree by the ENUM operator.

How does your web service proposal improve on this?

Presumably this is mainly a problem when an ENUM operator delegates a number 
range to a customer.  Is it the ENUM operators responsibility to monitor 
that tree any more than it is ICANN's (or is it Versign or someone) 
responsibility to monitor the shape of the .com tree?

> 2. Intelligent end devices with SEND buttons and clever GUIs that react 

Since such devices are relying on a user to tell them the length of a number 
I don't see that this needs solving.

> 3. Proxy servers and other systems validating numbers before attempting to

Why can't Send-n do this?  Surely you just do the relevant DNS query?

> 4. Routing and rating systems diagnosing problems

How does the web service solution improve this?

> PSTN does it is, in my opinion, a poor choice of solution.

I'm just not seeing how your web service proposal offers anything that 
Send-n doesn't.  They both allow you to find out how many digits you have to 
dial to get an end device.

> And, echoing Peter Koch, enum may not be the appropriate work group to 

That may be.

I'm coming from a position of a UK user that doesn't want their (or their 
mum's) dialling experience to suffer when the future finally arrives.  My 
perception is that many in the US and other parts of the world don't 
consider variable length numbers an issue, and it's gnarly details shouldn't 
contaminate their beautiful technology.

We also have to bear in mind that mobile phones are no longer (well, 
probably never have been) the smallest devices to connect to the internet. 
Why should your fridge download a megabyte table just to be able to tell you 
it needs defrosting.  There are also very small IP enabled ZigBee devices 
that we shouldn't prevent from using ENUM.

On that note, we shouldn't assume that such devices are always on either.  I 
turn off my PCs at night to do my bit to help save the planet.  (I hope 
everyone reading this does also!)  To me that suggests that a push update 
system is not appropriate.

I personally wouldn't care whether the whole solution is turned over to a 
web service type solution as long as satisfactory user experience was there. 
I find it difficult to think that a system that starts out doing web service 
queries, and then switches over to doing DNS queries is sensible.  It should 
be all web service, or all DNS.  Not only does that seem aesthetically more 
pleasing to me, I would have thought it would make it easier to maintain 
coherency of the data.

Thanks,

Pete.
--
=============================================
Pete Cordell
Codalogic
=============================================

---

From: Jay Daley <[email-masked]>
Date: Thu, 3 Jul 2008 21:19:48 +0100

Brian

> right?  Why would we want two ways to get the same information?

It only solves the send-n problem if:

* every device that is going to do the ENUM lookup is pre-loaded with 
every data document for every country that might be dialled.
* the tree being queried is sufficiently densely populated so that the 
number of times there is no number found (despite being in the number 
plan) is minimised.

send-n on the other hand:

* does not require any device to be loaded with any document
* does not require the tree to be filled in any way

Jay

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 3 Jul 2008 19:34:22 -0400

> Surely it's not all about carriers?
No, Send-N cannot work in those cases.  First of all, that would mean that
the UA is doing repeated ENUM dips, and except in the case of User ENUM
(which doesn't seem to have much traction), is not possible.  It's also, for
intelligent SIP UAs the wrong mechanism because they use something akin to
an MGCP digit map to interpret user GUI interactions.  

Think of a device which knows when it has enough digits that behaves as if
it had a SEND button, but actually the call is automatically placed when the
terminal digit is dialed.  Regardless, the UA wants to have the dialing
plan, not send-n.

> responsibility to monitor the shape of the .com tree?
No.  As an example, the ENUM operator would wish to validate that a number
is a good number before allowing provisioning on the number.

I can speak from some level of experience here, and having good number
length data is very useful when you are operating an ENUM database.

> I don't see that this needs solving.
I think this is incorrect.  You are repeating the current mobile experience,
where it is entirely the user's responsibility to know when enough digits
have been dialed, and the system's only response is an error tone or
announcement which, typically, is not helpful.  If the device knows that the
number so far entered is not yet complete, it can alert the user of that
fact, either before or after SEND is pressed.

> Why can't Send-n do this?  Surely you just do the relevant DNS query?
Because the entity with ENUM access is typically not the entity doing the
validation.  Typically, the ENUM query is at a border element, whereas the
validation function is closer to the user.

> How does the web service solution improve this?
Because the mechanism tells you how long a number is.  It tells you what
good numbers look like.  It gives you the whole picture.
If you have a number, and it fails to route, you can easily determine what
is wrong if the problem is too many or too few digits.  Send-N couldn't do
that, at least easily.

> dial to get an end device.
In the end, you can, by doing enough queries, determine the shape of the
tree, so yes, send-n can be used for everything but validating the enum
database shape (which is a chicken and egg problem for send-n).  On the
other hand, it's pretty darn inefficient to figure out a dialing plan by
doing a bunch of enum queries to get the shape of the number plan.  Think
about how you would go about creating an MGCP style digit map using send-n.
> contaminate their beautiful technology.
On the contrary, no one is arguing that we shouldn't have a solution that
allows overlapped dialing using black phones but ENUM routing to work. What
I'm saying is that it should be possible to improve user experiences with
newer devices, and other parts of the solution space need number length
data.
> that we shouldn't prevent from using ENUM.
Then keep the data at the proxy and let the user device do something
simpler.  The end device doesn't do ENUM, although I agree we don't prohibit
that and shouldn't.  Since it seems to be a fact that they don't, perhaps a
different solution is better.

> system is not appropriate.
Not sure who is promoting push update.

> pleasing to me, I would have thought it would make it easier to maintain
Well, I suppose it's the notion that if we are talking about an intelligent
device, first they do some kind of digit map thing, then they do some kind
of routing thing.

They aren't the same thing.  ENUM is a routing database.  This isn't a
routing problem.  It's actually a UI problem, at least the part you are
working on.

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 3 Jul 2008 20:00:57 -0400

> number of times there is no number found (despite being in the number
Nah, I don't think you will preload everything, just cache what you use the
most.  Download whatever else you need on demand.

The data I'm proposing gives you validation of number length.  It doesn't
tell you that you have a working number.  It gives you the information you
need to invoke routing.

In many systems, you won't get information on whether a given service is
available on a given number until you actually try to invoke the service.
I'm not too thrilled with that, but it's the way things work in some cases
now.  If we fixed that, then the actual ENUM query would get you that
information.  However, as I said, in general, the device in the network that
has ENUM access is at the border of the network and the device that handles
something like dial plan interpretation is near the user, so you would have
to have some other mechanism to propagate the information back towards the
proxy server doing the dial plan interpretation, or have more systems with
ENUM access.  The latter has its own operational issues.  That kind of thing
is solvable, but it's an indication to me that the solution has not yet been
thought all the way through.

Brian

---

From: "Jay Daley" <[email-masked]>
Date: Fri, 4 Jul 2008 11:15:45 +0100

Brian

> most.  Download whatever else you need on demand.

Whether you preload or cache and download on demand, is still the same 
thing.  Your solution means any device that will do ENUM lookups needs 
access to a great big database.

> tell you that you have a working number. 

Exactly!!  Which is why we need send-n.

Jay

---

From: "Jay Daley" <[email-masked]>
Date: Fri, 4 Jul 2008 11:28:46 +0100

Here's a much simpler way of putting it:

Your proposal can tell whether there *could be* a number of a particular 
length, send-n can tell whether there *is* a number of a particular 
length.

send-n is only about one tree, your proposal may cover multiple trees.

These are two very different, but complementary, requirements. 

Jay

---

From: Duane <[email-masked]>
Date: Fri, 04 Jul 2008 20:35:21 +1000

> Exactly!!  Which is why we need send-n.

Just because you need a solution to a problem doesn't mean it must
replicate what PSTN systems already do that's just crazy.

Has no one actually got a valid criticism for my suggestion of doing
this as a routing type protocol rather than this hack job on ENUM?

Seems most ignored my suggestion completely except for one remark about
TRIP.

-- 

Best regards,
 Duane

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 4 Jul 2008 14:58:43 -0400

No.

Send-n can't necessarily tell you that unless the ENUM tree is provisioned
with each separate number.  Real systems don't necessarily do that.  Many,
including ours, lets you provision a range of numbers, and you won't be able
to tell if the number is actually valid unless you try it.  That is what I
meant.  The information on number length is not equivalent to working
number, and never could be.  

Brian

> From: Jay Daley [mailto:[email-masked]]
> Sent: Friday, July 04, 2008 6:29 AM
> To: Brian Rosen
> Cc: [email-masked]

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 4 Jul 2008 15:04:50 -0400

As I said, I don't much care exactly how we get number length, as long as
it's the full length in some reasonably complete form.
  
The general problem of distributing the data is hard, because regulators,
carriers and even enterprises are the authoritative source, and getting all
of them to cooperate and be trustworthy to each other is hard.

Brian

> Sent: Friday, July 04, 2008 6:35 AM
> To: [email-masked]

---

From: Duane <[email-masked]>
Date: Sat, 05 Jul 2008 05:14:26 +1000

> of them to cooperate and be trustworthy to each other is hard.

Isn't the same true of BGP?

-- 

Best regards,
 Duane

---

From: Jay Daley <[email-masked]>
Date: Sat, 5 Jul 2008 09:49:01 +0100

Brian

> number, and never could be. 

Eh?  I have no idea what the first three sentences of that paragraph mean. 
 I'd be grateful if you could have another go at explaining that.

I understand your last sentence from your perspective - that a number with 
an identified SIP endpoint may still not be "working" but I don't get the 
logic of how it applies here - you are quite right that send-n can't deal 
with that but then neither can anything else!

Jay

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 7 Jul 2008 09:43:43 +0200

> Seems most ignored my suggestion completely except for one remark about

We (including speermint) have been though that discussion already 
a few times. A BGP-like protocol for numbers (or better: prefixes)
just won't scale.

One part of what makes BGP work for IP routing is the aggregation
properties of IP addresses: large blocks are given to ISPs, which give
out smaller blocks to enterprises, or just individual addresses to
end-users.

The rest of the world doesn't care how this ISPs handed out addresses, a
single entry in the global routing table suffices.

It used to be the case that phone numbers worked in a similar fashion:
country codes, block allocation, individual number assignment. Perfect
for prefix-based routing.

Now add one table-spoon of "number portability" to your stew, season
it with "premium rate" and "freephone" numbers and watch your routing
tables explode.

More technically: phone numbers used to be addresses. Now they are
names. It used to be that the equivalent of phone numbers were IP
addresses. This no longer holds. If you really want to compare them to
Internet objects, take domain names.

So, how do *you* like the idea of a BGP like routing protocol for domain names?

/ol
-- 
// Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933
// nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H
// http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg
_______________________________________________
enum mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/enum

---

From: Duane <[email-masked]>
Date: Mon, 07 Jul 2008 22:13:30 +1000

> a few times. A BGP-like protocol for numbers (or better: prefixes)

Why would DNS scale any better?

> out smaller blocks to enterprises, or just individual addresses to

Lets be clear here, we're not talking about routing, just prefixes and
there is a HUGE difference because there is much less problems with
security implications at the very least.

> single entry in the global routing table suffices.

Again, you are confusing things here between prefixes and routing, we're
not talking about routing just prefix lengths, the rest of your comments
are along the same line.

-- 

Best regards,
 Duane

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 7 Jul 2008 15:27:13 +0200

> Why would DNS scale any better?

Compare the # of domains out there with the number of routes in the
global BGP routing table. Roughly, there are 3 orders of magnitudes 
between the two.

> not talking about routing just prefix lengths, the rest of your comments

Think.

Who announces a length for a prefix? The carrier (or enterprise) who
operates the prefix. Given any leeway from the NRA, he is the only
one who definitly knows.

Any porting operation leads to someone to announce the length of the
number/prefix he just ported in. With open numbering plans, this ported
number does not need to have the same length as before.

Thus, taking open numbering plans into account, the size of the
BGP-like *whatever* table is O(#blocks + #ported numbers).

/ol

---

From: Edward Lewis <[email-masked]>
Date: Mon, 7 Jul 2008 10:40:32 -0400

>Otmar Lendl wrote:

Otmar made some good observations.

>Why would DNS scale any better?

DNS scales larger than BGP in the sense that the data held by DNS 
does not travel like the data held by BGP.  Let's say you have 
10,000,000 phone numbers with number portability.

In DNS I would need to have 10,000,000 NAPTR sets residing in a 
handful of servers (all under my administrative control) in key 
places.

In BGP, without aggregation, I would have to see that 10,000,000 
route entries would have to be sent to all of the routing points 
globally, not all under my control.

That's the idea in a nutshell - DNS does not attempt to move the data 
model everywhere, BGP does.  (Note - this is not a stab at BGP, the 
jobs of the two protocols are different.)

>security implications at the very least.

I think the point Otmar is making is that when you look at a IPv4 
address, the first N bits determine where all the 32-N bit addresses 
are.  I.e., a 10.10.10/24 route (if none are more specific) will be 
the path for all 256 numbers in 10.10.10.0-255.  But for +1-571-555, 
not all 10,000 below what will be routed the same way.

The obsevation of Otmar that I think is great is that telephone 
numbers, when backed by number portability, are no longer network 
addresses but are network names.  Yet, an IP address is just an 
address, not a name.  A lookup service (like DNS) or a 
directory/database deals with names better than addresses, a routing 
service deals with addresses better than names.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Never confuse activity with progress.  Activity pays more.
_______________________________________________
enum mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/enum

---

From: Peter Koch <[email-masked]>
Date: Mon, 7 Jul 2008 18:52:43 +0200

> service deals with addresses better than names.

that depends on the properties of the number space used for these addresses.
DNS lacks some of the BGP features that are implicitly asked for here,
be that visibility (application of filters) or response modification based
on client identity.
The question whether the IP address space or the E.164 space will turn out
to be "more flat" in the end is moot, say: "PI".  Well, multihoming is
another interesting, albeit unrelated, issue.

So, with a BGP model being "worse" that doesn't make "DNS" a good choice,
just a less bad one. And there are other protocols that might fit even
better: using IRIS+RFC 4414 as a substrate could solve a couple of problems
at once.

-Peter

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 7 Jul 2008 14:34:25 -0400

In our enum implementation, the number holder (carrier) can provision an
entire range of numbers with a single provisioning action.  If the "pattern"
of the NAPTRs is the same, then provisioning is simplified.  A query to any
number in the range will return a result determined by pattern.  NAPTRs use
regexps, and we use that.  So, the rule may be (details omitted)
sip:\[email-masked];user=phone, and could be applied to a range, say
+4412340000 through +4412349999

The provisioning action may apply to the entire range.  There is no
requirement that each and every number in the range be active (what I meant
by "working").  An enum query to +4412341234 would return
sip:[email-masked];user=phone

Nothing fancy, but you can't infer that +4412341234 is a valid number with
active service. 

Brian

> Sent: Saturday, July 05, 2008 4:49 AM
> To: Brian Rosen
> Cc: [email-masked]

---

From: Duane <[email-masked]>
Date: Tue, 08 Jul 2008 10:32:01 +1000

> global BGP routing table. Roughly, there are 3 orders of magnitudes 

Ok I think things are getting confused between routing and prefix
lengths here again. If route information is store there would be a lot
of data, if only prefix information is stored you store the general
cases then simply add exceptions as needed, the 1% Brian was pointing
out in an email the other day.

> BGP-like *whatever* table is O(#blocks + #ported numbers).

You are thinking about this wrong, the only time someone needs to
announce a prefix is if the length is different, countries with fixed
length dial plans would have very few entries.

Take Australia for example, I downloaded the entire file of allocated
numbers from the regulator a while back and ran a script across it.

http://www.e164.org/wiki/AU_Dialplan

For the entire country there is only 30 or 40 lines to describe the
entire prefix set 100% perfectly, this includes numbers that have been
ported, free phone numbers, so on an so forth.

Lets be clear here, we're only dealing with prefix lengths, and only
those that vary need to be stored as exceptions from the majority.

-- 

Best regards,
 Duane

---

From: Duane <[email-masked]>
Date: Tue, 08 Jul 2008 10:35:18 +1000

Edward Lewis wrote:

> DNS scales larger than BGP in the sense that the data held by DNS does
> not travel like the data held by BGP.  Let's say you have 10,000,000
> phone numbers with number portability.

But we're not talking about routing, we're talking about prefixes.

> are.  I.e., a 10.10.10/24 route (if none are more specific) will be the
> path for all 256 numbers in 10.10.10.0-255.  But for +1-571-555, not all
> 10,000 below what will be routed the same way.

Exactly, the problem is very similar, you can list the average case,
Brian's 99% and then the 1% exception you simply fill in the records as
needed.

> The obsevation of Otmar that I think is great is that telephone numbers,
> when backed by number portability, are no longer network addresses but
> are network names.  Yet, an IP address is just an address, not a name. 
> A lookup service (like DNS) or a directory/database deals with names
> better than addresses, a routing service deals with addresses better
> than names.

Number portability has *NOTHING* to do with prefix lengths. unless the
owner suddenly decides to increase the number space.

-- 

Best regards,
 Duane

---

From: Otmar Lendl <[email-masked]>
Date: Tue, 8 Jul 2008 11:54:49 +0200

> length dial plans would have very few entries.

If it were that easy everywhere and in all cases, we would not be
talking about this.

> numbers from the regulator a while back and ran a script across it.

Doesn't surprise me. Now do the same trick for Austria and Germany.

In the .au case, your sole data-source is the NRA. If that would hold
everwhere, then Brian's proposal could work: these numbering-plans
could be easily aggregated into a single database. (Why the hell you
want to do something BGP like for that, I just can't grasp.)

The trouble, and the reason for the send-n proposal, is the fact that
the NRA of .uk does NOT know the number lengths for all numbers in its
country-code. The same holds for .at, .de and probably a few more.

/ol

---

From: Duane <[email-masked]>
Date: Tue, 08 Jul 2008 20:46:09 +1000

> country-code. The same holds for .at, .de and probably a few more.

I'm guessing the UK is more inline with Australia than Austria, well
Australia would have copied the UK but in any case, from what has been
expressed the problem as I see it is that the majority of routes follow
a fixed dial plan but there are exceptions and the whole point of send-n
is to cover the exceptions.

Can someone in the UK doing send-n please give us a rough idea of the
ratio of known and unknown rather than everyone keep speculating over
the scale of this.

-- 

Best regards,
 Duane

---

From: [email-masked]
Date: Tue, 8 Jul 2008 12:03:25 +0100

> ratio of known and unknown rather than everyone keep speculating over

As far as I know the UK regulator does actually have a very good idea of 
the number lengths, although the published information isn't always 100% 
up-to-date.

The UK issue is the very large size of the prefix->length table, and the 
need to accurately maintain it in every switch in the UK telephone 
network.

Currently a mixture of static tables and ISUP SND is used, but with NGN 
interconnect over IP coming soon the latter method won't be available.

Ray

---

From: Duane <[email-masked]>
Date: Tue, 08 Jul 2008 21:04:17 +1000

> the number lengths, although the published information isn't always 100% 

Do you have a URI or data set I can run a script over?

-- 

Best regards,
 Duane

---

From: [email-masked]
Date: Tue, 8 Jul 2008 12:17:54 +0100

> Do you have a URI or data set I can run a script over?

It's all at 
http://www.ofcom.org.uk/telecoms/ioi/numbers/numbers_administered/

Ray

---

From: Duane <[email-masked]>
Date: Tue, 08 Jul 2008 23:56:14 +1000

> http://www.ofcom.org.uk/telecoms/ioi/numbers/numbers_administered/

Length is one of the fields in both the excel files and CSV files but
doesn't seem to be in any rows, you said the regulators has a fair idea
of this information, do they publish it at all?

-- 

Best regards,
 Duane

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 8 Jul 2008 12:08:41 -0400

Please note that my proposal works in every circumstance.  Each
authoritative source of number length data provides the data for the part of
the tree it is authoritative for.  This could be a carrier, but it could
even be an enterprise.

It makes a small database.  "Small" is in the current notion of databases.
The kind of database where many of them fit in the disk drive of a US$250
computer.  I can't imagine why any new system could possibly be concerned
about keeping a cache of such a database.  Since ENUM and this RR is new,
we're talking about new systems.

Brian

> Otmar Lendl
> Sent: Tuesday, July 08, 2008 5:55 AM
> To: Duane
> Cc: [email-masked]

---

From: "Rosbotham, Paul" <[email-masked]>
Date: Tue, 8 Jul 2008 17:40:57 +0100

ok, I'll attempt to decode for you (although the need to do this highlights the need for some kind of system, be that SEND-N or something else) :

S1_Code : the field "Number Length" is of the form X+Y, where X = national destination code (area code) and Y is local number.  So 0+10 means 10 digit NSN with no area code, 4+6 means 4 digit area code with 6 digit local number etc etc

S3_Code : in principle the "Number Length" field would report the number length, but since for 03 numbers they're uniform 10 digits, it hasn't been populated.

S5_Code : the "Notes" field contains the number length

S7_Code : as S5

S8_Code : as S5.  Note that the 0500 range is contained within S8 rather than S5 because it is a historic code that falls within the definition of 08 (ie 0500 is legacy freephone, and nowadays all new freephone is within 080).  Note also that there is a significant amount of churn in this file so whatever analysis you do now will be outdated within days/weeks.  In brief, whenever a range marked as "Allocated(Closed)" - which will always be 9 digit numbers - becomes totally clear, it is re-allocated as a 10 digit number range (obviously with 10x as many numbers).  The frequency of this is unpredictable as it's driven by customer behaviour.

S9_Code : as S5.

I note that both S8 and S9 have rows with no entry in the Notes field.  I would assume that these are 10 digits long, but this is an assumption.  Perhaps this re-inforces that getting the data is a non-trivial activity?  

Although we've used the UK as an example, my experience is that the majority of countries' numbering plans present such difficulties when attempting to decode, and because as an originating carrier we need to provide any-any connectivity globally, we're forced into the position of having to attempt to do that.  Each time we get it wrong, we either lose $$$s due to calls being unable to complete, or present a lousy customer experience via post dial delay.

Regards

Paul

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Duane
Sent: 08 July 2008 14:56
To: [email-masked]
Subject: Re: [Enum] Send-n, rat holes and real issues

-- 

Best regards,
 Duane

 
Cable and Wireless plc

---

From: [email-masked]
Date: Tue, 8 Jul 2008 17:44:13 +0100

> we're talking about new systems.

Brian,

You are correct that the data is not "large" in terms of current systems 
or database capacities.  Despite the size, though, it's not static and 
it's difficult to maintain in every switch in the network.  The carriers 
don't want to do that anymore.  See the mails from Paul Rosbotham.  He's 
an expert in the field of maintaining number plan information.

IMHO, however, a "routing protocol" type system for distributing such 
information between devices is immense overkill.  It would easily morph 
into something at least two orders of magnitude more complicated than a 
DNS-based system, for little additional gain.

Ray

---

From: Lawrence Conroy <[email-masked]>
Date: Tue, 8 Jul 2008 21:34:51 +0100

Hi Ray, folks,
  **Please** don't use the term 'routing protocol' for this data/table  
distribution.
It's bad enough with folk some folk confusing dialing plans and  
routing plans with number plans, without adding another spanner into  
the soup.
all the best,
   Lawrence

On 8 Jul 2008, at 17:44, [email-masked] wrote:

> information between devices is immense overkill.

---

From: Duane <[email-masked]>
Date: Wed, 09 Jul 2008 07:31:22 +1000

> DNS-based system, for little additional gain.

So that's the crux of the argument, it's hard so we'll take the easy way
out?

No, there most certainly is gain, for starters it can be dealt with in a
decentralised manner similar to that of BGP, tier-1 providers allow
their customers to announce prefix lengths and filter everything else.

Where people should stick to a fixed length to minimise the size of the
database OR where there is no fixed length some sort of grouping.

People are thinking of this from the dialled digits side only but I'm
sure there could be a way to group based on the prefix length as well to
minimise the data needing to be stored or broadcast or ....

Again this is only about prefix lengths not routing information, and is
most certainly not a routing protocol.

It has a similar benefit as DNS of being decentralised, but every 'node'
would have a cached copy of the information so depending on the
equipment and the coding, lookup times would be in the sub-ms, which
would reduce post dial delay, where as a few DNS server or network or
...... outages could leave people with a bad experience from extended
post dial delays.

-- 

Best regards,
 Duane

---

From: Duane <[email-masked]>
Date: Wed, 09 Jul 2008 07:35:54 +1000

> ok, I'll attempt to decode for you (although the need to do this highlights the need for some kind of system, be that SEND-N or something else) :

No one disagrees about the information being needed in some electronic
form automated systems can use, the question is what. I appreciate the
time/effort you spent explaining it and will try and parse the CSV info
into something usable for this purpose either today or tomorrow
depending on what else comes up in the mean time.

-- 

Best regards,
 Duane

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Wed, 9 Jul 2008 05:59:23 +0100

> S1_Code : the field "Number Length" is of the form X+Y, where X = national destination code (area code) and Y is local number.  So 0+10 means 10 digit NSN with no area code, 4+6 means 4 digit area…

Note also that "4+6" actually means 12 digits in E.164 form; the three
numbers in my .sig are in 2+8, 3+7, and 4+6 form respectively.

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
THUS plc            |                            |
_______________________________________________
enum mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/enum

---

From: Duane <[email-masked]>
Date: Thu, 10 Jul 2008 21:27:26 +1000

Rosbotham, Paul wrote:

> I note that both S8 and S9 have rows with no entry in the Notes
> field.  I would assume that these are 10 digits long, but this is an
> assumption.  Perhaps this re-inforces that getting the data is a
> non-trivial activity?

Actually S7 doesn't either. Does anyone have a better/more accurate
source of information?

Based on the information at hand most routes seems to be 10 digits
except for S8 which has 9 and 7 digit numbers listed as well.

If the missing information means 10 digits it would be pretty trivial to
collate this information, however that would be guessing and someone
should have this information published somewhere especially if someone
is planning to put it into send-n, or is the information going into
send-n guesses too?

-- 

Best regards,
 Duane

---

From: [email-masked]
Date: Thu, 10 Jul 2008 12:41:27 +0100

> is planning to put it into send-n, or is the information going into

For the UK the send-n information will be derived from the contents of the 
central numbering database.

The addition of any range of numbers to the database will require 
authorisation of the regulator.

Ray

---

From: "Rosbotham, Paul" <[email-masked]>
Date: Thu, 10 Jul 2008 12:43:37 +0100

LOL, you're learning.  I went through similar angst trying to prepare the NICC number length guidelines document I referenced earlier in this thread.

I think you missed that there are a couple of hundred assorted ranges in S=1 (ie +44 1) which are of 9 digit length, and even a couple at 8 digits.  Also, specific ranges in S=8 (ie +44 8) which are 7 digit (e.g. (0)800 1111 is our child helpine).  NB as Clive said, when I say 9, that's 11 in international form (inc 44).

What you're looking at is the supposedly authoritative source of data.  Better info can be found, but only by talking to the individual CPs...of which there are currently 384, off the top of my head.  That's what we're trying to get away from.

The point of Send-N is that the records are set according to what's populated into ENUM.  

- In the context of our porting database (ie a private ENUM), current plans are that it would be populated with all numbers hence Send-N would reflect the true structure of the numbering plan.  
- In the context of user-ENUM where population is inevitably partial, then Send-N would reflect what's in there...e.g. if +448001111 wasn't populated, then no Send-N records would reflect its existence.  That's the point that Jay's been trying to get across...in a user-ENUM context the number lengths as specified by the numbering plan administrator are of limited value...e.g. if there was a range in the UK that was 15 digits long, coding that into Send-N in ENUM is pretty pointless unless any such numbers were actually populated in ENUM.

Cheers

Paul

-----Original Message-----
Sent: 10 July 2008 12:27

-- 

Best regards,
 Duane

 
Cable and Wireless plc

---

From: Duane <[email-masked]>
Date: Thu, 10 Jul 2008 22:07:36 +1000

> - In the context of user-ENUM where population is inevitably partial, then Send-N would reflect what's in there...e.g. if +448001111 wasn't populated, then no Send-N records would reflect its exist…

That is the most pointless thing I have ever heard of.

I think we're all agreed this information would be good if it were to be
made available in a useful form, now you're saying the information will
only be partially available if there is a NAPTR record, but if one or
more NAPTR records exist for a end user record then there is no need for
send-n, what the ????

-- 

Best regards,
 Duane

---

From: Duane <[email-masked]>
Date: Thu, 10 Jul 2008 22:09:19 +1000

> authorisation of the regulator.

So the answer is no one has any idea of what a complete picture of the
UK dial plan current looks like?

-- 

Best regards,
 Duane

---

From: "Rosbotham, Paul" <[email-masked]>
Date: Thu, 10 Jul 2008 13:19:43 +0100

> > - In the context of user-ENUM where population is 
> inevitably partial, then Send-N would reflect what's in 
> there...e.g. if +448001111 wasn't populated, then no Send-N 
> records would reflect its existence.  That's the point that 
> Jay's been trying to get across...in a user-ENUM context the 
> number lengths as specified by the numbering plan 
> administrator are of limited value...e.g. if there was a 
> range in the UK that was 15 digits long, coding that into 
> Send-N in ENUM is pretty pointless unless any such numbers 
> were actually populated in ENUM.
> 
No, the other way around.

Let's say that +448001111 *is* populated with it's NAPTRs.

In that case, a query to 0.0.8.4.4.e164.foo would return a send-N with (assuming absolute) N = 9.

If, however, +448001111 was not populated, that would mean that all of the numbers actually in ENUM behind +44800 would be of either 11 or 12 digits long.

In that case, a query to 0.0.8.4.4.e164.foo would return a send-N with (assuming absolute) N = 11.

...the point is the Send-N records are populated according to what NAPTRs *are* populated, not according to those which could theoretically be populated.  In the latter example, it's saying "don't bother querying me until you've got at least 11 digits because there's nothing in ENUM with anything less".  It's *not* saying "according to the numbering plan administrator, all numbers in this range are at least 11 digits long".  Subtle difference.

 
Cable and Wireless plc

---

From: Duane <[email-masked]>
Date: Thu, 10 Jul 2008 22:23:45 +1000

> ...the point is the Send-N records are populated according to what NAPTRs *are* populated, not according to those which could theoretically be populated.  In the latter example, it's saying "don't…

That was my point, if there is NAPTR records present you want to
supplement it with a send-n, but what's the point in that since the
NAPTR record would be present anyway.

This is gone from wanting to know what prefix lengths are to wanting to
know when a NAPTR is present by having a second one for good measure.

-- 

Best regards,
 Duane

---

From: "Rosbotham, Paul" <[email-masked]>
Date: Thu, 10 Jul 2008 14:05:25 +0100

> 
> 
> Rosbotham, Paul wrote:
> 
> > ...the point is the Send-N records are populated according 
> to what NAPTRs *are* populated, not according to those which 
> could theoretically be populated.  In the latter example, 
> it's saying "don't bother querying me until you've got at 
> least 11 digits because there's nothing in ENUM with anything 
> less".  It's *not* saying "according to the numbering plan 
> administrator, all numbers in this range are at least 11 
> digits long".  Subtle difference.
> 
 
Ok, I'll try one more time.

Let's say for the sake of argument that +448001111 isn't present, end-user is dialling : ultimately they're going to dial 0800123456 but so far they've only dialled 0800 and are dithering about what the next digit is.

If I query on 0.0.8.4.4.e164.foo I get a Send-N of 11.

In absence of Send-N records I get no information other than there's no NAPTR for that combination of digits.

With the Send-11, I know that when the customer dials "1" (recall I already have the 0800) there's no point in requerying.  Likewise when they dial 2.  In fact, I don't bother requerying until they've dialled 0800123456.  The query on 6.5.4.3.2.1.0.0.8.e164.foo provides the NAPTR.  It doesn't result in a Send-N.

Without the Send-11, with no knowledge of the numbering plan I'd query on 1.0.0.8.e164.foo, then 2.1.0.0.8.e164.foo etc.

Now, because there's a mixture of number lengths in +44800, if my user was instead dialing 08001234789 (ie in a range one digit longer), when I queried on the 8.7.4.3.2.1.0.0.8.4.4.e164.foo having collected 11 digits after getting a Send-11, it would result in another Send-N, this time N=12 because the extra information I've provided has pinpointed it to being a number in a longer range.  This assumes at least one of x.8.7.4.3.2.1.0.0.8.4.4.e164.foo (x=0...9) is populated...if it's not it's pointless me collecting an extra digit and requerying, because I'll still get no record for my query.

So, for numbering plans where no complete number is a prefix of another (*), you should either get the NAPTR per today, or a Send-N, but not both.

(*) I believe that in some countries that may not be the case, e.g. 01234567 and 01234567890 can exist as separate numbers...obviously there'd be issues in that scenario.

 
Cable and Wireless plc

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 10 Jul 2008 09:28:21 -0400

> What you're looking at is the supposedly authoritative source of data.
> Better info can be found, but only by talking to the individual CPs...of
> which there are currently 384, off the top of my head.  That's what we're
> trying to get away from.
> 
And how does the ENUM operator get the data?  It needs to get data from 384
CPs, plus the regulator, right?  If the ENUM database was a world-wide
database, it has to get the data from thousands of sources in different
countries, right?

Doesn't that imply some sort of standardization?

And then, having standardized a way to get the data, why is that not good
enough for everyone?

---

From: "Rosbotham, Paul" <[email-masked]>
Date: Thu, 10 Jul 2008 15:01:57 +0100

> And then, having standardized a way to get the data, why is 

Who is "the ENUM operator" in this context?  

My view, in a user-ENUM environment you're talking about the T1 registry for a given country.  When a number's registered today, the Tier 2 has to notify the Tier 1 to make the delegation, as well as populating the NAPTRs on their DNS server.  Add Send-N to the mix, and the Tier 1 also has the task of synthesizing the Send-Ns based upon the info received for that and previous delegations.  As to whether the T1 is prepared to do that...well I can only say that the author of the I-D is the UK T1.  If a country had no need for Send-N (e.g. fixed length plan), then I haven't seen anything in Ray's proposals that mandates Send-Ns be populated.

Of course, if there's a desire to come up with something which meets the requirements of Send-N using something other than ENUM so couldn't leverage existing standards, then there would be a need for new stuff.

As an aside, in the UK portability context, the CDB provider will synthesize Send-Ns according to information populated by the CPs about active numbers.  The management interface has been standardised for providing that information.  I can't go into any detail about the level of support for this by CDB vendors because we're subject to EU Public Procurement legislation at present, but suffice to say that our prospective providers are not flagging support of this as an issue.

 
Cable and Wireless plc

---

From: Duane <[email-masked]>
Date: Fri, 11 Jul 2008 06:53:37 +1000

> So, for numbering plans where no complete number is a prefix of another (*), you should either get the NAPTR per today, or a Send-N, but not both.

I can't help but think this doesn't belong in DNS, repeating hit after
hit on name servers when the information could be dealt with at a local
level has to be the better way to do it surely.

> (*) I believe that in some countries that may not be the case, e.g. 01234567 and 01234567890 can exist as separate numbers...obviously there'd be issues in that scenario.

I wonder if this made it into the send-n proposal, in any case this
highlights further the need for a proper think about how to do this
rather than going bull at a gate with something that sort of works but
seems like a very nasty hack to me.

There seems to be a lot of effort to 'fix' the analogue problem, the
simple answer would be to move everyone to digital systems and when they
hit dial that's the final number :D

-- 

Best regards,
 Duane

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 10 Jul 2008 17:15:46 -0400

So why doesn't someone go to Gordon Brown and tell him to fix the bloody UK
dial plan? 

Oh ..that's right they tried that before and a couple of Ministers got
sacked.

And with the latest poll numbers looking as they do ...probably not a real
option. :-)

Sorry ...

>  From: [email-masked] [mailto:[email-masked]] On Behalf
>  Of Rosbotham, Paul
>  Sent: Thursday, July 10, 2008 7:44 AM
>  To: Duane; [email-masked]
>  LOL, you're learning.  I went through similar angst trying to prepare
>  the NICC number length guidelines document I referenced earlier in
>  this thread.
>  
>  I think you missed that there are a couple of hundred assorted ranges
>  in S=1 (ie +44 1) which are of 9 digit length, and even a couple at 8
>  digits.  Also, specific ranges in S=8 (ie +44 8) which are 7 digit
>  (e.g. (0)800 1111 is our child helpine).  NB as Clive said, when I say
>  9, that's 11 in international form (inc 44).
>  
>  Better info can be found, but only by talking to the individual
>  CPs...of which there are currently 384, off the top of my head.
>  That's what we're trying to get away from.
>  
>  - In the context of our porting database (ie a private ENUM), current
>  plans are that it would be populated with all numbers hence Send-N
>  would reflect the true structure of the numbering plan.
>  - In the context of user-ENUM where population is inevitably partial,
>  then Send-N would reflect what's in there...e.g. if +448001111 wasn't
>  populated, then no Send-N records would reflect its existence.  That's
>  the point that Jay's been trying to get across...in a user-ENUM
>  context the number lengths as specified by the numbering plan
>  administrator are of limited value...e.g. if there was a range in the
>  UK that was 15 digits long, coding that into Send-N in ENUM is pretty
>  pointless unless any such numbers were actually populated in ENUM.
>  
>  Cheers
>  
>  Paul
>  
>  
>  
>  
>  
>  This e-mail has been scanned for viruses by the Cable & Wireless e-
>  mail security system - powered by MessageLabs. For more information on
>  a proactive managed e-mail security service, visit
>  http://www.cw.com/uk/emailprotection/
>  
>  The information contained in this e-mail is confidential and may also
>  be subject to legal privilege. It is intended only for the
>  recipient(s) named above. If you are not named above as a recipient,
>  you must not read, copy, disclose, forward or otherwise use the
>  information contained in this email. If you have received this e-mail
>  in error, please notify the sender (whose contact details are above)
>  immediately by reply e-mail and delete the message and any attachments
>  without retaining any copies.
>  
>  Cable and Wireless plc

---

From: "Rosbotham, Paul" <[email-masked]>
Date: Fri, 11 Jul 2008 09:00:13 +0100

> From: Richard Shockey [mailto:[email-masked]]
> Sent: 10 July 2008 22:16

> And with the latest poll numbers looking as they do 

Tell you what, I'll do that when you tell George Dubya to forceably migrate everyone onto IPv6  ;-)

Seriously, though, getting a fixed length plan is a non-option.  The main fragmented range is 08.  That's because there's a mixture of legacy 0800+6 digit numbers, and newer 0800+7 digit numbers.  The industry tried to move to a uniform plan in this area a few years ago, and there was blood on the floor by the end.  You've got to recognise that large corporates have dedicated considerable advertising spend to building brands around their numbers, and they don't like to change.  Think in terms of the reaction if you went out and told every 800 number-holder in the US that they'd need to change their number...

There is a risk of this being characterised as a uniquely UK issue, though, which is not the case.  It's just we've got the biggest mouths.  Off the top of my head, similar issues would arise with complex variable length plans in Australia, Bangladesh, Belgium, China, Germany, Greece, India, Ireland, Italy, Monaco, Netherlands, Nigera, Pakistan, Poland, Portugal, Russia, South Africa, Spain, Sweden, Switzerland...  (this is using the criterion that it would take more than 50 lines to summarise the number lengths in the plan)

 
Cable and Wireless plc

---

From: Duane <[email-masked]>
Date: Fri, 11 Jul 2008 18:58:49 +1000

> Tell you what, I'll do that when you tell George Dubya to forceably migrate everyone onto IPv6  ;-)

Actually they did (sort of) all US govt backbones had a dead line of
June 30th to support IPv6 and to everyone's surprise apparently it happened.

> Seriously, though, getting a fixed length plan is a non-option.  The main fragmented range is 08.  That's because there's a mixture of legacy 0800+6 digit numbers, and newer 0800+7 digit numbers.…

Australia did this between 1995 and 1999 I think it was completed,
companies used to have 008 numbers but were forcibly moved to (+61)1800
along with all the other dial plan changes like 0055 numbers moving to
(+61)1900 and virtually every area code merging with all the other area
codes in the same state if not multiple states.

> There is a risk of this being characterised as a uniquely UK issue, though, which is not the case.  It's just we've got the biggest mouths.  Off the top of my head, similar issues would arise with…

While you may be technically correct about needing more than 50 lines to
describe the dial plan for Australia, the majority of people and for
most routes that can be dialled internationally to Australia can be
summarised in a lot less than 50. For the most part this is all that
anyone needs:

61[2378]NXXXXXXX - Geographical numbers
614XXXXXXXX - Mobile numbers
61130XXXXXXX - Caller and Callee pays
6113ZXXX - Caller and Callee pays
611345XXXX - Security systems, shouldn't be needed for international
calls ever
61180[01]XXXXXX - toll free
61180NXXX - govt toll free
61190[0126]XXXXXX - premium rate voice services
6119[1345]XXX - premium rate SMS services
6119[679]XXXXX - premium rate SMS services

Actually out of the above list the main numbers called by people are
geo, mobile and 13/18 numbers, although I'm sure there is a lot of
calls/sms to 19 numbers based on all the ads on tv for different
services. However most VoIP/VSP companies won't touch 19 numbers because
of the difficulty in billing services.

While there is 82 routes listed on http://www.e164.org/wiki/AU_Dialplan
a lot of these numbers can't be called/used outside of Australia, eg 000
is emergency services (like 911 or 112 etc), 001X and 14XX override
prefixes for local, long distance, mobile and international calls, 019
numbers are charged at local rates but are data services for ISPs
usually, majority of the geographical route information could be
summarised instead of the way I have it fleshed out, I went through and
pulled out all the information about allocated numbers and that list was
correct a few months ago.

The 12X numbers are 'special' numbers like directory services and other
carrier things, and hardly any numbers in the +615.

-- 

Best regards,
 Duane

---

From: "Rosbotham, Paul" <[email-masked]>
Date: Fri, 11 Jul 2008 10:23:49 +0100

> summarised in a lot less than 50. For the most part this is all that

Thanks Duane,

your analysis is interesting.  HOWEVER as a telephony provider, I don't have the luxury of maintaining data that will cope with the "majority" of calls.  I have to cope with all of them hence do need to go to that next level of detail (or use timers...typically for level 0/1 in Australia we do that).

 
Cable and Wireless plc

---

From: Duane <[email-masked]>
Date: Fri, 11 Jul 2008 20:03:07 +1000

> your analysis is interesting.  HOWEVER as a telephony provider, I don't have the luxury of maintaining data that will cope with the "majority" of calls.  I have to cope with all of them hence do ne…

No there is nothing about length so timers wouldn't come into it, the
only difference is if the number is allocated or not.

-- 

Best regards,
 Duane

http://www.freeauth.org - Enterprise Two Factor Authentication
http://www.nodedb.com - Think globally, network locally
http://www.sydneywireless.com - Telecommunications Freedom
http://e164.org - Global Communication for the 21st Century

"In the long run the pessimist may be proved right,
    but the optimist has a better time on the trip."