Subject: Re: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published

From: Peter Koch <[email-masked]>
Date: Tue, 1 Jul 2008 16:27:35 +0200

Ray,

> > "Send-N" stuffs lots of metadata in the tree that I think doesn't
> > belong there.
>
> As a DNS guy, do you see any mileage in Eleanor McHugh's suggestion of an
> RR that could represent tree-depth information in *any* DNS tree?

You mean this [quoting Eleanor McHugh]:
>> You've identified an interesting problem: how to validate the depth/
>> shape of namespace tree branches allowed given an intermediary point
>> on that tree. A general case solution using a new RR type could be
>> useful in places other than just ENUM, and if that's the case your
>> send-n proposal will either lead to the proliferation of copycat
>> solutions in other hierarchies or else be an evolutionary dead-end
>> when an RR does get defined. Therefore you have nothing to lose by
>> proposing an appropriate RR in the first place.

Well, I guess, I can say I share the academic interest, but I'm not sure
this is in any way better than "send-n" except its generality. One could
define a QTYPE that would return the number of empty non terminals at
or below a node in the DNS tree.  Still I don't agree with the need.

> Yes, for the user it's the final digit time-out.  When should the switch
> decide "enough is enough, it's time to try an ENUM lookup"?

Depending on the numbering plan determined by country prefix, it might be
sufficient to suppress the first n queries, where n is, say, two more than
the length of the area code being dialled. That would mean the client was
able to identify the are code.  But the ENUM lookups don't have to be blocking,
so why not let the client send an ENUM query after every digit (see above
for prefix/area code considerations)?

> For the server it's a potential 5-fold reduction in the number of queries.
>  If your switches are doing this lookup for every telephone call that's a
> *lot* of queries saved.

In the best case, maybe, but you need the cooperation of the clients and you
add a lot of complexity to the ENUM tree.  I've still not seen a convincing
argument that this query optimization is solving a real load problem.
Apart from that, there's also lots of optimization opportunity in the client
if you just let the client remember what a "full number" was; I've been
told this is already done.

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

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Tue, 1 Jul 2008 15:34:55 +0100

Peter Koch said:
> But the ENUM lookups don't have to be blocking,

Because it's still load on the servers that would be worth reducing.

> In the best case, maybe, but you need the cooperation of the clients

As is true of many optimisation techniques. That shouldn't be an issue for
this use case.

> and you
> add a lot of complexity to the ENUM tree.

I don't see how you can describe this as "a lot".

> told this is already done.

What do you mean by a "full number"? The whole problem is that it isn't a
simple thing to determine.

-- 
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: Jim Reid <[email-masked]>
Date: Tue, 1 Jul 2008 16:02:58 +0100

> Because it's still load on the servers that would be worth reducing.

I'm not sure that this load is ever likely to be significant in the  
overall scheme of things Clive. Is there any hard data here or are we  
all just working on guesses? How much query traffic could send-n  
actually save as a proportion of the overall number of DNS lookups  
that will be going on inside the NICC's private ENUM-like tree? I  
would assume that these lookups would be passing through some sort of  
resolving server, so there should be a Big Win for cache hits after  
the initial "priming" query.

Mimimising queries and reducing load is always a Good Thing. Sometimes  
though the cost of doing that exceeds the benefit. It's not clear to  
me where the balance lies for send-n. It does seem a bit strange to  
propose a new NAPTR type to deal with a possible operational problem.

---

From: Peter Koch <[email-masked]>
Date: Tue, 1 Jul 2008 19:11:13 +0200

> Because it's still load on the servers that would be worth reducing.

at least me would feel much more comfortable if this claim was substantiated
by facts, figures, measurements.

> As is true of many optimisation techniques. That shouldn't be an issue for

Only if you can sanction non-optimizing clients; otehrwise the (perceived,
so far) gain only benefits the server, so why would the client dare to
implement the optional send-n feature?

> I don't see how you can describe this as "a lot".

Adding a NAPTR for a significant fraction of all empty non terminals?
Thereby sacrificing the additional information that "ENT" might have given
you?

> simple thing to determine.

It is, once you succeded to placing a call there.  If the client (or the
PBX) remembers a list of dialed numbers, you can follow the digits until
you either match the number again or until you find the first differing
digit.  Of course, that's a client "cooperation", as well.  And from what
we've heard so far, it might not work well in AT.

-Peter

---

From: Edward Lewis <[email-masked]>
Date: Wed, 2 Jul 2008 18:45:29 -0400

At 18:08 +0200 6/30/08, Peter Koch wrote:

>understood.  Since that is an optimization for a provisioning issue of
>- to me - unclear frequency of occurence, would much be lost with using
>the absolute value only?

I'm responding to Peter's message to amplify at least to very good 
points he made.  This is one of them.

When I read the draft, I was first shocked at the choice of a 
relative number in the record.

My mind shot back in time to the debates over the IPv6 records for 
addresses, namely the AAAA record (and PTR for reverse) and the A6 
record (with something called bit labels for the reverse).  The 
former was the already defined, static absolute approach, the latter 
an up and coming relative approach, all the rage at the time (2001).

The benefits of A6/bit labels were that it was helpful in network 
renumbering, that is, if the (IPv6 network) prefix changed the local 
part could remain the same. The change would have very little impact 
on the provisioned data in the DNS.

The drawbacks became evident when the experts tried to explain how 
this worked on the chalkboard.  I never saw anyone walk through an 
entire, non-trivial example without a serious error.  That is, it was 
confusing for even an expert (much less a field engineer debugging a 
live system).  Secondly, with some carefully crafted entries, it was 
possible to tie up the resolution process in a nearly endless cycle 
of queries and assemblies of addresses.

I should point out that some of the drawbacks were unique to the 
A6/bit labels.  This is because it was the DNS as client in the 
lookup process.  With the send-n  use case, the DNS is only on the 
server side and wouldn't suffer.  Still, to this day relative offsets 
carry red flags as there is a potential for errors to pop up in the 
ENUM clients.

