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

From: [email-masked]
Date: Wed, 2 Apr 2008 09:40:08 +0100

I've just submitted a new I-D, available at
<http://www.ietf.org/internet-drafts/draft-bellis-enum-send-n-00.txt>

Filename:        draft-bellis-enum-send-n
Revision:        00
Title:           IANA Registrations for the 'Send-N' Enumservice
Creation_date:   2008-04-02
WG ID:           Independent Submission
Number_of_pages: 10

Abstract:

  This document requests IANA registration of an Enumservice 'Send-N'
  and extends the definition of the 'pstndata:' URI scheme.  This
  service allows more efficient support for overlapped dialling in
  E.164 Number Mapping (ENUM) enabled applications.

Any and all (constructive) feedback gratefully received!

regards,

Ray

-- 
Ray Bellis, MA(Oxon)
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211
_______________________________________________
enum mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/enum

---

From: "PFAUTZ, PENN L, ATTCORP" <[email-masked]>
Date: Wed, 2 Apr 2008 16:10:12 -0400

Ray:
I'm having a little trouble understanding the real need for this
enumservice. I would think that any network element  receiving a dial
string would have its own local information about dial patterns and
numbers and so be able to tell when dialing is complete and then be able
to formulate an ENUM query on the appropriate full E.164 number.
Since the number length information should be relatively static, why not
just provision it locally? 
Also, it's not clear to me when the client would initiate the initial
query in the example that told it to expect 5-6 more digits. And, if
it's 5-6, then if the number has only 5, don't I still have to use a
timeout algorithm to determine the user is finished dialing.
Am I missing something?

Penn Pfautz

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Wednesday, April 02, 2008 4:40 AM
To: [email-masked]
Subject: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00

Abstract:

regards,

Ray

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Wed, 2 Apr 2008 22:03:55 +0100

> just provision it locally? 

While the information should be static, it's also very complicated and it
might not be practical for the network element to store it all. In the UK
we have number ranges where the length varies in a very localised way; it
might be that:
     0456 789 0xx    numbers are all 10 digits
     0456 789 1xxx   numbers are all 11 digits
(these are hypothetical examples because I can't get to the relevant
database right now).

Germany has situations where the customer determines the length of numbers.

> query in the example that told it to expect 5-6 more digits.

The client would know, perhaps, that *every* number beginning 0 has at
least 7 digits. So it would initiate the query after receiving those 7.

> And, if

In the UK there are no numbers that are prefixes of other numbers. That is,
when you've received enough digits, you'll know you've reached the end. But
you may need several digits to do so - see the above examples.

-- 
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, 03 Apr 2008 08:42:07 +1000

> we have number ranges where the length varies in a very localised way; it

A similar thing occurs in Australia and I recently parsed the CSV file
published by the ACMA of all prefixes it is authorised to allocate or
has been allocated and its a horrible mess of sorts. So I can see how
this might be useful especially for keeping up with changes globally to
the benefit of all but without everyone needing to keep local databases
or updating their own databases themselves.

> least 7 digits. So it would initiate the query after receiving those 7.

I'm not exactly clear on when DNS queries should be triggered, or how
many need to be requested either or if these would interfere with
existing wild card entries.

I don't have time this morning to test but I like the idea a lot and I
very much would like to see it or some variation of it work.

-- 

Best regards,
 Duane

---

From: Duane <[email-masked]>
Date: Thu, 03 Apr 2008 09:00:51 +1000

> or updating their own databases themselves.

I meant to provide a link to the results of where I parsed the
Australian information in the first place, sorry.

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

The information at the top is a simplified version which most people
would be able to live with, however the full listing which appears at
the bottom is the most accurate description of the Australian numbering
plan as of about 3 weeks ago.

-- 

Best regards,
 Duane

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 02 Apr 2008 19:10:46 -0400

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.

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.

Then the USA could continue to dawdle on enum support, since there can 
be a fixed length for all of the NANP. Those countries with variable 
length numbers would have a harder requirement for enum support.

	Paul

---

From: Lawrence Conroy <[email-masked]>
Date: Thu, 3 Apr 2008 00:30:52 +0100

Hi Clive, Penn, Ray, folks,

I am somewhat discomforted by this thread. IMHO it's a damn good idea  
having (in effect) an digit length analysis tree in DNS. It sure as  
heck beats looking through the different CSV/Excel/Access/... formats  
in which different Regulators publish their number plans.

However, the ENUM standard doesn't seem to be set up to allow  
definition of these useful records. This may not be appropriate for  
E2U, but instead be another DDDS application entirely. Otmar, Alex,  
and Michael have had similar ideas, and they didn't prevail even  
though they were neat proposals. Heck, Rchard Stastny and I had some  
fun with VOID, and were reminded that THAT won't fly in ENUM with  
block numbers.

Scott has released a draft of rfc3761bis-03.
NOTE WELL - this has NOT changed the applicability text of 3761 at all.
Dialing Plans are specifically excluded from ENUM. Thus before the  
esteemed SIP aficionados dive in, ENUM is about numbers, not dialed  
digit strings.

An ENUM client is also expected to make an ENUM query only where it  
believes it has a complete E.164 number. RFC 3761 goes on to accept  
that a client may not know what constitutes a valid E.164 number (some  
of us call outside the NANP :).

In principle only having a partial view of global number plans is not  
good enough. The idea of provisioning every nation state's number plan  
locally into every switch is surely not what was meant. **

However, it is pushing this a bit far to send out an ENUM query with a  
partially collected number, in the expectation of getting back an ISUP  
SND style response. This is not something the originating node  
believes is a complete number - it's something it suspects isn't. Thus  
whilst I really like the concept, I fear that ENUM is not the  
appropriate carrier.

all the best,
   Lawrence
---------
**
We have had this number plan discussion many times before. In the  
NANP, numbering is (usually) easy. Dialing is another matter, but  
that's way out of scope.
In the UK one can at least know what constitutes a valid number  
length, BUT this is not immediate - one needs to have some digits to  
do the analysis.
Thus whilst a (semi) static analysis tree is possible (see <http://www.ofcom.org.uk/static/numbering/index.htm 
 >), as Clive states, the length of numbers in the UK is prefix  
dependent. Also as Clive points out, there are no subsets - again,  
look at the numbering plan files.
In Germany and Austria, all bets on number length are off, as these  
nation states have open numbering plans. However, again, they don't  
have independent numbers as subsets of others.
This should come as no surprise at all to someone in the business.
I am thus once again puzzled by this resurgence. Is this another game  
of WhackaMole?
----------

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 2 Apr 2008 21:47:38 -0400

Chair hat off ..

Lawrence I generally agree with the thrust of your analysis. I find it very
difficult to support the use of 3761 for digit analysis. 3761 was designed
to query on the full E.164 string not a partial string. We would be going
down a rat hole we do not want to go, especially now.

ENUM is a pure 1 to 1 mapping from fully formed E.164 FQDN to URI's. The
digit strings must be fully formed in advance before query not during. We
have seen the German arguments etc and have passed on those etc.

>  From: [email-masked] [mailto:[email-masked]] On Behalf
>  Of Lawrence Conroy
>  Sent: Wednesday, April 02, 2008 7:31 PM
>  To: Clive D.W.Feather
>  Cc: [email-masked]; [email-masked]; PFAUTZ, PENN L, ATTCORP
>  Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-
>  00
>  
>  Thus whilst a (semi) static analysis tree is possible (see
>  <http://www.ofcom.org.uk/static/numbering/index.htm

---

From: Duane <[email-masked]>
Date: Thu, 03 Apr 2008 16:41:43 +1000

> esteemed SIP aficionados dive in, ENUM is about numbers, not dialed  

This is a little more grey then you seem to be painting, even if no dns
checks are made until the full length is hit I see this as useful even
for non-SIP/non-VoIP applications since in theory sending an email to a
phone number and having the email application doing an enum lookup could
do a check to see if the number exists and failing that could also check
that the length is valid.

> of us call outside the NANP :).

Some of us rarely call inside the NANP :)

> whilst I really like the concept, I fear that ENUM is not the  

As above only send out queries as necessary to verify the length is
valid and I can see how this would be useful to all aspects of ENUM
queries. I also agree that specifically in terms of SIP/VoIP it would be
a bad idea and would create a lot of noise to send out numerous queries
before the any inter-digit timeouts occur.

Although if one thinks about it national dial plans rarely change, and
the only exception here being the open numbering plan in Germany and
Austria, so fixed numbering plans could in theory have relatively long
time to live values to over come problems with noise/excessive queries.

I will have time shortly to play further with this to see how it would
effect other DNS entries and will comment more on the technical problems
after that.

-- 

Best regards,
 Duane

---

From: Duane <[email-masked]>
Date: Thu, 03 Apr 2008 17:05:37 +1000

> have seen the German arguments etc and have passed on those etc.

If not ENUM, then where does this best fit?

I have doubts about the technical suitability because I can see where
and how it would interfere with existing records, sorry got distracted
and haven't actually done testing.

That said I can see benefit for all ENUM services in being able to find
out if the number is actually valid and using e164.arpa while ambition
was a neat idea to distribute the work back on the regulatory bodies
which is why this was being pushed via ENUM rather then a new service,
and this would also hit exceptions that include Germany etc as well.

Even if a new DNS or other service was invented to cover this, is there
any corrot that can be offered to get people to add and keep this
information updated without the stick from some regulatory body,
although this only applies for a small subset of countries, most
countries will have fixed numbering plans, even the NANP has variable
length numbering based on the prefixes (911, 411, etc), although they
would be special services redirected to normal numbers in the same area
I guess so hmmm.

-- 

Best regards,
 Duane

---

From: [email-masked]
Date: Thu, 3 Apr 2008 08:26:45 +0100

> have seen the German arguments etc and have passed on those etc.

Like it or not, for now at least it seems that private ENUM has been 
somewhat more successful than public ENUM.

The specific application for which this was originally designed is the 
UK's number portability database, where a private ENUM tree is used and 
where it is not known in advance to the application whether a complete 
number has been received.  The intent is to avoid excessive dips into that 
database, not least because there may be a (financial) cost associated 
with each dip.

If one does need this data (which NICC believe we do) then it makes 
absolute sense for it to be included in the ENUM tree.  By doing so we 
allow the central portability database to maintain a single protocol 
interface with the Communications Providers that are querying it.  When 
the CP asks for a NAPTR, they either get routing data, or a hint that more 
digits are required *from the same DNS request*.

cheers,

Ray

p.s. if it would make people happier I can quite readily change the 
examples so that they're not in e164.arpa.

---

From: Otmar Lendl <[email-masked]>
Date: Thu, 03 Apr 2008 10:06:37 +0200

