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

at end...

Brian Rosen wrote:
> 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?

We still need a *workable* solution to the overlap dialing issue. 
(People don't consider timers to be adequate.)

This seems like the only real solution to that.

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

If we want it available via a protocol (and I think that is far 
preferable to a word doc), and if it is to at least play nice with enum, 
then ietf seems like a suitable place. But I am not really familiar with 
the alternatives.

Re the numbering authorities: Obviously they must have a role in this. 
But it is not nice if we have to wait for a national numbering authority 
to report that some number that was assigned to a hotel in germany now 
may end in either "0" or "[1-9]xxx". The reporting needs to be more 
direct from those who implement the behavior.

	Paul

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of Paul
> Kyzivat
> Sent: Friday, April 04, 2008 9:37 AM
> To: Clive D.W. Feather
> Cc: [email protected] >> [email protected]; 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/enum
> 
> _______________________________________________
> enum mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/enum
>