This is why my knee-jerk reaction is to suggest that absolute numbers 
be used.  A little pain in the provisioning side will save a lot of 
suffering on the resolution side.  DNS's great strength is the 
resolution side, don't hamper it!

>Inter-digit timeouts, as far as I understand, would bite the dialing customer
>at the end of their dialing process because only after the timer's
>expiration would the full number be submitted to the ENUM lookup mechanism.
>But since the human can't dial at light speed - where's the gain in terms
>of latency over just querying after each digit pressed?

This isn't a DNS topic (referring to Peter's title as DNSOP chair as 
representative of one of his fields of expertise), his words echo my 
thoughts as I read the draft.  I do know that there are times I half 
dial a number and then have to squint again at a piece of paper, but 
it is usually apparent when the dialing is over.  Further, telephone 
dialing is so slow now, I wouldn't know if there was a longer delay 
"just to make sure" I was done dialing.

>Apologies.  NAPTR is becoming the TXT RR for enum; everything can be put

Back to the DNS side of the house, this is another opinion of Peter's 
I will second.  If you want to put a dialing plan in the DNS, just 
use TXT records and store it somewhere else!  The NAPTR has two 
outcomes - rewriting the URI you are trying to resolve or redirecting 
your DNS lookup.  Using it to convey data about the data model, well, 
it may be possible, but not in the scope of the NAPTR mission.

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

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

---

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

Peter - following up this comment again:

> in there so conveniently, especially using "data" type URIs.  That's not
> what NAPTR was designed for.

I wonder where this concern about NAPTR becoming a dumping ground for data 
has come from?

The whole DDDS architecture is *supposed* to be a generic database lookup 
system, albeit one that has its origins in ENUM.  The only implementation 
of DDDS that I'm aware of is RFC3403, and *that* is what specifies NAPTR 
records, not the ENUM RFCs.

One *could* write a Send-N U-NAPTR Application that sits in its own DNS 
tree that happens to represent the structure of some other DNS tree.  That 
might not be so controversial, but it would *still* be using NAPTR 
records.
 
As it happens, though, it's actually possible to put the data in the 
*same* DNS tree, albeit there are a couple of special edge cases that have 
to be taken into consideration.

Ray

---

From: Eleanor McHugh <[email-masked]>
Date: Thu, 3 Jul 2008 14:03:49 +0100

> to be taken into consideration.

This probably isn't the time or place to mention it (and apologies to  
those of you who've sat through discussion of these in the company of  
beer) but NAPTRs can be used for all kinds of fun purposes once you  
start thinking of them as generic production rules or s-expressions:  
URI validation; cross-service API translation and aggregation;  
relational data stores; multi-directional hyperlinks; all kinds of fun  
stuff.

I wouldn't necessarily advocate any of these as real world  
applications mind as they're outside the scope of DNS's core purpose,  
but it is amazing just how flexible a tool the U-NAPTR can be.

Ellie

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

---

From: Lawrence Conroy <[email-masked]>
Date: Thu, 3 Jul 2008 14:33:10 +0100

Hi Ray, folks,
  Speaking of red herrings...

Re. D3S as a dump - are TXT records better than NAPTRs? ROFL
AFAICT, the logic here is that NAPTRs hold PoinTeRs, whilst data: allows
"final" data to be inserted. Then again, so does pstndata:. The names  
have
been changed, but the story is the same. It seems to me that Send-N is  
*NOT*
final data to be processed, but merely holds meta-data to assist in the
process. Whether that meta-data in Send-N is useful or needed in  
practice
is a reasonable question, but arguing that this is the same as replacing
TXT with NAPTRs (or that TXT is better) is not, IMHO.

Re. NTNs - these will have the effect of causing another lookup - that's
what they're intended to do. IMHO, there should be NO other impact at  
all.
You might want to point out that extra lookups are bad as they do cause
delays/extra traffic, but that is a general issue for infrastructure  
use.
Send-N seems to me to be no different. There will either be an NTN loop
or there will (eventually) be a target domain. That target domain either
includes E2U NAPTRs or it doesn't. You process those E2U NAPTRs or  
give up.
Done. This is bog standard stuff and is the case for any D3S  
application.

Regarding "collision avoidance" - this is covered in 3402 section 5,  
in 3403
section 3, and in 3761 section 2.4.2.
Why on earth would one need to cover it again in this Enumservice  
Specification
unless it is a particular problem for Send-N? I don't believe that is  
the case.
I would be surprised if anyone provisioned these in DNS node that also  
had
NAPTRs from other D3S applications - ENUM uses its separate tree as  
one means
for collision avoidance, and that's is broken if U-NAPTRs or 3263- 
style NAPTRs
are put there.

Regarding whether NAPTRs or another RR type should be used - NAPTRs  
seem to
have been chosen as there isn't a need for a further lookup once a  
terminal
node has been reached - any extraneous Send-N NAPTRs come along for  
the ride
when looking up a URI for communications. Thus for correctly entered  
numbers,
only one ENUM query is made. That's good, IMHO.

Please let's focus on whether or not Send-N solves a problem, whether  
the cure
is worse than the disease,  and whether the particular URI form is  
appropriate.