> Any and all (constructive) feedback gratefully received!

Your definition of the min and max fields are relative to the location 
of the NAPTR record:

    The 'digitsmin' field of the data MUST correspond to the minimum
    number of additional digits to be dialled, relative to the current
    record, which might result in reaching a full ENUM record in the ENUM
    database.

Wouldn't it be easier to use absolute values here?

/ol

---

From: Duane <[email-masked]>
Date: Thu, 03 Apr 2008 18:18:43 +1000

> somewhat more successful than public ENUM.

I haven't seen dns request stats on e164.arpa, but last time they were
announced e164.org was getting more. In any case I see this useful for a
lot of VoIP and non-VoIP applications even if the primary beneficiary at
this stage would be VSPs and proficient home users at this stage.

> digits are required *from the same DNS request*.

I don't think it is technically feasible, sorry still haven't done
testing but I can see where it would fail immediately without testing as
written in the RFC. To get routing data and prefix lengths or hints at
the same time without breaking other things such as wild card records as
the most specific entry would block the wild card.

> examples so that they're not in e164.arpa.

It wouldn't matter I don't think, due to the technical issue alone above
I think there is no way to avoid multiple packets of some description so
you might be better off almost writing a new service rather then trying
to bolt it onto DNS for no benefit.

For example a simple service daemon listing on a UDP port could take
requests for a number and return the same information as written in the RFC.

I'm actually half thinking about doing this myself because I already
have quite a bit of data about different numbering plans in our database
but it's extensive for some countries and incomplete for others although
this is where grass root efforts get their power from.

-- 

Best regards,
 Duane

---

From: Jim Reid <[email-masked]>
Date: Thu, 3 Apr 2008 10:21:39 +0100

On Apr 3, 2008, at 09:18, Duane wrote:
> announced e164.org was getting more.

Please stop this "my tree's bigger than yours" childishness. Or at  
least take it somewhere other than this list.

---

From: [email-masked]
Date: Thu, 3 Apr 2008 10:25:58 +0100

> to bolt it onto DNS for no benefit.

As documented in the draft this is known to be specifically incompatible 
with wildcards.

In the NICC specifcation for the UK Central Numbering Database wildcards 
are not used at intermediate nodes (i.e, to represent number blocks). They 
are only used at leaf-nodes, to support over-dialling (i.e. sending too 
many digits).

Ray

---

From: Duane <[email-masked]>
Date: Thu, 03 Apr 2008 19:57:29 +1000

> least take it somewhere other than this list.

You are taking me out of context, the intention was to make his
statement less abstract because he never made any frame reference as
what success could be measured by at all.

Ok, so I'll turn this round and ask you, in your opinion is there any
frame of reference that could be used based on his original statement
that e164.arpa wasn't a success without comparing it?

If it is or isn't, what frame of reference would you use to make the
claim one way or the other?

Some made the claim years ago that IPv6 was a success. It's now years
later and I believe none of the fortune 500 companies have AAAA records
on their main website addresses, but that is only one way to judge
success and another would be the number of subnets actively seen in BGP
tables, or actively seen by some stats company.

I would like your opinion on this, hopefully this isn't taken in a
facetious way like my last.

-- 

Best regards,
 Duane

---

From: Duane <[email-masked]>
Date: Thu, 03 Apr 2008 20:00:00 +1000

> are only used at leaf-nodes, to support over-dialling (i.e. sending too 

If it breaks existing RFCs, and you are mostly planning to use it
privately or in infrastructure enum would an X- type, and no RFC on it
be more applicable?

-- 

Best regards,
 Duane

---

From: [email-masked]
Date: Thu, 3 Apr 2008 11:14:57 +0100

> this stage would be VSPs and proficient home users at this stage.

Duane,

My point about private ENUM vs public ENUM wasn't intended to be about the 
size of the databases - I was hurrying as I had to catch a train.

What I was trying to say is that in private ENUM the semantics are often 
not identical to those of public ENUM.  In particular, Richard's assertion 
that RFC3761 lookups should only be done on complete numbers need not 
apply.

To answer Lawrence's question about why this has been raised again: this 
is the proposed solution for a real application - UK number portability.

In another mail you've just asked why not 'X-'.  Say another country 
decided that 'Send-N' style data was a good idea for their portablity 
database, and then in the future multiple countries decide they'd like to 
intermesh their portability databases so that international calls to 
ported numbers go directly to the recipient CP.  I think it would make 
sense for there to be a common standard for this. 

I'd also counter (re: the wildcard issue) that this does not *break* other 
RFCs.  If your ENUM tree has to use wildcards, then so be it, go ahead and 
use them.  This draft supports an optimisation strategy for overlapped 
dialling, not a requirement.

As it happens the wildcard issue is tied in with the relative vs absolute 
question that Otmar raised.  I'll think further about that, and consult 
with my associates at NICC.

Ray

---

From: Duane <[email-masked]>
Date: Thu, 03 Apr 2008 20:30:01 +1000

> sense for there to be a common standard for this. 

Exactly, so why break existing standards which has the future potential
of causing such problems?

To date I know of 2 cases where wild cards are useful, although they are
really the same case just on different scales. Firstly where a large
Tier 1 carrier has a large block of numbers and delegates these numbers
out to a smaller carrier, and the smaller carrier delegates single
numbers out to end users. In both cases both carriers have wild card
records in a zone and so does the end user and the most specific record
is returned.

I realise the above cases can be handled with NS records at each
successive level and should still work with your draft, but a number of
countries that have evaluated or are evaluating e164.arpa are looking at
the option of a single zone for faster lookups.

As I keep saying I see how this is so useful for a lot of reasons, I
just don't see any benefit in doing it via DNS verses some other
protocol or method.

-- 

Best regards,
 Duane

---

From: Jim Reid <[email-masked]>
Date: Thu, 3 Apr 2008 12:35:28 +0100

> If not ENUM, then where does this best fit?

IMO the issue of putting numbering plan information in the DNS is  
best solved with a new DNS RR type that's designed for that specific  
purpose and probably not with a NAPTR. So that probably means writing  
up something for the dnsext 2929bis process. How that hypothetical  
new RRtype could be used in e164.arpa is something that this WG could  
pick up.

However this draft is deeply flawed. There are many problems:

[1] It is simply unacceptable to say this NAPTR service type MUST NOT  
be used with a wildcard. This violates DNS fundamentals: all RRtypes  
are the same and the same semantics apply to them wrt wildcard  
processing and the likes. [Well, let's not go down the wildcard SOA  
and NS ratholes.] In fact it's worse than that because the  
restriction on whether a wildcard can be used or not depends on a  
*subtype* of an RRtype. This is very bad.

Although I am no fan of wildcard DNS labels, it makes no sense to say  
"wildcards are OK for this RRtype but not that RRtype". It's even  
worse to say "wildcards can be used for these NAPTR service types,  
but not for these other ones". It's also exceptionally bad protocol  
design to make that a requirement.

[2] The draft says nothing about how a client should behave when  
there are many of these proposed send-n (sub) service types and what  
they would mean. Suppose a lookup returns:

	.... NAPTR 10 10 "E2U+pstndata:send-n" !^.*$!pstndata:send-n/5-6!" .
	.... NAPTR 10 20 "E2U+pstndata:send-n" !^.*$!pstndata:send-n/3-9!" .
	.... NAPTR 20 10 "E2U+pstndata:send-n" !^.*$!pstndata:send-n/1-5!" .
	.... NAPTR 20 20 "E2U+pstndata:send-n" !^.*$!pstndata:send-n/4-7!" .
	.... NAPTR 20 30 "E2U+pstndata:send-n" !^.*$!pstndata:send-n/6-9!" .

What does this mean and how are clients and applications expected to  
behave? For extra bonus points, add in funky regexp substitutions  
instead of a boring "!^.*$!". :-)

And what if there are other E2U+pstndata:send-n NAPTRs higher up the  
tree that conflict with these entries? Does a E2U+pstndata:send-n  
NAPTR for e164.arpa covering a 15 digit number over-ride one at  
1.2.3.4.5.6.7.8.9.e164.arpa? Which is definitive?

[3] The hierarchical structuring of E.164 numbers and the DNS means  
the scheme as proposed is vulnerable to all sorts of nasties. IIUC  
introducing one of these "E2U+pstndata:send-n" at the apex of the  
tree could nuke all the others at any leaf nodes in the tree. Suppose  
someone puts "E2U+pstndata:send-n" ""!^.*$!pstndata:send-n/1-15!" at  
the zone apex. It's game over. Any local or national dialling plan  
info that was submitted will never be found even though it's in the  
DNS because clients would have picked up the entry at the apex which  
tells them not to go looking for more localised dialling information.

And if one of these NAPTRs gets inserted at a higher node of the  
tree, it can break clients who depend on local dial plan info that  
was stored lower down. That violates another DNS fundamental. Apart  
from delegations and maybe DNSSEC, nothing that goes into a parent  
zone should have any impact on what's in a child zone or on the  
responses from the DNS. And when we're not talking about delegations,  
an RR for some domain should have no impact on any RRs at any  
subdomains.

[4] The concept of using the DNS to store numbering plan information  
is a good one. How it's been proposed here is broken. As is the  
application of that proposal IMO. For ENUM, the lookup is done on a  
complete digit string. Hitting the call button on a mobile phone is  
analagous in ENUM to "lookup the number that's just been typed". An  
ENUM lookup only takes place once the full number -- for some  
definition of full number -- has been dialled and translated into a  
domain name. To do the equivalent for overlapped dialling, a DNS  
lookup would be done for each digit in the number as it was typed or  
dialled until the client hits one of these n-send service types that  
has info about the number that's being dialled. I just don't see the  
point. Any device that has the intelligence to do a DNS lookup  
probably already has some sort of directory/call routing/address book  
capability and would be able to do The Right Thing when something  
dialled 3 or 4 digits on a steam phone or whatever.

To my mind, a cleaner scenario would be for numbering plan info to be  
stored in the DNS using an RRtype that was designed for that purpose.  
Clients like SIP servers and SBCs could query for this at start up  
and maybe have to navigate through a bunch of these RRs at different  
points of the tree. Once that's been done, they can configure  
themselves with information about any local dialling plans that are  
revelant.

---

From: [email-masked]
Date: Thu, 3 Apr 2008 12:56:55 +0100

Jim,

I'm at NICC at the moment and will see what others have to say before 
replying to the rest of your comments.

> they would mean. Suppose a lookup returns:

I had already spotted that one and covered it in my working copy.

Ray

---

From: [email-masked]
Date: Thu, 3 Apr 2008 13:18:47 -0500

Some technical points:

It seems undesirable to not allow the send-n record to be usable as a
wildcard.  The reason is that if one has a partial dial string that
has not already been processed for send-n information, the only way to
check if there is a relevant send-n record is to do DNS lookups on all
prefixes of the string.  That results in a lot of DNS lookups, which
is what the send-n mechanism was to avoid in the first place.

I am not familiar with the details of DNS wildcards, though, so there
may be no way to act on this concern.

The second issue is the use of the maximum number of digitsmax -- if
the owner of a higher-level node sets digitsmax, it can prevent the
delegated owner of a subtree from using more digits.  Or rather, the
subtree can use more digits as long as the caller doesn't attempt to
use send-n to determine the end of the dial string.  Indeed, it's not
clear that digitsmax saves DNS queires in any practical case.  So
maybe digitsmax should be removed.

Dale

---

From: Roy Arends <[email-masked]>
Date: Thu, 3 Apr 2008 21:16:05 +0200

On Apr 3, 2008, at 1:35 PM, Jim Reid wrote:

> be used with a wildcard.

Of course it is acceptable. Technically you could have a wildcard  
here, but it just makes no sense doesn't it? This record is at that  
position solely because it assumes a number of labels. That assumption  
only holds when its owner name is not a wildcard. Maybe a better  
wording would be "NOT RECOMMENDED".

> This violates DNS fundamentals: all RRtypes

This draft is an -00 version, and I'm sure this section is meant as an  
operations guideline, not as pure core protocol codex. It is a  
"Consideration" as the title of that specific section reveals. Like a  
sticker that warns against drying a cat in a microwave. Of course, it  
is a free world (mostly), and technically you could stick your cat in  
your microwave.

> the zone apex. It's game over.

Again, isn't that just a silly config mistake that one should avoid?

Roy

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 4 Apr 2008 10:55:14 +0100

> just don't see any benefit in doing it via DNS verses some other

The big benefit is that, given something looking like a phone number, you
do *one* lookup and get back either the full ENUM record or the send-n
record telling you that the number is incomplete.

With your approach, whenever the device has been given a full number, it
has to do two separate lookups. That's a extra round trip.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 4 Apr 2008 10:57:05 +0100

Richard Shockey said:
> digit strings must be fully formed in advance before query not during.

You've declared that to be the case, but there's no a priori reason why it
has to be true.

In other words, what is the problem with extending 3761 to allow the
interior nodes of the tree to contain useful information?

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 4 Apr 2008 10:38:07 +0100

> Wouldn't it be easier to use absolute values here?

No.

(1) This record corresponds to equivalent functionality in ISUP, which uses
the relative case.

(2) Making it relative means that the record value depends only on records
lower down the tree, not where the record is in the tree. If it's absolute,
then moving a sub-tree could alter the required value.

For example, my home telephone exchange has changed over the years from
        +44 954 8xxxx
    to  +44 954 78xxxx
    to  +44 1954 78xxxx
The latter change also involved an overlap period.

Under this proposal, the send-n record corresponding to the xxxx is
"pstndata:send-n/4-4" in all three cases. With your proposal, it would have
to alter from:
        pstndata:send-n/10-10
    to  pstndata:send-n/11-11
    to  pstndata:send-n/12-12

(3) The present proposal matches what the device consuming the record
actually needs to do. The above send-n record could be reached after I dial
any of:
    78
    0195478
    0044195478
In these three cases, the device needs a total of 6, 11, or 14 digits, but
in each case your proposal means it gets a record saying 12 digits. The
original proposal says it needs to get 4 more digits, which is always
correct.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 4 Apr 2008 10:49:55 +0100

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

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.

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

---

From: Jim Reid <[email-masked]>
Date: Fri, 4 Apr 2008 11:29:27 +0100

On Apr 3, 2008, at 20:16, Roy Arends wrote:
> Of course it is acceptable.

We will have to disagree about that. We're both used to disagreeing  
with each other. :-)

> Technically you could have a wildcard here, but it just makes no  
> sense doesn't it?

There may be circumstances where a wildcard will be needed. For  
instance when there are other NAPTRs besides this funky send-n  
service type at a given owner name.

Even though I despise wildcards, it's not unreasonable to have a  
construct like:
	*.<area-code-and-other-goop>.e164.arpa. NAPTR ... "<some-sip:-URI>" ..
to direct all numbers in a block to a specific end-point. Or maybe  
there are a bunch of wildcard NAPTRs, one for each specific service.  
If this scheme is deployed or needed, it can't be done if this send-n  
proposal goes ahead in its current form and there has to be one of  
these send-n NAPTRs as well. This is why I suggest a new RRtype  
that's specifically designed for encoding numbering schemes instead  
of a NAPTR.

> This record is at that position solely because it assumes a number  
> of labels.

This is also bad design. The RDATA for a resource record should not  
be dependent on the number of labels in the owner name. [And yes, I  
do know that RRSIGs have this property.] Thanks for reminding me  
about that so I could remind the list. :-)

> Maybe a better wording would be "NOT RECOMMENDED".

Maybe. But it still doesn't change the fact that it's very poor  
protocol design.

> operations guideline, not as pure core protocol codex.

An operations guidline may well be the intention. But what's written  
looks like "pure core protocol codex". Deployment of this NAPTR  
service type would prevent a core feature of the DNS from being used.  
Ordinarily I would rejoice about something that curtailed DNS  
wildcarding. But that should be an ID that gets rid of wildcarding  
completely, not something that tinkers with wildcard semantics for a  
particular NAPTR subtype.

> Again, isn't that just a silly config mistake that one should avoid?

That's a gross over-simplification Roy. Firstly, a protocol which is  
not just vulnerable to such a silly config mistake but actually  
allows it to be made is broken. Now when you consider the environment  
where this draft is expected to be used, the ramifications of a  
"silly config mistake" are mind-boggling. PBXs and SBCs could be told  
to dial incomplete numbers. This provides additional threats besides  
the obvious denial of service worries. For example, a SIP server  
could well have a configuration rule which says "fall back to the  
PSTN and SS7 (=> pay real money) when the outcome of the ENUM lookup  
results in some sort of call completion failure". Let's also consider  
the impact of this "silly config mistake" when it causes calls to  
emergency numbers to fail.
_______________________________________________
enum mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/enum

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 4 Apr 2008 11:37:01 +0100

Jim Reid said:
> purpose and probably not with a NAPTR.

Sheesh.

Firstly, the application is already going to be querying for NAPTR records,
so this means it gets back the desired information without any more effort.
Secondly, adding new RR types should be limited to major new issues that
can't be met with the existing types.

> [1] It is simply unacceptable to say this NAPTR service type MUST NOT  

This could be reworded, but it's still an issue.

> Well, let's not go down the wildcard SOA  
> and NS ratholes.
[...]
> "wildcards are OK for this RRtype but not that RRtype".

Why not? What are the semantics of a wildcard SOA?

As someone else said, this is a usage guide not a technical prohibition.

> instead of a boring "!^.*$!". :-)

In both cases, "don't do that".

What does it mean if I have two SOA records at the same node in a DNS tree?
What does it mean if the regexp substitution in an ENUM record is "^@.*$"?
The fact that a record can be misused doesn't make it a bad thing.

> 1.2.3.4.5.6.7.8.9.e164.arpa? Which is definitive?

Good point. Ray, this needs to be spelled out: the record lowest down the
tree overrides any higher up (since it can generally be more accurate).

Thus
    4.4.e164.arpa             would say     send-n/7-10
while
    0.0.5.4.4.e164.arpa       would say     send-n/6-6

although the earlier record implies only send-n/4-7.

> the scheme as proposed is vulnerable to all sorts of nasties.

Not so.

> IIUC  

No it doesn't.

The client picks up this record. It accepts one more digit (since digitsmin
is 1) *and then does an ENUM query*. If it gets back another send-n, that
overrides the 1-15. If it gets back a full record, it uses it. If it gets
nothing, it accepts another digit and tries again. If it accepts 15 more
digits and *still* doesn't get any records back, it signals that no record
was found.

The way I see these records being used is something like this:

    Set min to 1 and max to infinity.
    While max > 0
    {
        While min > 0
        {
            Accept another digit
            * On digit timeout, break from this inner loop
            * On overall timeout, break from the outer loop
            Decrement min and max (decrementing infinity has no effect)
        }
        Do a DNS lookup for NAPTR records.
        If you get the type you're looking for, return it.
        Otherwise, if you get a send-n record:
        {
            Set min to the digitsmin value.
            Set max to the digitsmax value, or infinity if there isn't one.
        }
        Otherwise set min to 1.
    }
    Return failure to find any record.

[First attempt; there may be errors.]

Ray, feel free to steal this if you think it helps.

> was stored lower down.

Only if the record says that the maximum number of digits is so small the
lower information can't be reached.

> That violates another DNS fundamental. Apart  

It doesn't.

> To do the equivalent for overlapped dialling, a DNS  
> has info about the number that's being dialled.

Right (though the device may hold an implicit top-level record of, say,
"send-n/6-15").

> I just don't see the  

I don't understand what you're getting at here. The user dials "78". The
internal configuation of the device converts that to "+44195478" or to
"+121278". Should the device do an ENUM lookup yet, or wait for more
digits? How many more?

Outside a few places like the NANP, this information is complex, hard to
get completely correct without help, and subject to change. Keeping all of
that information in every single device is a completely broken idea; the
same DNS tree as the target ENUM records appears to be the obvious place.

> stored in the DNS using an RRtype that was designed for that purpose.  

See above.

> points of the tree.

It takes a *lot* of information to describe E.164.

> Once that's been done, they can configure  

Unless I'm misunderstanding you, this isn't particuarly about local
dialling plans, it's about *national* dialling plans.

Which of these numbers are genuine and which are the wrong length?

    +448003634083
    +44800363487
    +448003635291
    +44800363587

On what date will the answer change?

---

From: Duane <[email-masked]>
Date: Fri, 04 Apr 2008 20:56:11 +1000

> record telling you that the number is incomplete.

Yes but you can't do that without breaking other DNS types so as the
other person pointed out regardless if you agree with it or not you
can't just pick and choose which DNS types are more important as they
are all deemed to be equal.

> has to do two separate lookups. That's a extra round trip.

I doubt you're approach will be allowed to become standardised if for no
other reason it breaks other DNS types so the benefit you are trying to
coax out isn't there at least won't be in RFCs.

-- 

Best regards,
 Duane

---

From: [email-masked]
Date: Fri, 4 Apr 2008 11:03:16 +0000

