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

I'd generally concur with Brian.
 
I'd also still like to be clear why this isn't about dialing plans
(which ENUM isn't supposed to be about) as opposed to numbering plans.
It seems this is only necessary for unsenderized user interfaces where
the network element interacting with the user is seeking a way to
determine end of dialing other than by inter-digit timeout. Since plans
that allow variable length numbers may return a value that is not
determinate, e.g. 5-6, the proposal wouldn't seem to work in all cases
in the absence of very low level information. (I recall in discussion of
open numbering plans and non-terminal NAPTRs for infrastructure ENUM it
was argued that enterprises would not want to populate records a that
kind of level. 
I'd also ask how PBXs and exchange switches achieve this function today
in places with open numbering plans.

Penn Pfautz
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Brian Rosen
Sent: Friday, April 04, 2008 10:17 AM
To: 'Paul Kyzivat'; 'Clive D.W. Feather'
Cc: [email protected]; 'Duane'
Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00

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: [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