The rest of this thread is going to make the (Outside) Dublin meeting  
go on
for days, and we have only an hour :(.

all the best,
   Lawrence

---

From: Edward Lewis <[email-masked]>
Date: Thu, 3 Jul 2008 10:44:45 -0400

>I wonder where this concern about NAPTR becoming a dumping ground for data

(Not speaking for Peter...)

For one, the send-n draft.  For two a draft I wrote last year.

The draft I wrote was presented at the ENUM WG meeting in spring '07 
(Prague). I sought to record the E.212 information for a telephone 
number.  After "fleshing it out" and some discussions, it was 
withdrawn - well, left to expire.

It is tempting to define more and more schemes and (ENUM) services. 
There's no clean set of criteria to judge this, but there's a point 
at which "one more feature" is "mission creep."  The former is 
desirable, the latter a cancer.

>records, not the ENUM RFCs.

The kinds of mail threads I detest most are ones about what something 
is "supposed" to be.  I can't agree that DDDS is "supposed" to be a 
generic database, because the DNS upon which it is built is not a 
database - just a lookup system.

I think of it this way - DNS is a piece of infrastructure.  It should 
be quick, reliable, and never noticed by the end user.  A database is 
something more complex.  DDDS, ENUM, DNS - all are lookup mechanisms, 
not database mechanisms.

---

From: Leslie Daigle <[email-masked]>
Date: Thu, 03 Jul 2008 11:19:17 -0400

Hi,

[email-masked] wrote:
> system,

Yes.

 >  albeit one that has its origins in ENUM.

No.

Uniform Resource Names.

 >  The only implementation

Yes.

> might not be so controversial, but it would *still* be using NAPTR 

Yes.  The interesting question is whether that would (or should) allow 
differences of use of ENUM (i.e., different dialing plans), which seems 
to be part of the hearburn here.

Leslie.

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
[email-masked]
-------------------------------------------------------------------
_______________________________________________
enum mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/enum

---

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

On 3 Jul 2008, at 15:44, Edward Lewis wrote:
> The kinds of mail threads I detest most are ones about what  
> something is "supposed" to be.  I can't agree that DDDS is  
> "supposed" to be a generic database, because the DNS upon which it  
> is built is not a database - just a lookup system.
>
> I think of it this way - DNS is a piece of infrastructure.  It  
> should be quick, reliable, and never noticed by the end user.  A  
> database is something more complex.  DDDS, ENUM, DNS - all are  
> lookup mechanisms, not database mechanisms.

When I first started playing with NAPTRs on the .tel project I had  
lots of fun pushing them as far as they could be pushed just to find  
out what's possible and where they break. Once you start playing  
they're addictive :)

But having explored some particularly deep rabbit-holes I've come to  
the conclusion that DNS is not the place for any of them. As you say,  
DNS is infrastructure and it should be quick, reliable and innocuous.  
The NAPTR extends it elegantly to address unconventional resources  
(telephones with ENUM, people with .tel, web services, map grid  
references, whatever) but those resources should always remain  
separate from the DNS tree itself.

What makes send-n interesting is that it's neither a link nor a  
resource, but introspective meta-data. I can see the logic of a  
standard NAPTR that links to this data by generating an appropriate  
URI but using a NAPTR to embody the data itself feels somewhat akin to  
using an HTTP GET resource to update a database. This is the reason I  
feel send-n would be better handled via a different RR type  
specifically geared to tree introspection and validation.

I can't comment on whether or not such a generic solution has uses  
beyond ENUM or how acceptable it will be to the wider DNS community.

Ellie

Eleanor McHugh
Games With Brains

---

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

> I wonder where this concern about NAPTR becoming a dumping ground for data 

Ed, although not speaking for me, basically hit the nail.  "send-n" isn't
an ENUM Service, i.e. it isn't anything that you look up to support a
communication initiation. Instead, you'd actually look for a "real" service
and only use "send-n" in the absence of such, where this NAPTR would
conveniently be put into the response, since you asked for this specific,
RR type.  In turn, the pstndata URI doesn't identify a resource but is
a hack to encode arbitrary information in a place where a URI is expected.
This fulfills syntax requirements, nothing else.

-Peter

---

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

Ellie

> beyond ENUM or how acceptable it will be to the wider DNS community.

I can see the attraction but this is more a thought experiment than a 
practical solution.  This is because 

* it has no use case;
* the security implications are too great of one label being able to make 
statements about lower labels that might be under different admin control.

If you think it is a good idea then please suggest it to dnsext, but I 
suspect it will not get much traction.  Hence my view that send-n is best 
as it is, a limited solution for ENUM.

Jay

---

From: Eleanor McHugh <[email-masked]>
Date: Fri, 4 Jul 2008 02:08:20 +0100

On 3 Jul 2008, at 21:28, Jay Daley wrote:
> practical solution.

Agreed. But it's a thought experiment that could have practical value  
as it hints at there being more to the send-n problem than just  
hinting at the number of valid digits in an ENUM lookup.

> This is because

Well I can see benefits to it:

a. it solves the number length problem in ENUM
b. it allows the shape of portions of the DNS tree to be specified and  
validated
c. it could be used to enforce naming policies

and I'm certain that someone more knowledgeable in general DNS usage  
could build use cases which exploit these.

> statements about lower labels that might be under different admin  

I've missed something in my interpretation of the send-n draft as I  
don't see how using a non-NAPTR resource to achieve the same effect  
makes any difference. In both cases the RR is making statements about  
the shape of the tree beneath the current level.

> suspect it will not get much traction. Hence my view that send-n is  
> best as it is, a limited solution for ENUM.

Well I definitely lack the time or resources to take on such a  
sisyphian task, which I guess is the reason for send-n in the first  
place?

Ellie

Eleanor McHugh
Games With Brains

---

From: Peter Koch <[email-masked]>
Date: Fri, 4 Jul 2008 12:42:28 +0200

> a. it solves the number length problem in ENUM

may I ask for a description of this problem?  What is the input and what is the
desired output?

> b. it allows the shape of portions of the DNS tree to be specified and  

The problem here is that it doesn't buy you much in the general DNS case.
There you face the fact that hierarchy in the name space does neither
follow nor imply administrative hierarchy (or control, if you wish).
So, while under certain circumstances you might be able to make statements
about the current shape of the tree, you're likely not in a position to
communicate rules.  For this reason finding a use case could become hard.

However, the situtation is slightly different in the case of ENUM since
there is some hierarchy in the e.164 space.  However, the applicability
is dependent on which part of the tree you're in since the rules,
including who actually sets the lengths of certain number ranges, vary
by country.

>From a DNS perspective, another RR type would be cleaner; however, the
question is whether you're actually describing a property of the DNS or
a property of the data that is put into the DNS.  This may sound like
splitting hairs, but the length and completeness issues are around
the e.164 numbers, not necessarily the DNS representation, even though there
is a very straightforward mapping.  Anyway, the basic reason use of NAPTR
(with which I've voiced my discomfort before) is that that's what you
ask for so it can "nicely" be put into the DNS repsonse.  Another RR type
would have to be asked for explicitly _or_ some DNS rules would have to
be changed (or gravity, whatever comes easier) to insert this new RR type
(or any one, the problem isn't the novelty of the type) into the additional
information of the response.  This is yet another example where DNS is
that ultimater best fit for ENUM/I-ENUM, just needs these little tewaks ...

-Peter

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 11 Jul 2008 13:46:37 +0100

Tidying up along the thread. This isn't a major issue, but ...

Pete Cordell said:
>> Personally I'm not sure.  Clive thinks relative is useful.
> From what I understand of this issue, the relative form of send-n just does 
> not seem worth the grief.  It's already been said that the zone files (or 
> what ever the preferred DNS input will be) will be automatically generated 
> by some sort of automated process such as a script.  So, pre-number move at 
> some point a script will be used to generate a set of zone files.  When the 
> new number plan comes along it seems just as easy to re-build a new set of 
> zones based on the new number plan using the same script.
> 
> I'm probably looking at it too simplistically, but, because a script can so 
> readily generate a zone file for any given input, the only benefit I can 
> see for the relative form is that it allows someone to manually tweak an 
> existing zone.  (What would they do?  Copy an existing set, and then edit 
> the $ORGIN line?)

What I had in mind was to use DNAME.

So, if 01954 8xxxx is migrating to 01954 78xxxx, you would go:

$ORIGIN 4.5.9.1.4.4.e164.arpa.
8.7  DNAME  8

0.0.0.0.8  NAPTR ....
1.0.0.0.8  NAPTR ....
etc.

The send-n records would only work in this case if they were relative.

> I would therefore strongly encourage the authors to drop the relative form 
> of send-n.

It still seems sensible to me, but I'm not going to die in the ditch over
it.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 11 Jul 2008 14:00:32 +0100

Jim Reid said:
> all just working on guesses?

I don't have hard data, but I can give you some estimates.

Say 50 million telephone users in the UK. Assume each averages 1 hour of
calling per day, average call length 3 minutes, and a 25% failure rate of
call attempts (no answer, engaged, etc.). Finally, assume a busy-hour ratio
of 6:1.

That's then about 87,000 call attempts per *second*.

> How much query traffic could send-n  
> that will be going on inside the NICC's private ENUM-like tree?

For calls in the UK, as Paul has shown, you need a lookup at 8 digits -
without send-N, that's therefore 4 lookups per call. Send-N will eliminate
2 of those. So that's 174,000 queries per second saved.

> I  

Let's assume caching gives you a 10:1 saving (I'm not at all clear it will
be anywhere near that good), so that reduces it to a saving of 17,000
queries per second.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 11 Jul 2008 14:02:05 +0100

Peter Koch said:
> digit.

Looking at my phone bill, there's little similarity in called numbers.

---

From: Lawrence Conroy <[email-masked]>
Date: Fri, 11 Jul 2008 17:26:27 +0100

Hi  Clive,
  As Paul pointed out, this is not a UK-only problem.
However, looking at your numbers, I think you are gilding the lilly.
I disagree with your figures for the generality of UK telephone users.

I would have used: 6 calls per day, 3-4 in busy two hour period.
Average call length << 1 hour.

As for call attempts / completed calls, I'd defer to Paul if he's
willing to give out some numbers for his network. 4 call attempts
per completed call seems high.

Even so, we *are* talking about a DNS based system. Our friends in
Verisign assure us all their servers are hammered much more than this.
The total number of queries is distributed over the whole of the UK.
You are thinking about a decentralized system, I hope? This is DNS.

It also does cacheing. The propensity of people to call any individual
number is low, but not always. Particularly with the "problem" ones in
the UK, the propensity is likely to be much higher. For example, if we
are to believe the Daily Mail and its ilk, there must be thousand upon
thousand of calls to 0800 1111. This is going to remain resident in the
cache of any provider's full-service resolver. If there are multiple
queries for incomplete numbers, then these may also be in the "negative"
cache.

So - assuming a distributed system with separate authoritative servers
and full-service resolvers, does it really matter whether or not one
saves 50% or 75% of queries?

There may well be some recommendations on negative cache times, but  
isn't
that a DNSOPS issue, not one specifically for ENUM.

all the best,
   Lawrence

On 11 Jul 2008, at 14:00, Clive D.W. Feather wrote:
>>>> so why not let the client send an ENUM query after every digit (see
>>>> above for prefix/area code considerations)?

---

From: Lawrence Conroy <[email-masked]>
Date: Fri, 11 Jul 2008 17:33:04 +0100

Hi again Clive,
  again, I respectfully suggest that you are atypical.
The numbers that you call may well be different from those called by
your neighbours, but there is typically a fairly well defined called
circle (albeit with "outliers") for most people - unless perhaps they
run a one-man call centre.

A counter-argument: In my case, I have many calls to a small set of
numbers - the top 5 make up well over 2/3 of the number of calls I make
(and *much* more in terms of total call length).

all the best,
   Lawrence

---

From: Peter Koch <[email-masked]>
Date: Fri, 11 Jul 2008 19:18:30 +0200

> Looking at my phone bill, there's little similarity in called numbers.

hmm, you don't call anybody twice? ;-)

Also, not sure that a sample taken over a population of size one is a good
approach.  If the assuption didn't work I guess the technique would not
be implemented.
But again, some measurement would be fine.

-Peter

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Mon, 14 Jul 2008 09:17:48 +0100

> Average call length << 1 hour.

Average call length of 3 minutes is, I believe, the standard used in UK
telephony planning.

I can't remember where I got the "1 hour usage per day" figure from, so I
can't help with that. But my phone bill typically has at least 6 chargeable
calls per day, and this excludes all off-peak calls to landlines in the UK
(which are free on the package I'm subscribed to).

> per completed call seems high.

You misread; I'm suggesting 1.25 attempts per completed call (that is, one
failure for every 4 successful calls).

> You are thinking about a decentralized system, I hope? This is DNS.

Yes, but the question is how many calls can be served off the caches and
how many go back to the authoritative server.

Plus it's not just the DNS. The switches have to make the queries and this
takes CPU away from other tasks. Reducing the load on the switches is part
of the objective.

> are to believe the Daily Mail and its ilk,

Don't go there. Please.

> there must be thousand upon
> cache of any provider's full-service resolver.

True. But that doesn't help with other numbers.

> saves 50% or 75% of queries?

I would have still thought so, yes.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Mon, 14 Jul 2008 09:24:24 +0100

>> Looking at my phone bill, there's little similarity in called numbers.

I think there's a misunderstanding here. Peter wrote:

| >> if you just let the client remember what a "full number" was; I've been
| >> told this is already done.
| > What do you mean by a "full number"? The whole problem is that it isn't a
| > simple thing to determine.
| It is, once you succeded to placing a call there.  If the client (or the
| PBX) remembers a list of dialed numbers, you can follow the digits until
| you either match the number again or until you find the first differing
| digit.

I read this as a suggestion along the lines of: customer calls 01234567890,
therefore you can deduce that other numbers beginning 012345678 are the same
length.

To which my reply was trying to point out that there's little commonality
between the *different* numbers that I call. This may be a UK v US thing:
the numbers I call frequently are in several area codes, and even those in
the same area code will be in different DG groups (the 56 in the above
example). That's what I meant by "little similarity".

Perhaps Peter can re-explain his suggestion, since I clearly didn't
understand it.

---

From: Peter Koch <[email-masked]>
Date: Tue, 15 Jul 2008 13:38:27 +0200

> therefore you can deduce that other numbers beginning 012345678 are the same

the idea is to notice differences, not similarities.  If the customer called
01234567890 and dials 012345679999 next, the client would have to probe (query
for NAPTR, feed into an ENUM lookup) starting with only 012345679, because
that's the first differing digit.  There is no conclusion drawn about the
length of 012345679*, because there are just too many options, at least in +49.

-Peter

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Wed, 16 Jul 2008 10:55:19 +0100

> length of 012345679*, because there are just too many options, at least in +49.

Ah, I see.

I have no idea how that would play out in general. In the case of the
numbers I call frequently, they rarely match longer than the 01234 stage.

Of course, in our problem domain the "client" is a local or even regional
switch or callserver. I'm not sure how well that approach would work.

There's also the question of how long you can assume the conclusion is
valid.

---

From: Duane <[email-masked]>
Date: Fri, 18 Jul 2008 08:38:50 +1000

If this information must go in DNS I agree with everyone else that
suggested this should get it's own DNS type, it would if nothing else
reduce the size of the DNS packet substantially, as well as not
interfere with NAPTR wildcards.

Although I thought it was a weak argument about offloading processing,
since the processing has to be done somewhere no matter what.

Having a new DNS type it would only need 1 byte for data, which would
speed up processing of the information since it doesn't need to deal
with regex and so on.

DNS Type SENDN ID to be assigned by IANA, packet structure:

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|MinDig |MaxDig |
+-+-+-+-+-+-+-+-+

Since the maximum length can only be 15 this fits perfectly inside a
nibble :)