> As someone else said, this is a usage guide not a technical prohibition.

	semantics are easy. interpretation of results are
	mixed.

	wildcard use in SOA and NS rr's is not specifed.
	given the variety of DNS implementations in the 
	field, interpretation of wildcards for these RR tyeps
	will vary wildly, without predictable behaviour.
	(this from emperical evidence)

	if you are looking at a -usage- guide, then it is 
	wise to stick wiht proven, well defined technologies
	like NAPTR.  assuming of course that you want 
	something that can be deployed/used in your lifetime.
	
	if the enum wg wants to tackle a crisp technical 
	specification on how wildcards should behave for
	SOA and NS rr's - feel free to add that to the charter.

	when the DNS wg looked at clarification of wildcard
	behaviour, it specifically excluded these two RR types.

--bill (who tried this out)

---

From: Duane <[email-masked]>
Date: Fri, 04 Apr 2008 21:04:28 +1000

> can't be met with the existing types.

As you pointed out, if you wanted a standardised approach across
countries and some have already placed wild card records in their
records for telcos, but allow end users to override the telco blocks by
providing a more specific record.

Send-n would break things for when a more specific record wasn't
available and would also prevent these countries from standardising on
your approach and would force little disconnected internet islands or
worst multiple islands interconnected and disjointed.

I'm sure both approaches are far from desirable.

> As someone else said, this is a usage guide not a technical prohibition.

Ah, but it is, you are giving people the choice of one or the other in
certain situations and expressly disallowing them from using both.

-- 

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 - Because e164.arpa is a tax on VoIP

"In the long run the pessimist may be proved right,
    but the optimist has a better time on the trip."
_______________________________________________
enum mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/enum

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 4 Apr 2008 12:03:35 +0100

> are all deemed to be equal.

I still haven't seen anything saying that this breaks other DNS types.

At most there is the statement not to use this with wildcards. That perhaps
needs toning down, but it's advice rather than mandatory.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 4 Apr 2008 12:02:12 +0100

> is what the send-n mechanism was to avoid in the first place.

If the record holds relative lengths, as currently specified, a wildcard
won't work: it matches records at different levels in the tree, and these
need different send-n values.

To ensure that no unnecessary lookups happen, you do need to put a send-n
record in every intermediate node of the tree. In practice, though, if
people follow an algorithm like the one in my earlier message today, many
of these won't be needed and it might be acceptable to leave the others
out.

However, with a fully-provisioned sub-tree, the total number of send-n
records is less than 11% of the number of end records.

For example, if the root contains a record "send-n/6-15", then the part of
the UK tree corresponding to London contains:

    +4420xx            send-n/6-6        37 such records
    +4420xxxxxxxx      endpoints         up to 23 million such records

Even if we fill in the gaps, we get:

    +4420x             send-n/7-7         5 such records
    +4420xxx           send-n/5-5       273 such records
    +4420xxxx          send-n/4-4      2395 such records
    +4420xxxxx         send-n/3-3     23950 such records
    +4420xxxxxx        send-n/2-2    239500 such records
    +4420xxxxxxx       send-n/1-1   2395000 such records

The last set is the only one that's significant in size, but it only grows
as real data gets added (so in the absolute worse case, where exactly one
number from each block of 10 is in the database, it's the same number of
records as the real data).

> delegated owner of a subtree from using more digits.

This is a slight issue, yes. However, if the device uses subsequent send-ns
to override previous ones, it can be mitigated to some extent.

I accept that a certain amount of trust in the tree management is necessary.

> Or rather, the

It was intended as a way for the device to know that there's no point
accepting more digits and digging deeper into the tree. I accept that some
extra wording is probably needed.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 4 Apr 2008 12:09:12 +0100

> esteemed SIP aficionados dive in, ENUM is about numbers, not dialed  

Agreed. This isn't about dialling plans, but about incomplete E.164
numbers. These aren't the same thing.

Simple example: I pick up my office phone and dial 97222. The dialling
plan tells the phone to make an ENUM lookup for +44207222. Someone in the
USA picks up their phone and dials 01144207222. Their phone should be
looking up the same record. Dialling plans are about the difference between
what the two of us dial. This proposal is about the fact that +44207222 is
an incomplete number.

> of us call outside the NANP :).

But this is circular. What you're demonstrating is that 3761bis needs to be
*extended* to cope with incomplete numbers.

> locally into every switch is surely not what was meant. **

Nor is it anything to do with this proposal.

> believes is a complete number - it's something it suspects isn't.

Actually, it's something that it doesn't know whether it's a complete
number or not. Which is why "yes it is" or "SND 4" are both sensible
answers.

---

From: Otmar Lendl <[email-masked]>
Date: Fri, 4 Apr 2008 14:55:10 +0200

> > Wouldn't it be easier to use absolute values here?

The reason for my comment just was that absolute values play much
better with wildcards than relative ones.

> then moving a sub-tree could alter the required value.

Correct. You certainly will not manually edit the zone file anyway, but
instead generate it from a database. Thus the change in send-n records
is just a side effect of the changes you need to make in the backend database. 

> "pstndata:send-n/4-4" in all three cases. With your proposal, it would have

One changed send-n record as you move over 10^4 other records. 

> actually needs to do. The above send-n record could be reached after I dial

Whoa, stop here.

You're talking dial-plans now, not numbering-plans. 

As others have noted, we don't do dial-plans with ENUM.

/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: Otmar Lendl <[email-masked]>
Date: Fri, 4 Apr 2008 15:34:08 +0200

> there are a bunch of wildcard NAPTRs, one for each specific service.  

This is a common deployment for all countries with open numbering plans,
as the organization creating these records do not necessarily know the
length of all the numbers in its own block.

> that's specifically designed for encoding numbering schemes instead  

I might be completely off here, but my dim recollection about the
working of wildcards tells me that it doesn't matter one jota whether
you mix wildcards of type FOO with "normal" records of type FOO or with
"normal" records of type BAR. In any case, once there is *any* record
at a certain sub-domain, the wildcard from above does no longer apply.
(Actually, it's even worse, read RFC 4592 and look for the discussion of
"empty non-terminals". We had a lot of fun with that during our I-ENUM
trial.)

As I see it, you can mix

  *.<area-code-and-other-goop>.e164.arpa. NAPTR ... "<some-sip:-URI>" ..
    <area-code-and-other-goop>.e164.arpa. NAPTR ... "send-n/" ..

but neither

     *.<area-code-and-other-goop>.e164.arpa. NAPTR ... "<some-sip:-URI>" ..
 1.2.3.<area-code-and-other-goop>.e164.arpa. NAPTR ... "send-n/" ..

nor

     *.<area-code-and-other-goop>.e164.arpa. NAPTR ... "<some-sip:-URI>" ..
 1.2.3.<area-code-and-other-goop>.e164.arpa. WHATEVER ... "send-n/" ..

In both cases you'd need to add

      3.<area-code-and-other-goop>.e164.arpa. NAPTR ... "<some-sip:-URI>" ..
    *.3.<area-code-and-other-goop>.e164.arpa. NAPTR ... "<some-sip:-URI>" ..
    2.3.<area-code-and-other-goop>.e164.arpa. NAPTR ... "<some-sip:-URI>" ..
  *.2.3.<area-code-and-other-goop>.e164.arpa. NAPTR ... "<some-sip:-URI>" ..
  1.2.3.<area-code-and-other-goop>.e164.arpa. NAPTR ... "<some-sip:-URI>" ..
*.1.2.3.<area-code-and-other-goop>.e164.arpa. NAPTR ... "<some-sip:-URI>" ..

in order to get the desired resolution behaviour for the call routing.

The wildcard issue is thus irrelevant to the question of whether the
"send-n" application should use NAPTRs or a different RRTYPE.

/ol

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 04 Apr 2008 09:37:23 -0400

> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 04 Apr 2008 10:14:23 -0400

IMO this would be more appealing if the higher level entries (fewer 
digits) were authoritative at least for the minimum number of digits. 
Thus there would then be no further queries until at least that many 
digits were received.

	Paul

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 4 Apr 2008 10:17:27 -0400

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-masked] [mailto:[email-masked]] On Behalf Of Paul
Kyzivat
Sent: Friday, April 04, 2008 9:37 AM
To: Clive D.W. Feather
Cc: [email-masked] >> [email-masked]; Duane
Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00

	Paul

---

From: "PFAUTZ, PENN L, ATTCORP" <[email-masked]>
Date: Fri, 4 Apr 2008 10:28:56 -0400

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-masked] [mailto:[email-masked]] On Behalf Of
Brian Rosen
Sent: Friday, April 04, 2008 10:17 AM
To: 'Paul Kyzivat'; 'Clive D.W. Feather'
Cc: [email-masked]; 'Duane'
Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00

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.

national numbering authority.  In most cases, it's reported to the ITU,
and

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

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 04 Apr 2008 10:38:30 -0400

at end...

> standardize a way to obtain TN length and possibly other related numbering

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.

> it?  Since we're trying to close down ENUM, this would be done somewhere

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

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 4 Apr 2008 11:53:02 -0400

In line...

>  then ietf seems like a suitable place. But I am not really familiar
>  with>  the alternatives.

I'm told Geneva is very pleasant in the springtime. I highly recommend Le
boufe rouge restaurant. Excellent French bistro food. 

>  direct from those who implement the behavior.

Numbering is, has been and will continue to be a nation state issue. My own
sentiment is that this is a out of band data point that it will be very
difficult implement as a protocol. For in country calls ..its a network
element configuration issue.  

For out of country calls ..give the call to your termination partner and let
them sort it out (a trunking decision).

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 04 Apr 2008 12:32:34 -0400

I am certainly not going to argue with a Neustar employee about the 
realities of deploying and managing this sort of stuff.

But from a UAC perspective the solutions for variable length numbers 
suck. Overlap dialing is problematic at best, and timers don't give an 
adequate user experience. Provisioning is ok if you are deploying in a 
place with a simple, generally fixed length numbering plan, with few and 
easily knowable exceptions. But as soon as you throw in international 
dialing or deploy in a place with variable number lengths on anything 
approaching a per-number basis it doesn't work.

Requirements to solve this keep coming up from marketing.

A good (hypothentical) use case is:

- install a sip "pbx" in a german hotel, with a short main number
   and longer room numbers.

- connect that hotel to a sip service provider

- connect some other sip clients (unaffiliated with the hotel)
   to the same sip SP. Let these be adapters to black phones.

- try to call the desk and the rooms of the hotel from
   those clients. Give as good a user experience to the caller
   as before switching from pstn to sip on both sided.
   (Namely no lag after dialing the last digit before getting
   ringback.)

- also have those clients call another hotel that is still
   only on the PSTN, using redundant GWs on the SP network.
   Again give as good a user experience as before.

	Paul

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 4 Apr 2008 13:28:13 -0400

One thing I don't think we have to do is give the black phone or black phone
connected to TA a BETTER experience than they have now.

