Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00

["Brian Rosen" <br at brianrosen.net>]

I think this is the crux of the matter.

We do, actually, need to know the length of a TN in order to support
overlapped dialing, and to distinguish when an ENUM query fails (was it no
valid number, or too few digits; there is quite a difference).

It's the attempt to encode that information in the actual ENUM tree that is
a problem.

First of all, let us recognize that this information is published by a
national numbering authority.  In most cases, it's reported to the ITU, and
the ITU publishes the information in a bulletin.  There are commercial
sources of the data.  Our experience with this data is that it's not
accurate, and often changes are not timely.

There are usually other pieces of information that accompany the number
length data that would also be valuable to anyone creating routing systems.
That would include valid number ranges and portability information (is the
range subject to portability).  The same data also often reports block
assignments (i.e. blocks of numbers assigned to specific carriers), and
carrier type (fixed/mobile/VoIP).

I don't foresee the end of numbering authorities any time soon.  Therefore
it might be worthwhile for someone to standardize the way this data is
reported in a manner that anyone who needed it could get it.  I am not
persuaded that putting it in an ENUM tree is a good idea.

I think the next question to ask if you accept that standardizing is useful
would be IETF or ITU?  Generally, we HAVE let the ITU handle numbering.  On
the other hand, it's 2008 and the ITU is reporting the data incomplete and
often late, and in the form of a Word file.

Summarizing, two questions:
1. Do people generally agree that it really would be a good idea to
standardize a way to obtain TN length and possibly other related numbering
data?
2. If such a standardization effort should be undertaken, should the IETF do
it?  Since we're trying to close down ENUM, this would be done somewhere
else I believe.

Brian



-----Original Message-----
From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of Paul
Kyzivat
Sent: Friday, April 04, 2008 9:37 AM
To: Clive D.W. Feather
Cc: enum at ietf.org >> enum at ietf.org; Duane
Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00



Clive D.W. Feather wrote:
> Paul Kyzivat said:
>> This would be good *if* we could be assured that there would be enough 
>> public ENUM entries to define the endpoint of all dial strings.
> 
> No. If there aren't any end-point records in the relevant tree, then it
> doesn't matter whether send-n gives you the right answer or not.

Sure it does. The phone still needs a way to figure out when enough 
digits have been dialed so that it can send an INVITE, even if that 
INVITE is going to fail.

My thought here was that it doesn't appear likely that the public enum 
tree under country code 1 will be fully populated any time soon. But 
ideally all that is really needed is a single entry that says all 
numbers under country code 1 require 10 more digits, and it ought to be 
a lot easier to get that one entry. The mechanics of getting that to 
work are another story. Whether its technically part of enum or 
something else seems to be a political issue that I don't (and don't 
want to) understand.

	Paul

> Suppose that a particular numbering plan has numbers of the form:
>     123456x
>     123457xx
> If it was fully populated with end-user records, then:
>     at the 5 node, there would be a record send-n/2-3
>     at the 6 node, there would be a record send-n/1-1
>     at the 7 node, there would be a record send-n/2-2
> Now suppose that the only public ENUM entry in this tree is for 1234568.
> It doesn't matter whether the entry at the 5 node says send-n/2-2 or
> send-n/2-3. If it says the former, then after dialling 1234579, the device
> will look for records and get none back even though the wrong number of
> digits have been dialled. But even if it waited for the next digit, that
> wouldn't help.
> 
> In the converse case where the only records are for 123457xx, the entry at
> the 5 node might say send-n/3-3. This is slightly more problematic if the
> user dials 1234560, but *only* if you're using the ENUM database to
> determine when to stop accepting digits. In this situation, you need to
> ensure that the send-n records are correct or be prepared to timeout
> dialling.
> 
> Ray, it might be worth adding something on this point of using the data to
> determine when a number is complete even though there are no records in
> the tree.
> 
>> I guess each device must at least know how to get to the country level. 
>> After that, there ought to at least be one of these entries for the 
>> country code. For each country there ought to be either a fixed length 
>> or a range. If a range, then there ought to be an entry for each string 
>> of length equal to the minimum of the range, which narrows it down.
> 
> True. However, in reality a device might have received more than the
> minimum number of digits before querying. So you need to fill in the gaps
> as well.
> 
_______________________________________________
enum mailing list
enum at ietf.org
https://www.ietf.org/mailman/listinfo/enum

_______________________________________________
enum mailing list
enum at ietf.org
https://www.ietf.org/mailman/listinfo/enum