-- 

Best regards,
 Duane

---

From: [email-masked]
Date: Fri, 18 Jul 2008 08:53:37 +0100

> interfere with NAPTR wildcards.

I don't believe there's anything like consensus on this.  For example I 
recall Lawrence specifically agreeing that getting the Send-N response as 
an automatic side-effect of an ENUM lookup was a good thing.

Also see Roy's message of 30/06 where it was explained how using a 
different RRtype doesn't affect wildcard processing - a more specific 
RRset containing *any* RRtype will prevent any wildcard expansion that 
would otherwise have succeeded.  However it's perfectly acceptable to put 
the Send-N in the wildcard RRset, or in a less specific RRset.

Personally I don't like the bloat of NAPTRs either, but for performance 
reasons we (NICC that is) consider that getting an answer back in one 
round-trip is more important than the size of the response.

If someone can propose a way to use a new RR-type which works with an 
optimal number of packets (i.e. 1) rather than size of packets then I'm 
open to it.

Jim Reid had suggested (off-list) that the Additional Section could be 
used for this.  However that would require any DNS server software 
implementing Send-N to be engineered to return this data there if the 
requested NAPTR doesn't exist.  The DNS clients would also need to be 
engineered to actually look in that Additional Section if there's nothing 
in the Answer Section.
 