Those of you in countries that allow this kind of "enterprise can define how
long the number is", what is the user experience?  You can route as soon as
the prefix is entered.  What is the user experience after that?  What if
there was a short or a long pause between the prefix and one of the
internally consumed digits?  After all, the originating switch doesn't know
how many digits the enterprise uses.

Brian

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Friday, April 04, 2008 12:33 PM
To: Richard Shockey
Cc: 'Brian Rosen'; [email-masked]; 'Clive D.W. Feather'; 'Duane'
Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00

	Paul

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 4 Apr 2008 13:58:57 -0400

>  realities of deploying and managing this sort of stuff...

But anyone familiar with the realities of the E.164 plan and its national
implementations would tell you exactly the same thing. There is no
centralized registry describing the structure of the totality of E.164 plan.

We've had the issue of various here for years especially given the structure
of the German and Austrian dialing plans.

The business/technical case here is self evident. The issue is do you use
the DNS to reveal the structure of the national dial plan or use some out of
band method to describe the structure.

I understand the issue of post dial delay intimately since it also comes up
in how the ENUM query is to be preformed and by what network element and if
the "directory" is THE DNS or simply a IPRD (big fat cached ANS- ENUM box)
located in the carrier network that has its data store fed from various
forms of numbering data sources (Private ENUM). 

I know people hate timers but the solution proposed here is probably worse
than the problem.

---

From: [email-masked]
Date: Fri, 4 Apr 2008 19:56:40 +0100

> centralized registry describing the structure of the totality of E.164 
plan.

I rather thought the point of this was that in the DNS it doesn't have to 
be centralized :)

In the future hypothetical use case of multiple countries allowing 
interconnection between their national portability databases [i.e. my 
justification for trying to standardise this] then each database 
administrator can publish their own portion of the E.164 numbering plan.

NB: I don't currently expect to see this in public ENUM, it really is a 
private ENUM application.  However it does have theoretical benefits in 
public ENUM, and several people have said the data would be useful (even 
if some of them aren't happy with the current proposed implementation). 
Hence I think it's worth making the effort to ensure that it wouldn't 
break anything were it to be deployed.

Ray

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 4 Apr 2008 20:30:02 -0400

>  administrator can publish their own portion of the E.164 numbering

But the point some of us are making is that you don't have to publish the
structure of the national dial plan in the DNS. This could be a out of band
process. You just need to know where to get the data.

>  
>  NB: I don't currently expect to see this in public ENUM, it really is
>  a  private ENUM application.  

Like duh .. :-) 

However it does have theoretical benefits
>  in  public ENUM, and several people have said the data would be useful
>  (even  if some of them aren't happy with the current proposed
>  implementation).

---

From: Duane <[email-masked]>
Date: Sat, 05 Apr 2008 11:06:26 +1000

> break anything were it to be deployed.

Since public enum was messed with in the pass to try and bolt on an
infrastructure component maybe something similar could be done that
would allow both public enum to still have the possibility of wild
cards, while allowing send-n to be published as well without interfering
as well. Just a thought.

-- 

Best regards,
 Duane

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 5 Apr 2008 01:48:45 -0400

Howdy,
I don't disagree with the points you guys are making, but I wonder if you're coming at this from the wrong angle given the relative sensitivities to ENUM-specific uses of DNS.

If one of your use-cases or goals is to enable this for public ENUM, I think one way to look at this is simply as a DNS problem.  Alice has asked a DNS NAPTR query, for foo.bar.com, and its server would like to tell her that NAPTR record types don't exist for foo.bar.com but may exist for *.*.foo.bar.com and *.*.*.foo.bar.com.  In other words the server wants to answer differently than not-found, or with additional detail, and could answer this way for any RR type asked of it for any name.  I have absolutely zero clue if that's going to help or make it worse in the IETF's view, but it's different. :) (it could easily be worse, fwiw, because it has a potential to raise a LOT of issues)

I hesitated saying this, because I fear what this would mean for UNUSED's chances of getting approved, but another way to look at it is as a specific type of UNUSED scenario, obviously.  Alice has asked a DNS NAPTR query for 1.4.4.e164.arpa, and there truly is no such E.164 globally (pstn and all), so all you're missing is something in the resulting data URN to tell the client why. (the latest draft is an http URL, but I'm going to try to revert to a data one that is well-defined, a la pstndata)  But at least you could then simply define an extension ABNF and semantics for the unused-data URN in a separate draft.  It would not break UNUSED, because the unknown extension abnf in the URN would simply be ignored.

If your goal is only private ENUM, but you want it publicly documented to foster interop with vendors for private use (a goal which I can certainly understand), then nothing stops you from defining it for UNUSED or your current way as an informational RFC, with clear language regarding applicability.  But I still think it would be good to hash out the best way for it to be done, so that it's not specific to private use in the UK.

-hadriel

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 5 Apr 2008 09:36:22 -0400

I think we're tending to agree that the data is useful, and disagree on how
you get it.

I think we're tending to agree that even if you use private ENUM, you need
the data.

The question is then where to put it.

I would point out that the SOURCE of the data is the number plan
administrator in a country, which is distinctly different from the operator
of the public enum tree, if there is one.

I'd rather see a mechanism that the number plan administrator could use
directly, and I'd like to avoid the delegation issues of public enum.

It's really just a file.  Couldn't we just define an XML data structure for
that file and figure out a way to publish it? 

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hadriel Kaplan
Sent: Saturday, April 05, 2008 1:49 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00

Howdy,
I don't disagree with the points you guys are making, but I wonder if you're
coming at this from the wrong angle given the relative sensitivities to
ENUM-specific uses of DNS.

If one of your use-cases or goals is to enable this for public ENUM, I think
one way to look at this is simply as a DNS problem.  Alice has asked a DNS
NAPTR query, for foo.bar.com, and its server would like to tell her that
NAPTR record types don't exist for foo.bar.com but may exist for
*.*.foo.bar.com and *.*.*.foo.bar.com.  In other words the server wants to
answer differently than not-found, or with additional detail, and could
answer this way for any RR type asked of it for any name.  I have absolutely
zero clue if that's going to help or make it worse in the IETF's view, but
it's different. :) (it could easily be worse, fwiw, because it has a
potential to raise a LOT of issues)

I hesitated saying this, because I fear what this would mean for UNUSED's
chances of getting approved, but another way to look at it is as a specific
type of UNUSED scenario, obviously.  Alice has asked a DNS NAPTR query for
1.4.4.e164.arpa, and there truly is no such E.164 globally (pstn and all),
so all you're missing is something in the resulting data URN to tell the
client why. (the latest draft is an http URL, but I'm going to try to revert
to a data one that is well-defined, a la pstndata)  But at least you could
then simply define an extension ABNF and semantics for the unused-data URN
in a separate draft.  It would not break UNUSED, because the unknown
extension abnf in the URN would simply be ignored.

If your goal is only private ENUM, but you want it publicly documented to
foster interop with vendors for private use (a goal which I can certainly
understand), then nothing stops you from defining it for UNUSED or your
current way as an informational RFC, with clear language regarding
applicability.  But I still think it would be good to hash out the best way
for it to be done, so that it's not specific to private use in the UK.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 5 Apr 2008 10:40:09 -0400

> From: Brian Rosen [mailto:[email-masked]]
>

Not really, or rather it won't be enough, if it's not put into the NAPTR records some way.  For closed environments that may well be enough, but for the public ENUM it would be really hard to see how any random UA is to know to get which file for which country or have the latest copy at all times, etc.  So I think they would query an UNUSED or non-existant entry a lot regardless.  One way to do it is using an UNUSED http url, to point to a source for the data, instead of a data url.  But I don't see why it couldn't (maybe optionally) be a data url, if it were sufficiently defined.

> of the public enum tree, if there is one.

Yes, but that's not the case for private use, and even for public use does it prevent the operator of the public enum tree from being able to supply such "hints", or the numbering plan admin from coordinating such with the operator?  IANAE.

> directly, and I'd like to avoid the delegation issues of public enum.

ESPP? ;)

> that file and figure out a way to publish it?

There are pros/cons to doing this in files.  There is no doubt that it would be far more efficient (messaging-wise) for each UA or proxy on the planet to have a numbering plan template, for the country it makes lots of calls to, but my guess is it would be fairly impractical and unnecessary for each to have those plans for all countries, and impractical for the files to be available to all UAs/proxies.  DNS has the rather nice property of lightweight just-in-time delivery with a limited scope to the node record being queried for.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 05 Apr 2008 22:57:57 -0400

> of the public enum tree, if there is one.

I will admit that I don't fully understand this stuff, so the following 
might be nonsense...

IIUC this may be the responsibility of the number plan administrator of 
a country in those cases where that isn't delegated. But in some places 
it is indeed delegated, perhaps all the way down to an end customer. 
Certainly is sounds like it is that way in Germany.

> directly, and I'd like to avoid the delegation issues of public enum.

In those cases where number length can be delegated it is *just* like 
the delegation issues of public enum. That is why it seems interesting 
to use the same or an analogous mechanism.

If the only variability was at the country level then I would agree with 
you that this is overkill and the data ought to simply be provisioned. 
Is would be quite feasible for individual UAs to be provisioned with 
data for all countries. But not every business in Germany.

	Paul

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 7 Apr 2008 10:59:41 +0200

> how many digits the enterprise uses.

The simple answer is: The user does not notice that the PBX on the
terminating side is not integrated into the operator's switch. It's all
completely transparent and realtime. Overlap dialing is an end-to-end
feature: individual digits are passed from originating PBX, via
originating carrier, via destiation carrier to the receiving PBX.

Here are some D-channel traces to explain this (using Asterisk 
connected to a Colt ISDN PRI, calling is via Telekom Austria.)

Lines starting with < are receiving, the ones with > are sent to the
operator.

I'm calling extension 300 on +43 1 25397. 

1) Direct dialing (incl. extension)

< Message type: SETUP (5)
< Called Number (len= 6) [ Ext: 1  TON: Unknown Number Type (0)  NPI:
ISDN/Telephony Numbering Plan (E.164/E.163) (1)  '300' ]

New call coming in, indicting extension 300. Actually, it is a config
option on an ISDN line whether these "Called Number" messages contains
just the extension or the national number + extension.

> Message type: SETUP ACKNOWLEDGE (13)
> Message type: CONNECT (7)

"300" is known, thus Asterisk accpects the call.

< Message type: CONNECT ACKNOWLEDGE (15)

2) overlap dialing.

On the sending side, all digits are passed one by one to the operator,
the second I hit the '7' key, I see on the receiving side:

< Message type: SETUP (5)
There is no "called number" information element in the setup message

> Message type: SETUP ACKNOWLEDGE (13)

I continue dialing and see