> DNS Type SENDN ID to be assigned by IANA, packet structure:

Except for flags to indicate absolute vs relative :)

Ray

---

From: Duane <[email-masked]>
Date: Fri, 18 Jul 2008 19:03:55 +1000

> optimal number of packets (i.e. 1) rather than size of packets then I'm 

You use the new DNS RR in the same way(s) you are proposing to use a
NAPTR record. As I said in my previous email, a new RR type wouldn't
have all the regex/text processing overhead so using binary parsing
would speed things up considerably.

> Except for flags to indicate absolute vs relative :)

 0 1 2 3 4 5 6 7 8 9 a b c d e f
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MinDig |MaxDig |F|0|0|0|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Anything else?

-- 

Best regards,
 Duane

---

From: [email-masked]
Date: Fri, 18 Jul 2008 10:41:18 +0100

> would speed things up considerably.

Sory - I think you missed my point.

With overlapped dialling, one would send a DNS query with QTYPE = NAPTR to 
see if a full ENUM record is available.

With Send-N, the full record isn't available, but a Send-N NAPTR is 
returned in its place.  This is the standard DNS behaviour, with no 
special processing required at either end and it's all done in one DNS 
request round-trip.

If a different RRtype is used for Send-N, the DNS client receiving NOHOST 
for the QTYPE = NAPTR lookup would need to send a second DNS request with 
QTYPE = SENDN.  That's specifically what we're trying to avoid.

The alternative would be to send QTYPE = ANY, but that's definitely 
considered bad practice.

Ray

---

From: Lawrence Conroy <[email-masked]>
Date: Fri, 18 Jul 2008 10:44:01 +0100

Hi Duane,
  What Ray has raised (and is not addressed by your mails) is why
this is a NAPTR. It's like this because the client makes one query
- for DNS type 35 - and gets back not only this one but also any
Send-N answers.

Thus, if the client has the correct number of digits already (e.g.
the end user has an en-bloc phone and has entered the full number
before hitting the send button), the final answer comes out with
a single query.
Thus for that [common] case, there is NO DNS QUERY OVERHEAD at all.
That feature is more than good - it's crucial if this is deployed
in a real telecom net. DNS scales, but elapsed time is still important.

----
I am puzzled, however, by this long and peregrinating thread.
There is one question that seems to have been missed - does this need
to be an E2U NAPTR, or instead could it use another DDDS Application
(i.e. use a different collision-avoidance string)?
There is nothing in 3761 (or 3761bis) that says that E2U NAPTRs are
the only ones that can appear in a domain under e164.arpa.
If this were another DDDS Application, any Send-N will come back in
the same DNS response to a type 35 question. There would continue to
be no overhead for the en bloc case.
There would, however, be more flexibility, instead of being constrained
with a comedy URI. Public ENUM clients will automatically discard any
such NAPTR in the RRSet as it doesn't have the right collision-avoidance
string (E2U) -- assuming that the client is not totally broken.

So... what's wrong with moving this (and maybe other PSTN-internal
meta-information specifications) into their own DDDS Application?

all the best,
   Lawrence

---

From: Lawrence Conroy <[email-masked]>
Date: Fri, 18 Jul 2008 11:19:05 +0100

Hi Ray, folks,
  Quick point - "QTYPE = ANY" is not an alternative (other than to  
sanity).
"ANYthing you have lying around right now" is not what you want (ever).
all the best,
   Lawrence

---

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

> QTYPE = SENDN.  That's specifically what we're trying to avoid.

Then go with the additional records suggestion then, since you more than
likely will have to poll 2 separate databases, what exactly is wrong
with returning this information as either a pseudo RR like EDNS0 or
something to that effect?

Actually that would be the smart way to do it, the client sends a EDNS0
requests or something similar asking for send-n too, otherwise only
NAPTR records are returned.

-- 

Best regards,
 Duane

---

From: Lawrence Conroy <[email-masked]>
Date: Fri, 18 Jul 2008 12:55:15 +0100

Hi Duane, folks,
  I know it's friday afternoon, but is it strictly necessary to re-write
DNS (by requiring new pseudo-opts in DNS messages) to do Number Port?
First we have ANY, now we have new pseudo-opts.
Please consider the LEAST change that will work efficiently *first*,
not jump straight to something that needs the world to change.

all the best,
   Lawrence
[envious, as he obviously hasn't had the same number of beers at  
lunch :]

On 18 Jul 2008, at 12:11, Duane wrote:
> what exactly is wrong

---

From: Duane <[email-masked]>
Date: Fri, 18 Jul 2008 21:55:37 +1000

> not jump straight to something that needs the world to change.

Actually it's Friday night here, that aside the world isn't changing,
the send-n folks are trying to change it by breaking wild cards and
causing looping in certain situations.

So when it comes down to the crux of it, you'd rather do a quick hack
than do it properly?

-- 

Best regards,
 Duane

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 18 Jul 2008 13:10:46 +0100

> causing looping in certain situations.

Neither of these is the case.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 18 Jul 2008 13:12:21 +0100

> in a real telecom net. DNS scales, but elapsed time is still important.

Right.

> (i.e. use a different collision-avoidance string)?

I don't see any particular thing that requires E2U.

> meta-information specifications) into their own DDDS Application?

Apart from the amount of I-D writing, nothing that I can see.

---

From: Eleanor McHugh <[email-masked]>
Date: Fri, 18 Jul 2008 13:47:38 +0100

> special processing required at either end and it's all done in one DNS

I interpreted his comment to mean 'no regular expression processing'  
as obviously this has a processing cost. Perhaps using an S-NAPTR  
style scheme with static data might alleviate this?

> QTYPE = SENDN.  That's specifically what we're trying to avoid.

Indeed latency will be the single biggest cost, especially for mobile  
devices. It's all too easy to forget this. Of course there's no reason  
why the client can't send two DNS requests at the same time, one for  
NAPTRs and one for another RRTYPE, then act depending on which brings  
back a meaningful result, but this of course would double the number  
of requests to be handled by the DNS server relative to the number of  
ENUM queries required.

> The alternative would be to send QTYPE = ANY, but that's definitely

Although in this particular instance it might be appropriate...

Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
http://www.linkedin.com/in/eleanormchugh

---

From: [email-masked]
Date: Fri, 18 Jul 2008 14:34:45 +0100

> "ANYthing you have lying around right now" is not what you want (ever).

That's what I meant - QTYPE = ANY is a theoretical solution, but you 
wouldn't want to do it.

Ray

---

From: [email-masked]
Date: Fri, 18 Jul 2008 14:55:38 +0100

> (i.e. use a different collision-avoidance string)?

That's a very interesting question, and one I don't have an obvious answer 
for.

Peter Koch said that Send-N isn't actually an ENUM Service, and 
technically he is of course correct.

> be no overhead for the en bloc case.

There is certainly some sense in clients being able to filter by type 
rather than subtype, particularly as the processes for filtering and 
ordering based on subtype are less than crystal clear.

If I have any niggle with the idea it's that this would effectively 
interleave two separate DDDS applications in one DNS lookup.  That doesn't 
really bother me, although I can imagine some might object.

> meta-information specifications) into their own DDDS Application?

For reasons already outlined it would still need to be a DDDS NAPTR, and 
therefore it would still need to use the regexp rewrite fiel.   I'm not 
convinced that it would make sense to radically alter the currently 
proposed Send-N URI format, particularly if Send-N is just one of a set of 
future meta-data types.