< Message type: INFORMATION (123)
< Called Number (len= 4) [ Ext: 1  TON: Unknown Number Type (0)  NPI:
ISDN/Telephony Numbering Plan (E.164/E.163) (1)  '3' ]

then:

< Message type: INFORMATION (123)
< Called Number (len= 4) [ Ext: 1  TON: Unknown Number Type (0)  NPI:
ISDN/Telephony Numbering Plan (E.164/E.163) (1)  '0' ]

< Message type: INFORMATION (123)
< Called Number (len= 4) [ Ext: 1  TON: Unknown Number Type (0)  NPI:
ISDN/Telephony Numbering Plan (E.164/E.163) (1)  '0' ]

At this point, the Asterisk knows that the extension is complete
and thus sends:

> Message type: CONNECT (7)

3) Timeout (receiving side):

Here is the case where the receiving side implements a timeout:

Overlap-dialing till the 7, then waiting:

< Message type: SETUP (5)   (no called party IE)
> Message type: SETUP ACKNOWLEDGE (13)

(some seconds later)

> Message type: CONNECT (7)

4) Timeout (sending side)

I can't reproduce this right now, but I rememeber that when calling
from a POTS phone, the network will issue a "SENDING COMPLETE" IE
to the receiving ISDN line after a suitable delay.

------------

I hope this helps a bit.

/ol

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 7 Apr 2008 08:56:51 -0400

Right.

So, there is indeed a pretty substantial problem to do something sensible
for a SIP version of this.  The network could complete its processing of the
call as soon as it has sufficient digits to route.  The originating end
however needs to know how many more digits there will be in order to
actually send a complete INVITE, and the receiving end can't issue an 200
until it has all the digits.

Seems like we have two choices, neither of them good.
1) We build a database which really is delegated out to enterprises, and
require that they populate the database if they want to get calls, and have
the originating side collect the right number of digits, and send a single
INVITE with the correct telephone number
2) Have the originating side send an INVITE when it has at least the prefix
number of digits, and then let the receiving end collect DTMF to determine
the rest of the digits using early media.  To get the right user experience,
you can't complete the call until all the required digits are entered.

Just another user experience question:
Suppose there was a network busy condition.  The user is going to get the
error tone after they enter the prefix, but before they have completed
dialing, right?

Brian

-----Original Message-----
From: Otmar Lendl [mailto:[email-masked]] On Behalf Of Otmar Lendl
Sent: Monday, April 07, 2008 5:00 AM
To: Brian Rosen
Cc: 'Paul Kyzivat'; 'Richard Shockey'; [email-masked]; 'Clive D.W. Feather';
'Duane'
Subject: Overlap dialing user experience (Re: [Enum] I-D Action: New draft -
draft-bellis-enum-send-n-00)

2) overlap dialing.

then:

(some seconds later)

------------

I hope this helps a bit.

/ol

---

From: "Pete Cordell" <[email-masked]>
Date: Mon, 7 Apr 2008 14:56:16 +0100

----- Original Message From: "Brian Rosen"

> you can't complete the call until all the required digits are entered.

Another option may be to reject the INVITE with some kind of message (I 
guess 4xx, but could it be some kind of moved 3xx type thing?) that says 
insufficient digits and don't try to contact me again until you have n more 
digits.

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

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 7 Apr 2008 16:01:39 +0200

> you can't complete the call until all the required digits are entered.

Asterisk seems to do something similar to this.

> error tone after they enter the prefix, but before they have completed

Yes. It doesn't happen much these days, but on a POTS service you used
to get the network busy cadence the moment you dial e.g. the area code
towards which the network was busy.

/ol

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 07 Apr 2008 14:02:26 -0400

There is a bit of a problem for sure. While there is theoretically a 
"overlap dialing" solution in RFC3578, but its my impression that this 
is rarely implemented, and that there are technical problems in doing so.

> INVITE with the correct telephone number

This would certainly be good from the caller's perspective. Whether it 
is feasible is TBD. Note that presumably we would need this populated 
even for enterprises that are connected to the PSTN and have no sip 
usage of their own, in order that sip-based callers can call them via 
gateways.

IMO a solution needs to work when either caller or callee or both are 
sip, and in the latter case whether the entire path is sip or there a 
pstn hop in the middle.

And from what I have picked up from marketing types, determining end of 
dialing by timers is *not* an acceptable user experience.

	Paul

---

From: [email-masked]
Date: Tue, 8 Apr 2008 18:23:54 -0400

From: "Pete Cordell" <[email-masked]>

RFC 3261, section 21.4.22: 484 Address Incomplete

   The server received a request with a Request-URI that was incomplete.
   Additional information SHOULD be provided in the reason phrase.

      This status code allows overlapped dialing.  With overlapped
      dialing, the client does not know the length of the dialing
      string.  It sends strings of increasing lengths, prompting the
      user for more input, until it no longer receives a 484 (Address
      Incomplete) status response.

If we want to send partial-dial-string queries into the network, as
in Otmar's example, we might as well use INVITE and 484 responses as
they are already defined.  The refinement would be to be able to
provide information as to the minimum number of additional digits
needed in the 484 response.

Dale

---

From: Duane <[email-masked]>
Date: Wed, 09 Apr 2008 11:53:24 +1000

>    insufficient digits and don't try to contact me again until you have n more 

What about non-VoIP applications that failed to find a URI and want to
check if the length was valid?

-- 

Best regards,
 Duane

---

From: [email-masked]
Date: Tue, 8 Apr 2008 23:01:40 -0400

From: "Brian Rosen" <[email-masked]>

   overlapped dialing,

Do we actually need to support overlapped dialing?

My belief is that (in the US) international calls (outside the +1
area) terminate dialing with a time-out, or by the user pushing '#'.

At the moment, my desk phone is a SIP phone, and it's got a "Send"
softkey to terminate dialing.  Our customers have made some noises
that they'd like our PBX's configuration system to work out the
dialplan regexp for their phones, but as a feature request, it is
remarkably far down the list.

So from where I stand, the demand for overlapped dialing seems to be
rather weak.

Dale

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 8 Apr 2008 23:22:18 -0400

> [email-masked]

We've seen it more lately, where they sometimes send multiple SIP INVITEs as more buttons are pushed.  It's rather ugly so far.

> softkey to terminate dialing.

Sure, people have been getting more mobile-phone-trained. :)
But lots and lots of SIP is generated by analog/POTS gateways for homes/SMBs, where I think they want a POTS-like black-phone experience. But YMMV.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 8 Apr 2008 23:23:26 -0400

Even if we should send a 484 back, how do we know to send that vs. a 480/604/whatever based on ENUM DNS not-found/unused responses, or even just alternate route it to the PSTN?

-hadriel

> Sent: Tuesday, April 08, 2008 6:24 PM
> To: [email-masked]
> Subject: Re: [Enum] Overlap dialing user experience (Re: I-D Action:
> Newdraft - draft-bellis-enum-send-n-00)
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Apr 2008 00:19:18 -0400

Dale,

I have marketing people telling me they need solutions for dialing 
variable length numbers without either a send key or a timeout, in order 
to give competitive user experience. This is coming up in those 
countries where variable length numbers are common, not in the US.

	Paul

---

From: Jay Daley <[email-masked]>
Date: Wed, 9 Apr 2008 08:44:03 +0100

Brian

> until it has all the digits.

You appear to have narrowed the case to solely the German/Austrian example 
where there is a nationally known prefix and the rest of the digits are 
variable.  This draft is not solely about that but primarily for those 
countries where the prefix length is different for different prefixes (if 
you see what I mean!).

> you can't complete the call until all the required digits are entered.

Assuming you try to apply this to that stated use case of this draft (as 
explained above) then this only works where the SIP URI can be determined 
from insufficient digits.  This is highly unlikely to be the case in user 
ENUM since each provisioned user number will have chosen their own SIP 
termination.  In infrastructure ENUM it might be possible when a carrier 
has not lost any numbers from its block allocation to number porting, but 
those cases will be rare.

This draft addresses the issue of determining where to send the INVITE to, 
so trying to solve this by the way the INVITE process works is 
contradictory.

Jay

---

From: "Pete Cordell" <[email-masked]>
Date: Wed, 9 Apr 2008 09:24:19 +0100