Richard - what plans (if any) do you have for your CNAM draft?  Obviously 
I've borrowed heavily from that for my URI syntax.

Ray

---

From: Duane <[email-masked]>
Date: Sun, 20 Jul 2008 14:19:20 +1000

> proposed Send-N URI format, particularly if Send-N is just one of a set of 

I'm pretty sure it was you that made the comment about the DNS software
you're using is custom written, it would be almost silly to pre-populate
a database with all the possible combinations when most are the same etc.

Someone else, maybe it was you mentioned this was meta information, your
reasoning for keeping this in NAPTR space is to reduce lookups, fair
enough, so still do it under a new RR type, and return this in the
additional section along with NAPTR records in the answer section.

If you aren't going to pre-populate a DNS database (like BIND) then
where is the issue with sticking it under some other RR type?

-- 

Best regards,
 Duane

---

From: [email-masked]
Date: Sun, 20 Jul 2008 09:17:58 +0100

> a database with all the possible combinations when most are the same 
etc.

There are cases where the Send-N records could be completely automatically 
synthesised in real-time.

In the UK case, however, each carrier is expecting to secondary 
significant portions of the database into their own DNS servers.

We don't expect those carriers to perform the same synthesis, therefore 
the Send-N's are expeced to be pre-populated as real RRs in the zone file. 
 They'll be available in IXFRs just like any other RR.

> where is the issue with sticking it under some other RR type?

This idea of using the Additional Section and why it was rejected was 
mentioned a couple of days ago.

There was a lot of concern from the WG as to whether Send-N would change 
any semantics of DNS (specifically wildcards, of course).  IMHO, making a 
change which relies on non-standard behaviour in any server would do just 
that.

The UK CDB operator may well use customised DNS server software, but its 
behaviour as currently proposed will look completely standard to the 
outside world.  We also can't expect all of the carriers who are 
secondarying the zones to have to run customised DNS server software with 
special Additional Section handling.

FWIW, I think Lawrence is onto something when he suggested a separate DDDS 
service (albeit in the same tree).  I'd like to hear what others think of 
that.
 
Ray

---

From: Jay Daley <[email-masked]>
Date: Sun, 20 Jul 2008 20:43:38 +0100

> where is the issue with sticking it under some other RR type?

1.  Because we only need it for ENUM.

2.  Because the hierarchy of ownership of labels for ENUM is completely 
different from the hierarchy for ordinary DNS and in ordinary DNS it is 
not acceptable for the owner of one label to make authoritative statements 
about a lower label under different ownership.

Not to mention the fact that this is the wrong place to discuss this - 
DNSEXT is the place for a new general RR.

Jay

---

From: Jay Daley <[email-masked]>
Date: Sun, 20 Jul 2008 20:45:48 +0100

Lawrence

> meta-information specifications) into their own DDDS Application?

A very good idea.  What else needs to be wrapped up in it other than 
send-n?

Jay

---

From: Jim Reid <[email-masked]>
Date: Tue, 22 Jul 2008 20:22:03 +0100

Apologies for using a meaningful Subject: header. Well someone had to  
make a start.....

> 1.  Because we only need it for ENUM.

No, it's needed for a behind-closed-doors version of 4.4.e164.arpa.

> different from the hierarchy for ordinary DNS

Rubbish. The DNS has never, ever cared about "ownership of labels"  
whatever that means. A client does a lookup and gets a response. It  
doesn't have the slightest interest in who "owns" the label or  
operates the name servers for it.

> and in ordinary DNS it is

Aha! I suppose you mean delegation points and zone cuts. Well what you  
say is true up to a point: though our DNSSEC friends have done a good  
job of demolishing that. DS records, anyone?

Even so, your point Jay is a diversion. IIUC, there won't be  
delegations in this behind-closed-doors version of 4.4.e164.arpa. This  
list has been told about a monolithic name space, database driven DNS  
records and even responses being generated on the fly. This doesn't  
look anything like a conventional delegation model where longer labels  
are handed out to distinct "owners". Or am I missing something?

> DNSEXT is the place for a new general RR.

Indeed. This is why I privately suggested to Ray that he replace send- 
n with a new RRtype template that should sail through the 2929-bis  
process.

Aside from all the heat that's being generated here, I think send-n is  
in trouble because it does not define a URI. I'm still far from  
convinced about the alleged benefits of saving the odd DNS lookup: the  
latency is one valid point, but some extra queries, so what? The  
resolving entities will presumably acquire a rich cache very quickly, 
_______________________________________________
enum mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/enum

---

From: "Jay Daley" <[email-masked]>
Date: Wed, 23 Jul 2008 09:59:28 +0100

Jim

> operates the name servers for it.

I'm sure you know this, but just in case ... in DNS a parent never makes 
an authoritative statement about a child's data.  If you have a new RR 
Type like this that can apply to any part of DNS then it will allow a 
(grand)parent to make an authoritative statement about a (grand)child's 
data.

> job of demolishing that. DS records, anyone?

Sorry. maybe you do know it.

> are handed out to distinct "owners". Or am I missing something?

Yes you are missing something - the whole point from what I can see.

In many instances of ENUM it is acceptable for a parent to make an 
authoritative statement about a child.  So that's why doing this for ENUM 
is acceptable, whereas a new RR type is not.

> n with a new RRtype template that should sail through the 2929-bis 

'sail through' - you're having a laugh!

> resolving entities will presumably acquire a rich cache very quickly, 

In the telephony world there is increasing pressure towards changes of 
routing (such as porting) to be reflected very quickly.  Mainly to avoid 
circular routing or failed calls.  So caching is much less a useful tool 
than you might imagine.

So what do you think of Lawrence's sensible suggestion of making 
pstn/numbering meta-data into a new DDDS application - equally dismissive?

Jay

---

From: Peter Koch <[email-masked]>
Date: Wed, 23 Jul 2008 13:04:15 +0200

> job of demolishing that. DS records, anyone?

well, this is not only about delegations and zone cuts, but about general
properties of the namespace.  And even though we have a hierarchy, the
DNS follows the principle that any information is published in place,
not inherited from "above", because such an inheritance doesn't exist.
For example, we have _lots of_ domains under DE which are maintained within
the DE zone.  Still no data at the DE level should apply to these domains
any more or less than it applies to a delegated domain -- zero in both cases.

Now, that's the general DNS rule.  However, there are parts of the DNS
namespace that are mappings of other name- or numberspaces, like e164.arpa.
The question of hierarchy, inheritance and the like is influenced by
the properties of the mapped name- or number space, not the DNS.
Therefore I doubt anything "generic" at the DNS level could or should help.

> n with a new RRtype template that should sail through the 2929-bis  

Except that it might not be eligible for the 2929bis process if it tries to
be "DNS generic" and it wouldn't have the appeal of being automatically
piggy backed onto the DNS response, like any NAPTR "re-use" would.

> resolving entities will presumably acquire a rich cache very quickly, 

Mobile devices have been mentioned as where latency matters, but then
I wonder why overlap dialling would appear with those devices in the
first place, since we're usually used to press the "green" button on
handhelds anyway.
The figures I've seen so far re: query volume have neither been frightening
nor convincing, so I'd like to re-issue my plea to first agree on the
size of the problem before designing or even standardizing a solution.

What I'd also like to learn during the Dublin discussion is whether "send-n"
is envisioned for private I-ENUM only or also for other applications and
whether the envisioned scenario (in case of private I-ENUM) would or
would not involve a "normal" DNS server and resolver infrastructure, including
delegations and caching, that is.

-Peter

---

From: [email-masked]
Date: Wed, 23 Jul 2008 12:37:29 +0100

> first place, since we're usually used to press the "green" button on

Indeed - modern "smart" devices with dial buttons are not expected to be 
the issue - dumb DTMF phones are.

> size of the problem before designing or even standardizing a solution.

I don't have any absolute volume figures available - call establishment 
volume data is very hard to come by.  Paul Rosbotham may be able to help 
there.

We can however model the relative saving the Send-N might achieve, 
although that in itself is country specific and also depends on how much 
base logic you're prepared to put in your switch.

For +44 we know that a completely naive implementation of overlapped 
dialling without Send-N would do up to 12 lookups (it would be less if 
they got to a part of the tree that didn't exist and hence returned 
NXDOMAIN).

A smart implementation with Send-N for +44 can do just two lookups.  The 
first is done after the first 9 digits, and because of the properties of 
+44 will get either a full NAPTR or a final Send-N.  If that Send-N is 
followed the next lookup will be a full NAPTR or NXDOMAIN.  This is 
because the +44 number length table does not change beyond the 9th digit.

There's probably a middle ground in benefit somewhere between the two, 
because nobody would use the completely naive method.

> would not involve a "normal" DNS server and resolver 
infrastructure,including
> delegations and caching, that is.

It has its origins in a private I-ENUM scenario, but should multiple 
private I-ENUM trees become interconnected it would have uses too.

The current proposal works with completely "normal" DNS server software 
and infrastructure, including caching.  Delegation (i.e. of blocks to 
carriers) would work, but isn't proposed for the UK database.

I don't personally have any use-cases for public ENUM in mind, but that's 
not to say that there aren't any.  I happened to be talking to a VoIP 
operator yesterday who was saying that using "Address Incomplete" in SIP 
to try and implement overlapped dialling was anything but satisfactory 
because of the massive performance load caused by each new SIP dialog.

Ray

---

From: "Rosbotham, Paul" <[email-masked]>
Date: Wed, 23 Jul 2008 13:23:01 +0100

Did someone mention my name?

> volume data is very hard to come by.  Paul Rosbotham may be 

Obviously the UK portability solution's based upon telcos taking a download of the whole thing and querying locally.  So it depends on the specifics of each individual CP.  Off the top of my head, a typical mid-size telco would be generating perhaps 2-3000 call attempts per second.  In the "naive" / no Send-N scenario Ray mentioned...which clearly wouldn't happen because if there was no Send-N the originator would seek to construct the decode information to some extent...that would mean 25k-35k queries per second.  An incumbent would generate maybe 3 or 4 times as much.    

There's pretty much zero correlation between the numbers called/queried at a callserver level - I guess there's scope for a degree of cacheing at a higher level...i.e. if you queried on 1.4.4.foo and got no NAPTR back, then it's worth cacheing at that level but cacheing the NAPTR returned by 6.0.5.1.5.4.2.7.7.1.e164.foo is of limited value unless you have an absolutely enormous (as in 60-70M entry) cache.

Of course (separate debate on this thread) there's the issue of whether we're talking about usage of Send-N for a specific quasi-private ENUM instance, or the public e164.arpa one.  I believe Ray's intent was to leverage the thinking for utilisation in the latter.  The volumes of queries on public DNS is then linked to the number of users querying it.  Anyone got a piece of string that I can measure?

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: Eleanor McHugh <[email-masked]>
Date: Wed, 23 Jul 2008 13:32:05 +0100

> (grand)parent to make an authoritative statement about a  

Jay, this is probably pedantry of the worst kind and I apologise in  
advance, but the RR Type suggested would not be making authoritative  
statements about the child node's data - it would be making such  
statements about the child node's very existence. This may or may not  
be a good thing from an administrative perspective as it's a slippery  
slope from this kind of meta-data to more generic DNS tree inspection.

Ellie

Eleanor McHugh
Games With Brains

---

From: [email-masked]
Date: Wed, 23 Jul 2008 13:36:15 +0100

> Of course (separate debate on this thread) there's the issue of 
> whether we're talking about usage of Send-N for a specific quasi-
> private ENUM instance, or the public e164.arpa one.  I believe Ray's
> intent was to leverage the thinking for utilisation in the latter. 

Not at all - I'm thinking more of international level interconnects 
between (private) I-ENUM trees used for different countries' NGNs.

Ray