----- Original Message ----- 
From: "Hadriel Kaplan" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Wednesday, April 09, 2008 4:23 AM
Subject: Re: [Enum] Overlap dialing user experience (Re:I-D Action: 

>
> Even if we should send a 484 back, how do we know to send that vs. a 
> 480/604/whatever based on
> ENUM DNS not-found/unused responses, or even just alternate route it to 
> the PSTN?

My thinking was that the UA would do an ENUM query for a number, and get 
back some sort of successful, go here response.  The UA would then send an 
INVITE and maybe get a 484 then.

So in the case of this German hotel, the ENUM query would be based on the 
E.164 data that the number provider has, and would resolve to the hotel SIP 
proxy.  The initial INVITE would be sent and the hotel's SIP proxy would 
then be able to say, "484: well actually we need a few more numbers".
I must confess that I'm not following all the issues about the impact of 
wildcards and relative vs. fixed length n's in the send-n proposal, but I 
could see something like send-n in ENUM and 484 in SIP complementing each 
other rather than competing.

HTH,

Pete.

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 9 Apr 2008 09:16:38 -0400

I think the mechanism needed by carriers to route calls is a heck of a lot
easier to solve then a mechanism needed by a phone to dial a hotel that
decided on its own how long it's numbers are.

If you want to generalize to "needed by originators" instead of carriers, it
doesn't change the problem.

The number of digits needed to route to the termination domain is determined
by a block assignment by a number administrator.  There is one per country
of them.  Creating a system where we define a way for them to communicate
block assignments seems to be a pretty tractable problem.

The number of digits needed to complete a call where the termination domain
chooses the number length is a bigger problem, with a much more difficult
delegation problem.  Essentially it requires something on the order of user
enum, with small groups of numbers delegated to the termination domain.
User enum has not been an unqualified success.  We can manage delegation
down to small units (I have 3 domains I manage, how about you?, but it's
messy, and takes a lot of work, and costs $10 a year in the marketplace.  In
fact it probably works where user enum doesn't because it is a marketplace,
and there is choice of TLDs.  In this case, we really are down to managing a
single root, which implies monopolies, and we get all the problems we have
with user enum.

So, I'd rather come up with a solution to the route-to-the-domain problem,
and come up with a sip solution for the route-to-the-phone problem.

Brian

-----Original Message-----
From: Jay Daley [mailto:[email-masked]] 
Sent: Wednesday, April 09, 2008 3:44 AM
To: Brian Rosen
Cc: [email-masked]
Subject: Re: [Enum] Overlap dialing user experience (Re: I-D Action: New
draft - draft-bellis-enum-send-n-00)

Brian

Jay

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 9 Apr 2008 10:22:14 -0400

> From: Pete Cordell [mailto:[email-masked]]
>

That's certainly one way to go.  I think it's pretty ugly, because it means sending SIP Invites all over the place when they didn't need to, and it means having SIP proxies available for every partial number, but it's one way to go.  I mean certainly nothing precludes that model for people/hotels that want it, even if we do decide some other way of handling this issue in general.

> other rather than competing.

Oh no I didn't mean they were competing - I meant the issue at hand is, imo, how the UAC or proxy doing the ENUM query can know to send back a 484 vs. another failure response (with/without whatever additional data it needs).

-hadriel

---

From: "Pete Cordell" <[email-masked]>
Date: Wed, 9 Apr 2008 16:33:47 +0100

----- Original Message From: "Hadriel Kaplan" <>

> That's certainly one way to go.  I think it's pretty ugly, because it 
> means sending
> SIP Invites all over the place when they didn't need to, and it means 
> having SIP
> proxies available for every partial number, but it's one way to go.  I 
> mean certainly
> nothing precludes that model for people/hotels that want it, even if we do 
> decide
> some other way of handling this issue in general.

I was envisioning ENUM would get you to the hotel.  The UAC would then send 
an INVITE to the hotel, and its proxy would return 484, I need 4 more digits 
(or maybe the minumum digit length is 20 or whatever it works out to be). 
Then the UAC sends a new invite with the extra collected digits.

Admittedly the x more digits thing is not in place, but it doesn't seem too 
difficult to come up with a header that could do that.

To me that sounds a lot better than administering some mega database, or 
sending an initial INVITE to the hotel and then sending extra DTMF (would 
that be INFO / RTP or whatever etc.?)

> Oh no I didn't mean they were competing - I meant the issue at hand is, 
> imo, how
> the UAC or proxy doing the ENUM query can know to send back a 484 vs.
> another failure response (with/without whatever additional data it needs).

Maybe I'm missing something, but the UAC keeps banging away at ENUM until it 
gets a 'go here' reply.  It then does a SIP INVITE and works from there 
(unless it gets a tel: re-direct, in which case it's back to ENUM I guess, 
but hopefully that won't happen!)

On reflection, maybe the thing I'm missing is I don't think ENUM has the 
ability to return a URI that a UAC, after receiving a 484, would be able to 
figure out how to add, say, 4 more digits to.

---

From: Jay Daley <[email-masked]>
Date: Wed, 9 Apr 2008 22:25:25 +0100

Brian

> block assignments seems to be a pretty tractable problem.

There is an assumption there that the number structure created by the 
national number administrator is the same as the structure within the ENUM 
tree.  This is only true in the pathological case of a fully populated 
tree.  In User ENUM that simply will not be the case.

What this draft does is allow the manager of a part of an ENUM tree to 
describe the structure of that part of the tree and thereby make the 
dialling process more efficient. 

In the case of User ENUM this could be the T1 registry.  As numbers are 
registered with them they would create and/or modify send-n records higher 
up the tree from where the numbers are provisioned.  These send-n records 
would therefore be quite dynamic, responding to the local growth in user 
ENUM.

Jay

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 9 Apr 2008 17:59:08 -0400

You are missing the point.

The number of digits need to route the call to the correct domain is
determined by a more static database which is not subject to public enum
implementations.  If we can solve the entire route-to-the-domain problem
simply, without requiring deployment of user enum, that is, in my opinion, a
better answer.

Once you get to the domain, there is more routing to do.  I would prefer
that the domain handle that directly.  That is, after all, how SIP works.
We route to the domain using one set of mechanisms.  Then the domain uses
another set of mechanisms to route to the device.

Right now, route to the device with variable length TNs is .001% of the
problem.  The other 99.999% is route to the domain.  I think a simple
solution to that would be great.  I don't think that is an ENUM solution.

Brian

-----Original Message-----
From: Jay Daley [mailto:[email-masked]] 
Sent: Wednesday, April 09, 2008 5:25 PM
To: Brian Rosen
Cc: [email-masked]
Subject: RE: [Enum] Overlap dialing user experience (Re: I-D Action: New

Brian

Jay

---

From: Jay Daley <[email-masked]>
Date: Wed, 9 Apr 2008 23:13:51 +0100

Brian

> implementations. 

No I'm not missing the point - it the incorrect assumption in what you are 
saying above that I am disagreeing with.  The number of digits needed to 
route a call is not determined by an independent static database, it is 
determined by the numbers provisioned in the ENUM trees, which in turn 
creates the structure of that tree.  This draft is a way of describing 
that structure.

> solution to that would be great.  I don't think that is an ENUM 
solution.

I have no objection to anyone working on that further routing.  But nobody 
in their right mind who runs a user ENUM tree (or other ENUM tree) would 
run a SIP server that just deals with that further routing and then add a 
NAPTR for that SIP server at every non-terminal point in their ENUM tree, 
if they could use send-n instead. 

Jay

---

From: Lawrence Conroy <[email-masked]>
Date: Wed, 9 Apr 2008 23:49:43 +0100

Hi Jay, Brian, folks,
  must resist - nope - I can't. This one has finally reached my  
threshold.
Jay - I know that you ARE aware of Ofcom's number plan docs. These have
absolutely F. all to do with ENUM, or LDAP, or any other implementation.
They are a representation of the national number plan in the UK, and  
they
DO give the digit length for each block. From this can be derived:
(i) the set of general prefix-dependent number length rules, AND
(ii) the number of digits needed to determine the route for calls to
      numbers in any of these blocks.
[NB - (i) and (ii) ARE NOT THE SAME].
Looks pretty static to me (qua Ofcom-anointed number plan changes).

Given that ENUM-like schemes are partitioned on a digit-by-digit  
basis, one
can reflect these digit length (and routing determination length)  
values in
DNS. Of course this is not kosher in ENUM, as these records will not  
be at
leaf nodes in the tree, and ENUM is for fully qualified E.164 numbers  
ONLY.

Re. your earlier comment on it not being possible in user ENUM - this  
is not
a technical/protocol argument. Your nation state may have chosen to  
require
each entry anywhere in the tree to be under the control of a  
subscriber OR
NOT BE THERE AT ALL, but that is only one choice. Other nation states/ 
regions
may allow (or even require) carrier control over nodes in the tree, or  
the
NRA may retain control over them, or give up entirely on DNS as a bad  
job
(e.g. USA/North America).

It seems to me perfectly reasonable to consider other means of  
publishing
or disseminating this (meta-)data. DNS is not necessary, particularly  
with
such bizarre data models as seem to be proposed by NICC.

all the best,
   Lawrence

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 9 Apr 2008 18:54:23 -0400

Here is an example of the authoritative data we're trying to get at, copied
from ITU Bulletin 901:
Rwanda (country code +250)
Communication of 9.I.2008:
The Agence Rwandaise de Régulation des Services d'Utilité Publique, Kigali,
announces the current National Numbering Plan (NNP) of Rwanda. A new
numbering plan is under preparation and will be communicated as soon as it
is available.

Country code	+250
International prefix	00

Overview:
Minimum number length (excluding the country code):	six (6) digits
Maximum number length (excluding the country code):	eight (8) digits
Details of numbering scheme:

 (1)	(2)	(3)	(4)	(5)
N(S)N (National (Significant) Number)	N(S)N
number length	Usage of E.164 Number	Operator	Additional
information
	Maximum
length	Minimum length			
5YXXXX
5YZXXX or
5YZXXXXX	8 digits	6 digits	Geographic number for fixed
telephony services	Rwandatel	Digit “5” identifies the Rwandatel
company: Y and Z identify the regional base used in giving telephone
numbers. Y, Z and X form the Subscriber Number (SN).

05XXXXXX	8 digits	8 digits	Non-geographic number for
digital mobile telephony services
(e.g. CDMA)	Rwandatel	“05” digits identify the Rwandatel company
and then X forms the Subscriber Number (SN).

06YZXXXX	8 digits	8 digits	Geographic number for fixed
telephony services	Artel	“06” digits identify the Artel company; Y
and Z identify the regional base used in giving telephone numbers. Y, Z and
X form the Subscriber Number (SN).

08XXXXXX	8 digits	8 digits	Non-geographic number for
digital mobile telephony services
(e.g. GSM)	MTN Rwanda cell	“08” digits identify the MTN Rwanda cell and
then X forms the Subscriber Number (SN).

03XXXXXX	8 digits	8 digits	Non-geographic number for
digital mobile telephony services
(e.g. GSM)	MTN Rwanda cell	“03” digits identify the MTN Rwanda cell and
then X identifies the Subscriber Number (SN).

It's possible to reflect that in an enum tree, but it's certainly not the
only way.

This is all the information you need to get a call routed to the correct
domain in country code +250.  There isn't, but if there was a block that was
6-8 digits, with the last 1 or 2 digits determined by the end domain, the
information needed to route the call to the end domain would be in this
table.  

The problem I have with doing this in enum is that we need the data for all
countries to run any form of routing: public, infrastructure or private
ENUM, TRIP or any other way.  If there is no user enum deployed for any
country, we need this data anyway.  We need a way to encode the above data
and distribute it for every country instead of the ITU bulletin that the
table is copied from.  That is the problem.  The shape of a non existent
public enum tree has nothing to do with that.

Another little tidbit.  Often, the number plan administer announces a change
before the change is in effect.  They include an effectivity date.  Some
times, they communicate that there is a period of time where old and new
versions of the number plan will work.  Whatever we do has to communicate
that data.

One way to look at the disagreement we are having is that I'm interested in
providing a way for some entity building an ENUM T1 to know what the shape
of the T1 is.  You are interested in communicating to a user of this T1 how
to use it.  You have to solve my problem before you solve yours.

I think once you solve my problem, everyone can use that solution pretty
effectively, and they won't need you to solve it.  That may not be the case,
but I think we have to solve my problem first.  Then we can see if it works
for everyone. 

Brian
-----Original Message-----
From: Jay Daley [mailto:[email-masked]] 
Sent: Wednesday, April 09, 2008 6:14 PM
To: Brian Rosen
Cc: [email-masked]
Subject: Re: [Enum] Overlap dialing user experience (Re: I-D Action: New

Brian

Jay

---

From: Jay Daley <[email-masked]>
Date: Thu, 10 Apr 2008 00:02:13 +0100

Lawrence

> Looks pretty static to me (qua Ofcom-anointed number plan changes).

Neither of those are the ENUM tree!!  There is an idealised state of the 
ENUM tree if is populated with every number in the national number plan 
but that is not going to happen.

The send-n proposal is about describing the ACTUAL structure not the 
idealised structure.  That is not static and not derivable from either (i) 
or (ii) above.

> leaf nodes in the tree, and ENUM is for fully qualified E.164 numbers 

Is that by dogma or design?

> such bizarre data models as seem to be proposed by NICC.

I agree entirely that we need a better, standardised way of representing 
(i) and (ii) above.  Some companies even make a living on creating such 
tables for their customers.  But that is entirely orthogonal to send-n.

Jay

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 9 Apr 2008 22:14:59 -0400

Well as a purely administrative issue ....

I'm assuming someone wants to present send-n or successor document in
Dublin?

Between this a revised UNUSED and of course, Source URI I'm going to need a
2 hour slot ?

Correct?

Working groups have "long tails" but really ...

>  Of Jay Daley
>  Sent: Wednesday, April 09, 2008 7:02 PM
>  To: Lawrence Conroy
>  Cc: [email-masked]
>  New draft - draft-bellis-enum-send-n-00)
>  
>  Lawrence
>

---

From: Richard Stastny <[email-masked]>
Date: Thu, 10 Apr 2008 07:17:28 +0200

> that the domain handle that directly.

Folks,

I am watching this discussion since some time and
I am wondering.

There seems to be an understanding of numbering
from 30 years in the past:

one uses number blocks to route to the
domain (= operator) and then the operator does
rest

Never heard about number portability ?

Regardless of User or Infrastructure ENUM
the routing to the domain has to be
per number finally. The domain has to
find out where the user really is connected.

The Rwanda example is nice and  was discussed
in Austria 1985 when new carriers are introduced,
because the routing was simple, but never implemented
because it does not support NP, beside other drawbacks.

Richard

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 10 Apr 2008 09:00:35 -0400

Richard

Nice to hear from you, hope you are enjoying your retirement and numbering
blocks still have great relevance 30 years later.

Nearly every country has number block assignments.  The information we are
trying to extract is the length of a number, although it does turn out that
the carrier assignment data is also useful, and as long as we're providing a
mechanism to extract the number plan from the number administrator, we might
as well get the assignment data.  Even in the U.S., which has a single
length, knowledge of the block assignments is useful to know:
1) What is a valid number
2) Which carrier owns the number when the number has not been ported.

I know of very few number portability databases where every number ever
issued is in the database.  Having access, in one form or another, to the
database only gets you so far.

However, I'd like to keep this discussion on track, which is determining the
number of digits in a number needed to route.

Brian

-----Original Message-----
From: Richard Stastny [mailto:[email-masked]] 
Sent: Thursday, April 10, 2008 1:17 AM
To: Brian Rosen
Cc: 'Jay Daley'; [email-masked]
Subject: Re: [Enum] Overlap dialing user experience 

Folks,

Richard

---

From: Richard Stastny <[email-masked]>
Date: Thu, 10 Apr 2008 17:42:49 +0200

Brian,

 > number of digits in a number needed to route.

Infrastructure ENUM is a replacement for All Call Queery (ACQ)
It only makes sense if a certain country or number range
is fully implemented.

The simplest and easiest way to do so is to
implement only a Tier 1 datebase (contrary to
User ENUM), where all E.164 numbers of the
number range are entered and are pointing to
the carrier hosting the number.

The problem I see here with send-n is that
you cannot use this simple structure here
and have to make zone delegations below to
hold the send-n NAPTRs.

In DE and AT, the whole thing does
not work anyway, because e.g.
you may have +43 1 9793321
and          +43 1 97933221
and          +43 1 97933222
and this is a carriers choice.

regards

Richard

---

From: "Rosbotham, Paul" <[email-masked]>
Date: Thu, 10 Apr 2008 09:36:36 +0100

Hi all

I too have been watching this debate with interest & biting my tongue, but threshold reached.

I chair the UK telecoms standards agency.  The concept of Send-N was developed there for usage in the numbering database that UK industry is currently procuring (more below), from a requirement agreed by a group that contains every major UK telco.  So, yes, we do sort of know that Ofcom provides a numbering plan because it's our day-to-day business.  We also know what it's issues are hence why we want something better.

I should at the outset say

- I'm ambivalent about bringing Send-N into the international domain & potential use of it in user-ENUM; I can see the attractions & issues, but my main concern is the introduction of our national database that I have a regulatory obligation to implement.
- I apologise that a lot of this is UK-centric, however it is worthy of mention here because the issues are pretty much replicated wherever there's a variable length numbering plan.

So, to where Send-N originally arose.  We are currently putting together a database that is notionally for support of portability, but (subject to the economics) may well contain the association of every number to the terminating domain.  It will offer a real-time query interface using an ENUM-like approach, but most telcos will in practise download the whole thing into their networks and query locally (again, in many cases using a network-internal ENUM approach).

As Lawrence says, it is possible to take the Ofcom numbering plan and embed it into your callservers/switches, and use that to ascertain when you've got sufficient digits to query the database.  However,

- errors do creep into the plan.
- for reasons that are too complicated/irrelevant to go into here, it isn't exhaustive, in particular in the 0800 ranges that Clive Feather mentioned in an earlier mail.
- it is a large amount of data that uses significant technical resources on callservers/switches and human resources to keep up to date.
...for this reason I think every telco to some degree relies on interdigit timers in those areas of the plan with more variability.

Now, given we're introducing a common database of numbers, the users of that database (ie the telcos) felt it appropriate to add functionality to it to indicate when it had been queried with insufficient digits.  Otherwise, we yield the benefit of not having to break out each individual number range for routeing purposes on our callservers (database is telling you that info), only to lose it because we have to break them out to check we've got enough digits prior to querying the database.  

A sensible telco won't be querying the database each time an end-user keys a digit, there would still be some basic number length info in the callserver.  For example, in the geographic code 01744 I know there are 10 & 11 digit numbers so will query after 10, receiving a Send-1 if it turns out the individual level within 01744 is one which is 11 digits long.  Conversely, 01772 has only 11 digit numbers so I'll query after 11.  This means the number length tree I have to hold on my nodes is <1000 entries long, versus nearer 25,000 entries now.

There's a valid question of whether Send-N should have been in the same database as the individual numbers, but from our perspective we're building a common/private database, and it makes little sense to build/have to query two separate databases versus putting it in a single one.  As an individual number database, we don't have wildcards, and in any case in a regime with portability meaning the numbering space is highly fragmented they're of little value.  I doubt there are any number ranges in the UK that are used solely by a single telco with no exported numbers so wildcarding based on number range simply doesn't work (as highlighted by Richard Stastny's mail).

As I say, I'm ambivalent on the usage in public ENUM.  Certainly there appears to have been a misconception to date that ENUM clients will know when the user has completed dialling.  For fixed length plans and applications where the customer has a "send"/"call" key that is the case, but for blackphone support it certainly isn't without using interdigit timeouts.  The ITU information has been mentioned as helpful.  Thanks for that, I kicked off the initiative back in 2000 so glad to hear it's added some value.  However, it really isn't much more than a map to provide clues (either to number length or where to go to try to find out)...it certainly isn't a reliable or comprehensive source of data for originating telcos to know how many digits to expect on international calls.

Regards

Paul Rosbotham
Manager, Interconnect Strategy & Technology Regulation 
Cable&Wireless 
Europe, Asia and US
Direct Dial: +44 1772 451506
Mobile: +44 7957 805573
www.cw.com 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Lawrence Conroy
Sent: 09 April 2008 23:50
To: Jay Daley
Cc: [email-masked]
Subject: Re: [Enum] Overlap dialing user experience (Re: I-DAction: New
draft - draft-bellis-enum-send-n-00)

Hi Jay, Brian, folks,

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: "Brian Rosen" <[email-masked]>
Date: Thu, 10 Apr 2008 12:40:52 -0400

Richard

Staying on track, the problem I want solve is to determine how many digits
are needed to route to the terminal domain.  In DE and AT, you have this
variable length capability.  I understand that.  I would expect that if I
found the equivalent number plan in the ITU bulletin for Austria, I would
find that there was a block something like 1 979 XXXX with a min of 8 and
max of 9 digits.  That is enough information to figure out when there are
enough digits to query ENUM, and is enough information to construct a T1
that works.  I would need access to the number portability database to route
the call if this block was subject to portability.

Brian

-----Original Message-----
From: Richard Stastny [mailto:[email-masked]] 
Sent: Thursday, April 10, 2008 11:43 AM
To: Brian Rosen
Cc: 'Jay Daley'; [email-masked]
Subject: Re: [Enum] Overlap dialing user experience

Brian,

regards

Richard

Brian Rosen wrote:
>> simply, without requiring deployment of user enum, that is, in my
opinion,
> a

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Apr 2008 12:44:56 -0400

Paul R,

Your reply was educational to me. Thanks.

You talk of this as primarily for SP, and question applicability to user 
enum. I understand that, I think. But the SP can only do this when it 
knows there is a call attempt. That works fine when it is a black phone 
connected to a SP server, sending digits one by one.

But what happens when the client phone is itself a sip UA? Even if it is 
going to delegate the call routing decisions to a SP server, it still 
has to determine the end of the dial string in order to know when to 
send an INVITE. So it seems that this DB needs to be accessible from 
those customer devices. How does that fit into your view?

	Paul K

---

From: Richard Stastny <[email-masked]>
Date: Thu, 10 Apr 2008 22:29:37 +0200

Brian,

 > I would expect that if I
 > max of 9 digits.

in the ITU bulletin for AT you only find for
NDC 1 (Vienna)
N(S)N max length 13
N(S)N min length  4

e.g. for NDC 664 (a mobile operator)
N(S)N max length 13
N(S)N min length  7

If you search for assigned number blocks
http://www.rtr.at/de/tk/Rufnummernsuche
you find only the 3 digit blocks and the carrier
e.g.
(0)1 200 Verizon Austria GmbH

I do not think this helps
The data has to be derived from the carriers
and you cannot build a flat T1.

 > I would need access to the number portability
 > database to route the call if this block was
 > subject to portability.

I am confused, I thought I-ENUM IS the NP database.

Richard

Brian Rosen wrote:
>> opinion, a

---

From: [email-masked]
Date: Fri, 11 Apr 2008 08:45:48 +0100

> I'm assuming someone wants to present send-n or successor document in

Absolutely, if that's what's required to progress it.

I'm on holiday at the moment, returning April 21st.

I'll summarise and issue a revised draft very shortly thereafter.

cheers,

Ray

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 11 Apr 2008 15:19:55 -0400

I'll request at 2 hour slot ...

>  Of [email-masked]
>  Sent: Friday, April 11, 2008 3:46 AM
>  To: [email-masked]
>  Subject: Re: [Enum] Chair Question...
>